Discussion:
LDAP
Add Reply
Jan-Erik Söderholm
2020-10-07 23:14:17 UTC
Reply
Permalink
Hi.

I have been asked if we can use LDAP against the corporate AD systems
to authenticate our user logins to our OpenVMS system.

Currently on VSI/Alpha.

Anyone that have looked and/or tested these LDAP parts on Alpha?
And if so, any thoughts, findings or something else worth to report?
How does it work with a mixed LDAP/local password verification?

The users to be verified over LDAP/AD are those that have “personal”
VMS accounts using their corporate signature. We also have “workgroup”
accounts for the workplaces in the factory, and they are not in the AD.

The logins are done using plain telnet sessions from terminal emulators.
No ssh here, if that matters in regard to LDAP…

Just starting to look at this…

Regards, Jan-Erik.
Arne Vajhøj
2020-10-07 23:44:44 UTC
Reply
Permalink
Post by Jan-Erik Söderholm
I have been asked if we can use LDAP against the corporate AD systems
to authenticate our user logins to our OpenVMS system.
Currently on VSI/Alpha.
Anyone that have looked and/or tested these LDAP parts on Alpha?
And if so, any thoughts, findings or something else worth to report?
How does it work with a mixed LDAP/local password verification?
The users to be verified over LDAP/AD are those that have “personal”
VMS accounts using their corporate signature. We also have “workgroup”
accounts for the workplaces in the factory, and they are not in the AD.
The logins are done using plain telnet sessions from terminal emulators.
No ssh here, if that matters in regard to LDAP…
Just starting to look at this…
I have never tried it.

But:

OpenVMS Guide to System Security
Managing System Access
Enabling External Authentication

sounds "relevant".

Arne
Kerry Main
2020-10-08 00:20:35 UTC
Reply
Permalink
-----Original Message-----
Söderholm via Info-vax
Sent: October 7, 2020 8:14 PM
Subject: [Info-vax] LDAP
Hi.
I have been asked if we can use LDAP against the corporate AD systems to
authenticate our user logins to our OpenVMS system.
Currently on VSI/Alpha.
Anyone that have looked and/or tested these LDAP parts on Alpha?
And if so, any thoughts, findings or something else worth to report?
How does it work with a mixed LDAP/local password verification?
The users to be verified over LDAP/AD are those that have “personal”
VMS accounts using their corporate signature. We also have “workgroup”
accounts for the workplaces in the factory, and they are not in the AD.
The logins are done using plain telnet sessions from terminal emulators.
No ssh here, if that matters in regard to LDAP…
Just starting to look at this…
Regards, Jan-Erik.
For those familiar with Windows environments, think of global AD (aka LDAP)
and local Windows (aka sysuaf) user accounts.

Something else to consider:
<http://www.process.com/products/vam/index.html>
<http://www.process.com/products/vam/vam_spd.html>

Extract:
" The VMS Authentication Module (VAM) provides controlled access to both
user-written applications and the OpenVMS system overall using LDAP, RADIUS
or the local VMS User Authentication File (UAF). It can be incorporated into
an OpenVMS-based platform in three ways:
- Via an API that can be incorporated into an application to control access
to that application
- On a system-wide basis by using the OpenVMS ACME system on OpenVMS V8 and
higher on Alpha and Integrity platforms
- On a system-wide basis via use of the LGI callouts for OpenVMS
LOGINOUT.EXE. "

Regards,

Kerry Main
Kerry dot main at starkgaming dot com
Stephen Hoffman
2020-10-08 00:42:40 UTC
Reply
Permalink
Post by Jan-Erik Söderholm
I have been asked if we can use LDAP against the corporate AD systems
to authenticate our user logins to our OpenVMS system.
Currently on VSI/Alpha.
I was last working with this with HPE OpenVMS Alpha V8.4 with
then-current now-mid-level patches.
Post by Jan-Erik Söderholm
Anyone that have looked and/or tested these LDAP parts on Alpha?
In the configuration I was working with, OpenVMS was authenticating to
an LDAP server based on OpenLDAP / Apple Open Directory, and it it
worked.
Post by Jan-Erik Söderholm
And if so, any thoughts, findings or something else worth to report?
The documentation and diagnostics and UI are all weak, but once you get
through the configuration and setup morass, it does work.

There was some documentation buried within the HPE LDAP LOGINOUT kit
that was helpful.

You'll probably want to provision a test configuration, as most places
aren't fond of opening up LDAP for testing.

VSI (thankfully, finally) integrated the LDAP LOGINOUT support into the
base distro, so no separate kit, so I don't know what happened with
that doc.

There have been Boot Camp presentations on this topic which might be
helpful if you can find those.
Post by Jan-Erik Söderholm
How does it work with a mixed LDAP/local password verification?
The OpenVMS environment is always mixed, with passwords mirrored
between LDAP and local storage in SYSUAF.
--
Pure Personal Opinion | HoffmanLabs LLC
dthi...@gmail.com
2020-10-08 01:32:02 UTC
Reply
Permalink
"One password to rule them all."

My project set up LDAP authentication to our corporate domain on our Integrity rx2620 per corporate login consolidation requirements, but they required us to use a domain service account assigned to our Integrity server to connect to the domain controller to verify the OpenVMS user login against the domain. What killed us was the requirement to change the server's domain service account password every *30* days, despite only being used by the "trusted" non-interactive LDAP connector on the OpenVMS server, and having to be a complex password of over 28 characters long. After activating the LDAP connection, the first time that the service password expired over a weekend and all of the OpenVMS users were unable to login (after about six months of service account password changes) got the LDAP module immediately removed, since corporate would not give us a waiver on the service password expiration duration. We would have happily set a nearly-unbreakable 128-character password if they would have set the service account password expiration to a year. Not a chance. Project management rejected the corporate LDAP requirement based on the projected cost of the administrative overhead of changing the password every 30 days and of the projected lost productivity of the OpenVMS users during LDAP failure events, assuming at least one such event a year, and was granted a waiver from the corporate LDAP password requirement. Thanks to our fine corporate for making the required consolidated domain logins actually unusable for our OpenVMS users. :-)

I think (but am not sure) that this was done when we were running HPE OpenVMS 8.3-1.

If you do set up LDAP on your system, may your corporate experience be better than ours!
Dave Froble
2020-10-08 02:47:26 UTC
Reply
Permalink
Post by ***@gmail.com
"One password to rule them all."
My project set up LDAP authentication to our corporate domain on our Integrity rx2620 per corporate login consolidation requirements, but they required us to use a domain service account assigned to our Integrity server to connect to the domain controller to verify the OpenVMS user login against the domain. What killed us was the requirement to change the server's domain service account password every *30* days, despite only being used by the "trusted" non-interactive LDAP connector on the OpenVMS server, and having to be a complex password of over 28 characters long. After activating the LDAP connection, the first time that the service password expired over a weekend and all of the OpenVMS users were unable to login (after about six months of service account password changes) got the LDAP module immediately removed, since corporate would not give us a waiver on the service password expiration duration. We would have happily set a nearly-unbreakable 128-character password if they would have set the service account password expiration to a year. Not a chance. Project management rejected the corporate LDAP requirement based on the projected cost of the administrative overhead of changing the password every 30 days and of the projected lost productivity of the OpenVMS users during LDAP failure events, assuming at least one such event a year, and was granted a waiver from the corporate LDAP password requirement. Thanks to our fine corporate for making the required consolidated domain logins actually unusable for our OpenVMS users. :-)
I think (but am not sure) that this was done when we were running HPE OpenVMS 8.3-1.
If you do set up LDAP on your system, may your corporate experience be better than ours!
I'm guessing that most people can't make up such ideas. It's left to
the "consultants" to suggest things that just won't work. Of course,
ramifications are not something that ever happens to "consultants".

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin R
Marc Van Dyck
2020-10-10 11:07:53 UTC
Reply
Permalink
Post by Jan-Erik Söderholm
Hi.
I have been asked if we can use LDAP against the corporate AD systems
to authenticate our user logins to our OpenVMS system.
Currently on VSI/Alpha.
Anyone that have looked and/or tested these LDAP parts on Alpha?
And if so, any thoughts, findings or something else worth to report?
How does it work with a mixed LDAP/local password verification?
The users to be verified over LDAP/AD are those that have “personal”
VMS accounts using their corporate signature. We also have “workgroup”
accounts for the workplaces in the factory, and they are not in the AD.
The logins are done using plain telnet sessions from terminal emulators.
No ssh here, if that matters in regard to LDAP…
Just starting to look at this…
Regards, Jan-Erik.
We tried it, it works, but it can only be used to store passwords. LDAP
does not have any provision to store the SYSUAF info so you need to
keep
local user definitions anyway. It just will disregard the password
stored in SYSUAF in favor of the LDAP one. Means that for system admin
people, it's twice the work... We decided it was not worth the effort
and we dropped it. The only real advantage that I can see is that the
LDAP password hashing algorithm is probably better than the one used in
SYSUAF so the systems would be marginally safer, which might be
important for some cases.
--
Marc Van Dyck
Jan-Erik Söderholm
2020-10-10 11:57:53 UTC
Reply
Permalink
Post by Marc Van Dyck
Post by Jan-Erik Söderholm
Hi.
I have been asked if we can use LDAP against the corporate AD systems
to authenticate our user logins to our OpenVMS system.
Currently on VSI/Alpha.
Anyone that have looked and/or tested these LDAP parts on Alpha?
And if so, any thoughts, findings or something else worth to report?
How does it work with a mixed LDAP/local password verification?
The users to be verified over LDAP/AD are those that have “personal”
VMS accounts using their corporate signature. We also have “workgroup”
accounts for the workplaces in the factory, and they are not in the AD.
The logins are done using plain telnet sessions from terminal emulators.
No ssh here, if that matters in regard to LDAP…
Just starting to look at this…
Regards, Jan-Erik.
We tried it, it works, but it can only be used to store passwords. LDAP
does not have any provision to store the SYSUAF info so you need to keep
local user definitions anyway. It just will disregard the password
stored in SYSUAF in favor of the LDAP one. Means that for system admin
people, it's twice the work... We decided it was not worth the effort
and we dropped it. The only real advantage that I can see is that the
LDAP password hashing algorithm is probably better than the one used in
SYSUAF so the systems would be marginally safer, which might be
important for some cases.
Thanks for the reply.

Why would it be twice the work? Is there any work involved at all
efter the LDAP link to AD has been established?

The AD administration is already there anyway. Is it more routine work
on the VMS side, after that the LDAP link has been setup?

And yes, password lookup is the only function we are looking at.

What about if the AD password happens to have characters that are
invalid on VMS? Is that transparent if LDAP lookup has been enabled?

Jan-Erik.
Phillip Helbig (undress to reply)
2020-10-10 16:27:23 UTC
Reply
Permalink
Post by Jan-Erik Söderholm
Post by Marc Van Dyck
We tried it, it works, but it can only be used to store passwords. LDAP
does not have any provision to store the SYSUAF info so you need to keep
local user definitions anyway. It just will disregard the password
stored in SYSUAF in favor of the LDAP one. Means that for system admin
people, it's twice the work... We decided it was not worth the effort
and we dropped it. The only real advantage that I can see is that the
LDAP password hashing algorithm is probably better than the one used in
SYSUAF so the systems would be marginally safer, which might be
important for some cases.
Thanks for the reply.
Why would it be twice the work? Is there any work involved at all
efter the LDAP link to AD has been established?
The AD administration is already there anyway. Is it more routine work
on the VMS side, after that the LDAP link has been setup?
And yes, password lookup is the only function we are looking at.
If the LDAP is already set up and running, then the additional work is
negligible.
Post by Jan-Erik Söderholm
What about if the AD password happens to have characters that are
invalid on VMS? Is that transparent if LDAP lookup has been enabled?
Yes, completely transparent; only the LDAP rules apply.
Stephen Hoffman
2020-10-10 18:50:11 UTC
Reply
Permalink
Post by Marc Van Dyck
We tried it, it works, but it can only be used to store passwords. LDAP
does not have any provision to store the SYSUAF info so you need to
keep local user definitions anyway. It just will disregard the password
stored in SYSUAF in favor of the LDAP one. Means that for system admin
people, it's twice the work... We decided it was not worth the effort
and we dropped it. The only real advantage that I can see is that the
LDAP password hashing algorithm is probably better than the one used in
SYSUAF so the systems would be marginally safer, which might be
important for some cases.
External Authentication synchronizes passwords, as well as
password-related access settings, and ~nothing else.

LDAP can be extended and does have provisions to store SYSUAF data or
pretty much anything else account-related.

OpenVMS didn't and doesn't use that mechanism, preferring a ~shadow
passwd file. (This is where wholly-local LDAP would be nice, but... I
digress.)

The password is stored twice, once locally in SYSUAF using the
highly-performant and memory-efficient (whoops) Purdy, and once using
the LDAP hash.

OpenVMS supports the MSV1_0 NT LAN Manager hash, though the doc claims
that can be extended.

One of the biggest advantages for many sites is a single source of
information on active accounts, with one spot to shut off access
~everywhere.
--
Pure Personal Opinion | HoffmanLabs LLC
Jan-Erik Söderholm
2020-10-10 20:41:34 UTC
Reply
Permalink
Post by Marc Van Dyck
We tried it, it works, but it can only be used to store passwords. LDAP
does not have any provision to store the SYSUAF info so you need to keep
local user definitions anyway. It just will disregard the password stored
in SYSUAF in favor of the LDAP one. Means that for system admin people,
it's twice the work... We decided it was not worth the effort and we
dropped it. The only real advantage that I can see is that the LDAP
password hashing algorithm is probably better than the one used in SYSUAF
so the systems would be marginally safer, which might be important for
some cases.
External Authentication synchronizes passwords, as well as password-related
access settings, and ~nothing else.
LDAP can be extended and does have provisions to store SYSUAF data or
pretty much anything else account-related.
OpenVMS didn't and doesn't use that mechanism, preferring a ~shadow passwd
file. (This is where wholly-local LDAP would be nice, but... I digress.)
The password is stored twice, once locally in SYSUAF using the
highly-performant and memory-efficient (whoops) Purdy, and once using the
LDAP hash.
OpenVMS supports the MSV1_0 NT LAN Manager hash, though the doc claims that
can be extended.
One of the biggest advantages for many sites is a single source of
information on active accounts, with one spot to shut off access ~everywhere.
Note, the password will never be specified, entered or changed from VMS.
The password management routines are already in place on the corporate
level on AD. That we do not comply to on our VMS boxes, of course...
Craig A. Berry
2020-10-10 21:36:37 UTC
Reply
Permalink
Post by Jan-Erik Söderholm
Post by Stephen Hoffman
Post by Marc Van Dyck
We tried it, it works, but it can only be used to store passwords.
LDAP does not have any provision to store the SYSUAF info so you need
to keep local user definitions anyway. It just will disregard the
password stored in SYSUAF in favor of the LDAP one. Means that for
system admin people, it's twice the work... We decided it was not
worth the effort and we dropped it. The only real advantage that I
can see is that the LDAP password hashing algorithm is probably
better than the one used in SYSUAF so the systems would be marginally
safer, which might be important for some cases.
External Authentication synchronizes passwords, as well as
password-related access settings, and ~nothing else.
LDAP can be extended and does have provisions to store SYSUAF data or
pretty much anything else account-related.
OpenVMS didn't and doesn't use that mechanism, preferring a ~shadow
passwd file. (This is where wholly-local LDAP would be nice, but... I
digress.)
The password is stored twice, once locally in SYSUAF using the
highly-performant and memory-efficient (whoops) Purdy, and once using
the LDAP hash.
OpenVMS supports the MSV1_0 NT LAN Manager hash, though the doc claims
that can be extended.
One of the biggest advantages for many sites is a single source of
information on active accounts, with one spot to shut off access ~everywhere.
Note, the password will never be specified, entered or changed from VMS.
Unless you set it up so it is. If you specify VMSAUTH as well as
EXTAUTH in the SYSUAF flags, then the VMS password that gets synched
with the external password whenever the user logs in can be specified by
entering /LOCAL after the username and then no external authentication
takes place. This is either awfully convenient when Active Directory is
down or a security hole when a compromised Windows password has been
changed but the VMS system has not been synched yet. Synching can be
disabled with DISPWDSYNCH.

Also, it is possible to change your external password from VMS. I
believe there was some problem doing this with Active Directory that
eventually got fixed.

Another feature that I think no one has mentioned is that you can
control who gets to log in to the VMS system by setting up your LDAP
search to only get results for a specified AD group.
Grant Taylor
2020-10-10 22:19:32 UTC
Reply
Permalink
Post by Craig A. Berry
Another feature that I think no one has mentioned is that you can
control who gets to log in to the VMS system by setting up your LDAP
search to only get results for a specified AD group.
I ran into that when configuring Active Directory Integration for Unix /
Linux at my last job.

Local accounts are inherently local. If you don't have a local account,
you can't do anything.

Directory accounts (AD / NDS / eD / LDAP / NIS(+)) are inherently much
larger scope than local accounts. It's expected that people will have a
directory account that should not be logging in to any given system.

As such, you become dependent on a new piece of information being
required to scope who can and can not log into a given system.
Explaining this during the ADI4U project ended up taking a LOT of
meeting time.

Q: But why do I need a new group to say who can and can not log into
this system using this new Directory thingy? I didn't need it using the
old method.

Me: <facepalm>
--
Grant. . . .
unix || die
Craig A. Berry
2020-10-10 22:41:32 UTC
Reply
Permalink
Post by Grant Taylor
Post by Craig A. Berry
Another feature that I think no one has mentioned is that you can
control who gets to log in to the VMS system by setting up your LDAP
search to only get results for a specified AD group.
I ran into that when configuring Active Directory Integration for Unix /
Linux at my last job.
Local accounts are inherently local.  If you don't have a local account,
you can't do anything.
Directory accounts (AD / NDS / eD / LDAP / NIS(+)) are inherently much
larger scope than local accounts.  It's expected that people will have a
directory account that should not be logging in to any given system.
As such, you become dependent on a new piece of information being
required to scope who can and can not log into a given system.
Explaining this during the ADI4U project ended up taking a LOT of
meeting time.
Q:  But why do I need a new group to say who can and can not log into
this system using this new Directory thingy?  I didn't need it using the
old method.
Because the first line support folks can readily add and remove people
from AD groups since they do it all the time for other apps and other
systems. Typing arcane commands that update SYSUAF not so much.
Hopefully this new WebUI thingy from VSI will help with that, but it's
still something different that can't be centrally managed like
everything else most shops have.
Post by Grant Taylor
Me:  <facepalm>
Grant Taylor
2020-10-10 17:22:14 UTC
Reply
Permalink
LDAP does not have any provision to store the SYSUAF info
That surprises me.

LDAP is eminently extensible. You can create new methods to define and
store things all day long.

Of course that would depend on something client side being willing to
look for those things in LDAP.

Dip your toe into the great lake of "extending the LDAP schema". It's
something that frequently happens with major OS upgrades in Windows.
E.g. extend the AD schema to support the new features of the new version
of the server OS.
--
Grant. . . .
unix || die
Dave Froble
2020-10-11 00:11:11 UTC
Reply
Permalink
Post by Grant Taylor
LDAP does not have any provision to store the SYSUAF info
That surprises me.
LDAP is eminently extensible. You can create new methods to define and
store things all day long.
Of course that would depend on something client side being willing to
look for those things in LDAP.
Dip your toe into the great lake of "extending the LDAP schema". It's
something that frequently happens with major OS upgrades in Windows.
E.g. extend the AD schema to support the new features of the new version
of the server OS.
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.

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.

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.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Grant Taylor
2020-10-11 02:10:29 UTC
Reply
Permalink
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.
I disagree with the division that you seem to be implying.

I see no reason why the people modifying VMS specific attributes in LDAP
should not be training in VMS account administration and know exactly
how the things they change impact the systems that use said information.

I also believe that /if/ a central directory is used, then it should
contain all the information that is the same across / duplicated on
multiple systems. I don't know what all this entails, but I suspect
it's considerably more than just the password and associated ID.
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.
VMS / Solaris / Windows / JBoss specific doesn't matter to me. That's
part of the things with the extensibility of LDAP schemas. You define
the format of various pieces of information in the LDAP schema. Then
you use a subset of the pieces needed for each record.

If someone only has a Windows account, then they don't have any of the
VMS specific attributes associated with their LDAP entry.

Similarly, if someone only has a VMS account, then they don't have any
of the Windows specific attributes associated with their LDAP entry.

LDAP makes it very easy to have different attributes associated with
different entries.
Trying to have people without VMS experience setting up some of that
data seems counter-productive to me.
I wouldn't let people without VMS experience change VMS specific
attributes, much less set them up.

There is nothing that prevents a properly authorized (in the managerial
hierarchy / LDAP permission control point of view) VMS administrator
from entering / updating / deleting the LDAP data.
Usually, this data doesn't change, so have a VMS person involved in
setting up such data seems reasonable.
The thing is, why do you explicitly want to duplicate it across multiple
systems if you don't have to?

This may be a poor analogy as I know very little about VMS. But why
would you duplicate entries in SYSUAF on multiple systems in a cluster
if you had the option to have the SYSUAF on a clustered file system so
that one copy of the SYSUAF was used by all of the systems in the cluster?

That centralized storage of data is what LDAP does. It just does it in
a way that is platform agnostic.
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.
LDAP can store a LOT more information than just passwords.
--
Grant. . . .
unix || die
Dave Froble
2020-10-11 03:31:23 UTC
Reply
Permalink
Post by Grant Taylor
Post by Dave Froble
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.
I disagree with the division that you seem to be implying.
I see no reason why the people modifying VMS specific attributes in LDAP
should not be training in VMS account administration and know exactly
how the things they change impact the systems that use said information.
First, Jan-Erik wanted a solution for passwords only.

Second, Marc Van Dyck mentioned that LADP on VMs only does passwords.
Yes, you may be able to store other data in the SD, but, if VMs is not
set up to get that data from the AD, then what's the use.
Post by Grant Taylor
I also believe that /if/ a central directory is used, then it should
contain all the information that is the same across / duplicated on
multiple systems. I don't know what all this entails, but I suspect
it's considerably more than just the password and associated ID.
Post by Dave Froble
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.
VMS / Solaris / Windows / JBoss specific doesn't matter to me. That's
part of the things with the extensibility of LDAP schemas. You define
the format of various pieces of information in the LDAP schema. Then
you use a subset of the pieces needed for each record.
And on VMS, if Marc is correct, what do you then do with the data?
Post by Grant Taylor
If someone only has a Windows account, then they don't have any of the
VMS specific attributes associated with their LDAP entry.
Similarly, if someone only has a VMS account, then they don't have any
of the Windows specific attributes associated with their LDAP entry.
LDAP makes it very easy to have different attributes associated with
different entries.
Post by Dave Froble
Trying to have people without VMS experience setting up some of that
data seems counter-productive to me.
I wouldn't let people without VMS experience change VMS specific
attributes, much less set them up.
I believe that Jan-Erik asked for, and I wrote about, using a company
wide password tool. For such access, only a password is required.

I agree, only someone who knows a bit about what is required for a VMS
user account should be involved is setting up accounts.
Post by Grant Taylor
There is nothing that prevents a properly authorized (in the managerial
hierarchy / LDAP permission control point of view) VMS administrator
from entering / updating / deleting the LDAP data.
No, but if a company wants a single point of access control, and is
willing to have a non-VMS person administer it, why should a VMS person
then bother?
Post by Grant Taylor
Post by Dave Froble
Usually, this data doesn't change, so have a VMS person involved in
setting up such data seems reasonable.
The thing is, why do you explicitly want to duplicate it across multiple
systems if you don't have to?
This may be a poor analogy as I know very little about VMS. But why
would you duplicate entries in SYSUAF on multiple systems in a cluster
if you had the option to have the SYSUAF on a clustered file system so
that one copy of the SYSUAF was used by all of the systems in the cluster?
If you're discussing a VMS Cluster, then you may find that most such do
have a single SYSUAF for the entire cluster.

If you are talking non-clustered systems, perhaps different SYSUAF data
might be required on each system. I'd prefer one size fit all, but,
that may not always be possible.
Post by Grant Taylor
That centralized storage of data is what LDAP does. It just does it in
a way that is platform agnostic.
Post by Dave Froble
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.
LDAP can store a LOT more information than just passwords.
And if VMS has no method for retrieving some of that data, as reported?
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Stephen Hoffman
2020-10-11 04:56:43 UTC
Reply
Permalink
Post by Dave Froble
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.
Post by Dave Froble
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.
Post by Dave Froble
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
Dave Froble
2020-10-11 15:11:38 UTC
Reply
Permalink
Post by Stephen Hoffman
Post by Dave Froble
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.
Post by Stephen Hoffman
Post by Dave Froble
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.
Post by Stephen Hoffman
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).
Post by Stephen Hoffman
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".
Post by Stephen Hoffman
LDAP also has other advantages here, such as the ability to apply
default settings for groups of computers and groups of users.
Yes.
Post by Stephen Hoffman
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.
Post by Stephen Hoffman
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.
Post by Stephen Hoffman
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.
Post by Stephen Hoffman
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 Froble
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.
Post by Stephen Hoffman
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: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Chris Townley
2020-10-11 16:31:25 UTC
Reply
Permalink
Post by Dave Froble
The SYSTEM user account, and any other "system maintenance" user
accounts should not use LDAP for access.  That just isn't reasonable.
I agree with that for the SYSTEM account, but on my systems any other
privileged account required a secondary log in with a user account, This
was logged securely, and changed the process name to include the
'account' from the UAF - used in our case for user initials, and made
unique. The use account also needed the appropriate identifier for
access to be allowed.

Worked for me and that powers that were...

Chris
Stephen Hoffman
2020-10-11 17:42:05 UTC
Reply
Permalink
Post by Dave Froble
Post by Stephen Hoffman
Post by Dave Froble
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.
Post by Dave Froble
Post by Stephen Hoffman
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.
Post by Dave Froble
Post by Stephen Hoffman
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
Post by Dave Froble
Post by Stephen Hoffman
Post by Dave Froble
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.
Post by Dave Froble
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
Stephen Hoffman
2020-10-13 20:35:01 UTC
Reply
Permalink
...
Apropos of nothing else here, an OpenLDAP V2.4.53 kit for OpenVMS just
became available from VSI.
--
Pure Personal Opinion | HoffmanLabs LLC
Jan-Erik Söderholm
2020-10-13 21:12:35 UTC
Reply
Permalink
Post by Stephen Hoffman
...
Apropos of nothing else here, an OpenLDAP V2.4.53 kit for OpenVMS just
became available from VSI.
He, I was just reading the mail from VSI. What is not clear to me, is if
this OpenLDAP thing is new to VMS or if it has always been OpenLDAP that
was available for VMS and this is just an update to a later version.

If OpenLDAP is new to VMS, does this bring something new "to the table"?
What are the pros/cons with OpenLDAP compared with the previous solutions?
Stephen Hoffman
2020-10-13 21:55:58 UTC
Reply
Permalink
Post by Jan-Erik Söderholm
Post by Stephen Hoffman
...
Apropos of nothing else here, an OpenLDAP V2.4.53 kit for OpenVMS just
became available from VSI.
He, I was just reading the mail from VSI. What is not clear to me, is
if this OpenLDAP thing is new to VMS or if it has always been OpenLDAP
that was available for VMS and this is just an update to a later
version.
If OpenLDAP is new to VMS, does this bring something new "to the
table"? What are the pros/cons with OpenLDAP compared with the previous
solutions?
All product positioning fodder for VSI, that.

I'm unfamiliar with the origin story for the Compaq (maybe DEC?)
Enterprise Directory product.

As for the future, OpenLDAP is being actively enhanced and updated by a
team of developers. By all appearances, OpenVMS Enterprise Directory is
receiving maintenance.
--
Pure Personal Opinion | HoffmanLabs LLC
Arne Vajhøj
2020-10-13 22:55:42 UTC
Reply
Permalink
Post by Jan-Erik Söderholm
Post by Stephen Hoffman
Apropos of nothing else here, an OpenLDAP V2.4.53 kit for OpenVMS just
became available from VSI.
He, I was just reading the mail from VSI. What is not clear to me, is if
this OpenLDAP thing is new to VMS or if it has always been OpenLDAP that
was available for VMS and this is just an update to a later version.
I believe OpenLDAP 2.4.47 was released in February/March. Is this a
newer version?
Post by Jan-Erik Söderholm
If OpenLDAP is new to VMS, does this bring something new "to the table"?
What are the pros/cons with OpenLDAP compared with the previous solutions?
OpenLDAP is rather widely used and available for almost
all platforms (Linux, Windows, macOS, *BSD, AIX, HP-UX,
Solaris, z/OS - and also VMS).

Unless one is a Microsoft shop, then OpenLDAP is a
common choice.

Arne
John H. Reinhardt
2020-10-13 23:20:52 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by Jan-Erik Söderholm
Apropos of nothing else here, an OpenLDAP V2.4.53 kit for OpenVMS just became available from VSI.
He, I was just reading the mail from VSI. What is not clear to me, is if
this OpenLDAP thing is new to VMS or if it has always been OpenLDAP that
was available for VMS and this is just an update to a later version.
I believe OpenLDAP 2.4.47 was released in February/March. Is this a
newer version?
Yes. The OpenLDAP group just announced the availability of 2.4.53 on 9/7/2020.

OpenLDAP 2.4.53 (2020/09/07)
Added slapd syncrepl additional SYNC logging (ITS#9043)
Fixed slapd syncrepl segfault on NULL cookie on REFRESH (ITS#9282)
Fixed slapd syncrepl to use fresh connection on REFRESH fallback (ITS#9338)
Fixed slapo-ppolicy race condition for pwdFailureTime (ITS#9302,ITS#9334)
Build
Require OpenSSL 1.0.2 or later (ITS#9323)
Fixed libldap compilation issue with broken C compilers (ITS#9332)


Though 2.4.54 was announced yesterday, 10/12/2020.

OpenLDAP 2.4.54 Release (2020/10/12)
Fixed slapd delta-syncrepl to ignore delete ops on deleted entry (ITS#9342)
Fixed slapd delta-syncrepl to be fully serialized (ITS#9330)
Fixed slapd delta-syncrepl MOD on zero-length context entry (ITS#9352)
Fixed slapd sessionlog to use a TAVL tree (ITS#8486)
Fixed slapd syncrepl to be fully serialized (ITS#8102)
Fixed slapd syncrepl to call check_syncprov on fresh consumer (ITS#9345)
Fixed slapd syncrepl to propagate errors from overlay_entry_get_ov (ITS#9355)
Fixed slapd syncrepl to not create empty ADD ops (ITS#9359)
Fixed slapd syncrepl replace usage on single valued attrs (ITS#9295)
Fixed slapd-monitor fix monitor_back_register_database for empty suffix DB (ITS#9353)
Fixed slapo-accesslog normalizer for reqStart (ITS#9358)
Fixed slapo-accesslog to not generate new contextCSN on purge (ITS#9361)
Fixed slapo-syncprov contextCSN generation with empty suffix (ITS#9015)


Only one month behind, that's pretty quick turnaround for VSI. Perhaps they are working with OpenLDAP.org to keep OpenVMS in the development stream.
--
John H. Reinhardt
Arne Vajhøj
2020-10-14 00:06:54 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by Jan-Erik Söderholm
Post by Stephen Hoffman
Apropos of nothing else here, an OpenLDAP V2.4.53 kit for OpenVMS
just became available from VSI.
He, I was just reading the mail from VSI. What is not clear to me, is if
this OpenLDAP thing is new to VMS or if it has always been OpenLDAP that
was available for VMS and this is just an update to a later version.
I believe OpenLDAP 2.4.47 was released in February/March. Is this a
newer version?
Yes.  The OpenLDAP group just announced the availability of 2.4.53 on
9/7/2020.
OpenLDAP 2.4.53 (2020/09/07)
    Added slapd syncrepl additional SYNC logging (ITS#9043)
    Fixed slapd syncrepl segfault on NULL cookie on REFRESH (ITS#9282)
    Fixed slapd syncrepl to use fresh connection on REFRESH fallback
(ITS#9338)
    Fixed slapo-ppolicy race condition for pwdFailureTime
(ITS#9302,ITS#9334)
    Build
        Require OpenSSL 1.0.2 or later (ITS#9323)
        Fixed libldap compilation issue with broken C compilers (ITS#9332)
Though 2.4.54 was announced yesterday,  10/12/2020.
OpenLDAP 2.4.54 Release (2020/10/12)
    Fixed slapd delta-syncrepl to ignore delete ops on deleted entry
(ITS#9342)
    Fixed slapd delta-syncrepl to be fully serialized (ITS#9330)
    Fixed slapd delta-syncrepl MOD on zero-length context entry (ITS#9352)
    Fixed slapd sessionlog to use a TAVL tree (ITS#8486)
    Fixed slapd syncrepl to be fully serialized (ITS#8102)
    Fixed slapd syncrepl to call check_syncprov on fresh consumer
(ITS#9345)
    Fixed slapd syncrepl to propagate errors from overlay_entry_get_ov
(ITS#9355)
    Fixed slapd syncrepl to not create empty ADD ops (ITS#9359)
    Fixed slapd syncrepl replace usage on single valued attrs (ITS#9295)
    Fixed slapd-monitor fix monitor_back_register_database for empty
suffix DB (ITS#9353)
    Fixed slapo-accesslog normalizer for reqStart (ITS#9358)
    Fixed slapo-accesslog to not generate new contextCSN on purge
(ITS#9361)
    Fixed slapo-syncprov contextCSN generation with empty suffix
(ITS#9015)
Only one month behind, that's pretty quick turnaround for VSI.  Perhaps
they are working with OpenLDAP.org to keep OpenVMS in the development
stream.
OpenLDAP 2.4.47 for VMS seems to have been released by VSI in
February/March (if one can trust release notes).

The general 2.4.47 is from December 2018.

I was curious whether the VSI announcement Hoff and Jan-Erik saw
was for 2.4.47 or a newer version.

Arne
Richard Brodie
2020-10-14 07:55:51 UTC
Reply
Permalink
Post by Arne Vajhøj
I was curious whether the VSI announcement Hoff and Jan-Erik saw
was for 2.4.47 or a newer version.
As Hoff said, 2.4.53.
Jan-Erik Söderholm
2020-10-14 09:43:01 UTC
Reply
Permalink
Post by Richard Brodie
Post by Arne Vajhøj
I was curious whether the VSI announcement Hoff and Jan-Erik saw
was for 2.4.47 or a newer version.
As Hoff said, 2.4.53.
I'm not sure if the release notes are public, but in there are
all the detail, of course.

Scott Dorsey
2020-10-11 14:43:56 UTC
Reply
Permalink
Post by Marc Van Dyck
We tried it, it works, but it can only be used to store passwords. LDAP
does not have any provision to store the SYSUAF info so you need to
keep
local user definitions anyway. It just will disregard the password
stored in SYSUAF in favor of the LDAP one. Means that for system admin
people, it's twice the work... We decided it was not worth the effort
and we dropped it. The only real advantage that I can see is that the
LDAP password hashing algorithm is probably better than the one used in
SYSUAF so the systems would be marginally safer, which might be
important for some cases.
This is a feature, not a bug.

In most cases, the whole point of using LDAP is because people have an IT
organization that uses LDAP for central authentication of everything and
the IT organization insists that VMS systems be integrated into their
authentication arrangement so that they can have control over them.

This configuration allows the IT people to be happy because now they control
authentication of VMS systems, but also allows their authentication to be
readily overriden when the IT systems fail.

The argument I have been repeatedly given about central authentication is
that it is necessary to allow user accounts to be immediately closed as
soon as a user is dismissed. (The fact that this is perceived to be an
issue would indicate a more fundamental management issue to me, but we
won't go there.) This configuration allows the IT people to disable access
as users leave, while permitting sufficient local control that the loss of
the LDAP server does not totally shut down critical systems.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
Loading...