dalibo
How to force the use of simple authentication (/binddn) instead of SASL
Hi,
When I use ldapsearch to test my connection, all works fine using the -x and -D switches (Simple authentication with binddn), but when connecting using SASL, does not seem to work.
How can I force ldap2pg to use simple authentication with binddn, similar to the ldapsearch swith combination -x and -D?
Can you share verbose output ? Does comment https://github.com/dalibo/ldap2pg/issues/390#issuecomment-974093715 help you ?
Yeah, this part of the comment you refer to, did help:
You should not define both user (for SASL) and binddn (for simple bind)
So, when regarding this bit of the configuration:
#########################################
ldap:
uri: ldap://somedomain.company.com
binddn: CN=username,OU=Users,OU=Global,DC=somedomain,DC=company,DC=com
#For SASL
#user: username
password: somepassword
#########################################
When the "user:"-line is activated, SASL is used, when it's inactivated like in this example, simple binddn is used. Meanwhile the password is used in both cases.
Pretty simple and straight forward, but I didn't get that from the inline comments or the online documentation. Perhaps something to improve.....
Thanks!
@arjan-saly-tfs I really advice you to not configure LDAP in the yml but using ldaprc and envvar, so that ldap2pg and ldapsearch are configured at the same time. This helps a lot.
@bersace What's the reason for this advice, what are your arguments?
To explain my reasons for preferring this in the yml (apart from that it's easy testing): When using ldaprc there's only one LDAP connection definition defined for a linux user (ldaprc). Then it's much harder to work with different ldap users for query (referring to #409) as that would require two different linux users for each schedule.
Not sure what you mean by envvar in this case. I could use user-level environment variables, if that's what you mean. Could be an option, but makes it more complex to roll out and maintain on multiple servers (with multiple settings) by operations who has limited linux knowledge. Prefer to keep it as simple as possible by simply providing an installation guide and a couple of configuration files. Using user-level environment variables brings either a command to execute that's harder to read and thus harder to maintain, or it brings additional steps of adding rows to the linux user config file. All can be scripted, but I prefer to KISS.
There's also a unix/OS-environment-level setting using an environment file, which is a no-go as the file is required to be readable by the "world". No way I will get permission from our security office to store a password in such a file.
To be honest, I explored and tested the various options that are described in the ldap2pg manual and putting all in the yml file really suites our situation best...... Which is why I really like to know your reasons for advising not to configure LDAP in yml as it might shine a different light on things.
Hi @arjan-saly-tfs , thanks for the answer.
When using ldaprc there's only one LDAP connection definition defined for a linux user (ldaprc)
Can't you have multiple ldaprc files and choose the one you need using LDAPRC or LDAPCONF environment variables ? man 5 ldap.conf may help you.
Not sure what you mean by envvar in this case. I could use user-level environment variables, if that's what you mean.
I don't know what is user-level environment variables. Usually, a script wraps ldap2pg execution to load and/or define environment variables, eventually generates a dynamic configuration before lauching ldap2pg.
Environment variables saved in a file has the same security level as a configuration file. Its just about shell vs yaml. Anyway, you may have constraint for security team preventing you from using environment variables, that's fair.
To be honest, I explored and tested the various options that are described in the ldap2pg manual and putting all in the yml file really suites our situation best......
That's fine. I juste wanted to challenge your choice. I always suggest configuration from env var and ldaprc because it's shared with openldap utils, its more complete because ldap2pg does not handle all possible ldap.conf parameter from yaml. It's not very valuable to add one more configuration handling.
Regarding the original description, I'm wondering if ldap2pg should have an explicit option to use simple auth like -x cli switch of ldap utils.
Regarding the original description, I'm wondering if ldap2pg should have an explicit option to use simple auth like
-xcli switch of ldap utils.
I think that would at least be much clearer.
On the other hand, if current behavior would be documented/explained inline in the ldap2pg.yml file, that would probably work as well....
@arjan-saly-tfs does the last section at https://ldap2pg.readthedocs.io/en/latest/ldap/ helps you ?
Looks to me there are two ways of forcing Simple Bind. I had tried leaving SASL_MECH empty, but that didn't work for me. Perhaps I did something wrong there.
For me, the solution was found in putting a hashtag (#) before the "username:" line the ldap: section:
#########################################
ldap:
uri: ldap://somedomain.company.com
binddn: CN=username,OU=Users,OU=Global,DC=somedomain,DC=company,DC=com
#For SASL
#user: username <== This line is commented-out, which forced binddn/simple bind for me
password: somepassword
#########################################
I know you're not in favor of specifying this information in the yml file. But especially for those not familiar with LDAP, it definitely is a very easy way to setup a working environment. And since you enforce chmod 600 on the file if it holds passwords, it's pretty safe as well as long as the ldap2pg is given its own user.
So, my tip would be to describe this as well, as a second option in the same section (https://ldap2pg.readthedocs.io/en/latest/ldap/#forcing-simple-bind).
So, my tip would be to describe this as well, as a second option in the same section (https://ldap2pg.readthedocs.io/en/latest/ldap/#forcing-simple-bind).
Ok, I'll review this. Reopening.