Sunday, 27 April 2014

Is Kerberos Dependent on Reverse DNS Working?

I’m going to answer this question using a lab setup.

Part 1: The Lab Setup

Networks

10.0.0.0/16 used by Windows Servers
10.2.0.0/16 used by Windows Workstations
10.4.0.0/16 used by NetApp Clustered ONTAP Storage

Systems

ROUTER (Standalone in a workgroup)
O/S: Windows 2003 R2 SP1 Server
Roles: Routing and Remote Access, DHCP

Note: DHCP server Active Directory domain authorization has been overridden using the registry hack HKLM\SYSTEM\CurrentControlSet\Service\DHCP\Parameters and the REG_DWORD DisableRogueDetection = 0x01.

Image 1: Overriding DHCP server AD authorization requirements in Win. Server 2003
MSDMC01.lab.priv
O/S: Windows Server 2008 R2 SP1
Roles: Domain Controller, DNS
IP Address: 10.0.1.11
Forward DNS (ping MSDMC01.lab.priv): CONFIGURED (Automatically)

NASVM01.lab.priv
O/S: NetApp Clustered Data ONTAP 8.2.1 SVM
Roles: CIFS File Server
IP Address (Data LIF 1): 10.4.9.21
Forward DNS (ping NASVM01-DATA1.lab.priv): CONFIGURED (Manually)

MSW7W01.lab.priv
O/S: Windows 7
Roles: Workstation
IP Address: 10.2.1.101 (DHCP provisioned from ROUTER)
Forward DNS (ping MSW7W01.lab.priv): CONFIGURED (Automatically)

Note 1: Ensure the Windows Firewall is either turned off or ICMP echo is allowed to get ping response from Windows systems.
Note 2: Windows clients automatically ‘register this connection’s addresses in DNS’

Image 2: ‘Register this connection’s addresses in DNS’ (taken from MSW7W01)
DNS Reverse Lookup Zones

No DNS Reverse Lookup Zones have been configured!

Image 3: No DNS Reverse Lookup Zones
Note: When testing reverse DNS, you must do the ping -a not on the system that’s got that address. A localhost will always be able to ‘ping -a’ its own IP Address!

Reverse DNS ‘Ping -A’ Results

From MSW7W01.lab.priv:

C:\Users\labuser>ping -a 10.0.1.11

Pinging MSDMC01 [10.0.1.11] with 32 bytes of data:
Reply from 10.0.1.11: bytes=32

C:\Users\labuser>ping -a 10.4.9.21

Pinging NASVM01 [10.4.9.21] with 32 bytes of data:
Reply from 10.4.9.21: bytes=32

From MSDMC01.lab.priv:

C:\Users\Administrator>ping -a 10.2.1.101

Pinging MSW7W01 [10.2.1.101] with 32 bytes of data:
Reply from 10.2.1.101: bytes=32

We see that in the absence of DNS Reverse Lookup Zones being configured, a ping -a returns the NETBIOS name of the system.

Part 2: Testing

Testing without Kerberos

Firstly, we test access without Kerberos by accessing the CIFS file server and a share called ‘testshare’ from our Windows 7 workstation using the DNS name:

NASVM01-DATA1.lab.priv

Kerberos will not work since a Kerberos ticket is going to be requested for NASVM01-DATA1.lab.priv, and no machine account currently has that SPN (Service Principal Name) configured.

C:\Users\labuser>setspn -q HOST/NASVM01
Checking domain DC=lab,DC=priv
CN=NASVM01,OU=NA-CDOT,OU=~LAB-SYSTEMS,DC=lab,DC=priv
        HOST/nasvm01.lab.priv
        HOST/NASVM01

Existing SPN found!

C:\Users\labuser>setspn -q HOST/NASVM01-DATA1.lab.priv
Checking domain DC=lab,DC=priv

No such SPN found.

The following output shows successfully connecting to the testshare (and then deleting the connection):

C:\Users\labuser>net use Z: \\NASVM01-DATA1.lab.priv\testshare
The command completed successfully.

C:\Users\labuser>net use
Status       Local     Remote                    Network
-------------------------------------------------------------------------
             Z:        \\NASVM01-DATA1.lab.priv\testshare
                                                Microsoft Windows Network

C:\Users\labuser>net use Z: /delete
Z: was deleted successfully.

Re-Testing with NTLM Disabled (Restricted) on the Domain

We disable NTLM on our domain by editing the ‘Default Domain Controllers Policy’ as below:

Start -> Administrative Tools -> Group Policy Management
Default Domain Controllers Policy -> Edit
Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options
Network Security: Restrict NTLM: NTLM authentication in this domain
Define this policy setting
Deny all

Image 4: Restrict NTLM authentication in this domain - Deny all
Run gpupdate on the domain controller to ensure the GPO is applied:

C:\Users\Administrator>gpupdate
Updating Policy...

User Policy update has completed successfully.
Computer Policy update has completed successfully.

Test access to \\NASVM01-DATA1.lab.priv\testshare from our Windows 7 workstation (I’ve rebooted it and re-logged in before doing the test, which I do before every test), and it fails as we’d expect:

C:\Users\labuser>net use Z: \\NASVM01-DATA1.lab.priv\testshare
System error 59 has occurred.

An unexpected network error occurred.

From the DC, we add in the SPN for NASVM01-DATA1.lab.priv:

C:\Users\Administrator>setspn -a HOST/NASVM01-DATA1.lab.priv NASVM01

And the from the Windows 7 workstation (after reboot) test access to \\NASVM01-DATA1.lab.priv\testshare again, and it works:

C:\Users\labuser>net use Z: \\NASVM01-DATA1.lab.priv\testshare
The command completed successfully.

C:\Users\labuser>net use
Status       Local     Remote                    Network
-------------------------------------------------------------------------
             Z:        \\NASVM01-DATA1.lab.priv\testshare
                                                Microsoft Windows Network

These are the SPNs as seen from the workstation:

C:\Users\labuser>setspn -q HOST/NASVM01
Checking domain DC=lab,DC=priv
CN=NASVM01,OU=NA-CDOT,OU=~LAB-SYSTEMS,DC=lab,DC=priv
        HOST/NASVM01-DATA1.lab.priv
        HOST/nasvm01.lab.priv
        HOST/NASVM01

And at no time did we have Reverse DNS configured (we didn’t even have the Reverse DNS zones on our DNS server) as seen from the workstation ‘pinging -a’ to the CIFS server (just returns its NETBIOS name):

C:\Users\labuser>ping -a 10.4.9.21
Pinging NASVM01 [10.4.9.21] with 32 bytes of data:
Reply from 10.4.9.21: bytes=32

And from the domain controller to the workstation (again, just returns its NETBIOS name):

C:\Users\Administrator>ping -a 10.2.1.101
Pinging MSW7W01 [10.2.1.101] with 32 bytes of data:
Reply from 10.2.1.101: bytes=32

We’ve answered the question:

Kerberos - at least with Windows 2008 R2 SP1, Windows 7 SP1, and Clustered Data ONTAP 8.2.1 - is not dependent on Reverse DNS being configured!

Note: Being thorough, I powered off the workstation, then powered it up a few minutes later, and logged in with a different user to test, and it continues to work.

APPENDIX A: An Interesting Registry Option

I found in this article http://support.microsoft.com/kb/837361 the following:

Entry: ClientIpAddress
Type: REG_DWORD
Default Value: 0 (This setting is 0 because of Dynamic Host Configuration Protocol and network address translation issues.)
Possible values: 0 (false) or any non-zero value (true)

This value indicates whether a client IP address will be added in AS_REQ to force the Caddr field to contain IP addresses in all tickets.

Checking on my Windows 7 Workstation, and Windows 2008 R2 Domain Controller, this DWORD does not exist, so we’re using the default value of 0. Infact HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters is pretty empty.

Image 5: HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
The article was for Windows Server 2003, but it left me thinking that if reverse DNS checks were a requirement, this registry option would need to be set to true, or at least that the default behaviour in Windows Operating systems since Windows Server 2003 (and perhaps earlier) is not to do reverse DNS checks. And NetApp Clustered ONTAP 8.2.1 is not configured out of the box to do these reverse DNS checks for Kerberos either.

APPENDIX B: Further Reading

Kerberos protocol registry entries and KDC configuration keys in Windows Server 2003

MIT Kerberos Documentation

Appendix D: Kerberos and LDAP Troubleshooting Tips

Step-by-Step Guide to Kerberos 5 (krb5 1.0) Interoperability
“The Microsoft Windows 2000 operating system implementation of the Kerberos version 5 protocol ...”

Kerberos (protocol)

No comments:

Post a Comment