Azure AD App Proxy allows you to publish an internal website to the internet. It is easy to set up and does not require inbound firewall rules. Traditionally, you would publish a website with the help of a reverse proxy, for example with Citrix Netscaler/ADC, KEMP Loadbalancer or F5.

In the Azure AD Portal (aad.portal.azure.com) open Application Proxy and firstly install the software on a server in the corporate network. Domain join is not a requirement, but is needed if you use Kerberos authentication.

You will need to log in with your tenant admin (or a M365 user that has the appropriate role).

After the installation, you should see the server in Azure AD App Proxy:

To then publish your site, select + Configure an app

Provide the internal URL along with the protocol (HTTPS or HTTP). You could select Azure AD in Pre Authentication and work with conditional access policies and require MFA for example. This example is using Passthrough Authentication.

Also some basic settings can be changed. To publish the site, hit + Add

After a few minutes, your site should be available:

You can also configure custom domains by verifying your domain(s) in Microsoft 365 by uploading your public certificate with the private key (pfx) and configuring the appropriate DNS record. For detailed information, check out the Microsoft docs below.

References:

https://docs.microsoft.com/en-us/azure/active-directory/app-proxy/application-proxy

If you have the misfortune of having to troubleshoot and repair boot issues on a virtual machine after a physical host crash, these two commands might help you.

First of all, try to get into the advanced settings on boot (it should be the F11 key), or after a while Windows (Server or 10/11) might automatically go into the menu when it cannot boot from disk. Alternatively a Windows ISO image can be used.

Once in the advanced settings, run the good old checkdisk command:

chkdsk /f C:

After completion, restart the VM and check if you are able to boot. If the issue persists, try restoring the registry database (once again through the advanced settings or a Windows ISO). A scheduled task regularly backs up the registry and puts it the folder C:\Windows\System32\config\Regbak.

copy C:\windows\system32\config\RegBack\* C:\windows\system32\config

Restart the VM and check if you are able to boot into Windows. If you still have issues, you should consider restoring from a backup (it sucks but sometimes it is unavoidable).

When syncing local AD users to Azure AD, you can configure Seamless Sign-On to automatically login to Microsoft 365 Apps like Sharepoint Online, OneDrive, or Exchange Online. This is very easy to do and will make logins for users less painful.

Assuming Azure AD Connect is already set up with Pass-through authentication (see https://www.ajni.it/2021/05/configuring-azure-ad-connect-for-user-synchronization/), just open Azure AD Connect and then hit "change user sign-in" and log in with an Azure AD Global admin. After that, select "Enable single sign-on".

Enter Domain Admin credentials.

When the pre-checks is complete, hit configure and exit.

A Computer Account named AZUREADSSOACC will be created in Active Directory which allows the authentication validation between Azure AD and local Active Directory. The Kerberos decryption key is saved in the cloud and should be changed regularly. You can see that on the Computer account, service principal names are configured

Lastly, you can roll out the feature with Group Policy. The URL https://autologon.microsoftazuread-sso.com must be added to the intranet zone list, which allows the browser to send Kerberos tickets to that site.

The GPO can be found under User Configuration > Policies > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page > Site to Zone Assignment List.

Status bar updates via script must be also enabled. This GPO is located under User Configuration > Policies > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page > Intranet Zone > Allow updates to status bar via script.

You can test the feature by opening portal.office.com. After entering the username, login should be done automatically without needing to insert a password.

References:

https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sso-quick-start

The first step in the journey to the cloud is to install and configure Azure AD Connect. This will synchronize users in local Active Directory to Azure AD and will allow you to use cloud services like OneDrive For Business, Sharepoint Online, Exchange Online, or Microsoft Teams.

Before installing the service itself, we have to set an alternate UPN suffix as in Azure AD. In Active Directory Domains and Trusts add a new UPN suffix. The suffix should be equal to the custom domain name in Azure AD.

Users synchronizing to Azure AD should have that UPN suffix set:

In the Azure AD panel, select Azure AD Connect and then "Download Azure AD Connect"

Start the installer and select "Customize"

Hit install

Select Password Hash Synchronization and login with your Azure AD global admin

Select Create new AD Account and enter Enterprise Admin credentials. The tool will automatically set the correct permission on the OU without adding Domain Admin rights to the user.

You will notice that a new user named MSOL_xxx has been created.

This is just a warning. We already set the correct UPN suffix.

Deselect the top checkbox and select the OU containing AD Users. Service users should not be synchronized.

Leave everything else on default settings and then hit install.

With the synchronization service you can check what objects have been synced and the last time a sync ran.

In Azure AD the synced user should show up. You can see that the correct UPN has been configured on the user.

If you want to manually start AD Sync, in Windows PowerShell enter this command:

Start-ADSyncSyncCycle -PolicyType Delta

When synchronizing on-prem users to Azure AD, there is a chance that Exchange attributes like msexchHideFromAddressLists are missing in Active Directory because the Exchange schema has never been updated, since there has never been a local installation of Microsoft Exchange. In that case, you could either extend the AD schema to include Exchange attributes or you could work with Azure AD synchronization rules, which is safer in my opinion.

On the Azure AD server, open Synchronization Rules Editor

Edit the rule "in from AD - User join". This will disable the rule itself and create a new one. Give the rule a descriptive name and a precedence of 50.

Under Transformations, add a new rule:

Expression msexchHideFromAddressLists IIF(IsPresent([msExchAssistantName]),IIF([msExchAssistantName]="HideFromGAL",True,False),NULL) Update

Now, you can set the attribute msExchAssistantName to HideFromGAL on the AD user. This will tell Azure AD Connect to set msexchHideFromAddressLists to true on the cloud side.

Obviously, you could use another attribute to achieve the same goal. Just change the if statement slightly.

IIF(IsPresent([msExchAssistantName]),IIF([msExchAssistantName]="HideFromGAL",True,False),NULL)

References:

https://jackstromberg.com/2018/08/how-to-hide-users-from-the-gal-in-office-365-synchronized-from-on-premises/