Hi Jordan,
Jordan Brown wrote:
Sorry, I didn't connect the dots between this message and your
previous one, and hadn't realized you were the guy with the "split"
environment.
I appologize also. I didn't see your reply to my original post due to a
mail filter. Oops. After I read your response today, I searched more on
the website and I saw you had replied there too. I was actually typing
in a reply to that when I saw this message. I think I'll try to put
everything in here, so we can end the split thread.
This new thread was posted after reading more through the
documentation, and I thought I might ask more pointed questions.
Kyle McDonald wrote:
Jordan Brown wrote:
If you can guarantee that for all users and groups the UNIX and AD
names are the same (or that there is no corresponding user/group on
the other side), you can configure Directory based name mapping to
use one of the standard AD attributes, probably sAMAccountName.
sAMAccountName is what the user interface calls the "Pre-Windows
2000 Logon Name".
That's the rub. At the moment the IT run AD database (Win2003R2 with
the integrates SFU schema) has them all the same, but their advice is
not to assume they always will though.
If it were me, I'd make it a rule that the names have to be the same
in the two environments. It'll make life much easier for everybody,
and it sounds like you don't have a legacy of misalignment that you
must live with.
I know. And I think that's the plan, but I don't think they want to box
themselves in. So given that they're willing to always put both
usernames (and all the UNIX info) into the AD directory, I think that's
the next best thing.
I'm just not sure how where I need to configure the mess of
domain/realm names.
DNS for xyz.COM and CORP.xyz.COM is run by the IT dept, and served by
the W2k3R2 AD servers.
From there they have delegated DNS responsibilities to me for
eng.xyz.COM, and lab.xyz.COM.
All the Windows client machines are in the CORP.xyz.Domain and all
the users login as CORP\username.
So is the right AD domain CORP.xyx.COM? or xyz.COM?
Ditto for the Kerberos realm?
Sorry, I didn't connect the dots between this message and your
previous one, and hadn't realized you were the guy with the "split"
environment.
I am not completely sure, but I think you want to do something along
these lines:
- Add eng.xyz.com and lab.xyz.com as new domains in the same forest as
corp.xyz.com. (You might make them all subdomains of xyz.com, but I
don't think it's required.)
- Have your Solaris system join whatever domain you want it to be in,
probably either eng.xyz.com or lab.xyz.com. This should match where
the system appears in DNS.
- Continue to copy NIS maps from corp.xyz.com and publish them
(updated as required) in your local NIS domain.
Net, you'll be autonomous for NIS purposes - you can do whatever you
like to the maps - but for AD purposes you will be close personal
friends with corp.xyz.com and CORP\username users will be able to log
in through CIFS.
That sounds good.
So Do I create these eng.xyz.com and lab.xyz.com sub domains on Solaris
some how? Or do I ask IT to do that on the AD servers?
Does making these new AD domains also make new Kerberos realms?
Can I choose to make the Kerberos Realms myself? Can I host the
ENG.XYZ.COM realm on Solaris? and just ask the IT dept to trust it?
The DNS I run has all my SOlaris and linux machines in 'lab' and
'eng' DNS subdomains, so naturally I have those domains listed first
in the /etc/resolv.conf config. I read something about needing to put
the AD first in the resolv.conf? is that true?
That will make local DNS lookups pretty inefficient.
Do you mean the domain search list, or the servers?
I mean the search directive.
The OS CIFS Administration Guide, p33 states that the AD domain must be
the only value of the 'domain' directive, or the first value of the
'search' directive in the /etc/resolv.conf.
I don't think the search list matters here. Put whatever in your
search list will make life easier for you.
In a sense, the server list shouldn't matter. All servers should be
able to resolve all requests, either because they know the answer or
because they can figure out who to ask.
What do you mean by a 'server list'??
If your servers are *not* all capable of answering all questions - for
instance, for some purposes my test systems live in a DNS domain that
our IT organization doesn't know about, and so queries about them need
to go to my DNS servers and not the IT DNS servers - then you need to
ensure that your resolv.conf lists *only* the servers that know about
your domains. It would be bad if you had some servers in the list
that could answer a particular question and some that could not; you
could see intermittent failures depending on which servers are up at
any given moment.
Oh, you mean the 'nameserver' directive in the resolv.conf?
Yes, all these domains are fully delegated both forward and reverse.
Unless the other DNS servers are on the other side of the world, I
wouldn't really worry about efficiency. DNS queries are pretty fast
and light. Even if the servers *are* on the other side of the world, I
wouldn't be very concerned; Solaris caches name service lookups and so
you shouldn't see much cost anyway.
I know. I'd just rather try the most likely name first. Also I think the
first value of 'search' and 'domain' can have an effect on other things.
Now from the other thread ( I think I got rid of redundancies with
above, but if I missed any just ignore them:)
>
> 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 is the one bundled in Win2003R2.
The sun Docs suggest that the LDAP UNIX username and groupname fileds
are normally are named 'unixUserName' and 'unixGroupName', like I see in
this AD for 'unixHomeDirectory'
However MS (or maybe my IT Dept?) has decided to name the fields 'uid'
and 'gid' (which in unix are normally numbers) and put the uid and gid
numbers in uidNumber and gidNumber.
Does that sound right?
So am I correct to think that I need to enter 'uid' and 'gid' into the
SMF properties to instruct idmap where to find the unix equivalents of
the windows usernames?
How does it know which field has the Windows username? in my LDAP dump
it was 'samaccountname'. Do i need o put that in the SMF properties also?
>
> 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.
>
For NIS I have no problems there. I didn't do it myself, but I remember
being on project teams at Sun where we did similiar things (our LDAP
defined groups of users for webservers to authenticate against, but the
passwords were 'reffered' on to ITops's LDAP servers for password
verification.)
> > Idea 2 - Switch to LDAP.
>
> 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.
That's OK. I think straight LDAP can do it. (It's kind of like how NIS+
let you link a parent domain's maps into a child domain.) It remains to
be seen if Windows does something to make it not work though.
Though through more reading, and your answers in the other thread, I
think I need to consider Kerberos more.
I'm not sure how I would handle Kerberos in Idea 1 (Stick with NIS.,)
but it seems like if I go through the work to add a LDAP sub-domain (to
the DNS subdomain I have) I probably should also setup a Kerberos
(sub-)realm?
That pretty well defines where I ultimately want to end up. But it also
looks like it won't be something I'll be able to do overnight.
So the question now, is which pieces depend on which others, and/or
which will need to be totally re-done later, so I can decide what to do
now vs. later??
>
> 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.
>
Ok. I'll definitely look more into build 124.
For now maybe I'll figure out what I need to do to get Kerberos setup
enough to get this one server joined to the domain, and it's shares
working, and then once I have 124 in my hands, I'll look into setting up
the rest.
>
> At the moment at least, "join" affects only CIFS
> interactions. It has no impact on traditional UNIX
> operations - login, NFS, et cetera.
>
OK. Good to know.
> On the other hand, using LDAP (even from AD) as your
> UNIX name service doesn't directly affect CIFS operations.
>
Also good to know.
So can a solaris machine even tell if it's LDAP server is really also an
LDAP server?
>
> 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.
Ok. That shouldn't normally be a problem, since most (all?) of the CIFS
clients should be Windows desktops or servers and members of the domain
already.
>
> > 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.
>
So when not joined to the domain, you can only map users from the
/etc/passwd file?
> > 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.
>
Why?
What exactly is planned for this integration?
I imagine something that can make Solaris machines look like nearly full
fledged windows clients?
Does it also include allowing Solaris Servers to act as AD slaves or
masters? or serve AD sub-domains?
-Kyle
_______________________________________________
cifs-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
