XO Community Edition - Ldap Plugin not working ?
-
Hi
i've set up xen orchestra community edition for my lab, to test XCP-NG and XO.installation from source is ok, i managed to set tup storage, backup, and Vm running.
But, i would like to set up ldap authentification, and only allow a specific group on my AD to connect to xen orchestra.our Ldap is strikly internal, not certificate.
is set up like this
URI : ldap://my-dc-01.corp.net:389
check certificat and use tls not checked.
base : dn=corp,dn=net
Credential : service_account@corp.net with it's password
user Filter
This where maybe i miss something
i put : (&(sAMAccountName={{name}})(memberOf="VMAdmin"))Id Attribute : sAMAccountName
When i test data with my user in the VMAdmin group, i got this error :
Code: -32000 Message: 000020D6: SvcErr: DSID-03100836, problem 5012 (DIR_ERROR), data 0 Code: 0x1 { "code": 1, "message": "000020D6: SvcErr: DSID-03100836, problem 5012 (DIR_ERROR), data 0\n\u0000 Code: 0x1", "name": "Error", "stack": "Error: 000020D6: SvcErr: DSID-03100836, problem 5012 (DIR_ERROR), data 0\n\u0000 Code: 0x1\n at Function.parse (/opt/xen-orchestra/node_modules/ldapts/StatusCodeParser.ts:55:16)\n at Client._sendSearch (/opt/xen-orchestra/node_modules/ldapts/Client.ts:648:30)\n at Client.search (/opt/xen-orchestra/node_modules/ldapts/Client.ts:610:5)\n at AuthLdap._authenticate (/opt/xen-orchestra/packages/xo-server-auth-ldap/src/index.js:277:42)\n at default.testPlugin (file:///opt/xen-orchestra/packages/xo-server/src/xo-mixins/plugins.mjs:285:5)\n at Xo.test (file:///opt/xen-orchestra/packages/xo-server/src/api/plugin.mjs:109:3)\n at Task.runInside (/opt/xen-orchestra/@vates/task/index.js:172:22)\n at Task.run (/opt/xen-orchestra/@vates/task/index.js:156:20)\n at Api.#callApiMethod (file:///opt/xen-orchestra/packages/xo-server/src/xo-mixins/api.mjs:469:18)" }
-
@Chico008 I, too, ran into some issues getting it to work on XOC. It did for about a month or two then stopped working and I haven't messed with it anymore.
However, I'm doing a proof-of-concept now using the air-gapped variant of XOA and I got it to work against an Active Directory domain controller on the first try. I'm not entirely sure what the difference is, but here's my working configuration - in case it helps you out:
URI: ldap://DC01:389 Certificate Authorities (left blank) Check certificate = No Use StartTLS = No Base: OU=Users,OU=LabNET,DC=LabNET,DC=local Credentials (fill this out) dn: "Put here the Distinguished Name of whichever account you're using to bind to AD" password: "goes without saying" User filter: (&(sAMAccountName=({name}))(memberOf=CN=XenOrchestra_Admins,OU=Groups,OU=LabNET,DC=LabNET,DC=local)) ID attribute: sAMAccountName Synchronize groups (fill this in if you want to control login based on group membership) Base: OU=Groups,OU=LabNET,DC=LabNET,DC=local Filter: (objectClass=group) ID attribute: dn Display name attribute: cn Members mapping (fill this out) Group attribute: member User attribute: dn
With this, I am able to sync the AD Groups into XOA, limit login to only users matching the
User filter
, and then use the ACLs to assign permissions to the group in XOA. Hope it helps you out. -
@Chico008 Just wanted to provide another update.
I just installed a fresh copy of XOC and tried the same LDAP settings I have shared above (which worked in XOA on the first try) against my AD environment at church and it fails to connect.
So looks like something has been done in XOA that hasn't been shared with XOC. Or that my AD environment is the problem - although that would mean that other applications that I have successfully integrated with AD shouldn't be working either (things like OpenNMS, Debian, RHEL, etc.).
If someone has a working configuration for the LDAP plugin in XOC they'd like to share, please do.
-
Hi,
I have XO CE (built from sources on a 09/24 commit) and I use the LDAP plugin connected to a Samba4 AD controller running on Debian. I'm not sure how different it is from a real Windows AD DC.My config is working and looks like this :
URI : ldap://IPv4:389 check certificate : no use starttls : yes Base : OU=MyOU,DC=company,DC=tld DN : username : CN=serviceaccount,OU=MyOU,DC=company,DC=tld password : the service account password user filter : (&(cn={{name}}) memberOf=CN=ADMIN_AD_GROUP,OU=Groups,DC=company,DC=tld)) ID attribute : cn
-
@ilyazam Thanks for sharing your config. I think the main difference for an AD environment would be the use of
sAMAccountName
vscn
.Looking at your settings, I think the only difference I see with mine is that you have
Use StartTLS : yes
, and you aren't synching Groups.The strange thing for me, though, is that it worked at some point (unfortunately I cannot recall those conditions at the time). I suspect that perhaps there's a special character in the passwords being used that's not being properly escaped and causes the underlying code that makes the LDAP Query not to execute properly. I say this because when I look at a Wireshark capture on the DC, the bind is successful but the query returns no results.
There's got to be something different about how XOA handles the LDAP query vs how XOCE handles it.
-
There isn't, it's the same code except the fact there's no stable version on the sources. I don't think we made any recent change there
-
@olivierlambert Certainly strange, then, that the same settings and same plugin works in XOA but not in XOCE. We could argue perhaps some configuration variances within the Domain Controllers, but given that I'm the same person that configured both environments - I'm highly confident that I stood up the DCs in the same way. Only things that would obviously be different would be the Domain Name and OU Structure.
I'll confirm the Forest and Domain functional levels later this evening and perhaps run an XOA trial and see if it works. I'll report back.
-
Perfect, keep us posted
-
@olivierlambert Of course, I'll spin it up now.
-
@olivierlambert My attempts to deploy XOA via https://vates.tech/deploy/ has failed (twice now). Each time, the deployment gets to about 80% and then errors out (with a very vague message).
However, when I go back into the VM listing in XOCE, I see an XOA VM listed but not running. If I attempt to start it, it will hang at 83% starting then eventually the VM gets deleted (not sure how long cos I wasn't tracking).
-
Are you using DHCP or static IP?
-
@olivierlambert DHCP. I could retry using static?
-
Sure, also double check you are selecting the right network. You can read logs to try to understand what's going on.
-
@olivierlambert Which logs please? I'm still learning so not familiar with where all the logs are, outside of what I see within XO - and those errors are very vague.
-
@olivierlambert I have tried deploying XOA using a static IP and the result is the same. It fails after 80% completion, with that exclamation sign. As before, I see the VM on the host but it does not have the IP address I set and it does not start (hangs at 83%).
Any other way I can get XOA?
-
@olivierlambert So after resolving the control domain space issues, I was able to successfully deploy XOA to the same host and wanted to test out the LDAP settings on XOA, but noticed that only two plugins come loaded with the install:
How do I install the LDAP plugin?
-
You need to start a trial
-
@olivierlambert I tried to but got a message that I've already consumed my trial. I did I did a trial a couple of years back when I was first introduced to XCP-ng, can't recall exactly.
Would it be possible to grant me another trial? If so, my account is tied to kagbasi [AT] wgsdac.org
-
New trial generated
-
@olivierlambert Thanks for extending the trial, much appreciated. I was able to activate the auth-ldap plugin (v0.10.10) with the same settings I used in my XOCE instance and it failed the test, even though the Wireshark capture seems to suggest the bind was successful.
ERROR MESSAGE IN XOA:
plugin.test { "id": "auth-ldap", "data": { "username": "yykagbasi", "password": "* obfuscated *" } } { "message": "Illegal unescaped character: ( in value: ({name}", "name": "Error", "stack": "Error: Illegal unescaped character: ( in value: ({name} at Function._unescapeHexValues (/opt/xo/xo-builds/xen-orchestra-202412100608/node_modules/ldapts/FilterParser.ts:334:17) at Function._parseExpressionFilterFromString (/opt/xo/xo-builds/xen-orchestra-202412100608/node_modules/ldapts/FilterParser.ts:247:29) at Function._parseString (/opt/xo/xo-builds/xen-orchestra-202412100608/node_modules/ldapts/FilterParser.ts:198:31) at Function._parseString (/opt/xo/xo-builds/xen-orchestra-202412100608/node_modules/ldapts/FilterParser.ts:154:44) at Function.parseString (/opt/xo/xo-builds/xen-orchestra-202412100608/node_modules/ldapts/FilterParser.ts:31:38) at Client.search (/opt/xo/xo-builds/xen-orchestra-202412100608/node_modules/ldapts/Client.ts:584:31) at AuthLdap._authenticate (/opt/xo/xo-builds/xen-orchestra-202412100608/packages/xo-server-auth-ldap/src/index.js:277:55) at default.testPlugin (file:///opt/xo/xo-builds/xen-orchestra-202412100608/packages/xo-server/src/xo-mixins/plugins.mjs:285:5) at Xo.test (file:///opt/xo/xo-builds/xen-orchestra-202412100608/packages/xo-server/src/api/plugin.mjs:109:3) at Task.runInside (/opt/xo/xo-builds/xen-orchestra-202412100608/@vates/task/index.js:172:22) at Task.run (/opt/xo/xo-builds/xen-orchestra-202412100608/@vates/task/index.js:156:20) at Api.#callApiMethod (file:///opt/xo/xo-builds/xen-orchestra-202412100608/packages/xo-server/src/xo-mixins/api.mjs:469:18)" }
WIRESHARK CAPTURE: