DDNS to Windows server Failed TGT

NBaumber

Hi,

 

I'm battling to get DDNS setup running from our Infoblox (running only DHCP) on v6.11 to send the PTR records back to our windows 2012 R2 DNS servers. I have been given lots of different and conflicting information on how to set this up (mainly the ktpass syntax for the keytab file) but I keep getting the same error as below when I run "show dhcp_gss_tsig config"

 

Failed to obtain TGT for principal. Please check that the KDC is
reachable, that port 88 (kerberos) is not firewalled, that the
principal is known to the KDC, and that this member's clock is
synchronized with the KDC.

 

I have checked (triple checked!) that port 88 is open and the clocks are sync.

 

Has anyone seen the above or successfully setup DDNS in the same way?

 

cheers

 

DEvans

That really looks like something is not matching between the keytabfile generation syntax with ktpass.exe and some of the fields that Infoblox assumes when using the key file.

It also could be your krypto key.   It is a combination of both the OS level of your DC's and the functional level of the forest that determines which of the encryption types that Microsoft will accept for the keyfile.


This is a link to a 3rd party that helped me decyher which of the key fields are hard coded \ assumed by Infoblox and which ones you have to fill in with your server info.   The syntax is slightly different for Infoblox DHCP servers sending DNS to Microsoft DNS servers than if you are trying to setup Infoblox DNS to accept GSS-TSIG signed updates from windows DHCP clients.

(EDIT-- so the link doesn't work any more but here is the raw text.)

https://www.accumuli.com/blog/infoblox-and-gss-tsig

Infoblox and GSS-TSIGWednesday 14th July 2010 I've been playing with GSS-TSIG support in Infoblox recently as we have a few customers who are looking to use it. Basically an Infoblox NIOS appliance can use GSS-TSIG authentication in one of two modes:

•GSS-TSIG from Clients to Infoblox DNS Servers
•GSS-TSIG from Infoblox DHCP Servers to Microsoft DNS
My testing focused in the second option - running an Infoblox DHCP server and having it do DDNS to a MS DNS server, hosting secure AD-integrated zones. I did the following to get it working:

Setup

•Windows server: artemis.foo.com (192.168.69.198)
•Windows AD domain: foo.com
•Infoblox DHCP grid member
Windows stuff
•Configure the Windows server and the NIOS appliance to synchronize time with the same NTP server (GSS-TSIG seems to like the same time on both systems)
•Add an AD account, example:
?Username: bloxgss
?Password: Password1
?Enable 'Use DES encryption...' on the users account (if running Windows server 2003)
•Note: The AD domain I'm testing with is foo.com.
•Generate a 'keytab' file on the Windows server, examples:
Windows 2003: C:\>ktpass -princ bloxgss/instance@FOO.COM -mapuser bloxgss@FOO.COM -pass Password1 -out blox2k3.ktb -ptype krb5_nt_principal -crypto des-cbc-md5 +DesOnly

Windows 2008: C:\>ktpass -princ bloxgss@FOO.COM -mapuser bloxgss@FOO.COM -pass Password1 -out blox2k8.ktb -ptype krb5_nt_principal -crypto All +DesOnly

Notes:

•A full description of the ktpass command line options is in the Infoblox NIOS admin guide. But the main difference is that Windows 2003 requires the principal name to include a slash with a character string (hence /instance). Windows 2008 doesn't require this.
•ktpass.exe? KtPass.exe command line tool configures the principal name for the service in Active Directory and generates an MIT-style Kerberos "keytab" file containing the shared secret key. The tool allows UNIX-based services that support Kerberos authentication to use the interoperability features provided by the Windows Server 2003 Kerberos KDC service.
 

UPDATE - October 2010

No Des

Due to Microsoft recommending that in Windows 2008, accounts should not be configured for Des only, I now omit the '+DesOnly' option on the ktpass command line when generating the keytab file.

Windows 2008 R2

If using Windows 2008 R2, the DDNS updates will fail if the keytab file is generated using the '-crypto All' option - Windows will not generate a Kerberos ticket for the Infoblox AD account. To resolve this, generate the keytab file with a specific encryption type, which is one of:

•DES-CBC-MD5
•AES256-SHA1
•AES128-SHA1
•RC4-HMAC-NT
I have tested with AE256-SHA1 and it worked fine.

An example of the ktpass command line is:

C:\>ktpass -princ bloxgss@FOO.COM -mapuser bloxgss@FOO.COM -pass Password2 -out blox2k8r2.ktb -ptype krb5_nt_principal -crypto AES256-SHA1

NOTE: This process can also be used if you want to force a particular encryption type in Windows 2008.

 

Infoblox stuff

•Enable DDNS in Infoblox, with GSS-TSIG authentication (grid or member level), example:
?Enable GSS-TSIG and define:
¦FQDN\IP of the domain controller: artemis.foo.com
¦Upload the keytab file generated in the previous step
?Enable option81 support, if required 
•Define external DDNS zones:
?Forward zone: 
¦zone: foo.com
¦DNS Server Address: 192.168.69.198
¦Security: GSS-TSIG
¦AD Domain: FOO.COM
¦DNS Principal: DNS/artemis.foo.com@foo.com
?Reverse zone: 
¦zone: 69.168.192.in-addr.arpa
¦DNS Server Address: 192.168.69.198
¦Security: GSS-TSIG
¦AD Domain: FOO.COM
¦DNS Principal: DNS/artemis.foo.com@foo.com
•Restart services and then check the syslog. You should see a number of GSS-TSIG entries, but the one I was looking for was:
dhcpd: Security context established with server 192.168.69.198 for principal bloxgss/instance@FOO.COM

•Then get a client to obtain an IP and confirm MS DNS is updated!
Notes:
In the DNS principal field, it must start with 'DNS/' (i.e. you need to type this in!). This then creates the required statements in the dhcpd configuration file. Example:
zone "foo.com." {
 primary 192.168.69.198;
 dns-principal "DNS/artemis.foo.com@foo.com";
 key GSS_TSIG_KEY_1;
}
 

There are a few considerations when deploying GSS-TSIG updates on Infoblox:

•An Infoblox DHCP server can send GSS-TSIG updates for one AD-integrated secure domain only *
•Multiple Infoblox DHCP servers can update that domain (using the same keytab on all servers or generating different keytab files for each server)
•Each grid DHCP member can update a different AD-integrated secure domain, if necessary
•A new keytab file must be generated and upload to Infoblox if the AD user's password that Infoblox uses is changed (I'm sure security teams would have an issue setting 'password never expires' on the account!)
•If a network view has multiple DNS views, you can select only one DNS view for DDNS updates
•The admin guide seemed to say that the Infoblox member must be in the AD domain it will be updating, or there must be a trust relationship. I didn't come across this though in testing
 

So, of these the first one seems to be the main issue with customers I've talked to - the Infoblox DHCP server can only send GSS-TSIG updates to one domain. One potential workaround if there are multiple AD domains in use is to have the clients (those that do DDNS updates themselves) update the A record and the DHCP server update the PTR, by using option 81. This only works though if the reverse zone(s) reside on one system.

* UPDATE March 2011

Infoblox can update multiple AD domains securely, as long as AD trusts are in place. See the Infoblox DHCP GSS-TSIG updates to multiple AD zones article which details the configuration required to get this working.

 

Kier Prior-Williams
Professional Services Consultant

tuscany networks Limited
Tuscany House, White Hart Lane, Basingstoke, RG21 4AF, UK.