Discussion:
External authentication using LDAP and AD?
(too old to reply)
Jan-Erik Söderholm
2021-04-20 08:10:03 UTC
Permalink
Hi.

We have got an requirement against our VMS systems to join the
corporate handling of user accounts. One part in this is to start
doing login authentications using the central AD.

Now, I have still some things to read up on, but my understanding is
that this should be possible by installing one LDAP kit to get the
basic LDAP functionality, and then a patch that modifies LOGINOUT.EXE
(I think it was) so that you can set a flag in the UAF to enable
“external authentication”.

Am I on the right track here?

I have found this in the VSI documentation pages:
https://vmssoftware.com/docs/openldap-release-notes.pdf

And there is a patch called: VMS842L2A_LDAP-V0400. Are this one and
the OpenLDAP above more or less the same thing? It does look as that
the LDAP patch has the LDAP client and OpenLDAP is a LDAP server (?).

Then I think I have seen some “external authentication” patch before.
Wasn’t there something you needed to actually be able to set a flag in
UAF to enable an account for external LDAP authentication?

Does someone know a link to some documentation/overview of all this?

Best Regards,
Jan-Erik.
Phillip Helbig (undress to reply)
2021-04-20 08:42:53 UTC
Permalink
Post by Jan-Erik Söderholm
We have got an requirement against our VMS systems to join the
corporate handling of user accounts. One part in this is to start
doing login authentications using the central AD.
Been there, done that.
Post by Jan-Erik Söderholm
Now, I have still some things to read up on, but my understanding is
that this should be possible by installing one LDAP kit to get the
basic LDAP functionality, and then a patch that modifies LOGINOUT.EXE
(I think it was) so that you can set a flag in the UAF to enable
`external authentication'.
Am I on the right track here?
I don't recall having to install a patch, i.e. the functionality was
already there and I just had to enable it.

Note that you can also set things up so that, for the accounts you
choose, it is possible to bypass the LDAP if it is not working.
Jan-Erik Söderholm
2021-04-20 12:03:04 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Jan-Erik Söderholm
We have got an requirement against our VMS systems to join the
corporate handling of user accounts. One part in this is to start
doing login authentications using the central AD.
Been there, done that.
Post by Jan-Erik Söderholm
Now, I have still some things to read up on, but my understanding is
that this should be possible by installing one LDAP kit to get the
basic LDAP functionality, and then a patch that modifies LOGINOUT.EXE
(I think it was) so that you can set a flag in the UAF to enable
`external authentication'.
Am I on the right track here?
I don't recall having to install a patch, i.e. the functionality was
already there and I just had to enable it.
OK. And "enabling it", is that "$ uaf mod user /flag=extauth" ?

That can not be all. I mean, you have to setup the server details
for the AD server to run LDAP against, right?

I guess I must find the relevant docs for this...
Post by Phillip Helbig (undress to reply)
Note that you can also set things up so that, for the accounts you
choose, it is possible to bypass the LDAP if it is not working.
Stephen Hoffman
2021-04-20 14:27:18 UTC
Permalink
Post by Jan-Erik Söderholm
https://vmssoftware.com/docs/openldap-release-notes.pdf
That's the OpenLDAP server info, not external authentication.
Post by Jan-Erik Söderholm
Does someone know a link to some documentation/overview of all this?
Contact VSI Support.

VSI removed the separate LOGINOUT patch rubbish a while back, seemingly
incorporating both LOGINOUTs into the kit (!?), though the only
documentation for configuring the feature for your particular Active
Directory or OpenDirectory or other authentication server was included
within the LOGINOUT (LDAP) patch kit and not in the OpenVMS docs.

It looks like some of the related documentation was then rolled into
section 7.4 in the security manual:

https://vmssoftware.com/docs/VSI_System_Security_Manual.pdf

The LDAP configuration steps are less than obvious, and are not
documented in the security manual AFAICT.

The documentation for using this feature was weak, and I found the
error-reporting and customization support lacking, particularly if the
setup configuration wasn't a completely stock Active Directory setup—if
your setup wasn't quite right for your particular LDAP authentication
server. I did get this working with OpenLDAP a while back, though.

If you still happen to have the old LDAP patch kit for OpenVMS from
your HPE era support, extract the patch notes from that and read.

But since you have VSI support, use it.
--
Pure Personal Opinion | HoffmanLabs LLC
Jan-Erik Söderholm
2021-04-20 15:36:20 UTC
Permalink
Post by Stephen Hoffman
Post by Jan-Erik Söderholm
https://vmssoftware.com/docs/openldap-release-notes.pdf
That's the OpenLDAP server info, not external authentication.
Post by Jan-Erik Söderholm
Does someone know a link to some documentation/overview of all this?
Contact VSI Support.
VSI removed the separate LOGINOUT patch rubbish a while back, seemingly
incorporating both LOGINOUTs into the kit (!?), though the only
documentation for configuring the feature for your particular Active
Directory or OpenDirectory or other authentication server was included
within the LOGINOUT (LDAP) patch kit and not in the OpenVMS docs.
It looks like some of the related documentation was then rolled into
https://vmssoftware.com/docs/VSI_System_Security_Manual.pdf
The LDAP configuration steps are less than obvious, and are not documented
in the security manual AFAICT.
The documentation for using this feature was weak, and I found the
error-reporting and customization support lacking, particularly if the
setup configuration wasn't a completely stock Active Directory setup—if
your setup wasn't quite right for your particular LDAP authentication
server. I did get this working with OpenLDAP a while back, though.
If you still happen to have the old LDAP patch kit for OpenVMS from your
HPE era support, extract the patch notes from that and read.
But since you have VSI support, use it.
Thanks, good tips. I'll open a support case also. I also have a
conference planned with a guy from the Swedish VSI office scheduled
Thursday. Not about LDAP but more about the VMS "situation" in general
and specifically in regard to my current customer.
Grant Taylor
2021-04-20 15:43:11 UTC
Permalink
Hi,

Drive by comment from having done similar on Unix / Linux.
Post by Stephen Hoffman
completely stock Active Directory setup
Not all Active Directory installations are created equally. Depending
on the AD Domain / Forest function level you may need considerably
different security requirements.

These requirements can manifest themselves as anyone / anything can bind
to the LDAP server, binding may require authentication, binding may
require encryption, binding may use a generic user, binding may be used
to test the credentials at hand, etc.

Then the different levels of encryption and / or the port (LDAPS vs
LDAP+STARTTLS?) may bite you.

Another thing to keep in mind is that you probably don't want just
anyone that can successfully authenticate against LDAP to be able to log
into the OpenVMS systems. You will probably want some additional level
of control, like requiring people to be a member of a specific group for
OpenVMS in general and / or the specific system in question.

And as Phillip mentioned, I *HIGHLY* recommend that you plan on and test
how you are going to log in when centralized LDAP isn't working.

The overall AD LDAP schema is probably fairly well standardized up to a
point. Though each AD installation will likely put different users and
systems into different Os / OUs and you'll probably need to account for
that in your LDAP queries.

Not all AD / LDAP installations are created equally.
--
Grant. . . .
unix || die
Stephen Hoffman
2021-04-20 15:58:00 UTC
Permalink
Post by Grant Taylor
Drive by comment from having done similar on Unix / Linux.
Yeah, I got OpenVMS authenticating with macOS Server running the
OpenDirectory LDAP server, and specifically with the versions of macOS
Server prior to its transition into an MDM package.

Had a few days' tussles getting that connection working, too.
Post by Grant Taylor
Not all AD / LDAP installations are created equally.
More than a few Active Directory installations are unfortunately
squatting in .local, too.

The external authentication connector provided with OpenVMS is
minimally functional, minimally documented, and with minimal logging
and diagnostics support, but I'm in a polite mood today.
--
Pure Personal Opinion | HoffmanLabs LLC
Grant Taylor
2021-04-20 17:13:39 UTC
Permalink
Post by Stephen Hoffman
More than a few Active Directory installations are unfortunately
squatting in .local, too.
Ya.... I suspect that Microsoft would like to retract their
recommendation to use the .local TLD (from the Windows Server 2003 days).
Post by Stephen Hoffman
The external authentication connector provided with OpenVMS is minimally
functional, minimally documented, and with minimal logging and
diagnostics support, but I'm in a polite mood today.
I would normally suggest Wireshark to debug what's going across the wire
to make sure that things are working as expected / desired. But LDAP.
Ew. ~> Ouch. *

Also, PFS with newer TLS means that Wireshark (et al.) are non-starters
without one end or the other logging ephemeral keys.

Aside: I am sort of curious how well OpenVMS would play with
contemporary TLS encryption; TLSv1.2 or TLSv1.3, on LDAPS / TCP port 636.

*Read: I haven't yet sufficiently wrapped my brain around LDAP and
attempts to do so have been painful and incomplete. So trying to
reverse engineer it on the wire sounds ... painful.
--
Grant. . . .
unix || die
Arne Vajhøj
2021-04-20 17:31:23 UTC
Permalink
(no quote as this is not related to any particular post)

I am thinking like this: getting VMS authentication using
LDAP (AD or otherwise) seems to be as much fun as dental surgery -
would it be better to try and change the problem?

Instead of users authenticating against VMS authenticating against
LDAP server then having users authentication against the application
authenticating against LDAP server.

This is a non-starter if users are having DCL access. But that
is not so common anymore.

If people are presented with some sort of UI (does not matter
if it is VT SMG$ or web browser or something else) then ask
for their AD username+password, authenticate and manage
them based on that.

That changes the problem from integrating VMS with LDAP
server using the apparently thin documentation to
finding an LDAP client library and change application
to use that.

May - just maybe - that would be a better way forward.

Arne
Stephen Hoffman
2021-04-20 18:23:20 UTC
Permalink
Post by Arne Vajhøj
May - just maybe - that would be a better way forward.
Hard no.

Popping up (more) password prompts is not my preferred approach, and
for various reasons.

I would prefer the existing external authentication prototype polished,
productized, and better integrated.

And that hypothetical password-prompting connection will still have to
authenticate with the local store and to skulk the password changes and
all the rest.
--
Pure Personal Opinion | HoffmanLabs LLC
Jan-Erik Söderholm
2021-04-20 20:58:51 UTC
Permalink
Post by Stephen Hoffman
Post by Arne Vajhøj
May - just maybe - that would be a better way forward.
Hard no.
Popping up (more) password prompts is not my preferred approach, and for
various reasons.
I would prefer the existing external authentication prototype polished,
productized, and better integrated.
And that hypothetical password-prompting connection will still have to
authenticate with the local store and to skulk the password changes and all
the rest.
I do not expect any *additional* login prompts, just the usual
"Username:" and "Password:". There should be no change for the user
besides using their "normal" corporate password used for everything
else instead of a local VMS password.

The only feature we want is to have the password entered verified
against AD instead of the local UAF. And if the AD authentication
doesn't work, that might be becuse the user has left the company.
We have issues today with users using accounts from retired workmates.

But thanks for all posts. I have sent a mail to VSI support also...

Jan-Erik.
k***@gmail.com
2021-04-28 00:31:10 UTC
Permalink
-----Original Message-----
Söderholm via Info-vax
Sent: April-20-21 5:59 PM
Subject: Re: [Info-vax] External authentication using LDAP and AD?
Post by Stephen Hoffman
Post by Arne Vajhøj
May - just maybe - that would be a better way forward.
Hard no.
Popping up (more) password prompts is not my preferred approach, and
for various reasons.
I would prefer the existing external authentication prototype
polished, productized, and better integrated.
And that hypothetical password-prompting connection will still have to
authenticate with the local store and to skulk the password changes
and all the rest.
I do not expect any *additional* login prompts, just the usual "Username:"
and "Password:". There should be no change for the user besides using their
"normal" corporate password used for everything else instead of a local VMS
password.
The only feature we want is to have the password entered verified against
AD
instead of the local UAF. And if the AD authentication doesn't work, that
might be becuse the user has left the company.
We have issues today with users using accounts from retired workmates.
But thanks for all posts. I have sent a mail to VSI support also...
Jan-Erik.
Sounds like what you are looking for is similar functionality to a Windows
domain account (AD) vs. a Windows Local Account (UAF)

Apologies if this was already raised in a previous reply, but another
consideration might be Process's VAM product.

<https://www.process.com/products/vam/vam_spd.html>

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

VAM provides a client for LDAPv3 servers on various platforms. Examples of
supported servers are Microsoft Active Directory and OpenLDAP from the
OpenLDAP Foundation."


Regards,

Kerry Main
Kerry dot main at starkgaming dot com
--
This email has been checked for viruses by AVG.
https://www.avg.com
Jan-Erik Söderholm
2021-04-28 08:33:15 UTC
Permalink
Post by k***@gmail.com
-----Original Message-----
Söderholm via Info-vax
Sent: April-20-21 5:59 PM
Subject: Re: [Info-vax] External authentication using LDAP and AD?
Post by Stephen Hoffman
Post by Arne Vajhøj
May - just maybe - that would be a better way forward.
Hard no.
Popping up (more) password prompts is not my preferred approach, and
for various reasons.
I would prefer the existing external authentication prototype
polished, productized, and better integrated.
And that hypothetical password-prompting connection will still have to
authenticate with the local store and to skulk the password changes
and all the rest.
I do not expect any *additional* login prompts, just the usual "Username:"
and "Password:". There should be no change for the user besides using their
"normal" corporate password used for everything else instead of a local VMS
password.
The only feature we want is to have the password entered verified against
AD
instead of the local UAF. And if the AD authentication doesn't work, that
might be becuse the user has left the company.
We have issues today with users using accounts from retired workmates.
But thanks for all posts. I have sent a mail to VSI support also...
Jan-Erik.
Sounds like what you are looking for is similar functionality to a Windows
domain account (AD) vs. a Windows Local Account (UAF)
Apologies if this was already raised in a previous reply, but another
consideration might be Process's VAM product.
<https://www.process.com/products/vam/vam_spd.html>
"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
- 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.
VAM provides a client for LDAPv3 servers on various platforms. Examples of
supported servers are Microsoft Active Directory and OpenLDAP from the
OpenLDAP Foundation."
Regards,
Kerry Main
Kerry dot main at starkgaming dot com
As I think I said, I got a nice document fro VSI support around ACME/LDAP.
And yes, there is mapping between the AD username and the local VMS
username, so we can keep the local workplace based usernames in VMS and
just create users in AD according to the corporate standard for the login.
Arne Vajhøj
2021-04-20 23:07:42 UTC
Permalink
Post by Stephen Hoffman
Post by Arne Vajhøj
May - just maybe - that would be a better way forward.
Hard no.
Popping up (more) password prompts is not my preferred approach, and for
various reasons.
I would prefer the existing external authentication prototype polished,
productized, and better integrated.
And that hypothetical password-prompting connection will still have to
authenticate with the local store and to skulk the password changes and
all the rest.
Fun little exercise: try note all the username/password logins you
do during a normal day and put them in two buckets: going through
OS login authentication and other.

For most I think the second bucket would outnumber the first
like 10:1.

There is no reason why VMS should be different than other systems.

Of course if the specific requirement is to be able to
login to VMS (interactive process with DCL), then the OS
login is necessary. And the LDAP integration need to
be figured out.

Arne
Stephen Hoffman
2021-04-21 00:18:58 UTC
Permalink
Fun little exercise: try note all the username/password logins you do
during a normal day and put them in two buckets: going through OS login
authentication and other.
I go through the operating system for all of the logins including web
logins, across *lots* of passwords.

Of the handful I don't, most are OpenVMS systems.

And my answer here remains hard no.
--
Pure Personal Opinion | HoffmanLabs LLC
Jan-Erik Söderholm
2021-04-21 06:58:20 UTC
Permalink
Post by Arne Vajhøj
Post by Stephen Hoffman
Post by Arne Vajhøj
May - just maybe - that would be a better way forward.
Hard no.
Popping up (more) password prompts is not my preferred approach, and for
various reasons.
I would prefer the existing external authentication prototype polished,
productized, and better integrated.
And that hypothetical password-prompting connection will still have to
authenticate with the local store and to skulk the password changes and
all the rest.
Fun little exercise: try note all the username/password logins you
do during a normal day and put them in two buckets: going through
OS login authentication and other.
For most I think the second bucket would outnumber the first
like 10:1.
There is no reason why VMS should be different than other systems.
Of course if the specific requirement is to be able to
login to VMS (interactive process with DCL), then the OS
login is necessary. And the LDAP integration need to
be figured out.
Arne
Well, these are "OS logins" (at the Username: and Password: prompts)
even if these users never sees a DCL prompt. They are captive and
would be logged out automaticaly if they get the DCL level. I do
not understand why you make that connection.

And what is the relevance of any *other* logins than these?
Shael Richmond
2021-04-21 14:58:24 UTC
Permalink
On Wednesday, April 21, 2021 at 1:58:23 AM UTC-5, Jan-Erik Söderholm wrote:
In addition to the change in authorize you need to do:

Install ACME/LDAP images
@SYS$MANAGER:SYS$LOGIN_SWITCH.COM (Switch to ACME from UAF)
MC SYSMAN
SYS_LOADABLE ADD LDAPACME LDAPACME$EXT
EXIT
@SYS$UPDATE:VMS$SYSTEM_IMAGES

The base software is included in the later versions although you will want the latest patches.

Shael Richmond
International Paper
Jan-Erik Söderholm
2021-04-21 15:58:45 UTC
Permalink
Post by Shael Richmond
Install ACME/LDAP images
@SYS$MANAGER:SYS$LOGIN_SWITCH.COM (Switch to ACME from UAF)
MC SYSMAN
SYS_LOADABLE ADD LDAPACME LDAPACME$EXT
EXIT
@SYS$UPDATE:VMS$SYSTEM_IMAGES
The base software is included in the later versions although you will want the latest patches.
Shael Richmond
International Paper
Right, all that is quite clearly described in the not-yet-released
documentation I got directly from VSI support. It is also based on
the new OpenLDAP client based solution. There was also an old
solution. So the above is now:

SYS_LOADABLE ADD LDAPACME LDAPACME2$EXT

Note the "2" in that command. This LDAPACME V2.0 also requires:

VSI OpenLDAP 2.4.53 or later.
VSI OpenSSL111 1.1-1g or later.

Good documentation. Hope it gets published soon...

Jan-Erik.
Arne Vajhøj
2021-04-21 16:04:13 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Arne Vajhøj
Post by Stephen Hoffman
Post by Arne Vajhøj
May - just maybe - that would be a better way forward.
Hard no.
Popping up (more) password prompts is not my preferred approach, and
for various reasons.
I would prefer the existing external authentication prototype
polished, productized, and better integrated.
And that hypothetical password-prompting connection will still have
to authenticate with the local store and to skulk the password
changes and all the rest.
Fun little exercise: try note all the username/password logins you
do during a normal day and put them in two buckets: going through
OS login authentication and other.
For most I think the second bucket would outnumber the first
like 10:1.
There is no reason why VMS should be different than other systems.
Of course if the specific requirement is to be able to
login to VMS (interactive process with DCL), then the OS
login is necessary. And the LDAP integration need to
be figured out.
Well, these are "OS logins" (at the Username: and Password: prompts)
even if these users never sees a DCL prompt. They are captive and
would be logged out automaticaly if they get the DCL level.
If the captive script is doing actual work, then OS access
is needed.

If the captive script just start the application, then moving the
authentication to the application could still be an option.
Post by Jan-Erik Söderholm
I do
not understand why you make that connection.
And what is the relevance of any *other* logins than these?
I just wanted to bring up the possibility of a different approach.

Arne
Jan-Erik Söderholm
2021-04-21 21:45:14 UTC
Permalink
Post by Arne Vajhøj
Post by Jan-Erik Söderholm
Post by Arne Vajhøj
Post by Stephen Hoffman
Post by Arne Vajhøj
May - just maybe - that would be a better way forward.
Hard no.
Popping up (more) password prompts is not my preferred approach, and
for various reasons.
I would prefer the existing external authentication prototype polished,
productized, and better integrated.
And that hypothetical password-prompting connection will still have to
authenticate with the local store and to skulk the password changes and
all the rest.
Fun little exercise: try note all the username/password logins you
do during a normal day and put them in two buckets: going through
OS login authentication and other.
For most I think the second bucket would outnumber the first
like 10:1.
There is no reason why VMS should be different than other systems.
Of course if the specific requirement is to be able to
login to VMS (interactive process with DCL), then the OS
login is necessary. And the LDAP integration need to
be figured out.
Well, these are "OS logins" (at the Username: and Password: prompts)
even if these users never sees a DCL prompt. They are captive and
would be logged out automaticaly if they get the DCL level.
If the captive script is doing actual work, then OS access
is needed.
Define "work". :-)

The login gets the user to a menu system where a large number of
(VT-screen) applications can be started. Or just about anything
such as COM files can be called.
Post by Arne Vajhøj
If the captive script just start the application, then moving the
authentication to the application could still be an option.
Post by Jan-Erik Söderholm
                                                           I do
not understand why you make that connection.
And what is the relevance of any *other* logins than these?
I just wanted to bring up the possibility of a different approach.
Arne
Arne Vajhøj
2021-04-21 23:37:42 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Arne Vajhøj
Post by Jan-Erik Söderholm
Post by Arne Vajhøj
Of course if the specific requirement is to be able to
login to VMS (interactive process with DCL), then the OS
login is necessary. And the LDAP integration need to
be figured out.
Well, these are "OS logins" (at the Username: and Password: prompts)
even if these users never sees a DCL prompt. They are captive and
would be logged out automaticaly if they get the DCL level.
If the captive script is doing actual work, then OS access
is needed.
Define "work". :-)
More than the one liner:

$ run big_application_that_can_handle_everything

:-)
Post by Jan-Erik Söderholm
The login gets the user to a menu system where a large number of
(VT-screen) applications can be started. Or just about anything
such as COM files can be called.
Sounds like you need OS authentication.

But if I understood another post correct, then you got some
good documentation from VSI, so no problem.

Arne
Richard Maher
2021-04-22 02:42:57 UTC
Permalink
Post by Stephen Hoffman
Post by Arne Vajhøj
May - just maybe - that would be a better way forward.
Hard no.
Popping up (more) password prompts is not my preferred approach,
and for various reasons.
I would prefer the existing external authentication prototype
polished, productized, and better integrated.
I really like the FIDO2/WebAuthn/WIndows Hello challenges. If they
allowed your phone to be used instead of a dongle that would be even
better
https://stackoverflow.com/questions/66624283/can-i-use-phone-as-webauthn-security-key-with-windows-10-sign-in-options

(Yes, you can use your phone when the web app is running on the phone
but you can't use your phone finger print when your on your PC even if
your phone is blue-toothed mated to it.)

With OAuth2 pretty much dead 'cos of no Apple support as well as
tracking fears FIDO2 *is* the answer!

Even if VMS won't have a platform authenticator it should still ve able
to validate the tokens and match the clients.
Post by Stephen Hoffman
And that hypothetical password-prompting connection will still have
to authenticate with the local store and to skulk the password
changes and all the rest.
Fun little exercise: try note all the username/password logins you do
during a normal day and put them in two buckets: going through OS
login authentication and other.
For most I think the second bucket would outnumber the first like
10:1.
There is no reason why VMS should be different than other systems.
Of course if the specific requirement is to be able to login to VMS
(interactive process with DCL), then the OS login is necessary. And
the LDAP integration need to be figured out.
Arne
John Santos
2021-04-29 03:04:08 UTC
Permalink
In article <s5n35b$13rf$***@gioia.aioe.org>, ***@vajhoej.dk
says...
Post by Arne Vajhøj
(no quote as this is not related to any particular post)
I am thinking like this: getting VMS authentication using
LDAP (AD or otherwise) seems to be as much fun as dental surgery -
would it be better to try and change the problem?
I'm sitting here at home debugging a weird problem with my
home-brew LDAP ACME agent (because our customer's LDAP
service is strange and non-standard and the standard VMS
LDAP-STD agent can't cope with it.) It ALMOST works.
Everything works for normal logins, local terminals,
DECnet terminals, LAT, SSH (both with password and public
key authentication),etc. etc. EXCEPT processes created
with $ run/detached/authorize get blown away right in the
finish phase... The really weird thing is the user in
question is NOT an EXTAUTH user, so my agent should have
no effect. (I did just find a bug in the sys$example
program that causes a buffer overflow, but that doesn't
fix the problem

The OTHER thing I'm doing is waiting for my gum to heal
from dental surgery - I had a tooth extracted last week so
they can put in an implant.

So I should be emminantly qualified to answer all the
questions here, and will try to do so, but on the other
hand, I feel that I mostly have no idea at all what is
going on and wny things are doing what thay do.
Post by Arne Vajhøj
Instead of users authenticating against VMS authenticating against
LDAP server then having users authentication against the application
authenticating against LDAP server.
This is a non-starter if users are having DCL access. But that
is not so common anymore.
If people are presented with some sort of UI (does not matter
if it is VT SMG$ or web browser or something else) then ask
for their AD username+password, authenticate and manage
them based on that.
That changes the problem from integrating VMS with LDAP
server using the apparently thin documentation to
finding an LDAP client library and change application
to use that.
May - just maybe - that would be a better way forward.
Arne
We are gradually transition our apps from using character
cell interfaces (e.g. SMG) to GUIs. Some are web/HTML
based and most are Java. The Java GUIs run in the user's
device (Windows, Mac, Unix, Linux, whatever) and access
the VMS system via a server process using SSL (really TLS
1.2, I think) as a communications mechanism. The server
process (running on VMS) authenticates the user against
the VMS SYSUAF and performs applications control, data
access, data modifications, etc. as allow by the VMS
rights assigned to the user. For many years, the server
has been using SYS$ACM() to authenticate the users, who
ware all local. My new agent will enable LDAP
authentication instead of VMS authentication for users
marked EXTAUTH in the SYSUAF. This all falls out, we
don't even have to recompile anything!

The remaining character cell interfaces will also use the
same LDAP agent, no matter how the user connects to VMS.

I hope this helps see what is possible.
--
John
Stephen Hoffman
2021-04-29 15:57:40 UTC
Permalink
...processes created with $ run/detached/authorize get blown away right
in the finish phase...
Aim the RUN/DETACH output somewhere, if you're not already doing that.
Pass in a WSA device as the error device having aimed that WSA device
at a local DECwindows session.
Or aim the process input and output at an unallocated terminal, or at a
custom-created DECterm terminal.
See if the output there provides any clues.
--
Pure Personal Opinion | HoffmanLabs LLC
Stephen Hoffman
2021-04-20 18:18:14 UTC
Permalink
Post by Grant Taylor
I would normally suggest Wireshark to debug what's going across the
wire to make sure that things are working as expected / desired. But
LDAP. Ew. ~> Ouch. *
With cooperating clients and servers, troubleshooting TLS connections
including viewing the connection cleartext contents is straightforward.

HPE went so far as to ship one way to perform that troubleshooting
enabled by default within OpenVMS, too. Whoops. That got fixed.

That's not where configuring the external authentication connection
gets "interesting", either.
--
Pure Personal Opinion | HoffmanLabs LLC
Dave Froble
2021-04-20 16:50:55 UTC
Permalink
Post by Jan-Erik Söderholm
Hi.
We have got an requirement against our VMS systems to join the
corporate handling of user accounts. One part in this is to start
doing login authentications using the central AD.
Now, I have still some things to read up on, but my understanding is
that this should be possible by installing one LDAP kit to get the
basic LDAP functionality, and then a patch that modifies LOGINOUT.EXE
(I think it was) so that you can set a flag in the UAF to enable
“external authentication”.
Am I on the right track here?
https://vmssoftware.com/docs/openldap-release-notes.pdf
And there is a patch called: VMS842L2A_LDAP-V0400. Are this one and
the OpenLDAP above more or less the same thing? It does look as that
the LDAP patch has the LDAP client and OpenLDAP is a LDAP server (?).
Then I think I have seen some “external authentication” patch before.
Wasn’t there something you needed to actually be able to set a flag in
UAF to enable an account for external LDAP authentication?
Does someone know a link to some documentation/overview of all this?
Best Regards,
Jan-Erik.
I've never used it, so I don't have specific knowledge. However, I
think Networking Dynamics just might have some of what you're looking
for. Extra cost, but, an inquiry should at least let you know what's
available.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Hunter Goatley
2021-04-21 03:13:23 UTC
Permalink
Post by Jan-Erik Söderholm
We have got an requirement against our VMS systems to join the
corporate handling of user accounts. One part in this is to start
doing login authentications using the central AD.
That's what our VAM (VMS Authentication Module) product does:

https://www.process.com/products/vam/

You can request a free trial from the webpage.
--
Hunter
------
Hunter Goatley, Process Software, http://www.process.com/
***@goatley.com http://hunter.goatley.com/
Hunter Goatley
2021-05-10 18:49:56 UTC
Permalink
I was reminded today that SSH in MultiNet and TCPware can authenticate
against a Radius server without requiring the use of VAM.
--
Hunter
------
Hunter Goatley, Process Software, http://www.process.com/
***@goatley.com http://hunter.goatley.com/
Loading...