~ubuntu-branches/ubuntu/gutsy/samba/gutsy-updates

« back to all changes in this revision

Viewing changes to examples/LDAP/smbldap-tools-0.9.2/INFRA

  • Committer: Bazaar Package Importer
  • Author(s): Andrew Mitchell
  • Date: 2006-11-28 20:14:37 UTC
  • mfrom: (0.10.1 upstream)
  • Revision ID: james.westby@ubuntu.com-20061128201437-a6x4lzlhempazocp
Tags: 3.0.23d-1ubuntu1
* Merge from debian unstable.
* Drop python2.4-samba, replace with python-samba. Added Conflicts/Replaces
  on python2.4-samba
* Drop track-connection-dos.patch, ubuntu-winbind-panic.patch, 
  ubuntu-fix-ldap.patch, ubuntu-setlocale.patch, ubuntu-setlocale-fixes.patch
* Remaining Ubuntu changes:
  - Revert Debian's installation of mount.cifs and umount.cifs as suid
  - Comment out the default [homes] shares and add more verbose comments to
    explain what they do and how they work (closes: launchpad.net/27608)
  - Add a "valid users = %S" stanza to the commented-out [homes] section, to
    show users how to restrict access to \\server\username to only username.
  - Change the (commented-out) "printer admin" example to use "@lpadmin"
    instead of "@ntadmin", since the lpadmin group is used for spool admin.
  - Alter the panic-action script to encourage users to report their
    bugs in Ubuntu packages to Ubuntu, rather than reporting to Debian.
    Modify text to more closely match the Debian script
  - Munge our init script to deal with the fact that our implementation
    (or lack thereof) of log_daemon_msg and log_progress_msg differs
    from Debian's implementation of the same (Ubuntu #19691)
  - Kept ubuntu-auxsrc.patch: some auxilliary sources (undocumented in 
    previous changelogs)
  - Set default workgroup to MSHOME

Show diffs side-by-side

added added

removed removed

Lines of Context:
 
1
# $Source: /opt/cvs/samba/smbldap-tools/INFRA,v $
 
2
#
 
3
## Some notes about the architecture
 
4
 
 
5
 
 
6
Global Architecture for smbdlap-tools
 
7
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 
8
 
 
9
smbldap-tools help you manage users and groups for Unix and Samba,
 
10
using LDAP. They may be used in any context, and are kept relatively
 
11
simplier enought to let you customize them to you needs.
 
12
 
 
13
They need the following objectClasses to work:
 
14
 . sambaAccount: from samba.schema for Samba 2.2 branch
 
15
 . posixAccount and posixGroup : from nis.schema
 
16
 . organizationalUnit and dcObject: from core.schema
 
17
 
 
18
They will probably use in a near future some additional objectClasses
 
19
to support : 
 
20
 . mail features (sendmail/postfix/qmail/courier).
 
21
 . conform to RFC2307 best practices (and so some maps too like merging
 
22
   Netbios computers (sambaAccounts) with ipHosts
 
23
 
 
24
For ease of visualization of the LDAP objects by human standards, we
 
25
used a DIT like this one :
 
26
 . dc=IDEALX,dc=org : the company/organization suffix
 
27
        . ou=Users : to store users accounts
 
28
        . ou=Computers : to store computers accounts
 
29
        . ou=Groups : to store system groups
 
30
Of course, you're free to use a different naming scheme and DIT (see
 
31
smbldap_conf.pm).
 
32
 
 
33
 
 
34
Built in groups initial population 
 
35
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 
36
 
 
37
smbldap-populate.pl populate the LDAP directory with some built in groups 
 
38
using gidNumber according to Well Know RID of Windows NT4 Srv. In fact, As
 
39
far a Samba 2.2.x is concerned, only the 'Domain Admins' (gidNumber 512) have 
 
40
real inpact on the Samba and Windows population. To activate this group as 
 
41
the Domain Administrators Group, use the following smb.conf directive (see 
 
42
man smb.conf for more):
 
43
 
 
44
        domain admin group = " @"Domain Admins" "
 
45
 
 
46
However, to make pdb_ldap accept bind without being uid=0, a quick and
 
47
dirty patch must be applied to 2.2.4 (see samba-2.2.4-ldapbindnotuid0.patch).
 
48
This patch is Q&D because the check is there because Samba store admin 
 
49
credentials to establish the LDAP connection. The uid == 0 check was to 
 
50
ensure that a normal user could not get write access to the LDAP backend.
 
51
A more logical situation should be done for 2.2.5 by checking if the user
 
52
is a member of the domain admin group (reported to Jerremy and Gerald 
 
53
2002-05-28).
 
54
 
 
55
Other built in groups are really cosmetic ones with Samba 2.2.x. We did not
 
56
removed them because one of these days, we whish to use Samba 3.0 where 
 
57
Windows Group Support should be operational.
 
58
 
 
59
Why these specific gidNumbers ?
 
60
It's about unix/windows mapping of numerical ids with Samba. Ids below 1024 
 
61
are NT special ids. In fact, 512 is the RID (Windows uid/gid) for the 
 
62
"Domain Administrators" NT group. The magic number is found in Samba sources 
 
63
and possibly other Samba/Windows documentations.
 
64
 
 
65
The goal is to have a set of Unix users who are Domain Administrators and can 
 
66
modify Samba datas (eg. LDAP content), with commandline tools or within 
 
67
Windows via Samba.
 
68
 
 
69
Say you want to add a NT4 ws to an NT domain (controlled by a samba/ldap  
 
70
server). You give the domain administrator's login and password in the 
 
71
appropriate ws settings, then the ws contacts the samba server, which checks 
 
72
the credentials and use them as unix user to run the smbldap-tools (if I 
 
73
remember). Giving 512 as a RID to a LDAP entry marks it as a domain admin   
 
74
for Samba (thus Windows). Using nss_ldap, you also have an account with
 
75
gid 512.
 
76
 
 
77
 
 
78
Known BUGS and WORKAROUND used
 
79
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 
80
 
 
81
The 2.2.2 has at least a bug : rid/primaryGroupID are read as hex in LDAP,
 
82
but written as decimal. Fixed in CVS by reading as decimal. By default
 
83
smbldap-useradd.pl writes decimal to LDAP. Use -x to support the odd
 
84
behaviour.
 
85
 
 
86
The samba-2.2.4-ldapbindnotuid0.patch is not a perfect solution however
 
87
as the check is there because Samba store admin credentials to establish the 
 
88
LDAP connection. The uid == 0 check was to ensure that a normal user could 
 
89
not get write access to the LDAP backend. A more logical situation should be 
 
90
done for 2.2.5 by checking if the user is a member of the domain admin group 
 
91
(reported to Jerremy and Gerald 2002-05-28).
 
92
 
 
93
# - The End