LDAP Authentication

[Malcolm Dunnett]

I've just installed the LDAP authentication kit VMS83A_ACMELDAP-V0200. It works very nicely except for a couple of issues/concerns:

1.) The TCP/IP Services SSH server doesn't talk to it as far as I can tell - is there any way to make them play nicely together?

2.) It only allows one LDAP server in the configuration file. That somewhat defeats the point of using a distributed directory for reliability. If I was to define a domain name that had two (or more) address entries and used that name in the configuration file does anyone know if that would work (ie would the authentication module try the second host listed if it couldn't talk to the first, etc?)

[Steven Schweda]

I know practically nothing about LDAP, or how
SSH deals with it, but ...

> 1.) [...]

You mean that when the SSH server gets to
"password" in its "AllowedAuthentications",
list, a good LDAP password fails? (You have
an "ssh -v" transcript from the client which
shows what happens?) Or what?

(I normally use "publickey" for SSH, so I
don't deal much with passwords v. SSH.)

[Malcolm Dunnett]

Yes, that's what happens. The LDAP server is Active Directory, so if I (for example) change the password from a Windows client and then try to SSH into the VMS box the SSH server on VMS doesn't see the new password, it still wants the old password. This is presumably because it's checking the UAF directly, not using the SYS$ACM service. On the other hand, if I do the same password change and then TELNET to the VMS box I can log in using the new password.

[M. T. Hollinger]

That's right, the current implementation of SSH is integrated with Kerberos (both to accept credentials and to check passwords) but not with LDAP. Since many SSH users choose public-key authentication anyway, this is not an issue for everyone.

Converting various TCP/IP Services components (IMAP, POP, PCNFS, XDM, and yes, SSH) to use the $ACM system service for password authentication is on the worklist for a future release. The main benefit of such a conversion will be support of Single Sign-On, including LDAP. Such support comes "for free" with TELNET and RLOGIN sessions since it isn't actually TCP/IP prompting for or checking the username, just the standard interactive session startup mechanism involving the terminal driver, the job controller, and LOGINOUT.

Thinking about it as a result of your post, I realize I don't actually know whether FTP and REXEC will honor LDAP passwords. Those components also use LOGINOUT rather than checking passwords directly. Have you tried your LDAP password with either FTP or REXEC?

- Mark

[Malcolm Dunnett]

FTP appears to use the ACM service, REXEC doesn't (this isn't an issue for me as the only time I use rexec is in conjunction with proxy settings so the password doesn't come into play.

As to ssh I guess we're neophytes here, we tend to use it as a more secure version of telnet rather than getting into exotic authentication methods such as public key.

It appears that the "standard" ssh implementation allows keyboard-interactive authentication, which would allow me to write a program/script that could get the password and verify it against ACM, but the TCP/IP services implementation doesn't appear to support this (I can put it in the config file but it appears to be ignored)