Login Differences Between DN and CN with LDAP
Novell Cool Solutions: Trench
Digg This -
Posted: 18 Sep 2003
In the Authentication Profile, if you set up authentication using the LDAP login format of Field Name (use of CN, for example) with multiple LDAP Search bases, will the HTTP authentication header still use the username in DN format? What are the significant differences between the User DN or using CN as the login format of Field Name in the LDAP authentication setting?
As for difference between using DN or FN for the LDAP profile. Here's a brief summary from what has been found when packet tracing the behavior.
With this,the admin configures some contexts. During login the user provides a CN with password and can optionally select the context from the drop down box.
- - If the context is selected, iChain adds the CN to the context to make a DN. It then makes a named LDAP bind using the DN and the user-supplied password. If LDAP returns a successful response then iChain knows the credentials are OK - i.e. authentication is OK. Note, no LDAP searching is done.
- - IF the user does not select the context, then iChain adds the supplied CN to the first context to make a DN and tries the bind as above. If successful, iChain assumes that the DN is correct and authentication is successful. If the bind fails, iChain makes a new DN out of the next context in the list and retries the bind. It will continue to work through all contexts until they have all failed or one succeeds.
- Simple, no LDAP searching so little load on LDAP server.
- If 2 users have the same CN and the SAME password (HIGHLY unlikely) then iChain will assume the user is the first DN that matches (ie. in the context nearer the top of the list).
- Not suitable for many contexts as may involve many LDAP binds.
Obviously, put the contexts with most users near the top of the list.
Field Name Method:
In this case, the admin configures a searchbase and specifies a UNIQUE field name (maybe email or EmployeeID). If CN is used (the default) then you MUST ensure that it is unique. During a login, the user supplies the attribute value (e.g. CN=mday) and password. iChain binds using a service account and performs an LDAP search looking for DNs that match e.g. "Find any DN for which CN=mday". If multiple DNs are found then iChain chokes -- which is why the attribute used must be unique -- we only want 1 DN returned.
Once iChain has the DN it then behaves in a similar way to Option 1 -- i.e. it tries a bind using the DN and the user-supplied password -- if successful then iChain assumes the supplied credentials are good.
- Can handle a very hierarchical tree with lots of user contexts. - Flexible -- can use any unique attribute.
- More work for the LDAP server. 1 user login involves at least 2 LDAP binds, and 1 LDAP search.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com