by Gareth | Jun 19, 2018 | ADFS, Facebook
I decided to write this article as if anyone is an early adopter like us for Facebook Workplace and has SSO issues on ADFS as the documentation here at the time of writing is limited and makes some assumptions. I will try and save you some of the time with a few tips below
TLDR:- If like me the main issue for login loops is either the users are not set to SSO or you get the following error
SSO Not Authenticated
The SAML Response was invalid. Please check that all fields are correct and try again.
Well, this part is most likely down to the email address not matching or even better a trailing / at the end of the ADFS URL’s! (I wasted an hour or so on this)
The next piece of advise I will give you is if you are going to use Azure AD as an IDP provider for the user’s detail get the SSO working before setting this up. Otherwise, you need to delete the users or use the bulk edit tool to set everyone to SSO within the People menu. Press the Edit People button
Within this menu select download CSV, this will then generate an email to the admin user you are logged in as.
Once downloaded open the file and you will now see that you can change users on mass from password to SSO
The way you can tell that a user is SSO or not is by hitting the … at the end of a user, below is a pre-synced user before SSO
And this is an SSO user, as you can see the force SAML authentication part appears
But of course first you need to get SSO working and this is probably why you are here. Firstly the documentation you follow from Facebook may differ as this all depends on the version of ADFS you are using. I was using Server 2016 and not 2012 like their screenshots so just follow this the best you can. You will also notice at the time of writing when you follow the hyperlink for next steps in the PDF you get this page, don’t panic! I listed out what I did below.
I fumbled along and came up with the below from what I gathered from the data in the PDF guide
Now you will hit Test SSO and now get the same error as I did
I even got the following error in my ADFS logs whilst I was playing around with the transforms. If you get this then you may have a typo in them as the E-Mail Address field is case sensitive and slightly different and again typed wrong in the PDF versus the screenshot
Description:
The SAML authentication request had a NameID Policy that could not be satisfied.
Requestor: https://www.facebook.com/company/COMPANYID
Name identifier format: urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
SPNameQualifier:
Exception details:
MSIS7070: The SAML request contained a NameIDPolicy that was not satisfied by the issued token. Requested NameIDPolicy: AllowCreate: True Format: urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress SPNameQualifier: . Actual NameID properties: null.
I played around with this for a bit thinking I had done something wrong as when you copy the URLs from your ADFS config like below they have a / at the end of them, ignore this… it appears the URL generated by the SSO in Facebook already adds this. Remove this from your URLs above so they now look like this
If you press Test SSO again now if all things are in order you should now see the following
You will also notice the form will refuse to save until you get the above message. You may also need to add additional email domains to allow single sign-on depending on their primary email address.
Toggling Users:- If you need to toggle a specific user between password and SSO select the … at the end of the user and scroll to the bottom and change the login with
by Gareth | May 24, 2018 | AirWatch, VMware
So this week I have been playing with AirWatch (AKA WorkSpace One) and the latest version. I have been slowly working on fully automated MacOS build and I came across a bit of a snag with deploying some of the application or rather to my surprise, AirWatch could do apps that are not in the App Store.
One main application I have always had issues with is Adobe and getting this to package nicely has always been a pain down for various reasons. I did try and see if this would work with AirWatch natively and well it doesn’t but thankfully digging into some of their code it appears at the time of writing this they are using a Munki backend of which I am quite familiar with. In essence, it’s like SCCM for Windows.
The first point I need to make is I am offering this advice assuming you are correctly licensed for Creative Cloud and you take the relevant steps to ensure it only goes to the intended users despite them needing a registered email to activate the software.
If you want to learn more about AirWatch I am going to be doing a series of posts to complment this one or head over here for more information
TLDR:- Basically you need to create a managed package as the self-service isn’t signed and Apple Gatekeeper blocks this (a few hours wasted here). This then also caused the install to fail in a managed package but you also need to make this a managed install for it to work. Hopefully I can do a video guide soon
TLDR2:- I want to keep working on this and see if I can just get the Creative Cloud App so it reduces the install size
One of the first steps to do is generate the installer for Creative Cloud. You can do this by logging into https://adminconsole.adobe.com/ and selecting Packages at the top.
Once in here select create a package and select Managed package.
Select all the options you need within here such as locale
From here select Photoshop, I know this one works and to be fair most people using the cloud apps will need this. I did try Adobe Reader but again for some reason the install would fail
In this next screen it will confirm the application selected. Use a name that will be displayed on AirWatch, for example, I used Adobe Cloud to make it obvious to my users. It appears that you cannot change this in the main console which would be a nice feature to see in the future.
Once the package has built, download this if it doesn’t start automatically. You will now need the VMware AirWatch Admin Assistant which you can get here. Open this and then drag you Adobe Cloud Install PKG file that is in the build folder of your download from Adobe
The application will sit there for a little while whilst it process the PKG file depending on its size as you may want to push the whole suite. Once it completes it should ask you to reveal this in finder
You should now see a folder with your application name, go into this and it usually has the please edit me at the end
In here you will find a .plist file you need to open this up in an editor and change the unattended_install value to true , I am using Xcode that allows me to select yes. At this stage, you could rename the DMG file and plist to something nicer reflecting this in here but it’s always best to test this as is first
Now due to the size limitation of 200mb at the time of writing this you need to upload the DMG that is within the same folder to a web server you clients can see. I would suggest protecting this still by HTTPS if you can and ensure you have this URL for the next step. In your AirWatch console select Apps & Books from the left and then Native. Within the sub window select App Application
Within this window select upload
In this window select Link and paste the in the URL to your web server hosting this file, select save and continue on the previous window
On the next window we need to upload the plist file you modified so the App Store knows how to install your app, do this by hitting choose file and then locate the file. Once done you will be back at the add application screen and select continue
You should now see the following screen and if possible at this point I add an icon so it doesn’t get the standard AirWatch icon. Fill in your categories and also and other details the like description you want and hit save and assign.
In this screen this selects which users will get the application shown in the app store, Press add assignment and fill in the details you want. I have selected All Devices just for demonstration purposes but do this to a group licensed for Adobe
I have found a bug on this next screen especially on Safari but select the radio button and then save and publish otherwise the assignment may not be saved.
You should now see a list of users this may affect if they are already in the correct groups and press publish
From here head back to the users machine and see if the application now exists, select Install and then confirm the installation
The icon should then change and this next bit can take some time depending on your web server and network
Eventually, this should go green and state installed. If you head into the users application folder you should now see Photoshop and the Creative Cloud Launcher where they can sign in for more applications
by Gareth | May 22, 2018 | #vExpert, AirWatch, VMware
So I am going to be honest as many of you know I use Apple devices most the time just down to their simplicity and integrations but recently I have had the chance to use the latest version of AirWatch and a newer based Android Device.
The enrolment process is not quite as slick as iOS where it forces the user to enrol with your companies deployment but it can be as simple as a few taps (7 plus a few more) and a scan of a QR code. You may find as an IT department you still enrol users devices anyway so this won’t bother you that users may try and skip this step. At a guess I am sure some vendors will catch up and have a portal similar to Apple DEP before long.
The actual term for this in the Android world is called “Work Managed” but you will need to ensure you have your Google for Work set up before you do this or you won’t be able to push any applications to the device. This can also negate the need for the Google Play store on the device and your users needing separate accounts or everyone sharing a department account. I will do a separate post on the Android at Work as this also offers some great features.
But back to the enrolment, its as simple as open the box, pop the SIM in the phone, power it on. From here tap ‘Welcome’ 7 times and this will then take you to a hidden screen. Join the WiFi to save data if you wish and then this will download a QR reader. You will need to generate your own code using this guide from here and I found leaving the username password as it was caused the agent to get confused then ask me for that users credentials so I didn’t have to create unique codes. I used this website to generate my QR code
I used my top level group ID as when the user authenticates this should override this if they are in other smart groups. You can easily find this by going to the top of your organisation and then hovering over the name for a moment and this box will appear
Once you have added a user if you have your profiles and apps set up they should start streaming down to the device. I do certainly like the fact Boxer can be setup to auto configure from the user who enrolled and all they then need to put in is their password to start getting their emails. This is also quite nice if you wish to offer a BYOD or let user have their personal account on their phone as the in built client can then provided segregation.
The hidden power of doing it this way is when the user leaves despite being a good or bad leaver if the device is reset you can get back into it as the device is managed by the organisation. I have seen many devices been handed back into IT that have personal Google account on of which we can then not reactivate the device easily without the leavers details.
If you want to learn more about AirWatch I am going to be doing a series of posts or head over here for more information
by Gareth | May 10, 2018 | Uncategorised
So this week I have been performing an Office 365 migration and part way through federating my domains and getting ADFS up and running I came across this error below
First thing I did was go have a quick look at what was going on within the Event log and there was a rather odd error. This can be down to your service account losing its groups or the DCOM components losing their permissions too but mine seemed to be ok
Scheduler::SchedulerThreadMain : An error occured and scheduler run failed to perform all operation.
System.Management.Automation.CmdletInvocationException: Run profile ‘Full Import’ does not have run steps. —> System.InvalidOperationException: Run profile ‘Full Import’ does not have run steps.
at Microsoft.DirectoryServices.MetadirectoryServices.UI.WebServices.MMSWebService.InvokeRunProfile(String connectorName, String runProfileName)
Firstly do try a repair of the install and ensure you are at the latest version, as I said before this may be permissions related but if not after much head scratching for some very very odd reason all my rules had been dropped in the Synchronization Service Manager. To be honest I never got to the bottom of quite why they vanished during switching over the federation but to get things working again launch the application and goto the connectors tab
You should see you main AD and any others you wanted to sync in your forest. select your local AD Domain Services and then select configure run profiles on the right hand side
Within this window it will probably now look rather bare and this is what the cryptic error is going on about. It basically doesn’t know what to do!
Repopulate all the option including the export which is pretty much simply select the matching type to the profile and ensuring your base DN/partition is correct
Do make sure your Export one is populated as I found my password sync stopped working and had to do this and then use the Wizard to remove ADFS and flip back to password hash and then re-integrate. If you don’t do this you will see errors in the 365 Portal stating Password sync hasn’t occurred and get this error in your event log despite things now looking like they are syncing
Scheduler::SchedulerThreadMain : An error occured and scheduler run failed to perform all operation.
System.Management.Automation.CmdletInvocationException: Run profile ‘Export’ does not have run steps. —> System.InvalidOperationException: Run profile ‘Export’ does not have run steps.
at Microsoft.DirectoryServices.MetadirectoryServices.UI.WebServices.MMSWebService.InvokeRunProfile(String connectorName, String runProfileName)
at Microsoft.IdentityManagement.PowerShell.Cmdlet.InvokeADSyncRunProfileCmdlet.ProcessRecord()
— End of inner exception stack trace —
at System.Management.Automation.Runspaces.PipelineBase.Invoke(IEnumerable input)
at System.Management.Automation.PowerShell.Worker.ConstructPipelineAndDoWork(Runspace rs, Boolean performSyncInvoke)
The final thing to do now is run the sync by right clicking the AD connector, selecting run and then the relevant task. I did select full first just to make things are working.
Hopefully you will now see nice informal messages in your event log like below and your 365 portal should update within the hour to say its all back in sync
I have to say these two resources helped point me in the correct direction https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnectsync-configure-filtering#update-the-run-profiles
https://social.msdn.microsoft.com/Forums/azure/en-US/3398333e-9e79-4261-bd8c-966fd18fd105/configure-aad-sync-element-marundata-was-not-found?forum=WindowsAzureAD
