>
> 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.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
