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 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
On 20/10/2019 16:52, 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 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 >Just to make sure, are you modifying either of the two default GPOs ? Rowland
Hi Rowland, On 20.10.19 19:16, Rowland penny wrote:> On 20/10/2019 16:52, 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 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 werdennicht 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 >> > Just to make sure, are you modifying either of the two default GPOs ? >This doesn't make any difference at all. I tried it with the Default Domain Policy as well as a separate policy. The results are all the same. As said, I tried all the proposed solutions in the old thread I linked. Please also note that all GPOs for Users get applied and work (as the users have the "correct" Security Groups), but computer accounts are not able to apply the GPO. Even opening up the SYSVOL share for everyone does not help - as the machine is part of "NULL SID" and "Untrusted Mandatory Level" which leads to the machine account not having any access to any share in the domain regardless of its security. The machine account itself is in "Domain Computers" and if I check the %COMPUTERNAME%$ account to the share it *should* have access. Unfortunately the GPO tooling of Microsoft thinks differently - that is why it is not part of "Authenticated Users" as it should be according to MS. This is how a machine/computer should look like in terms of Security Groups in AD (at the very least): The computer is a part of the following security groups: -------------------------------------------------------- ??? Everyone ??? NT AUTHORITY\NETWORK ??? NT AUTHORITY\Authenticated Users And this is what my machines in the Samba domain all look like (according to gpresult): The computer is a part of the following security groups: -------------------------------------------------------- ??????? NULL SID ??????? NETWORK ??????? THIS ORGANISATION ??????? Untrusted Mandatory Level And that exact mismatch to what MS says a machine account should be and what all my Samba accounts are seems to be the issue from my PoV. The machine is neither part of "Everyone" nor of "Authenticated Users" security group, which it should - also see e.g. https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc759506(v=ws.10)?redirectedfrom=MSDN Cheers, Martin> Rowland > > > >
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.htmlThe 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 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 >
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 >> > > >