[Info-vax] LDAP

[Stephen Hoffman]

On 2020-10-11 15:11:38 +0000, Dave Froble said:

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

And LDAP has that same separation.

There's abother thread going right now showing two issues related to 
app configuration: failure to check quotas at app startup, and no easy 
way to require quotas.

I've chased this same issue many years.

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

Multiple SYSUAFs becomes necessary when you're running a disparate 
cluster configuration, either disparate in time (nightly processing) or 
in configuration (mix of small and large hosts).  Maintaining that is a 
hassle.

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

Sure it is.  It's where you'd undoubted find yourself, if you were 
managing five or ten or a hundred OpenVMS hosts or more, and/or if you 
were managing app configuration details across multiple servers.

As was learned early on with the internet, using a file to copy around 
configuration data gets to be a real hassle, and DNS—for its various 
issues and warts—scales vastly better.

https://en.wikipedia.org/wiki/Domain_Name_System#History

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

Username is the identifier, the password is the authenticator.

BTW: LDAP can store digital certificates. Though not supported on 
OpenVMS with TCP/IP Services, PAMAuthenticationViaKbdInt is available 
in various other sshd servers on other platforms.

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

It is if you believe LDAP is separate, and not local. I've been working 
with systems that use LDAP locally (why even have two disparate 
systems?), and that can bind to a directory for LDAP remote (and LDAP 
is routinely replicated), which means that it all works the same, and 
that SYSTEM can be both stored in LDAP and local. And the 
authentication is then all the same calls and all the same tools, just 
which directory (local or remote) responds.

And it'd be an interesting discussion, whether an OpenVMS server outage 
or a replicated LDAP server outage or an IP routing outage or a DNS 
outage was a bigger issue.


-- 
Pure Personal Opinion | HoffmanLabs LLC