Hi.
I'm running two 389-ds instances on Centos9 servers, one master and one readonly slave server. Global pwpolicy is PBKDF2_SHA256 and local pwpolicy is SSHA512. The mail-servers are querying the readonly slave server for LDAP data. All servers are using TLS for encryption.
I'm running a two mail servers, one for incoming mail with Dovecot as an imap frontend and one for Postfix smtp with Dovecot as a SASL authentication backend. The Dovecot imap server has been running LDAP authentication flawlessly, but I recently switched the Postfix smtp server over to Dovecot SASL authentication.
Here's when everything started taking an interesting turn.
The incoming Dovecot imap server is set to do an authentication bind: auth_bind = yes
while the smtp server with Postfix + Dovecot SASL authentication does not do an auth_bind.
The authentication process started failing on the smtp server with the following error message for every authenticated user:
dovecot[721505]: auth: Error: ldap(USERNAME): Unknown scheme PBKDF2-SHA512
Changing password for a user will allow authentication against the LDAP from the smtp server, but when the imap server authenticates and use auth_bind, then no LDAP authentication is possible do on the smtp server and the above error message appears again for the user.
I found out, that when I also use auth_bind for Dovecot on the smtp server everything works.
What I hope someone could explain for me is, what's happening with the slave queries against the 389-ds ro server instance when the imap server authenticates the user with auth_bind enabled and the smtp server cannot authenticate the user when auth_bind is not enabled.
The servers are binding prior to auth_bind with a
dn = cn=binduser,ou=bindaccount,dc=example,dc=com
user so that part is working as intended.
Thank you.
BR, /MrM
What rpm version of 389-ds-base are you using? Is it the same on both systems?
In newer versions the standard storage scheme is PBKDF2-SHA512. Is your client trying to read or add already hashed passwords? Not sure why dovecot, or any client, would be complaining about an unknown password storage scheme since it should not know anything about the password storage scheme as it's supposed to be handled by the Directory Server internally.
Anything in the DS errors log?
Is PBKDF2-SHA512 in your DS config?
Anyway I'm not sure what is going on or what version of 389 you are using. I suspect you have two different versions of 389-ds-base, one which is newer and supports PBKDF2-SHA512, and one that is older and does not. Otherwise, I guess your clients are processing/using the userpassword value, and they just might not support PBKDF2-SHA512? So that means you have entries that already have PBKDF2-SHA512 (before you changed the password policy to PBKDF2_SHA256?). So those entries need to have their passwords reset to use the updated global password policy scheme.
FYI - you should avoid using SSHA512. It's very insecure as the hash can be cracked in 20 minutes or something like that.
Mark
On 3/7/23 8:22 AM, Mr Mysteron wrote:
Hi.
I'm running two 389-ds instances on Centos9 servers, one master and one readonly slave server. Global pwpolicy is PBKDF2_SHA256 and local pwpolicy is SSHA512. The mail-servers are querying the readonly slave server for LDAP data. All servers are using TLS for encryption.
I'm running a two mail servers, one for incoming mail with Dovecot as an imap frontend and one for Postfix smtp with Dovecot as a SASL authentication backend. The Dovecot imap server has been running LDAP authentication flawlessly, but I recently switched the Postfix smtp server over to Dovecot SASL authentication.
Here's when everything started taking an interesting turn.
The incoming Dovecot imap server is set to do an authentication bind: auth_bind = yes
while the smtp server with Postfix + Dovecot SASL authentication does not do an auth_bind.
The authentication process started failing on the smtp server with the following error message for every authenticated user:
dovecot[721505]: auth: Error: ldap(USERNAME): Unknown scheme PBKDF2-SHA512
Changing password for a user will allow authentication against the LDAP from the smtp server, but when the imap server authenticates and use auth_bind, then no LDAP authentication is possible do on the smtp server and the above error message appears again for the user.
I found out, that when I also use auth_bind for Dovecot on the smtp server everything works.
What I hope someone could explain for me is, what's happening with the slave queries against the 389-ds ro server instance when the imap server authenticates the user with auth_bind enabled and the smtp server cannot authenticate the user when auth_bind is not enabled.
The servers are binding prior to auth_bind with a
dn = cn=binduser,ou=bindaccount,dc=example,dc=com
user so that part is working as intended.
Thank you.
BR, /MrM
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Hi Mark,
Both servers are running the latest 2.2.x version from directory.fedoraproject.org:
python3-lib389-2.2.6-1.el9.noarch 389-ds-base-libs-2.2.6-1.el9.x86_64 389-ds-base-2.2.6-1.el9.x86_64 cockpit-389-ds-2.2.6-1.el9.noarch
This is listed in dse.ldif regarding PBKDF2-SHA512 and that makes the password storage schema active I assume:
dn: cn=PBKDF2-SHA512,cn=Password Storage Schemes,cn=plugins,cn=config objectClass: top objectClass: nsSlapdPlugin cn: PBKDF2-SHA512 nsslapd-pluginPath: libpwdchan-plugin nsslapd-pluginInitfunc: pwdchan_pbkdf2_sha512_plugin_init nsslapd-pluginType: pwdstoragescheme nsslapd-pluginEnabled: on nsslapd-pluginId: none nsslapd-pluginVersion: none nsslapd-pluginVendor: none nsslapd-pluginDescription: none
No error messages, all are log data points to "RESULT err=0" in access logfile.
I assume the problem is because the smtp server does not initiate a simple bind for checking the username & password when auth_bind is disabled in dovecot.
I'd like to know, if the object in the LDAP directory is set into some kind of "protective state" when a server has first authenticated with a simple bind in order to access the object, and when another server which doesn't make a simple bind in order to access the same object in the directory, 389-ds will not validate the users credentials.
BR, /MrM
On Tue, Mar 7, 2023 at 4:38 PM Mark Reynolds mareynol@redhat.com wrote:
What rpm version of 389-ds-base are you using? Is it the same on both systems?
In newer versions the standard storage scheme is PBKDF2-SHA512. Is your client trying to read or add already hashed passwords? Not sure why dovecot, or any client, would be complaining about an unknown password storage scheme since it should not know anything about the password storage scheme as it's supposed to be handled by the Directory Server internally.
Anything in the DS errors log?
Is PBKDF2-SHA512 in your DS config?
Anyway I'm not sure what is going on or what version of 389 you are using. I suspect you have two different versions of 389-ds-base, one which is newer and supports PBKDF2-SHA512, and one that is older and does not. Otherwise, I guess your clients are processing/using the userpassword value, and they just might not support PBKDF2-SHA512? So that means you have entries that already have PBKDF2-SHA512 (before you changed the password policy to PBKDF2_SHA256?). So those entries need to have their passwords reset to use the updated global password policy scheme.
FYI - you should avoid using SSHA512. It's very insecure as the hash can be cracked in 20 minutes or something like that.
Mark
On 3/7/23 8:22 AM, Mr Mysteron wrote:
Hi.
I'm running two 389-ds instances on Centos9 servers, one master and one readonly slave server. Global pwpolicy is PBKDF2_SHA256 and local pwpolicy is SSHA512. The mail-servers are querying the readonly slave server for LDAP data. All servers are using TLS for encryption.
I'm running a two mail servers, one for incoming mail with Dovecot as an imap frontend and one for Postfix smtp with Dovecot as a SASL authentication backend. The Dovecot imap server has been running LDAP authentication flawlessly, but I recently switched the Postfix smtp server over to Dovecot SASL authentication.
Here's when everything started taking an interesting turn.
The incoming Dovecot imap server is set to do an authentication bind: auth_bind = yes
while the smtp server with Postfix + Dovecot SASL authentication does not do an auth_bind.
The authentication process started failing on the smtp server with the following error message for every authenticated user:
dovecot[721505]: auth: Error: ldap(USERNAME): Unknown scheme
PBKDF2-SHA512
Changing password for a user will allow authentication against the LDAP from the smtp server, but when the imap server authenticates and use auth_bind, then no LDAP authentication is possible do on the smtp server and the above error message appears again for the user.
I found out, that when I also use auth_bind for Dovecot on the smtp server everything works.
What I hope someone could explain for me is, what's happening with the slave queries against the 389-ds ro server instance when the imap server authenticates the user with auth_bind enabled and the smtp server cannot authenticate the user when auth_bind is not enabled.
The servers are binding prior to auth_bind with a
dn = cn=binduser,ou=bindaccount,dc=example,dc=com
user so that part is working as intended.
Thank you.
BR, /MrM
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject....
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
-- Directory Server Development Team
On 3/7/23 2:23 PM, Mr Mysteron wrote:
Hi Mark,
Both servers are running the latest 2.2.x version from directory.fedoraproject.org http://directory.fedoraproject.org:
python3-lib389-2.2.6-1.el9.noarch 389-ds-base-libs-2.2.6-1.el9.x86_64 389-ds-base-2.2.6-1.el9.x86_64 cockpit-389-ds-2.2.6-1.el9.noarch
This is listed in dse.ldif regarding PBKDF2-SHA512 and that makes the password storage schema active I assume:
dn: cn=PBKDF2-SHA512,cn=Password Storage Schemes,cn=plugins,cn=config objectClass: top objectClass: nsSlapdPlugin cn: PBKDF2-SHA512 nsslapd-pluginPath: libpwdchan-plugin nsslapd-pluginInitfunc: pwdchan_pbkdf2_sha512_plugin_init nsslapd-pluginType: pwdstoragescheme nsslapd-pluginEnabled: on nsslapd-pluginId: none nsslapd-pluginVersion: none nsslapd-pluginVendor: none nsslapd-pluginDescription: none
No error messages, all are log data points to "RESULT err=0" in access logfile.
I assume the problem is because the smtp server does not initiate a simple bind for checking the username & password when auth_bind is disabled in dovecot.
I'd like to know, if the object in the LDAP directory is set into some kind of "protective state" when a server has first authenticated with a simple bind in order to access the object, and when another server which doesn't make a simple bind in order to access the same object in the directory, 389-ds will not validate the users credentials.
Entries do not go into any kind of state during a bind (or any other operation). Authentication is per connection. You open a connection, you bind (or don't bind), and then perform operations against the database. Access control rules are applied to those operations based on who authenticated when the connection was established. There are no issues/restrictions with multiple connections concurrently binding as the same user.
HTH,
Mark
BR, /MrM
On Tue, Mar 7, 2023 at 4:38 PM Mark Reynolds mareynol@redhat.com wrote:
What rpm version of 389-ds-base are you using? Is it the same on both systems? In newer versions the standard storage scheme is PBKDF2-SHA512. Is your client trying to read or add already hashed passwords? Not sure why dovecot, or any client, would be complaining about an unknown password storage scheme since it should not know anything about the password storage scheme as it's supposed to be handled by the Directory Server internally. Anything in the DS errors log? Is PBKDF2-SHA512 in your DS config? Anyway I'm not sure what is going on or what version of 389 you are using. I suspect you have two different versions of 389-ds-base, one which is newer and supports PBKDF2-SHA512, and one that is older and does not. Otherwise, I guess your clients are processing/using the userpassword value, and they just might not support PBKDF2-SHA512? So that means you have entries that already have PBKDF2-SHA512 (before you changed the password policy to PBKDF2_SHA256?). So those entries need to have their passwords reset to use the updated global password policy scheme. FYI - you should avoid using SSHA512. It's very insecure as the hash can be cracked in 20 minutes or something like that. Mark On 3/7/23 8:22 AM, Mr Mysteron wrote: > Hi. > > I'm running two 389-ds instances on Centos9 servers, one master and > one readonly slave server. > Global pwpolicy is PBKDF2_SHA256 and local pwpolicy is SSHA512. > The mail-servers are querying the readonly slave server for LDAP data. > All servers are using TLS for encryption. > > I'm running a two mail servers, one for incoming mail with Dovecot as > an imap frontend and one for Postfix smtp with Dovecot as a SASL > authentication backend. > The Dovecot imap server has been running LDAP authentication > flawlessly, but I recently switched the Postfix smtp server over to > Dovecot SASL authentication. > > Here's when everything started taking an interesting turn. > > The incoming Dovecot imap server is set to do an authentication bind: > auth_bind = yes > > while the smtp server with Postfix + Dovecot SASL authentication does > not do an auth_bind. > > The authentication process started failing on the smtp server with the > following error message for every authenticated user: > > dovecot[721505]: auth: Error: ldap(USERNAME): Unknown scheme PBKDF2-SHA512 > > Changing password for a user will allow authentication against the > LDAP from the smtp server, but when the imap server authenticates and > use auth_bind, then no LDAP authentication is possible do on the smtp > server and the above error message appears again for the user. > > I found out, that when I also use auth_bind for Dovecot on the smtp > server everything works. > > What I hope someone could explain for me is, what's happening with the > slave queries against the 389-ds ro server instance when the imap > server authenticates the user with auth_bind enabled and the smtp > server cannot authenticate the user when auth_bind is not enabled. > > The servers are binding prior to auth_bind with a > > dn = cn=binduser,ou=bindaccount,dc=example,dc=com > > user so that part is working as intended. > > Thank you. > > > BR, > /MrM > > _______________________________________________ > 389-users mailing list -- 389-users@lists.fedoraproject.org > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- Directory Server Development Team
On 8 Mar 2023, at 00:37, Mark Reynolds mareynol@redhat.com wrote:
What rpm version of 389-ds-base are you using? Is it the same on both systems?
In newer versions the standard storage scheme is PBKDF2-SHA512. Is your client trying to read or add already hashed passwords? Not sure why dovecot, or any client, would be complaining about an unknown password storage scheme since it should not know anything about the password storage scheme as it's supposed to be handled by the Directory Server internally.
You're bang on the money here Mark. Lots of "older" unix applications like dovecot *read* the raw hashes and try to actually compute and compare them themselves, rather than sending the pw cleartext and letting the ldap server do the work.
dovecot[721505]: auth: Error: ldap(USERNAME): Unknown scheme PBKDF2-SHA512
Changing password for a user will allow authentication against the LDAP from the smtp server, but when the imap server authenticates and use auth_bind, then no LDAP authentication is possible do on the smtp server and the above error message appears again for the user.
I found out, that when I also use auth_bind for Dovecot on the smtp server everything works.
What I hope someone could explain for me is, what's happening with the slave queries against the 389-ds ro server instance when the imap server authenticates the user with auth_bind enabled and the smtp server cannot authenticate the user when auth_bind is not enabled.
It'll be a config on the dovecot or postfix side.
It's been about 10 years since I ran dovecot for IMAP+SASL, but this sounds like an issue with how postfix is working with dovecot for the user/auth process.
Sorry I don't think we can help much in this case :(
-- Sincerely,
William Brown
Senior Software Engineer, Identity and Access Management SUSE Labs, Australia
389-users@lists.fedoraproject.org
-
Mark Reynolds -
Mr Mysteron -
William Brown