Maintenance Connection LoginHub

Discussion of a small intranet setup

When talking about LoginHub, especially on a small system, the term 'SSO' gets used heavily.

The term SSO unfortunately has several definitions. We discuss several of the meanings of "Single Sign On" in other documents. With Maintenance Connection LoginHub aka LoginHub, we try to support EVERYONE's definition of SSO, at least as far as is possible.

Note that we are taking the attitude that NONE of them are 'wrong'. We don't care what might have been the very first meaning of 'Single Sign On' – we ignore that debate. Instead we understand that you have needs and the phrase SSO will make sense in your context based on your use of the phrase.

One working way SSO is used is this:

"I want to sign in once to log into my computer

and then not have to do anything more to sign into MC/MCe.

When I go to a MC/MCe URL I want it to just sign me in silently, not bugging me with USER ID or PASSWORD"

There are broadly two ways though that you might be set up, and the dramatically change how we look at what this means for implementation purposes.

1. You have an Active Directory domain,
2. You are running essentially a very small 'home' setup or a very old style of network "peer to peer" where, at the risk of over simplifying, each computer worries about negotiating security with the other computers.

The first scenario is one of dozens we have been handling in LoginHub since about 2006. The second scenario is a difficult one to work with because the server (MC) has no real way to authenticate your 'local' login on your 'local' computer.

There are also, as noted above, many other scenarios that work, but again, at the risk of simplifying, they all require an internet security setup, such as Azure AD, Ping, Auth0, Google etc.., We handle all of these but they are not the discussion of this document.

Active Directory is FREE. So if the customer is trying to cut costs and thought that Active Directory is going to add additional expense … it is fair that it can take some time to figure out how to use it, but there are lots of benefits that go beyond using it for MC/LoginHub.

In general, if a company looks at the manual cost of setting up Active Directory as 'too expensive', then they should probably be looking at a SaaS solution rather than manage their on on-prem MC in which case they can use LoginHub with Azure AD, noting that many people think Azure AD is much easier to set up than Active Directory (AD). AD is a much older product than AzureAD so AD has a lot of legacy features that might make it more difficult to learn to use.

If you are talking about a SaaS install, then most of the below still applies, but any place I say Active Directory in THIS document , you will switch that to Azure Active Directory. Again, for a small customer, Azure Active Directory, Desktop SSO is included in the FREE level of Active Directory. https://azure.microsoft.com/en-us/pricing/details/active-directory/

NON-Domain vrs Domain network.

A non-domain, such as many home domains (but not all). All computers are independent. They don't trust each other. Any machine to machine trust is either 'given freely' or by some other mechanism, such as an id/password between them.

A domain means, there is a method whereby the computers on the domain/network have a variety of trust relationships.

Independent client computers, connecting to the MCe/MC server

In the case of a single computer on a home network, the computer itself keeps the user's credentials (possibly backed up to a Microsoft cloud server.) When the user logs in, that computer is happy that it knows who the person is.

In the case of MCe/MC, you have software running on a server on the network, and now you have a user that wants to log into it.

If MCe, MC or even LoginHub were to accept their computer's word that the person is who they say they are, then anyone who walks into the office with, say a Windows 10 Surface tablet, would be able to log into MC.

Lowest level. No SSO at all. This is MCe and MC standard, out of the box.

So the 1st level of available protection is "no LoginHub, no SSO". In this case, there are 2 pieces of info to log in: The user name and the user password. They have to be typed and passed either as is or hashed to the server every time, because there are no tools to do anything different.

MC's basic level "just SSO" no user management

This only works on the Accruent SaaS. This only works with Azure AD or Auth0 according to our last report from Accruent.

In this, Accruent provides a paid subscription option for "just simple SSO" with nothing else. In this case, the company must first obtain (pay for) and setup either Microsoft Azure Active Directory or Auth0. Then the MCe/MC software MUST be running on the Accruent SaaS system.

Accruent does NOT make that software available to on-prem customers or to their dealers such as ourselves for our SaaS systems. But to be honest, it does so little that we see no reason for it.

The remaining levels all involve the addition of our tool the Maintenance Connection LoginHub in one version or another.

Illustration: an Intra¹net only solution. The most common on-prem solution.

This is NOT trying to go into all the details of how this is all accomplished. This is the 10,000 foot view.

In this environment, we have the following computers, including servers:

• The user's computers. When they log in, they either have a pre-received 'trust' with the AD server OR in the process of logging in, they receive that trust.
• The SQL server , which can generally be ignored in this document.
• The MCe server (s), which is what the user is trying to log in to.
  • This server has a trust relationship with and a secure pipeline to the SQL Server, the SQL Server 'trusts' it.
• The MC server (s), which is what the user is trying to log in to.
  • This server has a trust relationship with and a secure pipeline to the SQL Server, the SQL Server 'trusts' it
  • This server must be domain joined, have a trust relationship with the AD server.
• The LoginHub server. This server MUST be on the MRO server. It installs itself 'into' MC.
  • This server has a trust relationship with and a secure pipeline to the SQL server, the SQL Server 'trusts' it.
  • This server has a trust relationship with and a secure pipeline to the MC server, the MC Server 'trusts' it.
  • This server has a trust relationship with and a secure pipeline to the MCe server, the MCe Server 'trusts' it.
• The Active Directory server.
  • This server doesn't trust anyone initially. But it hands out 'trust'.
  • This server has a trust relationship with and a secure pipeline to the LoginHub server, the LoginHub server 'trusts' it.

In a typical small on-prem install, there will be 3 physical computers:

1. All the user's computers (obviously this is potentially many computers)
2. The active directory server, the 'Domain Server'
3. The SQL, MC, MCe and LoginHub server or servers

It is very difficult/expensive to try to have the 2nd and 3rd on the same computer. Very few customers have the expertise to have these on the same computer. Though having both on virtual computers is perfectly acceptable. We don't provide the expertise for setting these up that way, and for small customers, it probably isn't worth it. For example: What happens when you are trying to log into the physical computer but the domain server (which lets you log in) is not running.

For the rest of this discussion I am ignoring whether all the above are on three machines or whether there are dozens of servers all in a Load balanced environment, or anything in between.

How does a user get logged in to MCe/MC?

When a user goes to log in, they connect with the Maintenance Connection LoginHub. Possibly passing their credentials.

The LoginHub proceeds to ask the Active Directory – is this a trusted person?

Active Directory looks at the credentials, if any, and decides whether to ask any questions. (This is not 100% technically true, due to caching of credentials. This helps it work even if the domain server is temporarily offline, where temporarily may mean a couple weeks depending on how your AD is set up.)

If the credentials that were passed are acceptable to Active Directory, it doesn't ask the user any questions, it just returns "Yes, this person is person x" with various info about person x (info that the customer who bought LoginHub has set up to have Active Directory pass to LoginHub.)

If the credentials that were passed are NOT acceptable to Active Directory, or there were no credentials passed, Active Directory asks whatever questions it wants to ask.

The typical questions are: What is your username and what is your password. But with 2FA, MFA and non-password authentication, other questions entirely may be asked.

Active Directory then passes (securely) back to LoginHub whatever info they have about the user. This MAY be "nope, don't trust them" if the person didn't meet the security requirements, i.e., they didn't log in successfully.

LoginHub receives this info back (securely) and then, if AD gave back info that the user is trusted, LoginHub decides what else, if anything must be done.

1. Perhaps they need to pick which database (if they have access to more than one.) This info MAY be already known to LoginHub based on how the user connected with LoginHub, such as using a custom URL, or because there is only one database the user has access to.
2. Perhaps they need to pick which application (if they have access to more than one.) This info MAY be already known to LoginHub based on how the user connected with LoginHub, such as using a customer URL, or because there is only one application the user has access to.

LoginHub then uses its trusted status to Log the user in.

So how does this look? Some scenarios.

Single sign on from a trusted computer that knows who 'you' are from MCe/MC's perspective:

The user is on a computer that has been set up with trusted credentials. They go to a link that goes to LoginHub, LoginHub goes to AD, AD says 'yes they are trusted, they are person x', LoginHub sees they have only one database and one application, so LoginHub logs them in.

All the USER sees is a fraction of a second blip and they are in the application. They did nothing to 'sign in' because they were already signed in to AD on their computer.

This is 'Single Sign on' in the sense: The user signed on to THE COMPUTER, and because the computer has trusted credentials and is identified with the user, the 'Single Sign On' when they turned their computer allows them into MCe/MC without logging in again.

Sign on from an unknown computer:

Now we take our friend who walked in from off the street. They connect to the WiFi and try to connect to MCe or MC.

LoginHub passes the info that it received on to Active Directory.

Active Directory says "That computer is NOT from my network", and either denies them access (if that is the rule set in AD) or does it's sign in process, typically asking for ID and Password.

If they successfully log in, AD continues as before.

The user therefore sees typically an ID and password prompt, or whatever AD is set up to require.

An hour later the same user tries to log into MC again, the same process happens, but this time Active Directory still knows who they are, so it gives LoginHub info that lets them in with no prompting.

This is SSO from a very different perspective. Sign in once for the day and never have to sign in again for the rest of the day (or for whatever time period Active Directory DECIDES that that computer is allowed – it may be for weeks.)

But notice in THIS scenario, the RIGHTS to log in are NOT granted to the COMPUTER, they are granted via the login to AD process.

Sign on from a trusted computer but not trusted user

This scenario is common in Hospitals and in manufacturing floors, where a shared computer has a certain degree of rights, such as access to printers, but does NOT have access to the MCe/MC application.

This scenario is essentially the same as the previous one, "Sign on from an unknown computer"

This is actually more difficult than that to set up – because the trusted computer is technically is a trusted 'user', so there is some setup processes that need to be done to make this actually work and LOOK like the 'not trusted user' scenario.

So how is this different from just wanting the client computer to login without AD

If you don't have a trusted provider, such as AD, or Novell or any of the Internet options, there is no way for MC or LoginHub to know to 'trust you'.

So why isn't there a version of LoginHub that essentially builds the trust like AD does?

In theory this could exist.

It is a marketing problem really. Who would pay for it?

You see, most customers that want SSO are big enough to have AD or Okta, or Auth0 or some other authentication provider. Even if they only have 3 or 4 MCe users, they have other applications that they have AD for, so it is a natural fit to 'also' mange MC/MCe from AD (or another provider.)

This leaves a very small number of very small customers who would want essentially us to write a competitor to Active Directory.

There are so few of these customers that the cost to develop the product would mean we would have to sell it for ridiculous amount of money.

But if we sold it for a lot … customers would say "forget it, Active directory is free, and the cost of setting it up is cheap to set up comparatively".

Is there anything a future version of LoginHub might do to help if I don't want to use AD, Azure AD, Ping etc..??

Maybe. Probably. But we would still recommend using Active Directory, Azure AD, Ping Okta etc..,

And the reason that we have never done the features below is quite simple, all of our customers who care enough about security to want the features below want to have a provider like AD to provide the features below, not LoginHub.

We have looked at some features that would be desirable to much larger customers, but could end up helping for this 'small customer' profile:

We have looked at providing the OPTION of having 2FA and MFA (2 factor authentication, Multi-factor authentication.) This would include things like: Having the option of having a barcode show up on the screen that they have to use their phone to scan to gain access. A search on the internet can tell you what some of those are. If you've ever used Whatsapp on a laptop or desktop, you will be familiar with this method of authenticating the laptop.

If we add that capability, we will also add the ability/Option to have Non-Password Authentication. In other words, you will have the option of the ability of Passwords will NOT be a required factor, in the MFA. When we do it, we plan on allowing the customer's option of allowing MFA to only be 'one' factor, and that factor won't have to be a password. We do NOT expect many customers to enable this option due to security concerns by most that that want 2FA.

In this case, any MFA that allows 'the computer' to provide one of the authentications, perhaps a 'key', will then be able to authenticate itself to LoginHub.

Tell me again why I can't just use my login to my computer to be THE authentication

Because if you don't have something like AD or Novell, or we don't have something like a dongle or trusted phone app, we have no way of authenticating you – and you could be anyone off the street. The windows login only has local, to the device, authentication. You need AD or similar to have the local authentication have 'trust' at a server level.

We need a secure source of trust, and logging into a non-domain computer is not a secure source of trust, it was never intended to be, that was why Microsoft created AD.