| 1 |
On Thu, 2004-09-23 at 15:13 +0200, Tarax wrote: |
| 2 |
> Hi, |
| 3 |
> |
| 4 |
> Could someone tell me how far it is possible to substitute a Windows |
| 5 |
> Server/PDC with linux products (samba+ldap+etc...) ? |
| 6 |
> What ar the main problems one could encounter ? |
| 7 |
> What is actually impossible ? |
| 8 |
|
| 9 |
Functionally, a Samba PDC is more or less equivalent to a Windows NT 4.0 |
| 10 |
domain controller. You can only tell a Samba server to authenticate |
| 11 |
against an Active Directory on a Windows 2000/2003 server, Samba cannot |
| 12 |
_act_ as an AD server. This also means that kerberos is not used |
| 13 |
(rather, the LANMAN authentication mechanism). |
| 14 |
|
| 15 |
In recent versions, one can define mappings between Unix user groups and |
| 16 |
the various standard user groups which are supported by Windows in a |
| 17 |
domain context (Domain Admins, Domain Users, Backup Operators etc). |
| 18 |
Before, it was only possible to map Unix users/groups to Domain Admins |
| 19 |
and Domain Users. |
| 20 |
|
| 21 |
Roaming profiles are fully supported. System policies are also supported |
| 22 |
but one must prepare the policy file using a Windows based tool before |
| 23 |
populating them in the netlogon share. Specifically, one must use the |
| 24 |
poledit.exe tool (supplied with NT 4.0 I believe) to create these files. |
| 25 |
However, someone has updated the .adm files used to define the available |
| 26 |
rules (and the registry keys that they alter) to work with modern |
| 27 |
Windows clients (2000 and XP). See http://www.osnews.com/story.php? |
| 28 |
news_id=6684 for an overview. The .adm files are available from here: |
| 29 |
http://www.snipes.org/admfiles.zip. One will not have quite the same |
| 30 |
flexibility as provided by the System Policies in AD (for instance, not |
| 31 |
being able to apply system policies to organisational units with child |
| 32 |
inheritance). However, one can use the traditional mechanism of applying |
| 33 |
them to groups or individual users, with the ability to "cascade" and |
| 34 |
the available permissions will be as extensive. In the poledit tool one |
| 35 |
can leave a checkbox grey to indicate that the policy in question will |
| 36 |
inherit either the OS default, or from another policy which applies to |
| 37 |
the same user (either by group or a per-user policy). |
| 38 |
|
| 39 |
Samba also has various tricks up its sleeve that would not be possible |
| 40 |
(at least, not trivially) on a Windows server. |
| 41 |
|
| 42 |
Please note that it is not necessary to disable SMB's SignOrSeal feature |
| 43 |
on the client anymore (as suggested in the article) |
| 44 |
|
| 45 |
Microsoft supply an extra to allow Windows clients to natively |
| 46 |
authenticate against an MIT Kerberos 5 server. I don't recommend it |
| 47 |
though because one would have to manage the groups and such locally on |
| 48 |
each client and at a cost to functionality. |
| 49 |
|
| 50 |
Whether you do all this via LDAP or using, say, the tdbsam backend |
| 51 |
doesn't really affect the nature of the functionality although I've |
| 52 |
heard that PDC/BDC co-operation is a good deal better when using LDAP. |
| 53 |
|
| 54 |
If you're looking for an open-source method for preparing clients using |
| 55 |
unattended installations then please look at |
| 56 |
http://unattended.sourceforge.net. It really is quite superb. As it uses |
| 57 |
ActivePerl on the client to do most of the heavy shifting, it can also |
| 58 |
make a good system for software deployment. |
| 59 |
|
| 60 |
In summary, the functionality should be quite sufficient for most |
| 61 |
setups. I've been using it for some time and rather like it! In fact, |
| 62 |
I'm planning to move to LDAP soon. I've made considerable progress; it |
| 63 |
has not been trivial and I intend to create documentation on it some |
| 64 |
time. |
| 65 |
|
| 66 |
HTH, |
| 67 |
|
| 68 |
--Kerin Francis Millar |
Archives