Malware Filter Policy Updates in Office 365

Posted on Leave a commentPosted in EOP, exchange online, Exchange Online Protection, malware, Office 365

In March I wrote a blog post that showed how to take the attachment filter list from Edge Server and add those attachment block types to EOP, as EOP had a very small list of attachments.

Today on one of my client tenants I noticed this precanned list of attachment extension types is now at 96 items, which is a considerable change from the list back in March 2017. The list in March was ace, ani, app, docm, exe, jar, reg, scr, vbe, vbs and still is for some tenants at the time of writing.

But while Microsoft has added new attachment types to the picker UI, there was no notification to the end client administrators that they might want to update their MalwareFilterPolicy to take account of these new attachment types that Microsoft have considered worthy of being blocked.

Therefore, now is the time to check your existing MalwareFilterPolicy to include the new extension types (listed below).

For reference, the new attachment filter types that have been added since March 2017 are asp,cer,der,dll,dos,gadget,Hta,Inf,Ins,Isp,Its,Jse,Ksh,Lnk,mad,maf,mag,mam,maq,mar,mas,mat,mau,mav,maw,msh,msh1,msh1xml,msh2,msh2xml,mshxml,obj,os2,plg,pst,rar,tmp,vsmacros,vsw,vxd,w16,ws

But notice that some of these are initial capital versions of entries that are already there (i.e. hta was in the list or on Edge server a few months ago, but now Hta is on the list as well).

I am assuming attachment blocking is not case sensitive and so the following extensions are if added from the attachment list picker will be duplicates – Hta, Inf, Ins, Jse, Ksh.

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.

Administrators, AADConnect and AdminSDHolder Issues (or why are some accounts having permission-issue)

Posted on 1 CommentPosted in AADConnect, AADSync, active directory, AdminSDHolder, dirsync, exchange, exchange online, hybrid, Office 365

AdminSDHolder is something I come across a lot, but find a lot of admins are unaware of it. In brief it is any user that is a member of a protected group (i.e. Domain Admins) will find that their AD permission inheritance and access control lists on their AD object will be reset every hour. Michael B. Smith did a nice write-up on this subject here.

AdminSDHolder is an AD object that determines what the permissions for all protected group members need to be. Why this matters with AADConnect and your sync to Azure Active Directory (i.e. the directory used by Office 365) is that any object that the AADConnect service cannot read cannot be synced, and any object that the AADConnect service cannot write to can be targeted by writeback permissions. This blog post was last updated 18th June 2017 in advance of the release of AADConnect version 1.1.552.0.

For the read permissions this is less of an issue, as the default read permissions by every object is part of a standard Active Directory deployment and so you will find that AdminSDHolder contains this permission and therefore protected objects can be read by AADConnect. This happens in reality becase Authenticated Users have read permissions to lots of attributes on the AdminSDHolder object under the hidden System containing in the domain. Unless your AD permissions are very locked down or AdminSDHolder permissions have been changed to remove Authenticated Users you should have no issue in syncing admin accounts, who of course might have dependencies on mailboxes and SharePoint sites etc. and so need to be synced to the cloud.

Writeback though is a different ball game. Unless you have done AADConnect with Express settings you will find that protected accounts fail during the last stage of AADConnect sync process. You often see errors in the Export profile for your Active Directory that list your admin accounts. Ofter the easiest way to fix this is to enable the Inheritance permission check box on the user account and sync again. The changes are now successfully written but within the hour this inheritance checkbox will be removed and the default permissions as set on AdminSDHolder reapplied to these user accounts. Later changes that need written back from the cloud will result in a failure to writeback again, and again permission issues will be to blame.

To fix this we just need to ensure that the AdminSDHolder object has the correct permissions needed. This is nothing more than doing what the AADConnect Express wizard will do for you anyway, but if you don’t do the Express wizard I don’t think I have seen what you should do documented anywhere – so this is the first (maybe).

Often if you don’t run Express settings you are interested in the principal of least privilege and so the rest of this blog post will outline what you will see in your Active Directory and what to do to ensure protected accounts will always sync and writeback in the Azure Active Directory sync engine. I covered the permissions to enable various types of writeback permissions in a different blog post, but the scripts in this post never added the correct write permissions to AdminSDHolder, so this post will cover what to do for your protected accounts.

First, take a look at any protected account (i.e. one that is a member of Domain Admins):
image

You will see in the Advanced permissions dialog that their is an “Enable Inheritance” button (or a check box is unchecked in older versions of Active Directory. You will also notice that all the permissions under the “Inherited From” column read “None” – that is there are no permissions inherited. You will also see, as shown in the above dialog, that if Express settings have been run for your AADConnect sync service that a access control entry for the AADConnect service account will be listed – here this is MSOL_924f68d9ff1f (yours will be different if it exists) and has read/write for everything. This is not least privilege! If you have run the sync engine previously on different servers and later removed them (as the sync engine can only run on one server to one AAD tenant, excluding staging servers) then you might see more than one MSOL account. The description field of the account will show what server it was created on for your information.

If you compare your above admin account to a non-protected account you will see inheritance can be disabled and that the Inherited From column lists the source of the permission inheritance.

Compare the access control entries (ACE) to the list of ACE’s on the AdminSDHolder object. AdminSDHolder can be found at CN=AdminSDHolder,CN=System,DC=domain,DC=local. You should find that the protected accounts match those of the AdminSDHolder, or at least will within the hour as someone could have just changed something.

Add a permission ACE to AdminSDHolder and it will appear on each protected account within an hour, remove an ACE and it will go within the hour as well. So you could for example remove the MSOL_ account(s) from older ADSync deployments and tidy up your permissions as well.

This is what my Advanced permissions for AdminSDHolder looks like on my domain

image

If I add the relevant ACE’s here for the writeback permissions then within the hour, and then for syncs that happen after that time, the errors for writeback in the sync management console will go away. Note though that AdminSDHolder is per domain, so if you are syncing more than one domain you need to set these permissions on each domain.

To script these permissions, run the following in PowerShell to update AD permissions regarding to the different hybrid writebacks scenarios that you are interested in implementing.

Finding All Your AdminSDHolder Affected Users

The following PowerShell will let you know all the users in your domain who have an AdminCount set to 1 (>0 in reality), which means they are impacted by AdminSDHolder restrictions. The changes below directly on the AdminSDHolder will impact these users as their permissions will get updated to allow writeback from Azure AD.

get-aduser -Filter {admincount -gt 0} -Properties adminCount -ResultSetSize $null | FT DistinguishedName,Enabled,SamAccountName

SourceAnchor Writeback

This setting is needed for all installations since version 1.1.552.0.

$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 or MSOL_number].
$AdminSDHolder = "CN=AdminSDHolder,CN=System,DC=contoso,DC=com"

$cmd = "dsacls.exe '$AdminSDHolder' /G '`"$accountName`":WP;ms-ds-consistencyGuid'"
Invoke-Expression $cmd | Out-Null

Password Writeback

The following PowerShell will modify the permissions on the AdminSDHolder object so that protected accounts can have Self Service Password Reset (SSPR) function against the accounts. Note you need to change the DC values in the script for it to function against your domain(s).

To determine the account name that permissions must be granted to, open the Synchronization Service Manager on the sync server, click Connectors and double click the connector to the domain you are updating. Under the Connect to Active Directory Forest item you will see the Forest Name and User Name. The User Name is the name of the account you need in the script. An example is shown below:

image

$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 or MSOL_number].
$AdminSDHolder = "CN=AdminSDHolder,CN=System,DC=contoso,DC=com"

$cmd = "dsacls.exe '$AdminSDHolder' /G '`"$accountName`":CA;`"Reset Password`"'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls.exe '$AdminSDHolder' /G '`"$accountName`":CA;`"Change Password`"'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls.exe '$AdminSDHolder' /G '`"$accountName`":WP;lockoutTime'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls.exe '$AdminSDHolder' /G '`"$accountName`":WP;pwdLastSet'"
Invoke-Expression $cmd | Out-Null

Exchange Hybrid Mode Writeback

The below script will set the permissions required for the service account that AADSync uses. Note that if Express mode has been used, then an account called MSOL_AD_Sync_RichCoexistence will exist that has these permissions rather than being assigned directly to the sync account. Therefore you could change the below permissions to utilise MSOL_AD_Sync_RichCoexistence rather than AAD_ or MSOL_ and achieve the same results, but knowing that future changes to the MSOL_ or AAD_ account will be saved as it was done via a group.

The final permission in the set is for msDS-ExternalDirectoryObjectID and this is part of the Exchange Server 2016 (and maybe Exchange Server 2013 later CU’s) schema updates. Newer documentation on AAD Connect synchronized attributes already has this attribute listed, for example in Azure AD Connect sync: Attributes synchronized to Azure Active Directory

$accountName = "domain\aad_account"
$AdminSDHolder = "CN=AdminSDHolder,CN=System,DC=contoso,DC=com"

$cmd = "dsacls '$AdminSDHolder' /G '`"$accountName`":WP;proxyAddresses'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$AdminSDHolder' /G '`"$accountName`":WP;msExchUCVoiceMailSettings'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$AdminSDHolder' /G '`"$accountName`":WP;msExchUserHoldPolicies'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$AdminSDHolder' /G '`"$accountName`":WP;msExchArchiveStatus'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$AdminSDHolder' /G '`"$accountName`":WP;msExchSafeSendersHash'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$AdminSDHolder' /G '`"$accountName`":WP;msExchBlockedSendersHash'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$AdminSDHolder' /G '`"$accountName`":WP;msExchSafeRecipientsHash'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$AdminSDHolder' /G '`"$accountName`":WP;msDS-ExternalDirectoryObjectID'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$AdminSDHolder' /G '`"$accountName`":WP;publicDelegates'"
Invoke-Expression $cmd | Out-Null

Once these two scripts are run against AdminSDHolder object and you wait an hour, the permissions will be applied to your protected accounts, then within 30 minutes (based on the default sync time) any admin account that is failing to get cloud settings written back to Active Directory due to permission-issue errors will automatically get resolved.

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

RC4 Kerberos and AD FS Issues

Posted on Leave a commentPosted in ADFS, kerberos, Office 365

It has become common place to consider the position of the RC4 cipher in TLS connections, but this is not something that you can take from a TLS connection (HTTPS) and assume the same for Kerberos connections. If you do disable RC4 for Kerberos then there are some things to consider, especially is you have ADFS servers in place and multiple forests that are trusted.

If RC4 is disabled in group policy and the trusted domain is Forest Functional Level 2003 then your ADFS logins across the trusts are not going to work. You need a FFL of 2008 (maybe R2) to support AES authentication across the trust (and to ensure the trust supports AES in the trust settings) before you can turn of RC4.

If you have disabled RC4 in the ADFS domain and you try and login with an account in a FFL 2003 trusted forest then Kerberos auth will fail, ADFS will be unable to read the token (the encryption type is wrong) and the fields of the SAML token are invalid. You get a lovely error in ADFS Debug logs that reads as follows (Event ID: 52):

ServiceHostManager.LogFailedAuthenticationInfo: Token of type ‘http://schemas.microsoft.com/ws/2006/05/identitymodel/tokens/UserName’ validation failed with following exception details:

System.ArgumentOutOfRangeException: Not a valid Win32 FileTime.

Parameter name: fileTime at System.DateTime.FromFileTimeUtc(Int64 fileTime) at Microsoft.IdentityServer.Service.Tokens.LsaLogonUserHelper.GetPasswordExpiryDetails(SafeLsaReturnBufferHandle profileHandle, DateTime& nextPasswordChange, DateTime& lastPasswordChange) at Microsoft.IdentityServer.Service.Tokens.LsaLogonUserHelper.GetLsaLogonUserInfo(SafeHGlobalHandle pLogonInfo, Int32 logonInfoSize, DateTime& nextPasswordChange, DateTime& lastPasswordChange, String authenticationType, String issuerName) at Microsoft.IdentityServer.Service.Tokens.LsaLogonUserHelper.GetLsaLogonUser(UserNameSecurityToken token, DateTime& nextPasswordChange, DateTime& lastPasswordChange, String issuerName) at Microsoft.IdentityServer.Service.Tokens.MSISWindowsUserNameSecurityTokenHandler.ValidateTokenInternal(SecurityToken token) at Microsoft.IdentityServer.Service.Tokens.MSISWindowsUserNameSecurityTokenHandler.ValidateToken(SecurityToken token)

The GPO setting that removes RC4 encryption needs to be enabled on the domain controllers and on the ADFS servers. This policy is found under the “Network security: Configure encryption types allowed for Kerberos” option as per https://technet.microsoft.com/en-us/library/jj852180(v=ws.11).aspx with only DES and AES.

If this is your issue, then reenable RC4 for Kerberos on the domain controllers and recreate the trust between the forests. Recreating trust after enabling RC4 in GPO meant the new password’s RC4 related keys were stored in the trust object related user account’s password. Then TGT could be decrypted and used for Kerberos successfully.

Securing Your Windows 10 Login With Yubikey

Posted on 2 CommentsPosted in MFA, MVP, security, yubikey

The Yubikey is a small USB connected hardware device that can generate a variety of security codes. Being virtually indestructible and easy to clip to a key ring (Yubikey 4) or leave inside your only device (Yubikey 4 Nano) you can now use this token to login to Windows. Once you have got your token from Yubico (via Amazon or other resellers) for around £40 you start the very simple Windows Hello authentication registration process by downloading the Yubikey app from Windows App Store.  Signing in after a restart requires full credentials (password or PIN), which means a stranger who steals your PC and the YubiKey can’t use it to access your device

Open the Store app, search for Yubikey and click the logo for the app.

image

Click the Get button to install the app then then launch to start it. In a corporate environment you can push the app to your devices with MDM solutions like Intune.

Launch the app. You will need to have a PIN login enabled for the device to work and so you will see a warning if you do not have this enabled.

image

If you need to set up a PIN then close the Yubikey app and type “PIN” in the search box in Windows and choose “Setup PIN sign-in”

image

Scroll down and click Add under PIN. You will need to reenter your password so other people cannot set up a PIN on your behalf.

Enter a PIN and confirm the same PIN

image

You will now be able to use a PIN to sign in. The PIN setup process will continue and you will be asked to confirm your PIN again. You can now use your PIN to sign into your computer, which as it is tied to the computer hardware, is more secure than your password. But we are not stopping there – we can now restart the Yubikey app. Either launch it from the Store app, from the search box on the Start Menu or From the Start menu, select All Apps >Start > YubiKey for Windows Hello

image

Click Register to start the process of pairing your Yubikey to your computer

image

Insert your Yubikey into any USB port on the PC and press Continue

image

Name the Yubikey, as at login it will ask you to insert this named key. Click Continue once you have a name

image

At this point it should register the device and all is good!

If you find that Windows Companion Devices are disabled then you will get this error:

image

It reads “Oh no! An error occurred during registration. Windows companion devices are disabled on this system. Contact your system administrator”. This is because the local security policy on your computer or network via your Active Directory and IT driven polices does not allow companion devices. On systems running Windows Pro or Windows Enterprise systems, you must enable the option to Allow companion device for secondary authentication in the Local Security Policy. If your organization manages your security policy, contact your IT administrator and request this change before installing this app. You cannot change local security policy on systems running Windows Home, however this option is enabled by default. Note that you will also get this on domain joined systems as well, as secondary auth is not supported on domain joined machines (even for individual users) at this time.

To modify local security policy

  1. Open the Local Group Policy Editor. To do this, press the Windows key, type R, and then type gpedit.msc.
  2. In the Local Group Policy Editor, from the top level Local Computer Policy, navigate to Computer Configuration > Administrative Templates > Windows Components > Microsoft Secondary Authentication Factor.
  3. In the right pane, click the link to Edit policy setting. (You can also double-click the setting to Allow companion device for secondary authentication.) The default state is Not configured.
  4. In the setting screen, select the option for Enabled, and click OK. If this option is already selected, your policy is set and you can click Cancel.
  5. Exit the Local Group Policy Editor and the Management Console.

Azure Information Protection General Troubleshooting

Posted on 1 CommentPosted 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

AADConnect Password Reset Date Sync Issues

Posted on 2 CommentsPosted in AADConnect, active directory, Azure Active Directory, Azure AD, sync error

Got this error the other day at a client and found nothing listed on Internet search for it, which of course means only I have this issue! But even so, lets get to see what it means and how to fix it.

The error turned up in the AADConnect tool and it reported sync-generic-failure on the Delta Synchronization stage when pulling data from Active Directory.

Error in evaluation of expression: IIF(IsPresent([pwdLastSet]),CStr(FormatDateTime(DateFromNum([pwdLastSet]),”yyyyMMddHHmmss.0Z”)),NULL) 
. Sync Rule: In from AD – User AccountEnabled
Destination: pwdLastSet

Following the above error was the entire stack dump of the issue (a few pages of errors) which are visible by clicking the sync-generic-failure link in AADConnect and clicking the Stack Trace button. Buried inside the stack dump are a few “InnerException” errors. These point out the real cause of the issue.

InnerException=>
Argument 1 to function DateFromNum is out of range.

and

InnerException=>
Not a valid Win32 FileTime.
Parameter name: fileTime

   at System.DateTime.FromFileTimeUtc(Int64 fileTime)
   at SyncRuleExpressions.FunctionLibrary.DateTimeFunctions.DateFromNum(Value[] arguments)

This shows that the user in question (which is listed by DN in the stack dump) has an invalid value for the pwdLastSet attribute.

So we opened up the user and viewed the pwdLastSet value and it read -1

Now this value is valid – it is used in code and scripts to set this attribute to the current date and time, as normally this value is set by a script and so setting -1 means that you want the time for the last password set to be now.

In my clients domain either the script failed or something else did not work, and the property was set and stayed at -1 in the directory. Viewing this attribute in adsiedit showed it to be <never> and double-clicking this attribute showed the value to be -1.

In the end the fix was simple – we retyped -1 into the field in adsiedit and clicked OK. This time the attribute updated to the current date and time. Now that the attribute was a valid date/time, the AADConnect sync rule worked and the object was synced to Azure AD.

Installing and Updating Microsoft AntiMalware in Azure

Posted on Leave a commentPosted in Uncategorized

The Microsoft AntiMalware agent is a virtual machine extension in Azure that adds support for build in antimalware management within your virtual machines hosted in Azure. The agent can be added easily when you are creating a new VM, which we will show first below using the resource manager model, but also can be added after the virtual machine creation and updated with changes as you need. We will show how to do that in the section part of this article.

Adding AV protection to new VM

The addition of malware protection to your new virtual machine happens during the VM creation process. To add it create a new VM in the Azure portal and from the Settings blade choose Extensions
Click Add Extension:

image
Click Add extension and then choose Microsoft Antimalware

image
From the Install Extension blade enter your exclusions, scan times etc. as required:

image

To enable antimalware with the default configuration, click Create on the Add Extension blade without inputting any configuration setting values. To enable antimalware with a custom configuration, input the supported values for the configuration settings provided on the Install Extension blade and click OK. Monitoring the antimalware is done via Windows Event Logs and is enabled automatically to your selected storage account.

Before you click OK, click Automation Options and grab the scripts needed to modify this extension later.  Copy the Template text into Wordpad (not Notepad) and then copy paste again into Notepad if you want to just quickly edit it. Or use an editor of your choice, but make sure the line breaks etc. remain the same as directly pasting into Notepad breaks the line breaks!

Click the PowerShell tab (shown) and copy the code from here. This code is used to upload the template that you just downloaded with changes to allow you to adjust the settings on the Microsoft Antimalware settings on your virtual machine later. See more on that below.

image

Once you have downloaded or copied the code close the Template blade and click OK on the Install extension blade.

Click OK on the Extensions blade. Click OK to create your virtual machine.

Adding Microsoft Antimalware To existing virtual machines

To customise the Microsoft Antimalware extension on an existing virtual machine or to install it on a virtual machine where it does not exist becuase it was not added when the server was initially provisioned. Both of these scenarios, updating settings and adding new are covered in this section.

Both of these scenarios require scripting and cannot be configured in the portal, unlike the install during virtual machine provisioning.

Adding Microsoft Antimalware to an existing virtual machine

The first thing that you need to do to add Microsoft Antimalware is the template. If you ran through the above steps you would have downloaded the template as an additional step in the creation process. If you did not grab a copy of the template then it looks similar to this. The template provided by Microsoft takes input from the PowerShell that you also downloaded. In its simplist form it can be reduced to the following:

{
 "AntimalwareEnabled": true,
 "RealtimeProtectionEnabled": "true",
 "ScheduledScanSettings": {
   "isEnabled": "false",
    "day": "7",
    "time": "120",
    "scanType": "Quick"
  },

  "Exclusions": {
    "Extensions": "",
    "Paths": "",
    "Processes": ""
  }
}

To customise this template just each of the values and save the file to the filesystem. If you use the above template without change then you get the default settings for the extension, so the “blank” template is actually functional. In the template Paths is a semicolon delimited list of file paths or locations to exclude from scanning, where each path is escaped, so for example c:\\temp\\blog would be the value if you wanted to exclude c:\temp\blog and all subdirectories from being scanned. Extensions is again a semicolon separated list starting with the dot, so “.ci;.edb;.log;” would be a valid string. Processes is again semicolon separated list of processes. RealtimeProtectionEnabled and isEnabled are true or false and day is 1=Sunday and 7=Saturday etc. Time is the number of hours past midnight, so 180 is 3am

We will take the default template and use it to add the extension to an existing virtual machine that does not have the extension.

To add the extension to an existing virtual machine we need to login to Azure using PowerShell. This starts with Login-AzureRmAccount cmdlet. Once you are logged in, if you have more than one subscription, use Select-AzureRmSubscription to select the subscription that contains your virtual machine.

To check if Microsoft Antimalware is already enabled on a virtual machine run the following PowerShell:

$resourceGroupName = "<name of resource group>"
$vmname = "<name of vm>"
Get-AzureRmVMExtension -ResourceGroupName $resourceGroupName –VMName $VMName -Name "IaaSAntimalware"

If some JSON is returned, then the Microsoft Antimalware extension (IaaSAntimalware) is enabled on this virtual machine. Note that PublicSettings “AntimalwareEnabled:” shows if the extension is actually running on the virtual machines, and not just that the extension exists on the virtual machine. If an error is returned then the extension is not enabled on the virtual machine.

To add the extension to an existing virtual machine you either need the full template JSON file above, if you want lots of customization, or if you want to do it simply then you can use a very small bit of JSON:

‘{ "AntimalwareEnabled": true,"RealtimeProtectionEnabled": true}’;

The above JSON enables the AV software and turns on real time protection. If you want more control, use the full JSON file above, with your customizations, saved to the filesystem.

The code to use the above JSON or the JSON file is:

# Use this "-SettingString $SettingsString" value for simple setup 
$SettingsString = ‘{ "AntimalwareEnabled": true,"RealtimeProtectionEnabled": true}’;
# Use this "-SettingString $MSAVConfigfile" to configure from JSON file
$MSAVConfigfile = Get-Content "C:\Scripts\IaaSAntimalware.json" -Raw

The code to add the extension is as follows. To run the below you need to set the $location variable to the same location string as the virtual machine. To get this you can run:

$location = (Get-AzureRmVM -VMName $VMName -resourceGroupName $resourceGroupName).location

You also need the available version numbers for the extension, and to use the latest version of the extension. To work this out you need the following script snippet:

$allVersions= (Get-AzureRmVMExtensionImage -Location $location -PublisherName "Microsoft.Azure.Security" -Type "IaaSAntimalware").Version
$typeHandlerVer = $allVersions[($allVersions.count)–1]
$typeHandlerVerMjandMn = $typeHandlerVer.split(".")
$typeHandlerVerMjandMn = $typeHandlerVerMjandMn[0] + "." + $typeHandlerVerMjandMn[1]

So to actually set the extension on the virtual machine, run the following:

Set-AzureRmVMExtension -ResourceGroupName $resourceGroupName -VMName $VMName -Name "IaaSAntimalware" -Publisher "Microsoft.Azure.Security" -ExtensionType "IaaSAntimalware" -TypeHandlerVersion $typeHandlerVerMjandMn -SettingString $SettingsString -Location $location

Customizing Microsoft Antimalware deployments in Azure

Once the extension is enabled you can customize the settings by uploading a config file or settings string with adjusted settings. For example is I took a copy of my above config file and changed time so the value was now 180 (instead of 120 as shown) and I set an Extensions and Paths value in the file, then I would update my virtual machine using the following:

$MSAVConfigfile = Get-Content "C:\temp\blog\Antimalware Azure\antimalware-edit.json" -Raw
Set-AzureRmVMExtension -ResourceGroupName $resourceGroupName -VMName $VMName -Name "IaaSAntimalware" -Publisher "Microsoft.Azure.Security" -ExtensionType "IaaSAntimalware" -TypeHandlerVersion $typeHandlerVerMjandMn -SettingString $MSAVConfigfile -Location $location

The other values have not changed from the above, so you still need to work out $typeHandlerVerMjandMn, $location etc.

Once you have applied the settings then you can use Get-AzureRmVMExtension -ResourceGroupName $resourceGroupName –VMName $VMName -Name “IaaSAntimalware” to check the settings have applied – it usually takes a minute or two for the correct data to be returned to show the change in place.