8. Next select edit attributes and click onto User.Email you will need to change this value to User.principalname, once you have hit save.
9. Next we will click onto edit on the SAML cert, we will need to generate a new SAML assertion SHA-256 certificate and save this.
10. We will now need to create a group that will be automatically provisioned and deprovisioned. To do this go into Users and groups from the left hand slide. Then click onto Provisioning. You should switch this from manual to Automatic and save.
11. Now we will need to Authorize, after you save you should have a pop up, be sure to approve this. Once you have be sure to test this connection and save it.
12. Once the connection is successful and saved we will need to toggle provisioning status to on, you will find this in the Provisioning section you were in earlier. If this doesn’t work after your first try do not be too concerned, this can take a few attempts to complete correctly, the first sync can take up to 30 minutes to run too.
13. We will then need to go back into Azure AD and then select App Registrations. Select the app you have been working on. Go to API permissions and add a permission.
14. Under API’s select the 3rd option and select the API for your instance, once selected hit save
15. We will then need to add 1 more permission. Go to Add another permission, go with Microsoft Graph and select delegated permission. We will then choose openID and user.read.
16. You will then need to grant consent with the tenant admin account, similar to the imagine in step 13.
17. Now we must return back to the app. Go to Azure AD, select Enterprise Apps and find the app. From here select Single Sign on where you will need to download the Base64 Cert as well as copying the Login URL and Azure AD Identifier URL.
18. Now it’s time to set up settings on the slack side. First go to your Slack instance and go into Settings and Permissions and be sure to navigate to the Authentication tab.
19. Click on the change settings button next to SAML authentication settings, you will see a menu which asks for SAML SSO URL, Identity Provider Issuer etc. You should now put the Login URL into SAML SSO URL and Azure AD ID into Identity Provider:
20. After you’ve completed this expand advance options, confirm that your FQDN Slack name is in the “Service Provider Issuer Field.
21 (optional). Now under settings tab select “it’s optional” under Authentication for your workspace must be used by:” otherwise change to fit your needs.
22 (optional). Customise your sign in button and save.
Note when this is published, Microsoft are known for updating and making changes to their UI.
Something that is rather niche is the need to change users displays. This need can occur for a number of reasons, one reason perhaps some systems require a specific resolution to work correctly. The issue here is when you need to have this applied across 100s and sometimes 1000s of devices suddenly it becomes a massive job and so we must turn to our great friend, PowerShell.
The first thing to do would be to open up PowerShell ISE add the following
The reason we are forced to make use of the execution policy cmdlet is due to how we’re forced to deploy this via Intune. Normally when deploying a PowerShell script as a Win32 app we would set the system to run, however, in this case this simply is not an option. If the system attempts to run the change to the resolution nothing will happen, it has to be the user which runs this.
The second part handles the installation of the needed module which actually applies these changes via PSGallery. For this to work a minimum version of NuGet is needed. From here we have the final part of the script which actually completes the changes.
This is pretty self explanatory, we are installed DisplaySettings module via PSGallery which allows us the ability to use the Set-DisplayResolution cmdlet. Be sure to change the actual -Width and -Height to what you need. From here you have the option to add a simple detection e.g mkdir and created a folder for testing later in Intune.
Now it’s time to convert this script into a usable .intunewin format which allows you to put it into Intune as a win32 app. I will need to create a guide on this later but for now you can find details on this here.
Once you have this ready you should go into Intune (https://endpoint.microsoft.com/) and navigate to all apps where you will create the app. You will then need to go through the app creation processes
Be sure to have Install behaviour switched to user or this will fail, you should also use the following install command.
Be sure to select both 32 and 64 bit systems via operating system architecture.
The last import thing to do is create a Detection rule, for myself I added the ability to create a folder in the primary script and set up Intune to detect this folder on it’s creation. This way I have the ability to detect if the script ran successfully.
And now simply complete until you have the app saved and having it applied to the correct groups, from here it should complete without issues. Below is the full script.