[Samba] GPO for Computer/Machine not working

[Martin Tessun]

On 31.10.19 18:14, Robert Marcano wrote:
> On 10/20/19 11:52 AM, Martin Tessun via samba wrote:
>> Hi all,
>>
>> I am having the same issue that is described in an older thread here: 
>> https://lists.samba.org/archive/samba/2018-February/213656.html
>
>
> The description of that link, says it is running Samba AD with MIT 
> Kerberos. the MIT backend is experimental and this is one of the 
> problems it has, machine GPOs don't work. The NULL SID group 
> membership for machines is the same symptom of a machine joined to a 
> Samba AD with MIT Kerberos backend.
>
> From where are you getting the Samba packages?


The packages are the ones shipped with openSUSE:
- samba-4.9.5+git.187.71edee57d5a-lp151.2.6.1.x86_64 (just listing this 
one for reference).

Kerberos packages are the ones that are pulled in by dependency:

libndr-krb5pac0-4.9.5+git.187.71edee57d5a-lp151.2.6.1.x86_64
krb5-1.16.3-lp151.2.6.1.x86_64
krb5-server-1.16.3-lp151.2.6.1.x86_64
sssd-krb5-common-1.16.1-lp151.7.6.1.x86_64
sssd-krb5-1.16.1-lp151.7.6.1.x86_64
krb5-client-1.16.3-lp151.2.6.1.x86_64

So this looks very much like MIT Kerberos implementation - also when 
checking the rpm-dependencies on the samba packages:

[snip]
libkrb5.so.3(krb5_3_MIT)(64bit)
[snip]


Thanks!
Martin


>
>>
>> The problem I am facing is that the machine accounts are not trusted 
>> in the domain (this is true for all Win 10 Systems). The issue with 
>> the computer is from my pov:
>>
>>
>>      Folgende herausgefilterte Gruppenrichtlinien werden nicht 
>> angewendet.
>> ----------------------------------------------------------------------
>>          Local Admins Policy
>>             Filterung:  Verweigert (Sicherheit)
>>
>>          Default Domain Policy
>>             Filterung:  Verweigert (Sicherheit)
>>
>>          Richtlinien der lokalen Gruppe
>>             Filterung:  Nicht angewendet (Leer)
>>
>>      Der Computer ist Mitglied der folgenden Sicherheitsgruppen
>>      ----------------------------------------------------------
>>          NULL SID
>>          NETZWERK
>>          Diese Organisation
>>          Nicht vertrauenswürdige Verbindlichkeitsstufe
>>
>> Sorry, the Windows is German unfortunately, but what is happening is 
>> mainly that the PC doesn not have access to the SYSVOL share, as the 
>> Computer Account is not part of the correct security groups´(see 
>> above), but instead is part of:
>> - NULL SID
>> - NETWORK
>> - THIS ORGANISATION
>> - Untrusted Mandatory Level
>>
>>  From my PoV the Computer should be part of:
>> - Authenticated Users
>> - Domain Computers
>> - High Mandatory Level
>>
>> This is not the case and the reason the machine does not get access 
>> to the sysvol. This can also be seen within the details, as the 
>> gpt.ini can't be accessed (Policy Version 65535):
>>
>> Verknüpfungsort ad.die-tessuns.de
>> Konfigurierte Erweiterungen {827D319E-6EAC-11D2-A4EA-00C04F79F83A}
>> Erzwungen Nein
>> Deaktiviert Keine
>> Sicherheitsfilter NT-AUTORITÄT\Authentifizierte Benutzer
>> Revision AD (2), SYSVOL (65535)
>> WMI-Filter
>> Grund: abgelehnt Zugriff verweigert (Sicherheitsfilterung)
>>
>>
>> Whereas the User has the correct security Groups:
>>
>>     Der Benutzer ist Mitglied der folgenden Sicherheitsgruppen
>>      ----------------------------------------------------------
>>          Domain Users
>>          Jeder
>>          Benutzer
>>          INTERAKTIV
>>          KONSOLENANMELDUNG
>>          Authentifizierte Benutzer
>>          Diese Organisation
>>          LOKAL
>>          Local Admins
>>          Hohe Verbindlichkeitsstufe
>>
>> So in English:
>> - Domain Users
>> - Everyone
>> - Users
>> - INTERACTIVE
>> - Console Logon
>> - Authenticated User
>> - This Organization
>> - Local
>> - Local Admins
>> - High Mandatory Level
>>
>> Rejoining the Computer does not make any difference as well as 
>> adjusting the SYSVOL permissions as described in several threads. So 
>> from my pov the right thing to solve this issue is to get the 
>> computer account to the correct trustlevel/security group membership.
>>
>> Unfortunately I found no way doing so.
>>
>> So if anyone has an idea on what to do here would be greatly 
>> appreciated (BTW. Looking at effective user rights for the SYSVOL 
>> shares the machine account <COMPUTERNAME>$ as well as SYSTEM should 
>> have access rights. Unfortunately the GPO thinks otherwise.
>>
>> Also note that Computer GPO is the only thing that is not working. 
>> And I also tried all the solution proposals listed in the 
>> aforementioned thread already - as expected with no success.
>>
>> Thanks!
>> Martin
>>
>
>
>