[OpenIndiana-discuss] ActiveDirectory UID mapping (netatalk)

[Günther Alka]

On 12.08.2012 19:42, Frank Lahm wrote:
>>> *sigh*
>>> I was just giving a pointer to some doc I have spent considerable time
>>> and effort to provide a consolidated ressource for anybody facing this
>>> problem.
>>> You may notice that using idmu is one the things explained in great length.
>>> Feel free to add links and add enhancements.
>>> -f
>>>
>> IDMU seems not really helpful.
>> If one wants to provide a transparent multiprotokoll server (CIFS + AFP + AD +
>> ACL support)
>> on OpenIndiana, it must be fully integrated into the builtin CIFS mechanism
>> without the need to add
>> anything to AD - with CIFS you need no IDMU due to ephemeral mappings.
>>
>> Netatalk needs to use the (by the CIFS service) already created idmappings or it
>> must create
>> a similar ephemeral mapping for new users (transparent for the next CIFS user).
> Netatalk uses standard UNIX APIs for user and group identication,
> authentication and authorization. That boils down to PAM and nsswitch.
> So the question is not how to adapt Netatalk to undocumented and
> private APIs, but how to configure PAM or in this case
> name-service-switch.
>
>> How can that be done?
> You may try substituting idmap with winbind. idmap ephemeral mappings
> are useless for for every UNIX process beside CIFS and NFS servers
> because
>
> "To prevent aliasing problems, all file systems, archive and backup
> formats, and protocols must store SIDs or map all UIDs and GIDs in the
> 231 to 232 - 2 range to the nobody user and group."
>
> <http://docs.oracle.com/cd/E23824_01/html/821-1462/idmap-1m.html>
>
> -f

Maybee the point of view is the core of the problem.
You wrote ephemeral mappings are useless beside CIFS and NFS

I would say, OpenIndiana/ Solaris  (as a fileserver) is useless without 
its Windows compatible
Snap, ACL and CIFS features. These are the killer arguments to use OI/ 
Solaris widely - the most compatible
Windows-server on Unix.

All persons that I know that use OI/ Solaris in an Active Directory 
environment as a filer
do not want to care about the Unix base but use it because of the hassle 
free AD integration
- indeed they use it like a Windows filer without the need do modify any 
Unix specific settings on the
AD server (they may even get troubles with their admins when asking 
about modifying AD settings)

If AFP on OI/Solaris could not be integrated within the default CIFS 
mechanism then is not the best option
in nearly all Active Directory environments. AD + netatalk only (without 
CIFS and a different permission
mechanism) is  not the most wanted solution as well as the need to 
modify anything only because netatalk
is not able to cooperate with AD+CIFS.

Other options like winbind + SAMBA means to abandon the magic of 
OI/Solaris. Its then just another Unix server that
can be connected from Windows without the essential features that allows 
to replace real Windows servers with CIFS.

So indeed, I  am interested in AD /CIFS/ Windows compatibility of all 
fileservices - not Unix compatibility.
This is really a pity. With netatalk 2, it was a pain to share a dataset 
via CIFS and AFP because of the additional AFP files -
they are now invisible with netatalk3. No the view from both is quite 
the same. You can even authenticate from AD
but the successfully authenticated user it not used for file-access.

Most of the problems to build  a Windows compatible and fully integrated 
multiprotokollserver  (like old Windows2000 servers)
are solved. Whats missing is the mini-jump to the Windows SID/ idmap 
compatibility.

So I hope for a way to do it more easily in future.


Gea
napp-it.org