14 Replies Latest reply: May 5, 2008 8:45 AM by infinite vortex
William R. Dickson Level 1 Level 1
Just set up 10.5 server on my G5, and trying to connect from 10.5 on my iMac. I have tried both with the server System Preferences set to allow Screen Sharing via VNC, and with Remote Management enabled for ARD. In both cases, I get authentication errors when trying to connect from home. I have tried with both the full username, and with the short name of the only account on the server. My assumption is that, since this is the administrator account, I don't need to setup explicit privs for it on the server.

I can authenticate without any trouble with both Server Admin and Server Preferences.

The Firewall is not enabled on either machine, although I am behind a NAT router at home -- is it necessary to open any special ports to enable screen sharing? Is it possible that having these ports closed would produce an authentication error?

Thanks for any help.

iMac 2.16 GHz Intel Core 2 Duo, Mac OS X (10.5.1)
  • William R. Dickson Level 1 Level 1
    Additional note: following these instructions:


    ...I tried kickstarting ARD from the command line:

    Activated Remote Management.
    Stopped ARD Agent.
    Stopped VNC Privilege Proxy
    Stopped VNC Server.
    Stopped RFB Register MDNS
    localadmin: Set user remote control privileges.
    localadmin: Set user remote access.

    ARD agent seems to be running:

    3039 ?? Ss 0:00.20 /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAg ent

    I can connect to other servers on the same network my server is plugged into via ARD. However, my own server spends about 30 seconds trying to authenticate before producing an "authentication failed" error.
  • Paul Kleeberg Level 1 Level 1
    Did you get screen sharing to work? I found I had to punch a hole in ports 5900-5903 in my firewall to make it work across the Internet. Not sure if that is the right thing to do. Just started researching this.
  • Larry_S Level 1 Level 1
    Hi Paul,

    I don't use ARD and wanted to just screen share with my Xserve (10.5.1 co-located at an ISP) running via VNC (using JollysFastVNC and Screen Sharing) from my local PowerMac G5 (10.5.1).

    Here's what I did:

    ARD wasn't needed, and in fact, since a recent update, caused me to not be able to log in at all. You can't have both Screen Sharing and ARD running at the same time, so I turned off ARD and just left Screen Sharing on in Sharing Sys Prefs.

    Avoid use of VNC over normal ports 5900-5903 as it is insecure. Apple uses some encryption with Screen Sharing but it is still over those ports and I don't trust it like I do SSH. I SSH tunnel into my Xserve (you need SSH port 22 open) using:

    *ssh -4 -L 9999: user@my.xservehostname.com -p 22*

    Normal VNC ports are closed on the server's firewall.

    This creates a local forward SSH tunnel from unused port 9999 to the Xserve's port 5900 behind it's firewall and I connect to it using my VNC clients with and the Xserve's Screen Sharing password for controlling. Screen Sharing, on the client, asks for the Xserve user's login password when connecting however (??). Screen Sharing's prefs can be set to the faster secure authentication. Jolly's VNC client is still faster and has better mouse response.

    I had problems with +ssh -4 -L 9999:localhost:5900 user@my.xservehostname.com -p 22+ for some reason it would fail randomly if I substituted localhost for (??).

    More on ssh tunnels: http://www.securityfocus.com/infocus/1816

    I previously figured out a way to set up Screen Sharing remotely if you have ARD screwing you up, or something similar.


    Also, if you use exchanged SSH keys you can log in without a password. Generate your client and server keys with 'ssh-keygen' and copy your clients '~/.ssh/id_dsa' contents over to the server's '~/.ssh/authorized_keys' file (create if necessary - MacRoman with Unix line endings). See 'man ssh' for more info.

  • William R. Dickson Level 1 Level 1
    It turns out I can authenticate as "localadmin", just not as the actual admin user I created. Still no idea why, though I suspect it has something to do with OpenDirectory, which I just don't understand well yet.
  • Patrick Gibson Level 1 Level 1
    I don't get this either, so you're not alone! It's most frustrating that Leopard Server doesn't "just work".
  • William R. Dickson Level 1 Level 1
    You know what else is frustrating? I can't seem to create new topics now!
  • Julien vander Straeten Level 1 Level 1
    Same here ... desperately waiting for 10.5.3 :-/
  • Antonio Rocco Level 6 Level 6
    Servers Enterprise

    I'm going to assume you configured your Server in Standard Configuration and not Workgroup or Advanced?

    When using Standard in setting up the server DNS is automatically configured for as well as the Server taking an Open Directory Master Role. The admin account created at the beginning is for administering the Open Directory. Unknown to you and not documented at all - as far as I can see - is the 'Local Administrator' (localadmin) account.

    You only become aware of this account if for some reason you have a problem with the Server which involves demoting to Standalone (ie not an Open Directory Master) once this happens you find you can't log on to the Server anymore or communicate with any of the Server applications because it won't accept any username or password other than root and localadmin for the name and the password defined for the original admin account you created right at the beginning.

    Sometimes it does not even take demotion to find yourself locked out of the Server. Some have experienced this problem when running the Security Update or when some other problem has occured.

    Part of the process of creating an Open Directory Master involves the creation of a 'special' directory administrator account. This account is used for administering the LDAP node. If demotion takes place this account gets blown away along with all users and group accounts that exist in the LDAP node, in fact everything to do with Open Directory is destroyed apart from Users' home folders.

    Why demote if this happens? Sometimes the LDAP database gets damaged/corrupted beyond a point where normal troubleshooting methods fail. This can happen for a whole variety of reasons but more often than not is due to a poorly configured DNS Service. You basically only have two options once you reach that stage. A server reinstall involving a format and rebuild or a demotion to Standalone. Which option would you choose? Prior to demotion you can (if you have the chance) export users and groups or even archive the LDAP database itself for restoration later on. This is a useful option as everything to do with the LDAP Server is retained - passwords, users, groups etc. The other method of saving users etc does not retain passwords.

    As time goes on and you become more familiar with your server you will find more and more of this information out for yourself. Hopefully the simple advice I've given helps you understand Open Directory a little better.

    Hope this helps, Tony
  • infinite vortex Level 7 Level 7
    To use ARD (and presumably Screen Sharing) you need to authenticate using an account in the Local directory rather than the /LDAPv3/ directory.

    It's really as simple as that. I butted my head for a while this problem myself.
  • Julien vander Straeten Level 1 Level 1
    We probably all tried that, but the server stopped authenticating us for some reason while any other service, other than ARD doesn't seem to react like that.

    SSH: No problem
    AFP: No problem
    etc ...
    ARD: Failed authentication

    I tried kickstart ... but ARD's dead now ...
    I'm afraid I'll have to plan a visit to the datacenter soon :-/
  • infinite vortex Level 7 Level 7
    Maybe you need to ensure that the Local directory is in fact being searched for authentication. You're going to have to do this while in front of your server (which is a right pain for many). If you open Directory Utility do you get /Local/Default listed in Search Policy > Authentication?

    If you don't then this could be your problem. Many don't actually notice this given they, which includes myself, would normally use an administrator from the /LDAPv3/ directory.

    I do have a similar problem where I am unable to reach workstations via ARD let alone even log in on the workstation using a local administrator account unless I physically disconnect it from the network. The source of this problem is probably the similar to your own. I'll be checking the Search Policy when I'm onsite on Monday.
  • iToaster Level 3 Level 3
    can you connect via VNC on the LAN?
    if it doesn't work on the LAN it's not going to work from home
    if the server is behind a router and a firewall you'll have to open the correct ports and setup forwarding rules.
    or setup VPN (which will also need firewall and port forwarding rules) and use VNC over your VPN connection. Using VPN will allow you to "see" any other macs on the lan remotely, access file shares intranet,etc just like being on the LAN, providing everything is configured correctly.
  • Julien vander Straeten Level 1 Level 1
    It doesn't even work for the local admin account, and ARD is the only service that doesn't work properly .
  • infinite vortex Level 7 Level 7
    OMG!! I've at least found the issue here. As it turns out the password for the local system administrator on the workstations are being "over-run" by the password of the LDAPv3 administrator. So if I have…

    Local administrator account : localsysadmin
    Password : password-123

    LDAPv3/directory administrator account : admin
    Password : password-abc

    I need to put in the…


    … combination for ARD to work on the workstations. How whacked is that!?!?!?!?