Hi,
I'm trying to make a system account in LDAP that has multiple passwords, one of which is time-limited. Basically, it's your run-of- the-mill posix/shadowAccount object, with your common-or-garden userPassword attribute. Everything works so far. But now I want to add a couple of new attributes, tempPassword and tempPasswordTimestamp. tempPassword will contain a long random string of characters hashed somehow (crypt, sha, md5, I don't care) generated by the service-management software my company develops. tempPasswordTimestamp is what one of its underlying systems will use to determine all tempPasswords that have expired.
Now, I created the attribute tempPassword, and made it SUP userPassword, but it doesn't seem to have inherited any of userPassword's functionality, like the ability to hash the entered string with a given scheme (like if I entered {SSHA}password I'd end up with a SHA-1 hashed password) and automatic encoding to base64.
I know (or, at least, I *think* that userPassword is a multi-valued attribute, so I could just enter another userPassword and let it auth off that, but that defeats the purpose, which is to create a secure password that operators in our service-management software can use to log in to this user's account at the push of a button, without having to actually *know* the user's password. The password itself will be at least 20 characters long, consisting of uppercase, lowercase, numbers and special characters, so it'll be as secure as we can make it. All of it relies on me being able to create a new password attribute and auth off it, though, so, anyone able to help?
Regards,
Adrian
Adrian Overbury wrote:
Hi,
I'm trying to make a system account in LDAP that has multiple passwords, one of which is time-limited. Basically, it's your run-of-the-mill posix/shadowAccount object, with your common-or-garden userPassword attribute. Everything works so far. But now I want to add a couple of new attributes, tempPassword and tempPasswordTimestamp. tempPassword will contain a long random string of characters hashed somehow (crypt, sha, md5, I don't care) generated by the service-management software my company develops. tempPasswordTimestamp is what one of its underlying systems will use to determine all tempPasswords that have expired.
Now, I created the attribute tempPassword, and made it SUP userPassword, but it doesn't seem to have inherited any of userPassword's functionality, like the ability to hash the entered string with a given scheme (like if I entered {SSHA}password I'd end up with a SHA-1 hashed password) and automatic encoding to base64.
I know (or, at least, I *think* that userPassword is a multi-valued attribute, so I could just enter another userPassword and let it auth off that, but that defeats the purpose, which is to create a secure password that operators in our service-management software can use to log in to this user's account at the push of a button, without having to actually *know* the user's password. The password itself will be at least 20 characters long, consisting of uppercase, lowercase, numbers and special characters, so it'll be as secure as we can make it. All of it relies on me being able to create a new password attribute and auth off it, though, so, anyone able to help?
What kind of access do your operators have? Are they logging in to LDAP, http, shell?
OpenLDAP itself allows you to assign SASL authorization rights so that an identity with special privileges (operator) can authenticate with their own credentials, but request authorization rights to act as another user.
See http://www.openldap.org/doc/admin24/sasl.html#SASL%20Proxy%20Authorization
- Dan
Hello,
Adrian Overbury wrote: [...]
Now, I created the attribute tempPassword, and made it SUP userPassword, but it doesn't seem to have inherited any of userPassword's functionality, like the ability to hash the entered string with a given scheme (like if I entered {SSHA}password I'd end up with a SHA-1 hashed password) and automatic encoding to base64.
The functionality you mention is - not part of the LDAP server but part of a client exporting to LDIF (base64 encoding) - specific to the userPassword attribute, because the extended operation "password modify" only operates on the Attribute named "userPassword". I don't know of any functionality in the LDAP server that hashes the Password when you just modify the userPassword attribute normally.
I know (or, at least, I *think* that userPassword is a multi-valued attribute, so I could just enter another userPassword and let it auth off that, but that defeats the purpose, [...]
Why? It sounds like just what you want.
All of it relies on me being able to create a new password attribute and auth off it, though, so, anyone able to help?
I am not aware of another attribute that OpenLDAP could use for authentication via simple bind.
Since userPassword is a multi-valued attribute, you could simply add a password just before an operator wants to start a "login as user"-session and remove it after a timeout. You'd just have to save the Password string you set in your "service-management software", so you can delete the right one after the operator session ends.
bye Christian
Christian Marg writes:
Since userPassword is a multi-valued attribute, you could simply add a password just before an operator wants to start a "login as user"-session and remove it after a timeout. You'd just have to save the Password string you set in your "service-management software", so you can delete the right one after the operator session ends.
And that service-management's password store can be a tempPassword LDAP attribute. Stored _in addition_ to userPassword in LDAP.
If two operators want to log in as the same users at approximately the same time, do two tempPasswords get created? If so each must be associated with its own timestamp. In LDAP that's simplest done by putting the timestamp and password in the same attribute, e.g. with tempPasswordInfo = "timestamp#password". It should have Octet String syntax since userPassoword does.
Assuming he needs to create those passwords at all and can't use SASL like Dan suggested, of course.
openldap-software@openldap.org
-
Adrian Overbury -
Christian Marg -
Dan White -
Hallvard B Furuseth