Can connect with Server Admin and Server Prefs, not Screen Sharing or ARD

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.

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:127.0.0.1:5900 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 127.0.0.1:9999 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 127.0.0.1 (??).

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.

http://discussions.apple.com/thread.jspa?threadID=1312397&tstart=45

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.

Larry

I don't get this either, so you're not alone! It's most frustrating that Leopard Server doesn't "just work".

Same here ... desperately waiting for 10.5.3 :-/

Hi

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

To use ARD (and presumably Screen Sharing) you need to authenticate using an account in the Local directory rather than the /LDAPv3/127.0.0.1 directory.

It's really as simple as that. I butted my head for a while this problem myself.

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

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

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.

It doesn't even work for the local admin account, and ARD is the only service that doesn't work properly .

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…

localsysadmin
password-abc

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