Integration with Active Directory
Jeremy Allison
Samba Team

Benefits of using Active Directory

Unlike the earlier Microsoft Windows NT 4.x Domain directory service which used proprietary DCE/RPC calls, Active Directory is based on standard Internet protocols.

LDAPv3 for directory lookup and updates.

Kerberos 5 for authentication (single sign on).

DNS for name resolution.

The hope was that non-Microsoft implementations of these protocols could be used to serve Windows clients allowing true competition for providing these services.

Unfortunately this is not the case.

What is Active Directory ?

Database Back

end Store

DHCP Server

Kerberos 5 Server

(KDC)

LDAPv3 Server

Dynamic DNS

Server

Microsoft RPC

Domain server

Why must we use an Active Directory Server ?

Windows clients don't use only the standard protocols to achieve logon services.

Mandatory “extra” features (like the modified Kerberos ticket and other details) are tied into the Active Directory implementation to enforce vendor lock-in.

The practical result of this is that if you want to use Windows clients and servers and obtain all the functionality you paid for then you must use a Windows Active Directory server.

IT Staff who recommend an Active Directory roll out without making management aware of this commitment going forward are misleading their executive staff.

Why must we use an Active Directory Server ?

Windows clients do not allow replacement of their low-level functionality to ease integration with non-Windows directory servers.

As usual, it is easier to configure non-Windows systems to interoperate with Windows systems than vica-versa.

The free release of Microsoft Services for UNIX does help here, although the protocols used (NIS) are not as secure as using the native protocols of Kerberos and LDAP.

Active Directory servers can have their LDAP schema (the formal definition of the format of the data they store) extended to allow them to serve non-Windows clients.

What do we mean by integration with an
Active Directory Server ?

For a non-Windows client to integrate successfully into Active Directory we need two operations to be seamless.

Authentication of Linux/UNIX accounts against Active Directory.

Enumeration of Linux/UNIX user and group directory information stored in an Active Directory store.

For authentication the preferred method is Kerberos 5 (the native Windows 2000 and above authentication method).

Microsoft Services for UNIX, LDAP or MS-RPC can also be used here.

For user and group enumeration integration LDAP is the preferred method.

Microsoft Services for UNIX and MS-RPC can also be used.

Kerberos Authentication
Integration

Active Directory Servers can be Kerberos 5 KDC servers for Linux/UNIX clients.

MIT or Heimdal Kerberos servers cannot be complete KDC servers for Windows clients due to the missing “extra” data field.

MIT or Heimdal KDC servers can be set to “trust” AD Kerberos servers if the Windows and UNIX user accounts are separated into separate “realms”.

In a more integrated environment it is probably easier to just use Active Directory Kerberos Servers (as Microsoft intended by “extending” the standard).

Integrating Windows Authentication
Services with Linux/UNIX

Linux/UNIX systems started with local files containing all authentication information.

Since then a standardized plug-in architecture has been developed to allow replacement of the authentication information validation (user logons) and maintenance (password changing) with many different possible targets.

PAM (Pluggable Authentication Modules) – API invented by Sun and adopted by Linux and other UNIX platforms.

PAM – Pluggable Authentication Modules

Application

PAM

request

PAM library

PAM

Config

Directory

Module

Stack

Application

lookup

PAM library

PAM library

PAM library

PAM requests can be for auth, account,

password or session functionality.

PAM on Linux/UNIX systems

PAM is a standard on Linux and many UNIX systems (HPUX, Solaris and others).

Over twenty different PAM modules exist to provide all manner of authentication services.

Three specific modules are of interest for Active Directory Integration

Kerberos – pam_krb5 (http://pam-krb5.sourceforge.net)

LDAP – pam_ldap (http://www.padl.com)

Samba/Microsoft RPC – pam_winbind (http://www.samba.org)

Kerberos - pam_krb5

Takes the users clear-text password and validates it against a standard Kerberos 5 server (Active Directory adds extra proprietary data into the returned ticket, but the client libraries on Linux/UNIX ignore this data).

Returns a Kerberos 5 Ticket-Granting-Ticket (TGT) which can be used to get tickets for other services.

Care must be taken to ensure the encryption method used by default by Windows (RC4-HMAC) is available on the Linux/UNIX Kerberos system.

Source code available, Open Source/Free Software.

LDAP - pam_ldap

Takes the users clear-text password and validates it against an LDAP server by attempting to set up an LDAP connection as the given username/password pair.

Must be set up to use SSL/TLS in order to securely validate the password (pam_krb5 doesn't have this problem, all kerberos exchanges are secure).

Developed by PADL software – available as Open Source/Free Software.

Samba - pam_winbind

Allows a Linux/UNIX user to authenticate in exactly the same way as if they were logging on to a Microsoft member server in the Domain.

Requires a working Samba set-up (more details later).

Completely integrates the Linux/UNIX authentication mechanism into the Windows world – identical to a Windows server.

All of Samba is Open Source/Free Software.

Integrating Windows User Directory
Services with Linux/UNIX

Linux/UNIX systems started with only local directory listings (local files) and have since had to develop standardized plug-in architectures to allow replacement of the directory service with any compatible server (no hidden protocols).

NSS (Name Service Switch).

NSS allows user and group lookup and enumeration to be done via many different directory services. The order in which they are queried can be changed.

The nss modules that are of interest for Active Directory Integration are :

nss_ldap

nss_winbind

nss_nis

NSS – Name Service Switch

Application

NSS

request

NSS library (libc)

/etc/nsswitch.conf

Module

Stack

Application

lookup

NSS library

NSS library

NSS library

NSS requests can look up user, group, or

enumerate the user or group lists.

External lookup

(NIS)

Local files

lookup

External lookup

(winbind)

LDAP - nss_ldap

Written by PADL software (as is pam_ldap) this library allows Linux/UNIX systems to look up users and groups stored in an Active Directory server.

The Active Directory Schema must have been extended from the standard schema by including either the RFC2307 schema (created by PADL) or the schema used by Microsoft's Services for UNIX product.

The Linux/UNIX user and group information must already exist in the Active Directory as part of the schema.

This requires some extra administration to add the extra information to the existing Active Directory data.

Samba - nss_winbind

Part of the complete solution provided by Samba (will be described in detail later).

Does not require any changes to the Active Directory Schema.

Does require a working Samba set up and the Linux/UNIX machine to have been added as a “member server” into the Active Directory.

Microsoft Services for UNIX - nss_nis

Does not talk directly to the Active Directory Server but to a NIS (Network Information Services) gateway running on a Windows server.

As with nss_ldap, requires additions to be made to the Active Directory Schema to add the Linux/UNIX (POSIX) definitions.

Useful for older UNIX installations that will only use the NIS protocols (regarded as insecure in modern UNIX systems).

NIS protocol developed by Sun in late 1980's.

Three Complete
Solutions for
Active Directory
Integration

PADL solution

Modify Active Directory with either the RFC2307 schema definition or the Microsoft Services for UNIX schema.

Install pam_ldap (or alternatively pam_krb5) to handle the authentication from the Linux/UNIX systems.

Install nss_ldap to handle the directory service enumeration from the Linux/UNIX systems.

Probably the easiest choice for organizations with significant existing Linux/UNIX experience.

Secure, robust solution but requires work to maintain.

Services for
UNIX solution

Windows Active

Directory Server

(modified schema)

NIS Server

Service

Linux/UNIX

Server

NIS PAM

NIS NSS

Communication using NIS

protocol over the network.

Services for
UNIX solution

Uses older NIS protocol – an older UNIX standard.

Modern Linux/UNIX systems use either NISPLUS (encrypted version of NIS) or LDAP or Kerberos for password verification.

Now Microsoft has made Services for UNIX available for free this is now a competitive solution.

No source code available, unlike other solutions.

Good choice if an organization is mainly Windows, with a few older Linux/UNIX machines for which security is not a priority.

Samba winbind
solution

Windows Active

Directory Server

(unmodified schema)

winbind

daemon

Linux/UNIX

Server

winbind PAM

winbind NSS

MS-RPC or LDAP

communication

over the network.

Samba winbind
solution

Allows a Linux/UNIX machine to completely emulate a Windows member server.

No changes to Active Directory schema needed – winbind copes with mapping Windows users and groups to Linux/UNIX users and groups.

Allows Windows clients accessing file and print (Samba) services on the Linux/UNIX server to pass kerberos 5 tickets to obtain service (as to a Windows file server).

To synchronize user and group mapping between multiple Linux/UNIX servers using winbind an external LDAP server must be used (not completely transparent).

Uses the same protocols as Windows servers for enumerating users and groups and checking passwords.

Integrating
Samba

Windows Active

Directory Server

Windows

Application

Server

Samba Domain

Controller

Trust

Relationship

Member

Server

Member

Server

Member

Server

The ugly details :-)

(This area intentionally left blank)

The following slides courtesy and © Jerry Carter

Domain Mode Security

smb.conf setting “security = domain”

NTLM

security = ads

Kerberos 5 & LDAPv3

Why is it better than security = server ?

Uses less resources on the PDC/BDC

The Samba server can participate in Domain Trust Relationships.

“allow trusted domains = yes”

The Samba server has access to more detailed user information as a domain member.

Domain Security details

SMBnegprot

request

Client

response

Member

Server

Domain

Controller

SMBsesssetup

request

NET_REQCHAL

NET_AUTH2

NET_SAMLOGON

response

SMBtcon request

response

Configuring Domain Membership

Make sure smbd and nmbd are not running.

Make necessary changes to smb.conf.

Join domain :

root# net [rpc | ads] join -U admin%pass

-W workgroup

-S server

Stores the machine password in secrets.tdb.

Start smbd and nmbd.

Caveat: smbd must be able to associate a UNIX uid with each user for file access.

smb.conf settings for Domain Security

global]

netbios name = MYNAME

workgroup = MYWORKGROUP

security = domain

encrypt passwords = yes

# use a '*' if smbd should locate

# an available DC by resolving

# workgroup<1c>

password server = PDC BDC1 BDC2 *

Finding a Domain Controller

PDC is needed to join a domain.

password server (string)

accepts a list of {ip address | names}[:port]

port is only used when connecting to an AD DC.

marked as preferred servers.

* (star character) - auto lookup DC's.

ADS - SRV RR for _ldap._tcp.domain

will fall back to netbios lookups if DNS fails (and netbios services are available).

NetBIOS - DOMAIN<0x1c>

e.g. password server = PDC 192.168.1.78 *

ADS Mode Security

Requires:

Kerberos 5 libraries.

MIT - http://web.mit.edu/kerberos/www/

Heimdal - http://www.pdc.kth.se/heimdal/

OpenLDAP 2.x libraries.

http://www.openldap.org/

No special ./configure options.

smbd -b | egrep '(HAVE_LDAP|HAVE_KRB5)'

If you do not have support for enctype 23 : (ARC4-HMAC-MD5), you must change the Administrator account password on the AD server to generate the appropriate DES keys.

smb.conf settings for ADS Security

[global]

netbios name = MYNAME

workgroup = MYWORKGROUP

realm = MY.DNSNAME.COM

security = ads

encrypt passwords = yes

password server = *

smb.conf

[realms]

MY.DNSNAME.COM = {

kdc = windc.my.dnsname.com

}

/etc/krb5.conf

ADS security details

Workgroup and Realm should be specified.

Even if 'disable netbios = yes'

MIT Krb5 can be build to use SRV RR to locate KDC's.

-DKRB5_DNS_LOOKUP

-DKRB5_DNS_LOOKUP_KDC

--enable-dns

Heimdal supports SRV lookups by default.

/etc/krb5.conf

[libdefaults]

dns_fallback = true

Joining an ADS Domain

root# net ads join -U Administrator%pass

Joined 'MYNAME' to realm 'MY.DNSNAME.COM'

Testing the join :

root# kinit Administrator@MY.DNSNAME.COM

Password:

root# smbclient //MYNAME/public -k -d 2

....

Doing spnego session setup (blob length=106)

Doing kerberos session setup

Domain=[MYDOMAIN] OS=[Unix] Server=[Samba-3.0.9]

smb: \>

Winbind Details

Winbind is composed of :

winbindd

Daemon to communicate with a WinNT 4.0 compatible DC.

pam_winbind.so

PAM module to support auth, account, & password control flags.

nss_winbind.so

Name Service Switch module to support obtaining password & group information from the winbindd daemon.

wbinfo - testing tool.

ntlm_auth - used for 3rd party applications.

Winbindd uses 2 named pipes ( /tmp/ & ${lockdir} ).

Winbind Architecture and Interactions

NSS

PAM

getpwnam()

auth

winbindd

smbd

nmbd

Samba

PDC

Database storing mapping

of Windows NT SIDs to

Unix uids/gids

Authentication

winbindd pipe

Installing Winbind

Supported on Linux, Solaris, HP-UX 11.0, AIX, and *BSD.

Compile and install.

Samba-HOWTO-Collection contains a chapter on winbind.

Make sure to use the libnss_winbind.so that matches the winbindd installation.

Make sure the name of the winbindd NSS library is correct for the OS.

Setting up winbind

Stop smbd, nmbd, & winbindd.

Join the domain :

net [rpc|ads] join -U admin%pw

Add idmap uid/gid parms to smb.conf

Add winbind entries to passwd and group services in /etc/nsswitch.conf

Start winbindd, smbd & nmbd

Use wbinfo to test

-t : test trust account

-u : list domain users

-g : list domain groups

-domain=DOMAINNAME

Winbind Parameters

[global]

workgroup = MYWORKGROUP

security = [domain | ads]

## required domain security

## parameters go here

...

## winbind settings

idmap uid = 10000-20000

idmap gid = 10000-20000

winbind separator = +

template shell = /bin/bash

template homedir = /home/winnt/%D/%U

smb.conf

Winbind Parameters (continued).

“winbind separator” (character).

Character used to separate the domain from the username for Windows users.

“template shell” (string).

Value of the shell field of the user's password entry.

“template homedir” (string).

Value of the home directory field from the domain user's password entry.

Winbind Parameters (continued).

Range from which winbindd should allocate uids & gids.

“idmap uid” (integer range).

“idmap gid” (integer range).

“winbind use default domain” (boolean).

Treat user as MYDOMAIN\user.

Only useful for UNIX services using pam_winbind.

May be necessary to disable the following for large domains:

“winbind enum users” (boolean).

“winbind enum groups” (boolean).

Winbind uid and gid Allocation.

Domain users do not need an entry in /etc/passwd.

winbindd daemon allocates uids and gids on an as needed basis from the range specified in smb.conf.

Mappings are stored in an TDB file.

Two winbind installations on two machines will have different mappings for different users.

Integration problem with NFS mounted filesystems.

Samba 3.0 provides a means of storing uid and gid mappings in an LDAP directory.

Local and Nested Groups.

“winbind nested groups” (boolean).

winbindd supports unrolling of local nested groups starting in Samba 3.0.3.

Managing local groups is best done via the Windows User Manager tools.

Group membership is stored as a list of SIDs

SIDs are expanded by getgrnam().

Resources (end of Jerry Slides :-)

Available on dead trees from Prentice Hall and in the Samba source distribution.

Samba 3 HOWTO and Reference Guide.

Samba 3 by Example.

Sams Teach Yourself Samba in 24 Hours, Carter, Sams, 2nd edition.

Covers up version 2.2.

O'Reilly's Using Samba (2nd ed.), included in Samba distribution under Open Content License.

Covers version 2.2 with some initial coverage of what was planned to be in 3.0.

Conclusions

Windows Active Directory is a necessary evil if you have large numbers of Windows clients.

The moral of this is if you're not piloting a desktop Linux program, you're paying too much for your Microsoft client software ☺.

Options are PADL Open Source code, Microsoft Services for UNIX, or Samba to provide no-cost integration between your Linux/UNIX machines and Active Directory.

All solutions have complexity involved – set up a test environment to determine which best matches your business (no surprises here ☺).

http://www.samba.org

http://www.hp.com/linux

2004-01-19T12:24:25