First, DON'T capitulate. He is not only an idiot but DANGEROUSLY wrong. In fact, releasing this information would violate the PCI standard (which is what I'm assuming the audit is for since it's a payment processor) along with every other standard out there and just plain common sense. It would also expose your company to all sorts of liabilities.
The next thing I would do is send an email to your boss saying he needs to get corporate counsel involved to determine the legal exposure the company would be facing by proceeding with this action.
This last bit is up to you, but I would contact VISA with this information and get his PCI auditor status pulled.
Thanks for all your input, guys. We got Microsoft on board, and they helped us debug the authentication process on the AD side. Everything worked as it was supposed to, but failed after thirty minutes.
While we were doing a remote debugging session, on of the participants noticed that the UPN/SPN of the service account was suddenly resat from HTTP/mysite.mycorp.com@MYCORP.COM to service-account@mycorp.com. After a LOT of digging around, including debugging AD replication, we found the culprit:
Someone had made a script that ran periodically (or probably by event, since it was exactly thirty minutes after running ktpass.exe), which updated the UPN/PSN to "ensure cloud connectivity". I do not have any supplemental information on the reasons for doing this.
The script was changed to allow existing UPN/SPN values ending in @mycorp.com, effectively solving the problem.
Tips for debugging issues like this:
- Ensure all the participants in the authentication supports the same encryption types. Avoid DES - it's outdated and insecure.
- Make sure to enable AES-128 and AES-256 encryption on the service account
- Be aware that enabling DES on the service account means "use ONLY DES for this account", even if you enabled any of the AES encryptions. Do a search for UF_USE_DES_KEY_ONLY for details on this.
- Make sure the UPN/SPN value is currect and matches the value in the issued keytab file (i.e. through an LDAP lookup)
- Make sure the KVNO (Key Version Number) in the keytab file matches the on on the server
- Inspect traffic between server and client (i.e. with tcpdump and/or WireShark)
- Enable debugging of authentication on the AD side - inspect logs
- Enable debugging of replication on the AD side - inspect logs
Again, thank you for your input.
Best Answer
When you get a ticket initially (by requesting one from the KDC) you get back a TGT, or Ticket Granting Ticket. This is then used to contact the Ticket Granting Server to request application or other tickets.
In every system I've had personal experience with, the KDC and TGS were the same machine, in fact the same application. However, 100% of my experience lies in the open source MIT and Heimdal services. In this case, once again in my experience, both services are performed in the same binary.