AD FS 3.0 claims-based identity failure; kerberos error 0x29 KRB_AP_ERR_MODIFIED RRS feed

  • Question

  • I am attempting to perform a claims-based access control scenario by utilizing claims included in kerberos tickets via Dynamic Access Control, and converting them to SAML attributes via pass through or transform rules in AD FS 3.0. The setup I want to implement is essentially what's described in this link, excluding the file server as I want to implement access control to web applications outside our Windows domain:


    The AD FS 3.0 setup appears to be working, in terms of SSO and generating SAML tokens with Active Directory attributes obtained through LDAP queries. But one thing I could not figure out and get working is to use existing claims I defined in Dynamic Access Control via ADAC and use them in the acceptance and issuance claims rules in AD FS. It would appear that the claims are not even being "read" or "detected" by AD FS, and the only clue I have left in solving this mystery is a kerberos error 0x29 KRB_AP_ERR_MODIFIED whenever a user performs SSO via Windows Integrated Authentication on the client browser.

    Here are the things I have done to eliminate them from possible troubleshooting:

    1. Claims in kerberos

    I have ensured that claims are indeed seen in the kerberos tickets. I see all claims defined through Dynamic Access Control whenver I perform a whoami /claims or when I try to query using System.Security.Principal.WindowsIdentity class in .NET. Kerberos armoring and compound authentication are enabled and requested, as set via Group Policy (KDC and Kerberos) for the entire domain.

    2. SPN

    I have ensured that the AD FS service is using a service account with an SPN for the federation service name: HOST/{FQDN of federation service}. There are no duplicate SPNs in the domain when queries using setspn -x. Federation service name FQDN is unique in the domain.

    3. DNS

    The federation service has its own certificate, IP address, and network interface (this is a virtual setup). Certificate subject contains the AD FS FQDN. There is a host (A) record for the AD FS FQDN, as well as a reverse lookup (PTR) record for its IP. There are no duplicate records and I am not using CNAME records.

      4. Kerberos Logs

    Interestingly, I get an audit success for the logged in user in the AD FS security logs whenever an SSO happens when I access the web application. There is also an audit success event for a "Kerberos service ticket operation" in the Domain Controller corresponding to this event. I get a  0x29 KRB_AP_ERR_MODIFIED error in the System log (after enabling kerberos logging) a few milliseconds after the audit success happens.

    5. Packet Capture

    Wireshark does not see this 0x29 KRB_AP_ERR_MODIFIED at all, which leads me to think that this error happens outside of network communication. It sometimes see a 0x19 KDC_ERR_PREAUTH_REQUIRED error from time to time but I presume this is normal as it always happens even from a base Windows Server install. Fiddler always mentions that it "appears" that a kerberos ticket is used throughout the SSO process. HTTPS decryption is enabled when doing/analyzing packet captures, just to be sure.

    6. MaxTokenSize

    I have enabled and experimented with values of the kerberos MaxTokenSize attribute via Group Policy, but this did not have any effect.

    7. Client Browser settings

    I pretty much used IE for testing, and it is set for Windows Integrated Authentication by default. My domain is in the Intranet zone, as well as the target web application. SSO is working fine. Enabling Chrome and Firefox as a supported clients in AD FS enables them to have SSO capabilities as well, so I have no problems here.

    8. Kerberos Delegation

    I have enabled the AD FS server for kerberos delegation to any service. I would think kerberos delegation is not possible for service accounts, so I did not attempt to enable delegation to the AD FS service (if in case it is possible).

    I am out of troubleshooting options at this time, so I am temporarily accepting that this is a bug or is not intended to work as described in the article for now. I'll have to take this closer to MS with our corporate support contract, but I am pasting it here for now just in case someone can identify the solution (or problem) and lead me to the right direction.

    If you have any suggestion, please let me know. Thanks!

    Friday, February 5, 2016 9:27 AM


  • Please see answer in this thread:


    Friday, March 25, 2016 9:12 AM

All replies

  • KDC_ERR_PREAUTH_REQUIRED can be ignored. It is a part of the probing implemented since Windows Vista/Windows Server 2008. It is expected.

    KRB_AP_ERR_MODIFIED though is not. And there are mainly three reasons why we would have this error.

    1. The SPN is on the wrong account in AD (the SPN HOST/adfs.contoso.com should be set only on the ADFS service account).
    2. The DNS resolution does not work as expected and the adfs.contoso.com is resolved to another FQDN than the A of the ADFS farm.
    3. The password of the ADFS service account changed multiple times recently and the ticket has been encrypted with an older key (check AD replication and the DCs used by the user and ADFS server).

    I know that you are telling that you checked this, but I don't see any other reasons.

    Note that the KERB_AP messages are embedded into the application protocol. So you won't see them in a network trace if the protocol is encrypted (which is the case of the HTTPS traffic).

    For the DNS resolution, make sure that you don't have an HTTP proxy messing with us and make the client thinks that the ADFS farm is something else.

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Saturday, February 6, 2016 5:23 PM
  • Hi Pierre,

    Thank you for your response. I checked SPN and DNS again but it really is all set correctly. This is a new virtual environment setup that I built as a proof of concept experiment on SSO and claims-based acces control using DAC and ADFS, so there really isn't much going on to possibly interfere with the setup. A proxy is certainly out of the question.

    It makes it twice as difficult to troubleshoot when the issue is not visible in packet captures, as you confirmed. I must point out though that I am using HTTPS decryption when doing a trace, so none should be encrypted in the trace file even if the channel is using HTTPS. I can actually see all KRB5/kerberos and HTTP packets going through the AD FS server. 

    If you or anyone else have another way of troubleshooting this issue, it is most welcome.

    Monday, February 8, 2016 9:14 AM
  • Please see answer in this thread:


    Friday, March 25, 2016 9:12 AM