Brian,

> so if the [log in to unmask] exists without a password should I
> a) configure ldap to forward a request for authentication
> b) fall back into the pam stack and use another pam module to talk to umbrella.psi.net

I'm having trouble understanding this. Can you perhaps draw a block diagram of what you're trying to achieve?

When you say "without a password", do you mean that user does not need to enter a password to login, or that the password is simply not stored in LDAP? Are you attempting to use Moonshot for authentication (using pam_gss) and LDAP for account information (using nss_ldap and either pam_unix or pam_ldap)?

Or are you attempting to authenticate with pam_ldap and have the LDAP server forward the authentication to a RADIUS server? (Which is entirely possible, pam_ldap supports arbitrary SASL mechanisms so it should work with GS2. For the curious, you would set pam_sasl_mech to EAP-AES128 or EAP-AES256 in ldap.conf. This has not been tested.)

> I previously had non-local users get forwarded to RADIUS using pam_radius, and successfully authenticated
> but the user couldn't ssh because they didn't have a local account.

Right, so it will be helpful to separate PAM and NSS here. Do you have nss_ldap (or something similar) configured and are you able to retrieve information using getent passwd?

The packet trace suggests that perhaps embedded quotes are making their way to the LDAP server. Are you sure you don't have any quotes in ldap.conf for any DNs? nss_ldap/pam_ldap will not strip them out.

> However, I have now set up local accounts in LDAP if only I could get it to work.

FWIW, it might be less confusing to reserve the term "local accounts" for accounts that actually reside in /etc/passwd, rather than an LDAP server (although I suppose in the Moonshot case this might make sense if the LDAP server is local to your organisation, and the authenticated identity is remote).

-- Luke