New users accounts keep getting disabled at login

If Users Can’t Log In or Authenticate

If a user can’t log in or authenticate to his or her account, consider the following to determine whether the source of the authentication problem is configuration-related or due to the password:

• Reset the password to a known value and then determine whether there is still a problem. Try using a 7-bit ASCII password, which is supported by most clients.
• Make sure the password contains characters supported by the authentication protocol. Leading, embedded, and trailing spaces, as well as special characters (such as pressing Option-8 to form a bullet), are not supported by some protocols. For example, leading spaces work with POP and AFP, but not IMAP.
• Make sure the user’s keyboard can generate all characters in the user’s password.
• Crypt passwords don’t support many authentication methods. To increase the probability that a user’s client applications are supported, set the user’s password type to Open Directory or suggest that the user try a different application.
• If the user’s account resides in a directory domain that is not available, create a user account in a directory domain that is available.
• Make sure the client software encodes the password so it is recognized correctly. For example, Open Directory recognizes UTF-8 encoded strings, which might not be sent by some clients.
• Make sure the user’s current application and operating system support the user’s password length. For example, Windows applications that use the LAN Manager authentication method support only 14-character passwords, so a password longer than 14 characters causes an authentication failure even though Windows service supports longer passwords.
• If you disabled authentication methods for Open Directory or shadow passwords (such as APOP or LAN Manager) the user’s applications can’t authenticate using the disabled methods.After enabling or disabling Open Directory Password Server or shadow password authentication methods, you might need to reset the user’s password.For additional information on enabling and disabling authentication methods, see Server Admin Help.
• For Kerberos troubleshooting tips, see Server Admin Help.
• If a Mac OS v8.1–8.6 computer fails to authenticate for Apple file service, the computer’s AppleShare Client software might need upgrading:
  • Mac OS v8.6 computers should use AppleShare Client v3.8.8.
  • Mac OS v8.1–8.5 computers should use AppleShare Client v3.8.6.
  • Mac OS v8.1–8.6 computers that have file server volumes mount during startup should use AppleShare Client v3.8.3 with DHX UAM (User Authentication Module) installed. DHX UAM is included with the AppleShare Client v3.8.3 installation software.

iqmax:

Any update on your issue with global policy?

Were you running your server as an OD Master before you updated to OS 10.8.2 and Server 2.1?

I was having this issue as well. For me it had to do with my presets. I deleted all of my presets. Then created a user without a preset. That worked.

Anthony

Thanks for the help. Just upgraded from 10.4 to 10.8 (which wasn't fun) and was wondering why new users were getting disabled.

This was the answer for me, deleted all the users that were broken, deleted presets and recreated each one withouth presets and now they work. Suppose i can try and file a bug on that if nobody else has.

It seems to relate to creating users via WGM.

Currently I am creating them in Server.app which works fine, then going in to WGM to configure homedir, groups etc manually.

It's a real pain but I would be surprised if Apple get round to fixing it considering WGM is a dead-man walking with Apple pushing us towards ProfileManager.

ignore/delete me

The thing we found related to this is the checkbox in Workgroup Manager (Advanced tab, Options...) that says that the password must be changed at next login.

What this actually does is disable the account until the user logs into a Mac and uses the login interface to change the password. All other uses of the account will see the account as disabled until this has been done.

This setting is a default when making a new account in some ways. So check this checkbox on one of your problem accounts and make sure it's not the cause of your problem.

ProfileManager is not intended for use with setting up account details. ProfileManager seems primarily for use in configuring devices. Apple seems to want us to use Server.app for settings account details.

i was having this problem with accounts created in WGM, make sure you are not using Presets.

every account created with a preset would lock. deleted the accounts and recreated with no presets they worked fine

The preset settings include whether that checkbox should be checked or not. So what you had there was presets which had that checkbox checked. It's just as easy to make presents that don't have that checkbox checked.

The issue the OP is referring to is not a simple as "Access Account" being checked in the preset. We had good presets with the account enabled. But when creating accounts in WGM they would switch to 'Disabled' when a user tried to log in. You could flip them back to enabled (in WGM or Server.app) but they would again switch to disabled each time the user attempted a login. I also see some service access options ticked and greyed out in Server.app if I create the accounts in WGM.

Server.app is definately where Apple want us to create users going forward, but ProfileManager duplicates most of WGM's... err... work group management 🙂

It pretty much replicates WGM's preference options for Users, User Groups, Devices and Device Groups but via the magic of Push and PostgresSQL. I still don't trust it though and am sticking with WGM just now.

Hi

• Is the OPEN-DIRECTORY in use?
• Have you tried to, within OPEN-DIRECTORY (access it through Server.App), change the global password settings?

I remember that the global password-settings is "change at first login" or so - maybe that helps?

Please, rate right answers

cheers