Zoho Banner September 2011

Archive for the ‘O365’ Category

This article explains how to link your O365 tenant to an existing Microsoft Azure subscription, so that you can manage your O365 users from within Azure. Why would you want to do this? Well, perhaps you just want to centralise your administration functions, but it also gives you other benefits, such as the ability to assign Multi-Factor Authentication (MFA) and to control the cloud applications to which the users have access.

Here’s how I did it…

I have an Office 365 Small Business tenant as well as a Microsoft Azure account that I fund through my MSDN subscription’s monthly credit. Until a couple of months ago I managed these as completely separate entities, logging in with separate credentials for each. Then a friend (thanks Kev!) sent me some information on how to link the O365 directory to my existing Azure account. The process is made possible by the fact that all O365 tenant identities are stored in Azure Active Directory (AAD). Here’s a brief overview of the process:

In this example I manage my existing Azure subscription using my Microsoft Account (formerly Windows Live ID) named passport@activedir.org.  My O365 tenant is named Badger Lafarge (badgerlafarge.onmicrosoft.com)

1. Sign in to Microsoft’s Azure Management Portal with your Account Administrator account, e.g. passport@activedir.org

2. Select Active Directory from the left hand menu bar.

3. Choose New from the bottom menu bar.

custom_create

4. Select APP SERVICES->ACTIVE DIRECTORY->DIRECTORY->CUSTOM CREATE

5. Choose Existing Directory from the drop down list

existing_directory

 

existing_directory2

6. When re-directed to the sign-in page, sign-in with your O365 admin account credentials

sign_in_o365

7. Select continue when prompted and then sign back in with your Azure Account Administrator account

confirm

8. You should now see your O365 tenant listed as a new directory (see below)

aad_O365_tenant

 

That’s it! At this point you are ready to manage your O365 accounts via the Azure Portal (or via Powershell of course).

In a follow-up article I will explain how to enable these accounts for multi-factor authentication (MFA).

 

 

 

 

 

It seems that a couple of weeks ago my standalone Exchange Online Protection (EOP) configuration was changed without me being involved. Basically, it looks like my default Accepted Domain was changed from type “Internal Relay” to “Authoritative” without my knowledge or consent.

The first I knew of this was when I noticed my on-premises mail server was no longer receiving email. The current usage is low, so I didn’t notice it for a couple of weeks. After some troubleshooting I pinned the problem down to the fact that the Accepted Domain was showing as “Authoritative”. After changing it back to “Internal Relay” mail started getting delivered to my on-prem server almost immediately.

Accepted Domains

I have no delegated admins for this service, so nobody could have gone rogue on me. I have also checked the admin audit logs and the only entries shown for modifying the Accepted Domains configuration are a) when I originally set it up last September and b) when I changed it back yesterday. Here are a few screenshots to show the evidence.

Firstly the graph below shows when mail stopped being received…

graph

 

…then the audit entries showing when I made modifications to the mail.activedir.org Accepted Domain. It only shows the two entries. The first was when I set up the service last September and the second was when I made the change from “Authoritative” to “Internal Relay”yesterday.

 

EOP_audit2

 

 

EOP_audit1

It looks like I don’t have access to the external admin audit log report. It doesn’t appear in my EAC view (see below), so perhaps it is simply not available to EOP-only subscriptions. This might have been insightful as the the log apparently shows actions performed by datacentre administrators, which is where I believe the change was made.

 

Audit_View

Given the external admin audit log report wasn’t available via the EAC, I thought I would try to invoke it via Powershell. All I got from the output was the changes that I had made in the portal, i.e. no external admin entries.

 

PS C:\> Search-AdminAuditLog -ExternalAccess $true

RunspaceId         : 4e7bfd93-6f40-493b-b294-4f936506f863
ObjectModified     : FFO.extest.microsoft.com/Microsoft Exchange Hosted Organizations/fisheaglelimited2014.onmicrosoft.com/Configuration/mail.activedir.org
CmdletName         : Set-AcceptedDomain
CmdletParameters   : {MatchSubDomains, Identity, DomainType}
ModifiedProperties : {AcceptedDomainFlags, AcceptedDomainType}
Caller             : tony@mail.activedir.org
ExternalAccess     : 
Succeeded          : True
Error              : None
RunDate            : 5/03/2015 1:44:26 a.m.
OriginatingServer  : DB3FFO11WS056 (15.01.0099.000)
Identity           : e7054efb-d9f5-461a-9c85-08d224fd0c3a
IsValid            : True
ObjectState        : New

PS C:\> $now = get-date

PS C:\> $start = $now.AddYears(-1)

PS C:\> Search-AdminAuditLog -ExternalAccess $true -StartDate $start -EndDate $now

RunspaceId         : 4e7bfd93-6f40-493b-b294-4f936506f863
ObjectModified     : FFO.extest.microsoft.com/Microsoft Exchange Hosted Organizations/fisheaglelimited2014.onmicrosoft.com/Transport Settings/FE Outbound
CmdletName         : New-OutboundConnector
CmdletParameters   : {TlsDomain, CloudServicesMailEnabled, TlsSettings, Enabled...}
ModifiedProperties : {ConfigurationUnit, SmartHostType, Id, OrganizationId...}
Caller             : tony@fisheaglelimited2014.onmicrosoft.com
ExternalAccess     : 
Succeeded          : True
Error              : None
RunDate            : 7/09/2014 8:57:44 p.m.
OriginatingServer  : AM1FFO11WS040 (15.00.1010.011)
Identity           : ec85e346-1d12-4ab0-2067-08d198f581a9
IsValid            : True
ObjectState        : New

RunspaceId         : 4e7bfd93-6f40-493b-b294-4f936506f863
ObjectModified     : FFO.extest.microsoft.com/Microsoft Exchange Hosted Organizations/fisheaglelimited2014.onmicrosoft.com/Transport Settings/FE Inbound
CmdletName         : New-InboundConnector
CmdletParameters   : {SenderIPAddresses, CloudServicesMailEnabled, RestrictDomainsToCertificate, Enabled...}
ModifiedProperties : {ConfigurationUnit, Id, OrganizationId, RawName...}
Caller             : tony@mail.activedir.org
ExternalAccess     : 
Succeeded          : True
Error              : None
RunDate            : 8/09/2014 1:17:15 a.m.
OriginatingServer  : AM1FFO11WS002 (15.00.1019.000)
Identity           : 50f7f697-a501-4106-56a9-08d19919c2fb
IsValid            : True
ObjectState        : New

RunspaceId         : 4e7bfd93-6f40-493b-b294-4f936506f863
ObjectModified     : FFO.extest.microsoft.com/Microsoft Exchange Hosted Organizations/fisheaglelimited2014.onmicrosoft.com/Configuration/FE Outbound
CmdletName         : Set-OutboundConnector
CmdletParameters   : {TlsDomain, CloudServicesMailEnabled, Identity, TlsSettings...}
ModifiedProperties : {RecipientDomains, RecipientDomainsEx, SmartHosts}
Caller             : tony@mail.activedir.org
ExternalAccess     : 
Succeeded          : True
Error              : None
RunDate            : 8/09/2014 1:19:30 a.m.
OriginatingServer  : DB3FFO11WS013 (15.00.1019.000)
Identity           : 9f184a42-929c-4a98-54c8-08d1991a134d
IsValid            : True
ObjectState        : New

RunspaceId         : 4e7bfd93-6f40-493b-b294-4f936506f863
ObjectModified     : FFO.extest.microsoft.com/Microsoft Exchange Hosted Organizations/fisheaglelimited2014.onmicrosoft.com/Configuration/mail.activedir.org
CmdletName         : Set-AcceptedDomain
CmdletParameters   : {MatchSubDomains, Identity, DomainType}
ModifiedProperties : {AcceptedDomainFlags, AcceptedDomainType}
Caller             : tony@mail.activedir.org
ExternalAccess     : 
Succeeded          : True
Error              : None
RunDate            : 8/09/2014 1:24:06 a.m.
OriginatingServer  : AM1FFO11WS002 (15.00.1019.000)
Identity           : 55b909e6-abbd-43af-8c21-08d1991ab767
IsValid            : True
ObjectState        : New

RunspaceId         : 4e7bfd93-6f40-493b-b294-4f936506f863
ObjectModified     : FFO.extest.microsoft.com/Microsoft Exchange Hosted Organizations/fisheaglelimited2014.onmicrosoft.com/Configuration/mail.activedir.org
CmdletName         : Set-AcceptedDomain
CmdletParameters   : {MatchSubDomains, Identity, DomainType}
ModifiedProperties : {AcceptedDomainFlags, AcceptedDomainType}
Caller             : tony@mail.activedir.org
ExternalAccess     : 
Succeeded          : True
Error              : None
RunDate            : 5/03/2015 1:44:26 a.m.
OriginatingServer  : DB3FFO11WS056 (15.01.0099.000)
Identity           : e7054efb-d9f5-461a-9c85-08d224fd0c3a
IsValid            : True
ObjectState        : New

 

I’ve opened a support incident with Microsoft about this, so I’ll post a follow-up here when that it resolved.

Anyone else out there experienced something similar?

 

 

 

 

You might come across a slight gotcha with SPF records if are using Exchange Online Protection (EOP) to provide protection for your on-premises mail environment and you don’t need to use EOP to scan your outbound (i.e. on-premises to Internet) messages. If this scenario is of interest to you, read on…

You may be aware that I run a mailing list running on a single server over at ActiveDir.org that provides a forum for disucssions on the topic of Active Directory. I set up Exchange Online Protection (EOP) to cover the mail.activedir.org namespace a little while ago as a lower-cost alternative to my previous anti-malware provider. When you first set up EOP with there are some DNS records that you are asked to configure. In fact, these *appear* to be mandatory based on the wording (see below).

EOP1

Without really thinking too deeply about I went ahead and configured the TXT record in DNS for SPF. With hindsight I shouldn’t have done this as I only wanted the traffic from the Internet to my on-premises mail server to be scanned for malware. I don’t need the SMTP traffic in the other direction to be scanned for malware because the only mail generated on the server is from the mailing list (list server) and as such as been scanned on the way in.

All appeared fine for a month or so and then fellow MVP Brian Arkills queried why he wasn’t receiving any email from the list. After a bit of digging, his infrastructure guy pointed to a problem with my SPF TXT record. Basically, the “-all” part of the record indicates that only the servers matching spf.protection.outlook.com are responsible for sending mail from mail.activedir.org. If a different server tries to deliver mail from that address the receiving MTA should fail the SPF check. Interestingly, most organisations treat this as a soft fail and deliver the email anyway. Not so the University of Washington, which is why Brian wasn’t receiving the list emails.

Once alerted to the problem, I modified the record like this:

v=spf1 a -all

What this says to the receiving MTA is to only pass the SPF check if sending server matches the A record for the namespace (i.e. my mail server).

That all seemed fine but then I looked at the message headers for emails that I was receiving from the list.  I am subscribed to the list with a standard cloud-based O365 email address. The header contained the following:

Received-SPF: Fail (protection.outlook.com: domain of mail.activedir.org does not designate 157.55.234.61 as permitted sender)  receiver=protection.outlook.com; client-ip=157.55.234.61;  helo=emea01-db3-obe.outbound.protection.outlook.com; Authentication-Results: spf=fail (sender IP is 157.55.234.61)  smtp.mailfrom=activedir-owner@mail.activedir.org;

The 157.55.234.61 IP address maps to emea01-db3-obe.outbound.protection.outlook.com (very clearly not my mail server). So what was going on? Why was the sending server showing as one of the outlook.com servers and not my mail server? I don’t know for sure but my best guess is that the O365 cloud servers are also EOP servers (makes sense). The EOP servers *think* they are responsible for the mail.activedir.org namespace and as such will effectively take over as the perceived sending server. The upshot was that I needed to go back to my SPF record and change it to include the EOP servers. It now looks like this:

v=spf1 a include:spf.protection.outlook.com -all

To summarise then:

  • Emails coming from my mail server to non-O365 addresses need to have a SPF TXT record that matches my mail server (via the A record for mail.activedir.org).
  • Emails coming from my mail server to O365 addresses need to have a SPF TXT record that matches the name required by EOP (spf.protection.outlook.com)

More than slightly confusing isn’t it? But then I guess I have a slightly unusual configuration.

For more information on SPF, this web site is a great starting point: http://www.openspf.org/