Home Forums OS X Server and Client Discussion File Serving 10.2 clients can’t authenticate against 10.4.3 for AFP?

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • #365400
    hiredman
    Participant

    I recently moved our 10.3 fileserver duties to new Xserve running 10.4.3. Users are currently set with Shadow passwords after the migration and everything is great with OS9, 10.3, 10.4 and Windows users but 10.2 clients can’t authenticate.

    Server shows “user failed to authenticate 5 times” and I occasionally get “PAM errors” on the client side but not always. Turned off firewalls for trials so it’s not that but can’t see any reason 10.2 users can’t get in.

    Was planning to migrate to OD and I assume that would solve the problem but wasn’t ready just yet…

    TIA,

    =Tod

    #365405
    hiredman
    Participant

    Doing [cmd]K and locating the server through browsing or by IP address.
    It talks to the server it just doesn’t authenticate – you get a “Unknown user, incorrect password, or not authorized to login” message.

    Right now I’m sorting through the PAM docs trying to figure that out. It seems to me that 10.2 is either supplying credentials in the wrong format or 10.4 is misinterpreting what is sent – maybe in PAM rules (?).

    I deleted mcx_cache on the client machines that had it but that doesn’t seem to make a difference. On the 10.2 machine console you see the afp kexts load but it makes no difference. I’ve been upgrading the 102 machines as I find them but I’d rather solve the issue.

    =Tod

    #365408
    hiredman
    Participant

    I have the AFP Log enabled and set to log both Access and Errors with “login” checked under access.

    The error log is completely empty and the access log shows no sign of the failed attempts. It shows the normal login, sleep request etc. but the failed logins show nothing.

    The only log entries I’ve found are in console, system, and asl which have errors relating to the failed attempts:
    console:Fileserver DirectoryService[52]: Failed Authentication return is being delayed due to over five recent auth failures for username:user.

    system: very similar to above

    asl: [timedate] [Facility daemon] [Sender Directory Service] [PID 52] [Message Failed Authentication return is being delayed due to over five recent failed attempts for username:user] [Level 1] [UID -2] [GID -2] [hostserver fileserver]

    I can find no mention in either Appletalk connections or errors log. BTW I have Authentication set to “Any Method” and everything one except guest access.

    The only other odd thing I’ve seen in the console of the client machine was an SSH connection timeout warning after several log in attempts. In case 10.2 was attempting to make an SSH connection and turned off the firewall but it made no difference. (Make SSH connection in the “Options” of the login dialogue is off. I tried it both ways to no effect.)

    =Tod

    #365423
    hiredman
    Participant

    I tried turning off AFP and didn’t work, tried restarting after turning it off and that didn’t work. I did TCPDUMPs and sent them to you via messaging off-line.

    Basically they look the same except after about 12 back and forth communications the 10.2 client starts an SSH attempt and sends 7 messages on-one to the server and then stops where the successful negotiation transfers two “S” messages and then starts a session.

    Why would the 10.2 client be falling into an SSH attempt? The “connect SSH” choice in the options dialogue is off. (Actually I’ve tried it both ways.) I have seen the “ssh timed out” message I mentioned earlier and I’ve tried connection with the firewall off but that didn’t help either. (I have SSH firewalled off but not SACLed.)

    Thanks for all your help,

    =Tod

    #365459
    hiredman
    Participant

    Update: I’ve been in communication with Apple and it looks like we’re into “known issue” land where problems go to die…

    Apparently 10.2 automatically (unsuccessfully) tries to create an ssh tunnel to the server and the server is not expecting it to do that. I’m working on determining a work around right now and will post reports of success or failure as appropriate.

    =Tod

    #365516
    hiredman
    Participant

    Partial resolution: If you turn firewall AND ssh service off 10.2 clients can authenticate against server. Clients are trying to create an ssh tunnel before authenticating and during their waited for ssh to fail their auth window times out on the server. By getting them an abject failure response quickly (no ssh running, no firewall interfering) they can proceed quickly enough.

    Apple claims only clients that previously were required to ssh exhibit this behavior, but I’ve seen it in all my 10.2 attempts. Besides is a fresh 10.2 install in anyone’s interest at this point??? Rolling Eyes

    I’m going to try SACLing off clients and opening the ssh port on the firewall to the few 10.2 machines I have – hopefully this will allow 10.2 clients to get the rejection they so desire and allow me to run ssh on that box at the same time.

    I’ll post back with results.

    =Tod

    #365870
    Anonymous
    Guest

    Just so you don’t feel left out, I have experienced this with 10.2 clients at a number of different sites. The ssh theory makes sense to me. Haven’t been able to confirm as we migrated all users to 10.3 / 10.4 as required.

    Couple of odd points I noticed were – even with OD password management set to disable user after ‘x’ failed logins, the 10.2 users never got locked out. So it wasn’t a failed password as suggested by the client error message.

    I did try to reinstall the OS, but cannot remember now whether it was a clean format and install, or an archive and install. There may indeed be a preference somewhere, but it is not user based, as I have tried creating new users on the client system for testing and had these fail to log in as well.

    As you mention, I think this one will die in the ‘known issue’ pile.

    regards

    Sean

    #366608
    Ross
    Participant

    I actually ran into this today… I had to choose “Standard” for Auth. under AFP to get it to work (Kerb or Any method did not work), this was only with replicas and connected to directory servers. The master was not a problem..

    #377921
    cedge
    Participant

    [QUOTE][u]Quote by: Ross[/u][p]I actually ran into this today… I had to choose “Standard” for Auth. under AFP to get it to work (Kerb or Any method did not work), this was only with replicas and connected to directory servers. The master was not a problem..[/p][/QUOTE]

    I believe this only occurred in upgrade scenarios.
    Charles Edge

    http://www.krypted.com

Viewing 9 posts - 1 through 9 (of 9 total)
  • You must be logged in to reply to this topic.

Comments are closed