call for best practices in the ad-world

[David Collier-Brown]

   To oversimplify, I suspect that it's easier to take over from a
downed server than convince one to interoperate.
   A takeover after a visible failure has the advantage of showing
the user communiuty that someone's trying to help them, and
they are likely to be accepting of temporary inconveniences
or workarounds.
   Full interoperability and a transparent takeover might be
quite difficuly, and might be seen by users as 'just another
mysterious slowdown of SMB services"

--dave

Wolfgang Pichler wrote:
> 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 ...
> 
> 
> 


-- 
David Collier-Brown,       | Always do right. This will gratify
Sun Microsystems,          | some people and astonish the rest.
Toronto, Ontario,          |                      -- Mark Twain
(905) 415-2849 or x52849   | davecb at canada.sun.com