NoMAD Credential Methodology

I finished listening to the MacAdmins podcast: Episode 78: Nolo Contendere, with Josh Wisenbaker.

Guest Josh Wisenbaker from Orchard & Grove (makers of NoMAD and NoMAD Login) discussed engineering at the Login Window level and modern security.    

I've written about NoMAD before. To learn about the products available from Orchard & Grove click the pictures below.

I want to camp out a bit regarding their product NoMAD Login+ that comes with NoMAD Pro. On the podcast, Josh Wisenbaker said they will be changing the naming of their products so NoMAD Login+ may have changed by the time you read this.

For visual learners such as myself check out "NoMAD Login+ managed via your Okta dashboard" video.

If you are not familiar with Okta then read "Okta Today and Tomorrow: Going Beyond Internal Access Management".

For an explanation regarding development read "Authentication API".

NoMAD Pro allows users to login at the Login Window using Okta credentials. If the user does not have a local account on the Mac then using Okta credentials then NoMAD Pro will create a local username that matches Okta credentials. NoMAD Pro keeps the credentials synchronized.

From NoMAD Pro’s description: "NoMAD Pro can ensure that your user’s Okta passwords are synchronized down to their local accounts on the Mac. With plugins for Safari, Chrome, and Firefox you are able to catch every time a user signs into Okta and make sure the accounts are synchronized".

If your Mac computers and enrolled in the "Device Enrollment Program' then the following workflow occurs:

  • A user unboxes their new Mac, connect to their network allowing for the enrollment into DEP and MDM. 
  • The first item seen is the NoMAD Login+ window. If the user hasn’t set up their Okta and activated Multi-Factor Authentication then the user can set up these items at the Login Window on their Mac.
  • They would then close the window and log in to their Mac account they have just set up.

NoMAD Pro keeps their credentials in sync.

This allows the inclusion of YubiKey or other third party Identity Management solutions. Very cool! 

yubikey.png

If you are unfamiliar with YubiKey by YubiCo then check out this resource.

Included in the discussion was in-depth discussion regarding handling authentication and proving one’s identity on the internet without the help of passwords.

WebAuthn and UAF

Diana Birsan refers to the talk given at OURSA

The movement away from depending on Active Directory for authentication and authorization is exciting indeed. However, I've spoken with too many administrators that will continue to refuse any methodology other than AD. I wouldn't get excited to soon. 

Microsoft SSH Server for Windows.

Being able to connect to Windows PCs using SSH is very useful. It opens a new world of tools that simply did not work prior to Windows 10 “Anniversary update” released last August. I will outline the basic steps for enabling SSH and connecting to a Windows computers using SSH.

Open "Settings". Click "Updates & Security"

Under “Updates and Security” click “For Developers”.

Enable “Developer Mode”. This will change the configuration to install any signed app and used advanced development features.

If prompted to restart, then do it.

Upon restart return to “Updates and Security” and click “For Developers”.

You can turn on “Device discovery” which adds mDNS support for Windows.

This will enable the “SSH Server Broker” and “SSH Server Proxy” background services. Depending on your Firewall settings this will allow the service to listen for coming connections from both private and public networks.

On my Mac, I opened “Terminal” and in my case connected via SSH using the command SSH daniel@10.0.1.5. I’m prompted with the RSA key fingerprint. Type “yes” to continue connecting.

Boom! I’m logged in to Windows.

Notice I am logged in to the “Command Prompt” by default and not the Bash shell for Windows. I can type either bash or powershell to continue using my preference.

Note: Currently, there are no brute-force login protections built in to “Microsoft SSH Server for Windows”. A remote attacker can make continual guesses of your login credentials. You can limit your risk of a brute force attack by disabling login from remote networks. 

Disable public remote network logins:

Open “Control Panel” - “System Security” - “Windows Firewall” - “Allowed apps”

Select “Change Settings”

In the list, locate “Ssh server” and disable “Public”

This limits the service to accept logins from what is identified in Windows as a local and private network source.