Single sign-on

[Wim Van den Wyngaert]

Hi,

I have about 140 AXP nodes with about 10 different sysuaf files. There is a system of distribution for feeding 60 stations with a copy of the sysuaf. VMS 6.2 - 7.3.

I was thinking of arming myself against management questions concerning single sign-on.

1) What software can I use to implement single sign-on and what does it cost ?
2) Who implemented it in a critical environment (e.g. multi-site cluster) and what problems did you have ?

Wim

[John Gillings · Accepted solution]

Wim,

Pathworks can do single signon into an NT domain on V7.1 and higher. It's been around for a long time. It's secure as a Windows only domain and any issues with stability are external to VMS. You'll have to ask your account manager for local pricing for Pathworks. If you don't want/need PC clients for Pathworks (ie: sharing VMS disks and printers), it might even be "free" - please check before basing decisions on that assessment!

V7.3 has support for generic authentication "ACME". There are EAKs for LDAP and hooks to support arbitrary authentication modules (Kerberos is under development, and possibly Radius). You won't see any backports, so it won't help with anything V7.2 or below.

There are also various implementations of UAF synchronization floating around with varying degrees of robustness and security. Generally speaking, I don't believe that is a good solution.

Check out the VMS Management Station - it might help. There are also lots of VMS management products from various sources that may have workable solutions. Just make sure anything that communicates passwords across a network implements some kind of encryption!

[Shael Richmond]

If all you are using Pathworks for is to provide authentication then there is no cost. We use it across 26 sites to have the VMS systems use the same username/password and their Windows domain username/password.

[John Gillings]

Wim,

I've confirmed that you can install Pathworks Server, join an NT domain and use single signon for zero cost. You will need TCPIP (licensed) and configured to start the PWIP driver.

You will need to define the system exec logical name SYS$SINGLE_SIGNON somewhere in your startup. Make sure it's not done until AFTER pathworks is running.

[Art Wiens]

John, when you say Pathworks Server...are you talking about the same product as Advanced Server, or an older version of Pathworks? It's free?!

Art

[Antoniov.]

John,
are you sure pathwork is free?
May you tell me more about pathwork and VMS sign-on?
It's possible set pathwork and vms with same user & password but AFAIK the user have to change the network password not vms password.
It's true?
I'm interesting in this feature!

Antonio Vigliotti

[Uwe Zessin]

Antonio,
it means that LOGINOUT verifies the username/password you enter against a Windows domain controller, not the SYSUAF. You can still do a login against the SYSUAF if you specify a qualifier (/LOCAL ?) after the username.

[Brad McCusker]

A few comments I hope are helpful...

John wrote:

"Pathworks can do single signon into an NT domain"

It can also do single signon into a Windows 2000 domain using LanManager security.

Art wrote:

"John, when you say Pathworks Server...are you talking about the same product as Advanced Server, or an older version of Pathworks?"

Yes, Advanced Server and PATHWORKS are essentially the same product. "Advanced Server for OpenVMS" is the follow-on product to "PATHWORKS for OpenVMS (Advanced Server)".

Art also asked:

"It's free?!"

Well, that depends on what you want to do. You can install, configure, start, and even run Advanced Server for OpenVMS with no licnese, so, it is free to do all of that. Once it is running, it can be a part of a domain, or, you can make it a PDC in its own domain, and add users and add shares and things like that. Also, External Authentication will just work.

Now, if you want to actually connect to a resource (file or printer), then, you will need a license. It is at the point of SessionSetup in the protocol that licenses are actually checked and enforced.

Antoniov asked:

"May you tell me more about pathwork and VMS sign-on?
It's possible set pathwork and vms with same user & password but AFAIK the user have to change the network password not vms password."

Yes, PATHWORKS and VMS would have the same password. But, what really happens is that VMS authentication is performed by PATHWORKS via the NT domain. There is a mechanism to keep the VMS password in synch with the domain password, but, generally speaking, it is the domain authentication that is used. See the Adminstrators guide for more information: http://h71000.www7.hp.com/doc/73final/documentation/pdf/ADSRV_ADMIN_GD.PDF

[Wim Van den Wyngaert]

All,

Is VMS able to continue without the NT nodes being operational ?

I also ment : sign on once, and work everywhere (where you are allowed). Is that also possible ?

Also nice would be that FTP, copy, etc could work without specifying username + password (I know use proxies for this but ftp doesn't handle that).

And is anyone using something in a critical environment ?

Wim@home

[Paul Nunez]

Hi,

I just wanted to clarify one point made earlier:

> You will need to define the system exec >logical name SYS$SINGLE_SIGNON somewhere in >your startup. Make sure it's not done until >AFTER pathworks is running.

The system logical name sys$single_signon is defined to 1 (enabled) by default; the sysmgr doesn't need to be concerned with the logical UNLESS external authentication is causing problems. In that case, you should set sys$single_signon to 80000001 and enable OPCOM security messages:

$ define/system/exec sys$single_signon - 80000001
$ reply/enable=security

Then repeat the failing operation to get debug messages.

The only action the system manager needs to take to enable single signon for a user is to enable the EXTAUTH flag on the user's SYSUAF account:

UAF> MOD AUSERNAME /FLAG=EXTAUTH

Also, the feature is extremely capable - it works egardless of the domain role of the Advanced Server (PDC, BDC, or Member server), regardless of what O/S the PDC (emulator) runs (PATHWORKS, Advanced Server, Windows NT/200x), and across trusts (NT-style trusts).

Good stuff :o)

Paul

[Wim Van den Wyngaert]

Also :

We now have usage of set password. What happend with that ?

We have a sysuaf that is also distributed. The base is an unused sysuaf. Can that be synchronized with pathworks too ?

Wim

[Paul Nunez]

Hi,

>We now have usage of set password. What >happend with that ?

For extauth users, $ SET PASSWORD will modify the user's _domain_ (i.e., Windows) password AND then immediately sync's the user's sysuaf password.

Not that it's a big deal, but $ SET PASSWORD is the only method of changing the password that sync's the two passwords immediately. It's not a big deal because once a user starts using extauth, it's likely they'll never attempt to access their sysuaf password again, UNLESS, (1) the extauth flag was removed from their sysuaf account or (2) some client/server app is in use in which the server end is running on the OVMS system and it accesses the SYSUAF directly, bypassing LOGINOUT.EXE.

If the user changes their domain password using the Advanced Server command $ ADMINISTER SET PASSWORD or they change it from their Windows workstation, only the domain account password is modified. When the user next utilizes external authentication to access the OVMS system, OVMS (LOGINOUT?) will sync the user's sysuaf account password at that time.

One other piece of this puzzle - if the user's domain account name and SYSUAF account name do not match, you must "map" the two together using the Advanced Server command:

$ admin add hostmap domainuname sysuafuname

>We have a sysuaf that is also distributed. >The base is an unused sysuaf. Can that be >synchronized with pathworks too ?

I don't understand enough of what you're doing to answer :<( Can you elaborate?

HTH,

Paul

[Jan van den Ende]

Wim,


Also nice would be that FTP, copy, etc could work without specifying username + password (I know use proxies for this but ftp doesn't handle that).


I am surprised!
We use IP proxies since many years!

Try
$ TCPIP help add proxy

Normally:
TCPIP ADD PROXY /host= /remote=

Of course your remotehost_name must be known, bij TCPIP$HOSTS or DNS

If you defined them on one node of the cluster, with TCPIP SHO PROX you will note a TYPE value CD, all other nodes see only C
On the other nodes
$ TCPIP SET TCPIP /SIGNAL
will synchronise them.

Success.

Cheers.

Have a Duvel on me.

jpe

[Wim Van den Wyngaert]

Jan,

Of course I use the proxies too. For rlogin for example. But, to my knowledge, FTP requires a username plus password. This causes hardcoded usernames and passwords. I know rcp can handle it but then I have to re-implement stuff that I don't own. (btw today no Duvel but Roodenberg, a very good red wine of South Africa).

Paul,

We have a lot of stations that have the same sysuaf. But sometimes they are power off and thus we have a reference sysuaf that is copied at boot time and synced after modification (or password change that is done with task-to-task).


Are there any non-HP people that have implemented pathworks and had problems ?

Wim

[Ian Miller.]

What would worry me is that the access to my VMS system was controlled by a windows system with its well known security and stability problems. I may be a bit biased :-) but Id prefer users to be authenticated against a secure system - parhaps kerberos or pki certificates in a corporate directory server on a secure platform.

(are we all mad posting replies on here during a weekend ? or parhaps just fanatics :-)
Newcastle Star Ale today :-)

[Uwe Zessin]

But according to John's message it sounds to me like non-Windows authentication is all beta-quality (EAK / under development) at best.

[DICTU OpenVMS]

If sys$single_signon is given the value of 3, then the windows passwd gets set in the uaf after a succesfull login. So even if the not so reliable system isn't available (again), the user is able to login...

[Ian Miller.]

Uwe - yes that unfortunate - the one one that works today is kerberos I think.

Menco - good point.

[Wim Van den Wyngaert]

I tend to agree with Ian.

Because it is Windows based, I have to do 3 months of admin before I can test this. And in case of a disaster, I don't want to depend on windows stuff (or in general, other platforms). For all stuff I depend for on windows, I have a backup system on VMS (allthough not is not always working as it should, e.g. mozilla).

Wim

[Uwe Zessin]

Eeek. I can certainly understand that you don't want to use a Windows solution if:

- it is not under your control
- you have a high administrative overhead dealing with them

It is too bad that VMS is a little behind in single sign-on technology.

[Cass Witkowski]

I thought there was some information in an OpenVMS future Road map where OpenVMS would allow autorization using LDAP. This was also linked in for using the CSWS (Apache Web server) that would allow users to authenticate not only on OpenVMS but from web pages all using the same source.


Anyone have more information on this?

[Kris Clippeleyr]

Hi,

Just wanted to add my 2 ct.

We're running an app over here, with hundreds of users, requiring to have and an account on the Wingdogs domain and one on VMS. They're accessing the app either via ACMSDI, or via SQL/Services. Our security policy is thus that the passwords have a lifetime of 90 days. Unfortunately, the users (well most of them) haven't got a clue how to login to the VMS box, let alone how to change their password. So we have considered external authentication & single signon using Advanced Server. Sadly to no avail, since neither ACMSDI, neither SQL/Services are capable of using this feature. I think they actually go directly to the SYSUAF.
So, imagine:
1. a user changing his password on Wingdogs; it doesn't get propagated to VMS; so no access to the app.
2. even if the user logs in into the VMS box and EXTAUTH is enabled, synchronization of passwords may fail because of different rules for passwords on Wingdogs & VMS (VMS does not allow "special" characters in passwords (other than "_" and "$", if I'm not mistaken)); so again no access to the app.
3. if the password on VMS expires, at least SQL/Services refuses the user access to the database; so the user is out of luck again.

So to us, external authentication & single signon using Advanced Server, is not (yet) the way to go. We're still waiting for "new" versions of ACMSDI & SQL/services that make use of this feature. And then again, there is still the issue of the possible failure of password synchronization.

For the moment, we have circumvented the problem somewhat. We now kind of "force" the users to change their password twice, once via the "normal" way on Wingdogs, and once via a home brewn CGI that sets the password on VMS. And we gave the users explicit instructions to use only A thru Z, 0 thru 9 and "_" and "$" to compose the password.

Does anyone here has any better (i.e. more elegant) solutions?

Regards,

Kris (aka Qkcl)

[Ian Miller.]

The ACME agent allowing authentication against a LDAP directory will be available as a EAK in V8.2 but not yet as a supported item. See side 20 of http://h71000.www7.hp.com/openvms/roadmap/openvms_roadmaps.htm

[Anton van Ruitenbeek]

Wim,

You're concern about not controlling the Lanmanager can be partial made easyer by creating an own DOMAIN, with only VMS machines. All other machines are BDC and one (cluster) is PDC. Take notice here with the IP ranges and number of cards in youre machine. LANManager is only on one card available (ugh), so herefore you need to set the two logicals (if you have more then one NIC in the machine)
PWRK$KNBDEAMON_DEVICE = EIA0
PWRK$KNBDEAMON_IPADDR = 10.11.12.13

The insecurity stays for LANMAN. But you have to leave a level for paswordsyncronisation. All the other party's we had who claimed to do paswordsyncro all work with procedures and these can be stopped and leaving an unknown situation behind.

AvR