We have few customer facing servers in DMZ that also have user accounts , all accounts are in shadow password file. I am trying to consolidate user logons and thinking about letting LAN users to authenticate against Active Directory.Services needing authentication are Apache, Proftpd and ssh. After consulting security team I have setup authentication DMZ that has LDAPS proxy that in turn contacts another LDAPS proxy (proxy2) in LAN and this one passes authentication info via LDAP (as LDAP bind) to AD controller.Second LDAP proxy only needed because AD server refuses speak TLS with our secure LDAP implemetation. This works for Apache using appropriate module.At a later stage I may try to move customer accounts from servers to LDAP proxy so they are not scattered around servers.
For SSH I joined proxy2 to Windows domain so users can logon using their windows credentials.Then I created ssh keys and copied them to DMZ servers using ssh-copy, to enable passwordless logon once users are authenticated.
Is this a good way to implement this kind of SSO?Did I miss any security issues here or maybe there is a better way ofachieving my goal?
If you're using PAM for your authentication stack, you can use pam_krb5 to provide kerberos authentication for your services. Kerberos was designed out-of-the-box to deal with hostile environments, handles authentication-by-proxy, and is already a part of the AD spec. Why struggle with LDAP when you can get Kerberos to do the heavy lifting for you, and get on with life? Yeah, you'll have to do some reading, and yeah, it'll take a bit of time, but I've used Kerb-to-AD authentication for years and have found it to be the easiest, quickest way to get SSO working out of the box when you have Active Directory as the authentication backend.
The main thing you'll run into is that Microsoft decided to be very specific about the default encryption types (they basically made their own), so you'll need to set up your Kerberos clients to have the correct matching encryption types, or the AD servers will continue to reject it. This is thankfully an easy procedure and shouldn't require more than a few edits to krb5.conf.
And now, some links for you to consider...
Microsoft's View of Kerberos
Meshing Kerberos and Active Directory
ssh and Kerberos authentication via PAM
Apache and Kerberos
ProFTP and Kerberos
RFCs of Microsoft's Activities with Kerberos (which you really don't want to read about):