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)
Comments
Post a Comment