> > Same here - which is why I raised the question. Although I probably > could get permission to join the domain I want to be able to add users > on the Linux side that don't exist in AD. Pam_smb works but I think > something that used LDAP would be better if the ldap server could have > local entries and proxy for the AD. > The strategy I took was far from best practices in my opinion but was really the best solution for us at the time we needed it (including AD licensing costs and several disparate facilities across the country). I have all of my servers use the pam_ldap module in addition to setting my nsswitch.conf to use ldap. Accounts in my openldap server which also exist in AD and which I would like to authenticate against use a local saslauthd daemon to support kerberos5 to our AD infrastructure. Accounts which do not exist in AD and I don't want them to are added to openldap as well but because of the value of the userPassword attribute they use local authentication instead of passing the request to saslauthd. Basically, I only use AD for authentication (SSO) when needed (typically for humans) and openldap for universal daemon accounts or other ancillary type accounts (plus rfc2307 type NIS data). Modifying the AD schema to support rfc2307 was not an option at the time either. This is far from elegant because many ldap attributes must be duplicated and made consistent in both AD and openldap but it has worked out quite well for us. The more sophisticated overlays weren't available to us when we rolled this out and I wasn't really familiar with any solid and free meta directory servers. I wonder if I could have done something with referrals for the ldap attributes that are duplicated... or does anyone recommend a solid and free meta directory server? Hope this helps someone.