Some more information.....
I again wiped the drive and reinstalled 10.5 Server, taking particular care about the password issue. Here's what I found.
After installing and entering a password, I enabled Remote Desktop. I was NOT able to connect via Remote Desktop, getting the "authentication failed" message. I am 100% positive that the password I entered is correct. I am able to ssh into the mini using the same password so I know that I'm entering the password correctly.
On a whim, I changed the password on the mini. It accepted my original password and my new password. I was still not able to connect via Remote Desktop using the new password (authentication failed), and I was still able to connect via ssh using the new password.
I then decided to change the password back to the original password. Upon attempting this I was told that the old password I had entered was incorrect, and I am therefore unable to change the password again.
W. T. F?!? I'm this close to installing a Linux server on my mini and start pressuring Apple for a refund on OS X Server.
I'm having the same problem as you. If I used my administrator name of "foo" with my administrator password, ARD fails with an authentication error.
I tried signing on as "root" with my administrator password and ARD comes up just fine.
I found a thread in another place that suggested kickstarting to solve the problem. This did not help me, but helped others:
I also found another thread that suggested using disk utility to repair permissions. this didn't help, either.
In my situation I built Leopard on an attached Firewire drive and got it working just fine, including ARD. Then I used SuperDuper to move the image from the Firewire drive to two raid 0 drives in my Xserve. That is when ARD started failing with my password for ARD. The password works for signing on to the machine.
The one thing I'm not seeing, is what was done to clear any cached info for ARD, which appears to be where the issue lay, not the username & pass on/at the server itself.
Try first re-adding the server by IP.
Failing that, quit ARD and try setting aside the ARD preferences files (say, to your Desktop):
Failing that, Quit ARD and
set aside the "ClientCaches" and "caches" folders inside of /private/var/db/RemoteManagement:
sudo mkdir /private/RmtMgt_Bak
sudo mv ClientCaches /private/RmtMgt_Bak/
sudo mv caches /private/RmtMgt_Bak/
_*Most emphatically, do not touch anything else whatsoever in /private/var/db*_
not for any reason whatsoever, unless you already know exactly what you're doing and why.
Thanks for your interest in solving this situation.
I went to a second machine that has ARD installed and tried to sign on and have the same problem. So I don't think it is a problem with any settings on the ARD host machine.
My guess is that it is a problem with the way passwords are tied to kerberos on the OS X Leopard server. I changed my password on the OS X server and verified that the username I'm using has full administrative rights, but ARD still can't authenticate to the OS X server.
Do you know of a way to get OS X to "relink" all the kerberos authentication?
I just migrated the server from Tiger to Leopard. The Tiger machine didn't have Kerberos running at all. Leopard came up with it enabled so I didn't figure out how to disable kerberos just to use password authentication.
For comparison, I would also try connecting via the built-in Screen sharing in 10.5 client, which might actually use Kerberos. Otherwise - with ARD - I don't think Kerberos is even used: instead DHX is used as with AFP. See http://support.apple.com/kb/TA24182
Well... DHX key exchange is used as part of the authentication but is not itself an auth method quite precisely. But there's no mention of Kerberos being used and I doubt that it is for ARD (the Admin application). For more on DHX see http://www.rsa.com/rsalabs/node.asp?id=2248
There are options in ARD > Preferences > Security, but no visible way of specifying auth methods.
My mistake on Kerberos. It was a wrong assumption on my part. So maybe DHX is the culprit instead. How does one tell OS X to make sure DHX and passwords are all tied together correctly?
I tried screen sharing. Using "root" as the user with the root password works. Using the administrator user name and password fails just like ARD with "Authentication failed to XServe".
There should be no need. If those components aren't working your install is probably damaged in other significant aspects. But that's probably not what's going on.
Are you trying to use the username & pass on your server of the local, initial admin account setup when doing the install ?
Can you auth & connect ok to the server from your workstation using Server Admin ?
And once there, click in the left-hand pane on the servername itself (not the services listed underneath its name), click the General tab, and confirm that Remote Management is enabled.
I only have one username and password on the new Leopard server so far. That is the administrator name and password. That is the UN/password that doesn't work for connecting via ARD.
I CAN connect using ARD if I use the username "root" and the administrator password. That works just fine.
So SSH is in place, the firewall settings are correct in the network, and, yes, Remote Management is enabled in the General Tab for the machine.
This has to be some sort of permissions/authentication issue. I just can't figure out what it is for ARD. One would have thought the "kickstart" process would have solved this situation, but it didn't...
I went back and booted up the OS X Leopard instance that I originally built on an external firewire disk. ARD connects up just fine with the username and password on the original instance.
So it looks like something got messed up in the permissions/validations/whatever in the process of cloning the Firewire drive to the XServe internal drive using SuperDuper and then booting from the new image.
This kinda bothers me, because I clone the disk regularly for backup using SuperDuper and now I'm not sure the clone is a true clone!
So far, ARD authentication is the only thing I've found that doesn't work. And it seems the ARD Kickstart doesn't fix the problem, either.
Since I can use ARD by signing on as ROOT, this isn't urgent and I can think about it a while and maybe file a bug report with Apple.
Any ideas are welcomed!
I don't use SuperDuper for cloning, I use ASR (Disk Utility) booted from another volume. That ensures the source is fully quiescent and allows for a full block-level copy.
At this juncture, were it me (I can't replicate the problem, not deliberately),
I'd use fs_usage & sc_usage both locally and on the server, as well as (since this is 10.5 and has dtrace with all it offers) iosnoop, rwsnoop, etc. to try to observe file/resource usage in order to try to determine which file(s) might be problematic.
As far as I can tell, the problem is Remote Desktop - or rather, the "Remote Management" component of OS X Server.
Starting with a CLEAN installation of OS X (10.5.0) Server that has only one account (the admin account) and a guaranteed-known password, I CAN login to the server locally, and I CAN connect to the server via Remote Desktop. It is very interesting to note that I am able to do so even though "Remote Management" on the server is OFF by default. (Screen Sharing and Remote Login are on, though.)
If I turn Remote Management ON (which automatically turns off Screen Sharing), my Remote Desktop connection is immediately severed with an "authentication failed" message. Deleting and re-adding the computer to Remote Desktop Admin doesn't work, always giving the "authentication failed" message. However, if I turn Remote Management OFF and Screen Sharing ON again, I am once again able to connect to it via Remote Desktop!
So apparently the workaround to connecting via Remote Desktop is to NOT enable Remote Management on the server. With Remote Management OFF I am able to observe and control the server, though I'm not able to do things like update the RD client software or drag-and-drop files to copy to/from the server. With Remote Management ON I can't do ANYTHING with the server via Remote Desktop.
I consider this to be a pretty blatantly obvious bug. To those having similar problems I'd be curious to know if you've got Remote Management turned on at the server and, if so, what happens if you turn it off and turn Screen Sharing on instead.
ÜberMacHead, I think you are correct!
I used Remote Desktop with username "root" to connect to the server, went to System Preferences/Sharing, unchecked "remote management", and immediately lost the Remote Desktop connection. Then using terminal I used SSH to get to the server, entered:
$ cd /Library/Preferences
$ echo -n enabled > com.apple.ScreenSharing.launchd
To start screensharing.
I was then able to connect to the server using remote desktop and the administrator username as well as "root".
Thanks for finding the combination that works!
Agree with you that this is a "blatantly obvious bug". Are you filing the bug report with Apple?
Hope so. I'll report a bug, too, referencing this discussion thread.