unable to get network users working in server 3

I know there is another way....where you have to make sure all network names are configured the same... along with your Open Directory.... but you would have to dig through Some of the archives where people made sure certain config files were configured corrected... hmmm I recall there was some help in 10.7 and 10.8 Server info in the forums.. but it's been a long time since I read it... However, the question is how comfortable are some people with command line....

but the easiest thing is to start over for newbie server upgraders.. and to get it setup up with a FQDN.

freefall722 wrote:

So after my first successful login with a test account and clean install of the server I'm hitting this brick wall of being unable to add any new accounts without crashes: "existing connection is not authenticated - cannot change password" is the error I'm getting.

I guess it's time to wipe the server again but not really sure what I did to get it in a messed up state - so I'm leaning towards this just being a bug.

Trying to change passwords in Workgroup Manager results in this:

"In order to set the password of a a user with an Open Directory Password, your own password type must be Open Directory. Administrators with other password types cannot set the password of a user with an Open Directory password."

Is there anybody out there for whom it's working at all?

I'm very interested in how this plays out for you, since network accounts is the primary use of my server.

In my year of messing with DNS, I found fallout with Open Directory and certificates in particular. Both had to be completely regenerated from scratch once the DNS was configured correctly. Yes, very painful, but there was no workaround since the certificate directs to the FQDN and the Open Directory is based on the certificate, even if those are local, self-signed certificates.

The second item I see up there is using Workgroup Manager and getting an note regarding Custom home directories in Server App. I saw variations on this as I messed about with Profile Manager and tried to move my users to NFS share instead of AFP. So, one possible things going on; if you use Profiles, it takes over many of the configuration features of Workgroup Manager and moves the source file locations so Workgroup Manager can't see them. Reinvoking Workgroup Manager can cause trouble.

Another angle is that your pre-existing users are likely configured to AFP directory share (as mine are) but Apple has moved to SMB2 protocol and there are serveral reports out there of problems with the new file directory share. This problem is hazier, but I did see Custom come up a few times when it shouldn't have until my Open Directory and DNS were truely, deeply, happy.

Good luck and keep us posted.

Freefall,

It's great that you got part of it working. Forgot about the repair option in host names etc server app.

Next you might want to use workgroup manager 10.9 and login with diradmin .

Select the user and hit home tab presuming its in workgroup manager 10.9 and fix the directory path per user

Make sure you edit the full option

To clarify workgroup manager, I meant to say you login the application with an admin account, but when you edit a open directory user and press the unlock button you need to use diradmin which is why when you tried to change a user password a few posts ago that you get a weird response about using an open directory administrator.

diradmin user was created when you first configured open directory.

Right, after wasting hours trying to resolve the above, I wiped the server after making sure everything was backed up and did a clean install of Maverick downloading fresh from Apple to a wiped drive, updated with any patches, then installed Server 3, set the basics up and it all works. Macbook, iMac and ipads all working again running Maverick or iOS7.

Major fault in the upgrade process Apple and you have cost me hours!

Thanks

Lelie,

I costed you hours? I think not.

No, Apple has!

Here is what I was able to do to fix the issue with my systems. Before I explain, I want to reiterate my setup here. I have the mac mini server with newly upgraded Maverick OS and OS X Server 3 installed. I also have 7 iMacs on the network. 2 I had upgraded to Maverick while the others are still running the previous version. I had the exact same issue as freefall722 when he/she said, "after upgrading to Mavericks and OS X server 3 I've been unable to log into my network accounts from any of my client machines (all also upgraded to Mavericks). The Network Account Server is showing as green on the clients and I don't get any warnings at the login screen but trying to log into any accounts results in the failed attempt "shake" of the password box.".

The fix that worked for me:

1. It turns out that the Maverick upgrade on my client computers messed up my DNS server address for my network adapter. It reverted to the factory settings. I had to reset it so that it once again pointed to the IP Address of my mac mini server.
2. Once I reset the DNS on my client computers, I needed to log into my mac mini server and reset the passwords of my users.
3. Then, I needed to re-enroll my client machines within the profile manager

Wala it worked again after that. I have sense upgraded one more of my client machines and had the perform the same extra tasks before it worked. I am holding off on the other machines because I don't want to take the unnecessary risk of all of my machines going haywire during a production season. I'll keep testing with the ones that I have already upgraded.

Hope this helps!

Wil

I just wanted to add my experience here. We had a spare iMac lying around so I formatted and did a clean install of Mavericks and Server 3. Pointed it to another Mac Server where we run our DNS and added an appropriate entry. Ran through the setup procedure including settings a FQDN. We bound the machine to our ML OD server and all the network users became available.

Everything seemed peachy until I tried to login from a ML client at which stage I got the shaking dialog. I could login fine as a local user but not as a network user. I then tried the same thing using SMB and lo and behold it worked fine. Of more interest was what happened next. I tried again with AFP and, just like magic, it now worked! It now also works immediately for all our AFP clients on ML (it seemed to be fine from Snow Leopard from the start)

I have no idea how or why this is now working, but if you are getting the 'shaking dialog' it might be worth trying to login with SMB and see if that works. If it does, try AFP again.

I don't have a Mavericks client to test but will check that when we do...

Just to add a little more info to the pile, we run Mt Lion and Mavs clients with Lion servers and when doing initial testing with Mavs we found that it would fail to login to network accounts, newly created ones, as well. The bizarre things was that to ensure there wasn't an account problem we logged into the accounts from Mt Lion and found they worked fine (actually both with Mt Lion and Lion). After having done so the ability to login from Mavs all of a sudden worked.

Basically, from the looks of it there's a client issue that makes it initially fail to login to network accounts and I have no idea what the trigger is to make it work but there is one.

We have yet to purchase OS X Server 3 so cannot comment as to additional issues from that end which may be compounding things. I would suggest that those with issues with both Mavs clients and OS X Server 3 try to seggregate the two… make sure your Mavs clients can login to non-OS X Server 3 servers then in the reverse, ensure Mt Lion/Lion clients can login to your OS X Server 3 servers.

And yes, ensure your DNS is actually setup right. I've always found that most server issues start and end with DNS.

Thanks freefall722 - your steps resolved it for me and I could access my server again. I had to recreate the local network users, though, but it was not a big issue as we are a small team.

The server app also stopped crashing as you mentioned after recreating the open directory.