Why Jira needs to sync userPassword from a LDAP Directory ?

[Feng Xi]

I'm trying to add a Directory in Jira with directory type as "LDAP" (not Internal with LDAP Directory).

According to my understanding, most of the settings are used for sync users/groups from external ldap to Jira, and delegate the jira login to ldap server(LDAP Bind).

What I'm very confused is that since jira uses the login delegation, why jira needs to sync the hashed userPassword from ldap ?

Thanks

[Andy Heinzer]

Hi Feng,

It's true that most deployments will use Jira in a login delegation setup like you have suggested when connecting to an LDAP directory.  Jira does not store passwords for these LDAP accounts.

However it is possible when you configure this user directory in Jira to use one of three different options

1. Read Only
2. Read only with local groups
3. Read/Write

Option #3 is where that user password attributes could be something Jira might need to know.  In that setup, the Jira application itself could be used to change values in LDAP, such as changing usernames OR even changing that account's password. 

For the other read only modes, the user schema settings mark 'User Password Attribute:' as a required attribute, however to the best of my knowledge that individual account data isn't being stored anywhere within Jira in read only configurations.

You can confirm this by looking more deeply into the SQL database after a sync

select * from cwd_user

will show you all the user accounts in Jira.  There is a credential column there for all account, and for Jira internal accounts, there is a password hash there.  However for LDAP accounts, that field tends to be empty or have a value of 'nopass'.  This is because Jira isn't storing that data for LDAP users, because it does not need to.  The LDAP server is responsible for handling the authentication aspects here.

I hope this helps.  Please let me know if I can clarify.

Andy

[Feng Xi]

Thanks for your reply, Andrew. But I'm still not convinced.

As you mentioned,

1. for option #1 and option #2, cwd_user will not store userPassword(hash or plain text) which is nice. But on jira admin console, why "User Password Attribute" is mandatory field ? is it a bug ?

2. for option #3, regarding the write, you mentioned changing the account's password. to the best of my knowledge, jira can delegate the chaning password request to LDAP server as well, thus JIRA does not needs to sync user's password. Besides, most of the write operation only NEEDS the write permission of ldap admin account. I still don't understand why jira needs user's password  even for write operation.

From my point of view, Jira as a service provider, ldap as an Identity Provider, for any reason(read or write), jira should not care about user's password.

[Andy Heinzer]

I think this field is mandatory, even in readonly configs because Jira has setup the type to be a quick selection between read only and read/write.  None of the directory options are configured to change when switching this read only or read/write modes.   In this sense if the options where different you would be prevented from enabling read/write until you correctly entered that additional field.

You can configure Jira to disable the resetting of passwords and delegate that to LDAP as you mentioned. See External user management in Configuring Jira Application options for more details. But when you add an LDAP directory to Jira, it does not presume that you want to do that.  This is a global setting in Jira that a system admin has to enable to take affect.

In Read/Write setups, Jira needs to know where that user password field is in the LDAP directory structure, otherwise it can't change that user's password in LDAP.  I suppose you could try to define that password field in Jira as being some other dummy field in LDAP if you are security paranoid about it.  Just understand that Jira won't be able to correctly change these users passwords, even if you have given it the read/write privledges it would need to do so.  In my understanding users can still login and have their other account details synced even if this field is defined inaccurately here.