[Freeipa-users] Apple OpenDirectory Integration

Thu Feb 4 17:09:03 UTC 2016

I have a few Macs with 10.7 (mini) and 10.9 (MB air). Let me know if I
can help using them as guinea piggies

On Thu, Feb 4, 2016 at 11:57 AM, Alexander Bokovoy <abokovoy at redhat.com> wrote:
> On Thu, 04 Feb 2016, "Răzvan Corneliu C.R. VILT" wrote:
>>
>>
>>>> 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.
>
> Yep.
>
> I've moved the ticket 4813 to needs triage basket and referenced this
> thread.
>
>
>>
>> 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.
>
> What VMs? Mac OS X?
>
>
> --
> / Alexander Bokovoy
>
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project