OWA and Conditional Access: Inconsistent Error Reports

Posted on 1 CommentPosted in AzureAD, conditional access, EM+S, enterprise mobility + security, exchange, exchange online, Exchange Online Protection, IAmMEC, Outlook

Here is a good error message. Its good, because I could not find any references to it on Google and the fault was nothing to do with the error message:

image

The error says “something went wrong” and “Ref A: a long string of Hex Ref B: AMSEDGE0319 Ref C: Date Time”. The server name in Ref B will change as well. It also says “more details” and if you click that there are no more details, but that text changes to “fewer details”. As far as I have seen, this only appears on Outlook Web Access (OWA).

The error appears under these conditions:

  1. You are enabled for Enterprise Mobility + Security licences in Azure AD
  2. Conditional Access rules are enabled
  3. The device you are on, or the location you are at etc (see the specifics of the conditional access rule) mean that you are outside the conditions allowed to access Outlook Web Access
  4. You browsed directly to https://outlook.office.com or https://outlook.office365.com

What you see in the error message is OWA’s way of telling you that you cannot get to that site from where you are. That you have failed the conditional access tests.

On the other hand, if you visit the Office 365 portal or MyApps (https://portal.office.com or https://myapps.microsoft.com) and click the Mail icon in your Office 365 menu or on the portal homepage then you get a page that says (in the language of your browser):

image or in Welsh, image

This says “you can’t get there from here” and the reasons why you have failed conditional access.

If you were on a device or location that allowed you to connect (such as a device managed by Intune and compliant with Intune rules) then going to OWA directly will work, as will going via the menu.

So how can you avoid this odd error message for your users. For this, you need to replace outlook.office.com with your own custom URL. For OWA you can create a DNS CNAME in your domain for (lets say) webmail that points to outlook.office365.com (for this it will not work if you point the CNAME to outlook.office.com). Your users can now go to webmail.yourdomain.com. This will redirect the user via Azure AD for login and token generation, and as you are redirected via Azure AD you will always see the proper, language relevant, conditional access page.

Bypassing Focused Inbox and Clutter Folders

Posted on Leave a commentPosted in Clutter, Focused Inbox, IAmMEC, Office 365, Outlook

For the last few years Exchange Online mailboxes have been processed by a service call Clutter, which moved the less important emails, or indeed the clutter, to a dedicated folder. This is now in the processes of being replaced by the Focused Inbox, which is client version dependant and is all based on views on the mailbox and not different folders.

The way to ensure mail is not marked as clutter, or shown in the Other view when your mailbox is processed by the Focused Inbox, is to mark the item as such, or to actively engage with the item. That is if you reply or read the emails from these recipients they do not go into Clutter/Other, but if you ignore them or delete them before they are read then this makes them candidates for future processing by the Focused Inbox or Clutter engine.

There are though times when occasional emails need to be in your Inbox and not the Other view or the Clutter folder. The best two ways to do this are as follows:

Management Hierarchy

The processing engine for Clutter/Focused Inbox will not place items from your Direct Reports or management chain in the Other view/Clutter folder nor will it place any emails from yourself into the low priority location. The Direct Reports and your management chain is known to the processing engine as it is part of Active Directory. So as long as your manager (and everyone else’s manager) attribute is populated in Active Directory and synced to Azure Active Directory then this configuration can be honoured.

Transport Rules

The other way to ensure certain messages always go to the Inbox is to have the message processed by a transport rule. Transport rules, like the management chain above are only available in Office 365 Business and not Outlook.com. The two Transport Rule placeholders below add the Clutter and Focused Inbox rules (there are two different rules, so if you added the Clutter one in the past a new one is needed for Focused Inbox). They add the rule with a arbitary placeholder, so that the rule never fires (unless you really happen to enter the demo text!). So once you add these rules change them to suit the conditions of your environment. For example if you have a “company wide communications” email sender then you could set the rule to be when that sender sends emails. The two rule placeholders you need in remote PowerShell to Exchange Online are:

   1: New-TransportRule -Name "Bypass Focused Inbox" -SubjectContainsWords "This is a placeholder rule that does nothing, change this action to suit the requirements of the client" -SetHeaderName "X-MS-Exchange-Organization-BypassFocusedInbox" -SetHeaderValue "true" -Comments "<date> - <name> - Any mail that meets the conditions of this rule will go into the Inbox or Focused Inbox and not the Clutter or Other folder in Exchange Online"

   2: New-TransportRule -Name "Bypass Clutter" -SubjectContainsWords "This is a placeholder rule that does nothing, change this action to suit the requirements of the client" -SetHeaderName "X-MS-Exchange-Organization-BypassClutter" -SetHeaderValue "true" -Comments "<date> - <name> - Any mail that meets the conditions of this rule will go into the Inbox or Focused Inbox and not the Other view in Exchange Online"

Change these rules to suit your requirements

Exchange Edge Server and Common Attachment Blocking In Exchange Online Protection

Posted on Leave a commentPosted in 2007, 2010, 2013, 2016, Edge, EOP, exchange, exchange online, Exchange Online Protection, FOPE, IAmMEC, Office 365

Both Exchange Server Edge role and Exchange Online Protection have an attachment filtering policy. The default in Edge Server is quite long, and the default in EOP is quite short. There is also a few values that are common to both.

So, how do you merge the lists so that your Edge Server attachment filtering policy is copied to Exchange Online in advance of changing your MX record to EOP?

You run

Set-MalwareFilterPolicy Default -FileTypes ade,adp,cpl,app,bas,asx,bat,chm,cmd,com,crt,csh,exe,fxp,hlp,hta,inf,ins,isp,js,jse,ksh,lnk,mda,mdb,mde,mdt,mdw,mdz,msc,msi,msp,mst,ops,pcd,pif,prf,prg,ps1,ps11,ps11xml,ps1xml,ps2,ps2xml,psc1,psc2,reg,scf,scr,sct,shb,shs,url,vb,vbe,vbs,wsc,wsf,wsh,xnk,ace,ani,docm,jar

This takes both the Edge Server default list and the EOP default list, minus the duplicate values and adds them to EOP. If you have a different custom list then use the following PowerShell to get your two lists and then use the above (with “Default” being the name of the policy) PowerShell to update the list in the cloud

Edge Server: Get-AttachmentFilterEntry

EOP: $variable = Get-MalwareFilterPolicy Default
$variable.FileTypes

Azure Information Protection General Troubleshooting

Posted on 3 CommentsPosted in aadrm, AIP, Azure Information Protection, encryption, IAmMEC, Office 365, rms

Azure Information Protection (AIP) is the new name, and new features for Azure Rights Management. Azure Information Protection allows a company to create a series of labels to apply to documents and to have those documents tags and labelled. For example a watermark or header is easy to set in the Azure Information Protection management blade in portal.azure.com.

In fact its so easy to turn on I did just that. The actual work and business consulting with Azure Information Protection is the why and business reasons for using it rather than the technical steps to enable it.

So once I enabled it and the client installed I found that I had a banner toolbar in Office applications as shown:

image

Clicking any of the labels will perform the default function of the product. These can be modified in the Azure Portal as shown:

image

image

The above two graphics show one example label (Confidential) that has had a sub label added (called NBConsult UK). The larger image above shows the details for this “NBConsult UK” label. In the properties blade for the label you can see I have turned on a template from RMS.

Once the changes are made and saved, you can publish the changes. Clients will pick up these changes on restarting the client application.

image

And then started my issues and the steps to troubleshoot this. First I got the following prompt twice:

image

Followed by:

image

And so I was finding my documents did not get the RMS based labels applied.

Reasons why this might be the case can be checked using the RMS tool in the Office application. So I tried to protect the document manually via File > Info tab:

image

This worked – I had the rights to use the template in the application – just AIP could not apply the template via the AIP tool.

To fix this I ran the Azure Information Protection (AIP) diagnostics tool. To get this click the AIP lock icon and choose Help and Feedback from the menu:

image

From this a popup appears:

image

And from this choose Run diagnostics:

image

Let the tool complete. I got the following errors before the application failed (crashed) and then did not complete again if left it again

image and then image

To get around this issue, as the reset option to fix the AIP application in the diagnostics tool was not available due to the application crash, I followed the steps in http://social.technet.microsoft.com/wiki/contents/articles/19251.ad-rms-troubleshooting-reset-the-client-msipc.aspx to bootstrap the client manually. If the AIP diag client completes, fix the listed issue or choose Reset in the client.

Once I had deleted the files and related registry keys mentioned in the above website I could restart any Office application. The RMS certs, keys and settings where downloaded to the client again and the AIP client was able to protect a document where as before it was not:

image

image

Exchange Online Archive–Counting Archives

Posted on Leave a commentPosted in archive, exchange, exchange online, Exchange Server, EXO, IAmMEC, Office 365

If you are using Exchange Online Archive and what to get a count of the number of users with an archive, or a list of the users with an archive, then the following PowerShell scripts will give you this info:

List all users with an Exchange Online Archive:

Get-MailUser -ResultSize Unlimited | where {$_.ArchiveName -ilike “In-Place Archive*”}

Count all users with an Exchange Online Archive:

(Get-MailUser -ResultSize Unlimited | where {$_.ArchiveName -ilike “In-Place Archive*”}).Count

Both of these PowerShell cmdlets need to be run in Exchange Online via Remote PowerShell.

Unable To Remove Office 365 Domain Error

Posted on Leave a commentPosted in dirsync, exchange online, hybrid, IAmMEC, MSOL, Office 365, powershell

If you need to remove a domain from Office 365 it needs to not be in use. This includes the services that use that domain, for example an Accepted Domain in Exchange Online. If though you have an expired, maybe test, Office 365 tenant and you want to remove a domain from it you may find unhelpful error messages. For example I have seen in the domain removal process in the portal a message saying “Please don’t close this page while we remove your domain” etc. It tries for several minutes as it predicts, but did not complete:

image

Upon failing to complete you get a further warning before it finally gives up and tells you that it cannot complete:

image

So the obvious next step (or obvious to me anyway) is to try the removal in remote PowerShell to Office 365. The cmdlet is Remove-MsolDomain -DomainName domain.com but this comes back with with messages that might be helpful, but after repeated running of the cmdlet and fixing the error still suggests the same fix.

image

The error reads: Remove-MsolDomain : Unable to remove this domain. Use Get-MsolUser -DomainName <domain name>  to retrieve a list  of objects that are blocking removal. The problem with this error is the list of objects here are only user accounts and not any of the other objects that could block a domain removal.

So sure, remove your unneeded users or change their UPN/email address to not include this domain that you want to remove, but also run Get-MsolContact and Get-MsolGroup and then remove or edit the contacts and the groups that use this domain.

So though the error says to fix the user objects that are blocking domain removal, you also need to fix or remove the groups and contacts as well.

Qualifications in Exchange Signatures

Posted on Leave a commentPosted in 2013, active directory, exchange, Exchange Server, Global Catalog, IAmMEC, iQ.Suite

In a recent project I was working with iQ.Suite from GBS and specifically the component of this software that add signatures to emails. The client are an international organization with users in different geographies and we needed to accommodate the users qualifications in their email signature.

The problem with this is that in Germany qualifications are written in front of the name and in the USA at the end and in other countries at the start and the end. We were doing a Notes to Exchange migration and in Notes the iQ.Suite signature software read data from Notes that was originally pulled from Active Directory, and so the client had placed the qualifications in the DisplayName field in the Active Directory.

But when we migrated to Exchange Server the Global Address List listed the users DisplayName an so the German users where all listed together with “Dipl” as the first characters of their name. Also the name the email came from was written like this. The signature worked, but the other changes that became apparent meant we had to work out a different way to look at this problem.

So rather than using DisplayName for the users name and qualifications, we used personalPrefix in Active Directory to store anything needed before their name (Dipl in the above German example, and Prof or Dr being English examples) and the generationQualifier Active Directory attribute to store any string that followed the users DisplayName (such as Jr in the USA or BSc for qualifications etc.)

In iQ.Suite we created a signature that looked like the following. This has a conditional [COND] entry for personalTitle, displayName and generationQualifier. That is if each of these are present, then show the displayName with personalTitle before it and generationQualifier after it. If the user does not have values for these fields, do not show them. The [COND] control is documented in iQ.Suite.

[COND]personalTitle;[VAR]personalTitle[/VAR] [/COND][COND]displayName;[VAR]displayName[/VAR][/COND][COND]generationQualifier; [VAR]generationQualifier[/VAR][/COND]

What was not so well documented, and why I wanted to write this blog entry was that the personalTitle and generationQualifier attributes are not stored in the Global Catalog and so are missing in the users signature. In the multi-domain deployment we had at the client, iQ.Suite read the personalTitle, displayName and generationQualifier Active Directory attributes from the Global Catalog as Exchange was installed in a resource domain and the users in separate domains and so unless the attribute was pushed to the Global Catalog it was not seen by iQ.Suite.

To promote an attribute to be visible in the Global Catalog you need to open the Schema Management MMC snap-in, find the attributes of question and tick the Replicate this attribute to the Global Catalog field. This is outlined in https://technet.microsoft.com/en-us/library/cc737521(v=ws.10).aspx.

Password Writeback Errors

Posted on 8 CommentsPosted in Azure, Azure Active Directory, Group Policy, IAmMEC, Office 365, password

I had been struggling with password writeback testing and was coming across the following set of errors, and found that searching for them uncovered nothing online. So I wrote this blog to remind me and help you solve these issues. These errors are all visible in the Application log of the Event Viewer.

User Restrictions

The following error is because the user has “user cannot change password” option set in Active Directory:

EventID 33004: TrackingId: 7344da2c-ab9d-42ef-adea-4a17d07fdeb9, Reason: Synchronization Engine returned an error hr=80230626, message=The password could not be updated because the management agent credentials were denied access., Context: cloudAnchor: User_9b83f544-ba22-4ffb-bff5-c1c2374d654c, SourceAnchorValue: F39SWQrM2EidaboN8UC8Ww==, UserPrincipalName: ethan@contoso.co.uk, Details: Microsoft.CredentialManagement.OnPremisesPasswordReset.Shared.PasswordResetException: Synchronization Engine returned an error hr=80230626, message=The password could not be updated because the management agent credentials were denied access.
   at AADPasswordReset.SynchronizationEngineManagedHandle.ThrowSyncEngineError(Int32 hr)
   at AADPasswordReset.SynchronizationEngineManagedHandle.ChangePassword(String cloudAnchor, String sourceAnchor, String oldPassword, String newPassword)
   at Microsoft.CredentialManagement.OnPremisesPasswordReset.PasswordResetCredentialManager.ChangePassword(String encryptedChangePasswordRequestString, String publicKeyEncryptedSymmetricKey, String publicKeyEncryptedSymmetricIV)

And also, as the second error generated:

Event ID 6329: An unexpected error has occurred during a password set operation.
“BAIL: MMS(5716): ..\server.cpp(11139): 0x80230626 (The password could not be updated because the management agent credentials were denied access.)
Azure AD Sync 1.0.8641.0″

image

Group Policy Restrictions

Its possible that the errors you see for password writeback in the application log are due to restrictions on the user’s password that they have chosen. If the password is not complex enough then you get a warning in the password reset page the user is visiting in Azure, but you can also get this is a Group Policy restriction is in place even if you have set a strong password. The text in the error message in the Azure password change portal reads “This password does not meet your corporate password policy. Please make sure to use a mix of upper and lowercase letters, numbers, symbols, and to update your password to one that you haven’t used previously.”. Therefore though Azure accepted the passwords (original and new) the on-premises server rejected them with the following:

Event ID 33008: TrackingId: 3c8c78dc-9167-4286-9384-e2f0e777af87, Reason: Synchronization Engine returned an error hr=80230619, message=A restriction prevents the password from being changed to the current one specified., Context: cloudAnchor: User_9b83f544-ba22-4ffb-bff5-c1c2374d654c, SourceAnchorValue: F39SWQrM2EidaboN8UC8Ww==, UserPrincipalName: ethan@contoso.co.uk, Details: Microsoft.CredentialManagement.OnPremisesPasswordReset.Shared.PasswordResetException: Synchronization Engine returned an error hr=80230619, message=A restriction prevents the password from being changed to the current one specified.
   at AADPasswordReset.SynchronizationEngineManagedHandle.ThrowSyncEngineError(Int32 hr)
   at AADPasswordReset.SynchronizationEngineManagedHandle.ChangePassword(String cloudAnchor, String sourceAnchor, String oldPassword, String newPassword)
   at Microsoft.CredentialManagement.OnPremisesPasswordReset.PasswordResetCredentialManager.ChangePassword(String encryptedChangePasswordRequestString, String publicKeyEncryptedSymmetricKey, String publicKeyEncryptedSymmetricIV)

and

Event ID 6329: An unexpected error has occurred during a password set operation.
“BAIL: MMS(5236): ..\server.cpp(11139): 0x80230619 (A restriction prevents the password from being changed to the current one specified.)
Azure AD Sync 1.0.8641.0″

This of course seems self explanatory – your password is not complex enough for your rules on-premises but complex enough to get past the Azure initial checks that it imposes.

image

This error though is especially annoying in test scenarios where you have turned off all the complexity checks. To test why you are getting this error, first check its a password change error and not something else, and try and change the users password on-premises. You should get the same restriction. Then use the cmd prompt to check the password settings for the user.

</p> <p>net user username /domain</p> <p>

This will report the following:

User name                    user1
Full Name                    First Last
Comment
User’s comment
Country/region code          000 (System Default)
Account active               Yes
Account expires              Never

Password last set            7/7/2015 3:19:00 PM
Password expires             Never
Password changeable          7/8/2015 3:19:00 PM
Password required            Yes
User may change password     Yes

Workstations allowed         All
Logon script
User profile
Home directory
Last logon                   7/8/2015 10:31:05 AM

Logon hours allowed          All

Local Group Memberships
Global Group memberships     *Domain Users
The command completed successfully.

image

In this example, notice the highlighted. Here there password minimum age requirement in Group Policy has been removed:

image

But the domain controller (after running gpupdate to force the change to the domain controller) still enforces a single day to allow the change to occur.

For test scenarios, modify group policy to 0 days (rather than not defined) and probably increase the max age from the suggested default of 30 days:

image

After running gpupdate, you get the following for the net user command:

Password last set            7/8/2015 10:42:05 AM
Password expires             Never
Password changeable          7/8/2015 10:42:05 AM

Now you should be able to change your password in Azure against an on-premises user.

Strong Password Required

In the password change portal, the user is required to enter a strong password regardless of any restrictions that you have on-premises. So even if you are testing and have removed all history and complex and renewal requirements for the password, Azure will ensure that a strong password of 7 or more characters is entered regardless of your on-premises policy. In fact, Azure does not know your on-premises policy for password restrictions and enforces its own in addition to the one you have.

You get errors in the portal that read “Strong password required. Combine at least three of the following: uppercase letters, lowercase letters, numbers, and symbols.”. You also cannot reset the password to the same and the errors you get look like the following options:

image image image image 

Success

For completion of the blog, here is what you should see in the event log when it is working:

Event ID 31006: TrackingId: f430189d-984c-41d5-a4a6-333c66ffae1f, ChangePasswordRequestStart, Details: ethan@contosochemists.co.uk

Event ID 31007: TrackingId: f430189d-984c-41d5-a4a6-333c66ffae1f, ChangePasswordSuccess, Details: Context: cloudAnchor: User_9b83f544-ba22-4ffb-bff5-c1c2374d654c, SourceAnchorValue: F39SWQrM2EidaboN8UC8Ww==, UserPrincipalName: ethan@contosochemists.co.uk

Configuring Writeback Permissions in Active Directory for Azure Active Directory Sync

Posted on 45 CommentsPosted in 2008, 2008 R2, 2012, 2012 R2, active directory, ADFS 3.0, Azure, Azure Active Directory, cloud, exchange, exchange online, groups, hybrid, IAmMEC, Office 365, WAP, Web Application Proxy, windows

[This blog post was last updated 5th October 2017 – added support to Exchange Hybrid for msExchDelegateLinkList attribute which was announced at Microsoft Ignite 2017 for the support of keeping auto-mapping working cross on-premises and the cloud]

[Updated 18th June 2017 in advance of the release of AADConnect version 1.1.553.0. This post contains updates to the below scripts to include the latest attributes synced back to on-premises including publicDelegates, which is used for supporting bi-directional sync for “Send on Behalf” of permissions in Exchange Online/Exchange Server hybrid writeback scenarios]

[Update March 2017 – added another blog post on using the below to fix permission-issue errors on admin and other protected accounts at http://c7solutions.com/2017/03/administrators-aadconnect-and-adminsdholder-issues]

Azure Active Directory has been long the read-only cousin of Active Directory for those Office 365 and Azure users who sync their directory from Active Directory to Azure Active Directory apart from eight attributes for Exchange Server hybrid mode. Not any more. Azure Active Directory writeback is now available and in preview for some of the writeback types at the time of writing. This enabled objects to be mastered or changed in Azure Active Directory and written back to on-premises Active Directory.

This writeback includes:

  • Devices that can be enrolled with Office 365 MDM or Intune, which will allow login to AD FS controlled resources based on user and the device they are on
  • “Modern Groups” in Office 365 can be written back to on-premises Exchange Server 2013 CU8 or later hybrid mode and appear as mail enabled distribution lists on premises. Does not require AAD Premium licences
  • Users can change their passwords via the login page or user settings in Office 365 and have that password written back online.
  • Exchange Server hybrid writeback is the classic writeback from Azure AD and is the apart from Group Writeback is the only one of these writebacks that does not require Azure AD Premium licences.
  • User writeback from Azure AD (i.e. users made in Office 365 in the cloud for example) to on-premises Active Directory
  • Windows 10 devices for “Azure AD Domain Join” functionality

All of these features (apart from Exchange Hybrid writeback) require AADConnect and not and of the earlier verions (which will be actively blocked by the end of 2017 anyway). Install and run the AADConnect program to migrate from DirSync to AADSync and then in the Synchronization Options on rerunning the AADConnect wizard you can add all these writeback functions.

In all the below sections you need to grant permission to the connector account. You can find the connector account for your Active Directory forest from the Synchronization Service program > Connectors > double-click your domain > select Connect to Active Directory Forest. The account listed here is the connector account you need to grant permissions to.

SourceAnchor Writeback

For users with (typically) multi-forest deployments or plans or a forest migration, the objectGuid value in Active Directory, which is used as the source for the attribute that keys your on-premises object to your synced cloud object – in AAD sync parlance, this is known as the SourceAnchor. If you set up AADConnect version 1.1.553.0 or later you can opt to change from objectGuid to a new source anchor attribute known as ms-ds-consistencyGuid. To be able to use this new feature you need the ability for AADConnect connector account to be able to read ObjectGUID and then write it back to ms-ds-consistencyGuid. The read permissions are typically available to the connector account without doing anything special, and if AADConnect is installed in Express Mode it will get the write permissions it needs, but as with the rest of this blog, if you are not using Express Mode you need to grant the permissions manually and so write permissions are needed to the ms-ds-consistencyGuid attribute. This can be done with this script.


$accountName = "domain\aad_account" #[this is the account that will be used by Azure AD Connect Sync to manage objects in the directory, this is often an account in the form of MSOL_number or AAD_number].
$ForestDN = "DC=contoso,DC=com"

$cmd = "dsacls '$ForestDN' /I:S /G '`"$accountName`":WP;ms-ds-consistencyGuid;user'"
Invoke-Expression $cmd | Out-Null

Note that if you use ms-ds-consistencyGuid then there are changes required on your ADFS deployment as well. The Issuance Transform Rules for the Office 365 Relying Party Trust contains a rule that specifies the ImmutableID (aka AADConnect SourceAnchor) that the user will be identified as for login. By default this is set to ObjectGUID, and if you use AADConnect to set up ADFS for you then the application will update the rule. But if you set up ADFS yourself then you need to update the rule.

Issuance Transform Rules

When Office 365 is configured to federate a domain (use ADFS for authentication of that domain and not Azure AD) then the following are the claims rules that exist out of the box need to be adjusted. This is to support the use of ms-ds-consistencyguid as the immutable ID.

ADFS Management UI > Trust Relationships > Relying Party Trusts

Select Microsoft Office 365 Identity Platform > click Edit Claim Rules

You get two or three rules listed here. You get three rules if you use -SupportMultipleDomain switch in Convert-MSOLDomainToFederated.
Rule 1:
Change objectGUID to ms-DS-ConsistencyGUID
Rule Was:
c:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname”]
=> issue(store = “Active Directory”, types = (“http://schemas.xmlsoap.org/claims/UPN”, “http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID”), query = “samAccountName={0};userPrincipalName,objectGUID;{1}”, param = regexreplace(c.Value, “(?<domain>[^\\]+)\\(?<user>.+)”, “${user}”), param = c.Value);
New Value:
c:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname”]
=> issue(store = “Active Directory”, types = (“http://schemas.xmlsoap.org/claims/UPN”, “http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID”), query = “samAccountName={0};userPrincipalName,ms-DS-ConsistencyGUID;{1}”, param = regexreplace(c.Value, “(?<domain>[^\\]+)\\(?<user>.+)”, “${user}”), param = c.Value);

Preparing for Device Writeback

If you do not have a 2012 R2 or later domain controller then you need to update the schema of your forest. Do this by getting a Windows Server 2012 R2 ISO image and mounting it as a drive. Copy the support/adprep folder from this image or DVD to a 64 bit domain member in the same site as the Schema Master. Then run adprep /forestprep from an admin cmd prompt when logged in as a Schema Admin. The domain member needs to be a 64 bit domain joined machine for adprep.exe to run.

Wait for the schema changes to replicate around the network.

Import the cmdlets needed to configure your Active Directory for writeback by running Import-Module ‘C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep\AdSyncPrep.psm1’ from an administrative PowerShell session. You need Azure AD Global Admin and Enterprise Admin permissions for Azure and local AD forest respectively. The cmdlets for this are obtained by running the Azure AD Connect tool.


$accountName = "domain\aad_account" #[this is the account that will be used by Azure AD Connect Sync to manage objects in the directory, this is often an account in the form of MSOL_number or AAD_number].
Initialize-ADSyncDeviceWriteBack -AdConnectorAccount $accountName -DomainName contoso.com #[domain where devices will be created].

This will create the “Device Registration Services” node in the Configuration partition of your forest as shown:

image

To see this, open Active Directory Sites and Services and from the View menu select Show Services Node. Also in the domain partition you should now see an OU called RegisteredDevices. The AADSync account now has permissions to write objects to this container as well.

In Azure AD Connect, if you get the error “This feature is disabled because there is no eligible forest with appropriate permissions for device writeback” then you need to complete the steps in this section and click Previous in the AADConnect wizard to go back to the “Connect your directories” page and then you can click Next to return to the “Optional features” page. This time the Device Writeback option will not be greyed out.

Device Writeback needs a 2012 R2 or later AD FS server and WAP to make use of the device info in the Active Directory (for example, conditional access to resources based on the user and the device they are using). Once Device Writeback is prepared for with these cmdlets and the AADConnect Synchronization Options page is enabled for Device Writeback then the following will appear in Active Directory:

image

Not shown in the above, but adding the Display Name column in Active Directory Users and Computers tells you the device name. The registered owner and registered users of the device are available to view, but as they are SID values, they are not really readable.

If you have multiple forests, then you need add the SCP record for the tenant name in each separate forest. The above will do it for the forest AADConnect is installed in and the below script can be used to add the SCP to other forests:

$verifiedDomain = "contoso.com"  # Replace this with any of your verified domain names in Azure AD
$tenantID = "27f998bf-86f2-41bf-91ab-2d7ab011df35"  # Replace this with you tenant ID
$configNC = "CN=Configuration,DC=corp,DC=contoso,DC=com"  # Replace this with your AD configuration naming context
$de = New-Object System.DirectoryServices.DirectoryEntry
$de.Path = "LDAP://CN=Services," + $configNC
$deDRC = $de.Children.Add("CN=Device Registration Configuration", "container")
$deDRC.CommitChanges()
$deSCP = $deDRC.Children.Add("CN=62a0ff2e-97b9-4513-943f-0d221bd30080", "serviceConnectionPoint")
$deSCP.Properties["keywords"].Add("azureADName:" + $verifiedDomain)
$deSCP.Properties["keywords"].Add("azureADId:" + $tenantID)
$deSCP.CommitChanges()

Preparing for Group Writeback

Writing Office 365 “Modern Groups” back to Active Directory on-premises requires Exchange Server 2013 CU8 or later schema updates and servers installed. To create the OU and permissions required for Group Writeback you need to do the following.

Import the cmdlets needed to configure your Active Directory for writeback by running Import-Module ‘C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep\AdSyncPrep.psm1’ from an administrative PowerShell session. You need Domain Admin permissions for the domain in the local AD forest that you will write back groups to. The cmdlets for this are obtained by running the Azure AD Connect tool.

$accountName = "domain\aad_account" #[this is the account that will be used by Azure AD Connect Sync to manage objects in the directory, this is often an account in the form of MSOL_number or AAD_number].
$cloudGroupOU = "OU=CloudGroups,DC=contoso,DC=com"
Initialize-ADSyncGroupWriteBack -AdConnectorAccount $accountName -GroupWriteBackContainerDN $cloudGroupOU

Once these cmdlets are run the AADSync account will have permissions to write objects to this OU. You can view the permissions in Active Directory Users and Computers for this OU if you enable Advanced mode in that program. There should be a permission entry for this account that is not inherited from the parent OU’s.

At the time of writing, the distribution list that is created on writeback from Azure AD will not appear in the Global Address List in Outlook etc. or allow on-premises mailboxes to send to these internal only cloud based groups. To add it to the address book you need to create a new subdomain, update public DNS and add send connectors to hybrid Exchange Server. This is all outlined in https://technet.microsoft.com/en-us/library/mt668829(v=exchg.150).aspx. This ensure’s that on-premises mailboxes can deliver to groups as internal senders and not require external senders enabled on the group. To add the group to the Global Address List you need to run Update-AddressList in Exchange Server. Once group writeback is prepared for using these cmdlets here and AADConnect has had it enabled during the Synchronization Options page, you should see the groups appearing in the selected OU as shown:

image

And you should find that on-premises users can send email to these groups as well.

Preparing for Password Writeback

The option for users to change their passwords in the cloud and have then written back to on-premises (with multifactor authentication and proof of right to change the password) is also available in Office 365 / Azure AD with the Premium Azure Active Directory or Enterprise Mobility Pack licence.

To enable password writeback for AADConnect you need to enable the Password Writeback option in AADConnect synchronization settings and then run the following three PowerShell cmdlets on the AADSync server:


Get-ADSyncConnector | fl name,AADPasswordResetConfiguration
Get-ADSyncAADPasswordResetConfiguration -Connector "contoso.onmicrosoft.com - AAD"
Set-ADSyncAADPasswordResetConfiguration -Connector "contoso.onmicrosoft.com - AAD" -Enable $true

The first of these cmdlets lists the ADSync connectors and the name and password reset state of the connector. You need the name of the AAD connector. The middle cmdlet tells you the state of password writeback on that connector and the last cmdlet enables it if needed. The name of the connector is required in these last two cmdlets.

To set the permissions on-premises for the passwords to be written back the following script is needed:

$passwordOU = "DC=contoso,DC=com" #[you can scope this down to a specific OU]
$accountName = "domain\aad_account" #[this is the account that will be used by Azure AD Connect Sync to manage objects in the directory, this is often an account in the form of MSOL_number or AAD_number].

$cmd = "dsacls.exe '$passwordOU' /I:S /G '`"$accountName`":CA;`"Reset Password`";user'"
Invoke-Expression $cmd | Out-Null

$cmd = "dsacls.exe '$passwordOU' /I:S /G '`"$accountName`":CA;`"Change Password`";user'"
Invoke-Expression $cmd | Out-Null

$cmd = "dsacls.exe '$passwordOU' /I:S /G '`"$accountName`":WP;lockoutTime;user'"
Invoke-Expression $cmd | Out-Null

$cmd = "dsacls.exe '$passwordOU' /I:S /G '`"$accountName`":WP;pwdLastSet;user'"
Invoke-Expression $cmd | Out-Null

Finally you need to run the above once per domain.

Preparing for Exchange Server Hybrid Writeback

Hybrid mode in Exchange Server requires the writing back on eight attributes from Azure AD to Active Directory. The list of attributes written back is found here. The following script will set these permissions for you in the OU you select (or as shown at the root of the domain). The DirSync tool used to do all this permissioning for you, but the AADSync tool does not. Therefore scripts such as this are required. This script sets lots of permissions on these eight attributes, but for clarify on running the script the output of the script is sent to Null. Remove the “| Out-Null” from the script to see the changes as they occur (the script also takes a lot longer to run).

$accountName = "domain\aad_account" #[this is the account that will be used by Azure AD Connect Sync to manage objects in the directory, this is often an account in the form of MSOL_number or AAD_number].
$HybridOU = "DC=contoso,DC=com"

#Object type: user
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;proxyAddresses;user'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchUCVoiceMailSettings;user'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchUserHoldPolicies;user'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchArchiveStatus;user'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchSafeSendersHash;user'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchBlockedSendersHash;user'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchSafeRecipientsHash;user'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msDS-ExternalDirectoryObjectID;user'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;publicDelegates;user'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchDelegateLinkList;user'"
Invoke-Expression $cmd | Out-Null

#Object type: iNetOrgPerson
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;proxyAddresses;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchUCVoiceMailSettings;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchUserHoldPolicies;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchArchiveStatus;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchSafeSendersHash;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchBlockedSendersHash;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchSafeRecipientsHash;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msDS-ExternalDirectoryObjectID;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;publicDelegates;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchDelegateLinkList;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null

#Object type: group
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;proxyAddresses;group'"
Invoke-Expression $cmd | Out-Null

#Object type: contact
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;proxyAddresses;contact'"
Invoke-Expression $cmd | Out-Null

Finally you need to run the above once per domain.

Preparing for User Writeback

[This functionality is not in the current builds of AADConnect]

Currently in preview at the time of writing, you are able to make users in Azure Active Directory (cloud users as Office 365 would call them) and write them back to on-premises Active Directory. The users password is not written back and so needs changing before the user can login on-premises.

To prepare the on-premises Active Directory to writeback user objects you need to run this script. This is contained in AdSyncPrep.psm1 and that is installed as part of Azure AD Connect. Azure AD Connect will install Azure AD Sync, which is needed to do the writeback. To load the AdSyncPrep.psm1 module into PowerShell run Import-Module ‘C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep\AdSyncPrep.psm1’ from an administrative PowerShell session.

$accountName = "domain\aad_account" #[this is the account that will be used by Azure AD Connect Sync to manage objects in the directory, this is an account usually in the form of AAD_number].
$cloudUserOU = "OU=CloudUsers,DC=contoso,DC=com"
Initialize-ADSyncUserWriteBack -AdConnectorAccount $accountName -UserWriteBackContainerDN $cloudUserOU

Once the next AADSync occurs you should see users in the OU used above that match the cloud users in Office 365 as shown:

image

Prepare for Windows 10 Registered Device Writeback Sync

Windows 10 devices that are joined to your domain can be written to Azure Active Directory as a registered device, and so conditional access rules on device ownership can be enforced. To do this you need to import the AdSyncPrep.psm1 module. This module supports the following two additional cmdlets to prepare your Active Directory for Windows 10 device sync:

CD "C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep"
Import-Module .\AdSyncPrep.psm1
Initialize-ADSyncDomainJoinedComputerSync
Initialize-ADSyncNGCKeysWriteBack

These cmdlets are run as follows:

$accountName = "domain\aad_account" #[this is the account that will be used by Azure AD Connect Sync to manage objects in the directory, this is often an account in the form of MSOL_number or AAD_number].
$azureAdCreds = Get-Credential #[Azure Active Directory administrator account]

CD "C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep"
Import-Module .\AdSyncPrep.psm1
Initialize-ADSyncDomainJoinedComputerSync -AdConnectorAccount $accountName -AzureADCredentials $azureAdCreds 
Initialize-ADSyncNGCKeysWriteBack -AdConnectorAccount $accountName 

Once complete, open Active Directory Sites and Services and from the View menu Show Services Node. Then you should see the GUID of your domain under the Device Registration Configuration container.

image

Office 365 MDM (Mobile Device Management) From A Users Perspective

Posted on Leave a commentPosted in ADFS, ADFS 2.0, ADFS 3.0, IAmMEC, MDM, Mobile Device Management, Multi-Factor Authentication, OD4B, ODFB, Office 365, OneDrive, OneDrive For Business, OWA for Devices

The following list of steps and screenshots are taken during the enrolment process to add an iPhone and an Android phone to Office 365 once the free MDM solution that comes with Office 365 is enabled for the user.

Step Details Image from iPhone Image from Android

1.

Once your IT Administrator enables MDM for your Office 365 account you will get the following email on your device if you already have email configured. It may take 24 hours from the admin configuring MDM for this to arrive. Once this email arrives no further email will arrive from that account any device until the devices are enrolled with the company for management.

01 Initial Email Screenshot_2015-06-29-10-55-47

2.

Click “Enrol your device” link in Step 1 of the email. This will take you to the relevant app store of your device to install the Company Portal (iPhone as shown and Android devices). Windows Phone users will see the Workplace Join settings (not shown)
In the iOS example, the Company Portal app is already installed so we can click Open at the top.

For Android to the right, it shows that the app needs installing from the page they see in the App Store.

02 Clicking Enroll Screenshot_2015-06-29-10-56-20
3. Once the app is installed you are required to login. Enter your Office 365 username.
Upon entering your username you will either be directed to your network to login (if your company uses AD FS to login) or you enter the password here. Step 4 shows the AD FS login page, which will probably have your company logo on it.
If your IT department does not use AD FS you enter your password here (the page will wait for you to enter it)
03 Login Page Screenshot_2015-06-29-10-58-51
4. This is an example AD FS login page with company logo. If you are required to login with other information as well as your password you will be prompted for this as well.

04 ADFS Login Page  
5. Upon login being successful your device will start the enrolment process by connecting to both Office 365 and the device manufacturer to download required secure management info. 05 Enrolling Screenshot_2015-06-29-11-00-07
6. For iOS click Enroll to start the process. For Android you need to click Activate.

The company you are enrolling your phone into will have some rights over some of the data on your phone – for example they will be able to remove the work email account from it if you leave the company.

Enrolment conditions will be enforced based on your companies requirement for using phones to access company data, for example a PIN number of a minimum length (see http://bit.ly/o365mdm for more on this)

06 Notice About Enrolling Screenshot_2015-06-29-11-00-55
7. Enrolment goes through a series of steps with the screen changing a few times automatically. Within a seconds you end up at the “Install” screen. Click Install to add the management profile for the displayed company here.

Android and Windows Phone have less steps to go through.

07 Certificate 1 Screenshot_2015-06-29-11-03-50
8. A unique encryption key is generated for your device when using iOS devices.

For Android, you need to accept the compliance requirements configured by your administrator. If you do not complete these requirements then business applications will not be available on the device.

08 Key Generation 1 Screenshot_2015-06-29-11-20-47
9. You need to click install at the personal settings screen when using iOS devices.

For Android, once compliance requirements are set (in this case a PIN number is entered). Note that for iOS, you have 1 hour to enter a PIN number to become compliant, but not for the Android.

09 Warning Screenshot_2015-06-29-11-22-49
10. You need to confirm that you trust this company for remote management of your device when using iOS devices.

For Android you need to name and install the certificate.

10 Install Trust Screenshot_2015-06-29-11-23-05
11. The management profile is installed and you can click Done when using iOS devices. 11 Profile Installed  
12. Device checks that it is enrolled and what the device settings are and if these settings are compatible with the companies required restrictions on the device.

On Android you may get a prompt about entering a PIN number or other compliance requirements if you did not enter them earlier

12 Checking  
13. Enrolment is confirmed. Notice that my device(s) are displayed and my current device is not compliant with company policy (the red exclamation mark).

For Android devices, the My Devices tab will show your devices, including if there are any compliance issues.

13 Enrolled  
14. Clicking my device in the Company Portal app shows the compliance status of the device. Here the device is still checking compliance 14 Checking Compliance 1st Time  
15 And here the device is shown not to be compliant.

For Android devices not in compliance, it shows an Enrollment update available (if you did not meet compliance requirements during the Company App enrollment process) or if you are not compliance (for example device is not encrypted) then it will show that the device is not in compliance as shown.

15 Not In Compliance Screenshot_2015-06-29-11-36-13
16 Details on compliance state is iOS shows the “This device is not in compliance” message.

Further details on the compliance failure are shown under the message. In this case the iOS device is unable to set up an email profile on the device and the Android devices need a longer password and device encryption

16 Not In Compliance Details Screenshot_2015-06-29-11-36-27
17 Clicking the “Unable to set up email on the device” message shows the full details. In this case the device already has an email profile configured and for the iPhone this needs to be removed and the Company Portal will recreate it. It is this recreated email profile that the iPhone/iPad can manage.

Android and Windows Phone users do not need to delete their email profile and have the device recreate it but Compliance requirements must still be met.

17 Actual Reason for not in compliance Screenshot_2015-06-29-11-37-47
18 For the iPhone/iPad the steps to delete the existing profile are Settings > Mail, Contacts, Calendars > Click the email profile > click Delete Account

For Android, if the device is compliant in the Company App then you need to check Exchange Server to validate this for you so that your email continues to work. Back in the email program view the enrollment email as shown – click hyperlink #2 in the email and sign into the web based Device portal

18 Deleting original email profile Screenshot_2015-06-29-11-57-54
19 Once the account is deleted on the iOS device it is not visible in the list of email accounts.

In this example the iCloud account remains along with two Exchange / Office 365 accounts that are not managed by MDM. You can only have one MDM managed account per device at any given time.

Other compliance settings may be required such as a PIN number. You have 60 minutes in iOS to enable this if required.

19 Seeing list of email profiles - work email is gone  
20 Once the Company App checks for compliance again and if you are compliant, a new email profile for your work appears. Clicking it (called “Office 365 email”) requires entry of your password.

In Android, once the device is shown as compliant in #2 of the email, click the hyperlink for #3 in the email. Click Allow on the certificate prompt if you see one.

20 Work Email Profile Arrives Screenshot_2015-06-29-12-00-26
21 You then see the email profile created. Compare this to the image in Step 19 for the difference.

An Android, you will be informed that your device has successfully authenticated for email.

21 Email Configured Automatically Screenshot_2015-06-29-12-00-40
22 It is possible to rename the email profile. In this case it is via Settings > Email, Contacts, Calendars > Office 365 email > Account and then change the “Description” value 22 Renaming Email Profile  
23 Updated email profile listed 23 Email Profile listed  
24 Email should now sync with your device again. Notice that the email about needing to set up MDM is now missing and has been removed automatically.

On the Android, drag the Inbox screen down to refresh it and your emails will appear.

24 Email available on device, enrollment email not available now Screenshot_2015-06-29-12-01-57
25 Now that the device is compliant (excepting the PIN number, which gives you 60 minutes of grace to complete this step) you can start other Office 365 aware applications. Here we are going to sign into OneDrive and show our OneDrive for Business data 25 Other Apps Screenshot_2015-06-29-12-03-12
26 Your app requires a login 26 Login for other apps Screenshot_2015-06-29-12-03-58
27 Which if you have an AD FS additional login you may also see 27 ADFS Login  
28 Your other app is now working, and in the case of OneDrive for Business did not need configuring 28 Other App Also Working