[tpop3d-discuss] ldap virtual auth plugin : near release
Prune
prune at lecentre.net
Thu, 21 Feb 2002 11:48:44 +0100
--------------040403080402020803080606
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
>
>
>
>
>>>>/* auth_mysql_new_user_pass */
>>>>
>>>>authcontext auth_mysql_new_user_pass(const char *user, const char *pass,
>>>>const char *host /* unused */) {
>>>>authcontext a = NULL;
>>>>char *local_part = NULL;
>>>>const char *domain;
>>>>char *filter = NULL;
>>>>
>>> [...]
>>>
>>>> /* we split the login and the domain from the email style login given
>>>> by the user */
>>>> domain = user + strcspn(user, "@%!");
>>>> if (domain == user || !*domain) return NULL;
>>>> ++domain;
>>>> local_part = xmalloc(domain - user);
>>>> if (!local_part) return NULL;
>>>> memset(local_part, 0, domain - user);
>>>> strncpy(local_part, user, domain - user - 1);
>>>>
>>>- Secondly, you never use the domain in constructing the
>>> query against the directory. How do you specify the
>>> existence of accounts in more than one domain?
>>>
>>you're right.
>>I search for the email address (unique, containing the domain). I use
>>'user' to build ldap filter. 'user' is the mail+domain or whatever is
>>typed by the user.
>>
>
>Ah, OK. Is this the normal procedure with LDAP? I had
>understood that you were expected to build heirachical
>directories....
>
this is hierarchical.
you go down to the directory and seek for the user DN having the
attribute requested in the search filter.
Then you get his DN. The DN is unique. it's your duty to make the search
filter to find a unique entry.
>
>
>Is LDAP case-sensitive?
>
globally no. It can be changed or depend on which attribute you're
requesting. but, no. search filters are not case sensitive.
>
>
>
>You establish whether the user has credentials on the
>mailbox by seeing whether they can bind (roughly
>equivalent to `log in', right?) to the LDAP server. Is
>this the normal approach? (I had assumed that one would
>have an attribute which contains a password hash -- as
>auth-mysql does -- and then test that explicitly.)
>
You can do both. getting the password and testing is the "old way" of
doing. At least, I think....
Doing a bind is better as the auth scheme depends on the ldap server,
and not on what you've coded into your plugin.
Some disallow users to be able to bind to the server.... that's a
problem. But there are no problem of letting them bind. Good ACL will
disallow then from seeing/modifying data in the ldap server. A good
firewall rule will also block connection to the ldap server from internet :)
Some ldap auth plugins offer both auth methode (bind and password
check). I've only worked on the bind methode as it's the best and more
robust.
You have to understand that a bind is something really common with ldap.
it's built in feature. it checks against the "userPassword" attribute.
>
>
>
>>Release the new tpop3d, and I'll work on this. it's simple to change.
>>Maybe you would like to have access to my test ldap server ?
>>
>
>I have OpenLDAP up and running, but if you could send me
>(not to the list I think...) twenty or so account
>specifications in the form above, that would be helpful.
>
I don't have 20 accounts to send you :)
but you can simply modify some attributes of the one before...
make your .ldif and add it.
If not yet done, try gq (gnome or kde ldap browser, don't remember) or
ldapbrowser, a java browser, very usefull.
Cheers,
Prune
--------------040403080402020803080606
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<html>
<head>
</head>
<body>
<blockquote type="cite" cite="mid:20020221101104.GA6859@aquila.esc.cam.ac.uk">
<pre wrap=""><br><br></pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">/* auth_mysql_new_user_pass */<br><br>authcontext auth_mysql_new_user_pass(const char *user, const char *pass, <br>const char *host /* unused */) {<br>authcontext a = NULL;<br>char *local_part = NULL;<br>const char *domain;<br>char *filter = NULL;<br><br></pre>
</blockquote>
<pre wrap=""> [...]<br><br></pre>
<blockquote type="cite">
<pre wrap=""> /* we split the login and the domain from the email style login given <br> by the user */<br> domain = user + strcspn(user, "@%!");<br> if (domain == user || !*domain) return NULL;<br> ++domain;<br> local_part = xmalloc(domain - user);<br> if (!local_part) return NULL;<br> memset(local_part, 0, domain - user);<br> strncpy(local_part, user, domain - user - 1);<br><br></pre>
</blockquote>
<pre wrap="">- Secondly, you never use the domain in constructing the<br> query against the directory. How do you specify the<br> existence of accounts in more than one domain?<br><br></pre>
</blockquote>
<pre wrap="">you're right.<br>I search for the email address (unique, containing the domain). I use <br>'user' to build ldap filter. 'user' is the mail+domain or whatever is <br>typed by the user.<br></pre>
</blockquote>
<pre wrap=""><!----><br>Ah, OK. Is this the normal procedure with LDAP? I had<br>understood that you were expected to build heirachical<br>directories....</pre>
</blockquote>
this is hierarchical.<br>
you go down to the directory and seek for the user DN having the attribute
requested in the search filter.<br>
Then you get his DN. The DN is unique. it's your duty to make the search
filter to find a unique entry.<br>
<blockquote type="cite" cite="mid:20020221101104.GA6859@aquila.esc.cam.ac.uk">
<pre wrap=""><br><br>Is LDAP case-sensitive?</pre>
</blockquote>
globally no. It can be changed or depend on which attribute you're requesting.
but, no. search filters are not case sensitive.<br>
<blockquote type="cite" cite="mid:20020221101104.GA6859@aquila.esc.cam.ac.uk">
<pre wrap=""><br><br><br>You establish whether the user has credentials on the<br>mailbox by seeing whether they can bind (roughly<br>equivalent to `log in', right?) to the LDAP server. Is<br>this the normal approach? (I had assumed that one would<br>have an attribute which contains a password hash -- as<br>auth-mysql does -- and then test that explicitly.)</pre>
</blockquote>
You can do both. getting the password and testing is the "old way" of doing.
At least, I think....<br>
Doing a bind is better as the auth scheme depends on the ldap server, and
not on what you've coded into your plugin.<br>
Some disallow users to be able to bind to the server.... that's a problem.
But there are no problem of letting them bind. Good ACL will disallow then
from seeing/modifying data in the ldap server. A good firewall rule will
also block connection to the ldap server from internet :)<br>
Some ldap auth plugins offer both auth methode (bind and password check).
I've only worked on the bind methode as it's the best and more robust.<br>
You have to understand that a bind is something really common with ldap.
it's built in feature. it checks against the "userPassword" attribute.<br>
<blockquote type="cite" cite="mid:20020221101104.GA6859@aquila.esc.cam.ac.uk">
<pre wrap=""><br><br><br></pre>
<blockquote type="cite">
<pre wrap="">Release the new tpop3d, and I'll work on this. it's simple to change.<br>Maybe you would like to have access to my test ldap server ?<br></pre>
</blockquote>
<pre wrap=""><!----><br>I have OpenLDAP up and running, but if you could send me<br>(not to the list I think...) twenty or so account<br>specifications in the form above, that would be helpful.<br><br></pre>
</blockquote>
I don't have 20 accounts to send you :)<br>
but you can simply modify some attributes of the one before...<br>
make your .ldif and add it.<br>
<br>
If not yet done, try gq (gnome or kde ldap browser, don't remember) or ldapbrowser,
a java browser, very usefull.<br>
Cheers,<br>
<br>
Prune<br>
</body>
</html>
--------------040403080402020803080606--