Extending Active Directory Authentication and Account Management To Solaris 10 Systems A HOWTO guide...

Extending Active Directory Authentication and Account Management To Solaris 10

Systems

A HOWTO guide for joining a Solaris 10 (8/07) host to a domain in a Windows 2003 Active

Directory domain for the purpose of authentication and accounts management.


Systems

A HOWTO guide for joining a Solaris 10 (8/07) host to a domain in a Windows 2003 Active

Directory domain for the purpose of authentication and accounts management.

No xhier packages required.

Further Details

Wiki page: https://www.cs.uwaterloo.ca/twiki/view/CF/ADAddSolaris10

What Do You Need

A Windows 2003 Active Directory (AD) Enterprise Admin credentials for your AD and logon

access to the schema master Domain Admin credentials for the Domain where the

Solaris host will authenticate and logon access to a domain controller (DC) in that domain

Superuser (root) rights to the Solaris host and login access to that host

May require Windows 2003 R2 installation disks

Account Management Involves Two Protocols

LDAP Account Lookup

Kerberos User Authentication

The AD and the Solaris host must be able to talk to each other using both these protocols

Account Management Involves Two Protocols

What do we have to start with? All domain controllers in an Active Directory are LDAP

servers and Kerberos Key Distribution Centres (KDC) by default

All Solaris 10 hosts have compatible vendor supplied LDAP and Kerberos clients

All Active Directory domains are corresponding Kerberos realms


Systems

Preparation In The Active Directory

Preparation in the Active Directory

LDAP Configuration Extend the Schema with RFC 2307 attributes Allow Anonymous LDAP Connections

Kerberos Credential Creation Create A User Account representing the Solaris host Create a keytab credential file for the Solaris host


LDAP Configuration:

Extend The Active Directory Schema

Extend the Active Directory Schema

Why?

Add AD user attributes that store required Solaris user information as part of user accounts. Such UNIX uid and gid numbers

Full account management within the AD for Solaris users

End the need for local user account maintenance on Solaris systems in /etc/passwd


Many new attributes are added to the schema. Of interest are the following posixAccount attributes uidNumber gidNumber loginShell unixHomeDirectory


How?

Run the adprep tool found on the Windows 2003 R2 installation disk set on the AD schema master adprep /forestprep

Enterprise or Schema Admin credentials are required

Does not require implementation of Windows 2003 R2


Reboot all domain controllers in the Active Directory


Use ADSI Editor snap-in to (manually) populate the new user attributes uidNumber gidNumber unixHomeDirectory loginShell


LDAP Configuration:

Allow Anonymous Read Of Active Directory LDAP Information


Why?

Eliminates the need for a specific LDAP bind DN which can break if the bind account is ever moved within the AD

Eliminates the need for LDAP bind credentials to be stored on every Solaris host


Security?

Anonymous read rights are applied only to relevant AD objects such as common users

Specific object attributes that must be secured can be denied anonymous read rights

User data stored by CSCF in /etc/passwd and the Active Directory is not sensitive

Domain controller LDAP ports can be secured using IPSec such that only authorized client subnets may connect to them

Allow Anonymous Read Of Active Directory LDAP

Information

How?

By default Windows 2003 Active Directory does not allow Anonymous connections to its LDAP service

On the schema master use the ADSI Editor snap-in to edit the 'Directory Service' container properties

Modify the dsHeuristics attribute such that the last numeral is a '2' (eg. 0000002, if not previously set)

Wait 30 minutes


Allowing Anonymous LDAP connections still does not imply Anonymous read rights Apply the List and Read rights for ANONYMOUS LOGON to

containers (OUs) with common users Avoid placing these rights on containers with sensitive

accounts such as Domain Admins


Success?

Use ldapsearch to lookup an AD user without using a binding DN ldapsearch -h domain_controller -b DN_for_top_of_domain cn=username ldapsearch -h intacta -b dc=cs,dc=uwaterloo,dc=ca cn=dlgawley


Kerberos Credential Creation:

Create A User Account For The Solaris System Within The Active Directory

Create A User Account For The Solaris System Within The Active

Directory

Why?

This account is used by the Solaris Kerberos client for user authentication within the Active Directory

This account is to be associated with the Solaris host's Service Principle Name (SPN)

Create A User Account For The Solaris System Within The Active

Directory

How?

Within a domain in the AD, create a user account with a password for the Solaris host eg. computername-host

DO NOT create a computer object Retain the password for the creation of the keytab file Enable account characteristics:

'Password never expires' 'Do not require kerberos pre-auth'


Kerberos Credential Creation:

Create a keytab file for the Solaris host

Create a keytab file for the Solaris host

Why?

To encode Solaris host account credentials into a file for porting to the corresponding Solaris host

To associate a Kerberos Service Principle Name (SPN) with the Solaris host's AD account

Create A keytab File For The Solaris Host

How?

On a corresponding domain controller, use the ktpass command to create a keytab file for the Solaris host

Specify account name, password, host SPN, encryption method as well as a file name

ktpass -ptype KRB5_NT_PRINCIPAL -crypto DES-CBC-MD5 -princ host/[email protected] -mapuser Domain_Name\computername-host -pass ComplexPasswd -out c:\temp\krb5.keytab


Systems

Preparation On The Solaris Host Side


Configure the Kerberos client Configure the LDAP client Configure the PAM stack


Configure the Kerberos Client

Configure The Solaris Kerberos Client

Securely install the Solaris host keytab file /etc/krb5/krb5.keytab

Set file permissions to root read only


Configure the krb5.conf file with the appropriate Kerberos realms /etc/krb5/krb5.conf


##pragma ident "@(#)krb5.conf 1.2 99/07/20 SMI"# Copyright (c) 1999, by Sun Microsystems, Inc.# All rights reserved.

[libdefaults] default_realm = CS.UWATERLOO.CA dns_lookup_realm = false dns_lookup_kdc = false ticket_lifetime = 24h forwardable = yes default_tkt_enctypes = des-cbc-md5 ; or des-cbc-crc default_tgs_enctypes = des-cbc-md5 ; or des-cbc-crc verify_ap_req_nofail = false


[realms] CSCF.UWATERLOO.CA = { kdc = elisa.cscf.uwaterloo.ca:88 admin_server = elisa.cscf.uwaterloo.ca:464 kpasswd_server = elisa.cscf.uwaterloo.ca:464 kpasswd_protocol = SET_CHANGE }

CS.UWATERLOO.CA = { kdc = intacta.cs.uwaterloo.ca:88 kdc = serverus.cs.uwaterloo.ca:88 kdc = viridis.cs.uwaterloo.ca:88 admin_server = intacta.cs.uwaterloo.ca:464 kpasswd_server = intacta.cs.uwaterloo.ca:464 kpasswd_protocol = SET_CHANGE }


[domain_realm] .cscf.uwaterloo.ca = CSCF.UWATERLOO.CA cscf.uwaterloo.ca = CSCF.UWATERLOO.CA .cs.uwaterloo.ca = CS.UWATERLOO.CA cs.uwaterloo.ca = CS.UWATERLOO.CA


Initialize the kerberos client using the kinit command kinit -k -t keytab_file_location host/host_fqdn@KERBEROS_REALM kinit -k -t /etc/krb5/krb5.keytab host/[email protected]

Success? kinit will supply no output Successful kerberos logon events will appear in the AD

domain Security logs for the computername-host account


Configure the LDAP Client

Configure The Solaris LDAP Client

Make a copy the /etc/nsswitch.conf file Edit the nsswitch.conf copy such that both passwd and

group databases fall over to ldap from files Or visa-versa


/etc/nsswitch.conf:

passwd: files group: fileshosts: files dns

ipnodes: files dnsnetworks: filesprotocols: filesrpc: filesethers: filesnetmasks: filesbootparams: filespublickey: filesnetgroup: files

...


Modifications to copy of nsswitch.conf:

...passwd: files ldap group: files ldap ...


Use the ldapclient command in manual mode to configure the host's LDAP client Specify LDAP servers Specify search bases Specify object class mappings Specify attribute mappings for database lookup


ldapclient manual \ -a credentialLevel=anonymous \-a authenticationMethod=none \-a defaultSearchBase=dc=cs,dc=uwaterloo,dc=ca \-a defaultSearchScope=sub \-a followReferrals=false \-a domainName=cs.uwaterloo.ca \-a defaultServerList=129.97.152.158 \-a attributeMap=group:userpassword=userPassword \-a attributeMap=group:memberuid=memberUid \-a attributeMap=group:gidnumber=gidNumber \-a attributeMap=passwd:uid=cn \-a attributeMap=passwd:gidnumber=gidNumber \-a attributeMap=passwd:uidnumber=uidNumber \-a attributeMap=passwd:homedirectory=unixHomeDirectory \-a attributeMap=passwd:loginshell=loginShell \-a attributeMap=shadow:uid=cn \-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=cs,dc=uwaterloo,dc=ca?sub" \-a serviceSearchDescriptor=group:"dc=cs,dc=uwaterloo,dc=ca?sub"


Replace the /etc/nsswitch.conf file with your copy of nsswitch.conf

Restart LDAP client service on the Solaris host svcadm restart svc:/network/ldap/client:default


Configure the PAM Stack

Configure The Solaris PAM Stack

Use of Kerberos and LDAP clients must be specified in the PAM stack for each login service /etc/pam.conf

Two native PAM modules are used pam_ldap.so.1 pam_krb5.so.1


Several login services, each has a stack (sequence) of PAM modules controlling authentication and account lookup: login rlogin rsh cron passwd other


For the 'other' service:

Add pam_ldap.so.1 as a 'sufficient' condition for the account stacks prior to pam_unix_account.so.1

Add pam_krb5.so.1 as a 'sufficient' condition for the auth stacks prior to pam_unix_cred.so.1

Add pam_krb5.so.1 as a 'optional' condition for the session stacks prior to pam_unix_session.so.1


other account requisite pam_roles.so.1other account sufficient pam_ldap.so.1other account sufficient pam_unix_account.so.1

...

other auth requisite pam_authtok_get.so.1other auth required pam_dhkeys.so.1other auth required pam_unix_cred.so.1other auth sufficient pam_krb5.so.1 other auth required pam_unix_auth.so.1

...

other session optional pam_krb5.so.1other session required pam_unix_session.so.1


For the 'passwd' service:

Add pam_krb5.so.1 as a sufficient condition for the auth stacks just prior to pam_unix_cred.so.1


passwd auth requisite pam_authtok_get.so.1passwd auth required pam_dhkeys.so.1passwd auth sufficient pam_krb5.so.1 passwd auth required pam_unix_cred.so.1passwd auth required pam_unix_auth.so.1


Success?

Use the getent command on the passwd database to look up a user that is in the AD but not /etc/passwd getent passwd username

The user must have his new UNIX attributes already specified for this to work


Systems

Success?

Attempt to login to the Solaris host via ssh using an AD account username and password

Further Details

Wiki page: https://www.cs.uwaterloo.ca/twiki/view/CF/ADAddSolaris10

Date post:	13-Dec-2015
Category:	Documents
Upload:	lisa-paul
View:	217 times
Download:	0 times

Extending Active Directory Authentication and Account Management To Solaris 10 Systems A HOWTO guide...

Documents