On Mon, 2009-01-19 at 14:15 -0500, David W Blaine wrote:
> 
> Hi all, 
> 
> I have been setting up a datasource in datasources.xml to bounce
> against Windows AD for authentication. How do you specify seperate
> bind credentials or is the bind attempted as the user that is supplied
> on the web form? 
<snip>
If I understand the question correctly, I believe the magic is in the
interplay of the binddn, searchattr, and role attribute.  Here is an
excerpt from our internal documentation (appropriately adapted):

However, it appears we can only use one access database at a time so, if
we want to use LDAP, comment out all the internal database information
including the password information. For LDAP authentication, we need to
use OUs to organize users as OpenCA does not properly use fedora ds
roles and groups. Thus, the LDAP section of the access_control templates
should look something like this:

<database>ldap</database>

<ldapdata>

<host>192.168.xxx.23</host>

<port>389</port>

<base>ou=Internal,dc=mycompany,dc=com</base>

<binddn>uid=dsearcher,ou=internal,dc=mycompany,dc=com</binddn> <!-- the
fixed openca user who will query LDAP for the credentials of the user
logging in -->

<bindpw>password</bindpw>

<usetls>yes</usetls>

<cacertpath>/etc/pki/CA/certs/</cacertpath> <!-- path to the LDAP
servers's CA cert -->

<searchattr>uid</searchattr> <!-- the attribute which corresponds to the
value used by the login user to login -->

<ldapdefaultauthmeth>bind</ldapdefaultauthmeth>

</ldapdata>

<passwd>

<roleattribute>ou</roleattribute> <!-- what LDAP attribute to use to
determine the user's role -->

<rolemapping>

<roleattributevalue>ou=pki_admins,ou=internal,dc=mycompany,dc=com</roleattributevalue>

<role>CA Operator</role>

</rolemapping>

</passwd>

Since any access_control templates and files contain the clear text
password for the LDAP searching user, they should be readable only to
the user however both openca and apache need access. Thus we change
permissions (chmod 640 *) and change group ownership (chgrp apache *).


To explain the documentation, the user authenticates to AD (by the way,
I haven't done this with AD).  I believe AD is then queried for the
<roleattribute> associated with the user's <searchattr>.  It then takes
the value of that roleattribute and compares it to <roleattributevalue>
and sees which <role> is mapped to that attribute value.  Thus, anyone
with a valid ID and password in AD can login into OpenCA but only those
who have roleattributes which map to OpenCA roles can actually do
anything.

Please understand this is my guess at what is going on.  I have not
analyzed it carefully and have not looked at the code.  Hope this helps
- John


-- 
John A. Sullivan III
Open Source Development Corporation

Street Preacher: Are you SAVED?????!!!!!!
Educated Skeptic: Saved from WHAT?????!!!!!!
Educated Believer: From our selfishness that hurts the ones we love
                   and condemns us to an eternity of hurting each other.
http://www.spiritualoutreach.com
Christianity that makes sense


------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Openca-Users mailing list
Openca-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openca-users

Reply via email to