Re: [Freeipa-users] Apple OpenDirectory Integration

[Rob Crittenden]

"Răzvan Corneliu C.R. VILT" wrote:

Hi Guys,

I've done a small scale demo of using FreeIPA instead of an Open
Directory Server to serve Apple OS X clients. This is based on my
experiences from one year ago (Ticket #4813). I've also attached some
screenshots.


This is very cool and excellent work!

Currently the FreeIPA wiki points to 
http://linsec.ca/Using_FreeIPA_for_User_Authentication#Mac_OS_X_10.7.2F10.8 
for instructions on configuring MacOS. Are these sufficient to match 
what you've accomplished?



*Here's what works:*

  * Host sees the IPA Server
  * Host is able to register to the IPA server
  * Host creates a computer account (needs a bit of help here)
  * Host sets it's own random password (including kerberosPrincipalKey
and kerberosExtraData)
  * Host can see the users and other computers in the LDAP
  * Host can use TLS registration with FreeIPA's own root certificate as
found in cn=CACert,cn=ipa,cn=etc
  * Host can use just Kerberos for authentication and doesn't need an
Apple Password Server


*Here's what needs to be done to get there:*

  * Create a cn=config,$baseDN entry (attached example ldif). This can
be created automatically based on a template.
  * Create and ACI that gives anonymous read access to cn=config,$baseDN
(SNIP #3)
  * Modify an existing ACI to give altSecurityIdentities and description
to anonymous/public consumption (SNIP #4)
  * Extend the schema to include apple-configuration (SNIP #1)
  * Extend the schema to include apple-user (should be renamed to
apple-account since it applies also to hosts) (SNIP #2)
  * Add PLAIN to the supported SASL mechanisms (I don't know why it's
missing anyway because it's restricted to TLS by default). For me,
without further investigation of the reasons, I had to also disable
CRAM-MD5 and DIGEST-MD5 on the 389 DS.
  * Make sure (if you upgraded from a v3) that you have OCSP and/or CRL
working
  * Add an _ldap._tcp entry in avahi and/or server the LDAP server via
DHCP and/or serve the search domain via DHCP and make the DNS-SD
service entries for it.


*Here's what's missing from FreeIPA:*

A 389 Directory Server plugin that generates altSecurityIdentities and
AuthAuthority values automatically for an objectClass=apple-account.
This would automatically present the following entries (user admin used
as an example):
--
altSecurityIdentitites: Kerberos:ad...@example.org 
AuthAuthority: ;Kerberosv5;;ad...@example.org
;EXAMPLE.ORG ;
--
AuthAuthority is interesting because it supports not only basic LDAP
authentication, but also Kerberos, Netlogon and Apple Password Server
and you can specify multiple authentication authorities (including an
Active Directory).


Is this generally static data set once during user-creation? If so them 
the framework can manage it w/o requiring a 389-ds plugin which means it 
would be far easier to do.



A better way to specify homes for users. Not everyone uses automount and
automount maps (although OS X can use them). We need to be able to
specify not the assumably mounted home directory, but the protocol (afp,
nfs, cifs, etc.), server and share/directory. Furthermore, most Mac
Admins will have a heart-attack if they see an auto-mounted
/home/$username instead of the usual /Users/$username.


Not sure what you mean. Do you mean having a way to map it by client 
type? You may be able to do it by having client-type-based automount maps.



*Here's what's missing from OS X:*
A way to request OS X to do GSS-TSIG registration to the DNS. We may
have an MCX method to do that, but I haven't investigated. NSUpdate is
available and has support for gss-tsig. I think that for Active
Directory it does this automatically, and if so, we should be able to
reproduce it.

A way to specify that the fqdn argument should actually be an FQDN. We
might have to write a 389 DS plugin to take the CN without the final "$"
and add the domain name after it.

SUDO Map support. Currently, the only way to specify if an account has
sudo rights is to make it an admin. This makes it clear that without
Password Server support (partly implemented in the LPWS project), the
usage scenarios are limited to normal users and SSO to servers. OTOH, OS
X only knows admin and non-admin accounts, so it's not that bad.

*Steps to produce my demo install before the patches below:*
ipa-server-install -r EXAMPLE.ORG  -n example.org
 -p deadbeef -a deadbeef -P
deadbeef --hostname=ipa.example.org 
--ip-address=172.16.23.138 --ssh-trust-dns -U --setup-dns --no-forwarders

Is anyone from Red Hat willing to pick this up? It would be a nice
addition. If so, I am offering to do the testing and fine-tuning for all
post-Tiger releases. I can also share virtual machines for server and
client configuration.


I'd open one or more RFE tickets on 

Re: [Freeipa-users] Apple OpenDirectory Integration

[Alexander Bokovoy]

On Thu, 04 Feb 2016, "Răzvan Corneliu C.R. VILT" wrote:



On 4 feb. 2016, at 12:16, Rob Crittenden  wrote:
This is very cool and excellent work!


Thanks. I've done most of the R 1 year ago for a client that has a
medium Mac-only network. Since a year passed, I wanted to share my
results in order make sure that the information won't be lost or
obsoleted. Furthermore, FreeIPA is a wonderful piece of software that
is making the life of admins around the world easier and due to BYOD
policies Macs should get more love.


Currently the FreeIPA wiki points to
http://linsec.ca/Using_FreeIPA_for_User_Authentication#Mac_OS_X_10.7.2F10.8
for instructions on configuring MacOS. Are these sufficient to match
what you've accomplished?


Nope, what I've accomplished is different. I've managed to get OS X
clients to register to the IPA server like it's an Open Directory
Server. No command line interaction on the clients at all. No need for
manual keytabs or manual file editing or PAM modules or Apple scripts.
Just click join in the System Preferences -> Users Preferences Pane.


A 389 Directory Server plugin that generates altSecurityIdentities and
AuthAuthority values automatically for an objectClass=apple-account.
This would automatically present the following entries (user admin used
as an example):
--
altSecurityIdentitites: Kerberos:ad...@example.org 
AuthAuthority: ;Kerberosv5;;ad...@example.org
;EXAMPLE.ORG ;
--



Is this generally static data set once during user-creation? If so
them the framework can manage it w/o requiring a 389-ds plugin which
means it would be far easier to do.


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?




A better way to specify homes for users. Not everyone uses automount and
automount maps (although OS X can use them). We need to be able to
specify not the assumably mounted home directory, but the protocol (afp,
nfs, cifs, etc.), server and share/directory. Furthermore, most Mac
Admins will have a heart-attack if they see an auto-mounted
/home/$username instead of the usual /Users/$username.


Not sure what you mean. Do you mean having a way to map it by client
type? You may be able to do it by having client-type-based automount
maps.


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?


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.


The Apple schemas are included in Apple's GPL code-drops for OpenLDAP if
anyone is wondering about licensing. We don't need the full schemas
because we can map most stuff to our own schema and it works brilliantly.


It is probably best to stick with the Apple schema otherwise there
could be pain later if something changes, requiring additional
mapping.


I wouldn't encourage it for two reasons:
1) The Apple schema is designed to be remapped to any other schema.
That's the point of cn=config. That's what I did. It describes the
attribute mappings to internal data structures. I've identified a
minimal number of apple-schema items that have no direct mapping to
freeIPA datastructures and documented them in the two schema expansions
in the email.
2) Using the Apple schema without remapping would duplicate a most of
the data and would make account maintenance and LDAP Browsing more
difficult in the future. Since Apple is flexible about the schema, why
shouldn't we use that?

Good points. Remapping is better from our perspective too.

--
/ Alexander Bokovoy

--
Manage 

Re: [Freeipa-users] Apple OpenDirectory Integration

[Răzvan Corneliu C.R. VILT]

>> It is probably best to stick with the Apple schema otherwise there could be 
>> pain later if something changes, requiring additional mapping.
> 
> I wouldn't encourage it for two reasons:
> 1) The Apple schema is designed to be remapped to any other schema. That's 
> the point of cn=config. That's what I did. It describes the attribute 
> mappings to internal data structures. I've identified a minimal number of 
> apple-schema items that have no direct mapping to freeIPA datastructures and 
> documented them in the two schema expansions in the email.
> 2) Using the Apple schema without remapping would duplicate a most of the 
> data and would make account maintenance and LDAP Browsing more difficult in 
> the future. Since Apple is flexible about the schema, why shouldn't we use 
> that?

If you open up the ldif file from the first email and base64 decode the entries 
you will see clear configuration directives such as below. These mean that you 
don't need to stick with Apple's schema and neither does Apple (for forward and 
backward compatibility):

OD Policy:
==

Denied SASL Methods


DIGEST-MD5
CRAM-MD5

Configured Security Level

Advisory Client Caching


Binding Required


Man In The Middle


No ClearText Authentications


Packet Encryption


Packet Signing



Directory Binding


LDAP Servers:
=
Here you list the replicas, read-only or read-write. For registration a r/w 
replica will be used, preferably the primary master.

IPaddresses

172.16.23.138

PrimaryMaster
ipa.example.org
ReplicaName
Master
Replicas


Kerberos KRB5.conf:
===
Since you can register to multiple realms at one on a Mac, you need to modify 
(and not replace) the krb5.conf file so they are including the information as 
opposed to the file.
edu.mit.kerberos

domain_realm

.example.org
EXAMPLE.ORG
example.org
EXAMPLE.ORG

libdefaults

default_realm
EXAMPLE.ORG

realms

EXAMPLE.ORG

KADM_List

ipa.example.org
172.16.23.138  

KDC_List

ipa.example.org
172.16.23.138





OD Config snipplets:

Server information used for LDAP binding.

Delay Rebind Try in seconds
0
Enable Use

Map Search Base
cn=config,dc=example,dc=org
OpenClose Timeout in seconds
15
Port Number
389
SSL

Search Timeout in seconds
120
Server
172.16.23.138
Server Mappings

Template Name
FreeIPA Server
Template Search Base Suffix
dc=example,dc=org
Template Version
1.0
UI Name
Example.ORG

OD Config Attribute Type Maps snipplet:
===
Open Directory also includes them, but they map to different attributes.

Attribute Type Map


Native Map

fqdn

Standard Name
dsAttrTypeStandard:RecordName


Native Map

ipaUniqueId

Standard Name
dsAttrTypeStandard:GeneratedUID


Native Map

sambaSID

Standard Name
dsAttrTypeStandard:SMBSID


Native Map


Group Object Classes
OR
Object Classes


ipaHost
krbPrincipal
krbPrincipalAux
apple-user
ieee802Device


Search Base

Re: [Freeipa-users] Apple OpenDirectory Integration

[Răzvan Corneliu C.R. VILT]

> On 4 feb. 2016, at 12:16, Rob Crittenden  wrote:
> This is very cool and excellent work!

Thanks. I've done most of the R 1 year ago for a client that has a medium 
Mac-only network. Since a year passed, I wanted to share my results in order 
make sure that the information won't be lost or obsoleted. Furthermore, FreeIPA 
is a wonderful piece of software that is making the life of admins around the 
world easier and due to BYOD policies Macs should get more love.

> Currently the FreeIPA wiki points to 
> http://linsec.ca/Using_FreeIPA_for_User_Authentication#Mac_OS_X_10.7.2F10.8 
> for instructions on configuring MacOS. Are these sufficient to match what 
> you've accomplished?

Nope, what I've accomplished is different. I've managed to get OS X clients to 
register to the IPA server like it's an Open Directory Server. No command line 
interaction on the clients at all. No need for manual keytabs or manual file 
editing or PAM modules or Apple scripts. Just click join in the System 
Preferences -> Users Preferences Pane.

>> A 389 Directory Server plugin that generates altSecurityIdentities and
>> AuthAuthority values automatically for an objectClass=apple-account.
>> This would automatically present the following entries (user admin used
>> as an example):
>> --
>> altSecurityIdentitites: Kerberos:ad...@example.org 
>> AuthAuthority: ;Kerberosv5;;ad...@example.org
>> ;EXAMPLE.ORG ;
>> --
>> 
> 
> Is this generally static data set once during user-creation? If so them the 
> framework can manage it w/o requiring a 389-ds plugin which means it would be 
> far easier to do.

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

> 
>> A better way to specify homes for users. Not everyone uses automount and
>> automount maps (although OS X can use them). We need to be able to
>> specify not the assumably mounted home directory, but the protocol (afp,
>> nfs, cifs, etc.), server and share/directory. Furthermore, most Mac
>> Admins will have a heart-attack if they see an auto-mounted
>> /home/$username instead of the usual /Users/$username.
> 
> Not sure what you mean. Do you mean having a way to map it by client type? 
> You may be able to do it by having client-type-based automount maps.

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.


>> Is anyone from Red Hat willing to pick this up? It would be a nice
>> addition. If so, I am offering to do the testing and fine-tuning for all
>> post-Tiger releases. I can also share virtual machines for server and
>> client configuration.
> 
> 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.

>> The Apple schemas are included in Apple's GPL code-drops for OpenLDAP if
>> anyone is wondering about licensing. We don't need the full schemas
>> because we can map most stuff to our own schema and it works brilliantly.
> 
> It is probably best to stick with the Apple schema otherwise there could be 
> pain later if something changes, requiring additional mapping.

I wouldn't encourage it for two reasons:
1) The Apple schema is designed to be remapped to any other schema. That's the 
point of cn=config. That's what I did. It describes the attribute mappings to 
internal data structures. I've identified a minimal number of apple-schema 
items that have no direct mapping to freeIPA datastructures and documented them 
in the two schema expansions in the email.
2) Using the Apple schema without remapping would duplicate a most of the data 
and would make account maintenance and LDAP Browsing more difficult in the 
future. Since Apple is flexible about the schema, why shouldn't we use that?


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

Re: [Freeipa-users] Apple OpenDirectory Integration

[Răzvan Corneliu C.R. VILT]

>> 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:" + "CN=" + $issuerRDN + "CN=" + $subject. Such as:
"X509:CN=Apple Root CA,OU=Apple Certification Authority,O=Apple 
Inc.,C=USCN=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/TP4917-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/TP4917-CH3-68270

Apple Password Server Authentication:
-
;ApplePasswordServer;0xfc001e291a400254ba69508,1024 65537 
1073536022652669667510124737971525265977003458292838259662475941942339637701783031842665637489899899968013535474647377427038990743911664412758698759306606987798849786426049586039725915353359580583450027978985802381494661566820916379229460639580871881869418576860074704243214464804408968770344748232621
 r...@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/TP4917-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:
Documented on:
https://developer.apple.com/library/mac/documentation/Networking/Conceptual/Open_Directory/openDirectoryConcepts/openDirectoryConcepts.html#//apple_ref/doc/uid/TP4917-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/TP4917-CH3-68528

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

iCloud Authentication (obvious)
---
;AppleID;razvan.v...@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 

Re: [Freeipa-users] Apple OpenDirectory Integration

[Mauricio Tavares]

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  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:" + "CN=" + $issuerRDN + "CN=" + $subject. Such as:
>> "X509:CN=Apple Root CA,OU=Apple Certification Authority,O=Apple
>> Inc.,C=USCN=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/TP4917-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/TP4917-CH3-68270
>>
>> Apple Password Server Authentication:
>> -
>> ;ApplePasswordServer;0xfc001e291a400254ba69508,1024 65537
>> 1073536022652669667510124737971525265977003458292838259662475941942339637701783031842665637489899899968013535474647377427038990743911664412758698759306606987798849786426049586039725915353359580583450027978985802381494661566820916379229460639580871881869418576860074704243214464804408968770344748232621
>> r...@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/TP4917-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:
>> Documented on:
>>
>> https://developer.apple.com/library/mac/documentation/Networking/Conceptual/Open_Directory/openDirectoryConcepts/openDirectoryConcepts.html#//apple_ref/doc/uid/TP4917-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/TP4917-CH3-68528
>>
>> Netlogon Authentication (used by Active Directory)
>> --
>> ;Netlogon;razvan.vilt;MYDOMAIN
>>
>> iCloud Authentication (obvious)
>> ---
>> ;AppleID;razvan.v...@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.