Linux-AD Integration, Version 4

Monday, January 15, 2007 in Interoperability, Linux, Microsoft by slowe | 177 comments

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 [email protected]
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

177 comments

Comments feed for this article

Trackback link: http://blog.scottlowe.org/2007/01/15/linux-ad-integration-version-4/trackback/

Pingback from Red Hat » Linux-AD Integration, Version 4 on Monday, January 15, 2007 at 4:12 pm
Pingback from Planeta CentOS » Linux-AD Integration, Version 4 on Monday, January 15, 2007 at 4:52 pm
Paul on Wednesday, January 17, 2007 at 4:21 pm

Hello
Net ads join is working OK on my Ubuntu, is it possible to do it on Solaris 10 ? How dou you think ?
slowe on Wednesday, January 17, 2007 at 6:11 pm

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
steve on Thursday, February 1, 2007 at 12:35 pm

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.
slowe on Thursday, February 1, 2007 at 1:20 pm

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
ron terren on Tuesday, February 6, 2007 at 1:01 am

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
slowe on Tuesday, February 6, 2007 at 9:57 pm

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
Leonard on Tuesday, February 13, 2007 at 3:39 pm

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
slowe on Tuesday, February 13, 2007 at 4:15 pm

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
Nico on Thursday, February 15, 2007 at 5:55 am

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
slowe on Thursday, February 15, 2007 at 9:15 am

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
John on Thursday, February 22, 2007 at 10:14 am

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?
slowe on Thursday, February 22, 2007 at 12:39 pm

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.
John on Thursday, February 22, 2007 at 3:29 pm

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.
slowe on Thursday, February 22, 2007 at 4:49 pm

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.
John on Thursday, February 22, 2007 at 5:08 pm

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?
slowe on Thursday, February 22, 2007 at 7:30 pm

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.
Ryan on Tuesday, February 27, 2007 at 10:10 am

Scott,

Any new update on password management ? Thanks.
slowe on Tuesday, February 27, 2007 at 7:41 pm

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
JS on Thursday, March 8, 2007 at 1:28 pm

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?
Alexey on Monday, March 12, 2007 at 9:47 am

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 [email protected]:
Password expired. You must change it now.

Access denied
Using keyboard-interactive authentication.
Password for [email protected]:

I can’t change password. Why?
Sean on Monday, March 12, 2007 at 7:33 pm

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.
Sean on Monday, March 12, 2007 at 7:33 pm

JS, would you be so kind as to share what information you used to get SSO working? Thanks, Sean
slowe on Monday, March 12, 2007 at 10:10 pm

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!
CS on Wednesday, March 14, 2007 at 2:18 am

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
slowe on Wednesday, March 14, 2007 at 6:56 pm

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.
CS on Wednesday, March 14, 2007 at 9:59 pm

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…)
slowe on Thursday, March 15, 2007 at 9:12 pm

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?
CS on Friday, March 16, 2007 at 12:47 am

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
slowe on Friday, March 16, 2007 at 5:33 am

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
Shannon VanWagner on Friday, March 16, 2007 at 2:22 pm

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
slowe on Friday, March 16, 2007 at 10:27 pm

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
Shannon VanWagner on Tuesday, March 20, 2007 at 9:20 am

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!
Shannon VanWagner on Tuesday, March 20, 2007 at 9:36 am

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!!
Shannon VanWagner on Tuesday, March 20, 2007 at 10:07 am

*****************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!
Shannon VanWagner on Tuesday, March 20, 2007 at 10:08 am

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
slowe on Tuesday, March 20, 2007 at 8:59 pm

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.
Shannon VanWagner on Thursday, March 22, 2007 at 1:01 am

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)
alaxa on Thursday, March 22, 2007 at 12:38 pm

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
Taras S. on Saturday, March 24, 2007 at 9:37 pm

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).
slowe on Friday, March 30, 2007 at 10:32 am

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.
McDouglas on Friday, April 6, 2007 at 3:48 am

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.
slowe on Friday, April 6, 2007 at 7:36 am

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.
McDouglas on Monday, April 9, 2007 at 6:59 am

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 [email protected]
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
slowe on Monday, April 9, 2007 at 2:59 pm

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.
McDouglas on Monday, April 9, 2007 at 3:08 pm

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.
McDouglas on Tuesday, April 10, 2007 at 2:38 am

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?
McDouglas on Tuesday, April 10, 2007 at 2:48 am

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?
slowe on Tuesday, April 10, 2007 at 8:54 am

McDouglas,

What is being reported in the system logs? Anything?