[OpenIndiana-discuss] ActiveDirectory UID mapping (netatalk)

[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  |
+============================================================+