>> 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 

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:
Minimal Kerberos:
";Kerberosv5;;" + $krbPrincipal + ";" + $realm + ";"

Fully compliant Kerberos:
";Kerberosv5;" + "0x"$GUID_HEX + ";" + $krbPrincipal + ";" + $realm + ";" + 
"Realm Public Key"
Documented on: 

Basic Authentication
Of no interest, just crypt(). Documented on:

Apple Password Server Authentication:
;ApplePasswordServer;0xfc00000000001e291a400254ba69508,1024 65537 
Documented on: 
Partly implemented in https://code.google.com/archive/p/lpws but without an IPA 

Shadow Hash Authentication (used by local accounts):
Documented on:

Local Cached User Authentication (used by road-warrior scenarios on the local 
Documented on:

Netlogon Authentication (used by Active Directory)

iCloud Authentication (obvious)

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"
The attributes are made by the Active Directory plugin automatically from 

>>> 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.

Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project

Reply via email to