eDSAuthFailed error in Workgroup Manager

I have the same problem - it just started at a couple of my 10.4.2 sites - users would suddenly fail to login. Attempts to change/reset their password would give the same error you're getting.

I can fix it by toggling the user to a Crypt password (which prompts for a new password), then moving them back to OD. After that, I can reset/change passwords at will, and logins function.

It looks like OD passwords are getting corrupt or damaged in the LDAP directory, but I'm not sure how. Crawling though the Inspector doesn't show me anything unexpected or different for these users.

I'll let you know if I find a fix. But you're not alone. 🙂

Charles

No solution, just wanted to chime in with a "me too" and a little additional data.

This problem manifested itself first when our users logged in for the first time and were asked to change their password (we have that set in the Open Directory Policy). It does not accept the "new" password. A little trip through the password server log shows the password server thinks this user is "untitled_1" and rejects the new password. Subsequent work in the workgroup manager (trying to fix the passwords) yielded the eDSAuthFailed message for us.

At first, you could go in and delete and recreate the user (might have to try a couple of times) and everything seemed to work, but now the recreated users are not managed correctly (wrong dock and other mcx problems).

A long time on the phone with applecare and they basically told me to export the users and groups, demote and promote the server, and import the users. This will create new ldap, password, and kerberos databases. He believed the password database is corrupted.

One other tip he gave me was to use the server tools from the server. Just copy the folder right over to my laptop. The version on the server is 10.4.2, while the server tools on the cd is only 10.4. This doesn't fix the problem, but may be part of what caused the corruption in the first place, he said, and may prevent future trouble.

for the past week i have been fighting this problem. and from what you say it can explain a lot.
I use passenger to create the files for importing users, the version with 150 user import limit. we have 1 year group that has more than 150 students so i had to split this up......this 1 year has had about 70% failure rate.
what i think has happened is that i created all the files on the server using passenger, and imported the users on the server, except for this 1 year which i must have taken back to my workstation to do, where i imported them after making 2 separate files for importing.
all the problems in this topic i have experienced, so much so that even using the proper version throws the error every time now.

Perhaps apple need to force users to upgrade WGM if the server is running a newer version?

I had the same issue with a client's machine this morning. This is what I did to fix it:

1. Make sure Workgroup Manager is not running on any machine.
2. Log in as root locally to the server (not sure if this is relevant, but it's what I did)
3. Launch Server Admin on the server that is housing the OD structure.
4. Go into OD -> Archive and archive your structure to a location you can find it (to the root desktop at /var/root/Desktop, for example)
5. Double-click the sparseimage file that it created and make sure it will open and mount properly.
6. Here's the breath holder -- demote your OD Master to a Single Server mode.
7. After you demoted it, repromote it to an OD Master. I didn't change any settings in this -- I just put in the diradmin password and told it to promote.
8. After it was promoted, I launched Workgroup Manager. It connected and I made a test user. (again, not sure if this step is necessary because of the next step)
9. I closed WM and went back to Server Admin. I went to OD -> Archive and restored the OD (tip: the path needs the full path to the archive, not just the directory the archive is housed in).
10. I launched Workgroup Manager to make sure all the users, groups, and computers are in there and created a new user. Voila! No errors.

I was able to use this method on two servers this morning. Not sure what is causing the issue, but I think it might have to do with multiple instances of WM being opened with editing of records occurring simultaneously. I'd rather err on the side of caution and have it open one computer at a time.

BTW, then I'm connecting in WM, I'm connecting as diradmin.

Hope this helps!

crypt password are inherently less secure, because they are stored in the directory data base and are subject to dictionary attacks. configure a user account to use a crypt a password only if you need to provide compatibility with a computer running mac os xv10.1 or earlier

if you are using a server that was upgraded from an earlier version of mac os x server on the server. if any records are sill using a crypt password, you should upgrade the password type fro the account to open directory

DID THIS HELP!

have you set up a Kerberos or open directory password server,

because there stored securely in a separate database

I too have had exactly the same thing.

I followed the demote/re-promote instructions to the letter and it has resolved the problem. WOOHOO. I have spent 3 days trying to find alternate ways to import users to bypass WGM etc... That solution took me all of 2 mins.

Thanks very much. Perhaps I can text all of my students now and tell them the place has not burned down afterall :P

hmm, got into work this morning to find that the problem has re-emerged 😟

Error of type eDSAuthFailed (-14090) on line 3330 of /SourceCache/ServerManagerUserGeneral/ServerManagerUserGeneral-193.1.1/UserAdva ncedPluginView.mm

Any other ideas?

yep same here its not as bad as it was before as i can currently create new user.
although it only seems to be happening on the users i had problems with before...

I got in this morning and 1 of the 2 servers having issues was having issues again. Read on to find out what I did.

Seeing "DSAuthFailed" shows me that the directory structure doesn't think the person making changes has been authenticated properly.

When I admin my servers, I log in as root locally to the box via ARD. I noticed when I would launch Workgroup Manager, on the login screen it would say "Keychain Locked" under the "Save Password" checkbox. I thought that might have something to do with it.

I launched Keychain Access and noticed that the default Keychain was X509Anchors, which was the System root certificate database. I made the default keychain for root "login" (under the File menu, choose "Make Keychain 'login' default"). I relaunched WM and the "Keychain Locked" item was missing (good thing) and I was able to add, delete, and edit users.

To be honest, this approach makes more sense to me than my previously "remedy".

So, tips:

-- Use ARD and login remotely as root
-- Make the default keychain login

Maybe the X509Anchors got corrupt or inaccessible or something? I ran Keychain first aid and didn't find anything that seemed relevant...

Hope that helps...

anyone know what causes this problem yet?
I have gone as far as exporting my users then importing them again but the users we had problems with still throw the error when i import them. (after re-promoting the server)

still getting this error.

We ended up re-entering all of our users by hand after demote/promote. We have stayed away from importing and things have been working well for a little over a week now

rebuilt the server yesterday, importing all the users from the original passenger files and all seems to be ok............for now

I'm just chiming back in here again - my problem was getting worse and then, reading some other threads, I found a fix - I don't know if it's temporary or not, since I just appiled it, but since doing the fix I've been able to create new users and change passwords cleanly, with no -14090 errors.

What I did was delete the overflow files:

# rm /var/db/authserver/ overflow
# rm /var/db/authserver/authserverfree

(I did the above as root)

Since deleting these files, it's been successful - no more crypt passwords or errors. Hopefully the problem will stay gone. I noted the overflow files were named authserveroverflow.1 through authserveroverflow.99 - from what I can gather, these are generated during import... I'm wondering if they cap out at two digits, so after .99 there was nowhere to go... so it crashes.

If it starts crashing again, I'll let you know, but for right now my 10.4.2 servers are running smoothly.

Charles

Just had an email from Jay at Macinmind. For all of you with this problem who Use Passenger. And those who don't actually, check out http://macinmind.com/Help/Passenger/Help/pgs/10.htm

Am about to try the 6 step solution.

Fingers crossed as The students need their logins in less than a week :P