[BlueOnyx:20433] Re: External Authentication

[Michael Stauber]

Hi Chris,

> As we have been adding staff, I was wondering about the ability to have
> BlueOnyx and Aventurin{e} use external authentication that syncs with
> our LAN user credentials.   In other words, our Active Directory
> permissions.
> 
> We've been integrating as much as we can in order to simplify management
> of credentials.

I once looked into such things ages ago and I might need to check again
to get up to speed on the topic.

Generally: A Linux box authenticating against Microsoft Active Directory
seems to fall back to LDAP client auth, which means if we ever get this
working it'll cover both Active Directory and LDAP in general.

As far as the GUI is concerned we do have a small issue here. Whenever
CCEd authenticates, it requires a local user. That user must exists in
CODB and on the system level (PAM and/or Passwd). This is such a core
functionality of CCEd that it will be really tricky to ever get around
this without lots of complications.

Upon login we see if this user has an Object. If he does, we check the
password against PAM. Which in turn currently is configured to check
Passwd as far as CCEd is concerned. If that matches, the user gets a
temporary SessionId that's used for the rest of the session to identify
him and his access levels.

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.

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.

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.

It would work like this:

BlueOnyx (or AVE) has the API enabled and configured. Access to the API
is only granted to the IP of your WHMCS control server. In your WHMCS CP
you'll get a new button called "Create Support Account". If that is
triggered, the extra-admin account alter-admin is created, a random
password is set and you get an email to a specified account of yours
that contains IP, hostname, port that SSH runs on, the username, the
password, a PEM key and public key for SSH. This temporary account will
be present for a configurable amount of time (I suggest 8 hours). After
that it will be removed automatically by Active Monitor.

Like said: We use this feature currently for support requests and it
works quite well. In our case it's of course triggered by a GUI
transaction of the server owner in case he wants to allow us in. But in
usage cases like yours (ISP managed servers) we can easily tie that into
the API as well and expose it to WHMCS. There would be no security
implication because it'll only answer to the configured WHMCS server.

Just some food for thought.

-- 
With best regards

Michael Stauber