map users

[David Poprik]

I am trying to convert my Confluence install from a local directory to an active directory Auth Only install.  I was under the impression I could choose to "Auth Only" without synchronization but that seems to be my only choices as of the latest 5.9.4 windows server install.  It imports all 200,000 + users in to the cache.  I am now trying to map the old users in the internal directory to those imported but do not see how?  

I would appreciate some guidance/tips.

Thanks!

[David Poprik]

Steven,  I found a doc on delegated "Connecting to an Internal Directory with LDAP Authentication" which is what I actually want.  Auth Only.

However I do not seem to be able to log in with a domain account when I try it now when I was using the full microsoft AD directory settings.

I understand the names need to match.

[Steven F Behnke]

When you say "auth only" you're referring to the delegated authentication connector. If you chose the Active Directory connector instead you are not using this delegated authentication connector.

You would typically filter the users out with LDAP filters instead of allowing it to sync 200,000+ users.

You cannot map users. They need to be the same username.

[David Poprik]

Steven,  I found a doc on delegated "Connecting to an Internal Directory with LDAP Authentication" which is what I actually want.  Auth Only.

I set the old internal Dir user to the same username as the LDAP account but no good.  If I chose "Copy users on login" in the user directory I added then a new account is created with that ldap accounts username and the directory sections says it is the delegated ldap directory I am pointing to.  The original account says it is using the internal.  I guess that is the problem.  I need to change the old users to the ldap directory rather than the internal?

I understand the names need to match.

[Steven F Behnke]

I'm trying to follow but this is hard to visualize.

If you use Delegated Authentication Connector and use the Copy Users on Login option, users will be automatically created in the directory.

The Delegated Authentication Connector Directory should be FIRST in the list so that users attempt to authenticate against it instead of the Internal Directory.

[David Poprik]

Steven,  Thanks for responding again.  I have in fact placed the internal with LDAP user directory both first and second but it makes no difference.  What I want to do is have it authenticate an LDAP credential and match the user up with one of my "original" internal directory accounts by the same username as the LDAP user.  

I set a username to match an LDAP account and signed in both with the LDAP authenticator and then internal as the order and vice versa but I just get a failed login.  (not a bad credentials message)

After a while with this I checked the create account option under the user directory for LDAP and signed on and it created the account in the internal DB for the LDAP user.  I looked at it and the significant difference was that looking at the account entry in users the Directory section showed the LDAP directory rather than "Internal" like my original users.

Following up on this I opened the SQL DB and looked at the cwd_users table.  All my original accounts had the same directory ID number.  My new account created automatically via the "Copy" command when I signed in the first time to LDAP had a new number.  I copied this number out, then in the confluence user manager I deleted the new user.  I modified one of my original users to have the the same username as the LDAP account again and then editted the DB manually and changed the directory entry to match what I had copied out earlier from the auto added account.  I had to restart the Atlassian service to get everything working right but now if I sign in with the LDAP credential I am the user account I want to be in the internal directory.  There seems to be an issue with the LDAP AUTH method even though I am following directions.

[Steven F Behnke]

Are you tailing the logs? If you put the Auth connector first and it's not working, perhaps Crowd is skipping the directory due to some error?

[David Poprik]

This was in the Atlassian log:

2016-02-27 22:28:13,991 WARN [http-nio-8090-exec-3] [atlassian.seraph.auth.DefaultAuthenticator] login login : 'fxxxxx' tried to login but they do not have USE permission or weren't found. Deleting remember me cookie.

I definitely have a user with that user ID in the internal DB.

[David Poprik]

oh and the user is not fxxxx I just obscured it.

[Steven F Behnke]

Hopefully we can figure this out quickly for you. You may also consider opening a ticket at Atlassian Support.

If you're seeing that error, it's the route we need to investigate. Have you allowed the user into the application by allowing their Group in the Application Connector in Crowd (or do you Allow All)?

Does the user have USE permission in the end application – Confluence?

They're being denied at an authorization level. The error reads that they are disallowed almost explicitly, there is no group authorizing them to log in.

[David Poprik]

Steven, 

I have opened a support case and have so far been pointed the documentation I have read.  I sent them zipped logs etc and the error info.

The user that I want to authenticate as exists in the internal directory and works fine when I use the internal directory credentials.  "Auth Only" is supposed to let me auth to LDAP and then map to an internal directory user of the same name as I understand it which is what I need but doesn't appear to be happening.