Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,368,955
Community Members
 
Community Events
168
Community Groups

Delegated Authentication directory mungles FullName and Email attributes on re-sync

One of our customers who uses NTLM Authenticator for Jira has encountered a strange problem with one of the newer releases.

Jira version: 5.2.4

The newer release triggers refresh of the user on successful login to make auto-join to default groups feature work. The approach is described here:

https://jira.atlassian.com/browse/CONF-24279

https://answers.atlassian.com/questions/24227/invoke-embedded-crowd-login

Everything seems to work well for other customers, including the other customet who requested this particular enhancement.

For this particular customer however, on successful login when the user information in the delegated authentication directory gets refreshed from Active Directory the following happens: full name is set to the LDAP username, email is set to empty value.

I've requested and got a confirmation that mappings for Full Name and Username are correct in delegated directory setup i.e. Jira."User Display Name Attribute"=AD.displayName and Jira."User Name Attribute"=AD.sAMAccountName and Jira."User Email Attribute"=AD.mail.

Our plugin doesn't have any information about the user's full name or email and doesn't submit these to Jira and as such I see no way that we can be overwriting these.

I do not have direct access to the customer's environment. Can someone point me to what I can request/what logging categories to enable to debug this issue?

1 answer

1 accepted

3 votes
Answer accepted

Hi Ed,

If you can request an LDIF for a user, you'll get the fqdn to the user, but this won't give you the user attributes. If you can request a screenshot of the details behind a user, or even be granted access to connect or can work with an LDAP admin to map out the variables, you'll be better off. LDIF export is explained here:

https://confluence.atlassian.com/display/CROWD/Getting+an+LDIF+Export+of+a+User+or+Group

In the right had pane of Apache Directory Studio (ADS) you'll see they've clicked on a user and the attributes are all in a collapsed tree view. As you can see they're not expanded, but usually the main ones are displayed in the center content pane.

That's how I'd get through this, hope this helps!

I have requested this, but I am assured that in LDAP the user looks perfectly fine.

My current suspicion is on case sensitivity - the result that the customer claims to be seeing looks exactly like the case when you go and delete the user from the backend external Crowd - after this all you see in Confluence for example is the login, which is displayed where the Full Name used to be.

I am trying to investigate if despite the fact that we (our authenticator) has successfully logged the user in, and found it in Jira (we are attempting first by all lower case, then the way NTLM has it), the search/update to the embedded crowd delegated dir is done with a case that prevents the crowd from finding a user.

As such any hints what logging in Jira to enable to zero on the issue - would be appreciated

Suggest an answer

Log in or Sign up to answer
TAGS

Atlassian Community Events