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.


  1. We have a number of AD domains trusted by each other and connected through VPN tunnels.
  2. We have a read only DC in a DMZ connected to the main AD network
  3. External LAMP web servers - we are using a single instance to test the new configuration

Tasks completed:

  1. Added the DMZ DC to the hosts file
  2. Updated the krb5.conf file and associated a single realm and domain (domain1) with DMZ DC
  3. Tested authentication on command line with kinit (worked)
  4. Updated the krb5.conf file with additional realms and domain realm mappings with all domains pointing at the DMZ DC
  5. 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


 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

  kdc = dc01.domain1.com
  admin_server= dc01.domain1.com
  kdc = dc01.domain2.com
  admin_server= dc01.domain2.com
  kdc = dc01.domain3.com
  admin_server= dc01.domain3.com
  kdc = dc01.domain4.com
  admin_server= dc01.domain4.com


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: [email protected] 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


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.

  • Is the DC seeing the requests? The Security log audits requests made against the DC. This will enable debugging in the System log as well.
    – Nathan C
    May 13, 2014 at 17:29
  • I have no access to the DC but have requested the log files from the network admin.
    – Jameel
    May 14, 2014 at 8:55
  • The log you have there appears to not be the requests from your external server but from the DC to itself (which is common)...definitely need one with your server's name in it.
    – Nathan C
    May 14, 2014 at 11:57
  • Have searched the log for references to the web server and can't find anything (IP address or server name).
    – Jameel
    May 14, 2014 at 13:06
  • So, with that in mind it sounds like your server isn't even hitting the DC...
    – Nathan C
    May 14, 2014 at 13:11

1 Answer 1


0x6. KDC_ERR_C_PRINCIPAL_UNKNOWN there it is...investigate this. It sounds like your SPNs are not set up correctly or it's trying to use an account that doesn't even exist. Wireshark is another good tool you can run on the web server to see what it gets from the DC when making requests.

  • Thanks for the guidance - I'll look into this and post my findings / resolution of the problem.
    – Jameel
    May 14, 2014 at 13:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .