LDAP in the Solaris Operating Environment[c] Deploying Secure Directory Services
| Unlike accounts set up in NIS and NIS+, you probably have additional information that you want to store about users. The ldapaddent command can be used to create user entries from /etc/passwd and /etc/shadow , but chances are it would not contain all the attributes you want stored. One way to create customized user entries is to write a script that helps automate the process. The following is an example of a shell script that creates user entries from the command line. Part 1 - Get the parameters: #!/bin/sh USHELL=/bin/sh PWORD=secret COMMENT="" HOMEDIR="" UID="" GID="10" CN="" USERID="" LDAPSERVER=hosta DMPASSWD=mysecret STARTUID=100 ENDUID=1000 parse_arg() { while getopts "w:c:d:g:u:s:" ARG do case $ARG in w) PWORD=$OPTARG;; c) COMMENT=$OPTARG;; d) HOMEDIR=$OPTARG;; g) GID=$OPTARG;; u) UID=$OPTARG;; s) USHELL=$OPTARG;; *) echo "**ERROR: Supported option missing handler!" exit 1;; esac done return 'expr $OPTIND - 1' } Part 2 - Create the entry: parse_arg $* shift $? USERID= if [ -z "$USERID" ]; then echo "User ID must be entered" exit 1 fi CN=" " if [ -z "" ]; then CN="$USERID" fi if [ -z "$HOMEDIR" ]; then HOMEDIR=/home/$USERID fi if [ -z "$UID" ]; then find_uid fi ( cat <<EOF uid=$USERID,ou=people,dc=example,dc=com objectClass=posixAccount objectClass=shadowAccount objectClass=account objectClass=top uid=$USERID cn=$CN uidNumber=$UID gidNumber=$GID gecos=newuser homeDirectory=$HOMEDIR loginShell=$USHELL userPassword=$PWORD EOF ) > lusr.ldif ldapmodify -a -h $LDAPSERVER -D "cn=directory manager" -w $DMPASSWD -f lusr.ldif Password Management
Directory server password management can be easily performed through the Directory Console. This is a convenient way to change the default password storage scheme and set password aging. FIGURE 7-4 shows an example. Figure 7-4. Password Management in the Directory Console
Note The password-aging attributes stored in the directory are operational attributes that are not stored in the user entry.
Limiting User Access to a Client System
There are a number of ways you can restrict access to particular client systems using LDAP. These include:
The method for limiting access by deploying netgroups with LDAP is the same method used with NIS. The basics steps are:
Modifying /etc/passwd
The way netgroups works is to direct the user and password search to look in a naming service for a list of users allowed to log in. The directive used is the +@ symbol followed by a netgroup name . The following is an example of what the /etc/passwd and /etc/shadow files would look like specifying a netgroup called ldap-users . The passwd file # cat /etc/passwd root:x:0:1:Super-User:/:/sbin/sh daemon:x:1:1::/: bin:x:2:2::/usr/bin: sys:x:3:3::/: . . . ldaptest:x:137850:1::/home/ldaptest:/bin/sh +@ldap-users:x::::: # The shadow file # cat /etc/shadow root:GNIWbjOoY1P2g:6445:::::: daemon:NP:6445:::::: bin:NP:6445:::::: sys:NP:6445:::::: ldaptest:KW25kt7gvYupk:11892:::::: . . . +@ldap-users:::::: Modifying nsswitch.conf
The nsswitch.conf file needs to be modified so it will be accessed in the compatibility mode. Prior to the introduction of the Name Service Switch (NSS), a plus (+) sign was used in the /etc/passwd file to direct the search to NIS. With the NSS, the + was no longer necessary because you could specify your search path in the nsswitch.conf file. However, to use netgroups , the old style is required. The following is an example of what the applicable portion of an nsswitch.conf file might look like. # cat /etc/nsswitch.conf ..... passwd: compat passwd_compat: ldap [tryagain=continue] ...... netgroup: ldap [tryagain=continue] ...... Creating Netgroup Entries
Entries can be created using ldapaddent or by creating your own LDIF. Example of a netgroup entry: # ldaplist -l netgroup dn: cn=ldap-users,ou=netgroup,dc=example,dc=com objectClass: nisNetgroup objectClass: top cn: ldap-users nisNetgroupTriple: (,user1,) nisNetgroupTriple: (,user3,) nisNetgroupTriple: (,user2,) nisNetgroupTriple: (,user5,) # Setting an Alternate Search Path
You can specify where in the DIT the client system is allowed to search. # ldapclient list NS_LDAP_FILE_VERSION= 2.0 NS_LDAP_BINDDN= cn=proxyagent,ou=profile,dc=example,dc=com NS_LDAP_BINDPASSWD= {NS1}4a3788e8c053424f NS_LDAP_SERVERS= 100.100.100.1 NS_LDAP_SEARCH_BASEDN= dc=example,dc=com NS_LDAP_AUTH= simple NS_LDAP_SEARCH_REF= FALSE NS_LDAP_SEARCH_SCOPE= one NS_LDAP_SEARCH_TIME= 30 NS_LDAP_PROFILE= newprofile NS_LDAP_CREDENTIAL_LEVEL= proxy NS_LDAP_SERVICE_SEARCH_DESC= passwd:ou=temps,dc=example,dc=com?one NS_LDAP_BIND_TIME= 10 # The DIT is arranged with two branches as shown in FIGURE 7-5. Figure 7-5. Two Branches of the DIT
In this configuration, users are placed in two different branches of the DIT. If you want to designate some systems that only people in the temps branch can log into, you can create a client profile that would look in the ou=temps container. Restricting automount Access on Client Systems
Another use of SSD is to restrict what file systems a particular system is allowed to mount. This can be done by setting the search path of the automount database. It should be noted that the restriction set in this case would be per system and not per user. Changing User Login Parameters
Client profiles can be used to pass different login parameters to users depending on what system they log in to. For example, you might want a different login shell for restrictive and non- restrictive systems. To change users shells based on what system they log into, you can specify the AttributeMap attribute in the client profile. Before you do this you need to create custom attributes that store the alternate shells. For example: attribute: ushell Type: DirectoryString attribute: rshell Type: DirectoryString objectclass: shelluser requires: ushell, rshell
Note The section "Extending the Directory Schema" on page 440 explains how to do this.
Next, you need to add the new attributes to the user's entry: dn: uid=user2,ou=people,dc=example,dc=com objectClass: posixAccount objectClass: shadowAccount objectClass: account objectClass: top objectClass: shelluser uid: user2 cn: user2 uidNumber: 101 gidNumber: 10 gecos: newuser Next, you need to create client profiles that map the loginShell attribute: dn: cn=newprofile,ou=profile,dc=example,dc=com objectClass: top objectClass: DUAConfigProfile defaultServerList: 129.100.100.1 defaultSearchBase: dc=example,dc=com authenticationMethod: simple followReferrals: FALSE defaultSearchScope: one searchTimeLimit: 30 profileTTL: 600 cn: newprofile credentialLevel: proxy bindTimeLimit: 10 attributeMap: passwd:loginShell=rshell Deploying RBAC with LDAP
Role-Based Access Control (RBAC) was introduced in the Solaris 8 OE to address the problem of how to delegate system administration responsibility. Prior to RBAC, administrators were provided with the superuser (root) password or setuid scripts were written with group permissions granted to specific administrators. Granting root permissions to a large population of administrators is dangerous because the root user can do intentional or unintentional damage to a server in addition to breaching security. Custom setuid scripts are insecure and are difficult to manage. The concept behind RBAC is that a subset of administrative functions can be assigned to a particular user. What these functions are and who is permitted to perform them are controlled by four databases. These are:
The databases can be stored locally in files under /etc or in a naming service. The /etc files are:
The precedence of local files versus naming service is set in the /etc/nsswitch.conf file. However there is not a one-to-one relationship. TABLE 7-1 shows the relationship between the database and a tag contained in the nsswitch.conf file. Table 7-1. nsswitch.conf Tag Mapping
Refer to Chapter 5 "Migrating Legacy Data to LDAP" for details on how to import RBAC data. |