AD authentication is failing in Jira 4.4.3

[Mark Everest]

Hey,

I am just upgrading from 4.2.4 to 4.4.3.

I have setup a new User Directory of type "Internal with LDAP Authentication" and used the same details as in 4.2.4. Clicking the 'test' button succeeds.

When I try to login I am told that my password is incorrect.

The jira-security log says:

2011-10-31 15:09:25,612 http-8080-12 anonymous 909x2916x1 1po38b4 10.2.222.16 /login.jsp login : 'markev' tried to login but they do not have USE permission or weren't found. Deleting remember me cookie.

2011-10-31 15:09:25,612 http-8080-12 anonymous 909x2916x1 1po38b4 10.2.222.16 /login.jsp The user 'markev' has FAILED authentication. Failure count equals 2

Any ideas please? This is a blocker for me!

[Mark Everest · Accepted solution]

Hello all,

For now I have opted for the option of having to manually update the AD connector in the database should I need to.

Thanks for all the suggestions.

[FagnerF]

Hi Mark,

I'm not sure about, but do you still having this issue?

If yes I'd like to suggest to you check out the file AtlassianDirectory\install\atlassian-jira\WEB-INF\ classes\osuser.xml. it should have something like that to be able authentication trough LDAP:

<provider class="com.opensymphony.user.provider.ldap.LDAPCredentialsProvider">
<property name="java.naming.factory.initial">com.sun.jndi.ldap.LdapCtxFactory</property>

<--Type your LDAP server IP address:Port for authentication -->

<property name="java.naming.provider.url">ldap://192.168.1.2:389</property>

<--Type your LDAP Domain (like this example test.local) -->

<property name="searchBase">dc=test,dc=local</property>

<--Type your User Name Attribute. It's related with what kind of data base you are using:

- if AD it gonna be sAMAccountName

- if LDAP (POSIX) it's gonna be uid -->

<property name="uidSearchName">sAMAccountName</property>

<--Here we have the main point in My opinion, because you'll type what user you'll use to consult your database (if him doesn't have any permission to, you'll have a problem) where:

cn=jira_consulter (user who I'll use, if you prefer you can create an exclusive user just to do this operation with needed permisssions)

ou=jira_users (it's the group that user jira_consulter belongs)

ou=jira (the main group)

dc=test (domain)

dc=local (domain)

looking forward our hierarchy should be something like that:

Local
Test
jira
jira_users
jira_consulter -->

<property name="java.naming.security.principal">cn=jira_consulter,ou=jira_users,ou=jira,dc=test,dc=local </property>

<-- Type the password-->

<property name="java.naming.security.credentials">password</property>

<property name="exclusive-access">true</property>
</provider>

Cheers

[Kevin Joanisse]

Hi,

We are upgrading to 4.3.2. We didn't have LDAP on our previous version...

We even tried a fresh instance without any users and a clean database and still no go...

it's frustrating as we are running confluence on LDAP without a hitch... We have basically tried everything to our knowledge to get JIRA authenticating to LDAP...

[FagnerF]

Hi Kevin,

I think those pages can be useful in your case:

A overview how to migrate Jira Data Base
https://confluence.atlassian.com/display/JIRA043/JIRA+4.3.2+Upgrade+Guide.

User Management
http://www.atlassian.com/software/jira/docs/latest/usermanagement.html

Group Management
http://www.atlassian.com/software/jira/docs/latest/group_management.html

Role Management
http://www.atlassian.com/software/jira/docs/latest/project_role_management.html

Migrating Users to Roles
http://confluence.atlassian.com/display/JIRA/Migrating+User+Groups+to+Project+Roles

LDAP Integration
http://confluence.atlassian.com/display/JIRA/Integrating+JIRA+with+LDAP

Another tip is about that when we are using LDAP as delegated mode in Server Settings you'll see a check box calls Copy User on Log in which means each user who wants to log in Jira will be import in JIRA. It can be seen there too with this message: "Users are copied from your LDAP server into JIRA when they authenticate. Copied users can subsequently be modified in JIRA, but modifications will not be reflected on the LDAP server." This feature means when JIRA doesn't have an user its going to LDAP to find them for bringing them for JIRA database, but the password authentication is kept with database although not internal authentication.

I hope I can give you a hand with those tips as well.

Cheers

[FagnerF]

Hi Kevin,

I think those pages can be useful in your case:

A overview how to migrate Jira Data Base
https://confluence.atlassian.com/display/JIRA043/JIRA+4.3.2+Upgrade+Guide.

User Management
http://www.atlassian.com/software/jira/docs/latest/usermanagement.html

Group Management
http://www.atlassian.com/software/jira/docs/latest/group_management.html

Role Management
http://www.atlassian.com/software/jira/docs/latest/project_role_management.html

Migrating Users to Roles
http://confluence.atlassian.com/display/JIRA/Migrating+User+Groups+to+Project+Roles

LDAP Integration
http://confluence.atlassian.com/display/JIRA/Integrating+JIRA+with+LDAP

Another tip is about that when we are using LDAP as delegated mode in Server Settings you'll see a check box calls Copy User on Log in which means each user who wants to log in Jira will be import in JIRA. It can be seen there too with this message: "Users are copied from your LDAP server into JIRA when they authenticate. Copied users can subsequently be modified in JIRA, but modifications will not be reflected on the LDAP server." This feature means when JIRA doesn't have an user its going to LDAP to find them for bringing them for JIRA database, but the password authentication is kept with database although not internal authentication.

I hope I can give you a hand with those tips as well.

Cheers

[FagnerF]

Hi Kevin,

I think those pages can be useful in your case:

A overview how to migrate Jira Data Base
https://confluence.atlassian.com/display/JIRA043/JIRA+4.3.2+Upgrade+Guide.

User Management
http://www.atlassian.com/software/jira/docs/latest/usermanagement.html

Group Management
http://www.atlassian.com/software/jira/docs/latest/group_management.html

Role Management
http://www.atlassian.com/software/jira/docs/latest/project_role_management.html

Migrating Users to Roles
http://confluence.atlassian.com/display/JIRA/Migrating+User+Groups+to+Project+Roles

LDAP Integration
http://confluence.atlassian.com/display/JIRA/Integrating+JIRA+with+LDAP

Another tip is about that when we are using LDAP as delegated mode in Server Settings you'll see a check box calls Copy User on Log in which means each user who wants to log in Jira will be import in JIRA. It can be seen there too with this message: "Users are copied from your LDAP server into JIRA when they authenticate. Copied users can subsequently be modified in JIRA, but modifications will not be reflected on the LDAP server." This feature means when JIRA doesn't have an user its going to LDAP to find them for bringing them for JIRA database, but the password authentication is kept with database although not internal authentication.

I hope I can give you a hand with those tips as well.

Cheers

[Kevin Joanisse]

I have a similar problem...

We have a confluence instance running delegated authentication as primary and internal as secondary. It works 100%

We are running a test instance of JIRA which we have configured with local directory only as it was suppose to be a pilot.. anyways, word got out and we currently have over 1500 users.. The problem is, when we try to add the delegated authentication, we use the exact configurations as confluence, the test comes back as PASSED. When we try to login, it says that the password entered is wrong. The delegated directory is primary and internal as secondary.. I have no problems signing in locally.. the LDAP id's and JIRA id's are exactly the same

Any help would be extremely appreciated as frustration is getting the best of me.

cheers

[FagnerF]

Hi kevin,

I'm wondering what JIRA's version do you have?

Cheers

[Manse Wolken]

- From a fresh install with osuser.xml file there (and the system created LDAP connector) import. All the existing accounts are assigned to this connector, but I still have the problem where I cannot change the connector details - our AD is changing this year so I will need to be able to update this.

If you can log in as Administrator, after you have imported your data, but with an LDAP Account, then check for the local Admin Account. You should be able to create a new local admin user, after the import. Please do so, give it a wierd name like "localjiraadminaccount" and put it an jira-users und jira-administrators group (both local, I hope).

Make sure that the local groups have login , respective admin rights.

Log of from Jira.

Log on with that new account.

If that is successful, you can change the LDAP connector details.

[Mark Everest]

I have tried this - the exception still occurs when clicking the 'test' button in the connector details.

How can I switch users from one directory to another?

If I was able to do this, it would remove the problem I am having.

[Manse Wolken]

Hm, I think right now, that would be "manually".

You'd have to look in the database, watch for the tables that have a cwd_ prefix.

cwd_group and cwd_user both have a directory_id field. It seems that it relates to the directory which is defined in cwd_directory and whose attributes are stored in cwd_directory_atribute.

I havent't tried fumbling with directory settings directly in the database, so be warned.But it seems to me, that this is one of the last options, that you can try.

[Mark Everest]

Ugh - not really a good option and one that I wouldn't want to attempt.

The problem I have is that this issue is blocking me from upgrading Jira.

Has anyone else reported the issue of not being able to edit directory connectors?

[JamieA]

What we've advised should work... ie have one user created before or after that is in the internal directory and not in ldap. If you get an error clicking test it sounds like there is corruption. Do you have current support? Now is the time to call them imho.

[Manse Wolken]

Regarding:

Yes, I signed in to Jira and created the admin account (in the startup screens) BEFORE I did the import of data.

I presume, you have two instances of Jira, one is prodction one is test/upgrade.

You did create that local admin on production, made sure it has a username that is definitely not in LDAP and exportet the data of your production jira then.

Afterwards you cleared your database from the test Jira and importet the exportet data right?

[Mark Everest]

Yes, all your points above are correct.

After the import the 'admin' user's directory is set to "JIRA Internal Directory"

[JamieA]

When you upgrade, make sure that there is a copy of your previous osuser.xml file in web-inf/classes.

There are two upgrade tasks that make use of this, the first creates a new "delegated" directory which I think you did manually, and the second one migrates any users that match the new delegated directory to it.

What I suspect might be happening is that a new user for markev is being created, which is not in the jira-users group. If you are just doing a test upgrade, then restart it with the old osuser.xml in place.

If you have upgraded production already, then I'd recommend contacting support, as I believe they have a procedure to run the moral equivalent of the two upgrade tasks that were missed because osuser.xml wasn't present.

If you have any user that you can login with, eg some admin user in the internal directory, you can see what directory markev is in... it should be the delegated directory, but it sounds like it's in the internal directory.

[Mark Everest]

No I've not done this in production yet.

OK - so this is now what I have tried:

1 - deleted all tables from the database (so Jira is back to a new installation).

2 - copied the osuser.xml from my prod instance to the test installation folder

3 - started jira and connected - used the setup wizard to create an admin user etc - I now see in the user directories an entry called "JIRA Delegated Authentication Directory"

If I edit this and click "test" I get:

Oops - an error has occurred

System Error

A system error has occurred.

Please try submitting this problem via the Support Request Page
Otherwise, please create a support issue on our support system at http://support.atlassian.com with the following information:

1. a description of your problem
2. cut & paste the error and system information found below
3. attach the application server log file ( D:\Program Files (x86)\Atlassian\Application Data\JIRA\log\atlassian-jira.log )

Cause:

Request processing failed; nested exception is java.lang.NullPointerException

Referer URL: http://jira-devt:8080/plugins/servlet/embedded-crowd/configure/delegatingldap/?xsrfTokenName=atl_token&xsrfTokenValue=506c39ac24e4ea5d2c5949124359eec43448f399&directoryId=3

Build Information:
Uptime : N/A
Version : 4.4.3
Build Number : 663
Build Date : Mon Oct 17 00:00:00 BST 2011
Build Revision : 165197
Atlassian Partner : null
Installation Type : Standalone
Server ID : B6JJ-NLLO-3WRC-BPXJ
Last Upgrade : 31/Oct/11 5:33 PM

...

[JamieA]

This is after you did the import of the old database?

Also I think you cut the stack trace, makes it difficult to tell what the problem is.

[JamieA]

Other thing is make sure you have an admin user that is in the local directory and is not in ldap *before* upgrading, because you cannot edit the directory that the current logged-in user is a member of.

[Mark Everest]

No - this is before I've imported the old database.

I had to cut the stack trace as this web page only allows 2000 characters per post. If it is any consolation, the stack trace didn't throw much light on to it!

Here is the part that includes the exception details (again trimmed due to 2000 character limit):

Request Attributes

- javax.servlet.forward.request_uri : /plugins/servlet/embedded-crowd/configure/delegatingldap/

- javax.servlet.error.message : Request processing failed; nested exception is java.lang.NullPointerException

- jira.session.last.accessed.time : 1320082457576

- webwork.result : Value stack =========== ===========

- jira.request.username : admin

- jira.websudo.request : true

- javax.servlet.error.request_uri : /plugins/servlet/embedded-crowd/configure/delegatingldap/

- com.atlassian.jira.security.xsrf.XsrfTokenAdditionRequestFilter_already_filtered : true

- com.atlassian.seraph.auth.LoginReason : OK

- jira.webwork.cleanup : false

- jira.request.id : 1054x44x1

- org.springframework.web.servlet.DispatcherServlet.CONTEXT : ECWebApplicationContext: display name [Root WebApplicationContext]; startup date [Mon Oct 31 17:34:10 GMT 2011]; parent: org.springframework.osgi.atlassian.NonValidatingOsgiBundleXmlApplicationContext@14d8b8d

- javax.servlet.error.status_code : 500

- org.springframework.web.servlet.HandlerMapping.pathWithinHandlerMapping :

- jira.request.start.millis : 1320082460076

- com.atlassian.johnson.filters.Johnson503Filter_already_filtered : true

- com.atlassian.jira.web.filters.accesslog.AccessLogRequestInfoexit.called : true

- com.opensymphony.sitemesh.APPLIED_ONCE : true

- com.atlassian.core.filters.HeaderSanitisingFilter_already_filtered : true

- jira.request.assession.id : 1qt1zc0

- org.springframework.web.servlet.DispatcherServlet.LOCALE_RESOLVER : org.springframework.web.servlet.i18n.AcceptHeaderLocaleResolver@1d0f86e

[Mark Everest]

Regarding:

Other thing is make sure you have an admin user that is in the local directory and is not in ldap *before* upgrading, because you cannot edit the directory that the current logged-in user is a member of.

Yes, I signed in to Jira and created the admin account (in the startup screens) BEFORE I did the import of data.

[Mark Everest]

This morning I have tried:

- From a fresh install, manually create the LDAP connector and then import. The import removes the connector and all the users are assigned to "JIRA Internal Directory"

- From a fresh install with osuser.xml file there (and the system created LDAP connector) import. All the existing accounts are assigned to this connector, but I still have the problem where I cannot change the connector details - our AD is changing this year so I will need to be able to update this.

So a bit of progress, but still the issue editing the directory connector remains.

Can you send me the details of what I'd ned to do to re-assign users accounts to directories?

[JamieA]

Regarding editing the LDAP directory, did you see my comment above:

Other thing is make sure you have an admin user that is in the local directory and is not in ldap *before* upgrading, because you cannot edit the directory that the current logged-in user is a member of.

[JamieA]

And can you log in as that user? And that user is definitely not matched by a user in LDAP?