Once there's a central authentication mecanism somewhere it would be idiotic to not use it :p
This is why I started looking the Erlang LDAP support...
Everybody knows that erlang is really good at doing ASN1, but more people may not know that this feature is very very powerful... And while using the LDAP protocol this is really a killer feature, because once all ELDAP.* generated files are written you have access to the full power of LDAPv3...
I was idling a little on #erlang and talked a bit about LDAP and finally 'etnt' shows me the 'eldap' module... The first article I found was the one on Trapexit.org.
Since I use CEAN to work I just need to do
cean:install(eldap).
To get the 'eldap' module installed, I also use the developer cean package so I can retrieve source files aka *.erl files...
Then comes problems...
I wasn't able to connect to any of both servers. I was able to see that the tcp connection was correct but that the module don't want to bind (LDAP meaning).
I then activate the debug level (really nice feature):
eldap:debug_level("ldap", 2).
After that everything becomes clearer... The 'check_Pkt/1' fun incorrectly drop the packet !
I modified the fun, and make it returns 'ok'. Right after that every connection (bind) attempt worked flawlessly...
Another thing I need to do was searching DN from a DN attributes, this cannot be done by anything else than a 'distinguishedNameMatch' only available with an 'ExtensibleMatch':
Performing ExtensibleMatch (LDAPv3):
We need to add this line into the 'v_filter/1' fun:
v_filter({extensibleMatch, AV}) -> {extensibleMatch, AV};
The rest is fully handled by the ASN1 part...
Making an ExtensibleMatch part 2:
Base = "dc=example,dc=com".
Filter = {extensibleMatch, {'MatchingRuleAssertion',"2.5.13.1", "CN", "Username", false}}
eldap:search("ldap", [ Base, Filter ]).
While this query perfectly works with OpenLdap it doesn't with Active Directory !
In fact AD closes the connection directly... (May be a bug ?)
No comments:
Post a Comment