If you're using PAM for your authentication stack, you can use pam_krb5 to provide kerberos authentication for your services. Kerberos was designed out-of-the-box to deal with hostile environments, handles authentication-by-proxy, and is already a part of the AD spec. Why struggle with LDAP when you can get Kerberos to do the heavy lifting for you, and get on with life? Yeah, you'll have to do some reading, and yeah, it'll take a bit of time, but I've used Kerb-to-AD authentication for years and have found it to be the easiest, quickest way to get SSO working out of the box when you have Active Directory as the authentication backend.
The main thing you'll run into is that Microsoft decided to be very specific about the default encryption types (they basically made their own), so you'll need to set up your Kerberos clients to have the correct matching encryption types, or the AD servers will continue to reject it. This is thankfully an easy procedure and shouldn't require more than a few edits to krb5.conf.
And now, some links for you to consider...
Microsoft's View of Kerberos
Meshing Kerberos and Active Directory
ssh and Kerberos authentication via PAM
Apache and Kerberos
ProFTP and Kerberos
RFCs of Microsoft's Activities with Kerberos (which you really don't want to read about):
This is going to be rather long, but let's do it anyway. First of all, yes this can be done. I can't supply much in the way of configuring CVS, but I can provide all you need to make a linux server authenticate users against Active Directory.
It all starts with /etc/nsswitch.conf. Here is the relevant section:
passwd: files ldap compat
shadow: files ldap compat
group: files ldap compat
Now, depending on what distro you are using, you will need to install some ldap packages. Under Redhat/Fedora/CentOS this would be nss_ldap, under Debian/Ubuntu and the likes, you will need libnss-ldap and libpam-ldap. I would also recommend some ldap-utils for debugging.
With the above your name services will attempt to use LDAP, so now you need to configure the various LDAP packages to use your AD server. The search base should be base cn=Users,dc=aminocom,dc=com
and the bind DN should be binddn cn=LDAPsearch,cn=Users,dc=aminocom,dc=com
. You will need to define a specific User to allow browsing of the AD. We have created a user named LDAPSearch, and put its credentials into a separate file named .secret. Read the documentation of these packages for more detail. Furthermore I would recommend a soft bind policy and the following attribute mappings:
# Services for UNIX 3.5 mappings
nss_base_passwd cn=Users,dc=aminocom,dc=com?sub
nss_base_shadow cn=Users,dc=aminocom,dc=com?sub
nss_base_group cn=Users,dc=aminocom,dc=com?sub
nss_map_objectclass posixAccount user
nss_map_objectclass shadowAccount user
nss_map_attribute uid sAMAccountName
nss_map_attribute uidNumber msSFU30UidNumber
nss_map_attribute gidNumber msSFU30GidNumber
nss_map_attribute loginShell msSFU30LoginShell
nss_map_attribute gecos name
nss_map_attribute userPassword msSFU30Password
nss_map_attribute homeDirectory msSFU30HomeDirectory
nss_map_objectclass posixGroup Group
nss_map_attribute uniqueMember msSFU30PosixMember
nss_map_attribute cn cn
pam_login_attribute sAMAccountName
pam_filter objectclass=user
pam_member_attribute msSFU30PosixMember
pam_groupdn cn=nixUsers,cn=Users,dc=aminocom,dc=com
pam_password ad
All of this assumes that you have the Windows Services for Unix installed on your domain controller. In AD you will need to configure a primary Unix group (in our case called nixUsers) and add every CVS user into that group.
You should probably be able to use AD directly (i.e. without the Windows Services for Unix), but that will require different attribute mappings. You might have to experiment a bit there.
Now we get to the PAM configuration. Under Debian there are basically 4 files that need modifications:
1.) common-account:
account required pam_unix.so broken_shadow
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid
2.) common-auth:
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >=500 quiet
auth sufficient pam_ldap.so use_first_pass
auth required pam_deny.so
3.) common-session:
session optional pam_keyinit.so revoke
session required pam_limits.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
session optional pam_ldap.so
4.) common-password
password sufficient pam_unix.so md5 shadow nullok try_first_pass
password sufficient pam_ldap.so
password required pam_deny.so
Under Redhat (and derivatives) all the necessary changes should go into the relevant sections in /etc/pam.d/system-auth and /etc/pam.d/system-auth-ac.
The above will allow users to log in with AD credentials. However, this does NOT automatically create a home directory for them (unless you do some more scripting around that) and it does not allow them to change their passwords through linux. This can be done, too, but it requires modification of their workstations (if they use Linux). Any more questions re the above, just ask.
We use this on many of our servers, works like a charm.
Best Answer
Preface
Authenticating against Active Directory with Kerberos is pretty simple on systems using PAM, but OpenBSD doesn't and makes it more difficult. From a tcpdump, it looks like the PAM systems are just doing pre-authentication while OpenBSD's bsd_auth system is using the whole Kerberos authentication process.
Anyway, this took me a while to figure out so hopefully some concise instructions will save you time.
A few quick notes before we begin:
Instructions
These steps assume you are trying to authenticate myuser@myhost.fqdn against the domain EXAMPLE.COM. The domain controller is pdc.EXAMPLE.COM.
Create an Active Directory User account named myhost (that's not a typo, these instructions won't work with a Computer account). Disable password expiration and don't let the user change its own password. Set the password to whatever you like - it'll be changed soon.
It's probably a good idea to create the User account under a new OU, remove it from the Domain Users group and add it to a dedicated group. This is all a matter of taste and your security layout.
On pdc.EXAMPLE.COM, download and install Windows Server Support Tools (specifically, you'll need ktpass.exe)
On pdc.EXAMPLE.COM, run:
This updates the myhost user's password to something random (+rndpass), maps the Kerberos principal "host/myhost.fqdn@EXAMPLE.COM" to the user "myhost" in Active Directory, and then dumps the principal and private key info into the -out keytab file.
Securely copy c:\temp\myhost.keytab to myhost and delete the file from pdc.EXAMPLE.COM
On myhost, add the AD keytab to your main keytab:
Configure /etc/krb5.conf. Below is the bare minimum that you need. There's a lot of options available, take a look at the manpage for more details. This just sets the maximum acceptable clock skew to 5 minutes, makes EXAMPLE.COM the default realm, and tells Kerberos how to translate between DNS and Kerberos realms.
Verify that you can get a ticket:
Modify /etc/login.conf to use Kerberos authentication. Your exact login.conf configuration will vary depending on how you use your system, but to go from a vanilla install to using Kerberos, just edit and comment this line under the default login class:
And add above it:
This checks Kerberos first unless the user is root. If Kerberos fails, it will use local passwords.
Add the users you'd like to authenticate on this host. Leave the passwords blank unless you want them to be able to use both Active Directory and local passwords (not recommended).
You can blank existing users' passwords "chpass
<user>
" and replacing the "Encrypted password:" value with an asterisk (*)Test SSH and Sudo. Both should work flawlessly with your Active Directory credentials.
That's all there is to it.
Links
A couple useful sites: