Re: Logon failure: the user has not been granted the requested log
- From: jerrydy <jerrydy@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 5 Oct 2006 00:51:02 -0700
dcdiag gave me the following error:
Starting test: NetLogons
[MOSES] An net use or LsaPolicy operation failed with error
-2147483622
, Win32 Error -2147483622.
I have file and printer sharing enabled, I've enabled NetBIOS over TCP/IP,
and the Windows Firewall is not running.
Any help on how to fix this? Thanks!
-Jerry
"Roger Abell [MVP]" wrote:
"jerrydy" <jerrydy@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message.
news:F205205B-706F-42FA-91F1-4CF5CC0B2956@xxxxxxxxxxxxxxxx
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
- References:
- Re: Logon failure: the user has not been granted the requested logon t
- From: Roger Abell [MVP]
- Re: Logon failure: the user has not been granted the requested logon t
- Prev by Date: Re: Logon failure: the user has not been granted the requested log
- Next by Date: Re: Advise to password policy
- Previous by thread: Re: Logon failure: the user has not been granted the requested log
- Next by thread: Re: Attacks prompt third parties to fix flaw
- Index(es):
Relevant Pages
|
|
