Yup, it’s once again the case of an upgrade and transition. As the portals started working on all browsers, I’ve decided to increase the difficulty level – let’s test the machine-name-based address of MIM Portal… Hmph, seems it does not work as intended. ☹
Thus, I have referred to a checklist based on the Microsoft’s guide as it usually sufficed, even during some rockier rides. Among the steps to perform is setting up the SPNs in order for Kerberos to work. Given the nature of the error – failure at logon despite multiple credentials prompt – that is precisely the direction I’ve decided to take. Let me quickly tell you why.
Windows Authentication "In Short"
Whenever our application, remote desktop connection, or a browser wants to authenticate the user, it makes a call to our system. As there are many ways to authenticate, it would either require explicit specification of the method or, the way it is actually resolved in Windows, an interface - Security Support Provider Interface (SSPI) to be precise. Then, this interface decides what sort of Security Support Provider (SSP) should it use – Kerberos, NTLM, Schannel (SSL and TLS protocols) or any other SSP.
The Windows logon prompt suggests that MIM relies on either NTLM or Kerberos. While from the UX perspective both seem quite similar, in reality, they differ profoundly. NTLM relies on challenge/response mechanism – every time a server wants to confirm client identity it makes a call to domain authentication service or looks up local account database. That leaves us with two issues – no way to confirm server’s identity by the client and a lot of requests to Domain Controller (DC) where domain authentication service is located.
The answer to our problems is Kerberos protocol. As the name reference implies, it consists of three components: client, server, and Key Distribution Centre (KDC) located on DC. Unlike in the NTLM case, it is not the server that makes a credentials challenge to the DC, but instead, first the client establishes the relationship with KDC and as a result can securely authenticate itself on the server.
The process works as follows:
Client sends to KDC a Kerberos authentication service request KRB_AS_REQ. This request is needed so that the client does not have to authenticate every time it needs access. Instead, the client requests a ticket-granting ticket (TGT). KRB_AS_REQ contains the following information:
The user principal name.
The name of the account domain.
Pre-authentication data encrypted with the user's key derived from the user's password. This element is of tremendous importance as it prevents a potential attacker from attempting to impersonate the user in order to receive TGT response from KDC with an intent to break its encryption and extract user credentials.
KDC sends to Client a Kerberos authentication service response KRB_AS_REP which is the actual TGT with a limited lifetime (e.g. 10 hours). Even though TGTs are not an approved access to resources, they are very important because users enter their passwords only once throughout the TGT lifetime. KRB_AS_REP contains the following information:
A TGS session key for the user to use with the KDC, encrypted with the user key derived from the user's password. Mark that it is not a TGS key for the resource but a service ticket for the KDC itself.
A TGT for the KDC, encrypted with the TGS key. The TGT includes:
A TGS session key for the KDC to use with the user.
Authorisation data for the user which includes:
The SID for the user's account.
SIDs for security groups which the user is a member of in the domain.
SIDs for universal groups in the enterprise that include either the user or one of the domain groups the user is a member of.
Client sends to KDC a Kerberos ticket-granting service request KRB_TGS_REQ. The client does this to gain access to a service or the local computer, i.e., the request is for approval to access needed resources. KRB_TGS_REQ contains the following information:
The name of the target computer.
The name of the target computer's domain.
The user's TGT.
An authenticator encrypted with the session key the user shares with the KDC.
KDC sends to the Client a Kerberos ticket-granting service response KRB_TGS_REP which contains the TGS ticket needed to access requested resource. KRB_TGS_REP contains the following information:
A session key for the user to share with the computer encrypted with the session key the user shares with the KDC.
The user's service ticket to the computer, encrypted with the computer's secret key which includes:
A session key for the computer to share with the user.
Authorisation data copied from the user's TGT.
Client sends to Server (resource) a Kerberos application server request KRB_AP_REQ, i.e., presents its valid TGS ticket to the server/resource which grants the client access to the resource. KRB_AP_REQ contains the following information:
An application option flag indicating whether to use session key. The setting of this flag is one of the options in configuring Kerberos applications. The user is never asked.
An application option flag indicating whether the client wants mutual authentication.
The service ticket obtained in the TGS exchange.
An authenticator encrypted with the session key for the service.
(Optionally) Server sends to Client a Kerberos application server response KRB_AP_REP. This step is performed when mutual authentication is required, i.e. the client also must confirm the identity of the server. KRB_AP_REP contains the following information:
Current time on Client (from the authenticator).
Millisecond part of client time (from the authenticator).
(Optional) A key to encrypt client sessions with application server.
(Optional) Application-specific sequence number, used if sequence number was specified in the authenticator.
To better visualise the process please refer to this short description and example.
The Credentials Prompt Hint
Well, getting back to our credentials prompt, it is most likely the “Double Hop” problem – a situation which Kerberos delegation should prevent. Let me give you an example – when we open MIM Portal we are prompted for our credentials by the front-end part of the solution. Yet where we actually make all the requests is the MIM Service database (back-end). Normally, MIM Portal would only be able to perform the operations permitted for its service account to execute, so in order to make use of all the privileges granted to us, the delegation is used. In terms of Kerberos, delegation is not so far from our daily cases where we ask our friend or family to do something in our name. In case of authentication, it basically allows a proxy that we use to impersonate us.
Ok, we now know how does the Kerberos operate, but then, why does the delegation not work? The answer to this question is that we need to set up SPNs properly. Well, let’s think of them a bit like postal address for services we want to work with – our client knows that it wants to send its “order” to “Billy Higgins Co”, but without knowing the exact address this wish may not be granted. In terms of MIM, it would be the case of MIM Portal getting the exact location (principal) of the MIM Service. Therefore, we need to define the following parameters in our environment’s “address book”:
Service class – type of service that allows you to call multiple services despite them sharing the same account. In other words, “Billy Higgins Co” may not be the only company in the town. In MIM case it’s HTTP, HTTPS or FIMService class.
Service host - the computer used to host the service – the town where “Billy Higgins Co” operates.
Optionally you may have to also define the port on which the service is running if it differs from the default port of this service class e.g., “FIMService” and port other than 5725 – in case that “Billy Higgins Co” shop has a few floors and instead of finding shoes on second floor as expected, when they are located on the fourth.
The account under which the service operates – for whom should we ask in the shop to get served. In MIM case it’s MIM Service’s service account, MIM Application Pool Service Account, etc.
Let’s Do It!
Now, that we have our theoretical foundations, let’s get to the actual setup. First, we need to get the appropriate permission. Basically, the only requirement is to grant “Validated write to service principal name”, yet this means that we’d have to use Domain Admins member or equivalent membership.
Next stop – IIS app pools section to get the actual account that MIM is using. Now, that we know the name we can use:
setspn -l Contoso\mimpoolcommand (-l stands for list) to view all the SPN registered for the account. Hmph, turns out that double checking pays up – there’s a typo in the machine name. 🤦♀️
Ok, so let’s get it fixed by first removing the incorrect entry and then adding a good one. Quick
setspn –d http/mim.contoso.com Contoso\mimpoollater (-d stands for delete) and we’re ready to add the corrected entries.
“You Are on This Council, But We Do Not Grant You the Rank of Master.”
So, let’s use the SPN addition (-s stands for set) command:
setspn –s http/mim.contoso.com Contoso\mimpoolWait, what?! “Operation failed because SPN value provided for addition/modification is not unique forest-wide”?! Ok, let’s assume that it is not some fanciful access denied and browse (-q stands for query) forest-wide (-f stands for forest-wide) through all (“*” is the wildcard character) the SPN entries related to our machine:
Setspn -f -q */mim.contoso.comNope, no luck, no such entry as ours. Thus, I have resolved to checking the Active Directory Administrative Center (ADAC) for a “recycle bin” - sort of a purgatory for recently deleted objects. Bullseye, there is such a folder, but…I do not have the permissions to open it. 😂
As clearly, I was only a meagre Jedi Knight, I have asked a true Jedi Master (Domain Administrator) to execute the addition command and well, Bob’s your uncle.
“The Dark Side Clouds Everything”
Lovely that the issue was fixed but, what was the actual cause of the problem? I tried confirming the cause with the client, yet to no avail. Thus, I have asked my colleague Vladi, given his enormous expertise in terms of infrastructure, to perform a few tests hoping that maybe he’d come up with some sound explanation as I had only two theories up my sleeve – either it was an SPN being already set on the object in the aforementioned “Recycle Bin” OU which contents I could not read or simply insufficient permissions as even in the Active Directory Users and Computers (ADUC) I could only set Service Principal Name attribute on users, but not computers.
Well, the results of the tests came back with quite an interesting conclusion. You see, it turns out that duplicates’ prevention mechanism does not possess any kind of sixth sense. Thus, if a user performing the SPN setup does not have read permission in a certain OU, “setspn” command would not discover this duplicate – so if, for whatever reason, you’d like to create duplicates of a certain SPN, simply put it into OU, which your account can’t read.
The second theory was also debunked. I have created a standard user account, first tested if I can set up SPNs, but a clear insufficient permissions message popped up. Then, I’ve granted it the “write all” permission, tested again, this time easily setting up the SPN. Myth busted. ☹
The closest to discovering the actual cause, was of course Vladi, for he has conducted one additional test – with two Domain Admins: Full and Limited (the later lacking read permission on “No Permission” OU). Thus, after setting up the SPN in “No Permission” OU using the Full, he successfully set the same SPN in Test OU using the Limited. Then, using the Full he has deleted the SPN on the “No Permission” OU test object and received the same problem encountered on client’s environment - “The operation failed because SPN value provided for addition/modification is not unique forest-wide.”
Conclusion on SPNs
“The operation failed because SPN value provided for addition/modification is not unique forest-wide.” is not some fanciful access denied, but an actual duplicate warning.
When the permissions are insufficient, the system does inform it verbatim.
To duplicate SPNs simply put them into Organisation Unit (OU) where the account establishing the SPNs does not have read permission (thus breaking the underlying service).
Kerberos is fundamental for MIM operability and any application which uses Active Directory and SSPI.
Kerberos provides mutual identity confirmation for both client and server.
Kerberos is far more efficient at work in comparison to NTLM as it relies on tokens, thus limiting the number of calls to Domain Controller.
Without delegation functionality provided by Kerberos, the user’s impersonation by MIM Portal would not work (except for Negotiate SSP setup or all-in-one environment).
SPNs are like address book for services and the KDC is the "operator".
If you need help with anything related to MIM or Active Directory go ahead and contact us today.
Comments