Background:
We have a number of AD networks (domains) that are connected through VPNs and have established AD trust relationships. We have an externally hosted web server and have configured seamless authentication for any user within the trusted network. This works but the presence of the VPN to an external web server not managed by our IT department has been deemed too great a security risk by the network team.
I have no admin access to the internal networks but do have full admin access on the web servers.
Want To:
Establish the same seamless authentication without a VPN by using a read only DC in a DMZ to process all authentication requests.
Details:
- We have a number of AD domains trusted by each other and connected through VPN tunnels.
- We have a read only DC in a DMZ connected to the main AD network
- External LAMP web servers - we are using a single instance to test the new configuration
Tasks completed:
- Added the DMZ DC to the hosts file
- Updated the krb5.conf file and associated a single realm and domain (domain1) with DMZ DC
- Tested authentication on command line with kinit (worked)
- Updated the krb5.conf file with additional realms and domain realm mappings with all domains pointing at the DMZ DC
- Tested authentication on the command line with a user from one of the additional realms and it failed.
Example of current configs
/etc/hosts/ : (I have replaced the actual IP with x's and the real domain names for reasons of confidentiality)
xxx.xxx.xxx.xxx dc01.domain1.com, dc01.domain2.com, dc01.domain3.com, dc01.domain4.com
/etc/krb5.conf:
[libdefaults]
default_realm = REALM1.COM
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
clockskew = 12000
kdc_timesync = 1
[realms]
REALM1.COM = {
kdc = dc01.domain1.com
admin_server= dc01.domain1.com
}
REALM2.COM = {
kdc = dc01.domain2.com
admin_server= dc01.domain2.com
}
REALM3.COM = {
kdc = dc01.domain3.com
admin_server= dc01.domain3.com
}
REALM4.COM = {
kdc = dc01.domain4.com
admin_server= dc01.domain4.com
}
Issues:
The DMZ is not processing authentication requests for the trusted domains. I do not know if this is a result of the configuration of the DC or the kerberos config hence the appeal for help.
Have spent a good few hours going through other questions on serverfault, googling and reading tutorials but nothing seems to match our scenario.
Can we do what we are trying and if so, what do we need to do to get it working? Is it a simple case of setting the DMZ as a proxy for the kdcs of the other realms?
In response to Nathan C, the security log shows requests for kerberos service tickets like this:
Audit Success 14/05/2014 11:05 Microsoft-Windows-Security-Auditing 4769 Kerberos Service Ticket Operations "A Kerberos service ticket was requested.
Account Information: Account Name: RODC01$@DOMAIN1.COM Account Domain: DOMAIN1.COM Logon GUID: {C93D9AAC-6968-6C00-83EF-2C2D54E2363B}
Service Information: Service Name: RODC01$ Service ID: DOMAIN1\RODC01$
Network Information: Client Address: ::1 Client Port: 0
Additional Information: Ticket Options: 0x40810000 Ticket Encryption Type: 0x17 Failure Code: 0x0 Transited Services: -
This event is generated every time access is requested to a resource such as a computer or a Windows service. The service name indicates the resource to which access was requested.
This event can be correlated with Windows logon events by comparing the Logon GUID fields in each event. The logon event occurs on the machine that was accessed, which is often a different machine than the domain controller which issued the service ticket.
Ticket options, encryption types, and failure codes are defined in RFC 4120."
Unfortunately the extract of the log sent to me does not tally with the times that I was trying the authentication so I don't know what that log entry actually relates to. I have requested another extract.
Account Information:
Account Name: jameel.rahmaa
Supplied Realm Name: DOMAIN1.COM
User ID: NULL SID
Service Information:
Service Name: krbtgt/DOMAIN1.COM
Service ID: NULL SID
Network Information:
Client Address: [WEB IP HIDDEN]
Client Port: 34567
Additional Information:
Ticket Options: 0x40800000
Result Code: 0x6
Ticket Encryption Type: 0xffffffff
Pre-Authentication Type: -
Certificate Information:
Certificate Issuer Name:
Certificate Serial Number:
Certificate Thumbprint:
Certificate information is only provided if a certificate was used for pre-authentication.
Pre-authentication types, ticket options, encryption types and result codes are defined in RFC 4120.
Not sure why but the final character of my name has been cut off.