ActiveDirectory

You are currently browsing articles tagged ActiveDirectory.

Semi-Automatic Security Groups

One really cool feature of Exchange Server 2003 is query-based distribution groups.  This feature allows organizations to define LDAP queries and then dynamically populate distribution groups based on the results of the LDAP query.  Unfortunately, there’s no built-in equivalent for security groups, but here’s a reasonable workaround to create that same kind of functionality.

Using the Dsquery and dsmod tools in Windows Server 2003, we can create a command that issues an LDAP query, then stuffs the result of that LDAP query into an already-existing security group.  Here’s how it works.

First, we use the “dsquery *” command, which allows us to define a custom LDAP query to find any kind of object within Active Directory.  Let’s say we are interested in automatically populating departmental security groups based on the department attribute for each user object.  To find all the members of the Engineering group in Atlanta, we’d use a command like this (this has been broken into three lines for readability, but should be typed in as a single line):

dsquery * ou=Users,ou=Atlanta,ou=Locations,dc=example,dc=net
-filter “(&(objectcategory=person)(objectclass=user)
(department=Engineering))” -limit 1000

This command will return the DNs of those user objects in the Locations/Atlanta/Users OU whose department attribute is set to Engineering.  We can then pipe that output to the Dsmod command, like so (again, lines have been broken for readability but this should be entered as a single line):

dsquery * ou=Users,ou=Atlanta,ou=Locations,dc=example,dc=net
-filter “(&(objectcategory=person)(objectclass=user)
(department=Engineering))” -limit 1000 | dsmod group “cn=Atlanta
Engineering Dept,ou=Groups,ou=Atlanta,ou=Locations,
dc=example,dc=net” -addmbr

This command takes the output of the Dsquery command and pipes it to the Dsmod command, modifying the group named Atlanta Engineering Dept in the Locations/Atlanta/Groups OU.  (If you anticipate more than 1,000 users in Atlanta in the Engineering department, adjust the “-limit” parameter accordingly.)

There’s a couple of problems, however.  Once the command has run once, then subsequent times will generate an error because the users will already be a member of that group.  In addition, this command doesn’t take into account those users who have left the Engineering group.  To fix this, we need a couple more commands.

First, we get the members of the group using the Dsget command:

dsget group “cn=Atlanta Engineering Dept,ou=Groups,
ou=Atlanta,ou=Locations,dc=example,dc=net” -members

This returns a list of the DNs for those users that are currently members of the specified group.  We pipe that to the Dsmod command again to clear the group out:

dsget group “cn=Atlanta Engineering Dept,ou=Groups,
ou=Atlanta,ou=Locations,dc=example,dc=net” -members | dsmod group
“cn=Atlanta Engineering Dept,ou=Groups,ou=Atlanta,ou=Locations,
dc=example,dc=net” -rmmbr

This command sequence removes all the current members of the group.  Run this command before the Dsquery, and both problems (the error about users already being a member and “stale” members not being removed) are corrected.

By wrapping these commands into a batch file and then scheduling the batch file to run on a regular interval (an interval to be determined by your organization), you have created semi-automatic security groups that will repopulate every time this command runs.

There are some caveats, of course.  Since groups memberships are only updated on the access token when a user logs out and logs back in again, the changes to the group membership won’t take effect immediately.  For this reason, it’s probably best to only run these scripts once a day during the off hours.  Second, this technique is only effective if your organization is making sure the information in Active Directory is up-to-date (of course).

Tags: , , ,

A short while ago, I published an entry discussing the integration of VMware ESX Server with Active Directory for the authentication of virtual machine management.  In that entry, I noted that I had not created a keytab as part of the configuration of Kerberos authentication.  I was curious as to why it worked, so I did some research.  Here’s what I found.

Seeking expertise, I started a thread on the comp.protocols.kerberos Usenet group about the presence or absence of the keytab, and its impact on the operation of pam_krb5 for authentication.  Based on the feedback received there, the keytab should be used to protect against a KDC spoofing attack, i.e., to verify the identity of the KDC against which pam_krb5 is attempting to authenticate and retrieve tickets.  Richard E. Silverman (of “Secure Shell: The Definitive Guide” fame) stated:

pam_krb5 verifies your password against Kerberos, right? In that case, there *should* be a keytab, due to the issue alluded to earlier in this thread: the module should obtain a host ticket to defend against a KDC spoofing attack. If it let you in without that, perhaps there’s a “verify KDC” option that’s turned off (and ideally, should be turned on).

With that in mind, I set out to see if pam_krb5 supported just such an option.  According to this pam_krb5 man page, there is a “validate” option that is supposed to force pam_krb5.so to “verify that the TGT obtained from the realm’s servers has not been spoofed.  Note that the process which is performing authentication must be able to read the keytab in order for validation to be possible.”

However, even with this option set (and the permissions set on the keytab so that it is readable by any user), this validation still did not take place (as evidenced by the fact that pam_krb5 still authenticated users against Active Directory even when the keytab wasn’t present).  The presence or absence of the keytab did not appear to affect the operation of pam_krb5 in any way.

Russ Alberry added this comment in the Usenet thread:

The pam_krb5 modules that I’ve used either don’t do this or only do this when the keytab is available, presumably doing a security vs. ease of deployment tradeoff.

So, apparently, even though the option is there, pam_krb5 still doesn’t perform validation of the TGT to ensure that the KDC wasn’t spoofed.

To test all of this, I used a freshly-built server running CentOS 4.3 and pam_krb5.  The server was authenticating against Active Directory running on Windows Server 2003 R2, where a computer account had been created and a principal mapped to that account using ktpass.exe.  The keytab generated by ktpass.exe was securely copied over to the Linux server and placed in the “/etc” directory as krb5.keytab.  Initially, only root had any permissions on the file, but read permissions were added later to see if that affected the behavior of the Kerberos module.

The final answer still remains unknown.  The man page for pam_krb5.so module indicates that the validate option should force the behavior we are seeking; but the tests that I’ve conducted so far don’t support that statement.  I plan to conduct additional tests and more research to see what other information I can uncover.

In the meantime, any Kerberos experts out there are invited to add their comments to this article and share any additional information.

Tags: , , , , , ,

Late last year, I published an entry that described a method for making mass password changes in Active Directory.  After some additional work on the topic, I have found a much better way of accomplishing the same thing.

In my previous example, I used ldifde to extract information from Active Directory.  Unfortunately, that information was a bit too complete, and it included fields and attributes that we didn’t need.  As a result, we had to parse down the ldifde output and remove everything except the DN field.

I have since discovered the use of the dsquery command, which will output DNs for objects easily from a single command:

dsquery user ou=Accounts,dc=testlab,dc=net

This command will produce a list of DNs for all users in the Accounts OU of the testlab.net AD domain.  Appending a “ > filename” to the command would redirect the output into a file that could be used later.  One caveat to this command:  be sure to use the “limit -XXX” parameter if there are more than 100 objects that you are trying to enumerate.  Otherwise, you’ll get only the first 100 objects.

Instead of redirecting the output of this command to a file we can pipe it to another command, such as dsmod:

dsquery user ou=Accounts,dc=testlab,dc=net |
dsmod user -pwd newpass1 -mustchpwd yes

This command will query all the users in the Accounts OU of the testlab.net AD domain, then set their passwords to “newpass1” and force a password change at next logon.  (Although this command is shown on two lines above, it should all be entered as a single line.)

Note that these commands work equally well against Active Directory domains running both Windows 2000 and Windows Server 2003.

Tags: , ,

The issue I described in my original post regarding upgrading the schema to support Windows Server 2003 R2 as a domain controller is getting more attention.

Jorge de Almeida Pinto, a Windows Server MVP, has created his own blog entry about the need to use ADPrep.exe from the second CD, and has also pointed out that Microsoft has created a Knowledge Base article about the problem as well:

Error message when you run the Active Directory Installation Wizard: “The version of the Active Directory schema of the source forest is not compatible with the version of Active Directory on this computer”
<http://support.microsoft.com/?kbid=917385>

Have a look at Jorge’s full weblog entry, as he lists some other helpful information as well.

Tags: , ,

Another interesting thread on the microsoft.public.windows.server.general newsgroup has turned up an issue with running Windows Server 2003 R2 as a member server.

First of all, many thanks to Jabez Gan, a Windows Server 2003 MVP, for his assistance in clearly defining the scope of this situation.  Jabez Gan’s weblog is found at http://www.msblog.org/.

It would seem that if you are going to deploy Windows Server 2003 R2 as a member server in a domain that is not running Windows Server 2003 R2 as domain controllers, there are still times when the Active Directory schema must be upgraded.  This is a bit unusual, since the addition of newer versions of Windows Server to a domain has typically not required this (think of adding Windows 2000 to a Windows NT domain, or adding Windows Server 2003—not R2—to a Windows 2000-based Active Directory domain).

So, the Active Directory schema will have to be extended if you are planning on deploying any of the following services on a Windows Server 2003 R2-based member server and you are not running Windows Server 2003 R2 on the DCs:

  • DFS Replication
  • Print Management Console
  • File Server Resource Management

Jabez also mentioned UNIX Identity Management, but it seems like that can only be deployed on domain controllers anyway (that’s definitely true for Server for NIS).  However, in the event that UNIX Identity Management can be deployed to member servers, that will require a schema extension as well.

In summary, if you are planning on deploying some of the newer features of Windows Server 2003 R2 in a domain that is not running Windows Server 2003 R2 on the domain controllers, you may have to extend the Active Directory schema anyway.  Be sure to plan and prepare accordingly.

Tags: , ,

Having successfully mapped out the steps for Linux/Unix-based hosts to authenticate against Active Directory on Windows Server 2003 R2 (get the complete details), I now turned my sights toward integrating authentication on ESX Server 2.5.3 with Active Directory as well.

Using instructions found in this technical white paper from VMware’s web site, I started out by modifying the /etc/krb5.conf file, which controls the operation of the Kerberos libraries in the Console Operating System (COS). The contents of the /etc/krb5.conf file should look something like this:

[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 ticket_lifetime = 24000
 default_realm = EXAMPLE.NET
 dns_lookup_realm = false
 dns_lookup_kdc = false

[realms]
 EXAMPLE.NET = {
  kdc = addc01.example.net:88
  admin_server = addc01.example.net:749
  default_domain = example.net
 }

[domain_realm]
 .example.net = EXAMPLE.NET
 example.net = EXAMPLE.NET

[kdc]
 profile = /var/kerberos/krb5kdc/kdc.conf

[pam]
 debug = false
 ticket_lifetime = 36000
 renew_lifetime = 36000
 forwardable = true
 krb4_convert = false

As you may already be aware, you can change the “dns_lookup_realm” and “dns_lookup_kdc” directives to true and omit the “[realms]” section, assuming that your Active Directory DNS infrastructure has the properly registered SRV records for the domain controllers.

The VMware white paper then instructed to modify the /var/kerberos/krb5kdc/kdc.conf file, but I had never performed any edits to that file in my earlier experiments, so I decided to forgo that step.  It is my understanding that this file controls the behavior of a Key Distribution Center (KDC), which the COS is not (in this instance, the KDC is the Active Directory domain controller).

Next, I edited the vmware-authd file in /etc/pam.d, which connects the vmware-authd daemon to the PAM modules for authentication.  After the edits, the /etc/pam.d/vmware-authd file looked like this:

#%PAM-1.0
auth       sufficient   /lib/security/pam_unix_auth.so shadow nullok
auth       required     /lib/security/pam_krb5.so use_first_pass
account    required     /lib/security/pam_unix_acct.so

Finally, still following the instructions, I created a user account on the ESX Server (using the useradd command there in the COS) that matched the username of an account in Active Directory.  At this point, I was ready to test connectivity.

(Those of you that have read the other articles on Kerberos/LDAP integration of Linux into Active Directory will note that I did not create a computer object, use ktpass.exe to create a keytab, nor did I configure ldap.conf with the attribute mapping.  I can’t explain why I don’t need a computer object or a keytab yet—rest assured I will get the bottom of that—but the LDAP pieces aren’t necessary because we are relying on the presence of the accounts locally and only using Kerberos for authentication.  This has some advantages and some disadvantages, which I’ll discuss in more detail later.)

The first test (performing by trying to log into the VMware ESX Server MUI using the account created above) failed; /var/log/messages indicated a problem with host resolution.  That problem was easily resolved with a quick edit of /etc/resolv.conf.

The next test also failed; again, /var/log/messages held the answer:  too great of a time skew between the ESX Server and the Active Directory domain controller.  The date command fixed that right up, and we were ready to test again.

The third time was the charm.  Using an account that existed locally (but for which no password had been set) as well as in Active Directory, I was able to log in to the MUI using the Active Directory password.  A quick test with another Active Directory account that did not have a matching local account failed (as expected), indicating that it was working as expected.

I learned a couple of useful tidbits from this experiment.  First, it seems viable that organizations may wish to use Kerberos for authentication to their Linux-based hosts but not use LDAP for account information, instead requiring that local accounts exist on each system (like in this situation).  This bears the advantage that the organization has more granular control over which specific Linux/Unix hosts may be used (i.e., no logins will succeed if a local account does not exist); that granularity does not exist if using LDAP for account information.  However, the corresponding disadvantage of this approach is that local accounts must be managed on each separate host.

Second, I learned that a computer object (and the whole ktpass.exe command to generate the keytab) may not be necessary; I’m going to go back and perform some additional testing to see if that is the case.  More information will be posted here as soon as it is available.

Tags: , , , ,

UPDATE:  An updated version of these instructions has been posted.

The integration of (what was formerly called) Services for UNIX into Windows Server 2003 R2 also brought some other changes.  To accommodate those changes, I’ve updated my Linux-AD integration instructions (the previous instructions are here for pre-R2 versions of Windows).  If you need to integrate Linux systems for authentication into Active Directory with Windows Server 2003 R2, these instructions should get you there.

Overall, the instructions are very similar to the instructions for pre-R2 versions of Windows.

Preparing Active Directory (One-Time)

Based on what I’ve seen so far, it appears as if a partial RFC 2307-compliant schema is included by default with Windows Server 2003 R2.  This means that it is no longer necessary to extend the schema to include attributes such as uid, gid, login shell, etc.  However, while the schema does appear to be present by default, you must install the “Server for NIS” component on at least one domain controller in order to be able to actually set those attributes (and it will be necessary to set the attributes before logins from Linux will work).

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.

Preparing 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 perform the additional tasks within Active Directory and on the Linux server that will enable the authentication.

Preparing Active Directory (Each Server)

For each Linux-based server that will be authenticating against Active Directory, follow the steps below.

  1. Create a computer account in Active Directory.  When creating the computer account, be sure to specify that this account may be used by a pre-Windows 2000–based computer.
  2. Use the following command at a command prompt to configure the new computer account:
    ktpass -princ host/fqdn@REALM -mapuser DOMAIN\name$
    -crypto DES-CBC-MD5 -pass password -ptype KRB5_NT_PRINCIPAL
    -out filename

    Of course, you’ll need to substitute the appropriate values for “fqdn” (the fully-qualified domain name of the computer), “REALM” (the DNS name of your Active Directory domain in UPPERCASE), “DOMAIN” (the NetBIOS name of your Active Directory domain), “password” (the password that will be set for the new computer account), and “filename” (the keytab that will be generated and must be copied over to the Linux computer).

If you need to rebuild the Linux server for whatever reason, you’ll need to delete the computer account you created and repeat this process.

Preparing Each Linux Server

Follow the steps below to configure the Linux server for authentication against Active Directory.

  1. Make sure that the appropriate Kerberos libraries, OpenLDAP, pam_krb5, and nss_ldap are installed.  If they are not installed, install them.
  2. Be sure that time is being properly synchronized between Active Directory and the Linux server in question.  Kerberos requires time synchronization.
  3. Edit the 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
     }
  4. 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.
    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=example,dc=com?sub
    nss_map_objectclass posixAccount user
    nss_map_objectclass shadowAccount user
    nss_map_objectclass posixGroup group
    nss_map_attribute gecos name
    nss_map_attribute homeDirectory unixHomeDirectory
    nss_map_attribute uniqueMember member
  5. Securely copy the file created using the ktpass.exe utility above to the Linux server in question, placing it in the /etc directory as krb5.keytab.  (SFTP or SCP are excellent candidates for this.)
  6. 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.
  7. Edit the /etc/nsswitch.conf file to include “ldap” as a lookup source for passwd, shadow, and groups.

That should be it.  Once you do that, you should be able to use kinit from a Linux shell prompt (for example, “kinit aduser”) and generate a valid Kerberos ticket for the specified Active Directory account.

At this point, any PAM-aware service that is configured to use the stacked system file (such as the system-auth configuration on Red Hat-based distributions) will use Active Directory for authentication.  Note, however, that unless you also add the pam_mkhomedir.so module in the PAM configuration, home directories will have to be created manually for any Active Directory account that may log on to that server.  (I generally recommend the use of pam_mkhomedir.so in this situation.)

This configuration was tested on Red Hat Linux 9.0 as well as CentOS 4.3.

Tags: , , , , , , , ,

Windows Server 2003 R2 Schema

I came across this little tidbit on the Microsoft public newsgroups for Windows Server 2003 R2.  It concerns adding a Windows Server 2003 R2 domain controller to an existing Windows 2000-based Active Directory domain.

Most of you are probably aware that before you can add a Windows Server 2003-based domain controller to a Windows 2000-based Active Directory domain, you must extend the Active Directory schema using ADPrep.  So far, so good.

Some of you may also be aware that Windows Server 2003 R2 is really nothing more than Windows Server 2003 with SP1 and some additional components.  In fact, if you don’t run the setup on CD 2 of the 2-disc set for Windows Server 2003 R2, you end up with Windows Server 2003 with SP1.  You have to install the second disc in order to get R2.  OK, still with me?

Here’s the kicker.  In order to add a Windows Server 2003 R2 to a Windows 2000-based Active Directory domain, you must run ADPrep from the second disc, not the first disc.  There is still an ADPrep.exe on the first disc, but it doesn’t extend the schema far enough to support R2.  So, unsuspecting admins install R2, run ADPrep from the first CD, then try to run DCPromo and get an error regarding the schema.  However, running ADPrep from the second disc will extend the schema properly and allow DCPromo to complete.

Tags: , ,

Mac OS X and .local Domains

Some time ago, Mac OS X Hints published a hint I submitted regarding the use of the .local TLD (top level domain) with Mac OS X.  Specifically, the hint centered around the use of Mac OS X with Active Directory domains using the .local TLD.  For ease of access, here’s that same hint.

Basically, Mac OS X uses the .local TLD for Bonjour/Rendezvous services, and is configured to use multicast DNS (mDNS) for discovery of those services.  This configuration occurs via a file named “local” in the /etc/resolver directory.  Apple’s Knowledge Base article offers a solution, but that solution involves editing this “local” file, which affects Bonjour/Rendezvous operation.  This solution, on the other hand, does not affect the “local” file in any way, and thus does not interfere with Bonjour/Rendezvous.

Let’s say that you need to integrate Mac OS X with an Active Directory domain called company.local.  Simply create a file in /etc/resolver named “company.local” with the following contents:

nameserver a.b.c.d
nameserver w.x.y.z
port 53

Obviously, replace the letters in the text above with the IP addresses of your appropriate DNS servers for the company.local Active Directory domain.  Then, flush the lookupd cache with “lookupd -flushcache” and that’s it!

With this file in place, your Mac OS X system will resolve company.local (or subdomain.company.local) via the instructions in the file /etc/resolver/company.local, but will handle Bonjour/Rendezvous service discovery via mDNS in the same fashion.

Tags: , , , , , ,

UPDATE:  These instructions are for Windows 2000 Server and Windows Server 2003 pre-R2.  For the R2 release, please see these updated instructions.

There are several articles posted here that discuss, in general terms, how to authenticate Linux against Active Directory.  For example, see this brief article on the broad direction of the integration, or this posting on using computer accounts for Linux servers (most how-to documents I’ve seen discuss the use of a user account for this purpose).

Over the last week or so, I’ve been having to rebuild one Linux server a number of times in an effort to fix a separate problem (see this article on NTPd problems with CentOS 4.1 and the recurrence of the problem with CentOS 4.2).  As a result, I’ve had to go through the process of configuring this Linux server (and preparing Active Directory) for authentication several times, and I found that I kept having to go back to my scattered and dispersed notes to remember what had to be done.  In the hopes of correcting that, I am collecting all the pertinent information I have here in this article.

Preparing Active Directory (One-Time)

There is a one-time preparation of Active Directory that is required.  In order to authenticate Linux logins against Active Directory, Active Directory’s schema must be extended to include Linux-specific attributes such as home directory, UID, GID, and default shell.  There are a couple of different ways to do this; I chose to use Microsoft’s Services for Unix (SFU) to extend the schema.  There are two reasons I chose SFU: 1) it’s free; and 2) the SFU schema is being included by default in Windows Server 2003 R2.

Once SFU has been installed and the schema has been extended, then the specific Active Directory accounts that are allowed to 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.

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.

After all the user accounts have been configured, then we are ready to perform the additional tasks within Active Directory and on the Linux server that will enable the authentication.

Preparing Active Directory (Each Server)

For each server that will be authenticating against Active Directory, follow the steps below.

  1. Create a computer account in Active Directory.  When creating the computer account, be sure to specify that this account may be used by a pre-Windows 2000–based computer.
  2. Use the following command at a command prompt to configure the new computer account:
    ktpass -princ host/fqdn@REALM -mapuser DOMAIN\name$
    -crypto DES-CBC-MD5 -pass password -ptype KRB5_NT_PRINCIPAL
    -out filename

    Of course, you’ll need to substitute the appropriate values for “fqdn” (the fully-qualified domain name of the computer), “REALM” (the DNS name of your Active Directory domain in UPPERCASE), “DOMAIN” (the NetBIOS name of your Active Directory domain), “password” (the password that will be set for the new computer account), and “filename” (the keytab that will be generated and must be copied over to the Linux computer).

If you need to rebuild the Linux server for whatever reason, you’ll need to delete the computer account you created and repeat this process.

Preparing the Linux Server

Follow the steps below to configure the Linux server for authentication against Active Directory.

  1. Make sure that the appropriate Kerberos libraries, OpenLDAP, pam_krb5, and nss_ldap are installed.  If they are not installed, install them.
  2. Be sure that time is being properly synchronized between Active Directory and the Linux server in question.  Kerberos requires time synchronization.
  3. Edit the 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
    }
  4. 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.
    host 10.10.10.10
    base dc=example,dc=com
    binddn cn=ldap,cn=Users,dc=example,dc=com
    bindpw adldapbindpw
    scope sub
    ssl no
    nss_base_passwd dc=example,dc=com
    nss_base_shadow dc=example,dc=com
    nss_base_group dc=example,dc=com
    nss_map_objectclass posixAccount user
    nss_map_objectclass shadowAccount user
    nss_map_objectclass posixGroup group
    nss_map_attribute uid sAMAccountName
    nss_map_attribute uidNumber msSFU30UidNumber
    nss_map_attribute gidNumber msSFU30GidNumber
    nss_map_attribute loginShell msSFU30LoginShell
    nss_map_attribute gecos name
    nss_map_attribute userPassword msSFU30Password
    nss_map_attribute homeDirectory msSFU30HomeDirectory
    nss_map_attribute uniqueMember msSFU30PosixMember
    nss_map_attribute cn cn
  5. Securely copy the file created using the ktpass.exe utility above to the Linux server in question, placing it in the /etc directory as krb5.keytab.  (SFTP or SCP are excellent candidates for this.)
  6. 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.
  7. Edit the /etc/nsswitch.conf file to include “ldap” as a lookup source for passwd, shadow, and groups.

That should be it.  Once you do that, you should be able to use kinit from a Linux shell prompt (for example, “kinit aduser”) and generate a valid Kerberos ticket for the specified Active Directory account.

At this point, any PAM-aware service that is configured to use the stacked system file (such as the system-auth configuration on Red Hat-based distributions) will use Active Directory for authentication.  Note, however, that unless you also add the pam_mkhomedir.so module in the PAM configuration, home directories will have to be created manually for any Active Directory account that may log on to that server.  (I generally recommend the use of pam_mkhomedir.so in this situation.)

Tags: , , , , , ,

« Older entries § Newer entries »