search

glauth / glauth

A lightweight LDAP server for development, home use, or CI
MIT License
2.46k stars 218 forks source link

Implement SASL #159

Open mildred opened 4 years ago

mildred commented 4 years ago

glauth is not able to receive bind requests using SASL as per RFC 4513 section 5.2.

Fusion commented 3 years ago

This is definitely a major enhancement request. It is likely that we will look into it over an extended period of time.

We would need to support the bind mechanism (may have to modify the LDAP library to support the additional attributes) then settle on some algorithms and finally get to work; that is, implement support for these algorithms.

Kerberos5 would likely be the first implemented algorithm.

terefang commented 2 years ago

i think you should not torture yourself with kerberos as the entry into SASL.

my suggestion would be to start with: ANONYMOUS, PLAIN/LOGIN, and EXTERNAL, exactly in that order

hexdrome commented 4 months ago

SASL is required for any service authenticated by Active Directory or FreeIPA. Because GLAuth supports a external LDAP backend so it must (not should) support GSSAPI too. For Cross-LDAP auth it also requires S4U2Proxy extension support. ANONIMOUS is not used in secured infrastructure. PLAIN is unsecured due to password file. EXTERNAL is associated with CA - too many nuances.

terefang commented 4 months ago

ANONYMOUS

could be enabled/disable with a config option, with default off.

PLAIN/LOGIN

there are many good password hashing algorithms and libraries out there

https://snyk.io/blog/secure-password-hashing-in-go/

EXTERNAL

if you do LDAPS (SSL/TLS) connections already the ssl-library will basically do this for free if configured.

you just need to retrieve the client-cert dn and start mapping:

people the will use SASL-EXTERNAL are usually well versed in managing CA topics.

all glauth needs to do is loading the list of known allowed CAs for the ssl-library via config. the simplest way is to read all .pem/.crt files from a directory.

Fusion commented 4 months ago

Thanks, nice summary. As a reminder, this is where we are today: https://glauth.github.io/docs/security.html

I understand that bcrypt is not the ultimate solution, for various reasons including allowing the admin to use too few rounds, or mistake a pepper for a salt.

So, yes, I have been very interested in alternate hashings (of course Argon is a top contender), or even zero knowledge auth.

Regarding EXTERNAL, it looks like you are advocating what would be otherwise known as "mutual auth" -- I like the idea, especially if we can use an enterprise signing chain for both ends. This doesn't seem to be a very popular approach, though, as from what I've been reading, only SASL-EXTERNAL is usually offered?

Fusion commented 4 months ago

BTW @hexdrome sometimes the best approach is the swiss cheese model. That is why OTP and Yubikey are also supported.

terefang commented 4 months ago

Thanks, nice summary. As a reminder, this is where we are today: https://glauth.github.io/docs/security.html

I understand that bcrypt is not the ultimate solution, for various reasons including allowing the admin to use too few rounds, or mistake a pepper for a salt.

So, yes, I have been very interested in alternate hashings (of course Argon is a top contender), or even zero knowledge auth.

while bcrypt is ok-ish, a simple sha256 is becoming increasingly insecure by todays standards.

ldap standard defines how password are stored by schemas https://datatracker.ietf.org/doc/html/rfc3112#section-3 as examplified here https://passlib.readthedocs.io/en/stable/lib/passlib.hash.ldap_std.html

and defines compatiblity with unix libcrypt/xcrypt here https://passlib.readthedocs.io/en/stable/lib/passlib.hash.ldap_crypt.html

once documentation catches up, both argon and yes-crypt will be part of that.

hexdrome commented 5 days ago

ANONYMOUS

could be enabled/disable with a config option, with default off.

PLAIN/LOGIN

there are many good password hashing algorithms and libraries out there

https://snyk.io/blog/secure-password-hashing-in-go/

EXTERNAL

if you do LDAPS (SSL/TLS) connections already the ssl-library will basically do this for free if configured.

you just need to retrieve the client-cert dn and start mapping:

  • try to map the complete dn to a user in the directory
  • extract known or configured attributes from dn (cn or uid are common) and map that to a known user.
  • compare the dn to a list of known valid ones
  • compare the certificate public key has to a list of known valid ones (called "certificate pinning")

people the will use SASL-EXTERNAL are usually well versed in managing CA topics.

all glauth needs to do is loading the list of known allowed CAs for the ssl-library via config. the simplest way is to read all .pem/.crt files from a directory.

Looks server doesn't support SASL at all Got it: ... INF SASL authentication is not supported

I guess you suggest to refactor code to turn on TLS library? It is not good idea because many of other could use SASL it is standard corporate networks.

And my last question was how to make secured transit connection like User (SASL) -> GLAuth (SASL) -> External LDAP (AD or FreeIPA)

Fusion commented 5 days ago

OK, you win. Once I'm done fixing some concerns with PAM, I'll look into SASL binds.

terefang commented 3 days ago

And my last question was how to make secured transit connection like User (SASL) -> GLAuth (SASL) -> External LDAP (AD or FreeIPA)

that is a good question.

in the simplest case the GLAuth server has a Server Cert and the User uses TLS or StartTLS to connect. in turn the External LDAP also has a Server Cert and GLAuth uses either TLS or StartTLS to connect. (this is basically what browsers and proxies do),

Fusion commented 11 hours ago

I know it's not exciting, but I had a bit of time to start looking, and implementing PLAIN was, of course, no biggie.