I am trying to connect to the Alternate endpoint with the Resource Management Client from a remote server. Since the existing DefaultClient does not support a specified SPN/UPN, I have added a constructor that will accept an SPN/UPN. The SPN/UPN is used to build an Alternate EndpointAddress with an EndpointIdentity, created with either CreateSpnIdentity or CreateUpnIdentity. My traces show that the password reset client service always establishes connectivity using the SPN: "FIMService/hostname", and the SSPI negotiation used is Kerberos/Delegation at the server side. The RequestSecurityToken's BinaryExchange holds the large Kerberos ticket. With the ResourceManagement Client, no matter what I try, the initial AlternateClient Put fails. The Service SpnegoTokenAuthenticator always attempts to use NTLM/Identify... which obviously fails with the exception: "The service does not allow you to log on anonymously". The RequestSecurityToken BinaryExchange seems to hold the small NTLM Token. I have set the alternateClient properties: this.alternateClient.ClientCredentials.Windows.AllowNtlm = false; this.alternateClient.ClientCredentials.Windows.AllowedImpersonationLevel = TokenImpersonationLevel.Delegation; I have tried using the FIMService SPN: Security Support Provider Interface (SSPI) authentication failed. The server may not be running in an account with identity 'FIMService/hostname.company.local'. If the server is running in a service account (Network Service for example), specify the account's ServicePrincipalName as the identity in the EndpointAddress for the server. If the server is running in a user account, specify the account's UserPrincipalName as the identity in the EndpointAddress for the server. I have tried using the FIM Service Account UPN: Security Support Provider Interface (SSPI) authentication failed. The server may not be running in an account with identity 'COMPANY\SVCACC001'. If the server is running in a service account (Network Service for example), specify the account's ServicePrincipalName as the identity in the EndpointAddress for the server. If the server is running in a user account, specify the account's UserPrincipalName as the identity in the EndpointAddress for the server. The following is how I am programmatically building up the Binding: WSHttpContextBinding oContextBinding = new WSHttpContextBinding(); oContextBinding.Name = "ServiceMultipleTokenBinding_Alternate"; oContextBinding.CloseTimeout = new TimeSpan(0, 1, 0); oContextBinding.OpenTimeout = new TimeSpan(0, 1, 0); oContextBinding.ReceiveTimeout = new TimeSpan(0, 10, 0); oContextBinding.SendTimeout = new TimeSpan(0, 1, 0); oContextBinding.BypassProxyOnLocal = false; oContextBinding.TransactionFlow = false; oContextBinding.HostNameComparisonMode = HostNameComparisonMode.StrongWildcard; oContextBinding.MaxBufferPoolSize = 524288; oContextBinding.MaxReceivedMessageSize = 965536; oContextBinding.MessageEncoding = WSMessageEncoding.Text; oContextBinding.TextEncoding = Encoding.UTF8; oContextBinding.UseDefaultWebProxy = true; oContextBinding.AllowCookies = false; oContextBinding.ContextProtectionLevel = System.Net.Security.ProtectionLevel.Sign; oContextBinding.ReaderQuotas = new XmlDictionaryReaderQuotas(); oContextBinding.ReaderQuotas.MaxDepth = 32; oContextBinding.ReaderQuotas.MaxStringContentLength = 8192; oContextBinding.ReaderQuotas.MaxArrayLength = 16384; oContextBinding.ReaderQuotas.MaxBytesPerRead = 4096; oContextBinding.ReaderQuotas.MaxNameTableCharCount = 16384; oContextBinding.ReliableSession.Ordered = true; oContextBinding.ReliableSession.InactivityTimeout = new TimeSpan(0, 10, 0); oContextBinding.ReliableSession.Enabled = false; oContextBinding.Security.Mode = SecurityMode.Message; oContextBinding.Security.Transport.ClientCredentialType = HttpClientCredentialType.Windows; oContextBinding.Security.Transport.ProxyCredentialType = HttpProxyCredentialType.None; oContextBinding.Security.Transport.Realm = ""; oContextBinding.Security.Message.ClientCredentialType = MessageCredentialType.Windows; oContextBinding.Security.Message.NegotiateServiceCredential = true; oContextBinding.Security.Message.AlgorithmSuite = System.ServiceModel.Security.SecurityAlgorithmSuite.Default; oContextBinding.Security.Message.EstablishSecurityContext = false; Has anyone been successful in establishing a remote connection to the Alternate endpoint via the ResourceManagement Client? I'm sure I am overlooking some setting, but I have been unable to find it. Thanks, -Mike

Additional Info: Here is the LSASS.log with Kerberos Logging enabled, after a KLIST Purge: 484.520> SPM-Neg: NegAcquireCredentialsHandle: Get a Negotiate CredHandle: 484.520> SPM-Neg: Added 0000000001B5F5F0:0000000000000001, NegoExtender 484.520> SPM-Neg: Added 0000000000B7E9A0:0000000000000002, Kerberos 484.520> SPM-Neg: Added 0000000000B7E9A0:0000000000000002, Kerberos 484.520> SPM-Neg: Added 0000000001B5FE10:0000000000000003, NTLM 484.520> SPM-Neg: NegAcquireCredentialsHandle: returned 0x0 484.2712> SPM-Neg: TokenTarg chosen! 484.520> SPM-WAPI: [358] WLsaInitContext(000000000044CE80 : 0000000000000000, 0000000000000000 : 0000000000000000, FIMService/FIMxxxxSVR) 484.520> SPM-Verbose: Context Req = 0x0002001e 484.520> SPM-Verbose: Package = Negotiate 484.520> SPM-Neg: NegBuildRequestToken swap Kerberos index 2 with extender index 0 484.520> SPM-Neg: NegBuildRequestToken getting initial token from preferred package 'Kerberos' 484.520> SPM-WAPI: [358] WLsaInitContext(0000000000B7E9A0 : 0000000000000002, 0000000000000000 : 0000000000000000, FIMService/FIMxxxxSVR) 484.520> SPM-Verbose: Context Req = 0x0003001e 484.520> SPM-Verbose: Package = Kerberos 484.520> SPM-WAPI: InitResult = 8009030e 484.520> SPM-Verbose: Flags = 00000000 484.520> SPM-WAPI: Init New Context = 0000000000000000 : 0000000000000000 to session 0000000000BA10A0 484.520> SPM-Neg: NegBuildRequestToken WLsaInitContext( FIMService/FIMxxxxSVR, package id 2 ) returned 0x8009030e 484.520> SPM-Neg: NegBuildRequestToken failed 0x8009030e getting token from preferred package 2 484.520> SPM-Neg: NegBuildRequestToken status code 8009030e causing us to continue 484.520> SPM-Neg: NegBuildRequestToken status code 8009030e causing us to continue 484.520> SPM-Neg: NegBuildRequestToken getting initial token from preferred package 'NegoExtender' 484.520> SPM-WAPI: [358] WLsaInitContext(0000000001B5F5F0 : 0000000000000001, 0000000000000000 : 0000000000000000, FIMService/FIMxxxxSVR) 484.520> SPM-Verbose: Context Req = 0x0003001e 484.520> SPM-Verbose: Package = NegoExtender 484.520> SPM-WAPI: InitResult = 8009030e 484.520> SPM-Verbose: Flags = 00000000 484.520> SPM-WAPI: Init New Context = 0000000000000000 : 0000000000000000 to session 0000000000BA10A0 484.520> SPM-Neg: NegBuildRequestToken WLsaInitContext( FIMService/FIMxxxxSVR, package id 1 ) returned 0x8009030e 484.520> SPM-Neg: NegBuildRequestToken failed 0x8009030e getting token from preferred package 1 484.520> SPM-Neg: NegBuildRequestToken status code 8009030e causing us to continue 484.520> SPM-Neg: NegBuildRequestToken dropping back to pure NTLM 484.520> SPM-Neg: NegBuildRequestToken getting initial token from preferred package 'NTLM' 484.520> SPM-WAPI: [358] WLsaInitContext(0000000001B5FE10 : 0000000000000003, 0000000000000000 : 0000000000000000, FIMService/FIMxxxxSVR) 484.520> SPM-Verbose: Context Req = 0x0003001e 484.520> SPM-Verbose: Package = NTLM 484.520> SPM-WAPI: InitResult = 90312 484.520> SPM-Verbose: Flags = 0003001c 484.520> SPM-WAPI: Init New Context = 0000000001B7F570 : 0000000000000003 to session 0000000000BA10A0 484.520> SPM-Neg: NegBuildRequestToken WLsaInitContext( FIMService/FIMxxxxSVR, package id 3 ) returned 0x90312 484.520> SPM-Neg: NegBuildRequestToken adding MechList 484.520> SPM-Neg: NegBuildRequestToken replacing handle, current status is 90312 484.520> SPM-Trace: [358] Deleting old context handle 0000000000000000 : 0000000000000000 484.520> SPM-Neg: Deleting context b7fbc0 484.520> SPM-Neg: NegGenerateInitialToken returned 90312 484.520> SPM-WAPI: InitResult = 90312 484.520> SPM-Verbose: Flags = 00001000 484.520> SPM-WAPI: Init New Context = 0000000001B7F570 : 0000000000000003 to session 0000000000BA10A0

Additional Info: Here is the LSASS.log with Kerberos Logging enabled, after a KLIST Purge: 484.520> SPM-Neg: NegAcquireCredentialsHandle: Get a Negotiate CredHandle: 484.520> SPM-Neg: Added 0000000001B5F5F0:0000000000000001, NegoExtender 484.520> SPM-Neg: Added 0000000000B7E9A0:0000000000000002, Kerberos 484.520> SPM-Neg: Added 0000000000B7E9A0:0000000000000002, Kerberos 484.520> SPM-Neg: Added 0000000001B5FE10:0000000000000003, NTLM 484.520> SPM-Neg: NegAcquireCredentialsHandle: returned 0x0 484.2712> SPM-Neg: TokenTarg chosen! 484.520> SPM-WAPI: [358] WLsaInitContext(000000000044CE80 : 0000000000000000, 0000000000000000 : 0000000000000000, FIMService/FIMxxxxSVR) 484.520> SPM-Verbose: Context Req = 0x0002001e 484.520> SPM-Verbose: Package = Negotiate 484.520> SPM-Neg: NegBuildRequestToken swap Kerberos index 2 with extender index 0 484.520> SPM-Neg: NegBuildRequestToken getting initial token from preferred package 'Kerberos' 484.520> SPM-WAPI: [358] WLsaInitContext(0000000000B7E9A0 : 0000000000000002, 0000000000000000 : 0000000000000000, FIMService/FIMxxxxSVR) 484.520> SPM-Verbose: Context Req = 0x0003001e 484.520> SPM-Verbose: Package = Kerberos 484.520> SPM-WAPI: InitResult = 8009030e 484.520> SPM-Verbose: Flags = 00000000 484.520> SPM-WAPI: Init New Context = 0000000000000000 : 0000000000000000 to session 0000000000BA10A0 484.520> SPM-Neg: NegBuildRequestToken WLsaInitContext( FIMService/FIMxxxxSVR, package id 2 ) returned 0x8009030e 484.520> SPM-Neg: NegBuildRequestToken failed 0x8009030e getting token from preferred package 2 484.520> SPM-Neg: NegBuildRequestToken status code 8009030e causing us to continue 484.520> SPM-Neg: NegBuildRequestToken status code 8009030e causing us to continue 484.520> SPM-Neg: NegBuildRequestToken getting initial token from preferred package 'NegoExtender' 484.520> SPM-WAPI: [358] WLsaInitContext(0000000001B5F5F0 : 0000000000000001, 0000000000000000 : 0000000000000000, FIMService/FIMxxxxSVR) 484.520> SPM-Verbose: Context Req = 0x0003001e 484.520> SPM-Verbose: Package = NegoExtender 484.520> SPM-WAPI: InitResult = 8009030e 484.520> SPM-Verbose: Flags = 00000000 484.520> SPM-WAPI: Init New Context = 0000000000000000 : 0000000000000000 to session 0000000000BA10A0 484.520> SPM-Neg: NegBuildRequestToken WLsaInitContext( FIMService/FIMxxxxSVR, package id 1 ) returned 0x8009030e 484.520> SPM-Neg: NegBuildRequestToken failed 0x8009030e getting token from preferred package 1 484.520> SPM-Neg: NegBuildRequestToken status code 8009030e causing us to continue 484.520> SPM-Neg: NegBuildRequestToken dropping back to pure NTLM 484.520> SPM-Neg: NegBuildRequestToken getting initial token from preferred package 'NTLM' 484.520> SPM-WAPI: [358] WLsaInitContext(0000000001B5FE10 : 0000000000000003, 0000000000000000 : 0000000000000000, FIMService/FIMxxxxSVR) 484.520> SPM-Verbose: Context Req = 0x0003001e 484.520> SPM-Verbose: Package = NTLM 484.520> SPM-WAPI: InitResult = 90312 484.520> SPM-Verbose: Flags = 0003001c 484.520> SPM-WAPI: Init New Context = 0000000001B7F570 : 0000000000000003 to session 0000000000BA10A0 484.520> SPM-Neg: NegBuildRequestToken WLsaInitContext( FIMService/FIMxxxxSVR, package id 3 ) returned 0x90312 484.520> SPM-Neg: NegBuildRequestToken adding MechList 484.520> SPM-Neg: NegBuildRequestToken replacing handle, current status is 90312 484.520> SPM-Trace: [358] Deleting old context handle 0000000000000000 : 0000000000000000 484.520> SPM-Neg: Deleting context b7fbc0 484.520> SPM-Neg: NegGenerateInitialToken returned 90312 484.520> SPM-WAPI: InitResult = 90312 484.520> SPM-Verbose: Flags = 00001000 484.520> SPM-WAPI: Init New Context = 0000000001B7F570 : 0000000000000003 to session 0000000000BA10A0

How about setting regular Kerberos debug loglevel on both client and server and then tell us what errors are thrown. For more info: Kerberos Basic Troubleshooting: Tip 4http://setspn.blogspot.com

Here is the two events at the DC (FIMServer): A Kerberos service ticket was requested. Account Information: Account Name: FIMPORTAL$@COMPANY.LOCAL Account Domain: COMPANY.LOCAL Logon GUID: {b6320c52-9785-0236-5cde-e6fffb7bb75d} Service Information: Service Name: FIMPORTAL$ Service ID: COMPANY\FIMPORTAL$ Network Information: Client Address: ::ffff:192.168.85.11 Client Port: 49290 Additional Information: Ticket Options: 0x40810000 Ticket Encryption Type: 0x12 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. An account was successfully logged on. Subject: Security ID: NULL SID Account Name: - Account Domain: - Logon ID: 0x0 Logon Type: 3 New Logon: Security ID: ANONYMOUS LOGON Account Name: ANONYMOUS LOGON Account Domain: NT AUTHORITY Logon ID: 0x55cea08 Logon GUID: {00000000-0000-0000-0000-000000000000} Process Information: Process ID: 0x0 Process Name: - Network Information: Workstation Name: FIMPORTAL Source Network Address: - Source Port: - Detailed Authentication Information: Logon Process: NtLmSsp Authentication Package: NTLM Transited Services: - Package Name (NTLM only): NTLM V1 Key Length: 128 This event is generated when a logon session is created. It is generated on the computer that was accessed. The subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe. The logon type field indicates the kind of logon that occurred. The most common types are 2 (interactive) and 3 (network). The New Logon fields indicate the account for whom the new logon was created, i.e. the account that was logged on. The network fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases. The authentication information fields provide detailed information about this specific logon request. - Logon GUID is a unique identifier that can be used to correlate this event with a KDC event. - Transited services indicate which intermediate services have participated in this logon request. - Package name indicates which sub-protocol was used among the NTLM protocols. - Key length indicates the length of the generated session key. This will be 0 if no session key was requested. Here are the two events thrown to the System event log (FIMPortal): A Kerberos Error Message was received: on logon session Client Time: Server Time: 18:37:14.0000 2/27/2011 Z Error Code: 0xd KDC_ERR_BADOPTION Extended Error: 0xc00000bb KLIN(0) Client Realm: Client Name: Server Realm: COMPANY.LOCAL Server Name: fimportal$@COMPANY.LOCAL Target Name: fimportal$@COMPANY.LOCAL@COMPANY.LOCAL Error Text: File: 9 Line: efb Error Data is in record data. A Kerberos Error Message was received: on logon session Client Time: Server Time: 18:37:15.0000 2/27/2011 Z Error Code: 0x7 KDC_ERR_S_PRINCIPAL_UNKNOWN Extended Error: Client Realm: Client Name: Server Realm: COMPANY.LOCAL Server Name: krbtgt/NT AUTHORITY Target Name: krbtgt/NT AUTHORITY@COMPANY.LOCAL Error Text: File: 9 Line: efb Error Data is in record data. FIMPortal is the SharePoint server that is trying to connect to FIMServer. FIMServer is also the DC in the company.local domain. SPNs where created as follows: C:> setspn -l COMPANY\SVCCPCLE001 Registered ServicePrincipalNames for CN=FIM Portal,OU=CP,OU=Services,OU=Special Accounts,DC=company,DC=local: HTTP/FIMServer.company.local HTTP/FIMPortal.company.local HTTP/FIMPortal FIMService/FIMServer.company.local MSSQLSvc/FIMServer.company.local:29178 MSSQLSvc/FIMServer.company.local:FIM HTTP/FIMServer FIMService/FIMServer C:> setspn -l FIMServer Registered ServicePrincipalNames for CN=FIMSERVER,OU=Domain Controllers,DC =company,DC=local: exchangeMDB/FIMServer.company.local exchangeMDB/FIMServer exchangeRFR/FIMServer.company.local exchangeRFR/FIMServer SMTP/FIMServer SMTP/FIMServer.company.local SmtpSvc/FIMServer SmtpSvc/FIMServer.company.local exchangeAB/FIMServer exchangeAB/FIMServer.company.local ldap/FIMServer.company.local/ForestDnsZones.company.local ldap/FIMServer.company.local/DomainDnsZones.company.local Dfsr-12F9A27C-BF97-4787-9364-D31B6C55EB04/FIMServer.company.local DNS/FIMServer.company.local GC/FIMServer.company.local/company.local RestrictedKrbHost/FIMServer.company.local RestrictedKrbHost/FIMServer HOST/FIMServer/COMPANY HOST/FIMServer.company.local/COMPANY HOST/FIMServer HOST/FIMServer.company.local HOST/FIMServer.company.local/company.local E3514235-4B06-11D1-AB04-00C04FC2DCD2/cdd0afaf-8997-4a7b-a325-3439a66721d 9/company.local ldap/FIMServer/COMPANY ldap/cdd0afaf-8997-4a7b-a325-3439a66721d9._msdcs.company.local ldap/FIMServer.company.local/COMPANY ldap/FIMServer ldap/FIMServer.company.local ldap/FIMServer.company.local/company.local C:> setspn -l FIMPortal Registered ServicePrincipalNames for CN=FIMPORTAL,CN=Computers,DC=company,DC=loc al: WSMAN/FIMPortal WSMAN/FIMPortal.company.local RestrictedKrbHost/FIMPORTAL HOST/FIMPORTAL RestrictedKrbHost/FIMPORTAL.company.local HOST/FIMPORTAL.company.local COMPANY\SVCCPCLE001 is the account that the FIM Service is executing. I have tried setting the FIMPORTAL app pool to use the same account, as well as Network Services... same result. Thanks.

Your SPN's don't seem to be conflicting. However having ... on SVCCPCLE001: MSSQLSvc/FIMServer.company.local:29178 MSSQLSvc/FIMServer.company.local:FIM => SQL Server Service should use SVCPCLE001 as it's service account FIMService/FIMServer.company.local FIMService/FIMServer => FIM Service Service should use SVCPCLE001 as it's service account HTTP/FIMServer.company.local HTTP/FIMPortal.company.local HTTP/FIMPortal HTTP/FIMServer => Application Pool for the FIM Portal (WSS) should be configured to use SVCCPCLE001 + If you configured IIS to use that account you have to do ONE of the following. Both should work you have to set useAppPoolCredentials=true in the relevant sections of your applicationHost.config (check Configuring Kerberos authentication pass through in an IIS 7 NLB setup this is for NLB, but the idea is the same) Uncheck Kernel Mode AuthN in IIS (advanced option for integrated authN) If you got all that covered, make sure you got your delegation configured: Using ADUC: double click the SVCCPLE001 account, choose the delegation tab and then make sure to select SVCCPLE001 itself and select the FIMService entry Do you have the above configured? http://setspn.blogspot.com

You're SPN's don't seem to be conflicting. However having ... on SVCCPCLE001: MSSQLSvc/FIMServer.company.local:29178 MSSQLSvc/FIMServer.company.local:FIM => SQL Server Service should use SVCPCLE001 as it's service account FIMService/FIMServer.company.local FIMService/FIMServer => FIM Service Service should use SVCPCLE001 as it's service account HTTP/FIMServer.company.local HTTP/FIMPortal.company.local HTTP/FIMPortal HTTP/FIMServer => Application Pool for the FIM Portal (WSS) should be configured to use SVCCPCLE001 + If you configured IIS to use that account you have to do ONE of the following. Both should work you have to set useAppPoolCredentials=true in the relevant sections of your applicationHost.config (check Configuring Kerberos authentication pass through in an IIS 7 NLB setup this is for NLB, but the idea is the same) Uncheck Kernel Mode AuthN in IIS (advanced option for integrated authN) If you got all that covered, make sure you got your delegation configured: Using ADUC: double click the SVCCPLE001 account, choose the delegation tab and then make sure to select SVCCPLE001 itself and select the FIMService entry Do you have the above configured?http://setspn.blogspot.com

To rule out the SPN's and the server's configuration I installed the FIM Password Reset Client. It was able to establish the connection to the Alternate endpoint via Kerberos without issue, so that means that there are problems with the WSHttpContextBinding's configuration of my WCF client. This is certainly a WCF configuration issue, Kerberos seems to be ruled out.

this.alternateClient.ClientCredentials.Windows.AllowNtlm = false; this.alternateClient.ClientCredentials.Windows.AllowedImpersonationLevel = TokenImpersonationLevel.Delegation; These don't do anything; fim service binding is not configured to allow delegation. I recall I was helping someone about a month ago precisely on this and I thought we fixed a bug in the alternate client but the bug was preventing the security negotiation when talking to the password reset activity (much later on). For quick sanity checks, can you try to access the normal endpoint with credentials? Can you then try to access the alternate endpoint with credentialed access?ex-MSFT developer, now FIM/MIIS/ILM/WPF/Silverlight consultant | http://blog.aesthetixsoftware.com/

You are correct. I am able to negotiate to the /Enumerate and /Resource endpoints just fine. The problem seems to be with just the /Alternate endpoint.

Have you tried doing an authenticated CRUD operation to the Alternate endpoint using the public client? You may have to go in there and do a thread.impersonate() before the calls to the web service. I also remember there may be some config flags still there from 6 months ago that allow you to specify the account/pwd to do the impersonation under.ex-MSFT developer, now FIM/MIIS/ILM/WPF/Silverlight consultant | http://blog.aesthetixsoftware.com/

Thanks, appreciate the second set of eyes... Sent to the only email address I could find for you (photo).

Yes, I am currently attempting to perfom a Modify operation by setting the ResetPassword attribute to "True" inorder to initiate the QAGate. Impersonation worked fine when we ran it on the same box as the FIM Service. The need for impersonation was when the client's credentials were managed in FIM it would not return the required Anonymous resource ID for the context on the Alternate endpoint. As soon as you try an connect over the wire, it fails with the SSPI negotiation fault. By setting the Service account's Delegations to "use any protocol," this corrected the issues with the other clients that use WSHttpContextBinding. Those are now negotiating with a Kerberos Delegate. The Alternate client is still reverting back to NTLM Identify and throwing the SPNego fault.

I meant what credentials are you performing that operation under? Is it anonymously (e.g. network service/machine credentials) or a user account? It's possible; I've made modifications to the client to add on top of Jeremy's functionality to allow for end to end authentication. And I remember hitting this specific issue but I'm trying to jog my memory to remember what the bug was.ex-MSFT developer, now FIM/MIIS/ILM/WPF/Silverlight consultant | http://blog.aesthetixsoftware.com/

Ah yes; now I remember. The operation was happening under a credentialed user account that was in AD but was not in the FIM store. And, the default client was performing an update on a user object by referencing a that user's GUID instead of Domain\Alias. So, in the FIM internal code, because this was coming under the alternate endpoint but was referencing the target object in the normal manner, it tried to pull the identity from the kerb ticket in the request which caused some stored proc to fail at an unexpected location which translated it back into a Security check failed/SSPI negotiation fault. So that's why I was asking, did you try it with under a credentialed user account and again under local system or network service?ex-MSFT developer, now FIM/MIIS/ILM/WPF/Silverlight consultant | http://blog.aesthetixsoftware.com/

I have tried executing my extended client with the FIM Service account and Network Services. Even added methods for forcing Impersonation if needed... this works fine for Enumerations but fails under the Alternate or STS endpoints. I am building the EndpointAddress with an EndpointIdentity from CreateSpnIdentity or CreateUpnIdentity. I am trying to extend the public client to work like the FIM Client... execute under Network Service and use the FIMService SPN for delegation.

Send me your code/test program and I'll debug it. Based on what you're saying, it doesn't sound like a kerb environment config problem. ex-MSFT developer, now FIM/MIIS/ILM/WPF/Silverlight consultant | http://blog.aesthetixsoftware.com/

I thought I would post the important differences between the FIM Client and the Open Client, in hopes that someone understands kerberos protocol transitions, low level WCF, and why the Open Client is sending the exact same Identity information to the channel as the FIM Client is...yet the outcome is quite different. <!-- Same on FIM Client and Open Client --> <DESCRIPTION m= "The IssuanceTokenProvider has started a new security negotiation." /> <TraceData> <DataItem> <TraceRecord xmlns="http://schemas.microsoft.com/2004/10/E2ETraceEvent/TraceRecord" Severity="Information"> <TraceIdentifier>http://msdn.microsoft.com/en-US/library/System.ServiceModel.Security.IssuanceTokenProviderBeginSecurityNegotiation.aspx</TraceIdentifier> <Description>The IssuanceTokenProvider has started a new security negotiation.</Description> <AppDomain>/LM/W3SVC/1795037928/ROOT-1-129436545847943576</AppDomain> <ExtendedData xmlns="http://schemas.microsoft.com/2006/08/ServiceModel/ClientSecurityNegotiationTraceRecord"> <IssuanceTokenProvider>System.ServiceModel.Security.SpnegoTokenProvider</IssuanceTokenProvider> <Target> <EndpointReference xmlns="http://www.w3.org/2005/08/addressing"> <Address>http://FimServer.company.local:5725/ResourceManagementService/Alternate</Address> <Identity xmlns="http://schemas.xmlsoap.org/ws/2006/02/addressingidentity"> <Spn>FIMService/FimServer.company.local</Spn> </Identity> </EndpointReference> </Target> </ExtendedData> </TraceRecord> </DataItem> </TraceData> <!-- Same on FIM Client and Open Client --> <DESCRIPTION m="Identity was determined for an EndpointReference." /> <TraceData> <DataItem> <TraceRecord xmlns="http://schemas.microsoft.com/2004/10/E2ETraceEvent/TraceRecord" Severity="Information"> <TraceIdentifier>http://msdn.microsoft.com/en-US/library/System.ServiceModel.Security. SecurityIdentityDeterminationSuccess.aspx</TraceIdentifier> <Description>Identity was determined for an EndpointReference.</Description> <AppDomain>/LM/W3SVC/1795037928/ROOT-1-129436545847943576</AppDomain> <ExtendedData xmlns="http://schemas.microsoft.com/2006/08/ServiceModel/ServiceIdentityDeterminationTraceRecord"> <IdentityVerifierType>System.ServiceModel.Security.IdentityVerifier+DefaultIdentityVerifier</IdentityVerifierType> <Identity xmlns="http://schemas.xmlsoap.org/ws/2006/02/addressingidentity"> <Spn>FIMService/FimServer.company.local</Spn> </Identity> <EndpointReference xmlns="http://www.w3.org/2005/08/addressing"> <Address>http://FimServer.company.local:5725/ResourceManagementService/Alternate</Address> <Identity xmlns="http://schemas.xmlsoap.org/ws/2006/02/addressingidentity"> <Spn>FIMService/FimServer.company.local</Spn> </Identity> </EndpointReference> </ExtendedData> </TraceRecord> </DataItem> </TraceData> <!-- Same on FIM Client and Open Client --> <DESCRIPTION m="Created: System.ServiceModel.Channels.HttpChannelFactory+HttpRequestChannel/46556843" /> <DESCRIPTION m="Opening System.ServiceModel.Channels.HttpChannelFactory+HttpRequestChannel/46556843" /> <DESCRIPTION m="Opened System.ServiceModel.Channels.HttpChannelFactory+HttpRequestChannel/46556843" /> <!-- ### FIM Client --> <DESCRIPTION m="Message Log Trace" /> <TraceData> <DataItem> <MessageLogTraceRecord Time="2011-03-03T12:52:01.4887010-05:00" Source="ServiceLevelReceiveRequest" Type="System.ServiceModel.Channels.BufferedMessage" xmlns="http://schemas.microsoft.com/2004/06/ServiceModel/Management/MessageTrace"> <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing"> <s:Header> <a:Action s:mustUnderstand="1">http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue</a:Action> <a:MessageID>urn:uuid:f30d0c06-e64a-4b0a-9c4d-47d36865b5f8</a:MessageID> <a:ReplyTo> <a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address> </a:ReplyTo> <a:To s:mustUnderstand="1">http://FimServer.company.local:5725/ResourceManagementService/Alternate</a:To> </s:Header> <s:Body> <t:RequestSecurityToken Context="uuid-1ce069d4-b1cc-4e50-a6ef-825af6d6fdfd-1" xmlns:t="http://schemas.xmlsoap.org/ws/2005/02/trust"> <t:TokenType>http://schemas.xmlsoap.org/ws/2005/02/sc/sct</t:TokenType> <t:RequestType>http://schemas.xmlsoap.org/ws/2005/02/trust/Issue</t:RequestType> <t:KeySize>256</t:KeySize> <t:BinaryExchange ValueType="http://schemas.xmlsoap.org/ws/2005/02/trust/spnego" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" >YIIGcAYGKwYBBQUCoIIGZDCCBmCgMDAuBgkqhkiC9xIBAgIGCSqGSIb3EgECAgYKKwYBBAGCNwICHgYKKwYBBAGCNwICCqKCBioEggYmYIIGIgY JKoZIhvcSAQICAQBuggYRMIIGDaADAgEFoQMCAQ6iBwMFACAAAACjggSSYYIEjjCCBIqgAwIBBaEPGw1DT01QQU5ZLkxPQ0FMojYwNKADAgECoS0 wKxsKRklNU2VydmljZRsdd2luLWFoa2M1bmdwbGFyLmNvbXBhbnkubG9jYWyjggQ4MIIENKADAgEXoQMCAQKiggQmBIIEIu4We1k9dVbSkz7KUtr GecFeLzRhGgaWwPitgQl6taJbc840LqiYPKp/ynUto1QDdsABvaDrKHX0rjj94uGnttGJ57MFJt/6W+ViVe3XujSrTV0UmJQ+DnC+1BLpGtEG3zw xH34Az1pxAyFACytJIeJs6ksWcLR4+T/jvwXklMxvh1tk+xc4WHaqS7ByMPC74DtcxG87OJWD6mcYSkALua6XKuPRcYjY5BihD3beimUX42wws+g e9l1WHk4vCcmM51RJzTxYMfbuJq0hOElxzC3WuSc0OO16cuZ6LTvCq7biAenpx190nltHwCTh+xrxlUPFtC+LCS7LN/7GxVVxjaNblFcnVUDrYc1 UbdkKfIGQsZFsORuwGQUgEaQu9M7SauFO7MAnujTSwzTjMIIY7o+fcB4laapmIajXNbcEH4+QOEvLqwhaFMel2zvpVmgyviFfCiEUdzotMQBvPsb 65NVt7VTF/EK8el+bHwYqaKf0fe4e3Kj45xcHnSYLPdhf4of3qda4Ln+OjD3okuK4BWjGvUMcNmDIYcE71uScn1D7BLFR+yLU/cCAryt4D71K4YV e1/swl5w5PX4EtVDxuXCQSAYMFIQNStEGzX1LsrbYhcPhLQivExR2RGlOhVmUhYI1eEmb1tG7OuGaulGnRh4ZvVKN3ExFwvQnPedoncXkwmY/BLW p+av6vKP8WBep3DTRsn/LSnfgmVTFLyo6kUwGrNJL6UfqkP7FqaN5HniSRTuO2tYGhFBPnV8NX2bRXdJIhMpBO0oIsoO4vdhku3lpw8neXb2YxU2 19dcFoN+U1eCOugGoAHOmbNCx7uAXXc9k1sDbjcyINpGgvw4aAokYzhcAURS3R19vSj7YE9xGH4Oo2CrPX1B5BU9skKtGL/yYhCqNn3BgfZdbkOa d+w/rOhwNTMYNLKD6ScVCIkKp3cpDxLUFjmph4gBCzfdw7CDrSF7Ud6ooq/qtEX+QIe9muw9rtM+bZIQIJ/Qn5dCgiJyJEn2MIxe6qblTyTykAur DljuBtRZEjhawf3izCw7XKwjV8+qa18PVsR3aOMadPIlZCysiAOYqZ6dDK+ytZMTmMBfMp/pHwJoJJHYfg6kRfbMPJAyWBFpBDhP7mNaRc9l07I3 uNLDpKEHwmluYQgCdQRYJNtr/5INzKiXZYRi6gYYL5E8mbGembHzaBKmreGqIhD9L9F7DuMwYAh53g0cIGmKcgPNVlXKcIZhA5PkUAIO+CyaMiWK wt51a9YHEu91YnnbUuuyHXNlZ4Yub5C7OHWNEs2sacr2Lx8o/c6NO+29ArdU/nx+yx9tqMnNcy2zx27kBT2sjlBg3lKd31ScVdVZvVqHhJD1jFEu wF3lG6FntmZLKsd+Vx94nNOSNWlf7DSo0JELHJVQqdX/e2ftEpIIBYDCCAVygAwIBF6KCAVMEggFPaeEDzI/cjfVoL39oarvUJt539Rf7ahSxRJ1 LtNaCa3Et5emxAp85OLwwwhbmS1LFNNGnRi61RWxg8z5N8A7azHN3xe6Vfzr2KW3Dgzy+nd5kls+8/kVdrK2/1+oKMx5XrZ2mge/o4ekPhzWPN5X nZ5VksRpZH3PXAD+yMeUdbAoDvM/utsEF3kWGrbPlpMJgkmrdhHBvLk3m+jruW0NBgZzgHkb+8q0peErBxgPOjux2TzwsaE2zkJMPgu9IZPou+1E uxSa+riAQG7wflgD224goBhs7KrzXBcicYSsMpp5DWVSUbFxYa837h9E+h1CT43yI1LAfmBEREslWCA4JbM6+7Id+LoaXWLiDk6QH0edOBAkMl5U U0bXnBHqVJElPuaFgnkclguITuLMl1XF95sbSUi5Tb/+B73i1ttB6GXX/ZEs7nw0pVX+cKJdrns4=</t:BinaryExchange> </t:RequestSecurityToken> </s:Body> </s:Envelope> </MessageLogTraceRecord> </DataItem> </TraceData> <!-- ### Open Client --> <DESCRIPTION m="Message Log Trace" /> <TraceData> <DataItem> <MessageLogTraceRecord Time="2011-03-03T14:37:10.0187504-05:00" Source="TransportSend" Type="System.ServiceModel.Channels.BodyWriterMessage" xmlns="http://schemas.microsoft.com/2004/06/ServiceModel/Management/MessageTrace"> <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing"> <s:Header> <a:Action s:mustUnderstand="1">http://schemas.xmlsoap.org/ws/2005/02/trust/RSTR/Issue</a:Action> <a:MessageID>urn:uuid:d733fb2a-255e-40e3-9539-2117fe1ae7bc</a:MessageID> <a:ReplyTo> <a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address> </a:ReplyTo> <a:To s:mustUnderstand="1">http://FimServer.company.local:5725/ResourceManagementService/Alternate</a:To> </s:Header> <s:Body> <t:RequestSecurityTokenResponse Context="uuid-0768ecf0-e5eb-4338-a8d5-d5a80ca42824-1" xmlns:t="http://schemas.xmlsoap.org/ws/2005/02/trust" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"> <t:BinaryExchange ValueType="http://schemas.xmlsoap.org/ws/2005/02/trust/spnego" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" >TlRMTVNTUAADAAAAAQABAGoAAAAAAAAAawAAAAAAAABYAAAAAAAAAFgAAAASABIAWAAAABAAEABrAAAANYqY4gYBsB0AAAAPylIuB7GZpU15B2Z KUjVlDUYASQBNAFAATwBSAFQAQQBMAABN4ajrgFds9dnutyupHTgy</t:BinaryExchange> </t:RequestSecurityTokenResponse> </s:Body> </s:Envelope> </MessageLogTraceRecord> </DataItem> </TraceData> <!-- ### FIM Client --> <DESCRIPTION m="SpnegoTokenProvider completed SSPI negotiation." /> <TraceData> <DataItem> <TraceRecord xmlns="http://schemas.microsoft.com/2004/10/E2ETraceEvent/TraceRecord" Severity="Information"> <TraceIdentifier>http://msdn.microsoft.com/en-US/library/System.ServiceModel.Security.SpnegoClientNegotiationCompleted.aspx</TraceIdentifier> <Description>SpnegoTokenProvider completed SSPI negotiation.</Description> <AppDomain>PwdMgmtProxy.exe</AppDomain> <ExtendedData xmlns="http://schemas.microsoft.com/2006/08/ServiceModel/SpnegoSecurityNegotiationTraceRecord"> <Protocol>Kerberos</Protocol> <ServicePrincipalName>FIMService/FimServer.company.local</ServicePrincipalName> <MutualAuthentication>True</MutualAuthentication> </ExtendedData> </TraceRecord> </DataItem> </TraceData> <!-- ### Open Client --> <DESCRIPTION m="Three exceptions" /> <Exception> <ExceptionType>System.ServiceModel.FaultException, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089</ExceptionType> <Message>The request for security token could not be satisfied because authentication failed.</Message> </Exception> <Exception> <ExceptionType>System.ServiceModel.Security.SecurityNegotiationException, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089</ExceptionType> <Message>The caller was not authenticated by the service.</Message> </Exception> <Exception> <ExceptionType>System.ServiceModel.Security.SecurityNegotiationException, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089</ExceptionType> <Message>The caller was not authenticated by the service.</Message> </Exception> <Description m="Aborted 'System.ServiceModel.Channels.HttpChannelFactory+HttpRequestChannel/62872692'." /> <!-- Same on FIM Client and Open Client --> <Description m="Closing System.ServiceModel.Channels.HttpChannelFactory+HttpRequestChannel/62872692" /> <Description m="Closed System.ServiceModel.Channels.HttpChannelFactory+HttpRequestChannel/62872692" /> <Description m="Disposed: System.ServiceModel.Channels.HttpChannelFactory+HttpRequestChannel/62872692" /> <!-- ### FIM Client --> <DESCRIPTION m="The IssuanceTokenProvider has completed the security negotiation." /> <TraceData> <DataItem> <TraceRecord xmlns="http://schemas.microsoft.com/2004/10/E2ETraceEvent/TraceRecord" Severity="Information"> <TraceIdentifier>http://msdn.microsoft.com/en-US/library/System.ServiceModel.Security.IssuanceTokenProviderEndSecurityNegotiation.aspx</TraceIdentifier> <Description>The IssuanceTokenProvider has completed the security negotiation.</Description> <AppDomain>PwdMgmtProxy.exe</AppDomain> <ExtendedData xmlns="http://schemas.microsoft.com/2006/08/ServiceModel/ClientSecurityNegotiationTraceRecord"> <IssuanceTokenProvider>System.ServiceModel.Security.SpnegoTokenProvider</IssuanceTokenProvider> <ServiceToken> <SessionTokenType>System.ServiceModel.Security.Tokens.BufferedGenericXmlSecurityToken</SessionTokenType> <ValidFrom>2011-03-03T17:52:01.511Z</ValidFrom> <ValidTo>2011-03-04T03:52:01.511Z</ValidTo> <InternalTokenReference>LocalIdKeyIdentifierClause(LocalId = 'uuid-76dda5ba-8fb7-4fc2-8416-ee1e900ef50d-1', Owner = 'System.ServiceModel.Security.Tokens.SecurityContextSecurityToken')</InternalTokenReference> <ExternalTokenReference>SecurityContextKeyIdentifierClause(ContextId = 'urn:uuid:3a25b907-6127-4ec4-a34c-c3303ba2551f', Generation = '')</ExternalTokenReference> <IssuedTokenElementName>SecurityContextToken</IssuedTokenElementName> <IssuedTokenElementNamespace>http://schemas.xmlsoap.org/ws/2005/02/sc</IssuedTokenElementNamespace> </ServiceToken> <Target> <EndpointReference xmlns="http://www.w3.org/2005/08/addressing"> <Address>http://FimServer.company.local:5725/ResourceManagementService/Alternate</Address> <Identity xmlns="http://schemas.xmlsoap.org/ws/2006/02/addressingidentity"> <Spn>FIMService/FimServer.company.local</Spn> </Identity> </EndpointReference> </Target> </ExtendedData> </TraceRecord> </DataItem> </TraceData> <!-- ### Open Client --> <DESCRIPTION m="Failed to open System.ServiceModel.Security.SpnegoTokenProvider" /> <TraceData> <DataItem> <TraceRecord xmlns="http://schemas.microsoft.com/2004/10/E2ETraceEvent/TraceRecord" Severity="Warning"> <TraceIdentifier>http://msdn.microsoft.com/en-US/library/System.ServiceModel.CommunicationObjectOpenFailed.aspx</TraceIdentifier> <Description>Failed to open System.ServiceModel.Security.SpnegoTokenProvider</Description> <AppDomain>/LM/W3SVC/1795037928/ROOT-1-129436545847943576</AppDomain> <Source>System.ServiceModel.Security.WrapperSecurityCommunicationObject/27077418</Source> </TraceRecord> </DataItem> </TraceData>

If I do not use the SPN Identity and add the FIM Service credential to the constructor for my ClientCredentials (my App Pool is using Network Services account to match the Fim Client Proxy service), the Alternate.Put will negotiate and generate the proper "AuthenticationRequiredFault". The RequestSecurityToken is now failing when communicating with the STS endpoint during it's negotiation: "The service does not allow you to log on anonymously" and it is reverting back to <Protocol>NTLM</Protocol> <ImpersonationLevel>Identify</ImpersonationLevel>

If I do not use the SPN Identity and add the FIM Service credential to the constructor for my ClientCredentials (my App Pool is using Network Services account to match the Fim Client Proxy service), the Alternate.Put will negotiate and generate the proper "AuthenticationRequiredFault". The RequestSecurityToken is now failing when communicating with the STS endpoint during it's negotiation: "The service does not allow you to log on anonymously" and it is reverting back to <Protocol>NTLM</Protocol> <ImpersonationLevel>Identify</ImpersonationLevel>

a few questions... sorry if these are lame questions, i am not expert in this area either. why do you need kerb auth? does setting AllowNtlm=false help? where do u see the FIM Password Reset Client is using Kerb instead of NTLM?

a few questions... sorry if these are lame questions, i am not expert in this area either. why do you need kerb auth? does setting AllowNtlm=false help? where do u see the FIM Password Reset Client is using Kerb instead of NTLM?

The server configuration defines the endpoint to use a Security Mode=Message, over a WsHttpContextBinding. I believe the problem come in where the FIM Service uses impersonation to query SQL, but it could very well be a limitation of the WCF proxy in this mode of the binding. All anonymous means to FIM is that it is a Domain Account that is not managed by FIM. What is does not mean is that the credentials are equal to NULL or an account defined as anonymous. Hope that makes sense, and is accurate... If anyone has found that to be incorrect, please correct me.

The server configuration defines the endpoint to use a Security Mode=Message, over a WsHttpContextBinding. I believe the problem come in where the FIM Service uses impersonation to query SQL, but it could very well be a limitation of the WCF proxy in this mode of the binding. All anonymous means to FIM is that it is a Domain Account that is not managed by FIM. What is does not mean is that the credentials are equal to NULL or an account defined as anonymous. Hope that makes sense, and is accurate... If anyone has found that to be incorrect, please correct me.

the reason i suggest you to use AllowNtlm=true is because it's set to true unless requireKerberos=true in config file. that doesn't seem to be the case for the fim pwd client... seems you are getting one step further...

the reason i suggest you to use AllowNtlm=true is because it's set to true unless requireKerberos=true in config file. that doesn't seem to be the case for the fim pwd client... seems you are getting one step further...

afaik, delegation happens usually in the following scenario Client Machine running a client under user context --> IIS Portal --> FIMService The client context/cred is passed to FIMService eventually. that's the double hop that you are talking about In pwd reset, there is no double hop because the client machine doesn't need to send credentials to IIS Portal. You just need to use IIS Portal's running context (usually defined in appPoolIdentity) to talk to FIMService. P.S. FIMService would never access SQL by impersonating the user.

afaik, delegation happens usually in the following scenario Client Machine running a client under user context --> IIS Portal --> FIMService The client context/cred is passed to FIMService eventually. that's the double hop that you are talking about In pwd reset, there is no double hop because the client machine doesn't need to send credentials to IIS Portal. You just need to use IIS Portal's running context (usually defined in appPoolIdentity) to talk to FIMService. P.S. FIMService would never access SQL by impersonating the user.

I need to use Kerberos because my client will be executing remotely from the FIM service. NTLM will fail due to a double-hop. AllowNtlm=false and AllowedImpersonationLevel=Delegate actually break the client. This was corrected by using Brad Turner's fix: http://www.identitychaos.com/2011/02/soap-security-negotiation-with.html If you look in the traces above, the FIM Client's "SpnegoTokenProvider completed SSPI negotiation", you can see the method used in the SPNego trace: <Protocol>Kerberos</Protocol> <ServicePrincipalName>FIMService/FimServer.company.local</ServicePrincipalName> <MutualAuthentication>True</MutualAuthentication> Thanks.

I need to use Kerberos because my client will be executing remotely from the FIM service. NTLM will fail due to a double-hop. AllowNtlm=false and AllowedImpersonationLevel=Delegate actually break the client. This was corrected by using Brad Turner's fix: http://www.identitychaos.com/2011/02/soap-security-negotiation-with.html If you look in the traces above, the FIM Client's "SpnegoTokenProvider completed SSPI negotiation", you can see the method used in the SPNego trace: <Protocol>Kerberos</Protocol> <ServicePrincipalName>FIMService/FimServer.company.local</ServicePrincipalName> <MutualAuthentication>True</MutualAuthentication> Thanks.

how is that double hop? i see only 1 hop during pwd reset, it's an anonymous user.

how is that double hop? i see only 1 hop during pwd reset, it's an anonymous user.

Cool. All I had to do was attach an EndpointIdentity to the EndpointAddress when creating the STS client. Now both the PW Reset and Reset Registration work perfectly. Wow, what a convoluted exchange of messages! Thanks everyone for your help!