Ok, that would take some customization to support doing a lookup by distinguished name first, and then using that record's sAMAccountName to bind with. Are the distinguished names and sAMAccountName values so different that you need to do that extra lookup? I mean, couldn't a user type in the DN that is used to bind with?
If you wanted, the Allura authentication methods are customizable and pluggable. You could write a custom one that extends LdapAuthenticationProvider and overrides just the _validate_password() function and maybe a few more that use ldap_conn() to do it the way you need. Or if this is a common situation (I haven't heard of it before but am not super familiar with different LDAP scenarios) then more config options and logic within the standard LdapAuthenticationProvider would be a nice enhancement for Allura. On 6/9/20 12:41 AM, Tony Hung wrote: > Hi Dave > Thanks for the reply > > I am trying to use Windows AD as my LDAP server. Here is the scenario > > 1. Connect to AD with the pre-set user (which is "auth.ldap.admin_dn" ). > 2. Query active directory with the pre-set user's credentials and search for > the distinguished name > 3. based on the sAMAccountName that the user will enter as their "username" > in Allura login page. > 4. Attempt to connect again to Active Directory using the distinguished name > from step 2, and the password that the user entered in login page. > If this connection is successful, then the user is authenticated. > > I only found the Allura sent [uid="username","DC=xxx,DC=xxxx,DC=xxx] during > BindRequest > > > On 2020/06/08 22:17:14, Dave Brondsema <d...@brondsema.net> wrote: >> Hello! >> >> Our LDAP authorization module offers some configuration options, but not >> enough >> to do what you want I think. Allura uses "auth.ldap.admin_dn" to bind in >> some >> situations, but for validating and setting passwords, it uses the current >> user. >> Does that not work for your LDAP setup? How would you want it to work? >> >> The schroot_name option only works if you have use_schroot enabled and >> requires >> various other installations requirements documented at >> https://forge-allura.apache.org/docs/getting_started/scm_host_ssh.html That >> process hasn't been used by anyone for a while, and I am not familiar with >> it, >> so it likely won't work. IIRC its main purpose was to make code repositories >> share authentication with Allura (and there are other options for that too). >> >> I've seen the python version mismatch message too. I think it is just >> informative, its never caused any problems that I know of. >> >> -Dave >> >> On 6/5/20 6:31 AM, Tony Hung wrote: >>> 1. When I use LDAP as my authentication method. The Allura sent user login >>> credential to LDAP instead of sent the "auth.ldap.schroot_name" I put in >>> the "development.ini" during Ldap bind request step. I think the user ID >>> should be send after bind request success. >>> >>> 2. When I use command "docker-compose logs http" >>> It seems apache python module is conflict with python version. >>> >>> [:error] [pid 1:tid 139749974105024] python_init: Python version mismatch, >>> expected '2.7.6', found '2.7.17'. >>> [:error] [pid 1:tid 139749974105024] python_init: Python executable found >>> '/usr/bin/python'. >>> [:error] [pid 1:tid 139749974105024] python_init: Python path being used >>> '/usr/lib/python2.7:/usr/lib/python2.7/plat-x86_64-linux-gnu:/usr/lib/python2.7/lib-tk:/usr/lib/python2.7/lib-old:/usr/lib/python2.7/lib-dynload'. >>> >> >> >> -- >> Dave Brondsema : d...@brondsema.net >> http://www.brondsema.net : personal >> http://www.splike.com : programming >> <>< >> > -- Dave Brondsema : d...@brondsema.net http://www.brondsema.net : personal http://www.splike.com : programming <><
