Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

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

TechTime Initiative Group April 25, 2013

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
Ryan Goodwin
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
April 25, 2013

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!

TechTime Initiative Group May 1, 2013

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
AUG Leaders

Atlassian Community Events