Mixed Results when Changing DNS

So your test A record (let's call it devtest.example.com) currently resolves to your virtual server address 172.16.1.11. When a connection is attempted at that FQDN and the connection gets routed to your virtual server, the connection doesn't work? This should be independent of the existing CNAME record unless one of the devservers is redirecting and using the CNAME.

Can you take a packet capture on the LTM between your client and the virtual server to see what is going on?

Cory, thanks for the reply.

To answer your first question, no. When I connect to the FQDN of "devtest.example.com" it works. My AD creds get passed and SSO works. But when I delete the CNAME in DNS, I go to "devtest.example.com" and it no longer passes my credentials.

I have a packet capture from the client, going to the server, but the results don't tell me much because I was connected to VPN at the time. I've never run a tcpdump on the Big IP.

I have a content re-write profile on the virtual server that hides the real server DNS name. It's a URI Translation, and I've made a change to it to see if it fixes the problem.

Yeah, it definitely sounds like some kind of redirect or translation is occurring. Let me know if your change fixes the issue. Sounds like it should though.

I figured out part of the problem, but not before I was able to finish within my change window.

My LTM is set to rewrite. I made a change to the rewrite rule on my LTM, and still could not get the SSO to work. However, I discovered that the server is set to rewrite as well, in order to hide the real server name.

Now it comes down to this: who does the rewriting? It seems inefficient to have a DNS A-record dev.example.com point to the LTM, the LTM pass the traffic to devserver01/02, who then rewrites to the A-record that already points at the LTM.

This is going to be the first server put behind my LTMs. Should I take the rewriting function off the servers and put that responsibility on the LTM exclusively?

Personally, I would leave the rewrite in place on the server instead of doing it on the LTM. Less configuration to troubleshoot in the event something goes awry, or when something changes and you have to make exceptions for that at the LTM.

We did some more testing and after checking the logs, we did not see user credentials being passed at all. After some digging around, the problem was fixed when we added the "dev.example.com" to the Service Principal Name. This allowed the Kerberos ticket to be generated and granted.

Thanks for your help.