Remote Desktop not working?

Question

Level 3

668 points

Remote Desktop not working?

I've got a Mac mini that I use as a home server, running 10.5 Server. I usually run it headless; when I need to access it directly I go through Apple Remote Desktop to get to it. Up until about two months ago that's worked without a hitch.

About two months ago I decided to change my administrator password on my server as I suspected the old password had been discovered. After I did this I naturally changed the password that Remote Desktop was using. After I did this I was unable to access the mini via Remote Desktop; it would tell me that authentication had failed. Neither the old nor the new password was working.

I connected a monitor to the mini and tried logging in directly. It too would not let me login, indicating the password was wrong. (It's perhaps worth noting that all of my user accounts on the server continued to work without any problems. It was only the administrative account that's an issue.)

I restarted from the OS X Server DVD and changed the administrative password from there, thinking that perhaps I entered it incorrectly. Once that was done I restarted - and still the mini wouldn't let me login either directly or through Remote Desktop. Now thinking that perhaps someone compromised my mini, I reformatted the drive and reinstalled OS X Server from scratch. I entered a new (third) completely unique administrative password. When it restarted I did nothing but enable Remote Desktop - and STILL I'm unable to login to it via Remote Desktop, always getting the "authentication failed" message.

I'm now hesitant to restart the mini since I want to be able to login to it. Does anyone have any idea *** is causing this issue?

Shiny New 24" iMac 2.8GHz 4GB/320GB, Mac OS X (10.4.11), Accessories by Apple, Matias, Microsoft, Epson, Dymo, Sony and others. w00t!

Posted on Dec 30, 2008 5:24 AM

Reply

Answer 1

ÜberMacHead Author

Level 3

668 points

Dec 30, 2008 5:54 AM in response to ÜberMacHead

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.

Reply

Answer 2

Dec 30, 2008 8:58 PM in response to ÜberMacHead

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:

http://antcooper.com/2007/10/31/fix-for-authentication-failed-in-apple-remote-de sktop-32/

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.

Pretty weird!

Reply

Answer 3

davidh

Level 4

1,890 points

Dec 31, 2008 4:08 AM in response to Paul Derby

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):

/Library/Preferences/com.apple.ARDAgent.plist
/Library/Preferences/com.apple.RemoteManagement.plist

and retry.

Failing that, Quit ARD and
set aside the "ClientCaches" and "caches" folders inside of /private/var/db/RemoteManagement:


sudo mkdir /private/RmtMgt_Bak
cd /private/var/db/RemoteManagement
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.

Reply

Answer 4

Dec 31, 2008 8:20 AM in response to davidh

David,

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.

Reply

Answer 5

davidh

Level 4

1,890 points

Dec 31, 2008 9:24 AM in response to Paul Derby

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.

Reply

Answer 6

Dec 31, 2008 9:38 AM in response to davidh

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".

Reply

Answer 7

davidh

Level 4

1,890 points

Dec 31, 2008 10:09 AM in response to Paul Derby

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.

Reply

Answer 8

Dec 31, 2008 10:33 AM in response to davidh

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...

Reply

Answer 9

Dec 31, 2008 11:20 AM in response to Paul Derby

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!

Reply

Answer 10

davidh

Level 4

1,890 points

Dec 31, 2008 11:25 AM in response to Paul Derby

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.

Reply

Answer 11

ÜberMacHead Author

Level 3

668 points

Jan 1, 2009 9:30 PM in response to davidh

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.

Reply

Answer 12

Jan 2, 2009 7:19 AM in response to ÜberMacHead

Ü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.

Reply

Answer 13

davidh

Level 4

1,890 points

Jan 2, 2009 9:24 AM in response to Paul Derby

Only problem is, on my in-house server (G5 Tower) running 10.5.5 server,
Remote Management is enabled, and I can connect to it perfectly fine via ARD & (10.5 client, built-in) Screen Sharing.

Reply

Answer 14

Jan 2, 2009 10:01 AM in response to davidh

DavidH, hope ARD continues to work for you when/if you upgrade to 10.5.6. If 10.5.6 fails then you have a workaround.

I never ran Version 10.5.5. I moved from OS X Server Tiger 10.4 to OS X Server Leopard 10.5.6 last week.

Reply

Answer 15

davidh

Level 4

1,890 points

Jan 2, 2009 10:30 AM in response to Paul Derby

Well, that's new information and part of the whole picture.

I don't know if you did a "migration" type install, starting with a wipe of the (to-be) system HD
and clean install of 10.5 (and updates).

That is the only kind of installation I will do. An upgrade install (10.5 overtop 10.4, previously 10.4 overtop 10.3, etc.) means you migrate every potential, existing (often lurking) problem with your install.

In some cases some startup items have not been converted (StartupItem to launchd) in upgrade installs of 10.5 (and 10.4 over 10.3), for example.

Reply