Re: LDAP: selective accounts on hosts

[ne...@elaan.dds.nl]

Gary Tay Teng Teck <gar...@singnet.com.sg> wrote:
> ne...@elaan.dds.nl wrote:
>> ne...@elaan.dds.nl wrote:
>>
>>>Neal A. Lucier <nlu...@math.purdue.edu> wrote:
>>>
>>>>ne...@elaan.dds.nl wrote:
>>>>
>>>>>David Magda <dmagda+tr...@ee.ryerson.ca> wrote:
>>>
>>>[snip]
>>>
>>>>>>I'm curious as to whether there is a more "advanced" technique with
>>>>>>LDAP (specifically under Solaris 8). Can I add something to the LDAP
>>>>>>records that says 'this account is only valid / visible on host(s) X,
>>>>>>Y, and Z'? Ideally this would also work for utilities like
>>>>>>ldapaddent(1M) as well.
>>>>>>
>>>>>>The LDAP master and slave servers would be OpenLDAP 2.2.x.
>>>>>
>>>>>In my environment every LDAP client (Solaris 8, AIX 4.3.3 and
>>>>>5.2) has it's own directory user to read the users from the
>>>>>LDAP-directory. These proxy-agent users can be put into LDAP
>>>>>groups. Every user's entry in ou=People can have one of 2
>>>>>specially made attributes, both multivalued and containing
>>>>>a DN. One mentions the DN('s) of the system('s) this user
>>>>>can login to, the other mentions the DN('s) of the system-
>>>>>group('s) this user can login to. This is all made possible
>>>>>with one ACI that allows read, search, compare access to
>>>>>the person entries in ou=People when the DN of the system
>>>>>requesting the access is either mentioned in attribute1 or
>>>>>is in a group mentioned in attribute2. I don't know if
>>>>>it is possible to make these kind of ACI's in OpenLDAP,
>>>>>I use SunONE Directory server (5.2).
>>>>
>>>>Erik,
>>>>This is the best solution I have seen so far to this problem. Could you
>>>>post a representative ACI that is doing this.
>>>
>>>[snip]
>>>
>>>Nice you like it. I will post the ACI, but you'll have to wait
>>>a few days as the ACI is at work and I'm not...
>>>We use this to allow about 80 or so different groups of people
>>>on 80 set's of machine's selected from about 340. Some of the
>>>system-groups are even dynamic LDAP groups (objectclass =
>>>groupOfURLs) selecting the "membermachine's" on certain attributes
>>>in the system's proxy-agent user, like the machine's name.
>>>Because the have the machine-naming standard it's easy to
>>>distinguish SUN's from AIX'en, and use these dynamic groups to
>>>let the SUN systemmanagement people login to SUN's only v.v.
>>
>> Hi,
>>
>> Here we go. Needed to work today (sunday), and this is the SunONE
>> Directory Server ACI's doing the work described above:
>>
>> For straight rfc2307 clients (Native Solaris 8+), read-access to
>> user-attributes:
>>
>> (targetattr = "objectClass || uid || uidNumber || gidNumber ||
>> gecos || description || homeDirectory || loginshell ||
>> shadowLastChange || shadowMin || shadowMax || shadowWarning ||
>> shadowInactive || shadowExpire || shadowFlag")
>> (version 3.0;acl "Allow users on system(s) by systemname or
>> system-group";allow (read,compare,search)(userattr =
>> "myOrgUnixSystem#USERDN" or userattr =
>> "myOrgUnixSystemGroup#GROUPDN");)
>>
>> In human language this translates to:
>> - When access is requested to the attributes "Objectclass, uid,
>> uidNumber, etc ,shadowExpire or shadowFlag" ....
>> - Allow it when read, search and compare access is requested by ...
>> - a LDAP-user whose USER-DN is in the myOrgUnixSystem attribute ...
>> or
>> - a LDAP-user who is in a group whose GROUP-DN is in the
>> myOrgUnixSystemGroup attribute.
>>
>> Please note that the proxy-agent users used by Solaris systems
>> don't need read access to the userPassword attribute! This is
>> because the Native Solaris LDAP client code verifies the users
>> password by doing a LDAP bind to the directory with the DN
>> of the user's entry, and the password given by the user. In
>> SunONE Directory Server you don't have to give a user any rights
>> to the userPassword attribute to be able to bind.
>>
>> When using AIX 5.2 clients with the rfc2307bis + AIX extensions
>> schema you'll have to add access to quite some more attributes
>> for AIX systems only. This looks like this in SunONE Directory
>> Server:
>>
>> (targetattr = "admingroupnames || aixdefaultmaclevel || aixfuncmode ||
>> aixisdceexport || aixlowmaclevel || aixpromptmac || aixscreens ||
>> aixuppermaclevel || auditclasses || authmethod1 || authmethod2 ||
>> coresizelimit || coresizelimithard || cpusize || cpusizehard ||
>> datasegsize || datasegsizehard || filepermmask || filesizelimit ||
>> filesizelimithard || grouplist || groupswitchuserallowed ||
>> hostlastlogin || hostlastunsuccessfullogin || isaccountenabled ||
>> isadministrator || isdaemon || isloginallowed || isremoteaccessallowed
>> || isswitchuserallowed || ixlastupdate || ixtimelastlogin ||
>> ixtimelastunsuccessfullogin || logintimes || maxfailedlogins || maxlogin
>> || openfilelimit || openfilelimithard || passwordchar ||
>> passwordcheckmethods || passworddictfiles || passwordexpiretime ||
>> passwordflags || passwordhistsize || passwordmaxrepeatedchars ||
>> passwordminalphachars || passwordmindiffchars || passwordminlength ||
>> passwordminotherchars || physicalmemlimit || physicalmemlimithard ||
>> rolelist || stacksizelimit || stacksizelimithard || systemenvironment ||
>> terminalaccess || terminallastlogin || terminallastunsuccessfullogin ||
>> timeexpiredlogout || timeexpirelockout || trustedpathstatus ||
>> unsuccessfullogincount || username || userenvironment || userPassword")
>> (version 3.0;acl "Allow users on AIX-system(s) by systemname
>> or system-group";allow (read,compare,search)(groupdn = "ldap:///cn=Hosts
>> with AIX,ou=Hostgroups,ou=Unix,ou=Services,ou=Groups,o=myOrg" and (userattr =
>> "myOrgUnixSystem#USERDN" or userattr =
>> "myOrgUnixSystemGroup#GROUPDN");)
>>
>> As you can see AIX needs read access to the userPassword attribute. This
>> is because AIX does the comparison of the excrypted password from the
>> LDAP-directory and the password the user just typed on the AIX system
>> itself. AIX also need to write some attributes. These attributes
>> store the hosti, time and terminal of the last (un)successfull login and
>> the unsuccessfull logincount:
>>
>> (targetattr = "hostlastlogin || hostlastunsuccessfullogin ||
>> ixlastupdate || ixtimelastlogin || ixtimelastunsuccessfullogin ||
>> terminallastlogin || terminallastunsuccessfullogin ||
>> unsuccessfullogincount") (version 3.0;acl "Allow users on AIX-system(s)
>> by systemname or system-group";allow (write)(groupdn = "ldap:///cn=Hosts
>> with AIX,ou=Hostgroups,ou=Unix,ou=Services,ou=Groups,o=myOrg" and (userattr =
>> "myOrgUnixSystem#USERDN" or userattr =
>> "myOrgUnixSystemGroup#GROUPDN");)
>>
>> As you see we don't allow AIX systems to update the userPassword attribute.
>> This means you cannot change your LDAP password from an AIX machine. This
>> has 2 reasons:
>> 1) To enable this you would need to give write access to the
>> userPassword attribute of all users, to the LDAP-proxy-agent users of
>> AIX systems.
>> 2) The password of these LDAP-proxy-agent users is not encrypted
>> on AIX, but it is in /etc/security/ldap/ldap.cfg. This file is permission
>> 600 for root, but still I think this is quite a risk. Especially when
>> compared to Solaris. On Solaris, when you update the password, the Solaris
>> LDAP proxy-agent user does some LDAP-queries to find the DN of the entry
>> belonging to the Unix user trying to change his/her password, and subse-
>> quently uses the old password to bind to the LDAP-directory server as
>> the entry belonging to the Unix user. It then proceeds to write the
>> new password in the userPassword attribute. This way only the user
>> him/herself needs write access to the userPassword attribute of his/her
>> own entry. This can be allowed with standard ACI's.
>> BTW: In AIX 5.3 you can configure your AIX machine to use this type of
>> password checking/changing behaviour. It's called ldap_auth, and the
>> old type has been branded "unix_auth". We had requested this, and
>> maybe others did too.
>>
>> If people want/need to translate these ACI's to OpenLDAP, I'd like
>> to request them to post the result, as I may be using it in my
>> (Open)LDAP server at home.
>>
>> HTH, Erik.
>>
>> P.S. Sorry, it's quite a long post, and may not always be within
>> 80 columns.
>
> Erik, I suggest you could post your trick to comp.unix.aix also.
>
> Gary

As per Gary's suggestion, also posted to comp.unix.aix.

Erik