Below I have tried to list, a flow for Troubleshooting, authentication issues for a federated user in Azure AD / O365

1.   Access https://login.microsoftonline.com/ and in the Login Form, enter the federated user’s login name like someone@example.com, once you hit tab to focus out of the login textbox, check if the statue of the page changes to redirecting and it redirect you to your STS / ADFS for sign-in.

1. 1. If no redirection happens and you get the option to enter password on the same page, then it means that Azure AD does not recognize the user or the domain of the user to be Federated.

1. This is when you check if there is a federation trust between Azure AD / O365 and your STS/ADFS.

Run ‘Get-msoldomain’ cmdlet from Azure AD powershell, to find out if the domain is managed or federated. 

b.   If you see Redirection happening but it does NOT take you to your STS / ADFS for sign-in, then check if the STS / ADFS service name is resolving to the correct IP and if it can connect to that IP on TCP port 443.

If it shows federated, then get information about the federation trust by running the below commands.

Get-MsolFederationProperty -DomainName <domain>

Get-MsolDomainFederationSettings -DomainName <string>

**check the URI, URL and Certificate of the federation partner configured with AzureAD.

2. After you get redirected to ADFS, the browser may throws a certificate trust related error, and for some client/devices it may not let you establish a SSL session with ADFS.

- Esnure that ADFS service communication certificate presented to the client is the same and one configured on ADFS

- Ensure that ADFS service communication certificate is trusted by the client.

- If Non-SNI capable client are trying to establish a SSL session with ADFS/WAP 2-12 R2, it may fail. Please consider adding a Fallback entry on the ADFS/WAP servers to support non-SNI clients.

How to support non-SNI capable Clients with Web Application Proxy and AD FS 2012 R2
https://blogs.technet.com/b/applicationproxyblog/archive/2014/06/19/how-to-support-non-sni-capable-clients-with-web-application-proxy-and-ad-fs-2012-r2.aspx 

 3.  “Unknown Auth method” or Errors stating AuthnCOntext not supported Errors at ADFS / STS level when you are redirected from Office 365.

This is most common when Office 365 and Azure AD redirects to the ADFS/STS with parameter enforcing a authentication method.

WSFED - uses WAUTH query string to force an preferred authentication method.

SAML2.0 - uses the following

<saml:AuthnContext>
<saml:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</saml:AuthnContextClassRef>
</saml:AuthnContext>

**When the enforced Authentication method is sent with a wrong value or that authentication method is not supported on  ADFS/ STS, it will give you an error before authenticating you.

4.   After you get to your STS / ADFS and enter you credential but you are NOT able to authenticate, check the following:

a.   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.

b.   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:
https://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

c.   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 -F’ to check for duplicate SPN.

d.   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.

e.   In a scenario, where you are using your email as the login ID on O365 and entering the same Email address when being redirected to ADFS for authenticate. The authentication may fail with NO_SUCH_USER error in Audit logs. For you to enable ADFS to find a user for authentication using an Attribute other than UPN or SAMaccountname, like Email, you need to configure it to support Alternate Logon ID.

Configuring Alternate Login ID

https://technet.microsoft.com/en-us/library/dn659436.aspx

f.   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

g.   “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
https://technet.microsoft.com/en-us/library/hh852537.aspx

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

h.   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
https://technet.microsoft.com/en-us/library/hh526961(v=ws.10).aspx -- for ADFS 2.0

https://technet.microsoft.com/en-in/library/dn592182.aspx -- for ADFS 2012 r2/WAP

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

5.   If you, are able to authenticate from Intranet when talking to the ADFS server directly but FAIL when accessing ADFS via ADFS proxy, check the following:

a.   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.

b. Check if the ADFS proxy Trust with the ADFS service is working fine. Re-running the proxy configuration may be a good option if you doubt that the proxy trust is broken.

 6.   After your STS / ADFS issues a Token, Azure AD / O365 throws an error.

a.   The Claims Issued by ADFS / STS in Token, should match the respective Attributes of the user in Azure AD.

In the Token for Azure AD / O365, we need the following Claims:

WSFED:

UPN = the value of this claim should match the userprincipalname of the users in Azure AD.

ImmutableID = the value of this claim should match the sourceAnchor or ImmutableID of the user in Azure AD.

To get User attribute value in Azure AD, run Get-MsolUser –UserPrincipalName <UPN>

SAML 2.0:

IDPEmail = the value of this claim should match the userprincipalname of the users in Azure AD.

NAMEID = the value of this claim should match the sourceAnchor or ImmutableID of the user in Azure AD.

Use a SAML 2.0 identity provider to implement single sign-on

https://technet.microsoft.com/en-us/library/dn641269.aspx

Examples:

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]”

It might also be that you are using AADsync to sync ‘MAIL as UPN’ and ‘EMPID as SourceAnchor’, but the Relying Party claim rules at ADFS level have not been updated to send ‘MAIL as UPN’ and ‘EMPID as ImmutableID’

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

This is one of the most common 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 may 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
https://gallery.technet.microsoft.com/scriptcenter/Office-365-Federation-27410bdc

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

c.    “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
https://blogs.technet.com/b/abizerh/archive/2013/02/06/supportmultipledomain-switch-when-managing-sso-to-office-365.aspx

d.  Ensure Token Encryption is NOT being used by ADFS or STS when issuing a Token to AzureAD or O365.

7.   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.

8. Ensure that Secure Hash Algorithm configured on the Relying Party Trust for O365  is set to SHA1

When the trust between the STS/ADFS and AzureAD/O365 is using SAML 2.0 protocol, the Secure Hash Algorithm configured  for digital signature should be SHA1.

6.   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"
https://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
https://support.microsoft.com/kb/2461628/EN-US

ADFS 2.0 troubleshooter

• Connectivity problems (KB 3044971)

• ADFS service problems (KB 3044973)

• Certificate problems (KB 3044974)

• Authentication issues (KB 3044976)

• Claim rules problems (KB 3044977)

Regard

Abizer

Sharing one of my videos providing an overview of Azure Active Directory (as on April 2015).

Ask The Expert session - Azure Active Directory Your Identity Management Solution for the Cloud

https://www.bing.com/videos/watch/video/ask-the-expert-session-azure-active-directory-your-identity-management-solution/qmt7sz0b

https://www.microsoft.com/en-us/showcase/details.aspx?uuid=e33047c1-3b55-4b14-88bb-60594403b575

happy learning

Abizer

I have been working with ADFS since the last few years and have tried to list most of the troubleshooting steps related to ADFS 2.0, categorized under 5 public articles.

I suggest you go through these to narrow down the cause of any issues with ADFS 2.0 and resolve them.

• Connectivity problems (KB 3044971)

• ADFS service problems (KB 3044973)

• Certificate problems (KB 3044974)

• Authentication issues (KB 3044976)

• Claim rules problems (KB 3044977)

Hope this helps.

Abizer

Hi folks

While recently working on some ADFS deployments on Azure, I learned a lot of stuff. Thought of sharing my learnings with all, some of it documented already, some not documented clearly.

Possible Deployments of ADFS on Azure:

1. All ADFS servers, ADFS proxies, DCs on Azure.

• Option 1: With ADFS servers behind load balanced VIP, and ADFS proxies pointing to VIP.
• Option 2: With ADFS proxies pointing to the DIP(Dedicated IP) of ADFS servers in a one to one relationship.
• Option 3 (RECOMMENDED) : Load balance the DIP(Dedicated Internal IP) of the ADFS servers. Make the ADFS proxies point to the load balanced Internal IP of the ADFS service.
  

       2.  Hybrid setup with ADFS servers, ADFS proxies and DCs distributed across on premise and Azure site, with either Azure setup as primary or DR.

       3.  ADFS proxies on Azure pointing to load balanced ADFS servers on-premises through the site-to-site VPN.

General recommendations: 

• Recommended to have 2 instances of ADFS and ADFS proxy for redundancy reasons, especially when the Azure site is hosting the primary/full ADFS deployment. These 2 instanced of the same role should be a part of the same Availability Set.

• ADFS servers require communication with DCs, these DCs can be setup on Azure or we can have ADFS query the DCs on-premises using the site to site VPN link.

• DCs in Azure site to Support ADFS:

• When extending the existing forest to Azure, make sure you have at least 1 DC of each domain in the forest, in the Azure site.
• If it satisfies your application's objective, you can also have a separate forest hosted on Azure with/without a NT Trust with On-premises forest.
• Its preferable to have the GC and DNS roles on the DC too. This would reduce the traffic going to the GCs on-premises, for evaluating the universal group membership.
• All the ADFS servers and DCs need to be a part of the same virtual network, else they would not be able to communicate with each other using the internal DIPs (Dedicated DHCP leased IP address assigned to the  VM).
• Windows Azure-provided DNS, does not meet the advanced name resolution needs of Windows Server AD DS. For example, it does not support dynamic SRV records, and so on. Name resolution is a critical configuration item for DCs and domain-joined clients. DCs must be capable of  registering resource records and resolving other DC’s resource records. Hence its best to add the DNS role to one of the DCs in Azure and add that DNS server’s IP to the VNET configuration.
• Move the DCs in Azure to a separate AD site created to represent Azure. Map the subnet in the VNet (Virtual Network) to the AD site, so that the ADFS servers in the same VNet prefer the local DC.
• The Azure site having the ADFS setup can host either RWDC and RODC.
• Since RODC is meant for site which are not secure, it may not ideally qualify for deployment on Azure, BUT one may still consider it from a cost saving perspective as RODC do not replicate any data out, resulting in less egress traffic, hence less cost.
• RODCs if deployed also need to be configured to cache passwords of all users who will be authenticated via ADFS, this it to prevent downtime on ADFS authentication, when site to site VPN is down. Now if your application or ADFS needs to authenticate all user in domain, for the same reason you are planning to cache all user passwords on RODC, you are better of with RWDC.
• While ADFS can authenticate against RODC, if the user password is cached on RODC. The ADFS server will need access to the writable DCs when there is a configuration change in ADFS like the Token signing certificate rollover.
• When using RWDC, you may have to configure site link, replication interval, change notification, compression to suite your objectives, i.e. lower latency or reduced traffic etc.
• When deploying DC on Azure VM, don’t assign a static address to it you can reserve the dedicated internal IP assigned to the DC via Powershell cmdlet Set-AzureStaticVNetIP. A tip to ensure that the dynamic IP sticks with the VM is to shutdown the VM from within the OS and not from the Azure portal. Shutting down any VM from the portal with de-allocate the resources assigned to it including the dynamic IP.
• Ensure that the DCs have an additional data disk (With NO caching ) added to the DC's VM. Store the NTDS and sysvol content on this data disk. This is to prevent data corruption in case of recovery, as data disks with NO caching ensures that the all the committed transactions are written to the database/disk.
• As a security best practice, once the site to site VPN is setup and we can access the Azure DC using its DIP, we should remove all endpoints exposed via the public IP of the VM.

• DCs on-premises to support ADFS:

• With the ADFS servers and ADFS proxies on the Azure site, if we don’t have a local DC in the same Azure VNet and the ADFS servers have to contact on-prem DC for authentication, ldap queries, Secure channel etc, In this scenario, we are looking at high amount of egress traffic leading to more cost and also the VPN link being the single point of failure.
• Some may want to just use the Azure site for ADFS proxies while the ADFS server and DC are on-premises. This may help if you want the Intranet users to get Single Sign on experience while authenticating with internal load balanced ADFS servers using Windows Integrated Authentication.

ADFS specific recommendations (Mainly for deployment option 1, i.e. full ADFS setup in Azure)

• ADFS proxies should be a part of the same cloud service, leading to common VIP (Virtual Public IP) and should have a load balanced endpoint for TCP 443. The ADFS proxy VM should have there own Availability Set too.

• The public name of the ADFS service for Example: STS.contoso.com, should be configured as a Cname pointing to the public DNS name of the VIP example: ADFSprx.cloudapp.net . We should not map the ADFS service name to the VIP IP of the ADFS proxies, as the VIP IP can change, during the lifetime of the cloud service. There is not an option to reserve this VIP assigned to a cloud service too, which can be used for ADFS proxy cloud service.

• Ideally ADFS proxies should resolve the ADFS service name to the backend ADFS servers. This can be done using Host files and split DNS configuration.

• Host file on the ADFS proxy servers, mapping the ADFS service name to VIP of the ADFS servers.
  • The challenge here could be that the proxies will not be able to reach the ADFS  service if the VIP of the backend ADFS servers has changed. Hence this requires you to monitor the health of the ADFS servers and the VIP assigned to it and manually change mapping on the proxy to redirect traffic to the correct ADFS farm.

• Host file on the ADFS proxy servers mapping ADFS service name to the DIP of the individual ADFS servers. Basically have the one to one mapping between the ADFS proxy and ADFS server.
• The challenge here is that when one of the ADFS servers is unresponsive, a proxy  server getting a portion of the external request will try to forward it to the mapped unresponsive ADFS server and fail. Hence this requires you to monitor the health of the ADFS servers and manually change mapping on the proxy to redirect traffic to the working ADFS server.

• Configure Host file on ADFS proxy to point to the load balanced internal IP of the ADFS servers (RECOMMENDED).

• ADFS servers can also be assigned a VIP with load balanced endpoint (TCP 443). This can be a security concern as via the VIP we would be exposing the domain joined ADFS server to the internet.

• ADFS server’s VIP ACL can be configure on the load balanced VIP endpoint to only allow traffic from proxy servers to the ADFS servers, securing the ADFS servers.

• The ADFS proxy when talking to the backend ADFS service farm via load balanced VIP, will be doing it over the internet. Which means that though the ADFS server and proxies are in the same VNet, the ADFS proxy VM may attract an extra charge for the Egress traffic to backend ADFS servers.

• In a setup where the whole ADFS setup is on the cloud, its recommended that you configure IE, Web-proxy so that internal users (connected to corporate network) contact the ADFS service via the external AD FS proxy endpoints instead of internal AD FS endpoints. Using only external endpoints removes the VPN connection as a single point of failure for internal user authentication to Office 365. Using only external endpoints for the ADFS service also means that additional authentication prompts may occur for users because ADFS treats all authentication requests as coming from users on the Internet.

• The alternative to the recommended approach above is to direct internal AD FS traffic over the VPN to the ADFS servers directly or through the use of a DNS record.

• If  the primary site for ADFS is Azure then ensure than the primary role is on the Azure VM.

• ADFS setup should be an ADFS farm using WID.

• Windows Azure™ Active Directory and Office 365 support several security token services, including AD FS, Shibboleth Identity Provider (https://technet.microsoft.com/en-us/library/jj205456.aspx),
  and other third-party providers (https://technet.microsoft.com/en-us/library/jj679342.aspx). While it may be feasible to deploy Shibboleth or other third-party providers on Virtual Machines, these providers haven’t been tested by Microsoft for the above deployment.

• ADFS on Azure can have multiple RP, which can include Office 365, another claim based application hosted on another VM in Azure, claim based application registered with Azure Active Directory which has the domain federated, claim based application hosted externally etc.

References:

Guidelines for Deploying Windows Server Active Directory on Windows Azure Virtual Machines

https://msdn.microsoft.com/en-us/library/azure/jj156090.aspx

Office 365 Adapter: Deploying Office 365 Single Sign-On using Windows Azure

https://www.microsoft.com/en-in/download/details.aspx?id=38845

Hope this helps,

-  Abizer

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:

https://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’

https://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”

https://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:

https://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

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.

https://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
https://technet.microsoft.com/en-us/library/hh852537.aspx

https://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
https://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
https://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
https://support.microsoft.com/kb/2461628

Regards

Abizer

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

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
https://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 (https://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 https://<domainname>/adfs/services/trust/ whereas the ADFS configuration still has https://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
== "https://schemas.xmlsoap.org/claims/UPN"]

=> issue(Type = "https://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", Value = regexreplace(c.Value, ".+@(?<domain>.+)", "https://${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 https://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="https://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=”https://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="https://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="https://schemas.microsoft.com/ws/2008/06/identity/claims"><saml:AttributeValue>https://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. https://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 https://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 https://contoso.com/adfs/services/trust/ instead of  https://Child1.contoso.com/adfs/services/trust/ (with default rule)

Customized
3rd rule

     Rule 1:

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

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

OR

Rule 2:

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

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

Sample output from the above rule:

[regex]::replace("abizerh@contoso.com", “^((.*)([.|@]))?(?<domain>[^.]*.(com|net|co|org)(.\w\w)?)$”, 'https://${domain}/adfs/services/trust')
https://contoso.com/adfs/services/trust

[regex]::replace("abizerh@contoso.co.in", “^((.*)([.|@]))?(?<domain>[^.]*.(com|net|co|org)(.\w\w)?)$”, 'https://${domain}/adfs/services/trust')
https://contoso.co.in/adfs/services/trust

[regex]::replace("abizerh@child.contoso.co.in", “^((.*)([.|@]))?(?<domain>[^.]*.(com|net|co|org)(.\w\w)?)$”, 'https://${domain}/adfs/services/trust')
https://contoso.co.in/adfs/services/trust

[regex]::replace("abizerh@child.contoso.org", “^((.*)([.|@]))?(?<domain>[^.]*.(com|net|co|org)(.\w\w)?)$”, 'https://${domain}/adfs/services/trust')
https://contoso.org/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 https://STS.contoso.com/adfs/services/trust/

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

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

Understanding Claim Rule Language in AD FS 2.0
https://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
https://technet.microsoft.com/en-us/library/hh440535.aspx

Hope this info helps 

Cheers

Abizer

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

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

Routing name suffixes across forests

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

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