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:

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
Accepted answer

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:

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
Community showcase
Posted yesterday in Agile

What is Scrum? A good, bad, and ugly answer.

In a world of dark-scrum, faux-scrum, and scrum-butt, the question still remains: What is scrum and how do you do it “right?” That’s the question we set out to answer. I'm Max, I've been teaching c...

78 views 0 4
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you