Chicken Soup for the Techie

How an incorrectly configured account lockout policy can give more pain than security.

Abizer — Sun, 21 Apr 2013 10:23:46 GMT

I don't believe this..... we still see environments with Account Lockout policy set with a threshold of 3, with lockout duration of 2 or 5 minutes etc.

Most of them, spend a good amount of money and time addressing these lockouts, and affecting business functions while the addressing them.

I have tried to list down some points that will indicate that the Account lockout policy with a low threshold, like 3 is NOT recommended. In fact an INCORRECTLY configured Account Lockout policy will cause more downtime for the business them help it.

A better security practice it to have a

- Strict password policy + disabled account lockout policy
OR
- Strict password policy + correctly lockout policy with high lockout threshold.

1. Microsoft's recommendations:

http://technet.microsoft.com/en-us/library/cc757692(WS.10).aspx

"Brute force password attacks can be automated to try thousands or even millions of password combinations for any or all user accounts. Limiting the number of failed logons that can be performed nearly eliminates the effectiveness of such attacks.

However, it is important to note that, in contrast, a denial-of-service attack could be performed on a domain that has an account lockout threshold configured. A malicious user could programmatically attempt a series of password attacks against all users in the organization. If the number of attempts is greater than the value of Account lockout threshold, the attacker could potentially lock out every account.

Because vulnerabilities can exist both when this value is configured and when it is not, any organization should weigh their identified threats and the risks that they are trying to mitigate. There are two options to consider for this policy setting:

Set Account lockout threshold to 0. This ensures that accounts will not be locked out. This setting will prevent a denial-of-service attack that intentionally locks out all or some accounts. In addition, this setting helps reduce Help desk calls because users cannot accidentally lock themselves out of their accounts.

Because it will not prevent a brute force attack, a value of 0 should only be chosen if both of the following criteria are explicitly met:

- Password Policy settings force all users to have complex passwords made up of eight or more characters.

- A robust auditing mechanism is in place to alert administrators when a series of failed logons are occurring in the environment.

If these criteria cannot be met, set Account lockout threshold to a high enough value that users can accidentally mistype their password several times before they are locked out of their account, but ensure that a brute-force password attack would still lock out the account. It is advisable to specify a value of 50 invalid logon attempts. Keep in mind, however, that although this setting can reduce the number of Help desk calls by reducing the number of user lockouts, it cannot prevent a denial-of-service attack."

2. Security Configuration Benchmark for Windows environment from ‘Center for Internet Security’

http://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v1.1.0.pdf

“Account lockout threshold
Description:
This control defines the number of failed logon attempts before a user is locked out of an account. It is recommended that this setting be configured as described below:
- For the SSLF profile(s), the recommended value is 10 invalid logon attempt(s).
- For the Enterprise profile(s), the recommended value is 50 invalid logon attempt(s).

Rationale:
Enforcing an account lockout threshold will almost eliminated the effectiveness of automated brute force password attacks and improves the security of a system”

3. Security Configuration Benchmark for Windows environment from “National Security Agency”

http://www.nsa.gov/ia/_files/os/win2003/oldFiles/MSCG-001R-2003.pdf

“Account lockout threshold
Table 2.10: Settings

Domain Member Default Legacy Client Enterprise Client High Security
0 invalid login attempts 50 invalid login attempts 50 invalid login attempts 10 invalid login attempts

The Account lockout threshold setting determines the number of attempts that a user can make to log on to an account before it is locked. Authorized users can lock themselves out of an account by incorrectly entering their password, or by changing their password on one computer while logged on to another computer. The computer with the incorrect password may continuously try to authenticate the user, and because the password it is using to authenticate is incorrect, the user account is eventually locked out. To avoid locking out authorized users, set the account lockout threshold to a high number.”

4. Other popular blogs talking about the same:

http://www.windowsecurity.com/articles/Implementing-Troubleshooting-Account-Lockout.html

5. Below are some numbers that will help you understand the above recommendations better.

**Assuming that you have an account lockout policy with a threshold set to 3, lockout duration of 0 and a password policy with minimum password lenght of 8.

An analysis of your current lockout and password policy is as follows:-

94 possible characters ^ 8 character per password (minimum password length) = 6,095,689,385,410,816 possible passwords.

You guess a password on average half way through a brute force attack = 6095689385410816 / 2 = 3047844692705408 average guesses required.

Because the lockout duration is not defined and accounts are only unlocked by Administrators, we have to pick an average amount of time it might take an account to be unlocked. Let's assume 30 minutes (it's probably longer which will reduce the odds further). Another reason why I'm taking 30 minutes is because if the lockout duration is defined, it would mostly be 30 minutes.

Only 3 guesses i.e. bad passwords (current threshold) can be accepted by AD every 30 minutes (approx. lockout duration) = 1 guess every 10 minutes.

Each password remains the same for 42 days (assuming you have a max password age is 42 days, which is the default), so you have

42 days * 24 hours per day * 60 minutes per hour * 1/10 guesses per minute = 6048 guesses per password lifetime.

The average chance of guessing the password = 6048 guesses per password lifetime / 3047844692705408 average guesses required = 1 in 503942574852 chance of guessing the password in 42 days.

If the lockout threshold were increased from 3 to 10, the chance of guessing the password over the 42 day password lifetime would be 1 in 151182772455. Still quite small!!

Increasing the required password length to 9 with an account lockout threshold of 10 results in the chance of guessing the password over the 42 day password lifetime of 1 in 14211180610828 - a chance 28 times stronger than the earlier policy with threshold of 3.

The above information was about the lockout threshold, now taking of the Account lockout duration,

It is advisable to set Account lockout duration to approximately 30 minutes. A value of 0 specifies that the account will be locked out until an administrator explicitly unlocks it.

To configure the value for this policy setting so that it never automatically unlocks the account might seem like a good idea, because then the admins/helpdesk gets a chance to investigate the cause of lockout, but doing so can increase the number of requests that your organization’s Help desk receives to unlock accounts that were locked by mistake.

To unlock the account automatically after a nn number of minutes, it needs to be set along side auditing so that the administrator gets to know if there are unusual amount of lockouts which need investigation. We recommend that you atleast set the lockout duration to 30 mins. If you reduce the lockout duration further down (like 2 or 5 minutes) to reduce the impact to the end user, you are undoing the purpose of having a account lockout policy and also adding up to the AD replication traffic.

Hope the above information helps you configure the account lockout policy correctly.

regards

Abizer

Possible causes of Authentications failures for federated users in Office 365.

Abizer — Sat, 20 Apr 2013 15:53:00 GMT

Here I’m assuming that we are using ADFS 2.0, for SSO to O365 services:

1. Active Directory replication issue

If AD replication is broken, changes made to user/group may not be in sync across DCs. Between DCs, we may have password/upn/groupmembersip/proxyaddress mismatch that will affect the ADFS response (authentication and claims), as it may go to different DCs for Authentication and LDAP query.

One should start looking at the DCs in the same site as ADFS, probably a ‘Repadmin /showreps’ or a ‘DCdiag /v’ should tell if there is a problem on the DCs, ADFS is most likely to contact.
We can also collect AD replication summary to ensure that AD changes are getting replicated across to all DCs correctly. I have found “repadmin /showrepl * /csv > showrepl.csv” output to be helpful.

2. Account locked out or disabled in Active Directory.

When getting authenticated via ADFS, the end user is not going to get an error stating that the account is locked or disabled.

With the ADFS auditing or Audit logon events enabled – we should be able to find if the authentication failed due to incorrect password, account disabled /locked etc.

Enable ADFS and Logon auditing on the ADFS servers.
1.     Use local or domain policy to enable Success and failure for
o    Computer configuration\Windows Settings\Security setting\Local Policy\Audit Policy
- Audit logon event
- Audit Object Access
2.     Disable the following policy
o    Computer configuration\Windows Settings\Security setting\Local Policy\Security Option – “Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings.” – Disabled

If you want to configure this via advanced auditing, then follow the steps in the link below:
http://technet.microsoft.com/en-us/library/adfs2-troubleshooting-configuring-computers(v=WS.10).aspx#bkmk_ConfigureAuditing

3.     Configure ADFS for auditing:
o    Open the AD FS 2.0 Management snap-in.
To open the AD FS 2.0 Management snap-in, click Start, point to Programs, point to Administrative Tools, and then click AD FS 2.0 Management.
o    In the Actions pane, click Edit Federation Service Properties.
o    In the Federation Service Properties dialog box, click the Events tab.
o    Select the Success audits and Failure audits check boxes
4.     Run ‘Gpupdate /force’ on the server

3. SPN registered incorrectly

Duplicate SPN or SPN registered under the an account other than the ADFS service account.

Ensure that SPN HOST/ADFSservicename is added under the Service account running the ADFS service, in an ADFS Farm setup. For ADFS standalone setup, where the service is running under the ‘Network Service’, the SPN need to be under the server computer account, hosting ADFS.

Ensure that there are not Duplicate SPNs for the ADFS service, as it may cause intermittent authentication failure with ADFS.
Use ‘SETSPN –L serviceaccount’ to list the SPN,
‘SETSPN –A HOST/ADFSservicename serviceaccount’ to Add the SPN
and ‘SETSPN –X’ to check for duplicate SPN.

4. Time sync issue on ADFS server and ADFS proxy

Ensure that the time on the ADFS server and the proxy is in sync, when the time on ADFS server is off by more than 5 minutes, from that on the DCs, we get authentication failures. When the time on ADFS proxy is off sync as compared to ADFS, the proxy trust would get affected and broken, which will start failing the request coming via the ADFS proxy.

5. Duplicate UPNs in AD.

One time I came across an issue where we were able to authenticate via ADFS when using SAMAccountName but failed when using UPN. We eventually found that users were failing to authenticate using UPN because the AD had 2 users with the same UPN. It’s possible to end up with 2 users with the same UPN when users are added and modified using scripting, ADSIedit etc.

In the above scenario, when using UPN the user was getting authenticated against the duplicate user, hence the credential supplied were not getting validated.

You can use queries like below to check if there are multiple objects in AD with same values for an attribute.
“Dsquery * forestroot -filter UserPrincipalName=problemuser_UPN“

Make sure that the UPN on the duplicate user is renamed, so that authentication request with the UPN get validated against the correct Objects.

6. UPN mismatch between Office 365 and On-premise

For a federated user to get authenticated to O365 via a Token from ADFS, we need to ensure that the UPN of the user in the Token issued by ADFS, should be the same as the logon name for the user in O365.

One common cause leading to this issue is when the UPN of a synced user is changed in AD without updating the online directory. Here one can either correct the User’s UPN in AD, to match the related user’s logon name or change the Logon name of the related user in the Online directory, using cmdlet - “Set-MsolUserPrincipalName -UserPrincipalName [ExistingUPN] -NewUserPrincipalName [DomainUPN-AD]”

7. Token signing certificate mismatch between ADFS and Office 365.

This is one of the most command issues. ADFS uses the Token signing certificate to sign the Token sent to the user or application. The trust between the ADFS and O365 is a federated trust based on this token signing certificate, i.e. Office 365 verifies that the Token received is signed using a token-signing certificate of the claim provider (ADFS service) it trust.

Now when the Token signing certificate on the ADFS is changed as a result of Auto Certificate Rollover or Admins intervention (after or before certificate expiry), then the details of the new certificate needs to be updated on the O365 tenant for the federated domain, which does not happen automatically and requires Admin intervention.

While in a broken state when the Primary Token signing certificate on the ADFS is different than what O365 knows about, the Token issued by ADFS is not trusted by O365 and hence the federated user is not allowed to logon.

We can use ‘Get-MsolFederationProperty -DomainName <domain>’ to dump the federation property on ADFS and O365. Here you can compare the TokenSigningCertificate thumbprint, to check if O365 tenant configuration for your federated domain is in sync with ADFS. If you find a mismatch in the Token-Signing certificate configuration, use the following command to update it, “Update-MsolFederatedDomain -DomainName <domain> -SupportMultipleDomain”

You can also run the below tool to schedule a task on the ADFS server that will monitor for the Auto-certificate rollover, of the Token signing certificate and update O365 tenant automatically.

Microsoft Office 365 Federation Metadata Update Automation Installation Tool
http://gallery.technet.microsoft.com/scriptcenter/Office-365-Federation-27410bdc

Verify and manage single sign-on with AD FS
http://technet.microsoft.com/en-us/library/jj151809.aspx

8. ADFS proxy trust with ADFS service, might be BROKEN.

During the ADFS proxy configuration wizard, we provide a domain user account to authenticate with ADFS service and establish Trust between ADFS service and ADFS proxy. Later, the AD FS proxy server periodically renews the proxy trust token with the AD FS Federation Service to maintain AD FS proxy server in a working state. By default AD FS proxy server tries to renew proxy trust token every 4 hours.

For a number of reason, the ADFS proxy trust may get broken, like, Time sync issues, Problem with ADFS server, connectivity issues with ADFS service etc. When this happens you should see more errors (mainly 364) under the ADFS 2.0 > Admin event log. In this scenario, you will be able to authenticate with ADFS, bypassing the proxy.

Quick method to reset the ADFS proxy trust with backend is by re-running the ADFS proxy configuration wizard. If you see the event 391 followed by 245 then we are good on the proxy.

Troubleshooting federation server proxy problems with AD FS 2.0
http://technet.microsoft.com/en-us/library/adfs2-troubleshooting-federation-server-proxy-problems%28WS.10%29.aspx

9. Issuance Authorization claims rules in RP, denying access to user.

On the ADFS Relying party Trust, you can configure the Issuance Authorization rules that can be used to control whether an authenticated user should be issued a token for an Relying Party. We can use the claims issued to this user to make that decision like DENY access to a user if he is a part of a group (group being pulled up as a claim).

If certain federated user are unable to get through via ADFS, you may want to check the “Issuance Authorization rules” for the Office 365 RP and check if it has ‘PERMIT All’. If not, go through the custom authorization rules to check if the condition in that rule will evaluate true for the affected user.

Limiting Access to Office 365 Services Based on the Location of the Client
http://technet.microsoft.com/en-us/library/hh526961(v=ws.10).aspx

Understanding Claim Rule Language in AD FS 2.0
http://social.technet.microsoft.com/wiki/contents/articles/4792.understanding-claim-rule-language-in-ad-fs-2-0.aspx

10. “Issuance Transform claim” rules for the Office 365 RP not configured correctly, in a scenarios where you have multiple TLD (Top level domain). You might have issues login in if ‘Supportmultipledomain’ switch was not used when creating and updating RP trust with O365

SupportMultipleDomain switch, when managing SSO to Office 365
http://blogs.technet.com/b/abizerh/archive/2013/02/06/supportmultipledomain-switch-when-managing-sso-to-office-365.aspx

11. Stale cached credentials in Windows Credential Manager

At times when login in from a workstation to the portal or using outlook, when being prompted for credentials, we might have selected save credentials/password, which in turn may have saved the credentials for the target (O365 or ADFS service), in the Windows Credentials manager (Control Panel\User Accounts\Credential Manager). This should help prevent credentials prompt for some time, but may cause a problem after the user password has changed and the credentials manager is not updated. Then you always end up sending the stale credentials to the ADFS service and fail to authenticate.

Removing or updating the cached credentials, in Windows Credential Manager may help.

12. Connectivity issues, when connecting via firewall/reverse proxy > ADFS proxy > ADFS service

We might not be able to authenticate a federated user if we cannot reach the ADFS proxy or ADFS server via the ADFS proxy. Might be an issue with the external firewall not routing traffic to the ADFS proxy from the Internet. Might be the load balancer managing traffic to the ADFS proxy servers or ADFS service.
Communication issue for some time between the ADFS proxy and ADFS service may have caused the ADFS proxy trust renewals to fail, breaking the Trust. Rerunning of the ADFS proxy configuration may help in this case

It could also be a problem with DNS name resolution for ADFS service

13. ADFS service account does not have READ access to on the ADFS token signing certificate’s private key.

a. When you add a new Token-Signing certificate, you receive a warning reading: "Ensure that the private key for the chosen certificate is accessible to the service account for this Federation Service on each server in the farm":
b. Click Start, Run, type MMC.exe, and press Enter
c. Click File, Add/Remove Snap-in
d. Double-click Certificates
e. Select Computer account and click Next
f. Select Local computer and click Finish
g. Expand Certificates (Local Computer), expand Personal, and select Certificates
h. Right-click your new Token-Signing certificate, select All Tasks, and select Manage Private Keys
i. Add Read access for your AD FS 2.0 service account and click OK
j. Close the Certificates MMC

14. “Extended Protection” for Windows Authentication is enabled for ADFS/LS – may cause issues with specific browsers

At times you may see ADFS repeatedly prompting for credentials, this could be related to “Extended protection” that is enabled for Windows Authentication for the ADFS/LS application, in IIS
When Extended Protection for Authentication is enabled, authentication requests are bound to both the Service Principal Names (SPN) of the server to which the client tries to connect and to the outer Transport Layer Security (TLS) channel over which Integrated Windows Authentication happens. Extended protection enhances the existing Windows Authentication functionality to mitigate authentication relay or "man in the middle" attacks. Certain browsers/fiddler cannot work with “Extended protection”, it would throw repeated prompts followed by access denied. Disabling “Extended protection” helps is such scenario.

Browser Issues with Extended Protection for Authentication
http://technet.microsoft.com/en-us/library/hh852537.aspx

AD FS 2.0: Continuously Prompted for Credentials While Using Fiddler Web Debugger
http://social.technet.microsoft.com/wiki/contents/articles/1426.ad-fs-2-0-continuously-prompted-for-credentials-while-using-fiddler-web-debugger.aspx

15. Lastly if none of the above causes are true, then create a support case with Microsoft and ask them to check if the User account shows consistent under the O365 tenant.

More info

Error message from AD FS 2.0 when a federated user signs in to Office 365: "There was a problem accessing the site"
http://support.microsoft.com/kb/2383983/EN-US

A federated user is repeatedly prompted for credentials when he or she connects to the AD FS 2.0 service endpoint during Office 365 sign-in
http://support.microsoft.com/kb/2461628/EN-US

Regards

Abizer

More information about SSO experience when authenticating via ADFS

Abizer — Thu, 11 Apr 2013 08:13:00 GMT

Common understanding about SSO:

Which may mean user enters username/password once, and does not need to reenter again during the same session.

It may also mean that when accessing different application/resources, we need not enter different credentials, but enter the same ones.

AD FS 2.0 enables identity federation, extending the notion of above centralized authentication, authorization, and single sign-on to Web applications and services located virtually anywhere.

As previously introduced, identity federation relies on standards-based protocols to establish federation trusts between claims providers and relying parties, facilitating secure access to Web applications and services across security boundaries.

For an organization, AD FS 2.0 provides corporate users with a rich federated experience and seamless access to resources located:

- Inside the corporate intranet;

- Outside the corporate network in a corporate perimeter network, extranet and/or in the Cloud, for example in the Microsoft Windows Azure platform, the Microsoft’s Platform as a Service (PaaS) offering;

- At the perimeter networks of partner organizations that have made resources available to the considered organization’s users;

- In the Cloud with Software as a Service (SaaS) vendors that support federated identity, for example, Microsoft with its Microsoft Office 365 offerings in the context of this paper.

While ADFS service provides Single Sign On (SSO) experience, below are a few points we need to be aware of to make the experience seamless. It should also help avoid confusion around Single Sign On when working with ADFS.

Common pre-requisites

- Although any current Web browser with JScript enabled can work as an ADFS client, only Internet Explorer, Mozilla Firefox, and Safari on Apple Macintosh have been tested by Microsoft. For performance reasons, we highly recommend that JScript be enabled.

- Cookies must be enabled, or at least trusted, for the federation servers and Web applications that are being accessed. It’s using Cookies that we prevent repeated logons to a service, within the same session. Cookies can also prevent repeated home realm discovery prompts with that are more claim providers on the STS. The authentication cookie is signed but not encrypted, which is one reason why use of TLS/SSL is mandatory in ADFS.

SSO when on the intranet from a domain joined machine, logged in with a domain credential:

To ensure the user is not prompted for his logged in credentials again, when accessing ADFS from intranet, the following configuration needs to be in place.

- In Internal DNS should resolve the ADFS service name to the backend ADFS servers or Load balanced IP for ADFS service. Domain Name System (DNS) resolution of the AD FS 2.0 service endpoint should not be performed through CNAME record lookup, instead we should add a A record for the ADFS service name.

- The Web-proxy configured on the client should be configured to bypass proxy, for request to ADFS URL

- The ADFS URL should be added to the IE > Security >Intranet zones > sites. This is done because IE > security > Local Intranet > Security Settings > user authentication – logon is configured to use the logged in credentials for Intranet sites.

- Ensure that IE > advanced > 'Enable Integrated Windows Authentication' is checked.

- Ensure that an SPN ‘HOST/ADFSservicename’ is registered for the ADFS service under the ADFS farm service account, to allow Kerberos authentication.

- The default authentication configuration for the ADFS service (in C:\inetpub\adfs\ls\web.config) is Integrated Windows Authentication, ensure that it has not been changed to Form-based Authentication.

http://social.technet.microsoft.com/wiki/contents/articles/1600.ad-fs-2-0-how-to-change-the-local-authentication-type.aspx

- The credentials prompt can only be avoided when you are accessing the cloud service using the same account used to logon to the workstation.

- If a user chooses to save his credentials in the 'credentials manager' (By selecting save password checkbox in the credential prompt) for use with ADFS, that saved credentials will only provide an SSO experience till the user changes his password. If the credential manager is not updated with the new password of the user, it will continue to use old user credentials and prompt the user for good credentials, after a number of failed attempts with the stale saved credentials.

- If user A wants to access User B’s mailbox, user B’s credentials has to be provided and ADFS will prompt you for user B credentials because it has no ways of guessing it by itself. But once User B’s credentials has been provided and the user is authenticated, the Browser may cache the
user B’s credentials and would reuse it when the same instance of IE is used to access the same application or authenticate via the same ADFS service.

- ADFS and most of the web applications do write cookies on the client machine after being authenticated/authorized, these cookies may be session specific or may be valid across sessions. If these cookies are valid, and presented again to the application /ADFS, by the browser, the user is allowed in without repeated authentication. For example, after being logged into Sharepoint or O365, we write a few AUTH related session cookies on the client. These cookies are presented again, if you access a link in the web application that opens up another page in the same windows or another tab, sharing the same session cookies. These session based cookies should expire once you sign-out of the application/ ADFS, post which the user may need to authenticate again.

SSO when accessing resources from over the Internet or an External network:

- When getting redirected to ADFS for authentication, our request hit the ADFS proxy (assuming you have the ADFS proxy configured, a workgroup server in DMZ network), which presents us a Form asking for user credentials.

- The default configuration on ADFS proxy is Form-Based Authentication, where the user is presented with a webpage asking for credentials. Since we use SSL to connect to ADFS proxy and passing credentials, the communication with the server is secure and encrypted. This authentication request with credential is later passed to the ADFS server over a SSL session, for getting the user authenticated.

- The reason why we stick to form based authentication when going via the proxy is because it just requires the SSL port 443 to be exposed. We cannot do Windows Integrated Authentication over the internet, because the ports and services required for it cannot be exposed to the internet.

- Apart from this, when accessing a resource from over the internet (using a home computer or public computer), using the logged in credentials does not help because you may not be logged in with domain credentials. Hence you may get prompted for credentials.

Another alternative to the form-based authentication is the TLS (certificate based authentication), where the user certificate which represents the user credentials need to be present on the client workstation.

- This configuration cannot be selectively done for a set of user but need to be set as the default authentication method on ADFS proxy.

- The challenge here is that a user will only get authenticated via ADFS when he has the correct certificate, else access denied. So you have to deploy certificates to all users who access the close service via the internet.

- In this scenario too, if the client machine has multiple certificates in the user store, the user will be prompted to choose a certificate.

When outside the corpnet network, the user can choose to VPN in to the corpnet or use DirectAccess to connect to corpnet and then access ADFS as if they are connected to Intranet.

At times you may see ADFS repeatedly prompting for credentials, this could be related to “Extended protection” that is enabled for Windows Authentication for the ADFS/LS application. In IIS when Extended Protection for Windows Authentication is enabled, authentication requests are bound to both the Service Principal Names (SPN) of the server to which the client tries to connect and to the outer Transport Layer Security (TLS) channel over which Integrated Windows Authentication happens. Extended protection enhances the existing Windows Authentication functionality to mitigate authentication relay or "man in the middle" attacks. Certain browsers/fiddler cannot work with “Extended protection”, it would throw repeated prompts followed by access denied. Disabling “Extended protection” helps is such scenario.

Browser Issues with Extended Protection for Authentication
http://technet.microsoft.com/en-us/library/hh852537.aspx

http://social.technet.microsoft.com/wiki/contents/articles/1426.ad-fs-2-0-continuously-prompted-for-credentials-while-using-fiddler-web-debugger.aspx

More references:

Below some references to related to SSO in Office 365 environment with help of ADFS 2.0

Office 365 Single Sign-On with AD FS 2.0 whitepaper
http://www.microsoft.com/en-us/download/details.aspx?id=28971

A federated user is prompted unexpectedly to enter their credentials when they access an Office 365 resource
http://support.microsoft.com/kb/2535227

A federated user is repeatedly prompted for credentials when he or she connects to the AD FS 2.0 service endpoint during Office 365 sign-in
http://support.microsoft.com/kb/2461628

Regards

Abizer

Information about Email addresses assigned to a licensed user in O365

Abizer — Mon, 08 Apr 2013 16:25:33 GMT

The Onmicrosoft.com email address gets stamped the time an Exchange license is assigned to the user. When creating the Onmicrosoft.com email address for the user, we look at the mailNickname attribute value for this user on the cloud.
The mailNickName value is derived from 3 places:

o From AD, if the mailNickName attribute is present and populated with a value. This mailNickName attribute gets added as a part of extending the AD schema when preparing for Exchange.

o From the Primary SMTP address specified in AD (i.e. the Mail and ProxyAddresses attributes). If Abizer.Haz@contoso.com is set as primary SMTP address, “Abizer.Haz” will be used as the mailNickname on the cloud side.

o If the above 2 values are not present, we rely on the UPN to derive the mailNickname. If UPN is Abizerh@contoso.com, then the mailNickname would be “Abizerh”.

The Onmicrosoft.com email address added initially, will always stay with the user, while he is on the cloud.

The OTHER time the Onmicrosoft.com email added is added to the user is when:

The user has a loginname with xx.onmicrosoft.com suffix (like abizerh11@contoso.onmicrosoft.com) and the loginname is changed to another login name with the same xx.onmicrosoft.com suffix (Abizerh22@contoso.onmicrosoft.com),
we add a new smtp address that matches the new loginname. So now the user would have 2 Onmicrosoft email addresses i.e Abizerh11@contoso.onmicrosoft.com and Abizerh22@contoso.onmicrosoft.com.

- When a user on cloud with login name userxx@verifieddomain.com (Eg: user1@contoso.com) changes his loginname on cloud to userxx@xxx.onmicrosoft.com, we add a new smtp address that matches the new loginname.

**We ensure that for every user licensed for Exchange, we have a smtp address for the user that matches his or her UPN.

Example:

For a user UserA@contoso.com UPN, they would have a proxyaddress UserA@contoso.com

-> When the user UPN / login name changes to UserB@contoso.com, the proxy addresses would get updated to include UserB@contoso.com

**Same goes for a user with login name UserC@contoso.onmicrosoft.com.

You cannot update the Onmicrosoft.com email addressed for a Dirsync-ed user, by adding the Onmicrosoft.com email address to the proxyaddress list of the AD user.

After assigning the Exchange license to the user, once his mailbox is created, if you plan to modify the prefix of the email addresses by modifying the mailNickName attribute of the AD user and syncing it to the cloud, it does not affect the
email address for the user on cloud. This does not help even if you remove and assign the Exchange license with the new mailNickname.

Email addresses that will not get synced from on-premise AD to Cloud for a user:

Email with suffix for which you don’t have a verified domain under your tenant.

Email addresses which are already present for a different user, contact or groups on cloud.

Email with onmicrosoft.com in the suffix.

Method used to modify the login name of users under the tenant, that trigger updated to the proxyaddresses:

- Set-MsolUserPrincipalName -UserPrincipalName [ExistingUPN] -NewUserPrincipalName [NewUPN]

Cmdlet used to update the Email address directly:

- Set-Mailbox -Identity "joe@contoso.com" -EmailAddresses @("SMTP:joe@contoso.com";"smtp:joe123@contoso.onmicrosoft.com";"sip:joe1@contoso.com")

Regards

Abizer

SupportMultipleDomain switch, when managing SSO to Office 365

Abizer — Wed, 06 Feb 2013 03:51:00 GMT

Use of SupportMultipleDomain switch, when managing SSO to Office 365 using ADFS

When a SSO is enabled for O365 via ADFS, you should see the Relying Party (RP) trust created for O365.

Commands that would create the RP trust for O365 are below:

`New-MsolFederatedDomain -DomainName<domain>`

OR

`Convert-MsolDomainToFederated -DomainName <domain>`

OR

`Update-MSOLFederatedDomain -DomainName <domain>`

**`Update-MSOLFederatedDomain as the name suggest if you update an existing federation trust between ADFS and O365, In this process it will update or recreate the RP on ADFS side.`

The RP trust created above comes with 2 claims rules

`'Get-MsolFederationProperty -DomainName <domain>' for the federated domains shows that the “FederationServiceIdentifier” was the same for source ADFS and O365 i.e. the`http://STSname/adfs/Services/trust

With the ADFS rollup 1 update, we added the following functionality:

Support for Multiple Top Level Domains

“Currently, Microsoft Office 365 customers who utilize single sign-on (SSO) through AD FS 2.0 and have multiple top level domains for users' user principal name (UPN) suffixes within their organization (for example, @contoso.com or @fabrikam.com) are required to deploy a separate instance of AD FS 2.0 Federation Service for each suffix. There is now a rollup for AD FS 2.0 (http://support.microsoft.com/kb/2607496) that works in conjunction with the “SupportMultipleDomain” switch to enable the AD FS server to support this scenario without requiring additional AD FS 2.0 servers.”

Commands that can be used to create the RP trust for O365, to support multiple top level domain:

`New-MsolFederatedDomain -DomainName` `<domain>` `-SupportMultiDomain`

OR

`Update-MSOLFederatedDomain -DomainName <domain>` `-`SupportMultipleDomain

OR

`Convert-MsolDomainToFederated -DomainName <domain>` `-`SupportMultipleDomain

`Post using SupportMultipleDomain switch, the following 2 changes take place:`

`1. 'Get-MsolFederationProperty -DomainName <domain>' on the federated domains now shows that the “FederationServiceIdentifier” is` `different` `for ADFS and O365. Every federated domain will have the “FederationServiceIdentifier” as` http://<domainname>/adfs/services/trust/ whereas the ADFS configuration still has http://STSname/adfs/Services/trust`.`

Due to this mismatch in configuration, we need to ensure that when a token is sent to O365 the issuer mentioned in it, is the same as one configured for the Domain in O365. Therefore the SupportMultipleDomain also adds the following 3rd claim rule in the O365 RP, under ADFS. If not you will get the error below:

So what does this 3^rd claim rule added by SupportMultipleDomain to the RP trust for O365, do

Default 3^rd rule:

c:[Type
== "http://schemas.xmlsoap.org/claims/UPN"]

=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", Value = regexreplace(c.Value, ".+@(?<domain>.+)", "http://${domain}/adfs/services/trust/"));

This rule uses the suffix value of user’s UPN and uses that to generate a new claim called Issuerid. For example, for a user User1@contoso.com , the issuerID in his Token will be http://contoso.com/adfs/services/trust/.

Using fiddler, we can trace the token being passed to login.microsoftonline.com/login.srf. After copying the token passed in wresult, paste the content in notepad and save that file as .xml.

Later you can open the token saved as .xml file using IE and see its content.

It’s interesting to note that the though this rule issues 'Issuerid' claim, we don’t see this claim in the response token, in fact we see the “Issuer” attribute modified to the newly composed value.

<saml:Assertion MajorVersion="1" MinorVersion="1"
AssertionID="_2546eb2e-a3a6-4cf3-9006-c9f20560097f" Issuer="http://contoso.com/adfs/services/trust/" IssueInstant="2012-12-23T04:07:30.874Z" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">

NOTE: If –SupportMultipleDomain is used without the ADFS rollup 1 or 2 installed. You will see that the response token generated by ADFS has BOTH the Issuer=”http://STSname/adfs/Services/trust” and the claim “Issuerid” with the composed value as per the 3^rd claim rule.

<saml:Assertion MajorVersion="1" MinorVersion="1"
AssertionID="_2546eb2e-a3a6-4cf3-9006-c9f20560097f" Issuer="http://STS.contoso.com/adfs/services/trust/" IssueInstant="2012-12-23T04:07:30.874Z" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">

…

<saml:Attribute
AttributeName="issuerid" AttributeNamespace="http://schemas.microsoft.com/ws/2008/06/identity/claims"><saml:AttributeValue>http://contoso.com/adfs/services/trust/</saml:AttributeValue>
</saml:Attribute>

- This will again lead to error “Your organization could not sign you in to this service”

Support for Sub domains

“It is important to note that the “SupportMultipleDomain” switch is not required when you have a single top level domain and multiple sub domains. For example if the domains used for upn suffixes are @sales.contoso.com, @marketing.contoso.com
and @contoso.com and the top level domain (contoso.com in this case) was added first and federated then you don’t need to use the “SupportMultipleDomain” switch. This is because these sub domains are effectively managed within the scope of the parent and a single AD FS server can be utilized to handle this already.”

If however, you have multiple top level domains (@contoso.com and @fabrikam.com) and these domains also have sub domains (@sales.contoso.com and @sales.fabrikam.com) the “SupportMultipleDomain” switch will not work for the sub domains and these users will not be able to login.

Why will this switch not work, in the above scenario?

Answer:

- For child domain, sharing the same namespace, we don’t federate them separately. The federated root domain covers the child as well, which mean that the federationServiceIdentifier value for the child domain will also be the same as that of parent i.e. http://contoso.com/adfs/services/trust/

- But the 3^rd claim rule which ends up picking the UPN suffix for the user to compose the Issuer value ends up with http://Child1.contoso.com/adfs/services/trust/, again causing a mismatch and hence the error “Your organization could not sign you in to this service”

To resolve this, we can modify the 3^rd rule such that it ends up generating an Issuer value that matches “FederationServiceIdentifier” for the domain at O365 end. 2 different rules that can work in this scenario are below. This rule just picks up the root domain from the UPN suffix to compose the Issuer value. For a UPN suffix child1.contoso.com, it will still generate an Issuer value of http://contoso.com/adfs/services/trust/ instead of http://Child1.contoso.com/adfs/services/trust/ (with default rule)

Customized 3^rd rule

Rule 1:

c:[Type == "http://schemas.xmlsoap.org/claims/UPN"]

=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", Value = regexreplace(c.Value, "^((.*)([.|@]))?(?<domain>[^.]*[.].*)$", "http://${domain}/adfs/services/trust/"));

Rule 2:

c:[Type
== "http://schemas.xmlsoap.org/claims/UPN"]

=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", Value = regexreplace(c.Value, “^((.*)([.|@]))?(?<domain>[^.]*.(com|net|co|org)(.\w\w)?)$”, “http://${domain}/adfs/services/trust/”));

Note:

The rules above may not apply to all scenarios, but can be customized to ensure that the Issuerid value matches “FederationServiceIdentifier” for the domain added/federated at O365 end.

The mismatch of federationServiceIdentifier between ADFS and O365 for a domain can also be corrected by modifying the “federationServiceIdentifier” for the domain at O365 end, to match the “federationServiceIdentifier” for ADFS. But the federationServiceIdentifier can only be configured for ONE federated domain and not all.

- Set-MSOLDomainFederationSettings -domainname Contoso.com –issueruri http://STS.contoso.com/adfs/services/trust/

More information that should help you write your own claim rules.

The Role of the Claim Rule Language
http://technet.microsoft.com/en-us/library/dd807118(WS.10).aspx

Understanding Claim Rule Language in AD FS 2.0
http://social.technet.microsoft.com/wiki/contents/articles/4792.understanding-claim-rule-language-in-ad-fs-2-0.aspx#General_Syntax_of_the_Claim_Rule_Language

Regular Expressions
http://technet.microsoft.com/en-us/library/hh440535.aspx

Hope this info helps

Cheers

Abizer

Kerberos Error KDC_ERR_POLICY while trying to access a resource in the Trusted forest (Forest Trust)

abizer_hazrat — Wed, 18 May 2011 17:03:30 GMT

Symptoms

Forest1 = 2003dom.local

Forest2 = 2008dom.local

2-way Forest Trust created between them, with forest level authentication.

**User from Forest2 access a server in Trusted Forest1 i.e. \\2003-dc1.2003dom.local

Here is what I see in the network capture on the source machine in Forest2

2008-dc1.2008dom.local 2003-dc1.2003dom.local KerberosV5:TGS Request Realm: 2003DOM.LOCAL Sname: cifs/2003-dc1.2003dom.local
2003-dc1.2003dom.local 2008-dc1.2008dom.local KerberosV5 KerberosV5:KRB_ERROR - KDC_ERR_POLICY (12)

After this Kerberos error, we fallback to NTLM. User gets prompted for credentials and when the credential for a user in Forest2 is provided, that fails too.

**From Forest1 when accessing a server on Forest2 we see Kerberos error below. Here instead of the user getting a referral TGT for the trusted forest krbtgt/2008dom.local, we just see the local domain DC replying with error stating it could not find the service principal name. It never feels the need to go outside its forest.

2003-MEM1 2003-dc1.2003dom.local KerberosV5 KerberosV5:TGS Request Realm: 2003DOM.LOCAL Sname: cifs/2008-dc1.2008dom.local
2003-dc1.2003dom.local 2003-MEM1 KerberosV5 KerberosV5:KRB_ERROR - KDC_ERR_S_PRINCIPAL_UNKNOWN (7)

Fallback to NTLM works:

2003-MEM1 2008-dc1.2008dom.local SMB SMB:C; Session Setup Andx, NTLM NEGOTIATE MESSAGE
2008-dc1.2008dom.local 2003-MEM1 SMB SMB:R; Session Setup Andx, NTLM CHALLENGE MESSAGE - NT Status: System - Error, Code = (22) STATUS_MORE_PROCESSING_REQUIRED
2003-MEM1 2008-dc1.2008dom.local SMB SMB:C; Session Setup Andx, NTLM AUTHENTICATE MESSAGE, Domain: 2003DOM, User: AdministratoR, Workstation: 2003-MEM1
2008-dc1.2008dom.local 2003-MEM1 SMB SMB:R; Session Setup Andx
2003-MEM1 2008-dc1.2008dom.local SMB SMB:C; Tree Connect Andx, Path = \\2008-DC1.2008DOM.LOCAL\IPC$, Service = ?????
2008-dc1.2008dom.local 2003-MEM1 SMB SMB:R; Tree Connect Andx, Service = IPC

Cause

We found that Forest1 had domain suffix for the trusted forest (in this case 2008dom.local) added to the Alternate UPN suffix list for the forest.

This had caused the name suffix for *.2008dom.local in the forest trust in the Forest1 (2003dom.local) go into a DISABLED state showing a conflict.

This also explains why the forest1 (2003dom.local) was throwing the Kerberos error KDC_ERR_POLICY, when issuing tickets across forest.

Resolution

- Remove Alternate UPN suffix from the Forest1, which is similar to the name suffix used in the Trusted domain/forest.

- After this change, we need to validate the trust (both incoming and outgoing) to update the UPN removal to the trust objects in both forest.

- Lastly, we need to Enable the Name suffix for the trusted domain using Trust properties > Name Suffix Routing tab, in Forest1.

Change the routing status of a name suffix

http://technet.microsoft.com/en-us/library/cc781019(WS.10).aspx

Routing name suffixes across forests

http://technet.microsoft.com/en-us/library/cc784334(WS.10).aspx

Tracing down user and computer account deletion in Active Directory

abizer_hazrat — Thu, 27 May 2010 07:40:37 GMT

In order to find out about user and computer account deletion, you must keep the “Account Management” auditing enabled, beforehand.

The Account Management auditing needs to be enabled as follows:

At Domain Controller OU level, edit the “Default Domain Controller” policy to enable auditing:

Computer configuration > Windows settings > Security settings > Local Policies > Audit Policies

- Enable Success for “Audit Account Management”

Ensure that the GPO application is working on all DCs.

After the User/Computer account deletion occurs, the steps you need to follow to get more information about user or computer account deletion.

Note: The below steps need to be done before you restore the deleted object:

1. Dump the deleted objects in “Deleted objects” container.

- Ldifde –x –d “CN=Deleted Objects,DC=domain,DC=com” –f Deletedobj.ldf

2. Search the Deletedobj.ldf file for the AD object that got deleted. The name of this object would have a GUID appended to it. Copy the DN attribute value of this object.

=========================================================

Extract from the LDF file above showing the deleted user object (TestUser):

dn: CN=TestUser\0ADEL:aff006d7-7758-4b24-bb53-6e8f1a87834e,CN=Deleted Objects,DC=2008dom,DC=local

changetype: add

objectClass: top

objectClass: person

objectClass: organizationalPerson

objectClass: user

cn:: dGVydApERUw6YWZmMDA2ZDctNzc1OC00YjI0LWJiNTMtNmU4ZjFhODc4MzRl

distinguishedName:

CN=TestUser\0ADEL:aff006d7-7758-4b24-bb53-6e8f1a87834e,CN=Deleted Objects,DC=2008d

om,DC=local

instanceType: 4

whenCreated: 20100526065020.0Z

whenChanged: 20100526065039.0Z

uSNCreated: 448479

isDeleted: TRUE – This attribute is set to true when an object is deleted.

uSNChanged: 448492

name:: dGVydApERUw6YWZmMDA2ZDctNzc1OC00YjI0LWJiNTMtNmU4ZjFhODc4MzRl

objectGUID:: 1wbwr1h3JEu7U26PGoeDTg==

userAccountControl: 512

objectSid:: AQUAAAAAAAUVAAAARb3/5MeOM1el+HeXPwgAAA==

sAMAccountName: TestUser

lastKnownParent: CN=Users,DC=2008dom,DC=local

=========================================================

3. Get the output of the following command on any DC.

- Repadmin /Showmeta “DN of the deleted object” > Delshowmeta.txt

Eg:

Repadmin /Showmeta “CN=TestUser\0ADEL:aff006d7-7758-4b24-bb53-6e8f1a87834e,CN=Deleted Objects,DC=2008dom,DC=local” > Delshowmeta.txt

4. While reviewing the output in Delshowmeta.txt, check the “Org. Time/Date” and the “Originating DC” value of isDeleted attribute of this object. These values will tell you the time of deletion of this object and the source DC used to delete object, respectively.

=========================================================

Output of Showmeta:

Loc.USN Originating DSA Org.USN Org.Time/Date Ver Attribute

======= =============== ========= ============= === =========

448479 SiteA\2008-DC2 448479 2010-05-26 12:20:20 1 objectClass

448492 SiteA\2008-DC2 448492 2010-05-26 12:20:39 2 cn

448492 SiteA\2008-DC2 448492 2010-05-26 12:20:39 2 givenName

448479 SiteA\2008-DC2 448479 2010-05-26 12:20:20 1 instanceType

448479 SiteA\2008-DC2 448479 2010-05-26 12:20:20 1 whenCreated

448492 SiteA\2008-DC2 448492 2010-05-26 12:20:39 2 displayName

448492 SiteA\2008-DC2 448492 2010-05-26 12:20:39 1 isDeleted

448479 SiteA\2008-DC2 448479 2010-05-26 12:20:20 1 nTSecurityDescriptor

448492 SiteA\2008-DC2 448492 2010-05-26 12:20:39 2 name

448488 SiteA\2008-DC2 448488 2010-05-26 12:20:20 4 userAccountControl

448492 SiteA\2008-DC2 448492 2010-05-26 12:20:39 2 codePage

448492 SiteA\2008-DC2 448492 2010-05-26 12:20:39 2 countryCode

448481 SiteA\2008-DC2 448481 2010-05-26 12:20:20 2 dBCSPwd

448480 SiteA\2008-DC2 448480 2010-05-26 12:20:20 1 logonHours

448492 SiteA\2008-DC2 448492 2010-05-26 12:20:39 3 unicodePwd

448492 SiteA\2008-DC2 448492 2010-05-26 12:20:39 3 ntPwdHistory

448492 SiteA\2008-DC2 448492 2010-05-26 12:20:39 4 pwdLastSet

448492 SiteA\2008-DC2 448492 2010-05-26 12:20:39 2 primaryGroupID

448492 SiteA\2008-DC2 448492 2010-05-26 12:20:39 2 supplementalCredentials

448479 SiteA\2008-DC2 448479 2010-05-26 12:20:20 1 objectSid

448492 SiteA\2008-DC2 448492 2010-05-26 12:20:39 2 accountExpires

448492 SiteA\2008-DC2 448492 2010-05-26 12:20:39 3 lmPwdHistory

448479 SiteA\2008-DC2 448479 2010-05-26 12:20:20 1 sAMAccountName

448492 SiteA\2008-DC2 448492 2010-05-26 12:20:39 2 sAMAccountType

448492 SiteA\2008-DC2 448492 2010-05-26 12:20:39 2 userPrincipalName

448492 SiteA\2008-DC2 448492 2010-05-26 12:20:39 1 lastKnownParent

448492 SiteA\2008-DC2 448492 2010-05-26 12:20:39 2 objectCategory

=========================================================

5. With the above info, we need to just check the security event logs on the “Originating DSA” during “Org. Time/Date”. With “Account Management” auditing enabled on the DCs, we should see the following events in the security log.

For computer account deletion:

·         On Windows 2003, we should get Event ID: 647

·         On Windows 2008, we should get Event ID: 4743

For User account deletion:

·         On Windows 2003, we should get Event ID: 630

·         On Windows 2008, we should get Event ID: 4726

=========================================================

Below is an example of an event confirming deletion and providing info about who deleted it.

Log Name: Security

Source: Microsoft-Windows-Security-Auditing

Date: 5/26/2010 12:20:39 PM

Event ID: 4726

Task Category: User Account Management

Level: Information

Keywords: Audit Success

User: N/A

Computer: 2008-dc2.2008dom.local

Description: A user account was deleted.

Subject:

Security ID: 2008DOM\Administrator

Account Name: Administrator

Account Domain: 2008DOM

Logon ID: 0x5fe2d

Target Account:

Security ID: S-1-5-21-3841965381-1462996679-2541222053-2111

Account Name: TestUser

Account Domain: 2008DOM

=========================================================

Hope this helps…

- Abizer

Netmon's view of Kerberos communication, when accessing resources across domains in the same forest.

abizer_hazrat — Fri, 31 Jul 2009 13:35:00 GMT

Domain setup:

Both Child1 and Child2 are in the same forest with the same parent domain R2dom.local.

Administrator of the Child domain (CHILD1) login to a member server (CH1-Mem) in CHILD1 domain.

After login in the user tries to access \\r2dom-ch2-Mem1 . R2dom-ch2-Mem1 is a member server in Child2 domain.

--> I have used Network monitor to analyze and understand how Kerberos authentication would work, when accessing resource across domain.

Below you see that the Administrator is getting the required Kerberos tickets when accessing resources across domain.

10.2.1.2 = DC of CHILD1.R2DOM.LOCAL

10.1.1.2 = DC of R2DOM.LOCAL

10.3.1.1 = Dc of CHILD2.R2DOM.LOCAL

10.10.10.1 = CH1-Mem in CHILD1

10.10.10.1 10.2.1.2 KerberosV5:TGS Request Realm: CHILD1.R2DOM.LOCAL Sname: cifs/r2dom-ch2-Mem1

--> KrbApReq: KRB_AP_REQ (14)

Ticket: Realm: CHILD1.R2DOM.LOCAL, Sname: krbtgt/CHILD1.R2DOM.LOCAL

** Here you see a Kerberos TGS request being sent to the local domain (CHILD1.R2DOM.LOCAL) DCs for a SPN cifs/r2dom-ch2-Mem1. Local domain TGT sent in the TGS request.

10.2.1.2 10.10.10.1 KerberosV5:TGS Response Cname: Administrator

--> Ticket: Realm: CHILD1.R2DOM.LOCAL, Sname: krbtgt/R2DOM.LOCAL

** Here the local domain DC returns a TGT of the Parent domain R2DOM.LOCAL. This is like a referral being sent to the client as the local domain does not have the right to issue a Kerberos Ticket for cifs/r2dom-ch2-Mem1.

10.10.10.1 10.1.1.2 KerberosV5:TGS Request Realm: R2DOM.LOCAL Sname: krbtgt/CHILD2.R2DOM.LOCAL

--> KrbApReq: KRB_AP_REQ (14)

Ticket: Realm: CHILD1.R2DOM.LOCAL, Sname: krbtgt/R2DOM.LOCAL

** Now the client machine send a TGS request to the Parent domain R2DOM.LOCAL, requesting for a TGT of another of its Child domain where the cifs/r2dom-ch2-Mem1 resides. When sending this request to the parent domain, the client uses the TGT of the Parent domain received in the earlier referral from local DC.

10.1.1.2 10.10.10.1 KerberosV5:TGS Response Cname: Administrator

--> Ticket: Realm: R2DOM.LOCAL, Sname: krbtgt/CHILD2.R2DOM.LOCAL

**Parent domain sends the TGT of the child2 domain to the client. This can also be taken as a referral to the CHILD2 domain.

10.10.10.1 10.3.1.1 KerberosV5:TGS Request Realm: CHILD2.R2DOM.LOCAL Sname: cifs/r2dom-ch2-Mem1

-->KrbApReq: KRB_AP_REQ (14)

Ticket: Realm: R2DOM.LOCAL, Sname: krbtgt/CHILD2.R2DOM.LOCAL

** Eventually the Child sends a TGS request for the SPN cifs/r2dom-ch2-Mem1 to the DCs in domain CHILD2.R2DOM.LOCAL who is authorized to issue a ticket for the server (r2dom-ch2-Mem1) in its domain. This time the client uses the CHILD2 domains TGT to make request.

10.3.1.1 10.10.10.1 KerberosV5:TGS Response Cname: Administrator

--> Ticket: Realm: CHILD2.R2DOM.LOCAL, Sname: cifs/r2dom-ch2-Mem1

** Finally the client gets the Kerberos Ticket for cifs/r2dom-ch2-Mem1, which will help the Administrator user access the shares on r2dom-ch2-Mem1 in domain CHILD2.R2DOM.LOCAL.

The workstation the user 'Administrator" is using to access the resource across domain, also needs a similar ticket.

Tickets for r2dom-ch2-Mem1 is requested from local domain, who returns the error KDC_ERR_S_PRINCIPAL_UNKNOWN, as the r2dom-ch2-Mem1 computer is not a part of the local domain (CHILD1.R2DOM.LOCAL)

10.10.10.1 10.2.1.2 KerberosV5 KerberosV5:TGS Request Realm: CHILD1.R2DOM.LOCAL Sname: r2dom-ch2-Mem1

10.2.1.2 10.10.10.1 KerberosV5 KerberosV5:KRB_ERROR - KDC_ERR_S_PRINCIPAL_UNKNOWN (7)

Below you see that the client computer is getting the required Kerberos tickets when accessing resources across domain.

10.10.10.1 10.2.1.2 KerberosV5 KerberosV5:TGS Request Realm: CHILD1.R2DOM.LOCAL Sname: cifs/r2dom-ch2-Mem1

10.2.1.2 10.10.10.1 KerberosV5 KerberosV5:TGS Response Cname: CH1-Mem$

10.10.10.1 10.1.1.2 KerberosV5 KerberosV5:TGS Request Realm: R2DOM.LOCAL Sname: krbtgt/CHILD2.R2DOM.LOCAL

10.1.1.2 10.10.10.1 KerberosV5 KerberosV5:TGS Response Cname: CH1-Mem$

10.10.10.1 10.3.1.1 KerberosV5 KerberosV5:TGS Request Realm: CHILD2.R2DOM.LOCAL Sname: cifs/r2dom-ch2-Mem1

10.3.1.1 10.10.10.1 KerberosV5 KerberosV5:TGS Response Cname: CH1-Mem$

- Abizer

Should IIS be installed on Domain Controller

abizer_hazrat — Thu, 16 Jul 2009 10:00:00 GMT

I have come across various scanarios where System Administrators have installed IIS on Domain Controllers. They do it to efffectively utilize that server hardware, to cut down cost by preventing a need for another server for IIS, some application that needs to be installed on the DC requires IIS etc.

Microsoft does NOT recommend IIS on a Domain Controller running Active Directory. There are 2 mains reasons behind this stand.

1. By installing IIS on a DC, we will end up increasing the surface attack area on that DC, hence causing a threat to the security database of the domain. This may also effect the servers performance and reliability.

2. IIS would NOT work correctly as it mainly works with local users and groups which will now become domain users /groups. This would cause permission issues if the ACLs set on different IIS folders and Metabase is not updated correctly.

Below are a few articles that would give you some idea of the issues faced when IIS is installed on a Domain controller.

DCPROMO does not retain permissions on some IIS folders
http://support.microsoft.com/default.aspx?scid=kb;EN-US;332097

How To Promote a Member Server Running IIS to a Domain Controller Running IIS
http://support.microsoft.com/kb/300432

FIX: ASP.NET does not work with the default ASPNET account on a domain controller
http://support.microsoft.com/default.aspx?scid=kb;EN-US;315158

Cannot install a Systems Management Server 2003 Management Point role on Windows Server 2003 domain controllers
http://support.microsoft.com/default.aspx?scid=kb;EN-US;886213

Avoid installing IIS on a domain controller
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/3a0742c4-f45a-4504-a232-83dd085bcfb3.mspx?mfr=true

Part from the above resources, I strongly recommend viewing the webcast below as it will talk in detail on why IIS is not recommended on DC. This webcast also covers the issues you may face when you install IIS on DC and how it deal with it.

TechNet Webcast: Successfully Running IIS on a Domain Controller - Level 200
http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032245355&Culture=en-US

To summarize, we don’t recommend installing IIS on DCs, but if you have to install it you need to be prepared to deal with issue related to IIS.

- Abizer

Error: "The parameter is incorrect" when connecting to a server using WMI.

abizer_hazrat — Wed, 15 Jul 2009 15:32:00 GMT

You test WMI connectivity remotely using WBEMTEST > Error: "The parameter is incorrect"

Analysis:

Network trace during the issue shows that communication is happening with TCP Port 135 but after that secondary connection other DCOM/WMI interface not happening on other DYNAMIC RPC ports (above 1024).
All ports between the client and the target server are open.

Network trace during the problem: communication only with TCP port 135

10.171.72.119    abizerh-lab MSRPC   MSRPC:c/o Bind: UUID{000001A0-0000-0000-C000-000000000046} IRemoteSCMActivator(DCOM) Call=0x4 Assoc Grp=0x0 Xmit=0x16D0 abizerh-lab   10.171.72.119 MSRPC MSRPC:c/o Bind Ack: Call=0x4 Assoc Grp=0x71F7 Xmit=0x16D0 Recv=0x16D0
10.171.72.119   abizerh-lab MSRPC   MSRPC:c/o Alter Cont: UUID{000001A0-0000-0000-C000-000000000046} IRemoteSCMActivator(DCOM) Call=0x4
abizerh-lab   10.171.72.119 MSRPC MSRPC:c/o Alter Cont Resp: Call=0x4 Assoc Grp=0x71F7 Xmit=0x16D0 Recv=0x16D0
10.171.72.119    abizerh-lab DCOM   DCOM:RemoteCreateInstance Request, DCOM Version=5.7 Causality Id={F756624A-7CA5-4534-9F62-6638201C68CD}
abizerh-lab   10.171.72.119 DCOM DCOM:RemoteCreateInstance Response, ORPCFLOCAL - Local call to this computer
                                                                              ----->ReturnValue: 0x00000057 - ERROR_INVALID_PARAMETER - The parameter is incorrect.

Working trace: You can see that apart from the connections to TCP 135, secondary connection are being made to other UUID of DCOM / WMI interface.

10.171.72.119   Abizerh-lab MSRPC   MSRPC:c/o Request: unknown   Call=0x3 Opnum=0x5 Context=0x0 Hint=0x0
Abizerh-lab 10.171.72.119 MSRPC   MSRPC:c/o Response: unknown   Call=0x3 Context=0x0 Hint=0xE4 Cancels=0x0
10.171.72.119   Abizerh-lab DCOM DCOM:RemoteCreateInstance Request, DCOM Version=5.7 Causality Id={03728AE5-CD86-4477-BA31-7B275C0A7CFF}
Abizerh-lab 10.171.72.119 DCOM   DCOM: Response, ORPCFLOCAL - Local call to this computer, Unknown IRemoteSCMActivator Method opnum=0
10.171.72.119 Abizerh-lab MSRPC   MSRPC:c/o Bind: UUID{00000143-0000-0000-C000-000000000046} IRemUnknown2(DCOM) Call=0x1 Assoc Grp=0x0 Xmit=0x16D0
Abizerh-lab   10.171.72.119 MSRPC   MSRPC:c/o Bind Ack: Call=0x1 Assoc Grp=0x7688 Xmit=0x16D0 Recv=0x16D0
10.171.72.119 Abizerh-lab MSRPC   MSRPC:c/o Auth3: Call=0x1
10.171.72.119 Abizerh-lab DCOM   DCOM:IRemUnknown2:RemQueryInterface Request, DCOM Version=5.7 Causality Id={03728AE5-CD86-4477-BA31-7B275C0A7CFF}
Abizerh-lab 10.171.72.119 DCOM   DCOM:IRemUnknown2:RemQueryInterface Response, ORPCFNULL - No additional information in this packet
10.171.72.119   Abizerh-lab MSRPC   MSRPC:c/o Alter Cont: UUID{D4781CD6-E5D3-44DF-AD94-930EFE48A887} IWbemLoginClientID(WMIRP) Call=0x2
Abizerh-lab 10.171.72.119 MSRPC MSRPC:c/o Alter Cont Resp: Call=0x2 Assoc Grp=0x7688 Xmit=0x16D0 Recv=0x16D0

Dumped the endpoint mapper database of the TARGET server (we are trying to connect to via WMI) containing the details of the services asociation with different protocols/ports.
- RPCDUMP /s target_server /v /i > rpcdump.txt
**RPCDUMP is a part of windows resource kit.

This output during the problem, from the target server, showed services listening on ncacn_np, ncalrpc but NO services listening on ncacn_ip_TCP. In a normal scenario, the above output should show atleast a few services listening on Dynamically allocated TCP ports i.e. associated with ncacn_ip_TCP protocol. A few services that you should fine listening on all Windows server is SAM {12345778_1234_abcd_ef00_0123456789ac} or SVCCTL {367abb81_9844_35f1_ad32_98f038001003}.

You should see something like this in the RPC dump to confirm that Dynamic allocation of TCP ports is happening on the server.

ProtSeq:ncacn_ip_tcp
Endpoint:5003
NetOpt:
Annotation:
IsListening:YES
StringBinding:ncacn_ip_tcp:ABIZERH-LAB[5003]
UUID:12345778-1234-abcd-ef00-0123456789ac
ComTimeOutValue:RPC_C_BINDING_DEFAULT_TIMEOUT
VersMajor 1 VersMinor 0

After receiving the hint from the RPCdump output, of the Target server, we looked up the following registry key/values on the Target server.

HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc\Internet
- Ports
- PortsInternetAvailable
- UseInternetPorts

**These values were present and configured on the Target server.

Note: the above registry values are not present by default and are set it case you want to set a range of TCP ports for RPC dynamic port allocation.

How to configure RPC dynamic port allocation to work with firewalls
http://support.microsoft.com/kb/154596

So was this RPC dynamic port allocation configuration causing the problem? NO NO NO

On the problem target server, we found that the RPC dynamic port allocation configuration were not set correctly i.e. the Port range had a space between them for example Ports = '5100 - 5200' instead of '5100-5200'. This was basically confusing the OS where it knew that the RPC dynamic allocation restriction was set but could make sence of the values, hence causing it not to allocate any ports to any services at all.

Further testing showed that even when "PortsInternetAvailable" or "UseInternetPorts" were mis-spelled, OS couldn't handle it correctly.

Correcting the above settings related to ‘RPC dynamic port allocation’ and rebooting the target server resolved the issue and now we were able connect to the server using WMI.

- Abizer

Chicken Soup for the Techie

How an incorrectly configured account lockout policy can give more pain than security.

Possible causes of Authentications failures for federated users in Office 365.

More information about SSO experience when authenticating via ADFS

Information about Email addresses assigned to a licensed user in O365

SupportMultipleDomain switch, when managing SSO to Office 365

When a SSO is enabled for O365 via ADFS, you should see the Relying Party (RP) trust created for O365.

Commands that would create the RP trust for O365 are below:

New-MsolFederatedDomain -DomainName<domain>

OR

Convert-MsolDomainToFederated -DomainName <domain>

OR

Update-MSOLFederatedDomain -DomainName <domain>

**Update-MSOLFederatedDomain as the name suggest if you update an existing federation trust between ADFS and O365, In this process it will update or recreate the RP on ADFS side.

The RP trust created above comes with 2 claims rules

'Get-MsolFederationProperty -DomainName <domain>' for the federated domains shows that the “FederationServiceIdentifier” was the same for source ADFS and O365 i.e. the http://STSname/adfs/Services/trust

With the ADFS rollup 1 update, we added the following functionality:

Support for Multiple Top Level Domains

Commands that can be used to create the RP trust for O365, to support multiple top level domain:

New-MsolFederatedDomain -DomainName <domain> -SupportMultiDomain

OR

Update-MSOLFederatedDomain -DomainName <domain> -SupportMultipleDomain

OR

Convert-MsolDomainToFederated -DomainName <domain> -SupportMultipleDomain

Post using SupportMultipleDomain switch, the following 2 changes take place:

So what does this 3rd claim rule added by SupportMultipleDomain to the RP trust for O365, do

Default 3rd rule:

This rule uses the suffix value of user’s UPN and uses that to generate a new claim called Issuerid. For example, for a user User1@contoso.com , the issuerID in his Token will be http://contoso.com/adfs/services/trust/.

It’s interesting to note that the though this rule issues 'Issuerid' claim, we don’t see this claim in the response token, in fact we see the “Issuer” attribute modified to the newly composed value.

<saml:Assertion MajorVersion="1" MinorVersion="1" AssertionID="_2546eb2e-a3a6-4cf3-9006-c9f20560097f" Issuer="http://contoso.com/adfs/services/trust/" IssueInstant="2012-12-23T04:07:30.874Z" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">

<saml:Assertion MajorVersion="1" MinorVersion="1" AssertionID="_2546eb2e-a3a6-4cf3-9006-c9f20560097f" Issuer="http://STS.contoso.com/adfs/services/trust/" IssueInstant="2012-12-23T04:07:30.874Z" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">

Support for Sub domains

Kerberos Error KDC_ERR_POLICY while trying to access a resource in the Trusted forest (Forest Trust)

Symptoms

Cause

Resolution

Tracing down user and computer account deletion in Active Directory

=========================================================

=========================================================

Netmon's view of Kerberos communication, when accessing resources across domains in the same forest.

Should IIS be installed on Domain Controller

Error: "The parameter is incorrect" when connecting to a server using WMI.

`New-MsolFederatedDomain -DomainName<domain>`

`Convert-MsolDomainToFederated -DomainName <domain>`

`Update-MSOLFederatedDomain -DomainName <domain>`

**`Update-MSOLFederatedDomain as the name suggest if you update an existing federation trust between ADFS and O365, In this process it will update or recreate the RP on ADFS side.`

`'Get-MsolFederationProperty -DomainName <domain>' for the federated domains shows that the “FederationServiceIdentifier” was the same for source ADFS and O365 i.e. the`http://STSname/adfs/Services/trust

`New-MsolFederatedDomain -DomainName` `<domain>` `-SupportMultiDomain`

`Update-MSOLFederatedDomain -DomainName <domain>` `-`SupportMultipleDomain

`Convert-MsolDomainToFederated -DomainName <domain>` `-`SupportMultipleDomain

`Post using SupportMultipleDomain switch, the following 2 changes take place:`

So what does this 3^rd claim rule added by SupportMultipleDomain to the RP trust for O365, do

Default 3^rd rule:

<saml:Assertion MajorVersion="1" MinorVersion="1"
AssertionID="_2546eb2e-a3a6-4cf3-9006-c9f20560097f" Issuer="http://contoso.com/adfs/services/trust/" IssueInstant="2012-12-23T04:07:30.874Z" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">

<saml:Assertion MajorVersion="1" MinorVersion="1"
AssertionID="_2546eb2e-a3a6-4cf3-9006-c9f20560097f" Issuer="http://STS.contoso.com/adfs/services/trust/" IssueInstant="2012-12-23T04:07:30.874Z" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">