XO Team

@olivierlambert Yep, I think it's safe enough to turn on by default in the next release

This does not appear to be an XO issue, more a config issue, I don't have much time to investigate this any further, maybe the rest of the community can help on this.

Hi,

As written in the changelog, this is only implemented for full backups for now, not for deltas.

@wesleylc1 For the upgrade, you need to ask the people behind the install script you used.

Concerning the output, it will only show the entry if the authentication was successful, that's why you need to start by using the default filter.

@wesleylc1 I'm not an expert, but it's a standard LDAP filter which is evaluated by the LDAP server, no special handling is done by the plugin itself.

It depends how you installed it, unfortunately I cannot help you for this.

Once you've upgrade to the latest version, use the default filter to authenticate the user and then you will see what fields it contains, then you will be able to write the correct filter.

@wesleylc1 It really depends of the structure of your LDAP server.

I've just committed a new version of the plugin which makes the test CLI displays the matched entry on success, this helps figuring out what should be put in the filter field.

Example:

$ xo-server-auth-ldap
? uri ldap://ldap.company.net
? fill optional certificateAuthorities? No
? fill optional checkCertificate? No
? fill optional bind? No
? base ou=people,dc=company,dc=net
? fill optional filter? No
configuration saved in ./ldap.cache.conf
? Username john.smith
? Password [hidden]
searching for entries...
.
1 entries found
attempting to bind as uid=john.smith,ou=people,dc=company,dc=net
successfully bound as uid=john.smith,ou=people,dc=company,dc=net => john.smith authenticated
{
  "messageID": 1,
  "protocolOp": "SearchEntry",
  "objectName": "uid=john.smith,ou=people,dc=company,dc=net",
  "attributes": [
    {
      "type": "cn",
      "vals": [
        "John Smith"
      ]
    },
    {
      "type": "gidNumber",
      "vals": [
        "10000"
      ]
    },
    {
      "type": "givenName",
      "vals": [
        "John"
      ]
    },
    {
      "type": "homeDirectory",
      "vals": [
        "/home/john.smith"
      ]
    },
    {
      "type": "initials",
      "vals": [
        "JSH"
      ]
    },
    {
      "type": "loginShell",
      "vals": [
        "/bin/bash"
      ]
    },
    {
      "type": "mail",
      "vals": [
        "john.smith@company.net"
      ]
    },
    {
      "type": "objectClass",
      "vals": [
        "posixAccount",
        "inetOrgPerson",
        "organizationalPerson",
        "person"
      ]
    },
    {
      "type": "sn",
      "vals": [
        "Smith"
      ]
    },
    {
      "type": "uid",
      "vals": [
        "john.smith"
      ]
    },
    {
      "type": "uidNumber",
      "vals": [
        "10000"
      ]
    }
  ],
  "controls": []
}

@wesleylc1 As @olivierlambert said, this is an LDAP config issue, you need to know the structure of your LDAP server.

The auth-ldap plugin comes with a CLI which is useful to test various configuration and figure out what is wrong:

$ /usr/local/lib/node_modules/xo-server-auth-ldap/dist/test-cli.js
? uri 

This should be fixed on master: https://github.com/vatesfr/xen-orchestra/commit/e171d8ed0e786772c9ccdb7dd4127d42faae141a

0 julien-f committed to vatesfr/xen-orchestra

fix(xo-server/vm.set): add `auto_poweron` to params

Related to b8524732ce5fc466ef73664ff02cd4e09fca7ad9

Fixes #4295

@olivierlambert Is the new XOA deployed on xoa.io?