5 Replies Latest reply on Sep 13, 2013 7:22 AM by JimKlimov

    LDAP groups to work as Unix groups


      We have ODSEE installed on a machine which is the LDAP server and a Solaris 10 machine as its LDAP client. Is it possible to create static or dynamic groups on LDAP server such that they can act as local groups on the client and standard Unix commands like chgrp can work on these groups.

        • 1. Re: LDAP groups to work as Unix groups
          Sylvain Duloutre-Oracle



          What do you mean exactly by "Solaris 10 as LDAP client" ?

          Have you configured LDAP as a Naming Service for Solaris ? If not, you should have a look at


          that cover use of LDAP groups by the OS.





          • 2. Re: LDAP groups to work as Unix groups

            Sorry if I was not clear. I intend to say that we have Solaris configured with LDAP naming service(LDAP server runs on a different machine). The Solaris machine has home directories of LDAP users. We want to create groups only in LDAP and give group permissions on these directories as if the groups and users were local to it.

            • 3. Re: LDAP groups to work as Unix groups
              Sylvain Duloutre-Oracle



              There are basically 3 kinds of  "groups" in your LDAP repository used for Solaris naming services:

              - every user entry (corresponding to an entry in etc/passwords) has a default group assigned to it via the gidnumber attr in posixAccount.

              - users may belong to a standard LDAP group (e.g groupOfNames, groupOfUniqueNAme). This can be used by the directory to control who has the right to update data in the naming service, but these groups do not correspond to Unix groups

              - users may belong to a posixGroup entry that correspond to a Unix group.


              You should use posixGroups in your case:


              posixGroup:  Uses the memberUid attribute which contains only the value of the UID of a users full DN.  For example:

              memberUID: someuser

              The memberUID value correspond to the uid of a posixAccount entry


              groupofNames: Uses the member attribute which contains the full DN of the user.  For example:

              memberUID: uid=someuser,ou=People,dc=example,dc=com





              1 person found this helpful
              • 4. Re: LDAP groups to work as Unix groups

                Thank you. The response was quite helpful but here is the exact problem.


                I created a group with objectClass: posixGroup

                two users' posixAccount entries

                memberUID: someuser1

                memberUID: someuser2

                These two users have a gidNumber  different to that of SomeGroup's gidNumber saved with their LDAP entry. i.e SomeGroup is a new group to which I want to add these users.

                I create a file  on the Solaris machine with someuser1 as owner and read write permissions to SomeGroup . When I access the files as someuser1 , the permissions work perfectly fine but while accessing the file as someuser2 , the read write permissions(for group) do not work. This makes it clear that the LDAP users  with posixAccount are being identified as owners, LDAP groups with posixGroup are being identified but the association between the groups and the users is not happening . I  also  see that permissions and Unix commands work perfectly fine for the gidNumber stored with LDAP user entry but when this user is added to a new posixGroup , they fail.


                Hope I explained the problem clearly enough. Kindly let me know what could be the reason for the issue above.

                • 5. Re: LDAP groups to work as Unix groups

                  To add to Sylvain's reply, there are also "netgroups" which can be used by LDAP clients. These are triplets which can be nested and are commonly used to bind hosts and user accounts (and, IIRC, domains which is not really used due to a vague definition of the latter).


                  For example, you can define a netgroup of C and Java development machines or local zones (some of which may have both roles and be listed in both netgroups), a netgroup of C developers and a netgroup of Java developers (some of which may be in both), and in the /etc/passwd files on the machines reference something like this:




                  This way relevant hosts (identified by their nodename) would pick up user entries which correspond to their job (duplicates are possible, but IIRC harmless). Other users would be completely undefined for these machines, which adds a bit of security (you can't so easily impersonate an undefined user, for example) and gives you better centralized control of who can login where. Add to that sudo built with support of LDAP, or pfexec with LDAP-based RBAC, and you can also define what they can do with elevated privileges, if needed (i.e. restart an appserver, but not any other system-service programs). If interested, google for examples, there are plenty.


                  I haven't really used posixGroups with list of secondary GIDs, but might suggest to also take a look at your clients' /etc/nsswitch.conf - there are definitions of back-ends for system lookup databases such as passwd, group, hosts and a number of others (i.e. where to fetch information from - local files, LDAP/NIS or DNS as relevant)? I have a feeling that your client might be set up to only use the passwd database from LDAP, but not the group database. Or maybe you have a higher-priority backend (i.e. files) which defines the same group entry and overrides the lookup in LDAP?..


                  You can also use these commands to check the situation:


                  # id someuser1


                  This should return his UID, GID and a list of secondary GIDs.


                  # getent group SomeGroup

                  this should return the group name and list of accounts in it, as resolved by the system.


                  Finally, "snoop -v" can help you sniff the LDAP (non-SSL) traffic to see if requests are happening. Logs on the DSEE server can also be enlightening (note that they are buffered and updated on-disk about once every 15 seconds, so you don't see requests instantly).



                  //Jim Klimov