Networking: AD + Linux
by HidekiAI on Feb.23, 2009, under Technology Opinions
Compilations of notes of joining Linux host to AD domain controller. This is an on-going notes and it will continue to evolve as I think of more…
Disclaimer: Please note that I’m not an I.T. (I’m a video game programmer – but that’s no excuse, I like to learn about all technologies I can get my hands on), these are notes from the past when I used to have access to Windows Server, and if I ever had to deal with it again, I have my notes here.
Windows DC:
This section are list of notes on the Windows Active Directory Domain Controller settings and configurations. If possible, do not install SFU3x or anything on your AD box. Keep it clean and minimal! More you mess with it and add stuffs, more confusing it becomes. Microsoft is superior on the LDAP server, it works out of the box in most cases. This setup assumes that Windows DC is based on DNS, DHCP, and AD. Don’t install WINS service if you can help it.
Register your host for Kerberos5
Make sure to register hosts with
C:\>setspn -R <hostname>
And verify with
C:\>setspn -L <hostname>
So that KDC master is aware of the host. Although you can use ksetup /DumpState to see what its state is, you need not mess with it! Also, use tools such as klist and/or kerbtray to verify your TGT service.
Oh, and make sure that your KDC host has the hostname with “$” as part of the list. Meaning when you do “setspn -L <hostname>”, there should be a “HOST/<hostname>$”. This is very critical! You’ll know this when you look at the EventLog’s Security errors and it says it could not authenticate “<Hostname>$” via Kerberos service.
Use diagnostic tools
Tools such as netdiag and dcdiag are very useful!
C:\>netdiag /debug /test:Kerberos
Fresh install, netdiag would and should work without any errors. If you’re getting errors, you’ve got too ambitious on installing more crap to your Windows, restart over!
Kerberos Encoding
When you generate a keytab (key table) using ktpass on the AD side, you will notice that the encoding is DES-CBC-MD5 as shown below:
F:\>ktpass -princ nssldap/MYLINUXCOMPUTERNAME@MYDOMAIN.LOCAL -pass * -mapuser Administrator@MYDOMAIN.LOCAL -out MyLinuxComputer_keytab Targeting domain controller: my_kdc_ad_computer.mydomain.local Successfully mapped nssldap/MYLINUXCOMPUTER to Administrator. Key created. Output keytab to MyLinuxComputer_keytab: Keytab version: 0x502 keysize 59 nssldap/MYLINUXCOMPUTERNAME@MYDOMAIN.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 9 etype 0x3 (DES-CBC-MD5) keylength 8 (0xXXxxXXxxXXxxXXxx) Account Administrator has been set for DES-only encryption.
So make sure that in your /etc/krb5.conf file, you have that support for your encoding type. (Note that by using “*” for “-pass” option, it will ask for the password).
Resetting the Computer on AD
Last but not least, this may be obvious to some but to others it may not be, is that if you’re getting a lot of kerberos errors in the Event viewer associated to your computer (MYWORKGROUP/COMPUTERNAME$), go to the Active Directory management and right click on the computer that’s having problems and select “Reset Account”.
Linux Host:
This section is notes on Linux host (clients) side.
Samba is your best friend.
Use Samba’s
#net ads join -U Administrator@YOURDOMAIN.TLD
on your host machine at least once so that Computer is joined to the DC. This may seem like a common sense to most domain admins, but I’ll mention this: you only need to join once. I’m not an I.T. guy, I’m a video game developer, I just do this because it’s educational to me (I believe everything computing is important to me and sooner or later, I’ll benefit from knowledge), and I had the impression that I had to join every single time I renewed my Keberos ticket *grin* So unless you have rebuilt your AD box, you do not need to join once you’ve joined (make sense right? When you join your XP or Vista to PDC, you have your Admin account to join to the DC, and once that box is joined, you never have to join again because it’s set).
Oh, also, another mistakes is computername versus username…. you cannot have both MYCOMPUTER$ and mycomputer.
On Samba’s testparm, if you see your host as ROLE_DOMAIN_SERVER, you need to make sure that it is ROLE_DOMAIN_MEMBER by setting (in your /etc/samba/smb.conf file):
domain logons = no
Your Windows AD should be the PDC.
If you have problems with wbinfo and you know for the fact that you’ve set everthing up correctly, try deleting the /var/cache/samba/winbindd_privileged folder (yes, the entire thing) and then restart samba. At least for me, on some of my boxes, when all else fails, this worked for me…
PAM is your Bridge
Once you get all working, make sure services are found in your /etc/pam.d/ folder. For example, if you want sshd to authenticate via PAM, make sure you have /etc/pam.d/sshd in there. Whether you authenticate via KRB5 (pam_krb5.so) or LDAP (pam_ldap.so), test things one at a time.
When debugging/testing, for ldap, add to your /etc/ldap.conf file:
debug 3
Just comment this whenever you are sure things are functional (use use 1, 3 or 5)
Kerberos
Make sure that master KDC is pointing to your PDC, and not to your host machine. We want your AD PDC to be the ticket generator.
If there exists a file /etc/krb5.keytab, delete it. It will just cause errors such as:
Key version number for principal in key table is incorrect
Also, if you get errors such as:
krb5_get_init_creds_password: Client not found in Kerberos database
Then you don’t have that account on PDC, simple as that (or possibly, did you forget to run setspn on the PDC side?)…
LDAP Configuration
No matter how you interpret it, at the end of the day, whether you use OpenLDAP or Active Directory, the end-result is how you query the user account database. That’s all it is to it. I usually start off using “ldp.exe” GUI tools for Windows. You can use any kind of tools, all you need to get it right is your query (filter) methods.
When you query the LDAP server for user authentications, you just have to make sure the query will return either 0 or 1 result for user-password mapping. If you get more than 1 result, you need to narrow down your query some more.
I usually start off with:
#getent passwd
If I see accounts that are not in my /etc/passwd from this query, then I know I’ve got far enough on my setups that it is querying AD PDC (whether it is querying via anonymous or proxy account is up to your method – for me, I prefer proxy account).
Alternatively, if your host has joined the PDC (see the section on KRB5), then you should be able to see some positive results when you do:
#net ads status
Again, Samba is your friend, I love “net ads”. If all goes well, net ads status should show you that your host is joined to the PDC by spitting out the LDAP query results (by the way, you want to verify that you are in fact connected to the right PDC via “net ads lookup“). If this fails, most likely you need to renew your Kerberos ticket (verify with klist) so make sure to run kinit if needed. Again, what you should see out of net ads status is the host (the computer) information on the AD PDC side. See the section on setspn (Windows PDC side) as well as net ads join -U Administrator@MYDOMAIN.TLD to make sure your computer (the host) is known to the PDC.
Note: Try to create another account that has only the specific rights than to use “Administrator” account. If you have auto-account-locking enabled on the PDC side, you may start to notice that Administrator account is getting constantly locked, causing SAM access on the PDC itself to fail often.
Going back to the query, other than using ldp.exe on Windows side, you can also use OpenLDAP’s ldapsearch tool. For example:
#ldapsearch -D "CN=Users,DC=MyDomain,DC=TLD" "(&(objectClass=User)(sAMAccountName=SomeUserName))"
Notice I purposely indicate DN with “-D” option, this is to keep me reminded of what DN I was using for the query. Also, note that for DN, it is “Users” while for filter, it is “User”.
By the way, if you fail this query with an error:
SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Ticket expired)
You’ll need to refresh your KRB5 ticket via kinit. You do not have to kinit with root or domain Administrator account, you should be able to acquire KRB ticket for any user account and be able to query ldap via ldapsearch.
By the way, if anybody knows a better way to renew kerberos ticket via other method than cronjobs (via “kinit -R“), please let me know because I really think it’s hacky!
LinkedIn profile
Recent Comments