[Freeipa-users] Apple OpenDirectory Integration

Thu Feb 4 13:46:34 UTC 2016

>> It's static data. It's a concatenation of multiple strings: a
>> hard-coded one, the uid and the realm. It only changes if you rename
>> the user account. It is used to route the authn phase to the Kerberos
>> account (no PAM configuration!!!).
> I wonder if we should use CoS plugin to get this data added to user
> entries instead of storing it in every single user's LDAP entry -- the
> only thing that is different is uid but the rest is the same, right?

Right. At least for single realms with no trust domains. If you have an identity from another realm, you need to use the KRB5 principal from that realm. So instead of mapping to the UID, we should map to the krbPrincipal.

The format for altSecurityIdentities is:
=======================================
"Kerberos:" + $krbPrincipal
Or for certificate logon:
"X509:" + "<T>CN=" + $issuerRDN + "<S>CN=" + $subject. Such as:
"X509:<T>CN=Apple Root CA,OU=Apple Certification Authority,O=Apple Inc.,C=US<S>CN=com.apple.idms.appleid.prd.deadbeefdeadbeefdeadbeefdeadbeef"

It's identical to the altSecurityIdentities from MSDN and was adopted by Apple from Microsoft. See https://msdn.microsoft.com/en-us/library/cc220106.aspx
In theory it can also be used for SC Certificate logons (see above example). It is also used by iCloud for certificate logons.

The format for authAuthority is:
=============================================
Kerberos
--------
Minimal Kerberos:
";Kerberosv5;;" + $krbPrincipal + ";" + $realm + ";"

Fully compliant Kerberos:
";Kerberosv5;" + "0x"$GUID_HEX + ";" + $krbPrincipal + ";" + $realm + ";" + "Realm Public Key"
Documented on: https://developer.apple.com/library/mac/documentation/Networking/Conceptual/Open_Directory/openDirectoryConcepts/openDirectoryConcepts.html#//apple_ref/doc/uid/TP40000917-CH3-68599

Basic Authentication
--------------------
Of no interest, just crypt(). Documented on:
https://developer.apple.com/library/mac/documentation/Networking/Conceptual/Open_Directory/openDirectoryConcepts/openDirectoryConcepts.html#//apple_ref/doc/uid/TP40000917-CH3-68270

Apple Password Server Authentication:
-------------------------------------
;ApplePasswordServer;0xfc00000000001e291a400254ba69508,1024 65537 100000735360000022652669667510124737971525265977003458292838259662475941942339637701783031842665637489899899968013535474647377427038990743911664412758698759306606987798849786426049586039725915353359580583450027978985802381494661566820916379229460639580871881869418576860074704243214464804408968770344748232621 root at ipa.example.com:172.23.36.138
Documented on: https://developer.apple.com/library/mac/documentation/Networking/Conceptual/Open_Directory/openDirectoryConcepts/openDirectoryConcepts.html#//apple_ref/doc/uid/TP40000917-CH3-68312
Partly implemented in https://code.google.com/archive/p/lpws but without an IPA Bridge.

Shadow Hash Authentication (used by local accounts):
----------------------------------------------------
;ShadowHash;HASHLIST:<SALTED-SHA512-PBKDF2,SRP-RFC5054-4096-SHA512-PBKDF2>
Documented on:
https://developer.apple.com/library/mac/documentation/Networking/Conceptual/Open_Directory/openDirectoryConcepts/openDirectoryConcepts.html#//apple_ref/doc/uid/TP40000917-CH3-68474

Local Cached User Authentication (used by road-warrior scenarios on the local systems):
---------------------------------------------------------------------------------------
Documented on:
https://developer.apple.com/library/mac/documentation/Networking/Conceptual/Open_Directory/openDirectoryConcepts/openDirectoryConcepts.html#//apple_ref/doc/uid/TP40000917-CH3-68528

Netlogon Authentication (used by Active Directory)
--------------------------------------------------
;Netlogon;razvan.vilt;MYDOMAIN

iCloud Authentication (obvious)
-------------------------------
;AppleID;razvan.vilt at me.com

Disabled Authentication (this needs attention)
----------------------------------------------
Basically put ";DisabledUser;;" in front of the previous authentication method.

>> OK. So on Linux you do an automount map for the file server with the
>> homes and state that the user home directory is in /home/$userName
>> 
>> On Windows, you give the home folder as \\server\share\folder, but
>> assume that the protocol is SMB/CIFS.
>> 
>> On Mac OS X, you give the protocol, the server and the share\folder.
>> You could use automount, but I've never seen any OS X admin do that.
>> Mainly because you loose the roaming ability (they call it file
>> synchronization). Mac OS X can use roaming profiles just like Windows.
>> They don't have to be mounted except at logon time which is important
>> for road-warriors. Since most Macs are laptops, the road-warrior
>> scenario is assumed. Otherwise, you just get local homes.
> If you don't provide any share details, what happens? Will Mac OS X
> would fill-in the defaults based on the user name?

It would create a local profile in /Users/$userName. Which in reality is what most Mac admins do anyway. Roaming profiles are not used very much.

If you bind to Active Directory on a Mac, you get the following Attributes:
NFSHomeDirectory: "/Users/razvan.vilt"
OriginalHomeDirectory: "<home_dir><url>smb://myFileServer/usersShare/razvan.vilt</url><path>/</path></home_dir>"
The attributes are made by the Active Directory plugin automatically from "\\myFileServer\usersShare\razvan.vilt".

> 
>>> I'd open one or more RFE tickets on https://fedorahosted.org/freeipa/newticket
>> 
>> One was already opened (https://fedorahosted.org/freeipa/ticket/4813)
>> and I'm in CC. Since nothing happened for 1 year after my offer to
>> document it, I've decided to start this thread.
> It mostly boils down to IPA developers not really having access to Mac
> OS X devices. And load of other tickets to solve, of course.

I can provide VMs and/or access to VMs. FreeIPA is Python, 389 DS and 389 plugins. It's overkill for me to go under the hood.