Connect to Server issues
 

Hello,

I'm relatively new to the Mac environment and have come across an issue with which you all may be familiar or, at least, may have ideas.

We have a department that uses strictly Mac workstations (I believe all are G5s) running Mac OS X 10.5 or 10.6. We have a Mac XServe Raid server running Mac OS X 10.4. The issue we are facing is this: The users have a problem connecting to the server in the morning at the same time. All usually put the computer to sleep the night before, instead of shutting down, to mitigate this, but it doesn't always work. When they attempt to connect to the server (via Finder > Go > Connect to Server; or Command + K with the the address being smb://IP_Address) they are prompted to enter a user name and password, where normally they would be greeted with a dialog box listing the share points on the server. After they enter their credentials, they get a message stating "You entered an invalid username or password. Please try again". Anywhere between 10 minutes and an hour may pass before they are successful, using the same technique mentioned above.

Now if they disconnect or reboot during the day, there doesn't seem to be an issue.

Any ideas on why there would be this delay or what the issue may be here?

Is the server a standalone server, Open Directory Master or Connected to an AD domain ?

Any reason for using SMB apart from having more than 10 connections to server without paying for an unlimited client licence ?
Even in these situations i tend to have 9 machines connecting with AFP and the other machines connecting with SMB !

Try connecting with AFP as a test.
If no one is connected try and restart SMB in Server Admin.

I have had issues with Leopard & Snow Leopard "Slow authentication with AFP to Tiger Servers"
Depending on your set up turn authentication to "standard" on the server.
Ie turn off secure connections unless your network relies on it !
Open Server Admin > AFP > Setting > Access > Turn from "any method" to "Standard" and Apply settings

Maybe tweak the Server Admin > Windows > Setting > Access > Authentication
Try turning off NTLMv2 & Kerberos ( or other combinations) and try connecting.

Check the SMB logs on server and Client machines for any clues.

Thanks
 

The server is on a AD domain, however, as I understand it, the users are not using AD credentials or only have them for email purposes. I can find out more on that if needed.

I will try your suggestions to see if anything changes and post an update when complete.

Ironically, nobody had issues connecting this morning, to my knowledge. Go figure.

I was unaware of client licensing for SMB. That may be the issue. We have 15 users all using SMB though I just now had about 9-10 of them change to AFP to see if anything changes.

Thanks again!

If it is unlimited client server it doesn't matter and OS X Server uses Samba not SMB, so it has unlimited client access anyway.

It sounds to me like the machines go to sleep, it kills the network connection or it times out from being idle and then the Finder freaks out when it tries to reconnect. I had this problem on my Tiger laptop when i would take it home from work and open it back up and the Finder would try to reconnect to all the mounted drives I had while at work. About 5 to 10 minutes later after the Finder was done freaking out I could use my laptop, but until then beach ball of death.

So, can you give me a bit more info about your environment? Desktops? laptops? OS X server? Open Directory or local accounts?

Thanks

There is no limit client connections for SMB !

More info required to troubleshoot......and the King of Servers (tlarkin) is on board things might get sorted quicker !

Also another trick of the trade if your passwords are stored on Client machines :
Open Keychain Access and Delete and references of network connections to server then try and reconnect and enter the username/password.

Ok. Our environment is mostly a Windows environment. We have AD and we use Exchange. Our Art Department uses Macs and all have static IP addresses, and the users' passwords are not set to expire. They are all using iMac G5s running, I believe, Mac OS X 10.5 or later. We have two Mac XRaid Servers and the one in question is running Mac OS X 10.4 also with a static IP address. The users log in to their Macs with local accounts, and the art department is saying they are using their AD credentials to connect to the server.

I just had several users switch from SMB to AFP and they are connecting ok now, (when they disconnect and reconnect), but the real test, I guess, will be tomorrow morning as that is when they normally experience the issue (between 8:00 and 9:00).

The Mac Server is getting backed up via Symantec Backup Exec, however the job is run in the evening and is done before midnight, so I don't think that's an issue.

Thanks again. If there is any other info you need that may help you with this, please let me know.

Are you using kerberos? It wasn't fully implemented until 10.5 server/OS but I do believe 10.4 had partial kerberos support.

How are they authenticating to the shares?

How do I verify if Kerberos is being used?

In Workgroup Manager, we sort the users into a group and share the folders on the server as a share point to those in that group. Does that help?

Kerberos is a ticketing system, you could have a REALM set up on one of your servers and then tell your Mac server to connect to that realm.

So, it sounds to me like connections are timing out and being severed from being idle and clients going to sleep? This can be remedied by an easy log out hook, but that would not teach your users to log out every day.

Ok. I think I found it. In Server Admin, under the Windows section under the server name in Computers and Services, then under the access tab NTLMv2 & Kerberos is checked along with NTLM and LAN Manager. Client connections is Unlimited. Under the Advanced tab, it is registered with the WINS server and the box next to Homes: Enable virtual share points is checked. The server has the role of a domain member. Is that the information you needed?

OK, so it sounds like when they authenticate against AD they are getting a kerberos ticket, which may or may not be how they map drives, or authenticate to anything else on the network...


So, if they are getting kerberos tickets and the client goes to sleep or the connection goes idle it may expire the ticket, and that would cause them to authenticate to the share.

Does that make sense?

So, you would have them somehow get a new kerberos ticket, and by logging in/out that should do the trick because you are issued one when you log against AD/OD.

That is your problem right? They go to sleep and then the next day the mapped drives ask for passwords?

While going through Server Admin > AFP > Settings > Idle Users I noticed the radio button for "Allow clients to sleep ___ hours - will not show as idle" is checked and the setting is for 24 hours. If I have all my users use AFP, will this keep them from having the disconnect and authentication issues? (I have under Maximum connections the Unlimited radio button selected)

In response to your last post, tlarkin, would be yes, yes and yes. So you're saying, if I have them disconnect the night prior, then attempt to connect the following morning, a new ticket would be issued and they should be able to connect instantly?

Yes, logging out or shutting down would probably remedy your problem all together.

The problem with AFP or any networking protocol is that when a client sleeps it generally shuts down all network traffic. It is no longer going to request an IP from the DHCP server and so forth. So if you wake it, and it needs to grab a new IP, well that can take a few moments before it is even back on the network.

Apple knew this was an issue and addressed it a bit in 10.5 and added in wake on demand technology in 10.6 which is suppose to fix a lot of sleep/networking/sharing issues.

Kerberos is date/time sensitive and only allows for a difference of like 5 minutes, so all your clients/servers must be in sync. It also is set to expire every so often and a new ticket is issued. Well if the client is asleep, I can't very well request a new ticket.

If they have a static IP address though, they shouldn't have to request an IP from DHCP, right?

Also, this might pose a problem with the solution you offered. A few users have reported that they experience the problem when they shut the computer down (e.g. shut down on Friday evening and then attempt to connect on Monday morning.) Would shutting the computer down while still connected to the server cause the problem as well? If so, then they need to disconnect from the server before they shut down, correct?

Thanks again for the help!

That all depends and that is the tricky part, and/or the art of form of enterprise networks. You find little quirks like the one you have, and it may only be particular to your environment.

I guess what I would do, is get a machine to fail and start looking in the system.log file and see what messages are coming to cause the failure.

I mean I have all sorts of weird problems, but my network is frankenstiened of network equipment mixed and matched for the last 9 years. So I got 9 year old switches in some parts that run 10/100 and I got Gig switches in other parts that are a year old.

If this problem is intermittent I would start by comparing a working client/user to a non working client/user and start troubleshooting from there.

Also, you mentioned you were running 10.4? OS X 10.4 had shoddy kerberos support and was not fully kerberized until 10.5.

Good deal. I'll see if I can do some sort of a process of elimination and see what happens.

Thanks again. I've learned a lot about Macs in the last couple of days (and I'm sure there's a lot more to learn). I'll be sure to post back any results I get.

Does a reboot fix the issue, or does it still hang from being woken from sleep? I mean if it was a kerberos ticket issue I would think a reboot would fix it every time. Unless the time/date were out of sync. You gotta make sure all the systems display the same time and date.

I recall one of the users stating a reboot didn't fix it. I'll have to do a test to see if the times are the same throughout.

I recall a user telling me that at reboot did not fix anything. Good point on the systems time and date. I'll verify that that is correct for the machines.

You should really try and confirm if Kerberos is being used on your network.

Can you confirm if your are using a Unlimited Client Licence version or 10 client version of OS X Server. You can find this out in Server Admin.

Has moving to AFP helped ? If so move all the client machines ( if you have unlimited licence ) to connect using AFP, IMHO preferable for Mac Client machines connections to OS X server anyway.

Thanks for all the help. I had a control group with the same configuration that had been having issues and then had two other groups, one using SMB and the other using AFP with both groups have a mixture of staying connected and putting their computer to sleep, disconnecting and putting their computer to sleep, and shutting their computer down. Those using AFP experienced no problems connecting while there was about a 50% success rate in connecting to the server with those using the SMB protocol. I had those who were having problems connecting switching over to AFP, and they had no problems connecting.

Thanks again and we can mark this as solved!

Agentx,

In response to your post, Kerberos is being used and we are using the unlimited Client Licensing. Switching to AFP appears to be solving the problem. Thanks!

So, the fact you have the idle and sleep settings with AFP they keep the connection alive where SMB probably kills it, thus never updating your kerberos tickets.

Just a guess, but sounds like you are on the right track. good luck with your macs.

All good happy days ;-)

So i would also advise all your machines sync with your local NTP server or all computers use the same external time clock.
Kerberos does not operate very well with non synced clocks.