I'm glossing over quite a bit here, of course, but it's a decent semi-technical summary that would be suitable for communicating to others who are not familiar with Active Directory itself, but generally familiar with computers and the issues associated with authentication and authorization.
Active Directory is, at its heart, a database management system. This database can be replicated amongst an arbitrary number of server computers (called Domain Controllers) in a multi-master manner (meaning that changes can be made to each independent copy, and eventually they'll be replicated to all the other copies).
The Active Directory database in an enterprise can be broken up into units of replication called "Domains". The system of replication between server computers can be configured in a very flexible manner to permit replication even in the face of failures of connectivity between domain controller computers, and to replicate efficiently between locations that might be connected with low-bandwidth WAN connectivity.
Windows uses the Active Directory as a repository for configuration information. Chief amongst these uses is the storage of user logon credentials (usernames / password hashes) such that computers can be configured to refer to this database to provide a centralized single sign-on capability for large numbers of machines (called "members" of the "Domain").
Permissions to access resources hosted by servers that are members of an Active Directory domain can be controlled through explicit naming of user accounts from the Active Directory domain in permissions called Access Control Lists (ACLs), or by creating logical groupings of user accounts into Security Groups. The information about the names and membership of these security groups are stored in the Active Directory.
The ability to modify records stored in the Active Directory database is controlled through security permissions that, themselves, refer to the Active Directory database. In this way, enterprises can provide "Delegation of Control" functionality to allow certain authorized users (or members of security groups) to perform administrative functions on the Active Directory of a limited and defined scope. This would allow, for example, a helpdesk employee to change the password of another user, but not to place his own account into security groups that might grant him permission to access sensitive resources.
Versions of the Windows operating system also can perform installations of software, make modifications to the user's environment (desktop, Start menu, behaviour of application programs, etc) by using the Group Policy. The back-end storage of the data that drives this Group Policy system is stored in Active Directory, and thus is given replication and security functionality.
Finally, other software applications, both from Microsoft and from third-parties, store additional configuration information in the Active Directory database. Microsoft Exchange Server, for example, makes heavy use of the Active Directory. Applications use Active Directory to gain the benefits of replication, security, and delegation of control described above.
Whew! Not too bad, I don't think, for a stream of consciousness!
Super short answer: AD is a database to store user logon and group information, and configuration information that drives group policy and other application software.
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:
- Users must exist on the OpenBSD system before attempting to login. They are not autocreated.
- If you want users autocreated, look into Samba/Winbind. I've had nothing but trouble (inexplicable crashes, serious log spamming, unreliable authentication) from it, so I only use it when I have to.
- This was tested on OpenBSD 4.5 and Windows Server 2003. I'm pretty sure it'll work with Win2k, but YMMV.
- This version of OpenBSD uses Heimdal 0.7.2. Everything here aside from the paths and login.conf stuff will probably work on other *nixes running the same Heimdal, but again, YMMV.
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:
ktpass -out c:\temp\myhost.keytab -princ host/myhost.fqdn@EXAMPLE.COM -mapuser myhost -pType KRB5_NT_PRINCIPAL +rndpass
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:
ktutil copy /path/to/myhost.keytab /etc/kerberosV/krb5.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.
[libdefaults]
clockskew = 300
default_realm = EXAMPLE.COM
[realms]
EXAMPLE.COM = {
default_domain = EXAMPLE.COM
}
[domain_realm]
.EXAMPLE.COM = EXAMPLE.COM
Verify that you can get a ticket:
# kinit Administrator@EXAMPLE.COM
Administrator@EXAMPLE.COM's Password:
# klist
Credentials cache: FILE:/tmp/krb5cc_0
Principal: Administrator@EXAMPLE.COM
Issued Expires Principal
Jun 4 21:41:05 Jun 5 07:40:28 krbtgt/EXAMPLE.COM@EXAMPLE.COM
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:
:tc=auth-defaults:\
And add above it:
:auth=krb5-or-pwd:\
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:
Best Answer
Figured out that at least in my use case I had to remove
roleUsernameMemberAttributeIt is also important to have
supplementalRolesdefinedThe final working example (unoptimized)
Note: This only does ldap authentication. You can also have a hybrid of local accounts and ldap accounts.
Update
Additional documentation & information in this github issue