Managing Users and Groups

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

graphics/07fig04.jpg

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:

  • netgroups

  • Alternate search paths with SSDs

The method for limiting access by deploying netgroups with LDAP is the same method used with NIS. The basics steps are:

  1. Modify the local /etc/passwd and /etc/shadow file.

  2. Modify the local /etc/nsswitch.conf file.

  3. Create and populate an entry in ou= netgroup .

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

graphics/07fig05.gif

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:

  • user_attr(4)

  • auth_attr(4)

  • prof_attr(4)

  • exec_attr

The databases can be stored locally in files under /etc or in a naming service. The /etc files are:

  • /etc/user_attr

  • /etc/security/auth_attr

  • /etc/security/prof_attr

  • /etc/security/exec_attr

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

RBAC Database

Relevant nsswitch.conf Tag

user_attr

Set by the precedence for passwd

prof_attr

Set by prof_attr

auth_attr

Set by auth_attr

exec_attr

Set by prof_attr

Refer to Chapter 5 "Migrating Legacy Data to LDAP" for details on how to import RBAC data.



LDAP in the Solaris Operating Environment[c] Deploying Secure Directory Services
LDAP in the Solaris Operating Environment[c] Deploying Secure Directory Services
ISBN: 131456938
EAN: N/A
Year: 2005
Pages: 87

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net