Questions[microsoft-office-365](server)

I have reason to suspect that a user may be accessing their company email using a copy of Microsoft Outlook (or perhaps another email client) from a personal device for the purpose of data exfiltration. I've ruled out them accessing their account using ActiveSync (using Get-ActiveSyncDeviceStatistics -Mailbox [username] | ft DeviceType, DeviceUserAgent, LastSuccessSync in powershell) but I cannot seem to find a way to rule out the Outlook desktop app.

IMAP, POP3, and OWA are disabled for this user per corporate policy so I can rule those out as well.

Is there a way to tell which MAPI clients are or have authenticated with Exchange for a particular user? (This is hosted-exchange on an Office 365 tenant, and I have full admin permissions.)

Okay so...this all started during our Office 365 setup. According to Microsoft, you have to delete your on-premises federation trust from Exchange, verify the domain, then add it back...otherwise you get an obscure error message when validating the domain name.

So I did this...except now the federation trust is broken. I get the following message from "Test-FederationTrust -Verbose":

VERBOSE: [19:43:14.005 GMT] Test-FederationTrust : Retrieved Token Issuer Uri from Federation Metadata:
urn:federation:MicrosoftOnline.
VERBOSE: [19:43:14.005 GMT] Test-FederationTrust : Retrieved Token Issuer Certificate from Federation Metadata:
<snip>.
VERBOSE: [19:43:14.005 GMT] Test-FederationTrust : Retrieved Token Issuer Previous Certificate from Federation
Metadata: <snip>.
VERBOSE: [19:43:14.005 GMT] Test-FederationTrust : Retrieved Token Issuer End Point from Federation Metadata:
https://login.microsoftonline.com/extSTS.srf.
VERBOSE: [19:43:14.005 GMT] Test-FederationTrust : Retrieved Web Requestor Redirect End Point from Federation Metadata:
 https://login.microsoftonline.com/login.srf.
VERBOSE: [19:43:14.912 GMT] Test-FederationTrust : Failed to request delegation token. Reason: <S:Fault
xmlns:S="http://www.w3.org/2003/05/soap-envelope"><S:Code><S:Value>S:Sender</S:Value><S:Subcode><S:Value>wst:FailedAuth
entication</S:Value></S:Subcode></S:Code><S:Reason><S:Text xml:lang="en-US">Authentication
Failure</S:Text></S:Reason><S:Detail><psf:error
xmlns:psf="http://schemas.microsoft.com/Passport/SoapServices/SOAPFault"><psf:value>0x80048821</psf:value><psf:internal
error><psf:code>0x80041012</psf:code><psf:text>The entered and stored passwords do not match.
</psf:text></psf:internalerror></psf:error></S:Detail></S:Fault>
Microsoft.Exchange.Net.WSTrust.SoapFaultException: Soap fault exception received.
   at Microsoft.Exchange.Net.WSTrust.SoapClient.Invoke(IEnumerable`1 headers, XmlElement bodyContent)
   at Microsoft.Exchange.Net.WSTrust.SecurityTokenService.IssueToken(DelegationTokenRequest request)
   at Microsoft.Exchange.Management.SystemConfigurationTasks.TestFederationTrust.GetDelegationToken(ADUser user, Uri
target, SecurityTokenService securityTokenService)

What the heck does this mean? There's no passwords in a federated trust! I've attempted to recreate the trust multiple times to no avail. I also attempted to re-use the certificate the trust was working with before but that wasn't working either.

This also breaks the organizational relationships with the same message. I've asked our MSP and they have no idea what's wrong. Before I drop the money on a support ticket to Microsoft themselves ...has anyone seen this error message before?

I have also posted my Get-FederationTrust output below (scrubbed for security purposes, obviously):

RunspaceId                   : 5de750d3-a3c9-4502-a108-8b1f12d77fda
ApplicationIdentifier        : 000000004804FA68
ApplicationUri               : mydomain.com
OrgCertificate               : [Subject]
                                 CN=Federation

                               [Issuer]
                                 CN=Federation

                               [Serial Number]
                                 <snip>

                               [Not Before]
                                 10/27/2017 11:58:27 AM

                               [Not After]
                                 10/27/2022 11:58:27 AM

                               [Thumbprint]
                                 <snip>

OrgNextCertificate           :
OrgPrevCertificate           :
OrgPrivCertificate           : <snip>
OrgNextPrivCertificate       :
OrgPrevPrivCertificate       :
TokenIssuerCertificate       : [Subject]
                                 CN=Live ID STS Signing Public Key

                               [Issuer]
                                 CN=Live ID STS Signing Public Key

                               [Serial Number]
                                 <snip>

                               [Not Before]
                                 12/6/2016 5:06:29 PM

                               [Not After]
                                 12/5/2021 5:06:29 PM

                               [Thumbprint]
                                 <snip>

TokenIssuerPrevCertificate   : [Subject]
                                 CN=Live ID STS Signing Public Key

                               [Issuer]
                                 CN=Live ID STS Signing Public Key

                               [Serial Number]
                                 <snip>

                               [Not Before]
                                 7/18/2014 3:53:40 PM

                               [Not After]
                                 7/17/2019 3:53:40 PM

                               [Thumbprint]
                                 <snip>

PolicyReferenceUri           : EX_MBI_FED_SSL
TokenIssuerMetadataEpr       : https://nexus.microsoftonline-p.com/FederationMetadata/2006-12/FederationMetadata.xml
MetadataPollInterval         : 1.00:00:00
TokenIssuerType              : LiveId
TokenIssuerUri               : urn:federation:MicrosoftOnline
TokenIssuerEpr               : https://login.microsoftonline.com/extSTS.srf
WebRequestorRedirectEpr      : https://login.microsoftonline.com/login.srf
MetadataEpr                  :
MetadataPutEpr               :
TokenIssuerCertReference     : stscer
TokenIssuerPrevCertReference : stsbcer
NamespaceProvisioner         : LiveDomainServices2
AdminDisplayName             :
ExchangeVersion              : 0.10 (14.0.100.0)
Name                         : Microsoft Federation Gateway
DistinguishedName            : CN=Microsoft Federation Gateway,CN=Federation Trusts,CN=<my CN>,CN=Mi
                               crosoft Exchange,CN=Services,CN=Configuration,DC=mydomain,DC=com
Identity                     : Microsoft Federation Gateway
Guid                         : fa98ab67-228f-4b8a-9f94-69b1d1609ec9
ObjectCategory               : Divcom.com/Configuration/Schema/ms-Exch-Fed-Trust
ObjectClass                  : {top, msExchFedTrust}
WhenChanged                  : 10/27/2017 12:13:31 PM
WhenCreated                  : 10/27/2017 11:58:29 AM
WhenChangedUTC               : 10/27/2017 4:13:31 PM
WhenCreatedUTC               : 10/27/2017 3:58:29 PM
OrganizationId               :
OriginatingServer            : dc.mydomain.com
IsValid                      : True

I'm in need of auditing the number of Office installs each user has installed as well as the computer names where Office Pro Plus has been installed.

I had never noticed a place to run such a report in the past, but figured there might be one. To my surprise I couldn't find anything in the admin portal.

Then I saw this blog post: Managing Office 365 ProPlus installations: activating, deactivating, and reactivating which confirms my frustrations:

Only the signed in user can see this information. Even if you are the administrator for your organization's Office 365 subscription, you can't see this information in any of your Office 365 administrative views. This also means you can't deactivate a user's installation of Office on a specific computer.

I understand well enough how Office Pro Plus activation/expiration works on Office 365:

When a user installs Office on a computer from the Office 365 Portal, and if the user hasn't already installed and activated Office on five other computers, Office is automatically activated. Once the Office installation is activated, the software page in the Office 365 Portal is updated with the name of the computer on which Office was installed.

Every day or every time you launch an Office 365 ProPlus application, it will check whether the individual installation or account has been deactivated. The computer needs to be connected to the Internet at least once every 30 days so that this check can be made. If the computer isn't connected to the Internet within 30 days, Office will end up in reduced functionality mode. In reduced functionality mode, the user will only be able to open and view existing Office files, but will not be able to use most of the other features of the application.

However, I can't seem to find any way of reporting each user's Office installs/activations short of having them show me via their portal login.

So, I'm not hoping too much on this, but maybe one of the MS Office 365 partners/vendors out there has managed to create something to gather this information?

P.S. I'll open a ticket with O365 support as well to ask them...but this seems like something that should be documented here on ServerFault for others to reference.

In volume licensed editions of Office (ones with an MSI deployment), you can use OCT to create a package that will remove previous versions of Office when the new version is deployed.

Office 365 Pro Plus is Click-to-Run only, which means that OCT will not work with it. ODT allows for some customization of Office 365 Pro Plus, but appears to lack the ability to remove previous versions of Office.

Is there a way to do this native to the Office 365 Pro Plus deployment, or does this really involve creating a script to check for every possible version of Office along with uninstall logic?

I am trying to setup a Postfix server on a Linux box to relay all mail to our Office365 (Exchange, hosted by Microsoft) mail server, but, I keep getting an error regarding the sending address:

BB338140DC1: to= relay=pod51010.outlook.com[157.56.234.118]:587, delay=7.6, delays=0.01/0/2.5/5.1, dsn=5.7.1, status=bounced (host pod51010.outlook.com[157.56.234.118] said: 550 5.7.1 Client does not have permissions to send as this sender (in reply to end of DATA command))

Office 365 requires that the sending address in the MAIL FROM and From: header be the same as the address used to authenticate. I have tried everything I can think of in the config to get this working. My postconf -n:

append_dot_mydomain = no
biff = no
config_directory = /etc/postfix
debug_peer_list = 127.0.0.1
inet_interfaces = loopback-only
inet_protocols = all
mailbox_size_limit = 0
mydestination = xxxxx, localhost.localdomain, localhost
myhostname = localhost
mynetworks = 127.0.0.0/8
recipient_delimiter = +
relay_domains = our.doamin
relayhost = [pod51010.outlook.com]:587
sender_canonical_classes = envelope_sender
sender_canonical_maps = hash:/etc/postfix/sender_canonical
smtp_always_send_ehlo = yes
smtp_sasl_auth_enable = yes
smtp_sasl_mechanism_filter = login
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options =
smtp_tls_CAfile = /etc/postfix/cacert.pem
smtp_tls_loglevel = 1
smtp_tls_security_level = may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes

/etc/postfix/sender_canonical:

www-data                [email protected]
root                    [email protected]
www-data@localhost      [email protected]
root@localhost          [email protected]

Also, sasl_passwd is set to the correct credentials (tested them using swaks multiple times.) Authentication works, and sends the message when the from headers are correct (also tested using swaks, which works)

The emails are coming from PHP, so I have also tried altering the sendmail path in php.ini to use pass the correct from address via -f

So, for some reason, mail coming from www-data and root are not having the from fields rewritten to Office 365's satisfaction, and it won't send the message.

Any postfix gurus out there that can help me setup this relay?