[OpenIndiana-discuss] ActiveDirectory UID mapping (netatalk)

[alka]

If CIFS can do it without this complexity, it must give an easier way - 
and maybee the problem is only the Oracle/ SUN documentation

When I understand the mechanism of CIFS and AD correctly, see
www.oug.org/files/presentations/cifs-losug.pdf

-  ZFS really stores the AD Windows SID as a Filesystem Unique ID used for CIFS
-  adds an entry in the idmap database for a persistent mapping 
of username, SID and a mapped  UID/GID

(this is not a regular ephemeral/ temporary mapping, but all the Docs about are not clear enough) 

so I think it is needed  to:
- use the same UID/GID for an AD user on netatalk like the one in the idmap database
- use/ write the SID when creating files like CIFS

If the user is new (not i the idmap database):
- add an entry

The problem that must be solved:
a File created from CIFS must have the same owner SID/ ACL/ UID/ GID
like those created with netatalk. (interoperabiity)



Am 13.08.2012 um 00:51 schrieb Jim Klimov:

> I might suggest an alternative solution, which may be an overkill for
> a single fileserver, but is rather widely employed in heterogenous
> shops: fire up a naming service (such as LDAP), and the fileserver
> would be its client. idmap mappings can be set up to map Windows
> users not to ephemeral IDs, but to statically defined individual
> POSIX UIDs from this LDAP service which can be used in ALCs, file
> ownerships, etc.
> 
> As you manage this LDAP server, you can mangle its schema however
> you like - such as adding the POSIX fields (perhaps implementing
> UID as an auto-incrementing counter). The trick would be to get
> the AD LDAP data into it, but if the windows admins would yield
> into making a proxy user (a windows domain user account which can
> read some or all fields from other accounts), you can set up lazy
> (on-demand) or active replication of data from AD into your LDAP
> with some scripts or perhaps with the chosen the LDAP server (or
> LDAP proxy server) built-in functionality. Quite likely, scripted
> regular pulls of updates can suffice...
> 
> Hashed passwords are also tricky (useless to non-Windows nodes),
> and if your Windows admins don't want to change their AD schemas,
> they are even less likely to roll out something like Sun's IdSyncWin
> replication services, or an IDM solution. You can however use the
> opensourced OpenDJ server, in 2.5 branch they planned to add a
> module for pass-thru authentication, so that "OpenDJ" users
> can in fact validate their entered passwords and ultimately
> authenticate to an MSAD server.
> 
> HTH,
> //Jim Klimov
> 
> 2012-08-13 0:57, 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
>> 
>> _______________________________________________
>> OpenIndiana-discuss mailing list
>> OpenIndiana-discuss at openindiana.org
>> http://openindiana.org/mailman/listinfo/openindiana-discuss
> 
> 
> -- 
> 
> 
> +============================================================+
> |                                                            |
> | Климов Евгений,                                 Jim Klimov |
> | технический директор                                   CTO |
> | ЗАО "ЦОС и ВТ"                                  JSC COS&HT |
> |                                                            |
> | +7-903-7705859 (cellular)          mailto:jimklimov at cos.ru |
> |                        CC:admin at cos.ru,jimklimov at gmail.com |
> +============================================================+
> | ()  ascii ribbon campaign - against html mail              |
> | /\                        - against microsoft attachments  |
> +============================================================+
> 
> 

--