Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Password policy "change password at first login" errors!

Complete panic!


I've updated to OS X Server 4.1 and all my users appear to be ok. All green lights within the server app. Computers are NOT giving the red light 'network accounts unavailable'. However, no one can login. Every user, new and old, are being prompted at login to create a new password (say: Password 1). They type in a new password (say: Password2), the box shakes like it didn't accept it. However, if they try to login again, it won't accept Password1. If they type Password2, they again get prompted to change the password.


So it looks like it's accepting the password, but stuck in this reset password loop.


I've checked in the server app and workgroup manager. Neither have 'reset password at first login' selected.

Mac mini, OS X Yosemite (10.10.3)

Posted on May 1, 2015 8:08 AM

Reply
Question marked as Best reply

Posted on May 1, 2015 2:15 PM

Many Open Directory problems can be resolved by taking the following steps. Test after each one, and back up all data before making any changes.

1. The OD master must have a static IP address on the local network, not a dynamic address. It must not be connected to the same network with more than one interface; e.g., Ethernet and Wi-Fi.

2. You must have a working DNS service, and the server's hostname must match its fully-qualified domain name. To confirm, select the server by name in the sidebar of the Server application window, then select the Overview tab. Click the Edit button on the Host Name line. On the Accessing your Server sheet, Domain Name should be selected. Change the Host Name, if necessary. The server must have at least a three-level name (e.g. "server.yourdomain.com"), and the name must not be in the ".local" top-level domain, which is reserved for Bonjour.

3. The primary DNS server used by the server must be itself, unless you're using another server for internal DNS. The only DNS server set on the clients should be the internal one, which they should get from DHCP if applicable.

4. If you have accounts with network home directories, make sure the URL's are correct in the user settings. A return status of 45 from the authorizationhost daemon in the log may mean that the URL for mounting the home directory was not updated after a change in the hostname. If the server and clients are all running OS X 10.10 or later, directories should be shared with SMB rather than AFP.

5. Follow these instructions to rebuild the Kerberos configuration on the server.

6. If you use authenticated binding, check the validity of the master's certificate. The common name must match the hostname and domain name. Deselecting and then reselecting the certificate in Server.app has been reported to have an effect in some cases. Otherwise delete all certificates and create new ones.

7. Unbind and then rebind the clients in the Users & Groups preference pane. Use the fully-qualified domain name of the master.

8. Reboot the master and the clients.

9. Don't log in to the server with a network user's account.

10. Disable any internal firewalls in use, including third-party "security" software.

11. If you've created any replica servers, delete them.

12. If OD has only recently stopped working when it was working before, you may be able to restore it from the automatic backup in /var/db/backups, or from a Time Machine snapshot of that backup.

13. Reset the password policy database:

sudo pwpolicy -clearaccountpolicies

14. As a last resort, export all OD users. In the Open Directory pane of Server, delete the OD server. Then recreate it and import the users. Ensure that the UID's are in the 1001+ range.

If you get this far without solving the problem, then you'll need to examine the logs in the Open Directory section of the log list in the Server app, and also the system log on the clients.

8 replies
Question marked as Best reply

May 1, 2015 2:15 PM in response to kcunningham374

Many Open Directory problems can be resolved by taking the following steps. Test after each one, and back up all data before making any changes.

1. The OD master must have a static IP address on the local network, not a dynamic address. It must not be connected to the same network with more than one interface; e.g., Ethernet and Wi-Fi.

2. You must have a working DNS service, and the server's hostname must match its fully-qualified domain name. To confirm, select the server by name in the sidebar of the Server application window, then select the Overview tab. Click the Edit button on the Host Name line. On the Accessing your Server sheet, Domain Name should be selected. Change the Host Name, if necessary. The server must have at least a three-level name (e.g. "server.yourdomain.com"), and the name must not be in the ".local" top-level domain, which is reserved for Bonjour.

3. The primary DNS server used by the server must be itself, unless you're using another server for internal DNS. The only DNS server set on the clients should be the internal one, which they should get from DHCP if applicable.

4. If you have accounts with network home directories, make sure the URL's are correct in the user settings. A return status of 45 from the authorizationhost daemon in the log may mean that the URL for mounting the home directory was not updated after a change in the hostname. If the server and clients are all running OS X 10.10 or later, directories should be shared with SMB rather than AFP.

5. Follow these instructions to rebuild the Kerberos configuration on the server.

6. If you use authenticated binding, check the validity of the master's certificate. The common name must match the hostname and domain name. Deselecting and then reselecting the certificate in Server.app has been reported to have an effect in some cases. Otherwise delete all certificates and create new ones.

7. Unbind and then rebind the clients in the Users & Groups preference pane. Use the fully-qualified domain name of the master.

8. Reboot the master and the clients.

9. Don't log in to the server with a network user's account.

10. Disable any internal firewalls in use, including third-party "security" software.

11. If you've created any replica servers, delete them.

12. If OD has only recently stopped working when it was working before, you may be able to restore it from the automatic backup in /var/db/backups, or from a Time Machine snapshot of that backup.

13. Reset the password policy database:

sudo pwpolicy -clearaccountpolicies

14. As a last resort, export all OD users. In the Open Directory pane of Server, delete the OD server. Then recreate it and import the users. Ensure that the UID's are in the 1001+ range.

If you get this far without solving the problem, then you'll need to examine the logs in the Open Directory section of the log list in the Server app, and also the system log on the clients.

Jun 8, 2015 8:29 AM in response to kcunningham374

I have noticed in the newest version of Yosemite Server if you select Change Password on First Login in Edit Password Policy it will corrupt the diradmin password. This may also be the case with user passwords. I have done a clean install all the way down to Yosemite and rebuilt the server with only one network user and if you toggle on Change Password on First Login it causes that problem. If that is left unchecked then everything is fine. Unfortunately, once you select it you can't unselect it because the diradmin is corrupted. If you are choosing to use this option this might be your problem.

Nov 16, 2015 8:28 PM in response to cszymanski

I recognize this is an older post, but I'm curious what admins are doing with this issue. I agree that checking the Change Password on First Login is locking out the diradmin account, which in turn prevents the changing of other account settings.


Using the terminal line to change the diradmin password is a good workaround, but this seems rather unclean.


Is this how admins are addressing this problem? In my deployments, I've been skipping the Change Password on First Login option and just managing this process manually. Not ideal though.

Feb 2, 2016 12:42 AM in response to tim_r_66

So i's been a while since the last post and a lot has changed. El Capitan has been released followed by 3 updates however OS X Server was last updated in October 2015. And yet, I am still experiencing this problem with setting the password policy and I don't seem to be able to reset the diradmin account using the terminal either. After entering the old password then the new, I just get "su: Sorry"


I did manage to change the diradmin password another way but when it came to actually using the new password in the Server.app it wouldn't accept it. Till now the only option I have to fix it is to delete the OD and start again.


Does the issue revolve specifically around the "reset at first user login"? I want to implement the "be reset every" option so I don't want the diradmin account to again stop working again when it's time for users to change passwords.

Feb 19, 2016 10:52 AM in response to hgelderbloem

Hi,

Environment :

- Old Server 10.8 => export user and group

- OS X Server 5.015 El Capitan fresh install and import user and group.

- no policy, no global policy.. after import user, i change all password to 'changeme' and tick "network user must change password on next login"

- client are 10.8, 10.10


Result :

- client 10.8 (not try 10.10) login, the change password pop-up and then fill new password

- response from server "your new password no meet to the server requirement" !?

- i activate the web password change option on the server, and i can change password !



I have try all solution found over the net, and nothing worked. User can't change password with login change password popup and too with user setting change password on client machine.


Then i fresh install a client in 10.11.3, and the result is : i can change password !!


The for me, 10.8 client and 10.11.3 server 5.015 havent not same "change password 'relation/communication/password policy scheme'"


Regads

Password policy "change password at first login" errors!

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.