[Info-vax] LDAP

[Dave Froble]

On 10/11/2020 12:56 AM, Stephen Hoffman wrote:
> On 2020-10-11 00:11:11 +0000, Dave Froble said:
>
>> I think using LDAP for passwords for VMS access is a good idea.  Let
>> those people who are suppose to be controlling such things do so, and
>> without having to know much about VMS.
>
> That's all that OpenVMS supports. Passwords and the associated account
> status.

For me, and it may not be the same for others, I see a fundamental 
difference between "access" and just about everything else in SYSUAF.

>> Now, everyone knows I don't get out much, so the following may not be
>> accurate.
>>
>> There is much in SYSUAF that is rather VMS specific.  Trying to have
>> people without VMS experience setting up some of that data seems
>> counter-productive to me.  Usually, this data doesn't change, so have
>> a VMS person involved in setting up such data seems reasonable.
>
> It's true that there's OpenVMS-specific data in SYSUAF and ilk, but
> there's no reason that SYSUAF, SYSUAFALT, RIGHTSLIST, NETPROXY,
> NET$PROXY, SYSALF, and ilk is the only place where such user-related
> data can be stored.

Of course ....

But for now, that's how it works, and, it does work.  Even if the SYSUAF 
data were moved to some database product, it is my opinion that much of 
that data should remain on individual systems or VMS Clusters.  While 
I'd like to see less customization of SYSUAF data for particular 
purposes, such can still exist, and be useful.

> Beyond tradition, of course.
>
> LDAP is easier to store additional data, and it operates across not just
> hosts and clusters, but can be configured to operate across isolated
> servers.
>
> Single sign-on across a wide variety of hosts can be available, all
> configurable from the directory.

Which in many cases would be a good thing.  "Sign-on" is "access" to the 
system(s).

> With a wider view, the directory can also spot more subtle patterns of
> attempted access than can OpenVMS break-in evasion.

A vital part of "access".

> LDAP also has other advantages here, such as the ability to apply
> default settings for groups of computers and groups of users.

Yes.

> OpenVMS tries to implement parallel settings (badly) with multiple
> SYSUAF files within a cluster, a little known and really ugly detail
> that's also documented and supported.

I don't do clusters, but, it has been my impression that most implement 
a cluster wide SYSUAF, not one on each node.  At least Phillip does that.

> LDAP allows those settings to be overridden specifically and selectively
> on a per-host or per-user basis.
>
> This rather than the OpenVMS multiple SYSUAF approach.
>
> Which is a wholesale replacement and not a selective override, and which
> also requires added maintenance to avoid skewing UIC and identifier values.
>
> Apps and app-level data are also available within LDAP, too, though
> OpenVMS knows approximately zilch about that. Apps can use that if
> they're LDAP-aware, but OpenVMS isn't.

Not something I'd do.

> What can happen here with apps and app data?  Load up the details of the
> FOOBAR app in the directory, and configure the FOOBAR app network-wide.
> Or specific groups of hosts. Or specific hosts. Or specific users.
>
> In OpenVMS terms, think cluster logical names here, though with a far
> better and far more flexible design and implementation. And with rather
> less of the logical name hackery.
>
> But then configuration data stored in logical names is little more than
> a widely-used and very ugly mess.

I'd agree with "ugly".  Apps should not do these things.

> Think of system- and cluster-wide logical names, and SYSUAF and related
> files, and app configuration files and startups all re-thought, fully
> distributed, and with full server replication support and failover for
> robustness. Certificates and other data, too. That's LDAP.
>
> LDAP is also more extensible than is SYSUAF and related files, so we
> don't end up with the "fun" that was the SYSUAF migration some years
> ago. (IIRC, there was a SYSUAF change some twenty years ago that meant
> some SYSUAF operations in a mixed-version cluster had to happen only on
> newer hosts and not on older pending completion of the migration, but I
> don't recall the OpenVMS versions involved there. This because the
> record definitions changed. Changing SYSUAF RMS record definitions is
> somewhat more of a project than is changing LDAP records, much as
> messing with RMS records can be more more of a project than are updates
> to databases using SQL or ilk.)
>
>
> Add in Kerberos or ilk for added fun of delegation and single-sign-on
> network-wide—OpenVMS has some support for Kerberos in telnet and a few
> other places, but that's also rather stale.
>
>> For most, I'd think allowing the use of a "local" password would not
>> be reasonable.  Too much chance to get around the corporate (or
>> whatever) control of access.
>
> The "fun" here is that OpenVMS has to have that local username at
> present, as that's where the user and process settings are stored.

"Username" is not the same as "Password".  Username defines a user, 
Password defines access.

> Whether the login is permitted while disconnected from the directory is
> another discussion. Some folks will want that. Some won't.
>
>
> One downside of LDAP: much like DNS and IP routing, if LDAP gets hosed,
> everything gets hosed. Same happens with SYSUAF in a big cluster, etc.
>
> ps: no, I don't expect to see Enterprise Directory integrated into base
> OpenVMS, nor SYSUAF et al replaced with local LDAP, etc. VSI has their
> queue full with what they already have planned.
>

The SYSTEM user account, and any other "system maintenance" user 
accounts should not use LDAP for access.  That just isn't reasonable.

-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486