From 259763dac98269781be22d36664518a1123b4bd2 Mon Sep 17 00:00:00 2001 From: Gerald Carter Date: Wed, 16 Jul 2003 03:51:25 +0000 Subject: updating WHATSNEW removing old readme (not part of WHATSNEW) (This used to be commit c9c5f68eeab5a36b279673c728411672b4b4449b) --- docs/README.idmap-and-winbind-changes | 73 ----------------------------------- 1 file changed, 73 deletions(-) delete mode 100644 docs/README.idmap-and-winbind-changes (limited to 'docs') diff --git a/docs/README.idmap-and-winbind-changes b/docs/README.idmap-and-winbind-changes deleted file mode 100644 index a892343c6e..0000000000 --- a/docs/README.idmap-and-winbind-changes +++ /dev/null @@ -1,73 +0,0 @@ -## Date : 2003-07-09 -## Author: Gerald (Jerry) Carter -## Title: README.idmap-and-winbind-changes - -Introduction ------------- - -Beginning with Samba3.0.0beta3, winbindd has been given new account -manage functionality equivalent to the 'add user script' family of -smb.conf parameters. The idmap design has also been changed to centralize -control of foreign SID lookups and matching to UNIX uids and gids. - - -Brief Description of Changes ----------------------------- - -1) The sid_to_uid() family of functions (smbd/uid.c) have been reverted - to the 2.2.x design. This means that when resolving a SID to a UID - or similar mapping: - - a) First consult winbindd - b) perform a local lookup only if winbindd fails to - return a successful answer - - There are some variations to this, but these two rules generally - apply. - -2) All idmap lookups have been moved into winbindd. This means that - a server must run winbindd (and support NSS) in order to achieve - any mappings of SID to dynamically allocated UNIX ids. This was - a conscious design choice. - -3) New functions have been added to winbindd to emulate the 'add user script' - family of smbd functions without requiring that external scripts - be defined. This functionality is controlled by the 'winbind enable local - accounts' smb.conf parameter (enabled by default). - - However, this account management functionality is only supported in - a local tdb (winbindd_idmap.tdb). If these new UNIX accounts must be - shared among multiple Samba servers (such as a PDC and BDCs), it - will be necessary to define your own 'add user script', et. al. - programs that place the accounts/groups in some form of directory - such as NIS or LDAP. This requirement was deemed beyond the scope - of winbind's account management functions. Solutions for distributing - UNIX system information have been deployed and tested for many years. - We saw no need to reinvent the wheel. - -4) A member of a Samba controlled domain running winbindd is now able to - map domain users directly onto existing UNIX accounts while still - automatically creating accounts for trusted users and groups. This - behavior is controlled by the 'winbind trusted domains only' smb.conf - parameter (disabled by default to provide 2.2.x winbind behavior). - -5) Group mapping support is wrapped in the local_XX_to_XX() functions - in smbd/uid.c. The reason that group mappings are not included - in winbindd is because the purpose of Samba's group map is to - match any Windows SID with an existing UNIX group. These UNIX - groups can be created by winbindd (see next section), but the - SID<->gid mapping is retreived by smbd, not winbindd. - - -Examples --------- - -* security = server running winbindd to allocate accounts on demand - -* Samba PDC running winbindd to handle the automatic creation of UNIX - identities for machine trust accounts - -* Automtically creating UNIX user and groups when migrating a Windows NT - 4.0 PDC to a Samba PDC. Winbindd must be running when executing - 'net rpc vampire' for this to work. - -- cgit