Randall Wood wrote: > Further information: > > For the user that was uneditable: When first the password retry count is > set to zero, we get the error when saving, but, if we reset the password > retry count to zero and then change the uid by deleting the last > character and retyping it, we can save the changes. > > Also: We were able to create a new user and change the password. We > were also able to unlock another account. The problem seems to be just > with this one account, but the red slash on the users group is still > there. > start the console like this: 389-console -D 9 -f console.log then try to edit your user with the red slash > On Tue, 2009-10-20 at 16:02 -0400, Randall Wood wrote: > >> I am supporting an outfit that has two FDS servers configured for >> multiple-master replication. I do not have access to these servers. >> >> Today it was observed that on both of these servers, a user logging into >> the FDS Console as cn=Directory Manager is unable to edit the advanced >> properties on a user (to unlock a user's account), and that the Users OU >> is marked with a red X. >> >> I can not find any documentation that discusses why this red X would >> appear. What does this mean? >> >> Users of the systems supported by these FDS servers are still able to >> authenticate against the servers, and the administrators of the servers >> can not find anything relevant in the error logs. Is there anything you >> could suggest looking for? >> >> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.fedoraproject.org/pipermail/389-users/attachments/20091022/b98c6ba5/attachment.bin
