dirsrv, SSH and forcing password change at first login

[Claudio Di Nardo]

Hi Joe,

thanks for your reply. I tried your work-around, but unfortunately nothing
changes. In fact, I still can't get the user to be asked to change his
password after the first successful login. I also took a look at the entire
ldap.conf file, looking for potentially interested directives, (as
pam_lookup_policy for example), but everything seems OK.
Furthermore, I checked the status of the authentication settings on the
client with authconfig --test

------------------------------------------------------------------------------------------------------------------------

nss_ldap is enabled
 LDAP+TLS is disabled
 LDAP server = "ldaps://xxx.xxx.xxx.xxx/ldaps://xxx.xxx.xxx.xxx/"
 LDAP base DN = "dc=xxx,dc=xxx"

------------------------------------------------------------------------------------------------------------------------

As you can see, for the authentication sub-system LDAP+TLS is DISABLED. But
I can assure you that LDAP servers only listen on 636 and that LDAP tools
queries, (ldapmodify, ldapsearch...), only take place if a certificates
database is present, as well as LDAP authentication over SSH only take place
if the .pem certificate is presente in /etc/openldap/cacerts :)
My hypothesis now is: as you may know, passwords and encrypted
communications are strictly tied between them, (e.g. Error 53: DSA is
unwilling to perform. LDAP server refuses to change passwords if a minimum
level of security is not assured). The fact that for NSS/PAM there's no TLS
in communications with LDAP server - even if, in fact, there IS - could
maybe result in this strange behavior?
I experienced anyway, during the installation and configuration, that the
tool authconfig must be a little buggy, and sometimes feeding it with
CORRECT informations at configuration time will result at the end in wrong
settings to the PAM/NSS subsystems. So i always prefer to manually edit the
files instead of use this tool.
I'll try to change some settings in this tool to make it work and to make it
recognize that TLS is enabled and keep you updated.
For now, thanks anyway :)

Claudio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pam-list/attachments/20110928/316c7677/attachment.htm>