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

I've moved the ticket 4813 to needs triage basket and referenced this

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

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.
What VMs? Mac OS X?

/ Alexander Bokovoy

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

Reply via email to