Managing Client Profiles and Proxy Agent Accounts

A client profile and proxy agent account are set up automatically when the idsconfig command is run to initialize the directory. While the environment created is a good starting point, you will most likely want to create additional client profiles and proxy agent accounts after the initial configuration.

Reasons for doing this include:

To implement access and security policies on a per client or group of clients basis.
To improve security by establishing separate passwords for different client systems to use when they bind to the LDAP server to obtain naming service data.

Creating too many profiles can result in increased management cost and complexity. You should take this into consideration when deciding how you want to implement client profiles.

Two client profile features are especially useful for implementing access policies. These are:

Service Search Descriptors (SSDs)
Attribute mapping

SSDs provide a great deal of flexibility and have many uses. Basically, they let you control which naming service data that a particular system is permitted to access. For example, you may set up an SSD that only allows a certain group of users to log in to a system or only auto-mounts a limited number of directories.

Attribute mapping can also be used to deny or allow access to a particular system based on the value of a particular attribute in the user's entry. It can also be used to change user profile data based on the system they log in to. For example, a different login shell or home directory can be set based on which client system a user logs in to.

The credentials that a system uses to bind to the directory server with are maintained in a file located in /var/ldap on the system the user logs in to. These credentials consist of a proxy DN and password contained in the proxyDN entry. Any directory object that can bind to the directory server can be used for a proxy DN, but for administration control, it is best to have dedicated proxy accounts for that purpose. While a single proxy DN and password can be used for all client systems, it might make sense to use different accounts for different sets of systems. The access rights of the proxy account can also be used to control access to naming service data.

The following sections explain the mechanics for managing client profiles and proxy agent accounts. Examples are provided to show how they can be deployed.

Creating Additional Profiles

When the idsconfig command is run, you are prompted for a profile name . The following examples show the prompts used to gather information to create a profile.

 Enter the profile name (h=help): [default]  newprofile  Default server list (h=help): [129.100.100.1]  129.100.100.1  Preferred server list (h=help): Choose desired search scope (one, sub, h=help): [one]  one  The following are the supported credential levels:   1 anonymous   2 proxy   3 proxy anonymous Choose Credential level [h=help]: [1]  2  The following are the supported Authentication Methods:   1 none   2 simple   3 sasl/DIGEST-MD5   4 tls:simple   5 tls:sasl/DIGEST-MD5 Choose Authentication Method (h=help): [1]  2  Current authenticationMethod:  simple  Do you want to add another Authentication Method?  n  Do you want the clients to follow referrals (y/n/h)? [n]  n  Do you want to modify the server timelimit value (y/n/h)? [n]  n  Do you want to modify the server sizelimit value (y/n/h)? [n]  n  Do you want to store passwords in "crypt" format (y/n/h)? [n]  n  Do you want to setup a Service Authentication Methods (y/n/h)?  n  Client search time limit in seconds (h=help): [30]  30  Profile Time To Live in seconds (h=help): [43200]  43200  Bind time limit in seconds (h=help): [10]  10

In this section of the example, the SSD parameter is set.

 Do you wish to setup Service Search Descriptors (y/n/h)? [n]  y  A Add a Service Search Descriptor   D Delete a SSD   M Modify a SSD   P Display all SSD's   H Help   X Clear all SSD's   Q Exit menu Enter menu choice: [Quit]  a  Enter the service id:  passwd  Enter the base:  ou=contractors,dc=example,dc=com  Enter the scope:  sub

The last section of the example shows where information about a proxyagent account is gathered.

 Enter config value to change: (1-19 0=commit changes) [0]   Enter DN for proxy agent: [cn=proxyagent,ou=profile,dc=example,dc= com]  cn=proxyagent1,ou=profile,dc=example,dc=com  Enter passwd for proxyagent:  passwd  Re-enter passwd:  passwd

While you can rerun the idsconfig command to create additional client profiles or additional proxy agent accounts, this approach is not recommended because other parameters besides those in the client profile are set. If you are not careful, you can unintentionally overwrite other parameters. It should be noted that idsconfig will generate Version 2 client profiles. The Solaris 8 OE ldap_gen_profile command must be run to generate Version 1 profiles.

Another method is to run the ldapclient genprofile command. This command assumes a number of defaults when it is run. You can overwrite any of the defaults as shown in the following example.

 #  ldapclient genprofile -a profileName=newprofile \   -a credentialLevel=proxy \   -a authenticationMethod=sasl/DIGEST-MD5 \   -a bindTimeLimit=20 \   -a defaultSearchBase=dc=example,dc=com \   -a "serviceSearchDescriptor=passwd:ou=temps,dc=sun,dc=com?one" \   -a serviceAuthenticationMethod=pam_ldap:tls:simple \   -a defaultSearchScope=sub \   -a attributeMap=passwd:uid=employeeNumber \   -a objectclassMap=passwd:posixAccount=unixAccount \   -a followReferrals=false \   -a profileTTL=6000 \   -a preferredServerList=129.100.100.30 -a searchTimeLimit=30 \   -a "defaultServerList=29.100.200.1 129.100.100.1 204.34.5.6"

The ldapclient genprofile command does not update the directory. Instead it simply generates LDIF that can be imported into the directory as shown in the following example.

 dn: cn=newprofile,ou=profile,dc=example,dc=com ObjectClass: top ObjectClass: DUAConfigProfile defaultServerList: 29.100.200.1 129.100.100.1 204.34.5.6 defaultSearchBase: dc=example,dc=com authenticationMethod: sasl/DIGEST-MD5 followReferrals: FALSE defaultSearchScope: sub searchTimeLimit: 30 preferredServerList: 129.100.100.30 profileTTL: 6000 cn: eng credentialLevel: proxy serviceSearchDescriptor: passwd:ou=people,dc=example,dc=com?one bindTimeLimit: 20 attributeMap: passwd:uid=employeeNumber objectClassMap: passwd:posixAccount=unixAccount serviceAuthenticationMethod: pam_ldap:tls:simple

This method allows more flexibility in the creation of client profiles than idsconfig . For example, complex filters can be specified in the SSD and attribute and object class mapping can be used.

Note

No error checking is performed by ldapclient genprofile . If you mistype a value for a parameter, the value will be used whether it is correct or not.

The third method of generating a new profile is to generate LDIF from an existing profile in the directory and edit it with new values. For example:

 #  ldapsearch -L -b dc=example,dc=com \   objectclass=DUAConfigProfile > profile.ldif  #  vi profile.ldif  dn: cn=default,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: 43200 cn: default credentialLevel: proxy bindTimeLimit: 10 #  ldapmodify -a -D "cn=Directory Manager" -f profile.ldif  password: #

This might be the best method because you can easily create new profiles by making a copy, then performing a few edits.

Adjusting the Client Cache

The parameter profileTTL sets the cache refresh time. This parameter is kept in the /var/ldap/ldap_client_file file. To get the client to refresh its cache, perform the following command:

 #  pkill -HUP ldap_cachemgr