We help IT Professionals succeed at work.

Fix Kerberos Authentication error.

AIGS
AIGS asked
on
I have 3 Servers all running Windows Server 2019 Standard, Domain server, Web Server and a Data Storage server.
Whilst copying data from a shared folder on Data server to a shared folder on Web Server - both servers froze during the process and had to be rebooted. After this, I get periodic issues with one of the servers not connecting to the Domain/Network. When I use Domain server to look at other servers I get the error - "Kerberos Authentication error" and I can't login remotely (which I often do).
The only way I have managed to fix the issue (temporarily I expect) is to disable the NIC and enable the other NIC, rebooot, the re-enable the original NIC. All 3 Servers have 2 NICs.
Any guidence appreciated.
Comment
Watch Question

View Solution Only

Michael Pfister
CERTIFIED EXPERT

Commented:
Just to make sure: the 2nd NIC is normally disabled?

Model of the NIC?
Model of the server?

NIC drivers up to date?
nociSoftware Engineer
CERTIFIED EXPERT
Distinguished Expert 2019

Commented:
Are the clocks running in sync?

You need to use the DC as the time source for ALL OTHER systems within that domain.
and time needs to be coordinated.
AIGSNetwork Administrator

Author

Commented:
Thanks to all for input.
All Servers are Supermicro brand.
SVR1 = Intel 82574L Gbit NIC, NIC 2 enabled, NIC 1disabled
SVR2 = Intel 1350 Gbit NIC, NIC 1 enabled, NIC 2 disabled
SVR3 = Intel Ethernet X722 for 1GbE, NIC 2 enabled, NIC 1 disabled
All NIC drivers are up to date as at today.
ALL TCPIP addresses are set correctly and are all static, all pointing to same DNS and Gateway.
SVR3 is the only Domain server (AD, DNS, Grp Policy, DHCP etc), is also time synced to outside source with all other Servers and workstations synched to this Domain server. (SVR1 was originally not synched - now fixed).
When I changed the two SVRS using NIC 2 to use NIC 1 (made sure there were no dup IPs) the kerneros error raised its head time and time again, so I put them back they way they were and all is ok (no kerberos error).
Observations:
In the DNS I notice I have two entries as follows:
SVR3 - why do I have this one?
SVR3.MYNET.Local - this is the correct Domain
Both of the above have the same Forward Lookup Zones and records, No Reverse Lookup Zones and No Conditional Forwarders.
Both of the above have SVR2 as the SERVER FQDN - this does not make sense, as SVR2 is not a Domain Server, should it point back to SVR3?
If I try to edit it - it resolves the IP ok, but when I go to SAVE the edit it says the IP address is not valid, so nothing is changed.
I hope this helps.
AIGSNetwork Administrator

Author

Commented:
The problem continues.
Whenever I need to reboot SVR3 - the kerberos error raises its head.
If I ensure both NICs are disabled, reboot, and then enable NIC2 (ensuring correct Static IPs set), reboot, everything ok. No kerberos issue.
Any other suggestions?
Michael Pfister
CERTIFIED EXPERT

Commented:
> In the DNS I notice I have two entries as follows:
> SVR3 - why do I have this one?
> SVR3.MYNET.Local - this is the correct Domain

The base DNS entry for your SVR3 (and all others) should be

Forward Lookupzones -> your domain fqdn (MYNET.Local) -> SRV3 (just name) -> host (A) -> ip address

So you shouldn't have an entry "SVR3.MYNET.Local"

Of course a domain controller/an active directory has a bunch of additional entries in sub-domains like _sites, _tcp, etc.

I'd also run

dcdiag /e /v /test:dns > dcdiag.txt

on SRV3 and have a look at the output
AIGSNetwork Administrator

Author

Commented:
The dcdiag.txt file references fqdn pointing to SVR02, when it should point to SVR03 (shouldn't it?).
I must admit there are references that I am not familiar with in this file.
As I mentione prev, I have tried to change the IP of FQDN, whilst it lets me edit it (and resolves it), it won't let me save the new IP.
I feel like I am going around in circles.
I agree that I shouldn't have "SVR3.MYNET.Local".
So what can I do?
Should I take the SVR01 & SVR 02 of the Domain, then remove SVR03 as DNS/Domain controller and reset them back up again?
I expect I will loose all DNS info once this is done (including AD as well)?
What is the best approach to fixing this issue?
Michael Pfister
CERTIFIED EXPERT

Commented:
If you remove SVR03 as DNS/Domain controller you will remove your active directory (I take from your original post this is the only DC).

dcdiag /e /v /test:dns > dcdiag_dns.txt
dcdiag /e /v > dcdiag.txt

Open in new window

Please attach the 2 output files here (replace domain name/server names if required).
AIGSNetwork Administrator

Author

Commented:
I have attached the two dcdiag TXT files as requested.
Yes, SVR03 is the only DC.
dcdiag.txt
dcdiag_dns.txt
Michael Pfister
CERTIFIED EXPERT

Commented: 
             TEST: Forwarders/Root hints (Forw)
                  Recursion is enabled
                  Forwarders Information: 
                     192.168.1.1 (SVR02.MYNET.local.) [Invalid (unreachable)] 
                     Error: All forwarders in the forwarder list are invalid.

Open in new window

This is not a problem. Just remove SRV02 from the Forwarder tab in the DNS mmc (Properties of SRV03). Don't let point it to SRV03 (loop!!!)

Is "SVR03.MYNET.Local" a static entry in the root of your Forwarding lookup zone? Note its settings, then delete it...
As I said, the only entry there is a host (A) entry for SRV03 pointing to its IP.
Michael Pfister
CERTIFIED EXPERT

Commented:
The dcdiag outputs don't show any other problem
AIGSNetwork Administrator

Author

Commented:
I have removed SVR02 from the from the Forwarder tab as requested.
"SVR03.MYNET.local" is not a static entry in the root of the Forwarding Lookup zone. The only entry I have  there is a host (A) entry for SRV03 pointing to its IP.
What I still have is shown in images attached. SVR03.MYNET.Local seems to be a copy of SVR03.
If I change an entry in SVR03, I can see that change reflected in SVR03.MYNET.local.
Can I delete SVR03.MYNET.local?
Also included 2 new dcdiag test files.
DNS.jpg
dcdiag_dns2.txt
dcdiag2.txt
Michael Pfister
CERTIFIED EXPERT

Commented:
Missed this one:

              TEST: Delegations (Del)
                  Delegation information for the zone: AIGSNET.local.
                     Delegated domain name: _msdcs.AIGSNET.local.
                        Warning: Delegation of DNS server aigsserver.aigsnet.local. is broken on IP:192.168.1.1
                        Error: DNS server: aigsserver.aigsnet.local.

                        IP:192.168.1.1 [Broken delegation]

Open in new window


Hard to say why this delegation has been created... at least 192.168.1.1 doesn't know about it. Maybe a previous trust? If its no longer used delete the zone.

Thanks for the screen... the explanation is simple:
When you connect to a DNS server via the DNS snap-in, the server is exactly shown as you entered it.
If you type SRV03 you'll see SRV03, if you type the fqdn, you'll see SRV03.MYNET.LOCAL.
Just right-click one of the entries and choose "Delete". It will remove it from the server list (and not delete the entire DNS server).
Michael Pfister
CERTIFIED EXPERT

Commented:
All this still doesn't explain you original problem.

Have to come back to this:
> Both of the above have SVR2 as the SERVER FQDN - this does not make sense, as SVR2 is not a Domain Server, should it point back to SVR3?

Where do you see this setting? Maybe another screenshot helps... :-)
AIGSNetwork Administrator

Author

Commented:
The attached is a screen dump of what was set.
If I try and set the FQDN to SVR03 - It does not let me save it and state the IP address is invalid.
I have since deleted the FQDN as you suggested in prev comments.
DNS3.jpg
CERTIFIED EXPERT
Commented:
Yes thats correct now. SRV02 is no longer a DNS as you said.
SRV03 should now no longer use it.

Lets see if the problem appears again
AIGSNetwork Administrator

Author

Commented:
Michael
Thanks for your assistance, I think it is finally fixed.
I found Host (A) records pointing to SVR02 in MYNET.local:
_msdcs
DomainDnsZone
ForrestDnsZone
I have removed them and ensured that thery point to SVR03.
After running the two diag tests again and they are all clear with all test passed.