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(a)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.
>>
>>