Integrating Unix into Active Directory while maintaining UNIX style security

Integrating Unix into Active Directory while maintaining UNIX style security

As technology grows IT Administrators are faced with challenges of managing a heterogeneous environment mixed with different operating platforms; Windows, Linux, Apple, etc... especially in business where majority of the infrastructure is Windows and well established Active Directory infrastructure. The challenge with IT is integrating the different systems into a centralized authentication mechanism for user and device management maintaining single sign on for user interoperability for production and corporate applications.

Interoperability with Active Directory and UNIX can be accomplished using different tools and technologies such as Microsoft Services for UNIX (SFU), Centrify, Likewise, and Samba to allow client authentication. Other methods is using LDAP based services for UNIX clients and use an AD connector to replicate or act as an authentication proxy. This document will define the process of integrating completely free solutions using Samba and OpenLDAP while maintaining a true single managed infrastructure using Active Directory and maintaining the ability to continue to use UNIX style security for services relying on UNIX style security such as NFS mounts.

1. Samba and LDAP

Samba is a free interoperability suite for UNIX that allows UNIX systems to integrate with Windows networks providing authentication and shared services such as file and print sharing. Samba provides a good and easily configurable solution out of the box for Linux; in some cases so integrated it's part of the installation process to integrate into Active Directory as an authentication mechanism, and easily obtainable for other UNIX platforms.


One of the challenges facing samba is the ability to have consistent unique UID and GID that follows the user from client to client making securing UNIX systems using UNIX style security difficult and challenging. While, newer beta builds have resolved this issue most administrators are apprehensive on deploying beta software in production environments and most commercially supported UNIX do not distribute out of the box with beta builds.


A solution to UID and GID roaming is to use a LDAP database to store UID and GID maps for Active Directory users and groups using a specified range defined in the Samba client configuration file. When a user logs in it will obtain the first available UID and then that UID is mapped in the LDAP database. When a client access a service that is secured with UNIX style security Samba will reference the UID from the LDAP to the AD account allowing the user to have access.

1.1 Authentication process

When the user logs into a workstation, or authenticates to a service hosted on UNIX, the Samba client authenticates to Active Directory, obtains a Kerberos ticket, and retrieves a UID from the OpenLDAP authentication server. Once authenticated the user can authenticate to shared services on Windows and UNIX Active Directory Domain member servers with Samba services enabled with their active directory account; or UNIX Active Directory domain member servers secured with UNIX style security using their UID and/or GID (See diagrams Fig A, B, and C)


1.2 Centralized management

Unlike other services using LDAP to proxy Active Directory accounts, no management is necessary on the OpenLDAP servers and access to resource allocations are done through Active Directory. Access can be granted using PAM (Pluggable Authentication modules) on UNIX to allow access to the console, SSH, FTP, and other services to security groups in Active Directory providing ease of access management and controlled secured environment through standard account policies.


1.3 High Availability

Active Directory by nature is highly available and as each domain controller is brought into the forest replication is configured automatically. OpenLDAP supports database replication allowing for user accessibility to be obtained in the case of server failures. UNIX clients can be configured to authenticate to multiple authentication servers for both OpenLDAP and Active Directory.


1.4 Operating system

Any UNIX style operating system that supports Kerberos authentication and has Samba ported to it can authenticate to Active Directory and OpenLDAP. This document primarily focuses on Red Hat Linux. However, configuration of PAM, Samba, and Kerberos configuration files should be consistent on all platforms. Consult documentation for paths to configuration files as this could be different on each platform and Linux distributions.

2 Configuring LDAP Server

This server will be the first LDAP server in the enterprise to store UID and GUID mappings to Active Directory accounts.

2.1 Perquisite

  • OpenLDAP 2.3x or later (Stable) installed from your distribution media or downloaded from http://www.openldap.org/software/download/
  • Static IP address configured
  • Hostname defined in DNS
  • Computer account created in Active directory for OpenLDAP Server
  • Samba 3.x or later (Stable) installed from your distribution media or downloaded form http://samba.org

2.2 Configuring Server

2.2.1 Host file

Add the following entries to your host file. Replace Hostname with actual host name of the client and domain.com with the proper domain (Example: JIMMT.COM)

127.0.0.1 hostname.domain.com hostname

127.0.0.1 domain.com domain

2.2.2 Resolv.conf

Ensure that proper search are identified for all domains and proper DNS server(s) are defined in /etc/resolv.conf (Example below)

search jimmt.com

nameserver 192.168.0.1

nameserver 10.0.0.2

2.3 Samba Client

Before we can populate the LDAP database we will configure the Samba client on the OpenLDAP server. There are different ways to setup Samba to authenticate to active directory. Most modern Linux distributions include script or applications to automatically configure the samba configuration, operating system configuration such as PAM, and join to the domain. We will go over the automated process as defined in Red Hat and manual configuration

2.3.1 RedHat (Automated)

  1. Log into Red Hat Enterprise Desktop

  2. Open terminal session and execute system-config-authentication

  3. On the first tab “User Information” select Winbind and click the Configure Winbind button

    1. Enter the Domain name; example JIMMT

    2. Select ADS under “Security model” drop down menu

    3. Enter Fully qualified domain name of the Active Directory realm in “Winbind ADS Realm” Example JIMMT.COM

    4. Select a shell from the “Template Shell” drop down menu

    5. Click ok

  4. Select “Authentication” tab and select Kerberos and click Configure Kerberos button

    1. Enter the fully qualified domain name of the Active Directory in the Realm field; example JIMMT.COM

    2. Enter a fully qualified domain name of a domain controller in the KDC’s and Admin Servers fields; example JIMMTADDC01.JIMMT.COM

    3. Check both Use DNS to resolve hosts to realms and Use DNS to locate KDCs for realms

  5. Select Winbind and click the Configure Winbind button

    1. Verify all information is correct. If not follow step 3 (1 – 5)

  6. Select “Options” tab and check “Create home directories on first login”

  7. Go back to “Authentication” tab and select Winbindand click the Configure Winbind button

    1. Click Join Domain

  8. Click Ok to exit the configuration utility

Validate domain membership

  1. Open terminal session and execute wbinfo –u Should see output of users listed in the domain. Note this could take a long time depending on user database.
  2. In the same terminal session execute kinit user@domain.com
  3. In the same terminal session execute klist -5
  4. If you have any issues please view manual configuration and verify configuration files were updated properly

2.3.1 RedHat and other operating system Manual

NOTE: RedHat was used to document this process. Refer to distribution manual for path to configuration files for other distributions

  1. Rename /etc/samba/smb.conf to smb.conf.bak

  2. Create a new smb.conf file in /etc/samba/ and add the following changing the items in BLUE to match your domain and configuration.

[global]

# The default workgroup

workgroup = JIMMT

# security = ads is used when connecting to Active Directory

security = ads

# The Kerberos domain

realm = JIMMT.COM

encrypt passwords = true

# The ranges for uid and gid assigned to users/groups from Active Directory

idmap uid = 16777216-33554431

idmap gid = 16777216-33554431

# The shell used for users from Active Directory

template shell = /bin/bash

# Let users from the default domain appear as just <username>

winbind use default domain = true

  1. Save configuration file

  2. Rename /etc/krb5.conf to krb5.conf.bak

  3. Create a new krb5.conf file in /etc/ and add the following changing the items in BLUE to match domain and configuration

[logging]

default = FILE:/var/log/krb5libs.log

admin_server = FILE:/var/log/kadmind.log

[libdefaults]

default_realm = JIMMT.COM

dns_lookup_realm = true *Note: If you have issues doing lookups set to false

dns_lookup_kdc = true *Note: if you have issues doing lookups set to false

ticket_lifetime = 24h

forwardable = yes

[realms]

JIMMT.COM = {

#NOTE: You can have more than one KDC and admin_server

kdc = JIMMTADDC01.JIMMT.COM:88

kdc = JIMMTADDC02.JIMMT.COM:88

admin_server = JIMMTADDC01.JIMMT.COM:749

admin_server = JIMMTADDC02.JIMMT.COM:749

default_domain = JIMMT.COM

}

[domain_realm]

.jimmt.com = JIMMT.COM

jimmt.com = JIMMT.COM

[appdefaults]

pam = {

degbug = false

ticket_lifetime = 36000

renew_lifetime = 36000

forwardable = true

krb4_convert = false

}


4. Edit the name switch library configuration file; /etc/nsswitch.conf and modify passwd, shadow, and group to files winbind

passwd: files winbind

shadow: files winbind

group: files winbind

5. Change PAM authentication module to allow winbind authentication. Edit /etc/pam.d/system-auth-ac

  1. Under Authentication (AUTH) add

auth sufficient pam_krb5.so use_first_pass

auth sufficient pam_winbind.so cached_login use_first_pass

2. Under Account change

account required pam_unix.so

to

account required pam_unix.so broken_shadow


3. Under Account Add

account sufficient pam_krb5.so

account sufficient pam_winbind.so cached_login

account sufficient pam_ldap.so


4. Under Password add

password sufficient pam_krb5.so use_authtok

password sufficient pam_winbind.so cached_login use_authtok

5. Under Session add

session optional pam_mkhomedir.so

session optional pam_mkhomedir.so

6. Execute from terminal net ads join –U <site administrator account>

7. Start the winbind service; /sbin/service winbind start

Validate domain membership

  1. Open terminal session and execute wbinfo –u

Should see output of users listed in the domain. Note this could take a long time depending on user database.

[root]# wbinfo -u

Administrator

guest

support_xxxxx

krbtgt

jimmt

smitht

  1. In the same terminal session execute kinit user@DOMAIN.COM.

    When prompted for password enter the password. If successful you will return to the prompt.

  2. In the same terminal session execute klist -5

[root]# klist -5

Ticket cache: FILE:/tmu/krbcc 0

Default principal: jimmt@JIMMT.COM

Valid starting Expires Service principal

11/12/09 16:30:00 11/13/09 02:00:00 krbtgt/JIMMT.COM@JIMMT.COM

renew until 11/13/09 16:30:00

3. If you have any issues please review manual configuration and verify configuration files were updated properly

8. Set winbind to auto-start on boot /sbin/chkconfig winbind on --level 2,3,5

9. Turn off nsc as it conflicts with winbind cache feature; /sbin/chkconfig nscd off

2.4 OpenLDAP

2.4.1 Configuration files

  1. Check where the Openldap slapd.conf configuration file is located. Should be in /etc/openldap or /etc/ldap. Reference this location for configuration settings below and replace /<path to openldap> with the proper path (openldap or ldap)

  2. Make a backup copy of the slapd.conf file in /etc/<path to openldap>

  3. Check /etc/<path to openldap>/schema for samba3.schema or samba.schema

    1. If not found copy from /usr/share/doc/samba-3.x.x/LDAP/ to /etc/<path to openldap>/schema

  4. Create an Administrator password using slappasswd and record the string output

  5. Edit the open LDAP server configuration file slapd.conf found in /etc/<path to openldap>
  6. In the top section add include /etc/<path to openldap>/schema/samba3.schema or /etc/<path to openldap>/schema/samba.schema at the end of the existing include statements

  7. In the top section add include /etc/<path to openldap>/schema/nis.schema (if not already defined) at the end of the existing include statements

  8. After PID and ARG file settings add sizelimit unlimited

  9. Comment out the remaining settings in the file by placing a # in front of each line

  10. At the end of the file add the following statements:

access to dn.base=””

by * read

access to dn.base=”cn=Subschema”

by * read

access to *

by dn=cn=manager,ou=idmap write

database bdb

suffix “ou=idmap”

checkpoint 1024 5

cachesize 10000


rootdn “cn=manager,ou=idmap”

rootpw <password string from slappasswd output>


directory /var/lib/ldap


index objectClass eq

index sambaSID eq

index sambaPrimaryGroupSID eq

index sambaDomainName eq


11. Save the configuration file

12. Change ownership on slapd.conf to ldap:ldap (chown ldap:ldap slapd.conf

13. Stop the LDAP service by executing /sbin/service ldap stop

2.4.2 Database

We need to create a Skelton for the LDAP database and import

  1. Create a new file samba-idmap.ldif

  2. Edit samba-idmap.ldif and add the following:

dn: ou=idmap

objectClass: organizationalUnit

ou: idmap

description: Posix and Samba LDAP Identity Database

dn: cn=manager,ou=idmap

objectClass: organizationalRole

cn: Manager

description: Directory Manager

3. Save the file

4. Copy DB_CONFIG.example to /var/lib/ldap/DB_CONFIG

5. Change ownership of /var/lib/ldap to ldap:ldap (chown -R ldap:ldap /var/lib/ldap)

6. Import the file by executing:

slapadd < /path to samba-idmap.ldif/samba-idmap.ldif

7. Start the LDAP server by executing /sbin/service ldap start * If services fail to start do step 5 again.

8. Verify you can connect to the LDAP server using the password previously set in slapd.conf NOTE: this will be the password given to slappasswd and not the string. Use the following command:

ldapsearch -x -b ou=idmap -h localhost -D cn=manager,ou=idmap -w <password>

If setup properly the output should be similar to this:

# extended LDIF

#

# LDAPv3

# base <ou=idmap> with scope subtree

# filter: (objectclass=*)

# requesting: ALL

#

# idmap

dn: ou=idmap

objectClass: organizationalUnit

objectClass: sambaUnixIdPool

ou: idmap

description: Posix and Samba LDAP Identity Database

# manager, idmap

dn: cn=manager,ou=idmap

objectClass: organizationalRole

cn: Manager

description: Directory Manager

# search result

search: 2

result: 0 Success

# numResponses: 3

# numEntries: 2

9. Set LDAP to start on boot by executing /sbin/chckconfig ldap on --level 2,3,5

2.5 Configuring WINBIND on Master LDAP server

  1. Stop the winbind service by executing /sbin/service winbind stop

  2. Dump the existing winbind database into a textfile by executing

net idmap dump /var/cache/samba/winbindd_idmap.tdb > /tmp/idmap.out

3. Move the files /var/cache/samba/winbindd_idmap.tdb and winbindd_cache.tdb to /var/cache/samba/<name of file>.old

4. Change the idmap backend for winbind to look at the LDAP server by editing /etc/samba/smb.conf by setting the following to the end of the file: (replace ldapserver.domain.com with the proper fully qualified domain name of the ldap server)

idmap backend = ldap:ldap://ldapserver.domain.com

ldap admin dn = cn=manager,ou=idmap

ldap suffix = ou=idmap

5. Set the password for ldap admin dn using the smbpasswd command. This will be the same password that was given to the slappasswd command when setting up the LDAP server

smbpasswd -w <password>

6. Start the winbind service /sbin/service/winbind start
7. Load the idmap dump from Samba into the ldap database by executing *this could take some time

net idmap restore < /tmp/idmap.out

8. Reboot the server

2.5.1 Testing LDAP/Samba

  1. Open another terminal and log in with an Active Directory account; <username> or <domain\username>

    login:jimmt

    Password:

    Last login: Wed July 27 11:30:22 on tty3

    jimmt\jimmt

    Password:

    Last login: Wed July 27 11:30:22 on tty3

  2. Get the UID of a user in the domain by executing getent passwd <username>The output should show username:*:UID:GID:Display Name:<path to home directory>:<shell>. If account has not logged in the home directory path will show the user executing the command.

[jimmt@jimmtldap01]$ getent passwd jimmt

jimmt:*:16777216:16777216:Jim Tessier:/home/JIMMT/jimmt:/bin/bash

Replace passwd with group to show GID of groups. Output will show groupname:*:GID:<group members>

[jimmt@jimmtldap01]$ getent group "Domain Admins"

domain admins:*:16777217:jimmt,administrator

[jimmt@jimmtldap01]$ getent group UnixAdmins

unixadmins:*:16777219:jimmt


3.0 Samba Client configuration

3.1 Samba Client

To setup the UNIX client to authenticate with Active Directory follow the same steps outlined in Chapter 2 Configuring LDAP server section 2.3

3.2 Change SAMBA client to use LDAP for UID/GID mapping

  1. Change the idmap backend for winbind to look at the LDAP server by editing /etc/samba/smb.conf by setting the following to the end of the file: (replace ldapserver.domain.com with the proper fully qualified domain name of the ldap server)

idmap backend = ldap:ldap://ldapserver.domain.com
ldap admin dn = cn=manager,ou=idmap
ldap suffix = ou=idmap

  2. Reboot the client

Testing Client Authentication and UID/GID roaming

  1. Open a terminal and log in with an Active Directory account; <username> or <domain\username>

    login: jimmt

    Password:

    Last login: Wed July 27 11:30:22 on tty3

    login: jimmt\jimmt

    Password:

    Last login: Wed July 27 11:30:22 on tty3

  2. Get the UID of a user in the domain by executing getent passwd <username>The output should show username:*:UID:GID:Display Name:<path to home directory>:<shell>. If account has not logged in the home directory path will show the user executing the command.

[jimmt@client1~]$getent passwd jimmt

jimmt:*:16777216:16777216:Jim Tessier:/home/JIMMT/jimmt:/bin/bash

Replace passwd with group to show GID of groups. Output will show groupname:*:GID:<group members>

[jimmt@client1~]$getent group "Domain Admins"

domain admins:*16777217:jimmt,administrator

[jimmt@client1~]$getent group UnixAdmins

unixadmins:*:16777219:jimmt

3. Compare to the results on the LDAP server to ensure UID and GID match.

3.3 Optional PAM configuration

Depending on your distribution some additional settings to PAM might need to be modified to allow log on such as SSH and WDM (Window Desktop Manager). If you are unable to to log on via active directory account to SSH or WDM modify the following PAM modules

3.3.1 SSH

Refer to your distribution or UNIX vendor manuals for path to PAM modules.

  1. Edit /etc/pam.d/sshd and replace the contents with the contents below:

auth include system-auth

account required pam_nologin.so

account include system-auth

password include system-auth

session optional pam_keyinit.so force revoke

session include system-auth

session required pam_loginuid.so

session required pam_mkhomedir.so skel=/etc/skel/ umask=0022

3.3.2 WDM (KDE, GNOME, XFCE, etc..

  1. Edit /etc/pam.d/gdm.conf and add the following line to the end of the configuration file:

session required pam_mkhomedir.so=/etc/home umask=0022



More by this Author


Comments 2 comments

amro.sallam 4 years ago

it's very good


martellawintek 3 years ago

yous ok gerry if your still hanging around i think this is the link

and some info , there there most competitive in the game , mention wintek put you on

    Sign in or sign up and post using a HubPages Network account.

    0 of 8192 characters used
    Post Comment

    No HTML is allowed in comments, but URLs will be hyperlinked. Comments are not for promoting your articles or other sites.


    Click to Rate This Article
    working