OD Master fails to authenticate diradmin, won’t accept correct password

[alternapop]

When trying to authenticate with WorkGroup Manager, to 127.0.0.1, on a 10.5.2 Server the diradmin account is failing. I’m certain that I’m typing in the correct password. I experienced this with 10.5.1 too.

Is this a known bug? Could I be doing something wrong when initially setting up the diradmin account when creating the OD Master?

The only solution I know of is to change the OD Master to a OD Standalone, and then back to a Master. But this is temporary because it soon seems to forget the password again.

Is there another way to fix this?

Thanks,
Chris

[alternapop]

[QUOTE][u]Quote by: MacTroll[/u][p]Are you able to login to other services as this user?

What do the logs say?[/p][/QUOTE]

i can successfully change the diradmin account’s password via the Terminal with “passwd diradmin” and it accepts the “old password”. going back to WGM, it still won’t accept the password.

via System Preferences, clicking on the lock to authenticate, it accepts the diradmin acct and password.

i can’t find any entries in any logs pertaining to this but it’s possible i’m not looking in the right log file.

this shows up every 30 seconds in system.log but i don’t know that it’s related:

“Feb 14 14:07:52 xxxopendirectory servermgrd[45]: –Module servermgr_xserve’s response has retain count of 1.”

via the Terminal, is there a command where i can add a new user and have that user be a new diradmin account (named differently of course) to see if WGM accepts that acct?

thanks!

[alternapop]

[QUOTE][u]Quote by: MacTroll[/u][p]dscl localhost read /Search/Users/diradmin[/p][/QUOTE]

——————
it returns the following text. nothing stands out to me as an obvious problem.
i used a different shortname other than diradmin but i’ve changed it, along with any other revealing info in the following text.

thanks

——————
clsopendirectory:~ isunit$ dscl localhost read /Search/Users/diradmin
dsAttrTypeNative:apple-generateduid: CD0BE9F1-B5B6-4FD4-AAEF-5B25BB158170
dsAttrTypeNative:authAuthority:
;ApplePasswordServer;0x47b1dde46b8b45670000000200000002,1024 35 13471747669994901427990051441621928930464366334988402441847486241250835528716529262188416797369764989724490493898419832705432105738330330415602044633490619874379403336254328581640475796657113805006318536936308859604069390925387441253557232949048000133953793586198583526155106002373353676643849697222856271 [email protected]:169.123.123.123
dsAttrTypeNative:cn:
Directory Administrator
dsAttrTypeNative:gidNumber: 20
dsAttrTypeNative:givenName: Directory
dsAttrTypeNative:homeDirectory: /Users/diradmin
dsAttrTypeNative:loginShell: /bin/bash
dsAttrTypeNative:objectClass: inetOrgPerson posixAccount shadowAccount apple-user extensibleObject organizationalPerson top person
dsAttrTypeNative:sn: Administrator
dsAttrTypeNative:uid: diradmin
dsAttrTypeNative:uidNumber: 1000
dsAttrTypeNative:userPassword: ********
AppleMetaNodeLocation: /LDAPv3/127.0.0.1
AuthenticationAuthority:
;ApplePasswordServer;0x47b1dde46b8b45670000000200000002,1024 35 13471747669994901427990051441621928930464366334988402441847486241250835528716529262188416797369764989724490493898419832705432105738330330415602044633490619874379403336254328581640475796657113805006318536936308859604069390925387441253557232949048000133953793586198583526155106002373353676643849697222856271 [email protected]:169.123.123.123
FirstName: Directory
GeneratedUID: CD0BE9F1-B5B6-4FD4-AAEF-5B25BB158170
LastName: Administrator
NFSHomeDirectory: /Users/diradmin
Password: ********
PrimaryGroupID: 20
RealName:
Directory Administrator
RecordName:
diradmin
Directory Administrator
RecordType: dsRecTypeStandard:Users
UniqueID: 1000
UserShell: /bin/bash

[alternapop]

[QUOTE][u]Quote by: MacTroll[/u][p]You used a different shortname than diradmin?

So were you able to get the diradmin user record back?[/p][/QUOTE]

yes, i didn’t use “diradmin”, i used something like “abcdiradmin” so it’s not easy to guess. i believe one of the speakers at macworld this year suggested not using diradmin for security reasons.

i’m pretty sure i used “diradmin” specifically last month when testing OD and it too failed to authenticate after a certain time frame…. so i don’t think that alone is the issue.

running your previous terminal command and replacing “diradmin” with “abcdiradmin” returned the previous data from my last post.

[alternapop]

[QUOTE][u]Quote by: MacTroll[/u][p]Ahhhh, that makes so much more sense.

I had at first thought you had just pulled any random user out of LDAP, and not the directory admin. 😀

mkpassdb -dump | grep diradmin

swapping in your local diradmin account.

That’s the password hash that authenticates the diradmin user. So… you’re looking to make sure that this lines up with the first bit of the authAuthority. Then you can use mkpassdb to actually reset that particular hash.[/p][/QUOTE]

the two hashes are identical.
i’ve never used mkpassdb before. what exactly am i doing with this?
thanks!

[alternapop]

[QUOTE][u]Quote by: MacTroll[/u][p]The PWS database is where your diradmin’s password is actually stored. So it’s good that a hash exists there.

You could use mkpassdb to reset that password, just to see if that’s the issue.

Although this is really beginning to smell like you have something deeper going on.[/p][/QUOTE]

there are other post regarding this problem on the apple forums. no apparent fix that i know of. i just wonder what exactly is causing this for some users and not for others. procedure error? environment?

[Macchick]

This is not a passwd problem. I have been having the same issue. This is a WorkGroupManager problem, but I don’t know how to fix it. If you have any idea of what I’m doing wrong, I appreciate it. It’s supposed to be in production phase next month, and it seems that I could just use something else to connect to the LDAP, but frankly, WGM is nice. I see a few other persons that have the same problem in the mac-os-x-server mailing list I’ve posted there too but no answer so far.

It never happens when I played with it in 10.4. Yet, I never had set it up fully to have my apache server connecting to it. It started happening after I upgraded to 10.5. It did it with 10.5.1 and still doing it. The first time, I downgraded/upgraded the OD so many times that it would fail to be a master after that, I had to run manually the command to erase the ldap server. I tried to change the passwd with mkpasswd and it successfully did it (so the logs were saying) but still no unlocking from WGM.

My system Intel xserve 10.5.2. Everything is original on the xserve. I did a full install from scratch of leopard server.
No DNS server on it (we do automatic DHCP and DNS). Only service running is the OD. I’ve set the OD as follows:
OD Master no replica (the first time it happened, it had a replica on an identical xserve)
No policy on passwd
Binding policy:
enable auth directory binding (required between directory and clients)
disable clear text passwd (I’ve try after it locked without this – no change)
digitally sign all packets
block man-in-the-middle
disable client-side caching

The DNS gives us a name as Name.PRETENDCO.COM, so that’a how I’ve set the base but in the log I sometimes see the full name in uppercases as
NAME.PRETENDCO.COM. The alias in the logs are “Name” and the sever knows itself as Name.PRETENDCO.COM

Here is what I know (it is reproducible, at least twice):

At first it works:

I set the diradmin password.
I log to the OD server through the local WGM AND from a remote one. I saved the passwd in the keychain of the remote one.
I get in directly remotely (because it can read the passwd saved in the keychain) and I have to type the passwd locally.
I can lock, unlock as much as I want.
I can connect to the OD though my apache server on another machine.
Everything works fine.
I see in the log which user is authenticated, whether it authenticated through apache or through the WGM.
I did that 2 (maybe it was 3) days in a row, no problems.

Then, I wait a few days (I’m not sure how many, let’s say a week), letting apache authenticate my users it works, no worry.
Then I want to add a user in the OD, I launch the WGM and that’s when it breaks.
Either locally or remotely, the WGM gives me the same error (remember that remotely the passwd is saved in my keychain).
I got the following error “The login information is not valid for this server”
Now I know this is not a passwd problem, because the logs tell me I successfully authenticated as diradmin.
My apache server is also still happy to negotiate the binding and the authentication with the OD (everything asks for passwd)
Only the WGM is refusing to unlock.

I bought the xserve only to be able to use the WGM. I could put an LDAP server on any of the debian machines we have. I don’t know what to do.

Here are the logs I can find:

Here is the Directory Services server logs when I last restarted it:
2008-02-19 15:49:43 PST – T[0xB029A000] – Plugin “PasswordServer”, Version “4.0.2”, loaded on demand successfully.
2008-02-19 15:49:43 PST – T[0xB029A000] – Plug-in PasswordServer state is now active.

No error in the DS error log

It seems like that what happens just before in the Kerberos Admin:
Feb 19 15:47:28 kadmind[40](info): No dictionary file specified, continuing without one.
Feb 19 15:47:28 kadmind[40](info): No dictionary file specified, continuing without one.
Feb 19 15:47:29 kadmind[40](info): Seeding random number generator
Feb 19 15:47:29 kadmind[40](info): Seeding random number generator
Feb 19 15:47:29 kadmind[40](info): starting
Feb 19 15:47:29 kadmind[40](info): starting

I guess that is just now when I tried to unlock the WGM (from the Kerberos server log):
Feb 21 14:27:07 krb5kdc[87](info): TGS_REQ (7 etypes {18 17 16 23 1 3 2}) : ISSUE: authtime 1203632827, etypes {rep=16 tkt=16 ses=16}, diradmin@ for ldap/@

I keep getting these in the LDAP log:
Feb 21 14:27:07: — last message repeated 1 time —
Feb 21 14:27:07 slapd[37]: <= bdb_substring_candidates: (authAuthority) index_param failed (18) Feb 21 14:27:07 slapd[37]: SASL [conn=727] Failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No principal in keytab matches desired name)

And that is the Password Service Server log, the one that tells me that the passwd is fine:

— Start: Server rolled log on: Feb 21 2008 14:25:55 —
Feb 21 2008 14:25:55 AUTH2: {ID, diradmin} DHX authentication succeeded.
Feb 21 2008 14:25:55 KERBEROS-LOGIN-CHECK: user {ID, diradmin} is in good standing.
Feb 21 2008 14:25:55 KERBEROS-LOGIN-CHECK: user {ID, diradmin} authentication succeeded.
Feb 21 2008 14:25:55 GETDISABLEDUSERS
Feb 21 2008 14:25:55 GETDISABLEDUSERS
Feb 21 2008 14:25:58 AUTH2: {ID, diradmin} DHX authentication succeeded.
Feb 21 2008 14:25:58 KERBEROS-LOGIN-CHECK: user {ID, diradmin} is in good standing.
Feb 21 2008 14:25:58 KERBEROS-LOGIN-CHECK: user {ID, diradmin} authentication succeeded.
Feb 21 2008 14:27:07 AUTH2: {ID, diradmin} DHX authentication succeeded.
Feb 21 2008 14:27:07 KERBEROS-LOGIN-CHECK: user {ID, diradmin} is in good standing.
Feb 21 2008 14:27:07 KERBEROS-LOGIN-CHECK: user {ID, diradmin} authentication succeeded.

I have errors in the passwd service error log:
— Start: Server rolled log on: Feb 19 2008 15:24:40 —
Feb 19 2008 15:24:40 Registration is finished error: (10, -72000).
Feb 19 2008 15:44:41 Registration is finished error: (10, -72000).
Feb 19 2008 15:44:41 Registration is finished error: (10, -72000).

Help Help Help!!!

–Yasmina

[alternapop]

After posting on numerous message boards, and no one having an exact answer, but several making plenty of great suggestions, I think I’ve finally figured out the cause of this issue or at least part of the cause.

Within ‘Server Admin’, select “Open Directory”,
under: Settings > Policy > Binding

there are six check boxes under “Security”… for testing kerberos, I have been checking the first four boxes, which are:

1. disable clear text passwords
2. digitally sign all packets (requires Kerberos)
3. encrypt all packets (requires ssl or kerberos)
4. block man-in-the-middle attackes (requires kerberos)

through troubleshooting this myself, and doing each change, followed by a server reboot, then immediately attempting to authenticate to /LDAPv3/127.0.0.1/, it seems that enabling some, or some combination of these Security settings triggers WordGroup Manager to not accept the diradmin password.

referring to the numbers above (1 through 4)…
2 or 4 by themselves fails
1 and 3 together fails

I haven’t gone beyond that for testing and don’t know what other combinations works or fails.

I don’t know if there is something beyond this that is specific to my configuration or environment that plays a part in this failing. All I know is that turning off all Security checkboxes in this section fixes the problem.

I wonder if anyone who has never seen this problem can try this on their 10.5.2 Server and see if they are still able to authenticate as their diradmin to WGM. Regardless, seems that this is a WGM bug to me, right?

[Macchick]

Yeaaaaaahhhhh! It is unlocked!!!!!! Victory!

I actually tried to remove all the kerberos settings (because I read it had worked for somebody on the macos-x-server list) but I didn’t reboot after that, just re-launched OD! I guess kerberos or something else has to be re-launched too.

Chris,
you saved me big-time!

Now, let’s see if that is going to hold stable for more than 2 days :-))))))

–Yasmina

[bugugly]

In my case I think this happened after I created the first ACL directory authentication.

I could still access the server using screen sharing with a given name/pw, but directory browsing access was buggered up. I could authenticate a couple of accounts I had created post ACL, but no accounts created prior. At least it seemed like that was the difference.

I did not try to go back and repeat, so it could just be my wild imagination.

But definitely a reboot and my server worked again.

slapd[38]: <= bdb_substring_candidates: (authAuthority) index_param failed (18) was the error message I googled to get here. Thanks for the suggestion, it used to be SOP with the former server OS. Then a few years without reboots except post-updates in 10.3.9 had me spoiled.

[bugugly]

Server Admin->Server.local->Settings->Access->Services

Select the service you are trying to connect to on the left, then “Allow all users and groups” and click save.

When you see the groups icon disappear from the left of the service, try connecting on that service again as the user that would not previously authenticate.

I could not get a user to authenticate on AFP even though the logs showed success in Kerberos authentication for that user.

Then I found this pane, opened up AFP to all, and those same user credentials got me right in.

From that point I can go back and review users/groups to see why that particular user could not access that particular service, shut down the wide open access, and try again.

Probably most already know all this. I didn’t. Hopefully this will save someone like me a little scratching around.

[Author]

Posts