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 >> [email protected] >> http://openindiana.org/mailman/listinfo/openindiana-discuss > > > -- > > > +============================================================+ > | | > | Климов Евгений, Jim Klimov | > | технический директор CTO | > | ЗАО "ЦОС и ВТ" JSC COS&HT | > | | > | +7-903-7705859 (cellular) mailto:[email protected] | > | CC:[email protected],[email protected] | > +============================================================+ > | () ascii ribbon campaign - against html mail | > | /\ - against microsoft attachments | > +============================================================+ > > -- _______________________________________________ OpenIndiana-discuss mailing list [email protected] http://openindiana.org/mailman/listinfo/openindiana-discuss
