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