Has anyone gotten Active Directory / LDAP Authentication working with Katello (specifically 3.5 but I’m pretty sure any version)?
I’m trying to figure out what’s going wrong at this point and am not sure where to go next for diagnosis.
I started by Administer->LDAP Authentication, and setup an LDAP authentication Source.
I next went to Administer->User Groups and setup a user group. In the “External Groups” section I “Added external user group”, selected my LDAP authentication source, and typed in my group name. The “submit” came back successful and shows me my group name and auth source, so I assume my LDAP connection is correct and is correctly connecting to my AD information.
I’ve tried both with and without the “Onthefly register” option checked. With it checked at this point I simply log out and try to log in. “Invalid Username/Password”. (I’ve tried both “DOMAIN\user” and just “user”).
Since that didn’t work, I unset Onthefly register, went to Administer->Users and created a user with my AD Username, filled in it’s information and selected “Authorized By” and my LDAP User source.
Again, when I logged out and logged back in I attempted to authenticate as the user and am getting “Invalid Username/Password” returned to me.
I’ve tried this both with and without an LDAP filter set to a group I’m a member of (same group as used in the “External Group” above).
Anyone have this working? Where might I go to get more info on why this is failing and/or what isn’t properly set. I’ve checked /var/log/foreman/production.log and can see the login attempts but it looks like it’s just redirecting back to the login page, no errors given. I also looked at the httpd/foreman-ssl_access_ssl.log but again this just looks like the attempt to access the page, no errors given.
This has to be something REALLY basic, since I THINK my LDAP source works (since groups can see the external group).
Name: generic name
Server: domain.company.location
LDAPS: unchecked
Port: 389
Server Type: Active Directory
ACCOUNT
Account username: AD service account with appropriate permissions
Account password: self explainable
Base DN: DC=domain,DC=company,DC=location
Groups base DN: OU=Security OU,OU=domain groups,DC=domain,DC=company,DC=location
LDAP filter: (memberOf=CN=Administrators Group,OU=Security OU,OU=domain groups,DC=domain,DC=company,DC=location)
Auto create accounts in foreman: checked
Usergroup sync: checked
ATTRIBUTE MAPPINGS
Login name attribute: userPrincipalName
First name attribute: givenName
Surname attribute: sn
Email address attribute: mail
It took me a fair amount of searching to figure out the group filter, and it was only including the whole path that it worked for us. Once the AD user logs in for the first time they are created in Katello and can then be assigned admin privileges (or whatever ones required).
I too got it working with Katello 3.5 and there are some instructions for setting it up here. For troubleshooting, I find it easiest to switch to unsecured LDAP and run tcpdump on the LDAP server. Then I can rightclick and follow stream in Wireshark and that gives me the ability to see what step I am failing on and how I might be asking for the wrong thing or misreading the data on the client side.
Given some of the information above and some LDAP Foo from my AD Guys we managed to get this setup. Our AD Archichitecture ALWAYS causes issues for getting products AD Integrated (we separate users and groups into multiple top level OU’s meaning the only place you have to get ahold of all users/groups is to point the base DN at our base domain). We also apparently have weird information in the userPrincipalName which was causing issues as well.
Just to be more explicit, with my AD Infrastructure this is what worked for us:
IMPORTANT (Lessons Learned):
BaseDN needs to be somewhere where the users that will log in to the system can be obtained from. In my org we break groups into top level OUs. OU=Users,OU=Location1,DC=domain,DC=com; OU=Users,OU=Location2,DC=domain,DC=com; OU=Users,OU=Location3,DC=domain,DC=com; etc. Thus my Base DN needed to be DC=domain,DC=com because that’s the only location in the tree that can find all the users.
Groups base DN needs to be a location in the tree that has access to any groups you’re going to setup through Katello. In my org, we separated the Unix AD Stuff into it’s own top level OU. So OU=Unix,DC=domain,DC=com is the top level OU for all Unix based stuff in AD, and I have a “groups” OU under that for all groups pertaining to Unix stuff. Again, I have one group I use out of one Lower level OU and one group out of another lower level OU, so my Groups base DN points at a higher OU so it can see both lower level OUs.
The LDAP Filter is absolutely optional. If there’s a single group to allow access to Katello, it’s easier to just use the Groups base DN pointed all the way down to the group: CN=Katello_Access,OU=Groups,DC=domain,DC=com; however, if you have multiple groups to allow access you’ll need to set Groups base DN to an OU that includes all the groups and then use the LDAP Filter (below) to specify each group to validate against.
If you have multiple groups for access you can use a filter something like the following: (|(memberOf=CN=katello_dev_login,OU=Patch Management,OU=Unix Groups,OU=UNIX,DC=domain,DC=com)(memberOf=CN=Enterprise Unix Admins,OU=Unix Groups,OU=UNIX,DC=domain,DC=com))
My Final Config:
Host: < ldap server name >
LDAPS: Unchecked
Port: 389
Server Type: Active Directory
Account: < Account with Access to AD >
Password: < password to above >
Base DN: DC=domain,DC=com
Groups base DN: OU=Groups,OU=UNIX,DC=domain,DC=com
LDAP Filter: (|(memberOf=CN=katello_dev_login,OU=Groups,OU=UNIX,DC=domain,DC=com)(memberOf=CN=Enterprise Unix Admins,OU=Admin Groups,OU=UNIX,DC=domain,DC=com))
Onthefly register: Checked
Usergroup sync: Checked
Attr Login: userPrincipalName
Attr Firstname: givenName
Attr lastname: sn
Attr mail: mail
Photo attribute: < blank >
NOTE: MAKE SURE YOU CHECK WHAT IS IN userPrincipalName!!! In our case, because we were setup for Office 365, our UPN is an e-mail address "user@domain.com" not just “user”…this is what broke the previous attempts at setting this up on my end…Several times I had the authentication setup correctly, but was attempting to log in as a different account (our AD Login is “user” the UPN however is "user@domain.com".
Thank you to everyone who responded to this, it helped a GREAT deal.
