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 > > > >
Hi all, On 21.10.19 17:38, Martin Tessun wrote:> 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 >Really no one knows something? Can someone with working Computer GPOs please check the security group of his/her computer? So the main question is: Are the (from my pov) wrong security groups for the machine account the real issue? Also: Why does the %COMPUTERNAME%$-Account show up in the correct security groups, while gpresult shows the computer is not trusted. All other things work (Authentication, Mounting shares, etc.) - just the GPO shows these strange results and is not working. Thanks! Martin> Cheers, > Martin > >> Rowland >> >> >> >> > > > >
gpresult /scope computer /r
The computer is a part of the following security groups
-------------------------------------------------------
BUILTIN\Administrators
Everyone
BUILTIN\Users
NT AUTHORITY\NETWORK
NT AUTHORITY\Authenticated Users
This Organization
<computername>$
Domain Computers
Windows Clients <----- Custom Security Group
Testing <------ Also custom Security Group
System Mandatory Level
This is on a Samba 4.9.13 domain, mostly Windows 10 1709 clients.
So yeah, your groups look funky.
Kris Lou
klou at themusiclink.net
On Thu, Oct 31, 2019 at 1:04 AM Martin Tessun via samba <
samba at lists.samba.org> wrote:
> Hi all,
>
> On 21.10.19 17:38, Martin Tessun wrote:
> > 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
> >
>
> Really no one knows something? Can someone with working Computer GPOs
> please check the security group of his/her computer? So the main
> question is: Are the (from my pov) wrong security groups for the machine
> account the real issue?
>
> Also: Why does the %COMPUTERNAME%$-Account show up in the correct
> security groups, while gpresult shows the computer is not trusted. All
> other things work (Authentication, Mounting shares, etc.) - just the GPO
> shows these strange results and is not working.
>
>
> Thanks!
> Martin
>
>
> > Cheers,
> > Martin
> >
> >> Rowland
> >>
> >>
> >>
> >>
> >
> >
> >
> >
>
>
>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions: https://lists.samba.org/mailman/options/samba
>