Bug 4900 - Group policy support in SAMBA
Summary: Group policy support in SAMBA
Alias: None
Product: Samba 4.0
Classification: Unclassified
Component: Other (show other bugs)
Version: unspecified
Hardware: All All
: P3 normal (vote)
Target Milestone: ---
Assignee: Andrew Bartlett
QA Contact: Andrew Bartlett
Depends on:
Reported: 2007-08-20 06:16 UTC by Matthias Dieter Wallnöfer
Modified: 2008-08-02 08:16 UTC (History)
0 users

See Also:

Client logs (2.59 KB, text/plain)
2007-08-31 02:13 UTC, Matthias Dieter Wallnöfer
no flags Details
Related network traffic capture (25.76 KB, application/octet-stream)
2007-11-29 16:45 UTC, Matthias Dieter Wallnöfer
no flags Details
Server log (76.81 KB, text/plain)
2007-11-29 16:50 UTC, Matthias Dieter Wallnöfer
no flags Details
Patch for provision script (720 bytes, patch)
2008-07-02 17:03 UTC, Matthias Dieter Wallnöfer
no flags Details
Cosmetic correction of the patch for provision script GPT.INI (720 bytes, patch)
2008-07-03 03:20 UTC, Matthias Dieter Wallnöfer
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Dieter Wallnöfer 2007-08-20 06:16:46 UTC
In my tests with SAMBA 4 I found the group policy support a bit labile. Often the domain client (the Win2k VM) wasn't able to apply them.  In fact I noticed the long duration of the login process for a domain user. The domain join seemed to work fine. In the client log I realized messages like "Source: userenv. User- and computername couldn't be determined". I think that should be the problem.
Have you any clues what that could be?
Comment 1 Matthias Dieter Wallnöfer 2007-08-22 12:59:02 UTC
Now I've fixed the issue with the slow login progress. It was caused by a bad WINS server entry on the client. Additionally, I get also message NETLOGON n. 5721 (bad machine account for domain) on the client in the event viewer. The other message USERENV (user- or computername couldn't be determined) has the id n. 1000.
Ironically, the domain join seems to work. I notice the machine account in ADUC and didn't get error messages on joining. I can also login normally with domain user accounts.
Comment 2 Matthias Dieter Wallnöfer 2007-08-31 02:13:12 UTC
Created attachment 2906 [details]
Client logs

Maybe you Andrew could discover the problems listed in the logfiles and in the eventviewer. I don't know why, but since one point now the client is unable to get the GPOs from SAMBA 4. Please comment!
Comment 3 Matthias Dieter Wallnöfer 2007-09-19 13:36:09 UTC
Andrew, does the group policies apply in the right manner on your Windows box/VM? On my test environment this doesn't work anymore since end of July (previous SVN's worked!).
Comment 4 Andrew Bartlett 2007-11-29 02:54:40 UTC
I've been working on the LDAP server, and retested group policy support.  It seems to be working again.  (I think I know what broke it too). 

Please test, and reopen if issues remain. 
Comment 5 Matthias Dieter Wallnöfer 2007-11-29 08:17:12 UTC
It may work on your test environment again. On my personal one it didn't start to work again (same messages in the event viewer - no policies applied).
As said, maybe you have a clue why it tells me "bad machine account for domain" when the workstation joined successfully and the account for it is created in the AD. Or also the other message "user- or computername couldn't be determined" (or similar - I work on a german environment) is very ambigous to me.
Comment 6 Andrew Bartlett 2007-11-29 15:04:57 UTC
I'll need matching client and server logs (at a level of detail showing the error returns), and a network trace, before I can chase this down any more. 
Comment 7 Matthias Dieter Wallnöfer 2007-11-29 15:23:16 UTC
Have you seen the attachment?
Comment 8 Andrew Bartlett 2007-11-29 15:26:42 UTC
I need a matching set of all three: client log, server log, network trace from wireshark. 
Comment 9 Matthias Dieter Wallnöfer 2007-11-29 16:31:47 UTC
One problem found: The id of the _ldap._tcp.<string>.domains entry in the from the provisioning autogenerated zone-file, wasn't the one the client was seeking. I have discovered that in wireshark and corrected.
Comment 10 Matthias Dieter Wallnöfer 2007-11-29 16:45:18 UTC
Created attachment 3010 [details]
Related network traffic capture

This could help to locate the problem. In this capture are the CLDAP queries saved.
Comment 11 Matthias Dieter Wallnöfer 2007-11-29 16:50:00 UTC
Created attachment 3011 [details]
Server log

Logfile from server with debuglevel 5
Comment 12 Matthias Dieter Wallnöfer 2008-01-01 13:56:05 UTC
Maybe another clue: my client launches a cldap netlogon request with version number 6 says wireshark. But SAMBA has only a structure for a cldap netlogon request version 5 (see nbt.idl file or cldap_server/netlogon.c) which is mapped to  6. The win2k virtual machine isn't satisfied and tries two dozen of times to get the right one.
We need to bring this up!
Comment 13 Andrew Bartlett 2008-01-06 22:46:18 UTC
I've spent much of today chasing down false leads on this bug, but have not yet had any sucesss.

The CLDAP queries and replies appear to match what Win2k3 does. 
Comment 14 Matthias Dieter Wallnöfer 2008-01-07 14:52:32 UTC
Andrew, but can it be that Win2k sends slightly different CLDAP queries?
Comment 15 Matthias Dieter Wallnöfer 2008-01-07 16:45:07 UTC
I've found now the matching error code in SAMBA 4:
libcli/util/werror.h: WERR_NO_SUCH_USER for #1317
Comment 16 Andrew Bartlett 2008-01-07 22:35:29 UTC
Is there really only CLDAP traffic when the problem presents itself?

With my Win2000 machine (SP0), I get far more interesting issues :-)

To assist in chasing down yours, a more comprehensive trace might be valuable.
Comment 17 Matthias Dieter Wallnöfer 2008-01-26 15:42:20 UTC
Maybe also that could be a reason for the problem:
I noticed in wireshark some DNS SRV queries which the SAMBA DNS server couldn't resolve:


<hostname> some times seems to be the NetBIOS name but it can be also the DNS name. There were mentioned the client and the server.
Comment 18 Sven Zaremba 2008-03-17 05:09:28 UTC

I use windows XP, but although I have got Problems with adding GPOs to 
"normal users". They don´t work. At Windows XP "Event Viewer", I think I found the Problem. It says that it isn´t possible to access the file "gpt.ini". But this file exists proberly. I testet it with windows explorer. 
I definetely can´t access the Folder "gpt.ini" exists in. But with the administrator account I can acces to this file. 
Comment 19 Matthias Dieter Wallnöfer 2008-05-22 05:08:34 UTC
Now, here updates (noticed on my Win2k test environment):
- In the event logger under "Applications" I get the following error messages (Userenv/ID: 1000): - Query to the list of group policy objects failed - File "gpt.ini" of the group policy object inaccessible. File should be located in path <>.
- In the event logger under "System" the following message (Netlogon/ID: 5719): No WinNT/2k domain controller available for the domain ... . RPC protocol error.
Comment 20 Matthias Dieter Wallnöfer 2008-05-22 05:23:48 UTC
- After a modification to the default group policy the event messages under "Applications" are gone. I think they are related to the missing "gpo.ini" file after the installation (the provision should create one). The second problem remains.
- My tested group policies work. Thanks Andrew for your great work!
- I cannot add new policies in the domain root object (there is only the default one). Is this behaviour correct?
Comment 21 Matthias Dieter Wallnöfer 2008-07-02 17:03:58 UTC
Created attachment 3377 [details]
Patch for provision script

This patch fixes the Windows 2000 warning regarding the missing "gpt.ini" file.
Comment 22 Matthias Dieter Wallnöfer 2008-07-03 03:20:09 UTC
Created attachment 3381 [details]
Cosmetic correction of the patch for provision script GPT.INI
Comment 23 Matthias Dieter Wallnöfer 2008-07-15 11:53:53 UTC
New status:
- "GPT.INI" warning with patch fixed
- Group policy dialog under domain root object fixed
- This remains: In the event logger under "System" the following message (Netlogon/ID: 5719): No WinNT/2k domain controller available for the domain ... RPC protocol error.
- The appending of new GPO's with the appropriate button "New" under the register "Group policies" doesn't work every time.
Comment 24 Matthias Dieter Wallnöfer 2008-08-02 08:16:15 UTC
I'm now also happy with the work done to fix this!