What about using a template like in java.text.Format object for ldap_bind_DN and ldap_bind_Password, user and password being parameters ldap_bind_DN = "DOMAIN\\{0}" ldap_bind_pass = "{1}"
this is better...
This way we only use one parameter to define binding strategy. In this case we still need to make a search to find DN in case we need to create the user in XWiki. Or we can also use a simple format such as : ldap_DN_format="CN={0},CN=Users,DC=domain,DC=com"
This won't for us because the DN format in our AD is: "CN={lastname} {firstname} {personalID},OU=Accounts,OU=All Users,DC=ad,DC=company,DC=cz" what about to allow to configure attribute=value pairs that will be used for DN search? E.g ldap_DN_filter="AMAccountName=luzny_j"?
For mapping LDAP/AD groups to XWiki group, I kind of postponed this task as it not so easy to provide a general LDAP solution.
One more reason to allow to plug a custom mapping logic ;-) On Fri, 29 Apr 2005 11:28:00 +0200, you wrote:
Hi Jiri,
The fact I didn't only bind the user to check the password is that in some case where directory structure is complex I can't guess the DN out of the user name...
Active directory allows more ways to authenticate user when binding: - Distinguished Name (only works with simple bind) - NT account name (domain\samAccountName) (always works with simple or secure bind) - UserPrincipalName (user@domain.com) (always works with simple or secure bind IF it is defined; is not required attribute) - sAMAcountName (user) (only works with AD secure bind)
Thanks for this information.
Anyway if in your case DN can be guessed out of user name, I think not setting ldap_bind_DN could do the trick
I cannot guess full DN because it consists of a company personal ID. What I use is the domain\samAccountName way where samAccountName equals to XWiki user name. Because the account name is combined name DOMAIN + "\" + USERNAME it would be nice if there is a new parameter introduced e.g. ldap_bind_addomain which will be then used when constructing userDN before using in the Bind method. Another problem of using a dedicated ldap_bind_DN (comparing to using of the user's DN only) is the need to have a special system account on AD which I can hardly imagine I will get it approved by our sys admins.
What about using a template like in java.text.Format object for ldap_bind_DN and ldap_bind_Password, user and password being parameters ldap_bind_DN = "DOMAIN\\{0}" ldap_bind_pass = "{1}" This way we only use one parameter to define binding strategy. In this case we still need to make a search to find DN in case we need to create the user in XWiki. Or we can also use a simple format such as : ldap_DN_format="CN={0},CN=Users,DC=domain,DC=com"
And beside I'll investigate into adding proper AD support (guess I'll have to install WS2003
I don't think there is another possibility than the introducing of a SSL stack, which is unnecessary overhead if you need just authentication and not changing of password, IMHO.
You're right, but in the future we may want to provide Xwiki > LDAP synchronization
As I don't want to bind twice, I use comparison of password (so I don't really read password).
Even for this comparison I get "attribute not find" from AD. I also was trying a more attributes names like "unicodePwd" but no success...
As for CreateUserFromLDAP, it's a very first version, and I'm looking for comments about it.
What would be interesting is to add a support of plugging custom mapping logic. We will need it for extracting a substring of an LDAP attribute and assigning user to a XWiki group based on LDAP grouping.
For mapping LDAP/AD groups to XWiki group, I kind of postponed this task as it not so easy to provide a general LDAP solution. There is no memberOf field in Open-LDAP for exemple, so in AD it is easier to find which groups a user belong (using his memberOf field).
Thank you, Jiri.