LDAP-UX Client Services B.05.00 with Microsoft Windows Active Directory Server Administrator's Guide (obsolete beyond B.05.00)

NOTE:
• If the user's login name is root or UID is 0, PAM_AUTHZ does not process the access rules
defined in the access policy file. The root user is always granted login access.
• The default <action> of PAM_AUTHZ is deny if no authoritative rule is found.
The following describes situations where PAM_AUTHZ skips an access rule and does not process
it:
• An access rule contains the wrong syntax.
• PAM_AUTHZ processes the ldap_filter and ldap_group types of access rules by querying
the directory server through ldapclientd daemon. If LDAP-UX Client Services is not running,
PAM_AUTHZ skips all the ldap_filter and ldap_group types of rules.
6.4.5.1 An example of access rule evaluation
The following shows an example of an access policy file:
allow:unix_user:user1,user2,user3,user4
required:ldap_filter:(status=active)
allow:unix_group:group1,group2
deny:unix_group:group11,group12
allow:netgroup:netgroup1,netgroup2
allow::ldap_group:ldapgroup1,ldapgroup2
allow:ldap_filter:(&(manager=Joeh) (department=marketing)(hostname=$[HOSTNAME]))
PAM_AUTHZ processes access rules in the order they are defined in the access policy file. It stops
evaluating the access rules when any one of the access rule is matched, unless that rule has the
action required assigned. In the preceding example, if the user2 user attempts to log in, it
matches one of the user names in the first access rule, PAM_AUTHZ stops evaluating the rest of
the access rules and allows the user2 user to log in. For another example, user5 attempts to log
in and this user is only a member of ldapgroup2. PAM_AUTHZ validates user5's login access
and when the fifth access rule is evaluated to be true, user5 is granted the login access.
Now assume that the user6 user has the attribute status set to active, reports to Joeh, the
user's job is related to marketing and has a hostname attribute with the returned value HostSrv
in his/her user entry in the directory server. PAM_AUTHZ starts to validate user6's login access
by evaluating all the access rules defined in the access policy file. The second rule is evaluated to
be true, but since the action assigned to this rule is required, processing continues with the next
rule. The sixth access rule is evaluated to be true, and the user6 is allowed to log in to the host,
HostSrv.
6.4.6 Dynamic variable support
Dynamic variable support is a method by which an access rule can be defined where part or all
of the policy criteria will be determined at the time the rule is evaluated. For example, the name
of the computer from which the user attempts to logon can be substituted into the access rule to be
evaluated. See Section 6.4.9 (page 107) for more information on how to define an access rule
using dynamic variable support.
6.4.7 Constructing an access rule in the access policy file
In the access policy file, an access rule consists of three fields as follows:
<action>:<type>:<object>
All fields are mandatory except for the <object> field when passwd_compat,
unix_local_user, or Other is specified in the <type> field. If any field is missing or contains
the incorrect syntax, the access rule is considered to be invalid and is ignored by PAM_AUTHZ.
102 Administering LDAP-UX Client Services