Post by Dave FrobleI 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.
Post by Dave FrobleNow, 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.
Post by Dave FrobleFor 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