We have had some difficulty integrating OpenCA 1.0.2 with fedora
directory server for LDAP access control. We finally do have a working
set up and thought we would post the issues we found both for any other
users, in case we have not handled it wisely (in which case someone
please tell us so), and so that the developers can see where they might
be able to improve interoperability. We found fedora ds easier to
manage than openldap although both are fine products. It would be nice
to have robust support for both.
First, we found we could not use multiple passwd authentication methods
so we had to comment out the internal database section of the
access_control templates.
Once we sorted through the debugging messages in the log files and the
AC.pm code (many thanks to whomever added those debugging messages!), we
realized our authentication failures were because no attributes were
being returned from the uid search. We think this is a consequence of
the way fedora ds handles roles and groups.
It seemed to us the value used in the <roleattribute> tag is used to
query LDAP for attribute values. These are then compared to the value
of the <roleattributevalue> tag. If there is a match, the user is
assigned the associated role.
It seems fedora ds does not add the memberOf attribute to users who are
members of a group. Thus, queries for memberOf did not return any
attribute values. Thus, there were no matches for roles and, without a
role, the user was not allowed entry to OpenCA.
We then tried using fedora ds roles. These do add an nsRole attribute
to the user. However, it is an "operational" attribute and is not
returned unless explicitly requested. Thus, once again, the query
returned no attributes and the login failed because of no role
assignment.
We finally resorted to grouping our uses with OrganizationalUnits. We
were then able to add the ou attribute to the users and search for the
ou. Our ldap entry in the access_control files looks something like:
<database>ldap</database>
<ldapdata>
<host>192.168.223.23</host>
<port>389</port>
<base>dc=niag,dc=com,dc=ssiservices,dc=biz</base>
<binddn>uid=dsearcher,dc=niag,dc=com,dc=ssiservices,dc=biz</binddn>
<bindpw>password</bindpw>
<usetls>no</usetls>
<searchattr>uid</searchattr>
<ldapdefaultauthmeth>bind</ldapdefaultauthmeth>
</ldapdata>
<passwd>
<roleattribute>ou</roleattribute>
<rolemapping>
<roleattributevalue>ou=pki
admins,ou=it,dc=niag,dc=com,dc=ssiservices,dc=biz</roleattributevalue>
<role>CA Operator</role>
</rolemapping>
</passwd>
Please note this is a test and not a production system thus the
<usetls>no</usetls> instead of yes.
Does anyone see something we might be doing wrong? Is there a better
approach? If the developers would like to use our test setup to enhance
interoperability between OpenCA and fedora/redhat/centos directory
server, please contact me. Thanks - John
--
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
[EMAIL PROTECTED]
http://www.spiritualoutreach.com
Making Christianity intelligible to secular society
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Openca-Users mailing list
Openca-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openca-users
