Installation and deployment
Version 7.x > Installation and deployment > Active Directory Forms Authentication View modes: 
User avatar
Member
Member
christian.nickel-nist - 10/17/2013 4:14:40 PM
   
Active Directory Forms Authentication
Hello,

I've been struggling with this issue for a few days and all my googling (and forum searching) hasn't turned up anything that can fix my problem.

We want to setup Forms authentication (NOT windows auth) that will authenticate users against Active Directory, we've been able to successfully use the AD Import tool to create the users in Kentico but we've been unsuccessful in trying to authenticate those users.

Kentico is running in IIS 7 in its own app domain, Integrated mode, .net 4.0, and using the local NETWORK SERVICE account. We've added a proper connection string for AD like so:

<add name="ADConn" connectionString="LDAP://sub.domain.ext/CN=Users,DC=sub,DC=domain,DC=ext" />

I've confirmed through multiple tools that this is the correct usage of the connection string.

We've also setup the membership provider as such:

<add name="ADProvider"
type="System.Web.Security.ActiveDirectoryMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
applicationName="/"
connectionStringName="ADConn"
connectionUsername="sub.domain.ext\connectionUser"
connectionPassword="connUserPassword"
connectionProtection="Secure"
enableSearchMethods="true"
/>


And we've set the defaultProvider to this new "ADLDSProvider" as well, and commented out the default CMSProvider.

Essentially Kentico is unable to authenticate any of the Active Directory users even after they've been given every role. The message given back to the user is "Your login attempt was not successful. Please try again.".

Now, if the AD membership provider or the connection strings are intentionally mis-configured, we will get a nasty "Server Error" page letting us know one of the following messages:
The server is not operational <-- bad server name
Logon failure: unknown user name or bad password <-- incorrect directory path
Logon failure: unknown user name or bad password. <-- incorrect connection un/pw

So we've experienced all of those, what we're having issues with is that when the web.config is configured properly, none of the Active Directory users can log into CMSDesk or CMSSiteManager when everything is telling me that they should be able to. Once configured properly, I get the following message upon every login attempt: "Your login attempt was not successful. Please try again."

At first and after a few different tries you would assume that the user was locked, didn't have enough permissions, or the username was somehow changed during the import process. The last part of that is true but the first few weren't. We've tried the following combinations:

sub.domain.ext\user
user@sub.domain.ext
user
sub.domain.ext-user
SUB\user
SUB-user

Each of those combinations works when logging into any other box in this domain, the ADProvider membership provider is the only membership provider. We seem to think that the SUB-user is the correct combinations as that is how they look in the list of users.

Nothing seems to allow the AD users to log in and I don't see anything in the logs that would tell me otherwise.

So I'm asking for help, are there any tools I could use to figure out what is going on? Am I missing something with this configuration? Anything else I should try?

Thank you all for your help, this has given quite a headache, lol.

User avatar
Kentico Legend
Kentico Legend
Accepted solutionAccepted solution
Brenden Kehren - 10/18/2013 7:57:04 AM
   
RE:Active Directory Forms Authentication
Have you looked at mixed mode authentication configuration docs? One main key point is the first IMPORTANT box at the top of the mentioned page. Another thing is to ensure you are using the same connection string name as what is shown in the documentation. (CMSADConnectionString vs. ADConn). I've found some items are simply hard coded and this could be one of them.

User avatar
Member
Member
christian.nickel-nist - 10/21/2013 1:55:29 PM
   
RE:Active Directory Forms Authentication
Thanks for your suggestion, right after I posted the question the Net Admins decided to rebuild our SQL server for the environment where I was testing. I'll post an update as soon as I can get everything working again.

User avatar
Member
Member
christian.nickel-nist - 10/25/2013 2:42:50 PM
   
RE:Active Directory Forms Authentication
So, good news, something clicked into place after making the stated changes!

What I noticed from the article that I didn't have before was the following:
1. The membership provider was using the type: "CMS.MembershipProvider.CMSADMembershipProvider"
2. I was completely missing the CMSADroleProvider, I've added it:
        <add name="CMSADRoleProvider" 
type="CMS.MembershipProvider.CMSADRoleProvider"
connectionStringName="CMSADConnectionString"
connectionUsername="DOMAIN\user"
connectionPassword="password"
writeExceptionsToEventLog="true" />

Something I noticed though, is that these new users must login with just their username instead of DOMAIN\username.

I have another problem though, while these users are now authenticated, they cannot access CMSDesk or CMSSiteManager, they keep getting 403 - Forbidden errors. I assume that I'll need to mess with some <location> tags to get them working properly. I'll see if I can fix that, but any insight would be helpful!

Thanks,
Christian

User avatar
Kentico Legend
Kentico Legend
Brenden Kehren - 10/25/2013 3:12:38 PM
   
RE:Active Directory Forms Authentication
Most likely some permissions that need to be set within Kentico or in the web.config in the /CMSDesk and /CMSSiteManager directories.

User avatar
Member
Member
christian.nickel-nist - 10/25/2013 3:24:43 PM
   
RE:Active Directory Forms Authentication
Yes, I've been researching the issue and was able to get the user to log in completely just by altering their groups.

Though the behavior isn't what I expected...

What I expected:
1. Use Kentico AD Import tool to bring over users from domain.
2. Domain users were created in Kentico with DOMAIN-username format.
3. Use admin account to configure recently imported users to give proper permisions and roles.
4. Setup web.config with membership and role provider.
5. Log in with DOMAIN-username or DOMAIN\username.

What actually happens:
1. Use Kentico AD Import tool to bring over users from domain.
2. Domain users were created in Kentico with DOMAIN-username format.
3. Use admin account to configure recently imported users to give proper permisions and roles.
4. Setup web.config with membership and role provider.
5. Attempt login with DOMAIN\username or DOMAIN-username <--FAIL
6. Login with username (without domain) <-- WORKS, sort-of
7. Kentico CREATES a new user in the list of users that matches that username, it does not use any of the imported DOMAIN\username entries... this is not what I expected.

Essentially I have to give permissions and Kentico roles to each user of the domain only after they login. I guess I could alter the imported AD roles to act as Kentico roles, but this isn't what I wanted to originally do.

Do you have any idea how can I get the DOMAIN\username style logins to work? It seems pointless to import them if I cant authenticate with those accounts.

User avatar
Member
Member
Cody.Williams-fsna-inc - 11/6/2013 3:34:33 PM
   
RE:Active Directory Forms Authentication
I'm currently struggling to figure out the "6. Login with username (without domain) <-- WORKS, sort-of
7. Kentico CREATES a new user in the list of users that matches that username, it does not use any of the imported DOMAIN\username entries... this is not what I expected." part on my site. It'd be nice if it would authenticate with the imported account.

Have you made any progress in figuring it out?

User avatar
Member
Member
christian.nickel-nist - 11/7/2013 4:25:01 PM
   
RE:Active Directory Forms Authentication
Hi Cody,

Nope, I've been unable to get that portion working.

My current process:
1. Have user access the site with their AD account and watch it yell at them for not having access. (just username, not DOMAIN\username)
2. Log in as admin and give them proper rights to log in.
3. Have the user log in again and everything seems to work.

I may revisit this in a month or so, but for now I have accepted this solution simply because it works.

-Christian

User avatar
Member
Member
Cody.Williams-fsna-inc - 11/7/2013 4:30:28 PM
   
RE:Active Directory Forms Authentication
I ended up running the AD Import tool again, but I changed it from Domain\SamAccountName to just SamAccountName. It stopped the duplicate user being created and it sets them as a domain user to be updated by AD. I have tested that it will pick up password changes from AD.

User avatar
Member
Member
Cody.Williams-fsna-inc - 11/7/2013 4:32:40 PM
   
RE:Active Directory Forms Authentication
Cody.Williams-fsna-inc wrote: I ended up running the AD Import tool again, but I changed it from Domain\SamAccountName to just SamAccountName. It stopped the duplicate user being created and it sets them as a domain user to be updated by AD. I have tested that it will pick up password changes from AD.

I haven't tested to see if the site will automatically pick up a newly created user from AD yet though. I'm hoping that it will so I don't have to run the AD Import utility or manually create a new account every time I create a new user in ADUC.