call for best practices in the ad-world
Wolfgang Pichler
wolfgang.pichler at ivv.tuwien.ac.at
Mon Feb 23 16:04:53 GMT 2004
i use winbindd (lib_nss-stuff, pam-stuff) to give access to services
(exim,ssh,etc.) running on local samba-box to users existing in w2k-ad
on local domain.
if for any reason both dc's (one in linux vmware, one on grindy pIII :-)
are not operating all those services are inaccessible, of course and
esp. with mail this is a nuisance since i encounter permanent address
errors ...
i am now considering/experimenting for some time
=> option 1 : try to substitute winbindd functionality if no dc's are
reachable :
+ scenario 1a :
- pam_smbpass's migrate option
- tdbdump secrets/windbindd_idmap/etc.
- convert & do magic -> /etc/shadow.smb
- getent -s winbind {passwd|group} > /etc/{passwd|group}.smb
- use a tweaked pam_unix to access those *.smb flat files
- use a tweaked libnss_files_smb for non pam-aware
+ scenario 1b :
- enhance winbindd to use some 'last-known-good' cache and/or
use/construct those *.smb files
- preferable enhance pam_winbind too and use internal *.tdb's
so no other tweaking would be necessary
=> option 2 : set up ldap and try to convince a m$ dc to interoperate or
at least dump the ad to the max and tweak the rest
- use ldap for samba idmap and auth
- engage pam_ldap for system services
=> option 3 set up a krb5 kdc an try to convince a m$ dc to interoperate
or at least dump the ad to the max and tweak the rest
- just solves single-sign-on if anything
- potentially will introduce nis as additional user-database
- engage pam_krb5 for system services
-- advantages/tradeoffs
- option 1a
- quick but dirty and far from elegant
- password migration tricky
- snippets from pam/glibc needs to be recompiled to have
tweaked modules which seems a bit tedious
- option 1b
- wonder if never one thought about this possibility
- option 2
- seems to be the "proposed" way (samba developers) ?
- ldap requires considerable configuration effort
- any possible or intended migration paths ad <-> linux
(if ever intended or practicable from the samba side of world)
is big-wizard-knowledge and/or undocumented
- option 3
- samba people implement their own krb5 since they explicitly
say (in 3.0 code), they do not trust libkrb - very strange ...
- authentication only, what about other user-data - nis?,ldap?
-- so there remains a main problem :
i cannot see any nice and elegant solution or even a "PROPSED WAY" to
administrate users in a mixed ad/samba-3.0 environment until now.
... and what experiences are there out used by you ?
... no best practices ? don't be kidding !
regards
w.pichler
---
IM(V)HO && standard disclaimers apply ...
More information about the samba-technical
mailing list