Solaris Authentication Login with Active Directory

In most office environments users will have a Windows workstation on their desktop; most locations do not have users’ log into a Unix/Linux desktop as their primary work environment. In these environments a small percentage of these users may have a need to connect to their Unix servers in order to manage databases, application servers, web servers, etc. It becomes an administrative nightmare to manage multiple sets of users for the Windows and the Unix systems. The reason for this nightmare is primarily password management. In a lot of cases, Windows and Unix systems have different password requirements even though they may be in the same environment.

Often times, password requirements may differ between the two system types. This means users will have to use a different password on Windows and Unix. Also, when password change dates are not synchronized between the Windows and Unix systems you’ll end with users that forget their Unix passwords on a very frequent basis.

This article is meant to provide the basic procedures to allow a Solaris system to use user information provided by Active Directory on a Windows 2008 server as the authentication method for logging into Solaris.

The following instructions are cobbled together from several locations on the internet and from in house testing.
We primarily used the following two sites, which offer steps on configuration using Windows 2003 R2. We then made changes where required.

Sun Wikis
Scott Lowe’s Blog

Our Test Environment

  • Domain Controller Information
    • Windows 2008 R2
    • Hostname = win2k8-dc
    • IP Address =
    • Domain =
    • Kerberos Realm = TEST.SOG.COM
  • Client Information
    • Solaris 10_u8 x86
    • Hostname = keystone
    • IP Address =

Windows Configuration

It is assumed that Active Directory is setup and that DNS is configured on the domain controller. The steps provided are what you need to do to add Unix functionality to an already existing Windows AD environment. The Solaris clients should be added to the DNS records on the DC.

The following steps are required to add all additional functionality to the domain controller to allow for Solaris clients to authenticate against AD.

Install UNIX Schema into Active Directory

Open “Server Manager” and click on “Roles” in the left pane. Click on “Add Role Services” in the “Active Directory Domain Services” section in the right pane.

Click on the check box to add “Identitiy Management for Unix.” Remove Password Synchronization then click on “Next”

When you reach the “Confirm Installation” page click on “Install”

Click on “Close” on the next screen. Your Domain Controller will now reboot.

User Configuration in AD

Any users that you want to be able to use Active Directory for Solaris logins must have the Unix Attributes set under User Properties for that user. These properties include the UID, Primary GID, login shell, and home directory. (The users’ GECOS will come from the Display Name setting under the General tab of the users’ properties.)

Under Active Directory Users and Computers Right click the new user account and select Properties. In the user’s properties window select the Unix Attributes tab.

Select the domain under “NIS Domain” and fill in the fields.

All other user properties (secondary groups, RBAC roles/profiles/auths…) will come from the standard file locations on the Solaris client systems- (/etc/group, /etc/users, /etc/security/*attr)

Also, make sure that the user’s password is not set to ‘change at next login.’ Solaris does not have the hooks back into AD to do password management, so your user will not be prompted to change their password and they will not be allowed to login. All they will see is a messages saying: “Login Incorrect.”

Create Kerberos Keytab for Client System

Although this step is given on both of the sites provided above, I have found that it is not required to create a functioning Solaris -> AD authentication environment. I do not know the security implication of not performing this step.
On the Windows system, create a user account for the Solaris system that will be authenticating. In this example we are creating a user account named host-keystone for the host keystone. (Note: this is a user account, not a computer account)

Once this user is created you can disable it for security purposes.

The purpose of this step is create the keytab file that will be transferred to the /etc/krb5 directory of the Solaris system that will be authenticating against AD. In order to create the keytab file run the following command from a CMD prompt on the domain controller. (Make appropriate changes for you local environment.)

C:\Users\Administrator> ktpass –princ HOST\ -mapuser TEST\host-keystone –crypto DES-CBC-MD5 +DesOnly –pass p@ssword1 -ptype KRB5_NT_PRINCIPAL –out Desktop\keystone.keytab

Transfer the file to the host keystone as /etc/krb5/krb5.keytab

Create ProxyDN User Account

On the Windows system, create a user account that will be the proxyDN. Make this user a member of “Domain Guests.” Give it a password, and select ‘password never expires’
This will be the proxyDN username used when you run the ldapclient command later on. This account must remain enabled.
In this test we created a user account called “ProxyDNUser” with a password of “p@ssword1”

Make sure to use the Display Name under the General properties (Full Name when creating the user) during the ldapclient step. In this case the correct user to use during the ldapclient command will be ProxyDNUser. Do not use the user logon name. We ran into a bit of a problem when we kept trying to use the Windows logon name and we kept getting messages saying:

libsldap: Status: 49 Mesg: openConnection: simple bind failed – Invalid credentials

It was a bit frustrating when we were completely sure that we were using the right password and still kept getting a messages saying ‘Invalid Credentials.’

Use ADSIedit on your domain controller to see the full DN for the user account if you keep getting the message above and you’re positive you have the password correct.

Solaris Configuration

Client Side DNS Configuration

Your Solaris system should be a member of the DNS domain defined by your domain controller. Make sure to create both forward and reverse lookup records in the domain for the Solaris system.

# cat /etc/resolv.conf

Make sure you have the /etc/nsswitch.conf file setup to use DNS as a name service for hosts.

# grep ‘^hosts’ /etc/nsswitch.conf
hosts files dns

Verify that DNS works.

# nslookup `hostname`


The following nslookup commands should produce output similar to the following.

# nslookup -querytype=any _ldap._tcp
Address: service = 0 100 389

# nslookup -querytype=any _gc._tcp
Address: service = 0 100 3268


Configure the /etc/krb5/krb5.conf file on the Solaris client. Make appropriate changes required for your local environment.
This is the /etc/krb5/krb5.conf that we used on our test system.

default_realm = TEST.SOG.COM
dns_lookup_kdc = true
verify_ap_req_nofail = false
default_domain = TEST
admin_server = WIN2K8-DC.TEST.SOG.COM
[domain_realm] = TEST.SOG.COM = TEST.SOG.COM
default = FILE:/var/krb5/kdc.log
kdc = FILE:/var/krb5/kdc.log
kdc_rotate = {
period = 1d
versions = 10
pam = {
debug = false
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
kinit = {
renewable = true
forwardable= true

Run the kinit command and enter the administrator’s password. If the command runs successfully, you will see no output.

# kinit administrator
Password for administrator@TEST.SOG.COM:


ldap client initialization on Solaris host. The part of the command in orange needs to be modified for your environment. The rest of the command is standard across all configurations.

# ldapclient manual \
-a credentialLevel=proxy \
-a authenticationMethod=simple \
-a proxyDN=cn=”ProxyDNUser,cn=Users,dc=TEST,dc=SOG,dc=COM” \
-a proxyPassword=p@ssword1 \
-a defaultSearchBase=dc=TEST,dc=SOG,dc=COM \
-a domainName=TEST.SOG.COM \
-a “defaultServerList=” \

-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=TEST,dc=SOG,dc=COM?sub \
-a serviceSearchDescriptor=group:dc=TEST,dc=SOG,dc=COM?sub

# cp /etc/nsswitch.files /etc/nsswitch.conf

# vi /etc/nsswitch.conf
passwd files ldap
group files ldap
hosts files dns

# svcadm restart ldap/client


Edit /etc/pam.conf to use Kerberos authentication. Both sites provided at the top of this article show the same modifications to pam.conf. In our tests we found that those entries caused problems, most notably that the root user could not login from the console. Here is the /etc/pam.conf that we found to work best.

# vi /etc/pam.conf
# Authentication management
# login service (explicit because of pam_dial_auth)
login auth requisite
login auth required
login auth required
login auth sufficient
login auth required
login auth required
# Default definitions for Authentication management
# Used when service name is not explicitly mentioned for authentication
other auth requisite
other auth required
other auth required
other auth sufficient
other auth required
# Default definition for Password management
# Used when service name is not explicitly mentioned for password management
other auth requisite
other auth required
other auth required
other auth sufficient
other auth required

Create home directory for user.

# mkdir -p /export/home/john.doe
# chown john.doe:staff /export/home/john.doe
# chmod 700 /export/home/john.doe

You should now be able to log into your Solaris system with your AD user account.

Related Articles:

Seeds of Genius, Inc. offers a full range of IT solutions including hardware and software products in addition to consulting, installation and support services. For more information, please visit our main web site at or contact our Technical Sales department at (410) 312-9806.

8 thoughts on “Solaris Authentication Login with Active Directory

  1. Pingback: whey protein side
  2. Pingback: here's how to buy dubturbo
  3. Pingback: Dermine Lift Review
  4. Pingback:
  5. Pingback: balustrady

Leave a Reply