Issues synchronizing LDAP groups (Active Directory)

[pamadmax]

I'm currently clueless as to how to synchronize ldap groups. I am currently running Active Directory on Server 2019. I have every app in my organization synchronize with AD via LDAP. I am curious as to what my Filter, ID Attribute, Group Attribute, and User Attribute should be. I'm a little new with LDAP. Without a tutorial, I am lost. Thanks in advance!

[ronivay]

Plugin configuration has good examples for those attributes. There really is no tutorial for your specific environment, depends how your AD is setup. If you have other applications setup with ldap, try to look for hints from their configuration. Note that it does not sync users, they’re being created on successful login after plugin is configured properly and activated.

[Kajetan321]

@pamadmax Guess what? I'm facing the exact same problem and if I don't get this going I'm going to be in trouble with my boss!

Install this on your computer to help figure out your LDAP URL
http://www.ldapbrowser.com/download.htm
Select: Softerra LDAP Browser

Connect to your AD domain LDAP with this software.
Verify you can brows the contents of LDAP with in the software.
On the left most pain, you should see an entry for your Windows LDAP.
Right click on it and select properties.
In the profile tab you should see your LDAP URL.

[Kajetan321]

This post is deleted!

[olivierlambert]

This is a pretty advanced question. @pdonias will take a look when he's back from holidays (if you are in a hurry, please create a support ticket with pro support)

[Kajetan321]

I will patiently wait for @pdonias to be back from holidays

[Kajetan321]

To troubleshoot, I have installed ldapsearch on XOA via ssh (sudo apt-get install ldap-utils) and edited /etc/ldap/ldap.conf. After fine tuning some settings I was able to get ldapsearch to return results. When I attempt to use "the same" settings to configure the XOA LDAP plugin however, I get this in the logs: "could not authenticate user"

Here is what's inside my /etc/ldap/ldap.conf:

#
# LDAP Defaults
#

# See ldap.conf(5) for details
# This file should be world readable but not world writable.

#BASE   dc=example,dc=com
BASE   OU=Accounts,DC=lan,DC=company,DC=com

#URI    ldap://ldap.example.com ldap://ldap-provider.example.com:666
URI    ldaps://server.lan.company.com

#SIZELIMIT      12
#TIMELIMIT      15
#DEREF          never

# TLS certificates (needed for GnuTLS)
TLS_CACERT      /etc/ssl/certs/company_root.pem

Executing this at the XOA command line I get a long list of entries pertaining to my AD users:

ldapsearch -H ldaps://server.lan.company.com -x -D user@lan.company.com -w password

My plugin settings are as follows:
ldaps://server.lan.company.com
/etc/ssl/certs/company_root.pem
Check certificate: Yes
Use StartTLS: off
Base: OU=Accounts,DC=lan,DC=company,DC=com

dn: user@lan.company.com
password: password
User filter: (uid={{name}})
ID attribute: dn

Any hints on how to trouble shoot this further?

[pdonias]

Hi @kajetan321, please add this to your xo-server config file:

[logs]
level = 'debug'

then test the plugin again and check xo-server's output when the error occurs to help identify what's causing the issue.

[Kajetan321]

@pdonias Thanks for getting back to me. I enabled debug level under logs and rebooted the VM. Here is what the logs show:

Jan 12 17:37:05 xoa xo-server[536]: 2022-01-12T22:37:05.296Z xo:xo-server-auth-ldap DEBUG attempting to bind with as user@lan.company.com...
Jan 12 17:37:05 xoa xo-server[536]: 2022-01-12T22:37:05.313Z xo:xo-server-auth-ldap DEBUG successfully bound as user@lan.company.com
Jan 12 17:37:05 xoa xo-server[536]: 2022-01-12T22:37:05.314Z xo:xo-server-auth-ldap DEBUG searching for entries...
Jan 12 17:37:05 xoa xo-server[536]: 2022-01-12T22:37:05.336Z xo:xo-server-auth-ldap DEBUG 0 entries found
Jan 12 17:37:05 xoa xo-server[536]: 2022-01-12T22:37:05.336Z xo:xo-server-auth-ldap DEBUG could not authenticate user@lan.company.com
Jan 12 17:37:05 xoa xo-server[536]: 2022-01-12T22:37:05.373Z xo:api WARN user | plugin.test(...) [89ms] =!> Error: could not authenticate user

I copied and pasted the user name and password from the ldapsearch command. Ldapsearch command still works.

[TheNorthernLight]

@kajetan321 So I literally got this to work this afternoon after lots of fiddling around (and trying several different "working" configs).

I ended up doing:
url: ldap://10.10.x.x:389/
check cert = OFF
Use StartTLS = OFF
base= DC=company,DC=com
Credentials:
dn = adqueryaccount@company.com
password = ....
user filter=(userPrincipalName={{name}})
ID Attribute= dn

The part that tripped me up forever was the Credential DN. I was putting all sorts of values, not realizing the simple UPN would work. Also the user used to query AD, needs to have the matching UPN suffix as your regular users. My account was defaulted to an internal .lan domain. It kept failing. As soon as I changed its UPN to match my corporate.com domain, everything started working.

You can test this, by simply using YOUR domain admin username/psw in the dn and password sections to test with. This eliminates the username being the source of the problems.

[olivierlambert]

That's the issue with LDAP configuration: there's nothing we can do on our side to make it work "out of the box", since it's 100% dependent on each LDAP server configuration

[Kajetan321]

@thenorthernlight Thanks! It appears I had two problems with the configuration I posted earlier that were causing the Test plugin to fail:

Use StartTLS should be off
User filter should be (userPrincipalName={{name}})

Now onto testing if actual AD logons are working.

Cheers.

[Kajetan321]

@olivierlambert May I propose a Windows Active Directory plugin? It should only require the domain name and credentials to "join the domain". I believe Synology has this setup, as does QNAP. I would strongly suspect that Windows Server has a specific way of setup up LDAP if using defaults during install. I believe I read on Phoronix that Ubuntu now supports "joining the domain" during the install process as well. By "joining the domain" I mean automatic LDAP configuration and domain controller root certificate should be added XO's trusted certificates.

For someone like me who never really dealt with or set up LDAP, this would make XO way more appealing to use. Just my two cents.

Thank you for all your work, other than this I'm really impressed with XO, especially the backups!

Cheers.

[olivierlambert]

Thanks for the feedback @Kajetan321 However, I have 0 idea on what it means and how it would work. Assistance will be welcome.

[cjackson]

I had a lot of trouble getting the LDAP integration to work with Active Directory domain controllers, So i wanted to share my configuration and make it easier on others trying to do the same thing in the future.

Using this config i was able to get everything working, but i found a few limitations:

1. Xen Orchestra cannot find any group members where the member has the "Primary Group" attribute set.
2. Only direct members of a group are recognized (nested groups don't work).
3. When signing in, i have to specify "username" instead of "username@cxlab.domain.com"
4. Groups are created by clicking "Synchronize LDAP groups", however users are not created until they sign into XOA the first time.
5. Users are not deleted from Xen Orchestra when they are removed from the domain. (but they can no longer log in to XOA)

---

auth-ldap (v0.10.6) - LDAP authentication plugin for XO-Server
Auto-load at server start [checked]

Configuration

URI: ldap://domaincontroller1.cxlab.domain.com

  **Certificate Authorities**
  Check certificate [disabled]
  Use StartTLS [disabled]
  Base: DC=cxlab,DC=domain,DC=com

  **Credentials**
  dn: cxadmin@cxlab.domain.com
  password: ******************

User filter: (sAMAccountName={{name}})
ID attribute: dn

  **Synchronize groups**
  [checked] Fill information (optional)
  Base: CN=Users,DC=cxlab,DC=domain,DC=com
  Filter: (ObjectClass=group)
  ID attribute: dn
  Display name attribute: cn

    **Members mapping**
    Group attribute: member
    User attribute: dn

---

[TheNorthernLight]

@cjackson The reason the login is just username, is because you've specified sAMAccountName. If you want to use email address, change this to UserPrincipleName. Obviously, verify the UPN in your AD box, but that should be the persons email address if your domain it setup correctly.

I dont believe most LDAP query tools support nested group security (its a common issue). Not an excuse, just an observation btw.