Hello,
In one of my OpenLDAP installation, I'm start using Ppolicy overlay and it's doesn't allow me to store multiple passwords in userPassword attribute as possible in regular situation. I'm looking for a solution that allowing me to keep using Ppolicy and have possibility to store an alternative user password (usually used by admins).
There is a solution to define an alternative attribute password ?
Regards,
On 3/12/21 5:20 PM, Benjamin Renard wrote:
In one of my OpenLDAP installation, I'm start using Ppolicy overlay and it's doesn't allow me to store multiple passwords in userPassword attribute as possible in regular situation.
What's your use-case? Up to now 100% of the concepts I saw relying on multiple user password were seriously flawed.
I'm looking for a solution that allowing me to keep using Ppolicy and have possibility to store an alternative user password (usually used by admins).
Ouch!
Many security regulations forbid especially this admin impersonation to arbitrary user accounts. And there are many good reasons for that.
Ciao, Michael.
Hi,
Le 12/03/2021 à 17:53, Michael Ströder a écrit :
On 3/12/21 5:20 PM, Benjamin Renard wrote:
In one of my OpenLDAP installation, I'm start using Ppolicy overlay and it's doesn't allow me to store multiple passwords in userPassword attribute as possible in regular situation.
What's your use-case? Up to now 100% of the concepts I saw relying on multiple user password were seriously flawed.
I'm looking for a solution that allowing me to keep using Ppolicy and have possibility to store an alternative user password (usually used by admins).
Ouch!
Many security regulations forbid especially this admin impersonation to arbitrary user accounts. And there are many good reasons for that.
This is my use-case and I'm agree with you that its not a regular situation. I have any responsibility of this choice and I just try to answer to this historical use-case in a Ppolicy context. I'm seeing any technical reason to impossibly achieve this requirement.
Do you have any idea to how to do that ?
Regards
On 3/12/21 6:23 PM, Benjamin Renard wrote:
Hi,
Le 12/03/2021 à 17:53, Michael Ströder a écrit :
On 3/12/21 5:20 PM, Benjamin Renard wrote:
In one of my OpenLDAP installation, I'm start using Ppolicy overlay and it's doesn't allow me to store multiple passwords in userPassword attribute as possible in regular situation.
What's your use-case? Up to now 100% of the concepts I saw relying on multiple user password were seriously flawed.
I'm looking for a solution that allowing me to keep using Ppolicy and have possibility to store an alternative user password (usually used by admins).
Ouch!
Many security regulations forbid especially this admin impersonation to arbitrary user accounts. And there are many good reasons for that.
This is my use-case and I'm agree with you that its not a regular situation. I have any responsibility of this choice and I just try to answer to this historical use-case in a Ppolicy context. I'm seeing any technical reason to impossibly achieve this requirement.
Ask yourself: How should password policy, e.g. correct password expiry, be applied to multiple, independently set userPassword values? You could of course hack your own slapo-ppolicy which does that with additional meta data. Good luck.
But I strongly recommend to get rid of this flawed use-case now by designing a more secure support process.
Ciao, Michael.
Le 12/03/2021 à 18:29, Michael Ströder a écrit :
On 3/12/21 6:23 PM, Benjamin Renard wrote:
Hi,
Le 12/03/2021 à 17:53, Michael Ströder a écrit :
On 3/12/21 5:20 PM, Benjamin Renard wrote:
In one of my OpenLDAP installation, I'm start using Ppolicy overlay and it's doesn't allow me to store multiple passwords in userPassword attribute as possible in regular situation.
What's your use-case? Up to now 100% of the concepts I saw relying on multiple user password were seriously flawed.
I'm looking for a solution that allowing me to keep using Ppolicy and have possibility to store an alternative user password (usually used by admins).
Ouch!
Many security regulations forbid especially this admin impersonation to arbitrary user accounts. And there are many good reasons for that.
This is my use-case and I'm agree with you that its not a regular situation. I have any responsibility of this choice and I just try to answer to this historical use-case in a Ppolicy context. I'm seeing any technical reason to impossibly achieve this requirement.
Ask yourself: How should password policy, e.g. correct password expiry, be applied to multiple, independently set userPassword values? You could of course hack your own slapo-ppolicy which does that with additional meta data. Good luck.
But I strongly recommend to get rid of this flawed use-case now by designing a more secure support process.
I totally agree that in slapo-ppolicy context, multiple passwords are unmanageable and it's why I firstly tried to configure an alternative password attribute, not managed by ppolicy and that it can be used in combination with userPassword regulary managed by ppolicy.
In another words, this alternative password attribute would not being affected by ppolicy. As the policy configuration accept an specific password attribute (using pwdAttribute parameter), it appeared to me to be an interesting track to explore, but I didn't found any solution to configure another alternative password attribute (reference to standard userPassword attribute seem to be hard-coded).
Michael Ströder wrote:
On 3/12/21 5:20 PM, Benjamin Renard wrote:
In one of my OpenLDAP installation, I'm start using Ppolicy overlay and it's doesn't allow me to store multiple passwords in userPassword attribute as possible in regular situation.
What's your use-case? Up to now 100% of the concepts I saw relying on multiple user password were seriously flawed.
I'm looking for a solution that allowing me to keep using Ppolicy and have possibility to store an alternative user password (usually used by admins).
As Michael correctly points out, this is an incredibly bad approach.
Also, in LDAP it is fundamentally wrong. Instead, you should create dedicated admin accounts, and if you want to let them impersonate other specific users, give them AuthzTo privileges for use with proxy authorization.
Ouch!
Many security regulations forbid especially this admin impersonation to arbitrary user accounts. And there are many good reasons for that.
Ciao, Michael.
Hello,
Le 13/03/2021 à 00:11, Howard Chu a écrit :
Michael Ströder wrote:
On 3/12/21 5:20 PM, Benjamin Renard wrote:
In one of my OpenLDAP installation, I'm start using Ppolicy overlay and it's doesn't allow me to store multiple passwords in userPassword attribute as possible in regular situation.
What's your use-case? Up to now 100% of the concepts I saw relying on multiple user password were seriously flawed.
I'm looking for a solution that allowing me to keep using Ppolicy and have possibility to store an alternative user password (usually used by admins).
As Michael correctly points out, this is an incredibly bad approach.
Also, in LDAP it is fundamentally wrong. Instead, you should create
dedicated
admin accounts, and if you want to let them impersonate other
specific users,
give them AuthzTo privileges for use with proxy authorization.Thank
you for this idea that could solve my needs for LDAP only access, but I looking for a solution that could works with other services taht using LDAP directory as user accounts provider (a IMAP server for instance).
Can you confirm me that the name of the userPassword password is hard-coded in OpenLDAP and there is no configuration parameter to change/configure it ?
Regards,
On 3/16/21 10:42 AM, Benjamin Renard wrote:
Can you confirm me that the name of the userPassword password is hard-coded in OpenLDAP and there is no configuration parameter to change/configure it ?
You can only use 'userPassword' attribute.
But even if you could change attribute 'pwdAttribute' to something else it would not help reaching your goal.
Again: The real solution is to fix your processes.
Ciao, Michael.
Le 16/03/2021 à 11:05, Michael Ströder a écrit :
On 3/16/21 10:42 AM, Benjamin Renard wrote:
Can you confirm me that the name of the userPassword password is hard-coded in OpenLDAP and there is no configuration parameter to change/configure it ?
You can only use 'userPassword' attribute.
But even if you could change attribute 'pwdAttribute' to something else it would not help reaching your goal.
Again: The real solution is to fix your processes.
OK, thanks for your help !
openldap-technical@openldap.org
-
Benjamin Renard -
Howard Chu -
Michael Ströder