Apple Support Communities > Servers and Enterprise Software > Mac OS X Server v10.4 and earlier > Discussions
This discussion is archived
6323 Views 10 Replies Latest reply: Feb 2, 2008 2:02 AM by Antonio Rocco
Currently Being ModeratedDec 26, 2007 12:47 PM (in response to Brian Dodds)Ok, in the terminal I ran the following commands.
cd <name of my domain that is listed>
cd Users (or Groups)
On the systems that are still working I could see the list of users on the LDAP server.
On the systems that are NOT working I could not get past "cd <name of my domain that is listed>"
it just returned "Invalid path"... ???
What is going on and how do I fix it!Mac OS X (10.4.10)
Currently Being ModeratedDec 26, 2007 1:44 PM (in response to Brian Dodds)Hi
Go back to basics and start inspecting the physical structure of the network. Can you ping the server from the affected macs? Have you checked the network cables and wall ports? Have you checked the network settings are the same on the affected macs as they are on the unaffected macs? Are DNS server settings as well as Search Domains different on the affected macs? Are the affected macs assigning self-assigned IP addresses? Are they receiving correct information from the DHCP Server?
Hope this Helps, Tony
Currently Being ModeratedDec 26, 2007 3:09 PM (in response to Antonio Rocco)I can ping the server and the Lookup DNS info looks correct..... I have checked to make sure the Network settings are the same, they are all getting IPs from the DHCP and the DNS server is pointed to the right place...
Good thing most of the people that would be freaking out over the lack of a computer to use are still on vacation...
I can even log in as the local admin user and run software update and it finds my server just fine.
Update: I just booted one of these iMacs from an external FireWire Drive with a Clean install of OS X 10.4 and bound it to the server. I still do not get the "Other" login option and the red light with "Network Accounts Unavailable" is there... It must be a problem on the server for sure, but where and why do some systems work fine??? I'm going to try doing the same thing on one of the systems that is working...
Message was edited by: Brian DoddsMac OS X (10.4.10)
Currently Being ModeratedDec 27, 2007 2:43 AM (in response to Brian Dodds)Hi Brian
You can use netstat and ipconfig to troubleshoot this further. On the Server issue:
netstat -a | grep LISTEN
If you see * . ldap then slapd is listening for LDAP requests. If it comes back with 127.0.0.1. ldap then its only listening on the loopback address. Although netstat probably won’t tell you much as for other clients its working. On the affected clients issue:
ipconfig getpacket en0/en1/en2
Where en0/en1/en2 is the network interface being used. Another possibility is time sync issues. Perhaps the date and time is so far out on the affected clients they are not being authorized to access the server?
Hope this helps, Tony
Currently Being ModeratedDec 27, 2007 7:20 PM (in response to Antonio Rocco)When I did netstat -a | grep LISTEN I got a list of around 27 items and one of them was *.ldap
What should ipconfig getpacket en0/en1/en2 do?
I also looked at the Time sync and everything looks to be fine there.Mac OS X (10.4.10)
Currently Being ModeratedDec 27, 2007 7:31 PM (in response to Brian Dodds)I think I got it working, but I'm still very new at this and I not sure this is correct...
Normally when I add a binding I put in the server FQDN and then it looks for it finds it and asks for directory user name and password. This time, just for kicks I thought I would see what happened if I failed to give it this name and password. It worked! Have I been doing this wrong all along? When looking at the Security tab for this new binding I see the "Access to Directory, Use authentication when connecting" is now unchecked and everything seams to be working...
Can some one tell me what the proper method of binding a client to the server is?Mac OS X (10.4.10)
Currently Being ModeratedDec 29, 2007 7:44 AM (in response to Brian Dodds)Hi Brian
I’ve deployed numerous OD Masters in different environments and I have never supplied any network user name or password when joining network clients to the Kerberos Realm. As long as the local client’s .local name populates the first field there is really no need to add anything else. Continue past this point and OK the next window. If you have enabled the 'require directory binding' option in Server Admin then you would have to add an authenticated LDAP user (diradmin generally).
Is a link for 10.4 Server specifically. It may still help as a reference for 10.5 Server.
Hope this helps, Tony
Currently Being ModeratedJan 11, 2008 12:14 PM (in response to Antonio Rocco)I don't know why I was adding the user name and password when I knew in the back of my head that I should leave it blank.
The odd thing is that 3 of the systems worked that way for a time then stopped...
Oh well everything is good now.
Thank You.Mac OS X (10.5)
Currently Being ModeratedFeb 2, 2008 2:02 AM (in response to Brian Dodds)Hi Brian
I may be able to explain this.
Before even taking client computers out of their boxes configure you server first as an OD Master with all the desired accounts existing in the LDAP node as well creating networked auto-mounting home directories.
As you switch on the clients the setup assistant will go through the process of assisting you in setting up the client's default admin account. If the client's are connected to the same network as your OD Master and are receiving IP addresses from the DHCP Server (it can be the OD Master but it also works if the DHCP Service is elsewhere) then you will be presented with an option to create the default admin account with an Account that exists on the Open Directory. It would be at this stage that you would present account details (name and password) that exists on the LDAP server. The account that gets created locally will still take the short name admin but will have the password of the network user account used. After the restart you'll be presented with the usual login window with admin and 'other'. This is a useful way of creating one admin account on the OD Server that can be used to create the local admin account on all the client computers. This account does not require a networked user home folder as the home folder would be created locally.
Defining a new Computer List and adding all client computers to that list should allow you to present a list of all OD users and groups.
Apologies if you already know this but its useful to present it here as others may read this post who are probably not aware that this is possible.
Hope this helps, Tony