Sunday, 22 September 2019

Is the File Server EOL ?

Previous posts have examined the problem of incorporating traditional file shares into a serverless solution, exploring such issues as;

  • How do you share files when you don’t have a local server ?
  • How do you apply a cloud based security model to a platform that only understands local Active Directory?

Although several solutions have been proposed it turns out there’s a simple answer - don’t use network file shares.

Before we examine the alternative it’s important to appreciate how long the F: drive has been with us and how deeply ingrained it is into the IT psyche. For most users file sharing is what a network does. This may be the reason why we have failed to appreciate how completely unsuited it has become to modern work practices.

The standard Windows file share has a list of limitations that is both long and varied.

  • No easy offline sync or mobile access.
  • No file versioning.
  • No recycle bin
  • No retention policies
  • No event logging
  • Poor search functions.
  • Poor integration with cloud based user directories.
  • Primitive document sharing using simple file locking.
  • Requires a high availability, backup and disaster recovery plan.


And of course file sharing depends on a server that requires patching, licencing, upgrading and monitoring.

Most, if not all of these limitations can be eliminated by employing more software or additional hardware (which also requires patching, licencing, upgrading and monitoring) but in the end you’ll still be left with a complex second rate solution that’s not flexible enough to meet the needs of a mobile workforce. Let’s face it, the F: drive has had a good run but it’s time to search for an alternative. So how do you replace the file server in a modern workplace that has no servers.




The first clue was when Dropbox started to appear on work PC’s synchronizing cloud storage to the local drive. Since then this model has been refined and extended by both Microsoft and Google and now it’s ready for prime time.

In the future, Microsoft expects you to access files through Team channels which act as a front-end to Sharepoint document libraries. The Sharepoint engine provides all the elements missing from files shares including content search, a recycle bin and a comprehensive versioning journal. Event logging and retention policies are other quick win. The close integration with the Windows10 OneDrive client allows the user to control synchronisation to the local device.

Clearly the sharing capability, collaborative workflow and mobile integration is light years ahead of a simple file share but perhaps the breakthrough feature is the ability of the OneDrive client to expose the Team channel within File explorer.  In many ways the user experience is identical to using file shares and therefore it can provide a clear migration path for organizations that want to move to a severless solution without significant retraining around new applications and the use of a web interface.

Because Microsoft are using this framework as the foundation of M365 these capabilities are baked directly into Windows10. So why not take the opportunity to trial these features as part of your Windows10 migration and ditch those servers.

Coming from the Google world this will be very familiar - being completely cloud based G Suite users have been working this way from day one. Versioning, collaborative working, extended search and mobile integration have always been part of the package. Google Vault provides the retention, legal hold and e-safety features while the G Suite admin consoles gives you the capability to report on file access.

In addition Google File Stream mirrors the features of the OneDrive client exposing Google Drive in File Explorer as a mounted drive and allowing direct access from native applications like MS Word and Photoshop.

The obvious conclusion is that both the major payers are offering the same solution. You can have the Microsoft version or the Google version but it’s essentially the same vision.

You still have local files, they are just delivered in a different way.

Instead of one central device that needs managing, protecting and opening out to external access you have a central cloud store backed by elastic storage that replicates data down to each personal device regardless of the location and platform using intelligent algorithms that determine the precise requirements of the user.   Data can be protected, ring-fenced and be subject to centralised retention policies.

Contents of the files can now form a valuable data resource that can be subject to big data analysis rather than offering up a simple list of file names. Onsite backup and disaster recovery plans are a thing of the past. It’s a modern data management strategy.

It’s unlikely that file servers are going to disappear overnight. They’ll hang around in the same way that one-task physical servers persisted in the face the face of virtualization but in the end they’ll go because, like virtualization, the alternative is better.

Saturday, 3 August 2019

Using Azure AD credentials with RDP.

As schools start to deploy InTune managed Windows10 desktop with an Azure based user directory a few interesting challenges emerge.

One of these is remote support of Azure joined Windows10 desktops using the RDP client. Using the default settings, the Azure AD (AAD) account credentials are rejected by the client dialog which stops the process in its tracks.

So how can you RDP into an Azure joined Windows10 device using your AAD user permissions?

The first job is to disable Network Level Authentication (NLA) for Remote Desktop Connection on the target Windows 10 computer.

Open System Properties and navigate to the Remote tab. Under Remote Desktop make sure Allow remote connections to this computer is enabled, and that Allow connections only from computers running Remote Desktop with Network Level Authentication is unchecked.



The second task is to edit the .rdp file you are using for the connection so it looks like this

full address:s:<ip address>:3389
enablecredsspsupport:i:0
authentication level:i:2

These settings disable any credentials being sent to the host computer.  As a result the host will be forced to present the logon screen rather trying to create the session prior to connection. This way you have the opportunity to present your AAD account details.

Now you will find that entering the AAD details in the logon box will open up a desktop.  This works fine with all accounts that have local admin rights but what if you try with a standard user account. You’ll find you get a rejection notice informing you that the user does not have the rights to a remote session which is expected as they are not a member of the Remote Desktop Users local group.

Opening up Local Users and Group MMC console on the console doesn't help you as there’s no way of selecting Azure AD as a source. Fortunately you can add users from Powershell.

Open up a powershell session with admin privileges and type.

net localgroup “Remote Desktop Users” /add "AZUREAD\JoeShmoe@yourdomain.com"

You should get a “Command successful” and the user account will be listed as a member in the Local Users and Group MMC console. The next RDP session will work as expected. The same technique works for any local group that needs to transfer Azure AD account rights.


Sunday, 7 July 2019

Using Google to authenticate Microsoft (p2).


This is the second part of an extended post that describes how to use Google as an identity source for Microsoft Azure Active Directory (Office 365).


The next stage involves configuring Azure to pass authentication requests through to Google rather than handling them locally. Using technical terms we are creating a federation between the two platforms with Google acting as the identity provider (idP) and Azure the service provider. As before we’ll work through this example using theserverlessschool.net which is a custom domain in a Azure AD  tenancy.

Note: Each federation object acts on a single domain so it’s possible to have many custom domains within an Azure AD  tenancy, some federated to Google (or some other idP) and some locally authenticated.

All of the work is done from the powershell console so the first job is to install the modules listed below within a session running with local admin permission. You’ll also need details of an admin account for Azure AD.

Microsoft Online Services Sign-In Assistant for IT Professionals RTW
Microsoft Azure Active Directory Module for Windows Powershell.

The first module is a simple download. Once installed it’s loaded with the command.

PS C\:> Import-Module MSOnline

Then login to Azure AD using an admin account using the commands.

PS C\:> $Msolcred = Get-credential
PS C\:> Connect-MsolService -Credential $MsolCred

Creating the federation is a one line powershell command Set-MsolDomainAuthentication Unfortunately the number and complexity of the arguments turns it into a bit of a monster.

To get round this problem the input variables are read from an xml file and since most of the values are standardised you only need to update two elements before running the command.

The template xml file (dfs-pf-samlp.xml) can be downloaded from the original GitHub repository or from here.

Before using the file you need to replace the string GOOGLESAMLID with your domains unique idpid recorded when setting up SSO in G Suite. The input  line should be similar to this:

https://accounts.google.com/o/saml2/idp?idpid=C03idbhgle

Note that GOOGLESAMLID occurs three times in the file and needs to be replaced in each location.

Lastly you need to carefully copy the certificate string from the IDP metadata file saved from the SSO setup process and paste it into the location below.

<S N="SigningCertificate"> YOUR CERTIFICATE GOES HERE </S>

A shortened version will look like this.

<S N="SigningCertificate">MIIDdHCCAly…...BAkTD0dv</S>

Make sure you paste as a single line and do not introduce any line breaks or extra characters.

Once that’s done we can create the federation using the command below, substituting theserverlessschool.net for your domain. The command is shown with line breaks but needs to be issued as a single line command.


Set-MsolDomainAuthentication -DomainName "theserverlessschool.net"
 -FederationBrandName $wsfed.FederationBrandName
-Authentication Federated
-PassiveLogOnUri $wsfed.PassiveLogOnUri
-ActiveLogOnUri $wsfed.ActiveLogonUri
-SigningCertificate $wsfed.SigningCertificate
-IssuerUri $wsfed.IssuerUri
-LogOffUri $wsfed.LogOffUri
-PreferredAuthenticationProtocol "SAMLP"


A couple of other useful commands:


Get-MsolDomainFederationSettings -DomainName "theserverlessschool.net" | Format-List
    Shows the federation settings for the domain in the  console.


Get-MsolDomainFederationSettings -DomainName "theserverlessschool.net" | Export-Clixml dfs-pf-samlp.xml
   Dumps the settings back into the config file.


Set-MsolDomainAuthentication -DomainName "theserverlessschool.net"  -Authentication Managed

   This command switches the authentication back to locally managed and effectively turns federation off. This is particularly useful as a fall back option but it also allows you to update the settings as the values cannot be changed while the federation is active.

Azure will now pass all authentication requests to Google for any non-admin account in the domain “theserverlessschool.net”.  So what does that look like ?

Open up a Chrome session in incognito mode, navigate to https://office.com and select Sign In. When asked for a user account enter an Azure username from your federated domain. After a short pause you’ll be directed to the standard Google dialog which will grant access to office.com.

So what happens if you try and login to an Azure joined Windows 10 device with the same Google user account. You might expect the same behaviour but that’s not what you see. The Windows logon box remains and the Google password is refused. Nothing has changed. So why is that ?

By default the conversation between the Windows 10 device and Azure doesn’t use SAML but WS-Fed (WS-Federation), a protocol supported by IBM and Microsoft but not Google, therefore the hand-off falls at first hurdle.

What you need is a Windows logon process that understands SAML not WS-Fed and with Windows 10 1809 edition you have exactly that.

The feature is off by default but can be turned on using a custom policy in InTune.


OMA-URl
 ./Device/Vendor/MSFT/Policy/Config/Authentication/EnableWebSignIn    


After deployment you are offered an additional option on a globe icon - Web Sign-In.



Select this option and sign in using your federated account. This time you will see the redirection and you’ll be presented with the familiar  Google login dialog which will grant access to the Windows desktop.

You have to enter the logon account name twice because Azure needs to know the username before it can offer the redirection. In the future it will be slicker and remember this is still a preview feature.


Summary.
In an earlier blog post I predicted it would be a while before we saw a Windows device using a Google account to authenticate.

A year later, here we are.
This could be used as an example of how wrong I can be but I’d prefer to think it reflects the pace of change and the general move towards open standards.


The new framework is becoming clearer by the day.

Cloud based user directories controlling MDM managed devices that host SaaS applications delivered through a store model backed by subscription licencing.

Google, Microsoft take your pick - they both offer the same vision. You can even mix and match.

The only thing you can be sure of is the fact that not a single element will require a local server.