Configure ADFS to work externally without having a WAP Server (configure Azure app proxy to publish ADFS externally)

Overview:

Screenshot 2022-05-27 141620

Azure Application proxy provides single sign-on (SSO) and secure remote access for web applications hosted on-premises environments without complexities. This makes your life easier as you won’t need those complicated reverse proxies or Web Application proxies (WAP) that are usually sit in the DMZ.

Objective:

In this scenario, the idea is to guide you through on how to publish ADFS service externally so that users can access your applications outside of the internal network. This will also be beneficial for public user scenario such as Azure AD users and Azure B2B. The known approach to publish ADFS externally is “to have a Web Application Proxy” server configured in DMZ but that’s very time consuming and over complicated for basic requirements (unless you have specific needs to depend on WAP or Reverse proxy).

This post assumes that you have an ADFS server/s configured and in the running conditions as we won’t be going through that part of the configuration on this one.

Prerequisites:

  • Active directory domain and DNS configured in your on-premise environment
  • ADFS Server installed, configured and running
  • Verifiable public domain name (i.e. mscloudjournal.com)
  • Public SSL certificate binding is done in the ADFS server
  • Azure tenancy with Azure AD Premium P1 or P2 license

Step1: Download and install proxy connector in the desired server

First thing is first, let’s download the proxy connector tool from Azure. Simply login to your Azure tenancy and navigate to Azure Active Directory –> Application Proxy –> Hit that nice little button to download the latest version of the tool.

Copy across this to your ADFS server (or any desired server that you’re planning to run this connector. You do not need a dedicated server for this as it’s a very lightweight service).

image

Once copied across to the desired server (ADFS server itself in this case), run the tool to begin the process.

image

Next, you’ll be prompted to sign in to Azure AD. Make sure you have appropriate privileges to run this operation in Azure AD.

image

It won’t take more than a couple of minutes.

image

And there we have the greenlight. Simply close this wizard now and switch back to Azure AD.

image

Hit refresh and you’ll notice our brand new connector is now up and running in Azure. And we also have a public IP assigned to it by Azure.

image

Step2: Configure an App in Azure

Now to configure an app using the option given in the top ribbon. Hit “Configure an app” to begin.

image

image

Input the details below to suit your environment’s naming. Choose “Passthrough” for Pre-authentication method and the rest can be defaults unless you have a specific need.

image

And that’s it! our new on-premises application is created successfully.

image

Step3: Adding the DNS CNAME record

Now we need a DNS record to point the traffic to Azure App Proxy service endpoint. This is done in the DNS repository so you’ll need the access to your domain’s hosting provider (i.e. Godaddy) to add a DNS pointing record.

image

The record will look something like this. Point to needs to be the address we saw in Azure ending with “msappproxy.net” (this is the proxy service endpoint for Azure). Add a new CNAME record as shown below and amend the naming to suit your record.

image

Step4: Binding the exported certificate

Now lets head over to “Enterprise Applications” –> All applications –> select the app one we created in the previous step (ADFS External Publishing Proxy) –> Application Proxy.

image

Here you get the certificate upload option. This certificate is taken from the ADFS server. Follow the next step to obtain this from the server.

image

Export the certificate from the ADFS server

Login to your relevant on-premises server (ADFS server in my case) and open mmc (type “mmc” in the run command and enter) and add the certificate snap-in to the mmc console.

image

Chose the right certificate that binds to the ADFS service URL and right click –> All tasks –> Export

image

image

You need both certificate + the private key so export it from the certificate export wizard in the server itself.

image

image

image

Choose “AES256-SHA256” for encryption and check the password option to enter a password.

image

Give the cert a name and save it in a secure space. We will upload this to the app we created in Azure, next.

image

Now lets switch back to Azure AD –> Enterprise Applications –> All applications –> select the app one we created in the previous step (ADFS External Publishing Proxy) –> Application Proxy.

Scroll down and click on the option that allows you to upload the certificate.

image

Chose the file we exported (.pfx) and input the same password specified when exporting it –> hit upload.

image

It should like below if everything went well.

image

image

And, that’s it ! we should now be able to test it out.

Step5: Testing the external accessibility

To test it, simply try to access the ADFS signon URL from a external network and if you can see the following screen with a validated certificate, you’re all done !

https://adfs.yourdomain.com/adfs/ls/idpinitiatedsignon

image

Advertisement

Azure AD Error: AADSTS700016 Application with identifier was not found in the directory

I recently had the chance to work on Azure B2B access integration with ADFS (SAML consumed by SaaS applications) and this post is inspired by the quick fix applied to an issue I encountered in the middle of the process. Although this may look obvious in technical point of view, I’m quite certain that someone will find this handy and could save hours of troubleshooting.

Mac-102-error-1200x900

When a B2B user (AAD registered guest) tries to access the ADFS signon URL (https://adfs.yourdomain.com/adfs/ls/idpinitiatedsignon), the following error received. I had the Azure AD App registered and configured to work with ADFS but, the error makes perfect sense here. It clearly says that “the application ID did not match the URN that was generated by ADFS.


“AADSTS700016: Application with identifier ‘<URN>’ was not found in the directory ‘<Tenant Id>’. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You may have sent your authentication request to the wrong tenant”

Screenshot 2022-05-28 235054

The Uniform Resource Name (URN) is a unique identifier assigned to our Enterprise SAML connection. This value is labelled as ‘”Federation service Identifier” in the ADFS server Federation service properties which is easy to find. The URN value apparently needs to be assigned to the App Registration.

ADFS Server –> Edit Federation Service Properties

Screenshot 2022-05-29 003839

To access the APP ID, select the Add an Application ID URI option in the Azure App.

Screenshot 2022-05-29 004046

Screenshot 2022-05-29 002752

Set the URN copied from the ADFS service properties. This is usually “HTTP”, not HTTPS.

Screenshot 2022-05-29 004110

No changes to the “Redirect URIs. Leave it with the IDPInitiatedSignOn page and hit save to apply the change.

Screenshot 2022-05-29 004130

And that’s it ! Azure App is now linked correctly with the ADFS service endpoint.

Remove orphaned delegation permissions of a deleted user in Exchange Online mailbox

You might think that a user’s delegate permissions for other mailboxes will be removed up on deleting the account in the Azure Active Directory, apparently it wasn’t in my case.

access20delegation-01_thumb

Scenario:

Location – Calendar folder of ‘manoj@mantoso.live:\Calendar’

Delegated editor permissions to – ‘Marie Jonas’ (Abandoned identity after AD account deletion)

Even though this particular account was permanently deleted from Azure AD after 30 days of marking deletion, the delegation access (editor) to other users’ Exchange mailboxes remained intact which caused the following strange behaviors that I had to get rid of.

  • Others can still spot this user’s name in the calendar invites
  • Possibly in other various occasions too based on the permissions the user had before deleted

Here’s the PowerShell command to fetch the permissions of a specific location. This will list down all the delegated permissions of ‘Manoj’s’ Exchange calendar. In my case, the abandoned user also popped up in the results.

Get-EXOMailboxFolderPermission "manoj@mantoso.live:\calendar" 

e.g0.1

Now, to dig further down to be more specific to this mysterious user, let’s run this command

Get-EXOMailboxFolderPermission "manoj@mantoso.live:\calendar" | where {$_.user.tostring() -like "Marie Jonas*"}

e.g0

This means the permission thumbprint is intact even after the account was permanently deleted which is a mystery. Now to get rid of this, we can use this command below. I tried several other approaches from various Microsoft articles and forum posts but none of them worked but the following.

Get-EXOMailboxFolderPermission "<user@domian.com:\calendar>" | where {$_.user.tostring() -like "<FirstName Last Name>*"} | Remove-MailboxFolderPermission -Confirm:$False

After running that with no errors/warnings. I ran Get command again to verify if it really was a success. And Yes ! Nothing returned, which means the permissions are now cleared for this abandoned identity of ‘Marie Jonas’.

2

Allowed it a couple of hours, her name disappeared from the calendar invites as well.

Get-EXOMailboxFolderPermission "<user@domian.com:\calendar>" | where {$_.user.tostring() -like "<FirstName Last Name>*"} | Remove-MailboxFolderPermission -Confirm:$False

Removing orphaned OneDrive secondary site collection admins

This is a scenario where, the user was deleted from Azure AD months ago but the OneDrive secondary site collection administrator permission assignments (OneDrive secondary admin) were intact as a thumbprints. This target account  supposed to be a service account utilized during a file server migration project and apparently assigned with OneDrive secondary site collection admin permission across all users in the tenancy.

Screenshot 2020-11-29 002255

The generic SharePoint Online commands did not do the job because “The user account does not exists in the AD” hence the identity validation fails at the first place. The OneDrive admin UI will do the job for a single OneDrive account but doesn’t help much in bulk operation scenarios like the one I dealt with.

Workaround: To remove this I used SharePoint PnP PowerShell command which was the only way around it.

Add yourself first in to one of the site collections (OneDrive accounts) before running the command so that you can verify the status ‘before’ and the result ‘after’.

For a single site collection (OneDrive Personal site in this case), run PowerShell as admin and execute these lines after customizing with your tenant, URL and user details. For this case, we will be using ‘Span ID’ to point to the abandoned account which usually goes as follows i:0#.f|membership|service.svc@tenant.onmicrosoft.com

#Config Variables - Customize this to match yours 
$SiteURL = "https://mantoso-my.sharepoint.com/personal/manoj_karunarathne_mantoso_com"
$UserID="i:0#.f|membership|account@tenant.onmicrosoft.com"
 
#Connect to PnP Online Service MFA
Connect-PnPOnline -Url $SiteURL -UseWebLogin
 
#sharepoint online powershell delete user from site collection
Remove-PnPUser -Identity $UserID -Force

If your result is similar to below, the command has done its job ! now go check that permission box and you should not see that account anymore.

Screenshot 2020-11-29 001807

Error when accessing Exchange Online classic Admin Center (EAC): 403 Access denied :(

We have been pulling our hair out for several days due to this issue. Office 365 Exchange admin center gives the following error whereas the new admin center worked well.

when you click that “Exchange” blade from the Office 365 admin center, it usually takes you to the classic Admin center which we still need for some functions that new Admin center doesn’t have.

image 

clip_image001

After lots of struggle, we managed to figure out the Root cause and reported to Microsoft through an incident.

Root cause: Group based access assignments in Privileged Identity Management.

image

Workaround: We had assigned Azure AD Roles such as Global Administrator, Exchange Administrator via Group based PIM which did not work properly with classic EAC. Assigning Direct permissions fixed this and we managed to open the classic console immediately, right after the direct assignment. If you are facing the same, try to get rid of “Group Assignments” for Exchange Admins at least for the time being and go for “Direct Assignments

Official reference: https://docs.microsoft.com/en-us/azure/active-directory/roles/groups-concept 

KnownIssue

I will update this post up-on Microsoft’ support responses.

Renew Apple MDM Push Certificate in Microsoft Endpoint Manager (Intune)

Apple MDM Push certificate is the key element for Microsoft EndPoint Manager to manage iOS/iPadOS and macOS devices in the MEM portal. After you add the certificate to EndPoint Manager, your users can enroll their devices using: The Company Portal app or Apple’s bulk enrollment methods such as the Device Enrollment Program (a.k.a DEP), Apple School Manager, or Apple Configurator.

digital

This renewal is crucial:  Ensure that you take necessary actions before the expiry date as revoking or allowing this certificate to expire will require existing devices to be re-enrolled with a new push certificate.

Prerequisites for renewal:

  1. Apple Identity portal account (mostly different from the Apple ID) which was used to setup the integration for your organization. – https://identity.apple.com/pushcert/
  2. MFA code (sends to the device registered for MFA under above account)

  3. Appropriate access to MEM (Microsoft Endpoint Manager a.k.a Intune portal) – https://endpoint.microsoft.com/ 

First we need to sign-in to MEM portal using your admin credentials copy paste this link and sign in https://endpoint.microsoft.com/ 

Navigate to Devices blade from the left panel and go to Apple iOS/iPadOS enrolment section as shown below and then click on ‘apple MDM Push Certificate’ widget

0

From the screen popped up, simply click on download CSR file on the 2nd option. Save it to a secure/temporarily location as we will delete this after the renewal.

5

Let’s now switch in to Apple Identity portal. This is where you need the original credentials which was used to setup the integration with Intune. Login from that account to this site – https://identity.apple.com/pushcert/

1

You can avoid MFA using other options but this may not be the same in your case. Hence make sure you have the device associated to the account to receive the MFA code. Hit ‘Continue“’ to enter the code or go to ‘other options’ to avoid it.

2

Highly recommended to associate a mobile device for MFA if you haven’t already, or, chose ‘don’t upgrade’ option to avoid it.

3

Once logged in, you will see all your certificates listed with the expiry date stated.

4

That little ‘i” button will show you more details of each certificate if you have multiple (mostly used for different tenancies under a single account). Serial Number is the key to identity which is which from the Intune portal. Ensure that you are renewing the correct certificate by cross-checking the Serial No here againts Intune. Once confirmed, simply click on that ‘Renew” button above and you should see a new dialog box prompting.

6

Add a note to indicate who renew it which might be useful in a organization this will be done by another person next year.

And now choose the CSR file you downloaded from Intune and hit ‘Upload’

7

That’s it and you can see the green tick indicates everything went well. Simply download the certificate and store in the same secure location you store CSR previously.

8

You should see the new expiry date for this certificate now.

9

Let’s head back to MEM (Intune) portal now and upload the new certificate file there. You should also provide the original Apple ID which was used to create the MDM push cert. Once done, hit ‘Upload’ button.

10

That’s about it and now you will see a green status prompts indicates it went well.

11

Certificate should now be valid for another year !

12

‘Connect-MsolService’ is not recognized as the name of a cmdlet

If you are facing this issue, you are not alone. In my case, I had run the install-Msolservice command before and it completed with no errors but nothing seemed to be installed, therefore it didn’t connect or recognize the modules in the machine. Here are the steps to get it fixed.

Open PowerShell as Admin –> Run the following commands in sequence (ensure your machine is connected to internet)

Firstly, uninstall the Azure-AD module

uninstall-module AzureAD

The re-install it

Install-module AzureAD
Install-module AzureADPreview

Try to run this. It will complete without any errors if you have the module existed but somehow corrupted (It could fail too but just run it anyways to verify)

Uninstall-module MSOnline

Now re-install the MSOnline Module

Install-module MSOnline

And now you can connect to O365. It should prompt you for credentials to login

Connect-MsolService

Once completed, the following command can be used to verify the installation.

Get-Module -ListAvailable -Name MSOnline*

MSolservice

Permanently deleting an Office 365 Group object in retention enabled environment

There is a stage where an Office 365 group can reach its end. As O365 group acts a major role for may Office 365/Azure related workloads, there could be plenty of situations you come across that you have to get rid of some of your Office 365 Groups.

For instance, a situation where you have removed your Team and Its associated SharePoint site but Group object could be still hanging in the recycle bin until it reaches the retention period based on the retention policy you have set. Or, perhaps, you have decided to delete a SharePoint site or Microsoft Team, you will find you cannot create another team or site in its place. You will receive an error saying this group already exists.  This is because the group was deleted as a ‘soft delete’. Meaning it’s sitting in a recycle bin for a number of days until it’s permanently deleted (retention plays again). Just follow these steps and you will immediately get rid of that unnecessary group object.

First and foremost, ensure that you have Azure AD PowerShell module is installed in your PC.

Run the following commands in sequence.

This first line will connect you to your Office 365 Tenant’s Azure AD. you will be prompted for the credentials to log in.

Connect-AzureAD

image

image

Now let’s run this one to get the group GUID from the deleted list

Get-AzureADMSDeletedGroup

image

Copy that GUID of the desired group and run the following by targeting that ID.

Remove-AzureADMSDeletedDirectoryObject -Id <ReplaceWithGroupID>

It should result as follows if it was success

clip_image001

To ensure the deletion is successful, run the same command again and see if it doesn’t return the group name you deleted. It shouldn’t !

Get-AzureADMSDeletedGroup

Retrieve and export Office 365 Group Members (Part02)

This is the 2nd part of the article series “Retrieve and export Office 365 Group Members”. We are covering up the second part in this post.

9

  1. Retrieve and export members of an specific Office 365 group (Part01)
  2. Retrieve and export members of all Office 365 groups (Part 02)

The best tool to run these kind of scripts is the PowerShell ISE. Copy the following code and paste it in to PowerShell ISE and make sure that you have run it as the Admin.

14

### All users of all groups 

$CSVPath = "C:\Exports\AllGroupMembersList.csv"
 
### Get Credentials
$Credential = Get-Credential
   
### Create Session
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $Credential -Authentication Basic -AllowRedirection
   
### Import Session
Import-PSSession $Session -DisableNameChecking

### Remove the CSV file if already exists
If(Test-Path $CSVPath) { Remove-Item $CSVPath}

### Retreive all Office 365 Groups
$O365Groups=Get-UnifiedGroup
ForEach ($Group in $O365Groups) 
{ 
    Write-Host "Group Name:" $Group.DisplayName -ForegroundColor Green
    Get-UnifiedGroupLinks -Identity $Group.Id -LinkType Members | Select DisplayName,PrimarySmtpAddress
 
    ### Get Group Members and export to CSV
    Get-UnifiedGroupLinks -Identity $Group.Id -LinkType Members | Select-Object @{Name="Group Name";Expression={$Group.DisplayName}},`
         @{Name="User Name";Expression={$_.DisplayName}}, PrimarySmtpAddress | Export-CSV $CSVPath -NoTypeInformation -Append
}
  
#Remove the session 
Remove-PSSession $Session

A closer look would be like this once you paste it. Ensure to replace the <CSVPath> parameter value before you run it.

1111

Just hit the play button to run the whole thing or you can highlight a specific line to run that only.

222

If all went well, you would not get any prompts or errors except the credentials insertion prompt.

And the group members list with the respective group name will be listed right on the PowerShell result pane just like below.

3333

4444

And if you go back to your export folder, the CSV will also sit there just for you to open and see.

5555

6666

DISCLAIMER NOTE: This is an enthusiast post and is not sponsored by Microsoft or any other vendor. Please do not copy/duplicate the content of the post unless you are authorized by me to do so.

Stay ahead on Hybrid Identities–Microsoft’s Azure AD Connect v1.3.20.0 has a lot to offer

Microsoft has released the latest version of Azure AD Connect last week which was long impending !

installadconnect02

Azure AD Connect is the bridge that is used to synchronize identities (objects and their attributes) across on-premise and cloud environments by many organizations.  However, every feature that is bundled in this release doesn’t target every audience. You can choose the ones that are most applicable to your organization’s environment.

Download the latest version of AADConnect

Fixes this version carries:

  1. Fix the SQL reconnect logic for ADSync service
  2. Fix to allow clean Install using an empty SQL AOA DB
  3. Fix PS Permissions script to refine GWB permissions
  4. Fix VSS Errors with LocalDB
  5. Fix misleading error message when object type is not in scope
  6. Corrected an issue where installation of Azure AD PowerShell on a server could potentially cause an assembly conflict with Azure AD Connect.
  7. Fixed PHS bug on Staging Server when Connector Credentials are updated in the old UI.
  8. Fixed some memory leaks
  9. Miscellaneous Auto upgrade fixes
  10. Miscellaneous fixes to Export and Unconfirmed Import Processing
  11. Fixed a bug with handling a backslash in Domain and OU filtering
  12. Fixed an issue where ADSync service takes more than 2 minutes to stop and causes a problem at upgrade time.

New features and advancements (19 new stuff in one go !)

  1. Add support for Domain Refresh
  2. Exchange Mail Public Folders feature goes GA
  3. Improve wizard error handling for service failures
  4. Added warning link for old UI on connector properties page.
  5. The Unified Groups Writeback feature is now GA
  6. Improved SSPR error message when the DC is missing an LDAP control
  7. Added diagnostics for DCOM registry errors during install
  8. Improved tracing of PHS RPC errors
  9. Allow EA creds from a child domain
  10. Allow database name to be entered during install (default name ADSync)
  11. Upgrade to ADAL 3.19.8 to pick up a WS-Trust fix for Ping and add support for new Azure instances
  12. Modify Group Sync Rules to flow samAccountName, DomainNetbios and domainFQDN to cloud – needed for claims
  13. Modified Default Sync Rule Handling – read more here.
  14. Added a new agent running as a windows service. This agent, named “Admin Agent”, enables deeper remote diagnostics of the Azure AD Connect server to help Microsoft Engineers troubleshoot when you open a support case. This agent is not installed and enabled by default. For more information on how to install and enable the agent see What is the Azure AD Connect Admin Agent?.
    Updated the End User License Agreement (EULA)
  15. Added auto upgrade support for deployments that use AD FS as their login type. This also removed the requirement of updating the AD FS Azure AD Relying Party Trust as part of the upgrade process.
  16. Added an Azure AD trust management task that provides two options: analyze/update trust and reset trust.
  17. Changed the AD FS Azure AD Relying Party trust behavior so that it always uses the -SupportMultipleDomain switch (includes trust and Azure AD domain updates).
  18. Changed the install new AD FS farm behavior so that it requires a .pfx certificate by removing the option of using a pre-installed certificate.
  19. Updated the install new AD FS farm workflow so that it only allows deploying 1 AD FS and 1 WAP server. All additional servers will be done after initial installation.

If you plan to upgrade, the following resources should be your first reads.