This procedure allows Linux-based systems to authenticate against Active Directory. We use Kerberos for authentication, LDAP for account information, and Samba to help automate the process along the way. When this process is complete, AD users can be enabled for use on Linux systems on the network and login to those Linux systems using the same username and password as throughout the rest of Active Directory.
These instructions are designed for use with Windows Server 2003 R2. If you are looking for information on using Linux with a previous version of Windows, please refer back to this article. The only significant changes in the process involve the mapping of the LDAP attributes; otherwise, the procedure is very similar between the two versions of Windows.
Preparing Active Directory (One-Time)
Enable Editing/Display of UNIX Attributes
Based on my research, it appears that the partially RFC 2307-compliant schema is installed with Windows Server 2003 R2; this means that the schema does not need to be extended to include UNIX-specific attributes such as uid, gid, login shell, etc. However, while the attributes are there in the schema, there is no way to edit those attributes, and these attributes must be populated correctly in order for this process to work.
The easiest way to enable the editing of these attributes is to install the “Server for NIS†component on at least one domain controller. This will cause a new tab, labeled “UNIX Attributes,†to appear in the properties dialog box for users and groups. You’ll use this tab to edit the UNIX-specific attributes that are required for logins to Linux-based systems. Please note that due to the way this tab is displayed, you’ll need Schema Admin privileges in order to install the “Server for NIS†component on your domain controller. (More information on this issue is available here.)
You could just as well use LDP, LDIF files, ADSI Edit, or any number of other methods to display and edit these attributes. To make this process as seamless as possible, however, you’ll want to integrate the management of these attributes into Active Directory Users and Computers using the method described above.
Create an LDAP Bind Account
You’ll also need to create an account in Active Directory that will be used to bind to Active Directory for LDAP queries. This account does not need any special privileges; in fact, making the account a member of Domain Guests and not a member of Domain Users is perfectly fine. This helps minimize any potential security risks as a result of this account.
Prepare Active Directory (Each User)
Each Active Directory account that will authenticate via Linux must be configured with a UID and other UNIX attributes. This is accomplished via the new “UNIX Attributes†tab on the properties dialog box of a user account. (Installing the “Server for NIS†component enables this, as mentioned previously.)
After all the user accounts have been configured, then we are ready to configure the Linux server(s) for authentication against Active Directory.
Prepare Each Linux Server
Follow the steps below to configure the Linux server for authentication against Active Directory.
- Edit the /etc/hosts file and ensure that the server’s fully-qualified domain name is listed first after its IP address.
- Make sure that the appropriate Kerberos libraries, OpenLDAP, pam_krb5, and nss_ldap are installed. If they are not installed, install them.
- Be sure that time is being properly synchronized between Active Directory and the Linux server in question. Kerberos requires time synchronization. Configure the NTP daemon if necessary.
- Edit the /etc/krb5.conf file to look something like this, substituting your actual host names and domain names where appropriate:
[logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = EXAMPLE.COM dns_lookup_realm = true dns_lookup_kdc = true [realms] EXAMPLE.COM = { kdc = host.example.com:88 admin_server = host.example.com:749 default_domain = example.com } [domain_realm] .example.com = EXAMPLE.COM example.com = EXAMPLE.COM [kdc] profile = /var/kerberos/krb5kdc/kdc.conf [appdefaults] pam = { debug = false ticket_lifetime = 36000 renew_lifetime = 36000 forwardable = true krb4_convert = false } - Edit the /etc/ldap.conf file to look something like this, substituting the appropriate host names, domain names, account names, and distinguished names (DNs) where appropriate. (Please note that the nss_base_group line should not be broken across two lines when you edit it; it has been wrapped here for readability.) (Note: These schema mappings assume that you are using the newer schema extensions provided by Windows Server 2003 R2. If you are using SFU 3.5 instead, you will need to use the schema mappings described here.)
host 10.10.10.10 base dc=example,dc=com uri ldap://server.example.com/ binddn ldap@example.com bindpw adldapbindpw scope sub ssl no nss_base_passwd dc=example,dc=com?sub nss_base_shadow dc=example,dc=com?sub nss_base_group dc=mydomain,dc=com?sub? &(objectCategory=group)(gidnumber=*) nss_map_objectclass posixAccount user nss_map_objectclass shadowAccount user nss_map_objectclass posixGroup group nss_map_attribute gecos cn nss_map_attribute homeDirectory unixHomeDirectory nss_map_attribute uniqueMember member - Configure PAM (this varies according to Linux distributions) to use pam_krb5 for authentication. Many modern distributions use a stacking mechanism whereby one file can be modified and those changes will applied to all the various PAM-aware services. For example, in Red Hat-based distributions, the system-auth file is referenced by most other PAM-aware services. Here’s a properly edited /etc/pam.d/system-auth file taken from CentOS 4.4 (some lines have been wrapped for readability; do not wrap them when editing the file):
#%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required /lib/security/$ISA/pam_env.so auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok auth sufficient /lib/security/$ISA/pam_krb5.so auth required /lib/security/$ISA/pam_deny.so account sufficient /lib/security/$ISA/pam_unix.so account sufficient /lib/security/$ISA/pam_krb5.so account sufficient /lib/security/$ISA/pam_succeed_if.so uid < 100 quiet account required /lib/security/$ISA/pam_deny.so password requisite /lib/security/$ISA/pam_cracklib.so retry=3 password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow password required /lib/security/$ISA/pam_deny.so session required /lib/security/$ISA/pam_limits.so session required /lib/security/$ISA/pam_unix.so - Edit the /etc/nsswitch.conf file to include “ldap†as a lookup source for passwd, shadow, and groups.
At this point we are now ready to test our configuration and, if successful, to perform the final step: to join the Linux server to Active Directory for authentication.
Test the Configuration
To test the Kerberos authentication, use the “kinit†command, as in “kinit <AD username>@<AD domain DNS name>â€; this should return no errors. A “klist†at that point should then show that you have retrieved a TGT (ticket granting ticket) from the AD domain controller. If this fails, go back and troubleshoot the Kerberos configuration. In particular, if you are seeing references to failed TGT validation, check to make sure that both your Linux servers and AD domain controllers have reverse lookup (PTR) records in DNS and that the Linux server’s /etc/hosts file listed the FQDN of the server first instead of just the nodename.
<aside>Some readers and some other articles have suggested the use of the AD domain DNS name in the /etc/krb5.conf file instead of an AD domain controller specifically; I recommend against this. First, I believe it may contribute to TGT validation errors; second, it is possible to list multiple KDCs (AD DCs) in the configuration. Since the only major reason to use the AD domain DNS name instead of the DNS name of one or more DCs would be fault tolerance, then it doesn’t really gain anything.</aside>
To test the LDAP lookups, use the “getent†command, as in “getent passwd <AD username>â€; this should return a listing of the account information from Active Directory. If this does not work, users will not be able to login, even if Kerberos is working fine. If you run into errors or failures here, go back and double-check the LDAP configuration. One common source of errors is the name of the LDAP bind account, so be sure that is correct.
Join the Linux Server to Active Directory
This is the final step. Don’t try this step until you’ve successfully tested the configuration. After this step is completed, you are finished and AD users will be able to login to Linux-based systems (assuming the AD users have been properly configured for Linux logins).
To join the Linux server to Active Directory, follow these steps:
- Verify the Samba configuration. Be sure the following settings are specified in /etc/samba/smb.conf:
workgroup = <NetBIOS name of AD domain> security = ads realm = <DNS name of AD domain> use kerberos keytab = true password server = <Space-delimited list of AD DCs>
- Use “kdestroy†to destroy any existing Kerberos credentials you may have; then run “kinit <Domain administrative account>@AD.DOMAIN.NAME†to get a Kerberos ticket for an account that is a domain administrator account.
- Run “net ads join†to join the Linux server to Active Directory. This command will automatically create a computer object in Active Directory and add the appropriate SPNs (service principal names) to the computer object. In addition, it will populate the local Kerberos key table (/etc/krb5.keytab, by default) with the correct entries for authentication against Active Directory.
Only one small detail remains: how to deal with home directories for users logging into Linux systems.
Deal with Home Directories
Unlike Windows systems, home directories are required on Linux-based systems. As a result, we must provide home directories for each AD user that will log in to a Linux-based system. We basically have two options here:
- Use the pam_mkhomedir.so PAM module to automatically create local home directories “on the fly†as users log in. To do this, you would add an entry for pam_mkhomedir.so in the session portion of the PAM configuration file.
- Use the automounter to automatically mount home directories from a network server. This process is fairly complicated (too involved to include the information here), so I’ll refer you to this article on using NFS and automounts for home directories. This has the added benefit of providing a foundation for unified home directories across both Windows and Linux systems.
(There is a third option as well: manually create home directories before users can log in.)
Once you’ve settled on and implemented a system for dealing with home directories, you are finished! UNIX-enabled users in Active Directory can now login to Linux-based systems with their Active Directory username and password.
What’s not addressed in this article? Password management. In this configuration, users will most likely not be able to change their password from the Linux servers and have that change properly reflected in Active Directory. I’ll try to work on that for version 5 of the instructions.
I hope you find this information helpful. As always, feel free to post corrections, additions, or suggestions in the comments below.
Tags: ActiveDirectory, CentOS, Interoperability, Kerberos, LDAP, Linux, Microsoft, Samba, SSH

168 comments
Comments feed for this article
Trackback link
http://blog.scottlowe.org/2007/01/15/linux-ad-integration-version-4/trackback/
Monday, January 15, 2007 at 4:12 pm
Pingback from Red Hat » Linux-AD Integration, Version 4
Monday, January 15, 2007 at 4:52 pm
Pingback from Planeta CentOS » Linux-AD Integration, Version 4
Tuesday, September 9, 2008 at 8:43 pm
Pingback from Active Directory authentication with CentOS and RHEL 5.1 at cyber security & profound submersion
Wednesday, January 17, 2007 at 4:21 pm
Paul
Hello
Net ads join is working OK on my Ubuntu, is it possible to do it on Solaris 10 ? How dou you think ?
Wednesday, January 17, 2007 at 6:11 pm
slowe
Paul,
The version of Samba that’s included with Solaris 10 (even the 11/06 or “Update 3″ release) do not include support for Active Directory compiled in, so “net ads join” doesn’t work on Solaris by default. I have been trying to compile a new version with AD support, but I keep running into various roadblocks and missing dependencies. Prepackaged Solaris binaries (from Sunfreeware or Blastwave) may work, but I haven’t yet tried those.
As soon as I can compile or install an AD-aware version of Samba on Solaris 10 and test it, I intend to revise the Solaris-AD integration instructions on this site accordingly.
Scott
Thursday, February 1, 2007 at 12:35 pm
steve
Scott,
I was able to use your procedures to setup kerberos authentication to AD and
user/group authorization to AD Windows2003 RC2.
After I logon to the Linux server with using openssh, I do not have a kerberos ticket.
:/> klist
klist: No ticket file: /tmp/krb5cc_145538
Any idea on how to get a ticket automatically? I can issue a kinit command to get a ticket
but I thought the reason you were getting the server keytab was to allow the OS to get
the ticket for us.
Thursday, February 1, 2007 at 1:20 pm
slowe
Steve,
You’ll only have a Kerberos ticket on the remote server if you use “native” Kerberos authentication as described here:
http://blog.scottlowe.org/2006/08/21/native-kerberos-authentication-with-ssh/
Otherwise, you’re not actually talking Kerberos between the SSH client and the SSH server…it’s just the SSH server that’s using Kerberos on the back-end to authenticate the user.
Of course, you could use some sort of script that executes when a user logs in…there’s always more than one way to accomplish your goal.
Scott
Tuesday, February 6, 2007 at 1:01 am
ron terren
Scott,
Taking all of this into account, does it matter if I want to raise the domain/forest functional level to the highest setting, or does it have to remain in mixed mode?
Thanks,
Ron
Tuesday, February 6, 2007 at 9:57 pm
slowe
Ron,
As far as I am aware, you are free to raise the domain/forest functional levels to their highest available settings. Linux integration does not require mixed mode.
Scott
Tuesday, February 13, 2007 at 3:39 pm
Leonard
I have the single sign on working but would like to prevent user from AD to logon unless they are a member of a certain group. Any ideas on how to do this?
Thanks,
Leonard
Tuesday, February 13, 2007 at 4:15 pm
slowe
Leonard,
Check out this article:
http://blog.scottlowe.org/2006/09/08/ldap-based-access-control/
It should provide the information you are seeking.
Regards,
Scott
Thursday, February 15, 2007 at 5:55 am
Nico
Hi Scott,
thanks for a *very* useful howto on linux-ad integration! I had been trying to get this to work for some time now.
One remark: although I was working with a freshly installed Win 2003 R2 server (with SFU 3.5 installed) I had to use the old schema mappings in /etc/ldap.conf. It took me a while to figure this out. You may want to add this as a remark in your text.
Thanks again!
Nico
Thursday, February 15, 2007 at 9:15 am
slowe
Nico,
You are absolutely correct–if you are using SFU 3.5 on any supported version of Windows, you must use the “old” schema mappings in /etc/ldap.conf. I made the incorrect assumption that if you were using 2003 R2 you would not be using SFU 3.5–my mistake. I’ve updated the article accordingly. Thanks!
Scott
Thursday, February 22, 2007 at 10:14 am
John
I’m curious about the ‘Join the server to AD’ portion of this. It seems that once you have setup nss_ldap & krb5/pam_krb5, you will have functional authentication and authorization from AD on the system already (even with no samba). What additional benefits are gained from the join portions of the procedure?
Thursday, February 22, 2007 at 12:39 pm
slowe
The joining of the server to AD creates a security principal in AD and generates all the keytab entries for the TGT validation that is part of Kerberos authentication. You can typically do Kerberos authentication without TGT validation by not including this step, but then you lose the assurance that the TGT is actually coming from the server that it’s claiming to be. Essentially, you lose mutual authentication.
Thursday, February 22, 2007 at 3:29 pm
John
Ok, so I’m correct in what I was assuming is this is an alternate method of populating the keytab rather than the method used in the Solaris document (and Microsoft’s) where it’s exported via ktpass and manually migrated across. I just wanted to make sure this wasn’t doing some voodoo magic that I couldn’t see, since I don’t have samba-common in the base system.
Have you done any work in the DNS based distribution of ADS communication from clients a-la what Windows clients natively do? That’s my next step. I think it may simply not be feasible though, and they will end up statically mapped to a pair of DCs.
Thursday, February 22, 2007 at 4:49 pm
slowe
John,
Yes, you are correct–using Samba in this case avoids the need to use ktpass.exe on the Windows side, then transferring the keytab to the Linux box, etc.
As for the use of SRV records to lookup DCs in Active Directory, you can do that using the “dns_lookup_kdc = true” option in /etc/krb5.conf. However, I have seen some instances where TGT validation fails in that instance. Most implementations end up statically mapped to a couple of DCs.
Thursday, February 22, 2007 at 5:08 pm
John
This would solve it for the krb5 portion, but I don’t think it would work for LDAP (in any method that I know) — which would leave you with authentication but no authorization. Is this incorrect?
Thursday, February 22, 2007 at 7:30 pm
slowe
You are correct. As far as I am aware, the nss_ldap libraries do not have the ability to use SRV records to locate LDAP servers, so you’ll have to just use statically coded entries. You can, of course, list multiple LDAP servers in the configuration file.
Tuesday, February 27, 2007 at 10:10 am
Ryan
Scott,
Any new update on password management ? Thanks.
Tuesday, February 27, 2007 at 7:41 pm
slowe
Sorry, Ryan, no new updates on password management. I messed around with changing passwords from the Linux side but haven’t had time to explore it fully.
Scott
Thursday, March 8, 2007 at 1:28 pm
JS
I have SSO working but I have a question. I can not add a local user since users authenticate to AD. Is it possible to add local users?
Monday, March 12, 2007 at 9:47 am
Alexey
I had been trying to get this. It is really work. But one question. When in AD on any account I make “User must change password at next logon” - receive next messages
login: test2
Password for test2@CTB.LOCAL:
Password expired. You must change it now.
Access denied
Using keyboard-interactive authentication.
Password for test2@CTB.LOCAL:
I can’t change password. Why?
Monday, March 12, 2007 at 7:33 pm
Sean
Scott, thanks for this awesome website, everything worked out as you outlined it here. I am now trying to figure out how to get Password Synchronization working.
Monday, March 12, 2007 at 7:33 pm
Sean
JS, would you be so kind as to share what information you used to get SSO working? Thanks, Sean
Monday, March 12, 2007 at 10:10 pm
slowe
JS,
As long as you left the pam_unix.so lines in the system-auth configuration, you should still be able to create and authenticate using local users.
Alexey,
There are some additional configurations that are required in order to be able to change your password from the Linux side, especially during logon. I have not had the time to research this fully, so I can’t give you any definitive guidance. I hope to be able toa ddress this soon in another blog posting.
Sean,
Glad you are finding the site helpful. As soon as I have the chance to research some information on password synchronization, I’ll be sure to post it here.
Thanks, everyone!
Wednesday, March 14, 2007 at 2:18 am
CS
After following your steps to the letter I have this mostly working, however, I frequently get errors like this:
[root@ad-linux ~]# ls -la /home
ls: ../../../libraries/liblber/sockbuf.c:90: ber_sockbuf_ctrl: Assertion `sb != ((void *)0)’ failed.
Aborted
[root@ad-linux ~]# ls -la /home
total 20
drwxr-xr-x 3 root root 4096 Mar 14 18:15 .
drwxr-xr-x 23 root root 4096 Mar 14 17:35 ..
drwxr-xr-x 2 csmith 10000 4096 Mar 14 18:15 csmith
[root@ad-linux ~]#
Any ideas ?
CS
Wednesday, March 14, 2007 at 6:56 pm
slowe
CS,
Looks like a bug of some sort in one of the libraries you have installed. I would guess it is the nss_ldap library or a related library, since the error manifests itself when resolving user names and group names to UIDs and GIDs, respectively. I’d suggest re-installing the nss_ldap library and any related packages and seeing if that resolves the issue.
Wednesday, March 14, 2007 at 9:59 pm
CS
Sorry, I should have provided some more details…
This is a bone-stock CentOS 4.4 installation, done from scratch specifically to proof-of-concept this authentication. I’ve actually since reinstalled the machine again and it’s still returning the same errors. Additionally, anything that involves sucking down user information (eg: getent passwd, ls’ing a directory with files/directories owned by AD users, etc) is extremely slow.
The DC is on the same network segment as the Linux machine and isn’t under any sort of load, so I don’t think that’s the problem.
Since I’m using CentOS and you used CentOS, I’m just trying to figure out why we don’t have the same problems :).
I am contemplating using SFU’s NIS server instead to grab the user information. A quick test indicates that it would work and doesn’t seem to have the “crashing” issue, but it’s still very slow. Thoughts ?
CS
(PS: I had these exact same issues the last time I tried to get this up and running, ~12 months ago - I just assumed at the time it was some bugs in the libraries that would be ironed out over time. Guess not…)
Thursday, March 15, 2007 at 9:12 pm
slowe
CS,
Hmmm…that’s very odd. I’ve done this many times, from scratch, and haven’t run into this problem. Have you indexed any of the attributes used by authentication, such as UID? That can help with some of the performance concerns you mentioned. I’m not sure about the error messages and the crashing; that just doesn’t make sense.
I’m not really sure what to suggest from here…have you tried any of the Linux newsgroups?
Friday, March 16, 2007 at 12:47 am
CS
Fixed it ! The culprit was “LDAP referrals”. Having just spent several hours figuring it out, this actually refreshed my memory that it was the same problem - and its cause - that stopped me implementing this the last time (which, in my defense, was 18 - 24 months ago, now that I go back and search my emails, not 12 months).
We have a slightly complicated domain structure in that we have multiple child domains (for each branch office). With referrals turned on, nss_ldap recurses down from domain.com to child1.domain.com, child2.domain.com, etc before returning results. There must be something that happens in this process that sometimes triggers the errors I was seeing (because they appear at random) and also causing the slowdowns.
If you put:
referrals no
into /etc/ldap.conf, the problems all go away (or, at least, they haven’t happened since - with these sort of random errors you never can be 100% sure
). Response time is also substantially faster.
I can get away with this _now_ because (for unrelated reasons) we are flattening our domain structure and nixing the child domains. Previously this was not an option so any authentication system had to be able to include users in the child domains.
I also seem to vaguely recall that you can get around much of the slowness related to multi-domain configurations by a) pointing at a DC that is a Global Catalogue and b) pointing at the GC port instead of the regular LDAP port. This didn’t help the random crashes with things like ‘getent group’ though, IIRC.
Well, now all I need to do is get the automounter going with NFS’d home directories, and we’ll be golden. I might have to bend your ear about that shortly as well ;).
CS
Friday, March 16, 2007 at 5:33 am
slowe
CS,
Thanks for the update! I’ll have to see if I can get in some testing time with this kind of scenario, reproduce the problem, and then try the fix of using the GC and GC port instead of standard LDAP.
Take care,
Scott
Friday, March 16, 2007 at 2:22 pm
Shannon VanWagner
Any ideas on how to set this up for Suse Linux Enterprise Desktop 10 -specifically the pam modules configuration section since they are a bit different from CentOS?
Thanks for the great information!
Shannon VanWagner
Friday, March 16, 2007 at 10:27 pm
slowe
Shannon,
I’m afraid I can’t offer much help in that regard, as I’ve never worked with that distribution. If you want to send over your existing system-auth (or equivalent), I’ll look and it and I might be able to make some recommendations.
Hope this helps,
Scott
Tuesday, March 20, 2007 at 9:20 am
Shannon VanWagner
Hi Scott,
Thanks for your reply. Here’s a more detailed description of my problem with configuration file information included:
RE: Sled 10 System Hangs When Using Ldap / kerberos To Authenticate To Server 2003 R2
I’ve configured LDAP/Kerberos authentication on SLED 10 and am trying to authenticate to Active Directory on Windows Server 2003 R2. Note: the UNIX attributes for each user are showing up in active directory.
The authentication seems to work as it lets me login as a Windows user. I can also run id and get the correct uid for that user. However, after logging in there are serious system performance issues (to the point where the system freezes up after about 10 min).
wbinfo -u and wbinfo -g show all domain users and domain groups as expected
However, when I run the getent passwd or getent group commands I get a listing that shows some of the Active Directory users and then the listing gets stuck and never returns to the command line. After that, if I don’t use CTRL+C to exit the getent listing, the computer freezes up as if it’s stuck in a loop or something.
I’ve already successfully had authentication working properly with the same client/server using winbind instead of ldap - that solution doesn’t give me the uid/gid mapping I need however. This makes me think there’s something I’m missing with the ldap configuration or something.
Here are my configs:
——————— /etc/nsswitch.conf——————————
#
# An example Name Service Switch config file. This file should be
# sorted with the most-used services at the beginning.
#
# The entry ‘[NOTFOUND=return]‘ means that the search for an
# entry should stop if the search in the previous entry turned
# up nothing. Note that if the search failed due to some other reason
# (like no NIS server responding) then the search continues with the
# next entry.
#
# Legal entries are:
#
# compat Use compatibility setup
# nisplus Use NIS+ (NIS version 3)
# nis Use NIS (NIS version 2), also called YP
# dns Use DNS (Domain Name Service)
# files Use the local files
# [NOTFOUND=return] Stop searching if not found so far
#
# For more information, please read the nsswitch.conf.5 manual page.
#
# passwd: files nis
# shadow: files nis
# group: files nis
passwd: compat ldap
shadow: compat ldap
group: compat ldap
hosts: files dns
networks: files dns
services: files
protocols: files
rpc: files
ethers: files
netmasks: files
netgroup: files nis
publickey: files
bootparams: files
automount: files nis
aliases: files
—————————–/etc/ldap.conf———————————-
host 10.10.0.10
base dc=mydomain,dc=com
uri ldap://host1.mydomain.com/
binddn cn=linuxldap,cn=Users,dc=mydomain,dc=com
bindpw mypassword
scope sub
bind_timelimit 15
timelimit 15
ssl no
nss_base_passwd dc=mydomain,dc=com?sub
nss_base_shadow dc=mydomain,dc=com?sub
nss_base_group dc=mydomain,dc=com?sub?&(objectCategory=group)(gidnumber=*)
nss_map_objectclass posixAccount user
nss_map_objectclass shadowAccount user
nss_map_objectclass posixGroup group
nss_map_attribute gecos cn
nss_map_attribute homeDirectory unixHomeDirectory
nss_map_attribute uniqueMember member
nss_initgroups_ignoreusers root,ldap
———————————–/etc/samba/smb.conf—————————–
sldtenghst:~ # cat /etc/samba/smb.conf
# smb.conf is the main Samba configuration file. You find a full commented
# version at /usr/share/doc/packages/samba/examples/smb.conf.SUSE if the
# samba-doc package is installed.
# Date: 2007-02-07
[global]
workgroup = INTERNAL
realm = MYDOMAIN.COM
security = ads
use kerberos keytab = true
password server = host1.mydomain.com
netbios name = suse10box
winbind use default domain = yes
winbind separator = +
idmap uid = 1000-29999
idmap gid = 1000-29999
winbind enum users = yes
winbind enum groups = yes
#deadtime = 15
#winbind cache time = 10
winbind nested groups = yes
template homedir = /home/%U
template shell = /bin/bash
client use spnego = yes
socket options = TCP_NODELAY SO_RCVBUF=16384 SO_SNDBUF=16384
dns proxy = no
domain master = no
preferred master = no
max log size = 100
log file = /var/log/samba/%m.log
printing = cups
printcap name = cups
printcap cache time = 750
cups options = raw
map to guest = Bad User
include = /etc/samba/dhcp.conf
logon path = \%L\profiles\.msprofile
logon home = \%L\%U\.9xprofile
logon drive = P:
usershare allow guests = Yes
—————————————–/etc/pam.d/common-auth—————
auth required pam_env.so
auth sufficient pam_krb5.so
auth required pam_unix2.so
—————————————-/etc/pam.d/common-account————-
account sufficient pam_krb5.so
account required pam_unix2.so
—————————————-/etc/pam.d/common-password———–
password required pam_pwcheck.so nullok
password required pam_unix2.so nullok use_first_pass use_authtok
—————————————-/etc/pam.d/common-session
session required pam_limits.so
session required pam_unix2.so
session required pam_mkhomedir.so umask=0077 skel=/etc/skel
—————————————————-
Thanks again!
Tuesday, March 20, 2007 at 9:36 am
Shannon VanWagner
Scott,
The previous posting from CS fixes my problem with LDAP hanging up!!
(per the posting by CS above) I put this in the /etc/ldap.conf file:
referrals no
The system hangup on getent passwd has disappeared - Thanks VERY MUCH to CS and Scott for having this information posted online!!
Now my NEW problem is that I don’t seem to have my pam files configured correctly..
I can su and that works great (with correct uid) but I can’t login at the front screen of the computer.
The errors logged in /var/log/messages show:
gdm[pid] pam_krb5[pid]: error resolving user name ‘windows-user’ to uid/gid pair
gdm[pid] pam_krb5[pid]: error getting information about ‘windows-user’
gdm[pid] pam_krb5[pid]: Couldn’t authenticate user
I’m thinking I need to add pam_ldap to my pam config files but I’m not exactly sure
Thanks very much for your assistance!!
Tuesday, March 20, 2007 at 10:07 am
Shannon VanWagner
*****************UPDATE 2***************************
Fixed the above problem with a posting by “weeden” at
——————————–original posting—————————————————
I found this which solved most of the problems.
http://www.redmondmag.com/columns/article.asp?EditorialsID=858
It doesn’t mention the following changes to the smb.conf file
idmap backend = ldap:ldap://ldapserver.domain.com
ldap idmap suffix = dc=domain,dc=com
ldap admin dn = cn=Administrator,cn=Users,dc=domain,dc=com
ldap suffix = dc=domain,dc=com
Save the conf file and run “smbpasswd -w ADMIN_DN_PASSWORD”
Then run: (to get the Windows User’s Passwords and Groups)
getent passwd
getent group
Add to /etc/pam.d/system-auth
session optional /lib/security/$ISA/pam_mkhomedir.so
And you’re ready to go! You will now beable to login via X with your Windows user name and password
——————————–original posting end———————————————–
Now I have a NEW problem:
When I su , I don’t get prompted to enter a password. Do you know how to configure my pam configs so that when su’ing to any windows user (as root) I will get the password prompt for that user? (example: su administrator — no password prompt).
Thanks very much!
Tuesday, March 20, 2007 at 10:08 am
Shannon VanWagner
Note: the previous comment should say that I found the information in a comment left by user “weeden” at http://forums.fedoraforum.org/archive/index.php/t-29825.html
Tuesday, March 20, 2007 at 8:59 pm
slowe
Shannon,
First off, I’m glad that you were able to find information here to fix the LDAP “hangup” that was plaguing your system. I’m excited to see a bit of an ecosystem forming here where users are sharing valuable information on AD integration tasks.
With regards to your su problem, it sounds to me like a PAM configuration issue. Some distributions have a PAM configuration that will implicitly trust members of certain groups or members with UIDs below a certain level. We’d need to review your PAM configuration for su in order to know if this is the case. You are welcome to shoot me an e-mail (scott dot lowe at scottlowe dot org) if you’d rather not post it here in the comments.
Thursday, March 22, 2007 at 1:01 am
Shannon VanWagner
SUSE Linux Enterprise Desktop ( SLED ) 10 Single Sign-On LDAP / Kerberos Authentication to Active Directory on Windows Server 2003 R2
Important Note: It’s been a bit of an emotional roller coaster for two weeks (with much blood, sweat, and tears involved) getting this to work… What’s depressing is that I haven’t found any resource that gives me absolute specific instructions on how to set this up for SLED 10.
Hehe, It’s time to “jerk the chain” a little for the Novell SLED 10 phone support…. I’d like to mention that I’ve called this whole problem in as a support ticket to Novell - I told them that I was fully able to authenticate with winbind from SLED 10 to Windows AD. The problem was that the winbind method didn’t appear to offer any way to sync user/group UID/GID across platforms, Novell confirmed this is true. The support guy actually said I should install eDirectory (Novell Product - go figure) in order to use LDAP authentication from SLED 10 to AD… Apparently Novell’s support team is not fully aware of the fact that Windows Server 2003 R2 is ready (out of the box) to support authentication and user/group UID/GID mapping from Active Directory LDAP to SLED 10. Hopefully Novell will catch on to this useful fact quick so that more sysadmins such as myself can use SLED 10 to its greatest ability for the great OS it is. SLED 10 truly is a very nice product!! Good Job Suse Devs, and Thanks!
So here’s how to configure SLED 10 to connect with Server 2003 R2 Active Directory via LDAP…
(Editor’s Note: The remainder of the information in Shannon’s comment has been moved into a post of its own:
http://blog.scottlowe.org/2007/03/22/sled-integration-into-active-directory/
The information was detailed enough and extensive enough that I felt it warranted a full blog posting of its own. -SL)
Thursday, March 22, 2007 at 12:38 pm
alaxa
this guide grows up very interestingly. great!
I still have no solved my problem where in SuSE10.1 sometime any process that involves the LDAP query hangs eating all the CPU. I found that disabling the group mapping in ldap.conf everything goes fine.
Anyhow, my new question is if it is possible to renew the kerberos ticket got at the login.
I mean, the ticket expires after sometime, I could renew it by hand but I have to check periodically if it’s going to expire or not. On the other side users are not so skilled to do a kinit any X hours so they cannot access to many kerberized applications.
thanks for any input
Saturday, March 24, 2007 at 9:37 pm
Taras S.
I spent much time to get ktpasswd work (Heimdal was saying “Soft error”, MIT - “Password change rejected”). As I expected, solution was simpe: password change via ktpasswd didn’t work only because of one thing in domain group policy: by default in AD environment password can’t be changed by user more often then once per day
My install:
Fresh Windows Server 2003 R2 Std, FreeBSD 6.2 with Heimdal(base) or MIT(ports).
Friday, March 30, 2007 at 10:32 am
slowe
Taras,
Can you share more information on what you did to make ktpasswd work with AD? As I’m sure you’ve noticed, there’s a lot of interest here in that configuration.
Friday, April 6, 2007 at 3:48 am
McDouglas
Hi!
I’m trying to implement this integration in a test environment. I’m not an expert, and i run into a problem I’m not sure about.
I followed you instructions, and installed the libraries on a newly installed Debian. However, after that i ended up with an /etc/ldap/ldap.conf file and with an /etc/libnss-ldap.conf one.
You say i should put the ldap configs in /etc/ldap.conf … now, what should i do?
1, create the file /etc/ldap.conf?
2, edit /etc/ldap/ldap.conf?
3, edit /etc/libnss-ldap.conf?
I’m not sure which one is the correct solution, and i don’t want to mess up something in the long run.
Thanks.
Friday, April 6, 2007 at 7:36 am
slowe
McDouglas,
I’m not that familiar with Debian, but I’d have to say that the file you want to modify is the /etc/libnss-ldap.conf file. This should be the file that controls the behavior of the name switch service interface to LDAP, and that’s what you need.
Monday, April 9, 2007 at 6:59 am
McDouglas
Hello!
I hit another problem. The kerberos test is woking fine (kinit&klist) however i do not get any data with getent. I did try placing the ldap information in all 3 files (one at a time, and also everywhere)
As far as i know PAM should not effect the results of getent, right? Only the nsswitch.conf, which is:
passwd: ldap compat
group: ldap compat
shadow: ldap compat
hosts: files dns
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
netgroup: nis
Any idea what could be the problem?
Config files:
krb5.conf
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = TESTDOMAIN.LOCAL
dns_lookup_realm = true
dns_lookup_kdc = true
[realms]
TESTDOMAIN.LOCAL = {
kdc = mmserverr2.testdomain.local:88
admin_server = mmserverr2.testdomain.local:749
default_domain = testdomain.local
}
[domain_realm]
.testdomain.local = TESTDOMAIN.LOCAL
testdomain.local = TESTDOMAIN.LOCAL
[kdc]
profile = /var/kerberos/krb5kdc/kdc.conf
[appdefaults]
pam = {
debug = false
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
}
———
ldap.conf:
host 192.168.0.5
base dc=testdomain,dc=local
uri ldap://192.168.0.5/
binddn ldap@testdomain.local
bindpw ***
scope sub
ssl no
nss_base_passwd dc=testdomain,dc=local?sub
nss_base_shadow dc=testdomain,dc=local?sub
nss_base_group dc=testdomain,dc=local?sub?&(objectCategory=group)(gidnumber=*)
nss_map_objectclass posixAccount user
nss_map_objectclass shadowAccount user
nss_map_objectclass posixGroup group
nss_map_attribute gecos cn
nss_map_attribute homeDirectory unixHomeDirectory
nss_map_attribute uniqueMember member
Monday, April 9, 2007 at 2:59 pm
slowe
McDouglas,
Everything seems to look OK; I’m not sure why it’s not working. Some quick questions:
- I assume that you have the correct password and name for the LDAP bind account? When using user@domain, you must make sure this matches the account’s UPN in AD.
- No DNS problems?
- Does the “id” command work, i.e., “id aduser”?
- No firewall rules that could be blocking LDAP traffic from the Linux client to the AD server(s)?
Let me know about this stuff and let’s see if we can get you working.
Monday, April 9, 2007 at 3:08 pm
McDouglas
Hi,
Yes, the password is correct, i can login with the password for the bind user account on the windows.
As for dns, each machine has an A and a PTR record, in the dns server (which is the domain controller itself). Besides that, everything is left default as the win2k3 r2 made it after completing a new install and adding the AD and DNS roles.
Can’t test “id” right now, will do tomorrow. But if i read it right, it resolves the username to uid, right? It should get its info from the ldap too :\ So i suspect it wont work.
No firewall is present.
Tuesday, April 10, 2007 at 2:38 am
McDouglas
Hi Scott,
After reinstalling the debian to make sure I did not make any misstakes it still does not work. However i did play with ldapsearch to see if the connection does work at all or not, and here is the result:
debian:/# ldapsearch -x -b “dc=testdomain,dc=local” “(objectclass=*)”
# extended LDIF
#
# LDAPv3
# base with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# search result
search: 2
result: 1 Operations error
text: 00000000: LdapErr: DSID-0C090627, comment: In order to perform this ope
ration a successful bind must be completed on the connection., data 0, vece
# numResponses: 1
So, according to this, there is sime kind of bind problem…. but what? The bind user exists nad the password is correct (can log in on windows)…
One question maybe: do i have to configure the unix attributes on windows for this bind user too? Like putting it into a nis domain?
Tuesday, April 10, 2007 at 2:48 am
McDouglas
Update:
I was wrong, the ldapsearch does not take the bind parameters from the ldap.conf file, instead its specified int he cmd line. And after doing so, it did list the ldap info from the windows server.
So, the ldap connection works, can use the bind user…. why does not work the getent?
Tuesday, April 10, 2007 at 8:54 am
slowe
McDouglas,
What is being reported in the system logs? Anything?
Tuesday, April 10, 2007 at 9:20 am
McDouglas
FIXED!
Finaly, i got it working. I reinstalled the windows machine and instead of the new R2 component, i installed the SFU 3.5. On the linux box i used the old ldap mappings and everything worked!
However i got an interesting error now. I edited the pam files and joined the linux to the ad with net ads join command. I could log in with my AD users, without any problem, it was perfect. But after a reboot, the server just spamms the screen with errors: “nss_ldap: could not bind to the server/could not connect to the server”. And it hangs there, no more booting.
Any ideas?
Tuesday, April 10, 2007 at 9:56 am
McDouglas
Just to make it clear, here is a screenshoot. Maybe it explains the error better than i did
http://mmcomp.adsl.datanet.hu/~mcdouglas/error.jpg
Tuesday, April 10, 2007 at 10:23 am
slowe
McDouglas,
The only thing I can suggest is to boot into single user mode and make sure that your nsswitch.conf file lists “files” first for passwd, shadow, and group. You may be running into an issue where it needs to resolve some information, but can’t because the network isn’t up yet and LDAP is listed first in nsswitch.conf.
Hope this helps!
Tuesday, April 10, 2007 at 10:28 am
McDouglas
Well, i already left my workplace, but i do remember what is in the nsswitch.conf
passwd: compat ldap
shadow: compat ldap
group: compat ldap
The “compat” was there originaly, i just added the ldap entries, in this order. Could this be the problem?
Tuesday, April 10, 2007 at 5:07 pm
McDouglas
I think i found out what is the problem:
http://www.liquidx.net/blog/2006/04/03/nss_ldap-undocumented-nss_reconnect_tries/
I’m eager to try this tomorrow.
Wednesday, April 11, 2007 at 1:44 am
mopok
Hi, Scott!
I’ve used your tutorual to let my AD users login into my Ubuntu box. And everything went well until the last step. When I recieved kerberos ticket for a domain administrator account and typed ‘net ads join’ command my Ubuntu box successfully joined AD realm. And after that no AD users can login into it. Before I joined my box to AD users could login into it. Funny. While trying to login using AD credentials in syslog I see lines like this:
gdm[4243] : Unable to authorize user
(well, sorry for free translation - I have a localized version of Ubuntu
Where is an issue?
Wednesday, April 11, 2007 at 3:09 am
mopok
Update: everything works fine! The issue was in misconfigured hostname and hosts files.
Wednesday, April 11, 2007 at 9:06 am
Doug
Thanks for the info CS regarding the ldap referrals. I had one RHEL that was very slow with commands like ls -l and setting referrals no in ldap.conf appears to have solved the problem. Oddly enough, another RHEL box that is an ADS client and that is configured in same way [as the once "slow" box] has not experienced any such slow down.
Monday, April 16, 2007 at 7:15 am
Habanera
Hello together,
I hope to find some helpful tips here.
I have the following problem.
I want to use an gentoo dist. to authenticate against ads (Windows 2003 Std).
I habe configured the conf files. With getent I get the userinformation:
adstestuser001:*:1001:1000:adstestuser001:/home/adstestuser001:/bin/bash
adstestuser002:*:1002:1000:adstestuser002:/home/adstestuser002:/bin/bash
and “id adstestuser001″ returns “uid=1001(adstestuser001) gid=1000 groups=1000″.
ldapsearch also works fine for the user.
First problem:
With kinit I can create an Kerberos ticket for Administrator, but not for other user. It appears this error message:
gsxgentooads log # kinit adstestuser001@DOMAIN.LOCAL
Password for adstestuser001@DOMAIN.LOCAL:
kinit(v5): Preauthentication failed while getting initial credentials.
Second problem:
When I want to log in via SSH (putty) it appears an Network disconnect, when I have created an valid kerberos ticket (just using kinit where the Administrator account will be used). If the ticket is not valid (time expired), the ssh-login prompt appears.11
Third problem:
When I try to login as “adstestuser001″ @ the shell, I always get first an other password question and as secondary password question the user login passwd.
An login is always successless.
If further information are needed, please tell me what.
Thanks!!!
Monday, April 16, 2007 at 9:19 pm
slowe
Habanera,
Any messages in the logs when you attempt to obtain a Kerberos ticket for a non-Administrator user, on either the Linux client or the Windows server(s)?
Thursday, April 19, 2007 at 9:55 am
McDouglas
Hello!
Finally, everything is working! Thanks for the great guide and the help you provided.
However, i came across a strange error: after setting up the system, almost every authentication works (login, ssh, pop3, samba) BUT the proftpd will not allow me to log in with AD users (only local ones). In /etc/pam.d i have the proftpd file filled with the proper settings (@include common-auth…etc), and “proftpd -l” lists mod_auth_pam.c as compiled in modules. I did set the AuthPAM to on (altough it is the default) and AuthPAM to proftpd.
Stil not working :\
Wednesday, April 25, 2007 at 6:52 am
Nico
Hi Scott,
one problem I haven’t seen mentioned yet: when I disable an account on my AD server
I can still logon on linux. Has anybody else seen this behaviour? The state of the account
is recorded in the userAccountControl field in Active Directory however I can’t figure out how
to make PAM check it.
Nico
Thursday, April 26, 2007 at 10:02 am
slowe
Nico,
I haven’t observed that behavior, but I’ll try again and see if I can replicate it with my setup.
Friday, April 27, 2007 at 3:56 am
Nico
The problem seems to be with unixwindows password synchronisation on Windows. If you turn this on in Services for Unix, windows will put a unix-encrypted copy of your windows password in AD the next time you change your password. So if you do ‘getent passwd ‘ the second field will contain your password as it would appear in the /etc/passwd file. If you don’t turn on password synchronisation the password field will be an invalid value ‘ABCD!efgh12345$67890′.
It turns out that if the password field is set pam_unix.so will actually do the authentication in stead of pam_krb5.so. So if you disable the account on Windows pam_unix.so will still check your password and let you in while pam_krb5.so would have kicked you out. Commenting out the line
# auth sufficient pam_unix.so likeauth nullok
fixes this, however it also makes it impossible to log on as local root. I believe there should be a way to use pam_unix only for uid
Friday, April 27, 2007 at 11:12 pm
slowe
Nico,
Hmmm….good information. I’ll have to see if I can find a workaround. I haven’t worked with the password synchronization features, which is why I haven’t seen this particular behavior myself. I can certainly see where it could be a serious problem in some environments.
You might consider implementing LDAP-based access controls in addition to your existing security measures. This article has more information:
http://blog.scottlowe.org/2006/09/08/ldap-based-access-control/
Hope this helps!
Friday, May 4, 2007 at 10:21 am
Kessia Pinheiro
Hi! I’m doing the Linux integration, but my boss dont want do “net ads join”. Using OpenLDAP + Samba + Kerberos + Pam, all authentication works, excepts the Samba + Cups. I want add a printer in Windows Server, using AD to auth, but doesnt work anymore. I get that error:
I [04/May/2007:11:16:01 -0300] Job 18 queued on “Lexmark” by “kessia”.
I [04/May/2007:11:16:01 -0300] Started filter /usr/lib/cups/filter/pstops (PID 4297) for job 18.
I [04/May/2007:11:16:01 -0300] Started backend /usr/lib/cups/backend/smb (PID 4298) for job 18.
E [04/May/2007:11:16:01 -0300] [Job 18] Session setup failed: SUCCESS - 0
E [04/May/2007:11:16:01 -0300] [Job 18] Session setup failed: NT_STATUS_LOGON_FAILURE
E [04/May/2007:11:16:01 -0300] [Job 18] Tree connect failed (NT_STATUS_ACCESS_DENIED)
E [04/May/2007:11:16:01 -0300] [Job 18] Unable to connect to CIFS host, will retry in 60 seconds…
You can help me? I dont kow what more i do… Please, answer by email.
Wednesday, May 9, 2007 at 4:23 am
Greg West
Hi Nico & Scott,
I’ve found a solution to a user still being able to login, even if their account is disabled in AD. I achieved this using the pam_succeed_if module. So, (on CentOS/RHEL4) my /etc/pam.d/system-auth looks like this.
auth required /lib/security/$ISA/pam_env.so
auth sufficient /lib/security/$ISA/pam_krb5.so
auth requisite /lib/security/$ISA/pam_succeed_if.so uid = 0
auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok
auth required /lib/security/$ISA/pam_deny.so
Works a treat! Basically it says, if uid = 0 tries to login (root), proceed. However, if you have local accounts as well as AD accounts, this will fail. A possible solution to this is to have your UID’s start from say, 10000 in unix attributes in the AD, and to have your local UID’s all below 10000. You could then change the pam_succeed_if line to read:
auth requisite /lib/security/$ISA/pam_succeed_if.so uid
Wednesday, May 9, 2007 at 4:24 am
Greg West
Hmmm, my post above had its less than sign stripped …. lets try again
<snip>
A possible solution to this is to have your UID’s start from say, 10000 in unix attributes in the AD, and to have your local UID’s all below 10000. You could then change the pam_succeed_if line to read:
auth requisite /lib/security/$ISA/pam_succeed_if.so uid < 10000
Friday, May 11, 2007 at 3:33 pm
slowe
Kessia,
It sounds like the user under which CUPS is running can’t authenticate to AD. I’d have a look in that direction and see what additional information you can gather.
Greg,
Good tip–thanks for sharing it here. I need to delve into that issue in more detail and see what additional information I can gather. When I get more info, I’ll post something here.
Monday, May 14, 2007 at 3:58 am
Nico
Thanks Greg! The pam_succeed_if.so trick was exactly what I was looking for!
Nico
Tuesday, May 22, 2007 at 9:11 pm
Greg West
Hi Nico,
here’s an even better solution.
Using this system-auth, local accounts will take precedence, and pam_groupdn restrictions (IE locking down accounts that can login based on their ldap groups) also work. Also if the user is disabled in AD they cannot login, and password restrictions will also apply (IE 3 wrong attempts and the account gets locked).
I spent quite a while getting this to work well, but I can confidently say this is a very good solution.
Cheers,
Greg.
#%PAM-1.0
auth required /lib/security/$ISA/pam_env.so
auth required /lib/security/$ISA/pam_unix.so likeauth nullok
auth sufficient /lib/security/$ISA/pam_localuser.so
auth sufficient /lib/security/$ISA/pam_krb5.so forwardable
auth required /lib/security/$ISA/pam_deny.so
account sufficient /lib/security/$ISA/pam_localuser.so
account required /lib/security/$ISA/pam_ldap.so
account sufficient /lib/security/$ISA/pam_krb5.so forwardable
account sufficient /lib/security/$ISA/pam_unix.so
password required /lib/security/$ISA/pam_cracklib.so retry=3 type=
password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow
password required /lib/security/$ISA/pam_deny.so
session required /lib/security/$ISA/pam_limits.so
session required /lib/security/$ISA/pam_unix.so
session required /lib/security/pam_mkhomedir.so skel=/etc/skel/ umask=0022
Thursday, July 5, 2007 at 2:02 am
Chris
Hi Scott,
after following your instructions with w2k3 R2 enterprise and fedora core 6, everything works perfectly fine. I was just wondering if it’s possible to set other SPN for a linux computer account without using the ktpass.
For instance, if I have a NFSv4 NetApp NASFiler (OS 7.2.1), I’d need an NFS/fqdn_of_linux_client@REALM principle. I then would use ktpass.exe to map this principle to the computer account like linuxtest01, (or is it DOMAINlinuxtest01$ ?), copy the keytab to my fedora box and merge it there. I have not tried that yet.
So if I have a lot of linux boxes and do not want to first join them via samba, then use ktpass then copy and merge, is it not possible somehow to create the nfs SPN from the linux side? I was thinking of something like kadmin, which unfortunately is not supported by M$ (no open port on 749).
There was a project called “netjoin” on sourceforge, tried, but it threw some “encryption not supported” errors. And on some newsgroup post I think to remember to have read “is not supported for 2003 yet”; and last update to that project was in 2004.
Maybe you have got any ideas?
Cheers, Chris
Thursday, July 5, 2007 at 8:21 am
Chris
Hi again,
I believe to have solved the issue partly.Samba (3.0.24-7) can do exactly what I asked earlier: “net ads keytab add %service%”, in my case “net ads keytab add nfs”. This will work after you have sucessfully joined the machine to your domain.
It will then create for the maschine the principals “%service%/%clienthostname%” and “%service%/fqdn”, where %service% will be automatically uppercased, if necessary.
So in my case it created “NFS/linuxtest01″ and “NFS/linuxtest01.mydomain.local”.
You can test your confgiuration by issuing the command “kvno %service/%clienthostname%” (”kvno nfs/linuxtest01″); it gives back the kvno for that service, if all went well. Then view the ticket with “klist”. By now you should have the requested ticket in your local ticket cache with an expiration date.
Will now try to get an NFSv4 mount to a Nasfiler export with security set to krb5, krb5i, krb5p.
Hope that helped…
Chris
Tuesday, July 10, 2007 at 2:03 am
Chris
Hi again…
Since I encountered some minor (*g*) difficulties and had to do some more resolving, I thought I’d post the issues with rpc.gssd here as well. I am assuming that you already created the necessary service principals in the machine account with “net ads keytab add %service%”.
First, you definitely need rpc.gssd (/usr/sbin/rpc.gssd) running. On most systems it will already be activated for levels 3, 4 and 5, but better double check with chkconfig. Unfortunately, it would always fail starting on my box until I found in some list posting the reason: check whether or not you enabled secure nfs in /usr/sysconfig/nfs. There should be a line reading _exactly_ like SECURE_NFS=”yes”. Make sure the case is like shown or it will not work.
Then on every nfs4 mount attempt my rpc.gssd kept writing to the syslog “client ´nfs/linuxtest01.mydomain.local@MYDOMAIN.LOCAL´ not found in kerberos database” and denied access. It means that gssd was not able to find a UserPrincipalName like stated. And no, this does not mean the ServicePrincipalName `nfs/[...]`!
So this is what all the guys are doing when they create a dummy user for each host and each service on that host. See, Active Directory only stores exactly one UPN for each account (be it a machine or a user).
Imo a Windows client uses the current users TGT to request additional service tickets. Gssd does not. It requests a TGT for the _machine_ and does not take an already present TGT from a user to request the nfs service ticket. And since a machine cannot enter a password on its own, you will need to create a keytab entry for the machine account with the secret password already stored.
So basically, to get nfsv4 working with AD, you have (imo) three options:
1. Windows User account
- Create a new windows user account (machine account also possible, imo)
- Name it %service%%Client_machine_name% (uppercase first char of client machine name); name in given name, login and prew2k login (basically, the name does not matter, but this convention kinda convinced me)
- any password (you will reset it later anyway)
- use ktpass command line client to map ‘%service%/%fqdn%@DOMAIN.TLD’ to the user just created (%service%%Client_machine_name%) and to create a unix keytab file. See instructions here in the blog (sorry, don’t remember where exactly).
- copy and import the keytab into you linux machine
This is only practicable for few linux boxes and few services, since automatism would involve a batch script running under at least domain administrator priviliges on the server to create the keytabs everytime a new computer is joined to the domain and ssh with root access on every client. You may not want that and I didn’t try this way.
2. ADSIEDIT
- When you’ve joined your machine with “net ads join” and you’re sure that you don’t need samba again, you can manually (or with a batch script) rename the machine account’s UserPrincipalName (usually “HOST/%client_machine_name%@DOMAIN.TLD”) to the nfs principal “nfs/%fqdn%@DOMAIN.TLD”. Please note: most likely any “net ads *” commands will fail afterwards!
ps: The UPN “HOST/*” will be set by samba automatically when using net ads join…
I tried this way, and it workes (except for samba domain commands afterwards :p)
ps2: When you edit the machine’s UPN in AD, the keyentry in the machine’s local keytab will still be valid. But _never_ use the feature “reset machine account”. You’d have to delete the account and join the domain again.
3. Hack rpc.gssd
- Modify the source to take the machine UPN created by default by samba which would be “HOST/%client_machine_name%@DOMAIN.TLD” instead of the gssd default “nfs/%fqdn%@DOMAIN.TLD”.
Remember: if you have a large number of clients, you’d have to spread the new gssd to all these machines. Did not try it yet, so do not have a clue how much work it is.
if I got something wrong, please set it right
thanks, Chris
Tuesday, July 17, 2007 at 8:09 am
Matt Evans
Thanks for the great writeup. I could get everything working but actual users couldn’t log in. Looks like the LDAP config on Windows 2003 R2 and on my CentOS box was missing. Everything is working perfectly now.
Thursday, July 19, 2007 at 6:44 am
Aram
Thanks a lot for the great article.
There’s just one thing I don’t understand, why would I need the linux server to actually join the AD domain? I got through this tutorial to that section, and I can authenticate the users just fine without it… Although I do have a problem with NFS on AD (I’m getting the 4294967294 uid) but I don’t think that’s related. Is that step necessary?
Note to Matt Evans: “getent passwd” doesn’t get you the AD users? Check /etc/libnss-ldap.conf if you have the correct login information to bind to the server. I used http://www.jxplorer.org/ to make sure that I can browse AD.
Thursday, July 19, 2007 at 12:48 pm
slowe
Aram,
Technically, you don’t, and I’ve alluded to that in previous articles. The joining of the Linux server to the AD domain enables TGT validation, so that the Linux server can be assured that the TGT it received is really from the KDC that it claims to be from–it’s part of the Kerberos spec to help ensure that no spoofing is going on anywhere within the process. Without TGT validation, you can authenticate users all day long and not join the Linux server to the domain. With TGT validation, I think you’ll find that authentication will fail without an object in the domain that hosts the SPN (Service Principal Name) for your Linux server.
In addition, if you ever wanted to leverage the Kerberos authentication on your Linux server for stuff like Samba, Apache, etc., you’ll end up needing objects in AD to represent those SPNs as well.
Hope this helps!
Monday, July 30, 2007 at 12:13 pm
Jackie
Hi,
I am fairly new to LDAP and AD but I am assigned by my manager to get the AD-Linux integrated in our lab. However I don’t quite understand about “create an account in AD that will be used to bind to AD for LDAP queries”.
Can any of you help me out here? Thanks a lot.
Regards,
Jackie
Monday, July 30, 2007 at 1:38 pm
slowe
Jackie,
Active Directory does not, by default, allow unauthenticated LDAP queries. Therefore, you need an account that your Linux servers can use to authenticate against AD for the purposes of conducting LDAP queries. This is referred to as “binding to LDAP”. You need to create a user account (no special privileges required; in fact, you can make it a guest account) and then specify that account for your LDAP clients to use when performing queries.
Hope this helps!
Wednesday, August 1, 2007 at 10:50 am
Jackie
Hi Slowe,
Thank you very much for your information.
Once I have the account created, how can I specify that account for the LDAP clients (which will be a number of Linux and Solaris boxes) to use when performing queries?
I also have a question, do all the windows machines have to be in the same domain/workgroup with all the Linux boxes?
In the website, it uses EXAMPLE.com, host.example.com, dc=example, etc to describe how this whole thing can be setup. Would you mind giving me a bit more specific example?
eg. the hostname of my windows machine is win123.intranet.prod.com
the hostname of my linux server is redhat123.intranettest.prodtest.com
and the FQDN of the AD server is intranettest.prodtest.com
I apologise if this is too much to ask.
Thank you very much for your help again.
Regards,
Jackie
Wednesday, August 1, 2007 at 9:13 pm
slowe
Jackie,
Refer to step #5 in the arrticle on configuring the nss_ldap libraries to use the account you created. There is similar information in the Solaris integration article(s).
As for domains, you’ll just need to map your DNS domains to the Kerberos realms. The Kerberos realms will always be the DNS name of your AD domain in UPPERCASE. Refer to the [domain_realm] section of krb5.conf (as described in step #4 above) for more information.
Hope this helps!
Friday, August 3, 2007 at 6:02 am
Jackie
Hi Scott,
thanks again for your help.
I tried and I am still struggling with getting the whole thing works. Here are my questions:
1. I am running MS Server 2003 R2, enterprise x64 edition, service pack 2, how can I tell if my server is using SFU 3.5 or a newer schema?
2. do my AD server and the linux machine have to be in the same domain? e.g. the FQDN of my AD server is intranettest.prodtest.com and the DN of my linux box is intranet.dev.com, will it work?
3. To create an account in AD to bind to AD for LDAP queries, do you mean an account for my linux box?
4. is it necessary to have my unix LDAP userid and password the same as my AD userid and password? (mine are different)
Regards,
Jackie
Friday, August 3, 2007 at 7:07 am
slowe
Jackie,
Let’s move this conversation to e-mail, that may make it a bit easier to address some of your questions. You can reach me via scott dot lowe at scottlowe dot org.
Saturday, August 4, 2007 at 8:52 am
Jackie
Hi Scott,
Thanks a lot.
Regards,
Jackie
Tuesday, August 14, 2007 at 8:06 pm
Mel
Can you put a note in the section, “Test the Configuration” indicating that when you enter the kinit command that the domain name must be in ALL CAPS for it to work. That may help some of us (grin).
Tuesday, August 14, 2007 at 11:52 pm
slowe
Mel,
I’ll double-check that. I don’t recall having to even enter the domain name, but it makes sense that it would work that way (since kinit would treat the domain name as a Kerberos realm, which must be in UPPERCASE).
Thanks!
Thursday, August 16, 2007 at 11:24 am
Ian
Hi Scott,
I’ve been attempting to get AD working with both Linux and Solaris 10, and I’ve successfully done so for authentication and session management. (session == account information, just to be clear.) But, every time I attempt a kpasswd change against AD, from both Solaris and Linux, I get “Password change rejected.” I’ve also tried plain old “passwd’ from Linux, since it uses PAM properly to pass it off to krb5 (Solaris doesn’t want to see to do this properly yet.) and I get “Soft Error: Password Change Rejected ()” from it. I’ve checked my AD and all policy entries are disabled for the Password Policy. There is no minimum age or length, and no maximum age, either (I.E. indefinite use of passwords.) I can’t figure out what else might be blocking the password change. I’ve also checked all across Google, and nothing comes close to this type of issue. Would you have any ideas?
Ian
Thursday, August 16, 2007 at 12:02 pm
Ian
Hi Scott,
I figured it out. The domain policy was set to NOT allowed local logins (by default, no less!) and that was causing the system to reject any password changes, as I guess it treated changing your password like logging in locally to the system. I guess thats something for future readers.
Ian
Thursday, August 23, 2007 at 5:01 am
Jackie
Hi everyone,
I finally got my linux server configured to authenticate against AD. Thanks for Scott’s help, I really appreciate it.
Now I just have one question. after my server is configured to authenticate against AD instead of LDAP, some users who have an LDAP account and used to be able to logon to the box can no longer logon to the server because their accounts are not in AD but just LDAP. By any chance, this can be fixed? I mean is it possible to authenticate against AD first and then LDAP if account doesn’t exist in AD?
Also if the same user has different id and password in AD and LDAP, is there any mapping mechanism can be used?
Cheers,
Jackie
Tuesday, August 28, 2