Re: Logon failure: the user has not been granted the requested logon t

Giganews Newsgroups
Subject: Re: Logon failure: the user has not been granted the requested logon t
Posted by:  Roger Abell [MVP] (mvpNoSp…@asu.edu)
Date: Tue, 3 Oct 2006

"jerrydy" <jerry…@discussions.microsoft.com> wrote in message
news:F205205B-706F-42FA-91F1-4CF5CC0B29…@microsoft.com...
>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

Replies

In response to

Logon failure: the user has not been granted the requested logon t posted by jerrydy on Mon, 2 Oct 2006