[Info-vax] LDAP

[Stephen Hoffman]

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.

> 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.

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.

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

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

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.

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.

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.

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.

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.

-- 
Pure Personal Opinion | HoffmanLabs LLC