Hello list.
Reading http://www.openldap.org/doc/admin24/security.html#SASL password storage scheme, I understand autentication can be delegated to an external mechanisme. Such as, for instance, a kerberos server. In this case, it is advised to prevent changing passwords in the directory.
What happens if the autentication provider is an heimdal server, using OpenLDAP as its backend, and smbkrb5 overlay to keep ldap, samba and kerberos password synced ? Does pass-through still work ? And it is recommended then to make the userPassword attribute read-ony, but still use Exop PasswordChange to change samba and kerberos attributes ?
I didn't tested it yet, but it look very interesting if it works. Particulary because heimdal password change through kpassword doesn't use ExOp PasswordChange operation, but only update kerberos and samba passwords.
I know smbkrb5 has a special {smbkrb5} password storage scheme for redirecting autentication against kerberos password internally, not relying on a external SASL process. But it's only usable if smbkrb5 overlay is available (some of our slaves servers are centos-based, and don't have this overlay, but still need to autenticate users). And the trick of setting password-hash directive in slapd.conf to {smbkrb5} to prevent overwriting of userPassword attribute on PasswordChange operation with a normal value has the drawback than even pure ldap administrative accounts (syncrepl, for instance) get redirected to kerberos password for autentication, whereas only our users have principals currently.
Guillaume Rousse wrote:
Hello list.
Reading http://www.openldap.org/doc/admin24/security.html#SASL password storage scheme, I understand autentication can be delegated to an external mechanisme. Such as, for instance, a kerberos server. In this case, it is advised to prevent changing passwords in the directory.
That part of the doc appears to be wrong. slapd will call SASL's setpass function to change a SASL password, so there's no reason to prevent changing passwords via LDAP.
Also, the {KERBEROS} delegation scheme has been removed, only SASL delegation is supported.
What happens if the autentication provider is an heimdal server, using OpenLDAP as its backend, and smbkrb5 overlay to keep ldap, samba and kerberos password synced ? Does pass-through still work ?
When using the smbk5pwd overlay in such a configuration, there is no pass-through. The Kerberos credentials reside in slapd and slapd validates the authentication directly.
And it is recommended then to make the userPassword attribute read-ony, but still use Exop PasswordChange to change samba and kerberos attributes ?
Yes.
I didn't tested it yet, but it look very interesting if it works. Particulary because heimdal password change through kpassword doesn't use ExOp PasswordChange operation, but only update kerberos and samba passwords.
I know smbkrb5 has a special {smbkrb5} password storage scheme for redirecting autentication against kerberos password internally, not relying on a external SASL process. But it's only usable if smbkrb5 overlay is available (some of our slaves servers are centos-based, and don't have this overlay, but still need to autenticate users).
You can always obtain the source tree that was used to build your distro and compile the overlay yourself.
And the trick of setting password-hash directive in slapd.conf to {smbkrb5} to prevent overwriting of userPassword attribute on PasswordChange operation with a normal value has the drawback than even pure ldap administrative accounts (syncrepl, for instance) get redirected to kerberos password for autentication, whereas only our users have principals currently.
The password_hash setting in slapd.conf is only a default. You can explicitly set any hash type on any account.
Howard Chu a écrit :
Guillaume Rousse wrote:
Hello list.
Reading http://www.openldap.org/doc/admin24/security.html#SASL password storage scheme, I understand autentication can be delegated to an external mechanisme. Such as, for instance, a kerberos server. In this case, it is advised to prevent changing passwords in the directory.
That part of the doc appears to be wrong. slapd will call SASL's setpass function to change a SASL password, so there's no reason to prevent changing passwords via LDAP.
I guess it is just a phrasing issue, and the doc means 'take care users don't inadvertly rewrite their password attribute with a true password instead of keeping this pointer'.
Also, the {KERBEROS} delegation scheme has been removed, only SASL delegation is supported.
What happens if the autentication provider is an heimdal server, using OpenLDAP as its backend, and smbkrb5 overlay to keep ldap, samba and kerberos password synced ? Does pass-through still work ?
When using the smbk5pwd overlay in such a configuration, there is no pass-through. The Kerberos credentials reside in slapd and slapd validates the authentication directly.
Only if you use the {SMBKRB5} redirection, or even if you use a {SASL} one ?
[..]
I know smbkrb5 has a special {smbkrb5} password storage scheme for redirecting autentication against kerberos password internally, not relying on a external SASL process. But it's only usable if smbkrb5 overlay is available (some of our slaves servers are centos-based, and don't have this overlay, but still need to autenticate users).
You can always obtain the source tree that was used to build your distro and compile the overlay yourself.
Out of my control, unfortunatly (otherwise, those servers wouldn't use centOs at all :P). Anyway, it doesn't really hurt, it will just make those servers from a specific department unable to autenticate users from other department, not their own ones.
And the trick of setting password-hash directive in slapd.conf to {smbkrb5} to prevent overwriting of userPassword attribute on PasswordChange operation with a normal value has the drawback than even pure ldap administrative accounts (syncrepl, for instance) get redirected to kerberos password for autentication, whereas only our users have principals currently.
The password_hash setting in slapd.conf is only a default. You can explicitly set any hash type on any account.
Yes, if you use an normal attribute change operation. I don't think there is a way to use an extended password change operation, and bypass this value. Anyway, it doesn't matter very much either, only sysadmins are suposed to take care of administrative accounts.
Let's to summarize what's I'm understanding so far.
First, you have to use either password_hash or ACLs to prevent users to rewrite password attribute with a standard password. Using password_hash is only possible with smbkrb5 overlay, because it uses a fixed {SMBKRB5} pattern, whereas {SASL} storage scheme change with any user
Second, {SMBKRB5} is an optimisation only possible with smbkrb5 overlay, whereas {SASL} is more generical, but also more expensives, as external calls are needed.
Am I correct ?
Guillaume Rousse a écrit :
Howard Chu a écrit :
Guillaume Rousse wrote:
Hello list.
Reading http://www.openldap.org/doc/admin24/security.html#SASL password storage scheme, I understand autentication can be delegated to an external mechanisme. Such as, for instance, a kerberos server. In this case, it is advised to prevent changing passwords in the directory.
That part of the doc appears to be wrong. slapd will call SASL's setpass function to change a SASL password, so there's no reason to prevent changing passwords via LDAP.
I guess it is just a phrasing issue, and the doc means 'take care users don't inadvertly rewrite their password attribute with a true password instead of keeping this pointer'.
Sorry, I just reread it, it's explicitely stated than slapd doesn't allow to change password at all. You were right.
[..]
Second, {SMBKRB5} is an optimisation only possible with smbkrb5 overlay, whereas {SASL} is more generical, but also more expensives, as external calls are needed.
And from my own tests this morning: {SASL} is a bit more complex to setup, but doesn't suffer from the few glitches than {K5KEY} does (See just reported ITS #5766 and #5767)
Guillaume Rousse wrote:
Guillaume Rousse a écrit :
Howard Chu a écrit :
Guillaume Rousse wrote:
Hello list.
Reading http://www.openldap.org/doc/admin24/security.html#SASL password storage scheme, I understand autentication can be delegated to an external mechanisme. Such as, for instance, a kerberos server. In this case, it is advised to prevent changing passwords in the directory.
That part of the doc appears to be wrong. slapd will call SASL's setpass function to change a SASL password, so there's no reason to prevent changing passwords via LDAP.
I guess it is just a phrasing issue, and the doc means 'take care users don't inadvertly rewrite their password attribute with a true password instead of keeping this pointer'.
Sorry, I just reread it, it's explicitely stated than slapd doesn't allow to change password at all. You were right.
We'll have to update that part of the Guide, there are very specific restrictions on this feature: The sasl_setpass call only works if the LDAP session was authenticated using SASL, and only if you're changing your own password. Otherwise it will fail. As such, e.g. a sysadmin cannot reset the password of some other SASL user via LDAP...
[..]
Second, {SMBKRB5} is an optimisation only possible with smbkrb5 overlay, whereas {SASL} is more generical, but also more expensives, as external calls are needed.
And from my own tests this morning: {SASL} is a bit more complex to setup, but doesn't suffer from the few glitches than {K5KEY} does (See just reported ITS #5766 and #5767)
Thanks for the reports. Will look into them later this week.
Howard Chu a écrit :
Guillaume Rousse wrote:
Guillaume Rousse a écrit :
Howard Chu a écrit :
Guillaume Rousse wrote:
Hello list.
Reading http://www.openldap.org/doc/admin24/security.html#SASL password storage scheme, I understand autentication can be delegated to an external mechanisme. Such as, for instance, a kerberos server. In this case, it is advised to prevent changing passwords in the directory.
That part of the doc appears to be wrong. slapd will call SASL's setpass function to change a SASL password, so there's no reason to prevent changing passwords via LDAP.
I guess it is just a phrasing issue, and the doc means 'take care users don't inadvertly rewrite their password attribute with a true password instead of keeping this pointer'.
Sorry, I just reread it, it's explicitely stated than slapd doesn't allow to change password at all. You were right.
We'll have to update that part of the Guide, there are very specific restrictions on this feature: The sasl_setpass call only works if the LDAP session was authenticated using SASL, and only if you're changing your own password. Otherwise it will fail. As such, e.g. a sysadmin cannot reset the password of some other SASL user via LDAP...
While on the documentation subject: it could be worth explaining, than despite SASL autentication of LDAP session being a different thing, the file /path/to/sasl/config.slapd.conf is used by all kind of SASL/slapd interaction. And if you use the one given in example, with only 'plain' mechanism, you'll break GSSAPI support (needed for those sessions), and also EXTERNAL support (needed for heimdal, for instance).
Second, {SMBKRB5} is an optimisation only possible with smbkrb5 overlay, whereas {SASL} is more generical, but also more expensives, as external calls are needed.
And from my own tests this morning: {SASL} is a bit more complex to setup, but doesn't suffer from the few glitches than {K5KEY} does (See just reported ITS #5766 and #5767)
Thanks for the reports. Will look into them later this week.
Thanks. If you could also deal with #5535 at the same time, it would be wonderful :)
openldap-software@openldap.org
-
Guillaume Rousse -
Howard Chu