Often we, as cloud admins, need our audit or sign in logs. Usually, we need real-time data because, for example, we’re debugging why that one user has conditional access issues. But sometimes, we need to go back further than 30 days. And that is not something Azure does by default, but can be enabled:
Our options when exporting logs are limited to a Storage account, Log Analytics or an Event Hub. All these options offer multiple extraction methods to cover your transport needs to other systems. The default retention period is then forever, which is nice as we might need audit info going back a bit as hacks are usually discovered after about 206 days.
If you don’t have specific tools or requirements, I recommend setting up a Log Analytics workspace and connecting that to Azure AD:
Whichever method you choose, a P1 or P2 license is required. You only need a single license for the entire tenant when using the export audit / singin log functionality of AzureAD. Once configured, the Logs option directly bring you to the Log Analytics workspace search results:
I’ve briefly shown how to configure AzureAD to send audit and sign in logs to Log Analytics so you can go back further than 30 days. Stay tuned for the next post that will utilize these logs to dive deeper into Guest User activity.
Okta natively does not allow you to sync users to Office 365 contacts; they either exist as users in Office 365, or they don’t exist at all.
In hybrid scenarios where you are doing a staged migration to Office 365, or where you simply manage your contacts in Okta, you may want to populate the Global Address List in Office 365 with your Okta users.
I’ve written a simple solution for this, you will require:
Configuring a multi forest sync solution for a single Office 365 tenant is pretty straightforward, but there are a few small tiny gotcha’s:
1. DNS resolution is critical, adding a few host file entries won’t do the trick, use a (conditional) forwarder to a DC for each forest
2. Ensure the proper firewall ports are open
3. Ensure you type your login in the netbios format and include the suffix, e.g.: LIEBEN.NU\Admin, using LIEBEN\Admin will fail
If you don’t, you’ll probably run into this error:
[ERROR] Caught exception while validating the domain credentials and retrieving domain FQDN of the specified user XXXX.XXX\Admin.
Exception Data (Raw): System.DirectoryServices.ActiveDirectory.ActiveDirectoryObjectNotFoundException: The specified domain does not exist or cannot be contacted.
at System.DirectoryServices.ActiveDirectory.Domain.GetDomain(DirectoryContext context)
at Microsoft.Online.Deployment.Framework.Providers.ActiveDirectoryProvider.ValidateUserCredentials(String domainName, String username, SecureString password, String& domainFqdn)
at Microsoft.Online.Deployment.OneADWizard.UI.WizardPages.ConfigSyncDirectoriesPageViewModel.ValidateADDirectoryConnection(DirectoryConnectionViewModel connection)