All,
I'm new to the community and apologize if posting to the wrong area. I'm looking for "_current_" information relating to a forum or documentation on RHEL Directory Server wrt to application integration. I'm making the assumption that the FDS is a parallel effort. I've used RHDS for basic user authentication but would like to do more with it. The docs that come with it are pretty extensive but really don't cover basic things such as integrating say autofs etc. Everywhere I read it says things like "you can easily extend it to do ..." but no where does it say "here's how". Probably just looking in the wrong places.
If this is the wrong area, please advise on where to post if you know. No flaming please.
Nate
2010/2/25 Natr Brazell natrbrazell@gmail.com:
All, I'm new to the community and apologize if posting to the wrong area. I'm looking for "_current_" information relating to a forum or documentation on RHEL Directory Server wrt to application integration. I'm making the assumption that the FDS is a parallel effort. I've used RHDS for basic user authentication but would like to do more with it. The docs that come with it are pretty extensive but really don't cover basic things such as integrating say autofs etc. Everywhere I read it says things like "you can easily extend it to do ..." but no where does it say "here's how". Probably just looking in the wrong places. If this is the wrong area, please advise on where to post if you know. No flaming please. Nate -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Natr,
How applications integrate with 389 is normally the job of the application developer. I can give you two examples of this: sudo and as you mentioned autofs. Normally such applications supply a schema file that defines how the data it needs should be structured.
LDAP servers like 389 do not know what the data is or how it is used, they only know how to store,search,modify, and delete it.
If you are interested in having your own application integrate with LDAP you should begin by learning how to design new schema, or possibly use/reuse already existing schema if applicable. If you are interested in learning how autofs integrates with LDAP that documentation would be found with the autofs vendor.
I'm trying to set up two 389 Directory Services servers in a replication scenario. I can do this quite easily without any SSL/TLS setup.
In an effort to improve the security of our environment, I would like to get TLS configured so that this replication (and all LDAP authentication attempts) are encrypted.
Using the scripts provided at http://directory.fedoraproject.org/wiki/Howto:SSL I can get one server using SSL; however when I try and establish the cross-server communication, the SSL/TLS keys appear to fall apart. My understanding from the logs on the systems is that the reason why the two servers (FDSMEM1 and FDSMEM2) do not have a common CA and so their server-certs do not trust each other.
So, I have set up TinyCA and created a CA cert from a third server. I have generated manual cert requests on the two LDAP servers (after registering the CA cert) and generated the certificates. Replication appears to be working through TLS.
Now, the problem I am having.
When I run the 'certutil -L -d . -n "CA certificate" -a > cacert.asc' command I get a cacert.asc. When I deploy this cacert.asc to my LDAP clients as the key for TLS to start, though, it appears that something isn't handshaking well and I am never able to query the LDAP server from a client.
Has anyone gotten a 389DS system (or pair of systems) fully working with certs managed & created by TinyCA2? If so, what are the gotchas that I must be missing to get this working? Would anyone be willing to help me write a HOWTO on getting this working so that it would be outlined more effectively for newer users?
Thanks.
-- Jeff Moody Senior Systems Engineer Electronic Vaulting Services 5050 Poplar Ave., Suite 1600 Memphis, TN 38157 (901) 259-2387 - 24x7 Helpdesk (901) 213-5146 - Office (901) 497-1444 - Mobile
Jeff Moody wrote:
I'm trying to set up two 389 Directory Services servers in a replication scenario. I can do this quite easily without any SSL/TLS setup.
In an effort to improve the security of our environment, I would like to get TLS configured so that this replication (and all LDAP authentication attempts) are encrypted.
Using the scripts provided at http://directory.fedoraproject.org/wiki/Howto:SSL I can get one server using SSL; however when I try and establish the cross-server communication, the SSL/TLS keys appear to fall apart. My understanding from the logs on the systems is that the reason why the two servers (FDSMEM1 and FDSMEM2) do not have a common CA and so their server-certs do not trust each other.
So, I have set up TinyCA and created a CA cert from a third server. I have generated manual cert requests on the two LDAP servers (after registering the CA cert) and generated the certificates. Replication appears to be working through TLS.
Now, the problem I am having.
When I run the 'certutil -L -d . -n "CA certificate" -a > cacert.asc' command I get a cacert.asc. When I deploy this cacert.asc to my LDAP clients as the key for TLS to start, though, it appears that something isn't handshaking well and I am never able to query the LDAP server from a client.
Has anyone gotten a 389DS system (or pair of systems) fully working with certs managed & created by TinyCA2? If so, what are the gotchas that I must be missing to get this working? Would anyone be willing to help me write a HOWTO on getting this working so that it would be outlined more effectively for newer users?
I'm not sure what's going on with your setup. I do know that, in order for an SSL client to talk to an SSL server, the SSL client needs the CA cert of the CA that issued the SSL server's cert. There is some information about TinyCA2 here - http://directory.fedoraproject.org/wiki/Howto:WindowsSync#With_TinyCA2 - don't know how accurate it is, or how applicable it is to your situation.
Thanks.
-- Jeff Moody Senior Systems Engineer Electronic Vaulting Services 5050 Poplar Ave., Suite 1600 Memphis, TN 38157 (901) 259-2387 - 24x7 Helpdesk (901) 213-5146 - Office (901) 497-1444 - Mobile
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Hello, Jeff.
I am working with the current release of RHDS towards bringing an LDAP infrastructure online at my place of business. The secure communications bit is one of the first aspects of the system that I've gotten set up. At this time I am working with the systems that will be authenticating to the directory, so I have not yet gotten to the business of replication; however, I thought I'd post my thoughts on what it seems you might be dealing with.
I am using the easy-rsa set of scripts that is shipped with OpenVPN; however, I do not think the software you're using to generate the certificates is the source of the problem.
The first thing that I have found is that the netscape security services library is very sensitive to what kind of certificate it is actually dealing with. I discovered this when attempting to use the server certificate I generated to test TLS connectivity with ldapsearch from the directory server's command line. It complains quite loudly that it cannot trust the certificate that it uses to identify the server as a client certificate.
conn=48 Netscape Portable Runtime error -8101 (Certificate type not approved for application.)
I determined that the "certificate type" was in reference to the X509v3 Extended Key Usage specification. For server certificates it is "TLS Web Server Authentication" vs "TLS Web Client Authentication" for client identification.
For local TLS testing purposes, I issued a client certificate "cn=test.client", created a test.client user under the appropriate branch in the tree and voila.
Without further information, I would assume that the problem is that you haven't provided your client with an appropriate client key. Installing your local Root CA is necessary and is a good start; however, whatever client program you are using will need some way to complete the handshake with the server.
If this doesn't get you on your way, run a tail -f /var/log/dirsrv/slapd-[instance]/access while your client system is trying to connect to the server and put it in a response to this thread.
Stephen Spencer Lawrence, KS
389-users@lists.fedoraproject.org