Hi Jonas,
I'm very sorry to see you have been having troubles with LDAP-UX. I understand your concerns about the complexity of setup, which is something we are attempting to address for the future.
I've been reviewing your query and the replies, and it seems to me that no-one has completely understood your requirement. Perhaps I don't either, but I will attempt to summarize what I believe you want to do.
sudo has a database where you keep a security policy. This policy file defines which users can run which tools and which elevated privileges the user should get (run as root for example) when running that application. You'd like to store the information of that data base in an LDAP directory server. Correct?
If so, then I don't think LDAP-UX can address your requirement. But neither can the any PAM library (from open source or from LDAP-UX.) Part of this confusion appears to be related to the difference between authentication and authorization. PAM is primarily and authentication service, not an authorization service. And sudo is primarily an authorization service. The difference between the two is that authentication is used to verify the identity of the user and authorization verifies the right of the user to perform specific actions. There is some gray area here, in that PAM implicitly acts as an authorization service, in that once complete, the user is implicitly granted authorization to access the service using PAM (I.E. such as the implicit right to login to the operating system.) And sudo also acts as an authentication service, in that it can be configured to re-verify the identity of the user performing the sudo command, by calling PAM before determining the user's rights.
To solve this problem, sudo would either have to directly connect to the LDAP server or define interface with the name service subsystem (as Claus indicated). I believe there is some effort in this area, to provide LDAP backend database for sudo. But I am also not fully learned in the sudo community so I donâ t know what is available today. And to my knowledge this effort is not tied directly to any existing OS-enabled LDAP services (like LDAP-UX or the open source versions of pam_ldap or nss_ldap). Part of this disconnect is that UNIX has no standard authorization subsystem, like PAM is for authentication. While sudo is popular, it runs at the user level and is not tied into the OS with a pluggable architecture like PAM.
On HP-UX there is a pluggable authorization subsystem, known as the Access Control Policy Switch. This subsystem is authorizationâ s equivalent to PAM on HP-UX. And it is currently plugged into LDAP, indirectly through the IdMI product. ACPS is part of the RBAC subsystem and supports sudo-like capabilities and more. You can discover more about RBAC and IdMI and how it integrates with LDAP through the following URLs:
http://h20392.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=AccessControlhttp://h20392.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=IdMIntegration http://h20392.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=SelectAccessIdMIBTW, I would like to clarify some mis-communications that were mentioned in previous replies in this thread. One of them is that OpenLDAP can be used to solve this problem. OpenLDAP is merely a directory server. While OpenLDAP can be used to store the security policy for sudo, thatâ s all it can do. sudo itself must be LDAP-enabled before it can discover that security policy in the directory server. Another concern was that LDAP-UX does not support non-standard schemas. While LDAP-UX is limited to supporting specific OS name services (like passwd, group, hosts, â ¦) and the PAM authentication subsystem, it is not required to us any specific schema to do so. LDAP-UX can use any schema desired, for those particular services. For example, you use an employee number in the employeeId attribute to represent a Unix uid number.
Hope that helps!
Bob
