After attempting to decommission an old Skype for Business 2015 Enterprise Cluster we ran into an issue which was stopping us from decommissioning the cluster itself. The error being presented was “Can’t publish topology because users still homed to pool that would be deleted”. We thought that we had moved all of our contacts and users across to the new but after further investigation we found the following Powershell script which helped us along the way to get rid of the orphaned objects:
Unfortunately, we ran into a problem where this script ended up presenting all of our response groups as being homed on our older cluster. We have identified the culprit piece of code and updated it to match against the pool FQDN you enter in the script. The script can be found below:
Picture the scene – you have a custom enrolment application using ASP.NET identity for authentication and from out of nowhere someone decides that the users now need to be able to login to a VLE to complete assignments. Moodle already has a external database plugin so it can’t be too hard, except it doesn’t support the hashing that identity uses.
Given the short timescale to implement and crazy workload I of course went looking to see if anyone else had done this. There are some threads on Stack Exchange where people have tried to do the same thing and lots of info about how the hashing works so I set about porting the code to PHP only to find that someone had already done a much better job than I’d ever do. Thanks MDHearingAid.
So I cloned the repo and set about bodging it into Moodle. My bodge is not pretty but it works. If you want to do the same thing you can download my patch file (apologies for the Zip, WordPress won’t accept plain text files for some reason) and go at it, just don’t judge me too harshly. This is a patch against Moodle 3.8 but will probably/possibly work against other versions.
Obviously you need connectivity to the database that Identity Services is running on. So you’ll probably want to install Microsoft Drivers for PHP for SQL Server if you haven’t already and then set up your connection in Moodle under Site Administration -> Plugins -> Authentication -> External database. The table name will most likely be AspNetUsers. Username = Username , Password = PasswordHash. Under password format you should now see ASP.NET Identity Service or maybe just [[identityservice]] if my patch to the language file didn’t work properly.
Please note this is not supported by PacketFence/Inverse at the time of writing
There aren’t really any guides out there for Mist and Packetfence integration. During our time working with the Mist engineers we were able to get the authentication services working between Mist and PacketFence. We’ll submit this as a PR to Packetfence in the hope that it’s included in the main release.
To make this work you need to configure the Mist system with an SSID with the following security parameters:
From here the Mist system attempts to authenticate the device using RADIUS-MAB against the PacketFence system. Should PacketFence not authenticate the device, it returns a redirect request for the device which the Mist AP picks up and forwards to the client so that they can register.
The CoA settings are required here as, should the user no longer become registered e.g. PacketFence times out the device, then a CoA is sent to the Mist system for the device to be disassociated from the wireless environment.
Firstly, the Mist.pm perl script will need to be installed into the PacketFence environment so PacketFence understand hows to communicate with Mist and to perform the CoA requests as per the configuration. To access this please visit here: https://github.com/talanw/mist-packetfence
Once connected you can see your meeting policies and the current DesignatedPresenterRoleMode with
Get-CsTeamsMeetingPolicy | ft Identity, DesignatedPresenterRoleMode
Set your policy to allow only the organiser to present by default and allow the presenter to override this setting. I’m going to do this globally but obviously replace the identifier with whatever policy name you want to set.
Set-CsTeamsMeetingPolicy -Identity Global -DesignatedPresenterRoleMode OrganizerOnlyUserOverride
You can set four options here, which are self explanatory
Login to your Azure portal and go to Azure Active Directory -> Enterprise Applications -> New Application. Click “Non-Gallery Application”, enter whatever name you wish to use for the Application, e.g. “Mist” then Add. Go to the new application, click “Single Sign-On” and select “SAML”. Copy the “AzureAD Identifier” from section 4.
Click on the pencil icon next to SAML Signing Certificate and set “Signing option” to “Sign SAML response and assertion”
Download “Certificate (Base64)”
Login to https://manage.mist.com and go to Organisation -> Settings. Under Single Sign-On click “Add IDP”. Enter a name such as “AzureAD” and complete the fields as per the below table. For the certificate, open the “Certificate (Base64)” file that you downloaded from your Azure app in a text editor, copy the entire content of the file and paste into the “Certificate” box.
The rest of the fields can be copied and pasted from your Azure app as follows
Custom Logout URL
Content of downloaded “Certificate (Base64)”
Next, we need to complete the configuration of Azure. You can do this manually, but it is easier to download your metadata file from Mist and upload it to Azure.
Go to your AzureAD application -> Single Sign On – > SAML -> Upload metadata file and select the metadata.xml you downloaded.
You now have SAML set up between AzureAD and Mist, but you can’t login as you’re not currently passing a “Role” attribute.
Firstly, log into Mist -> Organization -> Settings. Under “Single Sign-on” click Create Role. For “Name” enter a sensible value for each role that you wish to set up.
It probably makes most sense to use AzureAD group memberships for this. There are several ways to do this, but we do it like this.
Go back to your Azure Mist app -> Single Sign-on. Click the pencil button next to “User Attributes & Claims” then “Add a new claim”. Enter the name as “Role”, source as Attribute and then enter “None” in the “Source attribute”, this ensures people that aren’t in the correct groups get a role of “None” which prevents them from logging in.
Expand “Claim conditions” then in the “User type” dropdown select “Members”. Click “Select groups” and select the relevant group. For “Source” select Attribute and for “Value” type in the Mist role name you wish to assign to users that are members of this group. Continue to add groups for your desired roles.
In your Azure Mist app you’ll need to grant access to users at “Users and Groups”. Add the relevant groups to allow access. Users will see Mist in the Office 365 launcher under