[BlueOnyx:20436] Re: External Authentication

[Chris Gebhardt - VIRTBIZ Internet]

Hi Michael,
Thanks for the analysis and explanation.  Plenty of food for thought to 
chew on there.

On 12/28/2016 12:41 PM, Michael Stauber wrote:
> If we use LDAP or Active Directory we need a "plugin" of sorts that
> handles the sync between the user database of the external auth
> mechanism and the CODB. Which will complicate things a little. However,
> I can do most of his before we hit CCEd. So by the time it does, we can
> make sure that the LDAP auth has finished and if it was successful, I
> can create the user before CCEd is bothered. Yet this needs to be done
> with an extreme attention to detail because of some security precautions
> I need to take to make sure that this is as secure as it can get.

This is my favorite of the methods you suggested.  The idea is that at 
the GUI, our tech is able to enter his username or username at domain.local 
along with his Active Directory password and he gets access into 
BlueOnyx as "admin".   If we activate or de-activate a user in AD or 
change that user's password, the BlueOnyx or Aventurin{e} GUI login will 
reflect that.

> Another and much easier method would be: We create a maintenance account
> with a randomized password that can be enabled in the GUI of a BlueOnyx
> or Aventurin{e} if (and only if!) external Auth is enabled and
> configured. If LDAP or Active Directory is configured and a login with
> this maintenance account happens, it checks the login credentials
> against LDAP/AD and if that matches, the user gets in.
>
> That way it doesn't matter what (random) password the maintenance
> account has and whenever you update the pass in your external auth
> database it'll work on all client boxes that use LDAP/AD.
>
> Drawback: Fixed account name. We can make it configurable in the GUI,
> though, although a default name like "isp-admin" or "noc-admin" or
> something like that will be offered.

If I understand this correctly, this is roughly equivalent to setting up 
another server admin, and we'd have that user ("isp-admin" or 
"noc-admin") in Active Directory.  Rather than share "admin" 
credentials, we're sharing alternate admin credentials.  The buyback is 
that you can manage the password centrally.

> Here is another option which I might suggest and it would make things
> simpler for coding purpose, as it ties into existing and proven mechanisms:
>
> If your Aventurin{e} and BlueOnyx boxes are tied into WHMCS via the API
> anyway, then we could rig the current support request feature in a way
> that it would grant you access to managed boxes.

I see - yes, that would be the easiest, most immediate solution, 
although as described it would be most cumbersome for regular operation. 
  In practice, as I understand it, this would require the tech to get 
into WHMCS, activate a function there via the API, receive an email with 
credentials & SSH keys, then go to log into the server.  Oh, and that 
info would be emailed to... an individual?  A roll account?  I suppose 
you could fill in the blank with the tech's email if you pull that from 
the WHMCS records.   Otherwise, it goes to a roll account that is going 
to all techs, on duty or not, who could well be checking their email 
from home, on their mobile, etc.   Not sure I love that.

As it stands now, we have our techs using their web browsers to log into 
the various servers, all using the "admin" account, and passwords stored 
in the browser.   That makes it very quick to access whatever particular 
box needs attention.

Of course, we could set up additional admin accounts, but then you have 
to add all those accounts for the individual techs, and keep them 
maintained / up-to-date on each server.   Ooof.

> Just some food for thought.

Absolutely.   Who wants desert?  ;)

It's entirely possible that AD or LDAP integration onto Aventurin{e} and 
BlueOnyx isn't worth the hassle.   Maybe what we have now is good enough.

For the small operators with a couple servers and operating as a one-man 
shop, the regular admin/password login at the GUI is certainly adequate. 
  I'm not sure if there are enough BlueOnyx operators out there who 
share the concerns that I'm expressing.   I'm good with that.   Just 
thought as long as the centrally managed credentials have become a 
project in our shop, I'd put the question out there.  TBH, I wasn't even 
sure what all the considerations would be, though I was vaguely aware 
that the Linux user issue would be some sort of obstacle.

And of course, the first option, which is the most complicated 
implementation by far, is the one that works best for our usage case.

Bottom line: if it's a feature that would be in some sort of demand and 
it's not too troublesome to implement, it may be worth pursuing.   If 
it's a big chunk of work that answers a question nobody's really asking, 
we can forget about it.

-- 
Chris Gebhardt
VIRTBIZ Internet Services
Access, Web Hosting, Colocation, Dedicated
www.virtbiz.com | toll-free (866) 4 VIRTBIZ