Using ad as solaris authentication source

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 topublish 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 willconfigure 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, inwhich 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 toinclude “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 Server2003; 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 thesethree 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 onSolaris. 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 GroupPolicy 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...