Active Directory & Solaris
Using Active Directory as your Solaris
Authentication Source
The scope of this paper is to document how a newly installed Solaris 10 server can be
configured to use an Active Directory directory service as an authentication source. This
is not a definitive guide, and is the result of the following request:
Scenario: A customer has a variety of “fat-client” Windows-based applications
they wish to publish to multiple client types through the use of a kind of portal.
They will also be introducing some new Solaris/Linux-based X-Windows
applications as low-cost alternatives to Windows-based applications. The
customer will use SGD to publish these applications through their custom portal,
and have an existing Active Directory directory service to act as their
authentication source. They will configure SGD to use AD as their login
authority; how can they configure Solaris/Linux to use the same authentication
information?
To be clear, this setup uses AD as the authentication source, and all account information
is to be maintained in AD – there is no replication of user data between AD and the
Solaris clients; there are other ways to achieve what can be viewed to be as similar
results, such as:
· Account Replication / Synchronization – by using password / account
synchronization tools, (used by many Identity Management tools, including the
“Server for NIS” installed as part of this process), accounts are replicated
/synchronized among the various authentication sources, and are “linked” together
by some common attribute;
· Single Sign-On (SSO) techniques, such as used by SGD, in which SGD “learns”
user credentials for each different system, remembering them for future use, but
with no replication or synchronization provided amongst the different platforms.
And, of course, the user (or perhaps administrator) has to manually provide these
different credentials, at least once.
The things you need to accomplish include:
· Extend the Active Directory schema to include “Unix” operating system attributes
· Establish the Solaris server as a participant in the Kerberos realm
· Setup Solaris’ ldap client to map AD attributes to Unix attributes
· Setup the Solaris PAM configuration to use Kerberos/LDAP (Active Directory)
In the following, I’m using Server 2003 R2 (“R2” installs as an add-on to Server 2003) –
this adds a number of interoperability features to Server 2003; for our purposes, the
addition of the “Services For Unix” product to the base operating system is the most
important, as it extends the AD schema to include Unix attributes, such as uid and gid,
that aren’t present in the basic AD schema. RFC 2307 is the manner that Microsoft (and
Vintela’s and Centrify’s) chose to provide these attributes; it shouldn’t be assumed,
however, that these three products are interoperable, or chose to implement the RFC in
exactly the same way.
Step-By-Step Instructions
1. Environmental Setup
Time Service – Kerberos is dependent on time being synchronized between the client
and server; too large a clock skew will cause authentication failures. To prevent this,
each server should use the same time source. By default, the ntp service isn’t started
on Solaris. To setup a Solaris 10 server as an ntp client, (that is, to listen for NTP
multicasts for time adjustments), enter:
# cp /etc/inet/ntp.client /etc/inet/ntp.conf
# svcadm enable svc:/network/ntp:default
# svcadm restart svc:/network/ntp:default
For Windows 2003, NTP system behavior is controlled with the Group Policy
MMC Snap-In. To make changes to the Windows Time Server, using the Group
Policy Snap-In, and select Computer Configuration, click Administrative
Templates, click System, and then click Windows Time Service. Here you can
configure and enable time services for your Windows 2003 server(s.) Note that
the Windows NTP service doesn’t support multicasts.
DNS – Active Directory is integrated with DNS, and as such, needs to fully
configured and reliable. Client computers must be registed in both forward and
reverse lookup zones. In lab environments, it may be easiest to allow the Active
Directory setup wizard to install a DNS server. AD uses the SRV resource record
type to locate Active Directory domain servers. In addition, the DNS server service
should support dynamic DNS updates – if it doesn’t, SRV records must be maintained
manually by the administrator, which isn’t practical. To ensure that DNS is able to
return a domain controller address, enter the following command:
# nslookup –query=any _ldap._tcp.domainname
where domainname is the DNS domain name we’re setting up, e.g. “example.com”.
This should return a SRV resource record like:
_ldap._tcp.ttagov.com service = 0 100 389 win2k3.example.com.
the information returned includes:
priority ‘0’ in the above Clients attempt to connect to servers
with the lowest priority
weight ‘100’ in the above A load-balancing mechanism when
more than one server has the same
priority
port number ‘389’ in the above – The port number where the server is
listening to this service
hostname ‘win2k3.example.com’ in the
above
The FQDN of the server this record
pertains to
These values can be found/adjusted in the DNS Management snap-in.
There are other service record types as well, some other useful ones include:
# nslookup –query=any _gc._tcp.domainname
locates a Global Catalog server for this domain.
# nslookup –query=any _ldap._tcp._SiteName._sites._dc._msdcs.domainname
locates a domain controller in the site “SiteName” in the DNS domain
“domainname”.
2.Install NIS Server
This adds Unix attributes to the Active Directory schema
On an AD Catalog Server:
Select “Control Panel Add/Remove Programs”
Click “Add/Remove Windows Components”
Select “Active Directory Services” “Details” “Identity Management for
Unix” “Server for NIS”
Ensure that “Administration Components” is also selected, then click “Ok”, “Ok”,
then “Next” to install.
3. Install Windows Support Tools
This step installs the “ktpass.exe” utility, (used later in the procedure.)
Insert the Windows Server CD into your CD-ROM drive.
Click No if you are prompted to reinstall Windows.
When the Welcome screen appears, click Perform additional tasks, and then
click Browse this CD.
Go to the \Support\Tools folder.
Double-click suptools.msi.
Follow the instructions that appear on your screen.
4. Create a service account in Active Directory
This account will be used to bind to Active Directory. This account need not have any
special rights, and (if applicable) can be the same service account used by SGD to bind to
Active Directory. Make sure the password never expires.
5. Create a AD user account for each Solaris “client” server
Use the Active Directory Users and Computers tool to create these accounts. Since
Solaris will use the host service principal, a name like “host-solarissrvr” would be good.
For each account was created, run the ktpass.exe command to generate a unique keytab
for each account (host). The command will look something like this (this example is for
a hostname of “solx86.example.com”, in the realm “TTAGOV.COM”, with an output
filename of “solx86.keytab):
\Program Files\Support Tools\ktpass -princ
host/solx86.example.com@EXAMPLE.COM -mapuser host-solx86 -crypto
DES-CBC-MD5 +DesOnly -pass password -ptype KRB5_NT_PRINCIPAL -out
solx86.keytab
Be sure to specify a unique output filename (so that you don’t overwrite files; each
server/account will needs its own unique file). I suggest using the server’s name as
the filename, i.e., something like “solarissrvr.keytab”. Repeat the above for each
Solaris server, and copy the resultant keytab files to the /etc/krb5 directory on each
host as appropriate, naming the file as “/etc/krb5/krb5.keytab”, owned by root, with
mode 700 permissions. Note that if this file already exists, you will use the “ktutil”
utility to merge these files.
6. Create a Global Security group for your Unix Users
Create a Group in Active Directory for your Unix users. This group will have the a scope
of “Global” and a type of “Security”. Once created, set the “Unix Attributes” of the
created Group Name. When you create users, you’ll make them members of this group.
7. Configure Kerberos
On each server, configure your Kerberos client as follows, replacing hostname(s),
domains, and realm as appropriate. Be sure to use the proper case, and also be sure that
comments (‘#’) begin in column 1, otherwise a rather obscure error message will result –
trust me on this one.
# ident "@(#)krb5.conf 1.3 04/03/25 SMI"
# krb5.conf template
# In order to complete this configuration file
# you will need to replace the ____ placeholders
# with appropriate values for your network.
#
[logging]
default = FILE:/var/log/kdc.log
kdc = FILE:/var/log/kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = EXAMPLE.COM
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
forwardable = yes
[realms]
EXAMPLE.COM = {
kdc = win2k3.example.com
default_domain = example.com
}
[domain_realm]
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM
[appdefaults]
pam = {
debug = false
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
}
Test your configuration with the following:
# kinit administrator
Enter the administrator password. If no error results, enter the “klist” command to
confirm you have a valid ticket.
8. Configure the Solaris LDAP client
With a text editor, create the following shell script, replacing the “proxyDN” and
“proxyPassword” values with the service account values you created previously. Be sure
to use consistent naming within your “proxyDN” info – not the UPN or
sAMAccountName. Also, change the “defaultServerList” to point to your domain
controller. And, of course, change your domain to the proper values.
ldapclient manual \
-a credentialLevel=proxy \
-a authenticationMethod=simple \
-a proxyDN=cn=Service Account Name,cn=Users,dc=example,dc=com \
-a proxyPassword= mypass \
-a defaultSearchBase=dc=example,dc=com \
-a domainName=example.com \
-a "defaultServerList=172.16.0.202" \
-a attributeMap=group:userpassword=userPassword \
-a attributeMap=group:memberuid=memberUid \
-a attributeMap=group:gidnumber=gidNumber \
-a attributeMap=passwd:gecos=cn \
-a attributeMap=passwd:gidnumber=gidNumber \
-a attributeMap=passwd:uidnumber=uidNumber \
-a attributeMap=passwd:homedirectory=unixHomeDirectory \
-a attributeMap=passwd:loginshell=loginShell \
-a attributeMap=shadow:shadowflag=shadowFlag \
-a attributeMap=shadow:userpassword=userPassword \
-a objectClassMap=group:posixGroup=group \
-a objectClassMap=passwd:posixAccount=user \
-a objectClassMap=shadow:shadowAccount=user \
-a serviceSearchDescriptor=passwd:dc=example,dc=com?sub \
-a serviceSearchDescriptor=group:dc=example,dc=com?sub
After this completes, you’ll have to edit /etc/nsswitch.conf to remove all references to
“ldap” except for “user” and “group” entries. You may find it simpler to just copy
“/etc/nsswitch.conf.bak” to “/etc/nsswitch” and manually add the “ldap” entry
yourself.
Restart the LDAP client service:
# svcadm restart svc:/network/ldap/client:default
Test the configuration with a command like (substituting domain/service account info as
appropriate):
ldapsearch -v -h 172.16.0.202 -b "dc=example,dc=com" \
-D "cn=SGD Service Account,cn=Users,dc=example,dc=com" -w - "cn=administrator"
cn
Specify the password for the service account at the “Enter bind password:” prompt. If
successful, you’ll see output like:
ldapsearch: started Mon Mar 26 14:44:41 2007
ldap_init( 172.16.0.202, 389 )
filter pattern: cn=administrator
returning: cn
filter is: (cn=administrator)
version: 1
dn: CN=Administrator,CN=Users,DC=example,DC=com
cn: Administrator
1 matches
9. Add Entries to PAM Configuration
Next we need configure the PAM configuration file. First backup your pam.conf file:
# cp /etc/pam.conf /etc/pam.conf.bak
Next edit /etc/pam.conf as follows:
# Default definitions for Authentication management
# Used when service name is not explicitly mentioned for authentication
#
other auth requisite pam_authtok_get.so.1
other auth required pam_dhkeys.so.1
other auth sufficient pam_krb5.so.1
other auth required pam_unix_cred.so.1
other auth required pam_unix_auth.so.1
#
# Default definition for Account management
#
other account requisite pam_roles.so.1
other account sufficient pam_unix_account.so.1
other account required pam_ldap.so.1
#
10. Reboot Server
After rebooting, you should be able to login using user credentials stored in the Active
Directory directory service. At this juncture, common failures include:
· Missing Home Directory
· Invalid Shell
· Failed to set Unix attributes on the AD Account