Somehow when clients are logging in they are retaining a login that doesn't allow them to see the shares from the
Snow leopard server. I've trashed managed prefs, trashed the keychain and recreated, but when the client
Logs in, and performs a connect to server command, it auto attempts to login to the server and the account credentials
Are no longer valid.
I'm thinking next it might be a plist acting up somewhere
But where?
did you try unbinding and rebinding the computer to the directory server?
was the computer imaged from another computer? if so how did you deploy the image onto the client computer? (disk utility, System Imaging Utility, other )
Imaging has nothing to do with this. Computers were Alll built from os disc.
Computers are
Only managed by an os x sus server, that is their only binding.
Let me rephrase my question...
In what places besides Keychain would login credentials for afp share be stored?
That stuff is stored in Keychain.
There are several keychains around, and centrally including the system keychain. (Did you trash them all, or just the local user's keychain?)
And I too would try an unbind and rebind via directory services.
Also have a look at whether the shares are enabled for guest access. If not, turn that on as a test.
login items can include alias and bookmarks for AFP. bookmarks in login items can contain login credentials.
If the account logged into is from a directory service the act of logging in can created KDC ticket. This ticket can be used for authentication to network services such as AFP.
I had Trashed the local user's keychain, as well as the admin's login keychain.
I had left the system keychain intact, as it contains the passwords for the
Airport connections. i will try trashing those as a possibility.....
No login items other than iTunesHelper exist on these systems.
I will also look at the following items:
~/Library/Preferences/com.apple.NetAuthAgent.plist
Library/Preferences/com.apple.AppleShareClient.plist
Library/Preferences/com.apple.AppleFileServer.plist
I found entries for the shares in each of these plist files.
Surely deleting them would restore the proper functionality?
Ok, removing those did nothing.
I also tried a new out of the box iMac running 10.6.6 and it connected to the shares just fine
through afp. No problems.
OS I know that the Server is fine, afp is working like it should (server wise) and that a brand new client
works out of the box beautifully.
At this point, after trashing plists and and keychains, all that is left is to try and reinstall
the OS, wiping out any corruption there. I'll try that tomorrow.
You could try unbinding the computer from the directory service. completely deleting the KDC, then rebinding the KDC, then re-binding the computer to the directory service.
1) unbind from directory services
2) In the Utilities folder, open Keychain Access. In the System keychain, find and delete the three com.apple.kerberos.kdc entries - a certificate and a public/private key pair generated from that certificate. (witch it sounds like you may have already done so)
3) In Terminal, run 'sudo rm -fr /var/db/krb5kdc' - this will destroy the local KDC database.
4) In Terminal, run 'sudo /usr/libexec/configureLocalKDC' - this will regenerate the local KDC database, including a new certificate and SHA1 hash.
5) Bind the machine to directory services."
Titan,
I've done one, two and 5 already with no luck.
I will try the complete steps in order and see what we get there.
Titan,
I performed all five steps, & the issue still persists.
On another machine in this same lab, with the same issue,
to rule out accounts, I went to that machine and erased all accounts,
and created a new Admin account.
Logged in as that user, and the issue still occurs:
When trying login to the server via afp at afp://fqdn
it tries to "auto login" into a share with credentials it no longer has
(you cannot login to the share 'xxxx' because you do not have privileges to do so)
What it needs to do is present the proper login screen, so that new credentials
( name and password) can be entered to access the new share.
that window never comes up; it isntead tries to "auto login" with credentials
it stored SOMEWHERE, for an old share.
At this point, I'm going to try re-installing the system folder ( w/ Archive and Install)
as I've ruled out it's not in a user account that is causing the issue, but the system itself,
as by my new test above.
Reinsalling system didn' work, but i found what did!
Apparently when I set up the original share, I set guest access to r/w for the share (ACL),
And the new share resides upon the same physical drive as the old share.
Well, for the managed group (SUS Bind), I had guest access set to off.
Afp was telling the client to login as guest, and it was guest access
They were attempting to use to connect to the old share.
(which I had disabled in server admin).
Turning off guest access in afp, and removing the guest ACL,
And pow! The clients login correctly, with the authenticating
Screen coming up as normal!
How to reset connection to server?
