Adambean / gitlab-ce-ldap-sync

Synchronise users and groups (including group members) from an LDAP instance with Gitlab CE (and EE in free tier) self-hosted instance(s).
Apache License 2.0
59 stars 23 forks source link

Filter by attributes #27

Open kleyoneo opened 2 years ago

kleyoneo commented 2 years ago

Hi,

Is it possible to use filter with attributes instead objects ? For example userFilter: (&(attrib1=x)(attrib2=y))

In my cas it doesn't work.

Thanks

Adambean commented 2 years ago

Yes, that should be very possible. userFilter is just passed across, so if you're not getting any results use the very verbose option -vv to potentially see why, or try the same query in another LDAP utility.

If you switch to the master branch instead of a release I've just committed two debug messages to help you with this. Use very very verbose option -vvv to see these and you'll see "Retrieving users" and "Retrieving groups" debug messages showing you the base DN, filter, and attributes used for each query.

kleyoneo commented 2 years ago

ok thank you. I'm using master branch now. And I found out that the mistake is my fault : In baseDn parameter I added userDn .....

Now retrieving LDAP users is ok, but I've a cURL error : Gitlab failure: cURL error 60: SSL certificate problem: unable to get local issuer certificate

I think it's because of I'm behind a proxy. But even I configure environment variable it doesn't work. any idea ?

Adambean commented 2 years ago

That sounds like a certificate chain trust issue, which is external to this tool. (This uses trust from your system's cryptographic framework.)

Common causes are self signed certificates untrusted by the system (including self/corporate CAs) or the end entity certificate hasn't been stapled with its parent issuer correctly, meaning the trusted root can't be determined.

kleyoneo commented 2 years ago

You were right, it's a certificate issue. I don't use a self-signed certificate, but the Certificate Chain File was missing in my configuration.

Now I'm making progress but with another error :-( : [error] Gitlab failure: "public_email" must be an email you have verified

I don't know if I will succeed ! :-(

Adambean commented 2 years ago

That came from a change to the Gitlab API only allowing us to set the public email address of an account that is already verified, which is quite silly. Related: #21

What message appears before that problem? It'll either be "Creating Gitlab user" or "Updating Gitlab user #".

kleyoneo commented 2 years ago

Ouch. Silly indeed...

The error appears after "Creating Gitlab user" message.

Adambean commented 2 years ago

That's an incredibly strange quirk of the Gitlab platform... I'm not in a position to test this right now but you may want to edit src/LdapSyncCommand.php and change "public_email" to "email". As of right now this is line 1213 and looks like this:

!$this->dryRun ? ($gitlabUser = $gitlab->api("users")->create($ldapUserDetails["email"], $gitlabUserPassword, [
    "username"          => $gitlabUserName,
    "reset_password"    => false,
    "name"              => $ldapUserDetails["fullName"],
    "extern_uid"        => $ldapUserDetails["dn"],
    "provider"          => $gitlabConfig["ldapServerName"],
    "public_email"      => $ldapUserDetails["email"],
    "admin"             => $ldapUserDetails["isAdmin"],
    "can_create_group"  => $ldapUserDetails["isAdmin"],
    "skip_confirmation" => true,
    "external"          => $ldapUserDetails["isExternal"],
])) : $this->logger->warning("Operation skipped due to dry run.");

Change "public_email" => $ldapUserDetails["email"], to "email" => $ldapUserDetails["email"],, save, and run again. Gitlab may well throw an error that the account has no public email address though!

!$this->dryRun ? ($gitlabUser = $gitlab->api("users")->create($ldapUserDetails["email"], $gitlabUserPassword, [
    "username"          => $gitlabUserName,
    "reset_password"    => false,
    "name"              => $ldapUserDetails["fullName"],
    "extern_uid"        => $ldapUserDetails["dn"],
    "provider"          => $gitlabConfig["ldapServerName"],
    "email"             => $ldapUserDetails["email"],
    "admin"             => $ldapUserDetails["isAdmin"],
    "can_create_group"  => $ldapUserDetails["isAdmin"],
    "skip_confirmation" => true,
    "external"          => $ldapUserDetails["isExternal"],
])) : $this->logger->warning("Operation skipped due to dry run.");
kleyoneo commented 2 years ago

ok, it works by changing public_email by email :-)

Once all users have been created, there is this error : Gitlab failure: 403 Forbidden - LDAP blocked users cannot be modified by the API

My token is "full privileges". Is it another gitlab blocking ?

Adambean commented 2 years ago

That is also external to this tool. Searching for "LDAP blocked users cannot be modified by the API" brings up this which may be of use: https://stackoverflow.com/questions/40990190/how-do-i-unblock-ldap-users-in-gitlab-ce

kleyoneo commented 2 years ago

Some users was blocked indeed. Unblocking this users remove this error.

Now, all news users are well created. Existing users are updated... until "Gitlab failure: 403 Forbidden"

Forbidden but why ? :-(

Adambean commented 2 years ago

There's limited knowledge this tool can provide on that as the 403 error is returned by the Gitlab API. You may get more information by increasing verbosity (-vv), otherwise you'd need to check your Gitlab's access log for a more specific reason. The API token you've generated may not have permission to edit users for example.