Kerberos Auth with AFP on Lion Clients (AD Bound) not working

Kedgar
Contributor

Has anyone had a problem yet with AD bound Lion Clients authenticating via kerberos to AFP shares? My servers are 10.6.8 and AFP with Kerberos auth works fine on previous versions of OS X.

Symptoms: Connect to an afp share and prompted for authentication klist shows I have valid tgt and service tickets for cifs but no service ticket for AFP

Thanks,
Ken

3 REPLIES 3

suleymantwana
New Contributor III

We do have the same problem but not with Mac OS X Server. Our problem is with ExtremeZ-IP shares. So, the problem is not specific to Mac OS X Server but to any AFP connection.

Bukira
Contributor

did you find a fix for this, i have the same issue with ExtremeZ-IP and group logic can offer no help and say its not their issue

acdesigntech
Contributor II

kind of an old post, but just ran into this and solved it yesterday at work. Well, ran into it Thursday, solved it Friday.

My environment consists of MS Active Directory and two ExtremeZ-IP enabled file servers. I'm thinking that Apple's change from MIT kerberos to Heimdal Kerberos is what's causing the issue here: When a Mac user logs in, they do not get a TGT from the MS Active Directory*. According to MITs blog, you have to add the ```
default_principal
line to the authorization file in /etc/pam.d/authorization (find the line that starts with
auth optional pam_krb5.so use_first_pass use_kcminit
, and edit it to read
auth optional pam_krb5.so use_first_pass use_kcminit default_principal
```).

After adding that, my Macs are consistently getting TGTs on login and authenticating just fine to the EZIP shares.

My second issue comes in with laptop users who may or may not be connected to the network when they log in. They won't get a TGT regardless of what settings I have in /etc, so I need to make sure that they can still get to those EZIP shares even with a TGT since this method had worked just fine in 10.6. The problem there is yet again, apple has unilaterally declared some authentication protocols as "insecure," and so has disabled them. Thanks Apple.

It seems that EZIP relies on the DHCAST128 auth protocol, so you have to reenable that in /Library/Preferences/com.apple.AppleShareClient.plist file: ```
sudo defaults write /Library/Preferences/com.apple.AppleShareClient afp_disabled_uams -array "Cleartxt Passwrd" "MS2.0" "2-Way Randnum exchange"
``` Allegedly this change is made unnecessary by EZIP v8.01 or higher, but I have not been able to verify that.

Restart the Mac. With both of the above changes made, afp shares advertised by EZIP servers will now use the valid kerberos TGT generated on network login, or default to username/password auth in the case of a non-network login.

Go Go gadget Apple!

* Seems to only affect units upgraded from 10.6. Newly imaged 10.8 Macs do not seem to exhibit this behavior. Or at the very least no one has called the service desk about it :/