Frank Cusack wrote:
The topology is quite simple. There is a single domain controller,
in a single domain in a single forest. The domain is XYZ.COM but the
hostname of the domain controller is dc1.loc.XYZ.COM.
I'm pretty sure that will give kclient indigestion. I don't know about
smbadm join. It's a bug in kclient that it gets indigestion.
Crap. What is the recommended practice here? I will have a second AD
site but did not want a second domain. Should I just change the domain
name to be LOC.XYZ.COM, as unappealing as that is? I'd much rather do
that than expose my internal names or have to do a split DNS. The reason
I chose XYZ.COM as the domain name is I don't want machines at my
other site (loc2) to have a hostname in loc.xyz.com, but I do want
them to be in the same domain (I don't want more than 1 domain in
the forest). I've chosen site names that match the ".loc" part of the
fdqn, is there a way to convince Windows to assign names which include
the site as part of the name? I haven't defined subnets to go along
with sites, should that help? Should I just create AD subdomains that
match the dns subdomains?
I'm not sure whether you're talking about AD sites here, or just informally
talking about multiple locations. AD sites are orthogonal to domains, I
believe.
I think you're probably talking informally, that you want to use the third
component of the domain to represent location, while keeping all of the
systems in a single AD domain. I don't know whether that's possible.
I suspect that if you move the DC to dc1.XYZ.COM it will relieve the
indigestion. If convenient, it's worth trying. (I don't think that's the
_answer_, but it might be a workaround.) The nature of the bug is that
kclient (and maybe smbadm join too) assumes that the DC is directly under
the domain, not under a subdomain, superdomain, peer, or whatever.
(The nitty-gritty details of the bug that I noticed are that when kclient
discovers a DC by looking for an SRV record, it uses the domain suffix of
the server as the domain name, rather than using the domain suffix of the
name of the SRV record.)
I do have to note again, that when I join the domain with samba, using
the net command, the fqdn does get populated correctly, and inspection
of the secrets.tdb file seems to show a keytab with the correct fqdn.
If my guess is correct, that's simple to answer: Samba doesn't have the
bug :-)
I believe there are issues when the DC is not itself a member of the
domain. I know there are such issues with kclient, see 6899608.
I didn't know the DC had to be a member of the domain, or even could be.
It definitely can be. Whether it must be I don't know. From what I've
seen, it isn't a requirement but, again, Solaris has bugs if you don't do
it that way.
How do I do that?
It looks like the default is for the DC to be a member of its domain, but
I'd have to experiment a bit to be sure. The DC's DNS domain is controlled
the same way it is (I believe) for any Windows system: System Properties /
Computer Name / Change... / More... . Note that AD domain membership is
not, I think, necessarily tied to DNS domain membership, and that makes the
situation even more confusing.
_______________________________________________
cifs-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
