You're not being ignored. I just don't have any good answers :-(.
I know a fair amount about AD and how the CIFS service uses it, but
unfortunately I'm not an expert on NIS or setting Solaris up as an LDAP client.
However, I'll try to answer a couple of your questions:
Kyle McDonald wrote:
Background:
I need to setup several ZFS file servers to mainly share NFS to Solaris
and Linux Clients, but there is also a need for CIFS access to many of
the files.
So far so good. This is one of our primary target configurations.
The IT group here maintains an AD server for either xyz.com or
CORP.xyz.com ( I'm not sure - All the machines and users belong to the
CORP windows domain.) The AD servers they use have the newer bundled
versions of 'Services For Unix' installed, and the AD schema has been
expanded to include the traditional UNIX information:
If it's the bundled one, I believe it's called Identity Management for UNIX
(IDMU). Direct support for some of the IDMU features is coming in, I
believe, build 124. That will eliminate the need for rules per se, and
will use IDMU data to directly map from Windows identities to/from UIDs and
GIDs.
IT and I have successfully delegated 2 DNS domains to other non-AD DNS
servers in the company. I manage one of these new DNS subdomains
'eng.xyz.com'. I have BIND on Solaris serving this domain nicely.
I have in the past setup automated merging of the password and group
info from the 'corp' NIS domain into my own 'eng' NIS domain. I created
my own NIS domain in order to have local control over the Automount
maps, and a few other local grown NIS maps that are used by other
scripts and tools I've written.
This is where we reach the edges of my competence. I don't know how to set
up a semi-autonomous domain like you're trying to do, where some of the
data is managed centrally but you have your own local set of data too.
So given that, I see basically 2 choices, one of which I'm not sure will
work, but might be easier if it will. The second of which is
probably the smarter move, but will need more research, learning, and
convincing of others that it's a good idea:
Idea 1 - Stick with NIS.
* Linux and Solaris NFS clients all continue to bind to the 'eng' NIS
domain, which is already kept in sync with the CORP one.
* NFS/CIFS Servers get configured how?
- WildCard rule based mapping locally on each server:
Should work since the AD->NIS syncing should keep the
usernames in sync?
Should work.
- Directory based mapping:
Should I have the server use AD(LDAP?) name service locally?
or leave the nsswitch.conf set for NIS?
Doesn't matter. (Note that if you set it for LDAP you're falling into Idea
2 below.) The idmap mapping mechanisms do not really care where the UNIX
user/group information is coming from.
Idea 2 - Switch to LDAP.
* Replace eng NIS servers with local LDAP servers. Populate my
automount and other LDAP "tables" locally, setup refferals (I think
that's what they're called) so that Password and Group lookup 'fall
through' to the AD LDAP servers.
* Configure all Linux and Solaris NFS clients to use LDAP and direct
them to the new Solaris based LDAP servers.
* NFS/CIFS Servers get configured how?
- WildCard based rule mapping?
- Directory based mapping?
That does seem to me the "modern" way to do it, but I'm not very familiar
with using LDAP as a UNIX name service and not at all familiar with trying
to do this kind of semi-autonomous configuration.
I suspect that wild card rule mapping is the right answer with builds prior
to 124, and that the direct IDMU support is more appropriate to builds 124
and later.
Questions::
1) I think I'm still not clear on the difference between having a
Solaris server "Join" an AD domain, and just setting it to use the LDAP
name service from an LDAP server that happens to be running Windows/AD?
At the moment at least, "join" affects only CIFS interactions. It has no
impact on traditional UNIX operations - login, NFS, et cetera.
On the other hand, using LDAP (even from AD) as your UNIX name service
doesn't directly affect CIFS operations.
2) Given that the directory appears to have the mapping info in place,
I'm inclined to use directory based mapping. If I do,
"joining" the domain is only required for the NFS/CIFS servers correct?
I believe, but I am not sure of the details, that if your CIFS clients join
the domain they will not have to prompt you for a password when they
connect to the file server.
3) Does Rule based mapping still require joining the AD Domain?
When you're not joined to an AD domain, the only kind of user that exists
is a "local" UNIX user (which includes users from NIS and LDAP, except that
setting them up for CIFS access is unsupported), and so mapping isn't
really directly applicable.
4) Can a host in the 'eng' DNS subdomain join the 'CORP' AD domain?
(Given how the resolv.conf works I don't think so.)
I'm not sure. It does seem like shaky ground, and likely to get shakier if
we ever do more integration between the CIFS and UNIX sides of the house.
5) How would using 'Work Group' mode instead of joing the domain change
things?
Not sure.
6) Any other tips and/or suggestions?
Afraid not.
_______________________________________________
cifs-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
