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?
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.
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!
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!).
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.
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.
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.
Have you seen the attachment?
I need a matching set of all three: client log, server log, network trace from wireshark.
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.
Created attachment 3010 [details] Related network traffic capture This could help to locate the problem. In this capture are the CLDAP queries saved.
Created attachment 3011 [details] Server log Logfile from server with debuglevel 5
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!
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.
Andrew, but can it be that Win2k sends slightly different CLDAP queries?
I've found now the matching error code in SAMBA 4: libcli/util/werror.h: WERR_NO_SUCH_USER for #1317
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.
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: _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.<hostname> _ldap._tcp.dc._msdcs.<hostname> <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.
Hello, 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.
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.
- 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?
Created attachment 3377 [details] Patch for provision script This patch fixes the Windows 2000 warning regarding the missing "gpt.ini" file.
Created attachment 3381 [details] Cosmetic correction of the patch for provision script GPT.INI
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.
I'm now also happy with the work done to fix this!