Running RH5 with openldap-2.3.43. We have a script that pulls ssha passwords from a ldap server out of our control. So when a user updates their passwords on that server, the script pulls the password periodically and updates our ldap servers so users can use our ldap servers with posix attributes to authenticate to systems using ldap and pam settings.
We need to inactivate accounts after a period of inactivity. We can do this using the shadowInactive attribute in ldap that is based on when the user password expired.
So the issue we have is that when the user logs into a system and their accounts are expired they can enter a new password and our ldap servers our updated with the new password, but when the script runs at a later time, the password is reset back to whatever is in the ldap server we pull passwords from. We would like users to not be able to change their password using the password command. We can accomplish this in a few ways including:
1. pam_password_prohibit_message in ldap.conf 2. Just commenting out the ldap module in pam that controls password updates.
The problem is that we have a small group of users that are added manually that we would like to be able to change their passwords using the passwd command. The above will impact all users. We are looking for suggestions on how to handle the above. We thought of the following:
1. Use the ppolocy overlay and create a default policy for all users that sets pwdAllowUserChange to no and then create individual policies to that allow certain users to change their pass. In this method, what happens to all the shadow attributes, are they overwridden by the ppolicy. I don't see anything regarding Inactive accounts in ppolicy like the shadowInactive attribute.
2. Could we accomplish this by figuring out a ACL in slapd.conf that only users with a special attribute value are able to write to the userPassword attribute?
Any other suggestions?
ldap@mm.st wrote:
Running RH5 with openldap-2.3.43. We have a script that pulls ssha passwords from a ldap server out of our control. So when a user updates their passwords on that server, the script pulls the password periodically and updates our ldap servers so users can use our ldap servers with posix attributes to authenticate to systems using ldap and pam settings.
We need to inactivate accounts after a period of inactivity. We can do this using the shadowInactive attribute in ldap that is based on when the user password expired.
So the issue we have is that when the user logs into a system and their accounts are expired they can enter a new password and our ldap servers our updated with the new password, but when the script runs at a later time, the password is reset back to whatever is in the ldap server we pull passwords from. We would like users to not be able to change their password using the password command. We can accomplish this in a few ways including:
- pam_password_prohibit_message in ldap.conf
- Just commenting out the ldap module in pam that controls password
updates.
The problem is that we have a small group of users that are added manually that we would like to be able to change their passwords using the passwd command. The above will impact all users. We are looking for suggestions on how to handle the above. We thought of the following:
- Use the ppolocy overlay and create a default policy for all users
that sets pwdAllowUserChange to no and then create individual policies to that allow certain users to change their pass. In this method, what happens to all the shadow attributes, are they overwridden by the ppolicy. I don't see anything regarding Inactive accounts in ppolicy like the shadowInactive attribute.
- Could we accomplish this by figuring out a ACL in slapd.conf that
only users with a special attribute value are able to write to the userPassword attribute?
(2) seems like the most straightforward.
Any other suggestions?
We have RH5 servers with openldap-2.3.43 used to authenticate systems via ldap and pam settings. We are using a single master and our consumers run in refreshOnly mode. The consumers are placed on various networks so the systems do not need to traverse a bunch of routers to contact the server for authentication. The consumer is the first server listed in the ldap.conf files and the provider is listed as the secondary for the systems. We need to allow only certain users to change their passwords via the passwd command and will be trying to figure out an ACl to put in the servers slapd.conf files to accomplish this.
The question is, if the system authenticates against a consumer which is read only and their password has expired, when they try to change their password I assume that the command will fail since it can not write to the consumer which is read only? If this is the case and the provider is listed as a secondary or the slapd.conf file for the consumer has the provider listed as the updateref, will the system try the provider when it can not write to the consumer?
Unfortunately, I am unable to test this right now and wanted to get some feedback on how this works.
--On Monday, June 13, 2011 3:44 PM -0600 ldap@mm.st wrote:
Unfortunately, I am unable to test this right now and wanted to get some feedback on how this works.
man slapo-chain(5)
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
On Mon, 13 Jun 2011 15:44 -0600, ldap@mm">ldap@mm.st wrote:
We have RH5 servers with openldap-2.3.43 used to authenticate systems via ldap and pam settings. We are using a single master and our consumers run in refreshOnly mode. The consumers are placed on various networks so the systems do not need to traverse a bunch of routers to contact the server for authentication. The consumer is the first server listed in the ldap.conf files and the provider is listed as the secondary for the systems. We need to allow only certain users to change their passwords via the passwd command and will be trying to figure out an ACl to put in the servers slapd.conf files to accomplish this.
The question is, if the system authenticates against a consumer which is read only and their password has expired, when they try to change their password I assume that the command will fail since it can not write to the consumer which is read only? If this is the case and the provider is listed as a secondary or the slapd.conf file for the consumer has the provider listed as the updateref, will the system try the provider when it can not write to the consumer?
Unfortunately, I am unable to test this right now and wanted to get some feedback on how this works.
Haven't had a chance to try the chain overlay that was suggested yet, but we were able to try changing the password on of the consumers and the password was updated properly on the provider. The updateref setting on the consumers seems to be work with the passwd command.
openldap-technical@openldap.org
-
Howard Chu -
ldap＠mm.st -
Quanah Gibson-Mount