|
Posted by =?Utf-8?B?amVycnlkeQ==?= on October 5, 2006, 3:28 am
If you were Registered and logged in, you could reply and use other advanced thread options
I ran
netdiag /test:dns
dnslint /ad 192.168.1.250 /s 192.168.1.250.
The output is below. It appears that all tests passed without problems.
==== netdiag output ===
Netcard queries test . . . . . . . : Passed
Per interface results:
Adapter : Local Area Connection
Netcard queries test . . . : Passed
Global results:
Domain membership test . . . . . . : Passed
NetBT transports test. . . . . . . : Passed
List of NetBt transports currently configured:
NetBT_Tcpip_
1 NetBt transport currently configured.
DNS test . . . . . . . . . . . . . : Passed
PASS - All the DNS entries for DC are registered on DNS server
'192.168.1.25
0'.
===== start of dnslint output ====
The following 1 DNS servers were checked for records related to AD forest
replication:
DNS server: moses.spls.local
IP Address: 192.168.1.250
UDP port 53 responding to queries: YES
TCP port 53 responding to queries: Not tested
Answering authoritatively for domain: YES
SOA record data from server:
Authoritative name server: moses.spls.local
Hostmaster: hostmaster.spls.local
Zone serial number: 44
Zone expires in: 1.00 day(s)
Refresh period: 900 seconds
Retry delay: 600 seconds
Default (minimum) TTL: 14400 seconds
Additional authoritative (NS) records from server:
moses.spls.local 192.168.1.250
Alias (CNAME) and glue (A) records for forest GUIDs from server:
CNAME: 0640ffa0-1808-4b3d-95f4-3d06c1e5ad50._msdcs.spls.local
Alias: moses.spls.local
Glue: 192.168.1.250
Total number of CNAME records found on this server: 1
Total number of CNAME records missing on this server: 0
Total number of glue (A) records this server could not find: 0
========= end of output
"Roger Abell [MVP]" wrote:
> >I login locally to our domain server as user Administrator. When I use
> > windows explorer to go to \domain.local\shares, I get
> > \domain.local\Shares
> > is not accessible ... Logon failure: the user has not been granted the
> > requested logon type at this computer.
> >
> > But when I go use \server.domain.local\Shares, it works without any
> > problems. It's not a DNS problem because I can ping both domain.local and
> > server.domain.local. nslookup resolves both names to the same local
> > server.
> > It shouldn't be a security problem either because the shared folder has
> > the
> > following set:
> > Sharing Tab -> Permissions -> Everyone has Full Control
> > Security Tab -> Everyone has Full Control
> >
> > Why should domain.local and server.domain.local be different, since both
> > resolves to the same IP address?
> >
> > Any help appreciated. Thanks!
> >
> > -Jerry
>
> Insufficient information.
> In an AD domain with all default DNS records in existence, then
> domain.local will resolve to the IPs of all DCs of that domain, but
> server.domain.local will resolve to that one server's IP (not included
> in prior unless that server is a DC).
>
> That one can ping, or locate A records using nslookup is not how
> one determines whether there is completeness, or lack of, in the
> use of DNS to support a specific AD. One should use netdiag
> (perhaps even with the /test:dns switch if fully complete testing is
> wanted) or dnslint. These tools include tests for the all important
> SRV records and CNAME glue.
>
> Note however that intraforest location is not just done with DNS,
> but also with LDAP (not to mention downlevel NetBT methods
> if needed). In particular, LDAP may be used to locate SPN info
> needed to support Kerberos in accessing resources.
>
> You should run both netdiag and dcdiag, when logged into the
> DC and also when logged into the client from which you are
> having this problem.
>
> What I suspect MAY be operative here is that in one case Kerberos
> is working just fine, but in the other it is not and your access attempt
> is reverting to NTLM but there is a mismatch in the network signing
> requirements needed for NTLM to be successful.
>
> Roger
>
>
>
| 
XML site map