Grupenrichtlinien werden nicht übernommen

Hallo zusammen
wir haben folgendes Problem:
wir haben einen neuen UCS Server 4.1.1installiert und die Domäne eingerichtet.
Bei der Installation gabe es keine Probleme.
Es ist eine kleine Umgebung mit einem Standalone Server und ca 10 Win 7 Clients.
Habe dann nach der installation auf einem Client Rsat installiert und einige Gruppenrichtlinien erstellt: kein CMD, Systemsteuerung etc.
Die GPO- Verknüpfung erfolgt direkt auf Domänenebene.
Bei allen Clients haben die Gruppenrichtlinien sofort gezogen.
Nun musste ich neue User anlegen aber es wird keine einzgige Gruppenrichtlinie übernommen.
Wenn ich mit mit Samba-tool gpo list neuerUser - Uadministrator die Richtlinien anzeigen lassen will bekomme ich folgende Fehlermeldung:

ERROR(runtime): uncaught exception - Badly formed gPLink ’ ’
File “/usr/lib/python2.7/dist-packages/samba/netcmd/init.py”, line 175, in _run
return self.run(*args, **kwargs)
File “/usr/lib/python2.7/dist-packages/samba/netcmd/gpo.py”, line 386, in run
glist = parse_gplink(msg[‘gPLink’][0])
File “/usr/lib/python2.7/dist-packages/samba/netcmd/gpo.py”, line 95, in parse_gplink
raise RuntimeError(“Badly formed gPLink ‘%s’” % g)

Bei den ursprünglich angelegten Usern funktioniert alles einwandfrei.

Hat da jemand eine Idee.
setzten leider erst seit kurzem UCS ein und wir verzweifeln hier langasam.
LG Frank

Moin,

können Sie bitte mal die Ausgabe des folgenden Befehls posten:

univention-s4search samaccountname=neuerUser

Dabei den Loginnamen des gleichen Users eintragen, für den Sie das »samba-tool« aufrufen wollten.

Gruß,
mosu

Hallo
hier ist die Ausgabe

record 1

dn: CN=akquise3,OU=alleMA,DC=beispiel-un,DC=int
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: akquise3
sn: akquise3
instanceType: 4
whenCreated: 20160704210823.0Z
displayName: akquise3
uSNCreated: 5025
name: akquise3
objectGUID: a0c53f9b-4cc0-48ab-8138-3c5a24cbfe8a
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 0
lastLogoff: 0
primaryGroupID: 513
objectSid: S-1-5-21-3291827241-2335134631-3176151534-1150
accountExpires: 9223372036854775807
logonCount: 0
sAMAccountName: akquise3
sAMAccountType: 805306368
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=bespiel-un,DC=int
userAccountControl: 512
profilePath: \servername\freigaben\profile\akquise3
userPrincipalName: akquise3@BEISPIEL-UN.INT
pwdLastSet: 131121401010000000
lockoutTime: 0
memberOf: CN=group,CN=Groups,DC=beispiel-un,DC=int
memberOf: CN=desktop,CN=Groups,DC=beispiel-un,DC=int
lastLogonTimestamp: 131121859669309460
whenChanged: 20160705095246.0Z
uSNChanged: 5098
lastLogon: 131122668182842260
distinguishedName: CN=akquise3,OU=alleMA,DC=beispiel-un,DC=int

Referral

ref: ldap://beispiel-un.int/CN=Configuration … -un,DC=int

Referral

ref: ldap://beispiel-un.int/DC=DomainDnsZone … -un,DC=int

Referral

ref: ldap://beispiel-un.int/DC=ForestDnsZone … -un,DC=int

returned 4 records

1 entries

3 referrals

Habe nur den Domainnamen durch “Beispiel” ersetzt.

Könnte es sein das der Server ein Problem damit hat, dass ich die GPO’s direkt auf Domänenebene verknüpft habe.
Habe das in einer Testumgebung mal nachgestellt. Habe dort dann eine OU erstellt den User dort reingeschoben und eine von den GPO’s die ich auf der Domäne verknüpft habe mit der OU noch mal verknüpft.
Anschließend konnte dann der User sich die Gruppenrichlinie ziehen. Eigenartigerweise auch die übrigen GPO’s die direkt mit der Dömäne verknüpft sind.

Moin,

danke für die Ausgabe. Leider kann ich an ihr erst mal nichts Ungewöhnliches erkennen; ein Attribut »gPLink« hat dieser User schlicht nicht. Allerdings habe ich mir den Code noch mal angesehen — es muss nicht zwangsläufig der Link exakt dieses Users sein, der die Probleme verursacht, wenn ich das richtig verstehe.

Forschen Sie bitte ein wenig weiter nach. Zuerst mal durchsuchen Sie das komplette Samba4-LDAP, also bitte mal die Ausgabe posten von dem hier:

univention-s4search | ldapsearch-wrapper | grep -i gplink

Anschließend prüfen Sie bitte für alle Links, ob es die referenzierten Objekte wirklich gibt. Hier ein Beispiel aus unserem S4-LDAP. Zu dem Ergebnis aus dem vorherigen Befehl…

gPLink: [LDAP://CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=bs,DC=linet-services,DC=de;0]

…würde ich jetzt also das hier ausführen:

univention-s4search -s base -b 'CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=bs,DC=linet-services,DC=de' dn

Wenn dabei genau ein Objekt gefunden wird, so wie hier…

[code]# record 1
dn: CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=bs,DC=linet-services,DC=de

returned 1 records

1 entries

0 referrals[/code]

…so sollte dieser Link OK sein.

Das gPLink-Attribut kann auch mehrere solcher Links enthalten. Dann müssten Sie die Suche für all diese Links durchführen.

Eine direkte Verknüpfung auf Domänenebene sollte sehr wohl funktionieren; das nutzen wir auch, und auch Ihre Teststellung zeigt ja, dass es prinzipiell geht.

Gruß,
mosu

Erst mal herzliche Dank für Ihre Mühe

hier zunächst die aus Ausgabe:

root@dcmg:/# univention-s4search | ldapsearch-wrapper | grep -i gplink
gPLink:: IA==
gPLink: [LDAP://cn={8B48B98E-2B4F-49B8-BFE7-E60D33949EDF},cn=policies,cn=system,DC=kangaroo-mg,DC=int;0][LDAP://cn={3A612ED0-3A66-4825-87A2-D307AAE887EC},cn=policies,cn=system,DC=kangaroo-mg,DC=int;0][LDAP://cn={882623A2-30BE-44AB-82B8-D775237D2CFA},cn=policies,cn=system,DC=kangaroo-mg,DC=int;0][LDAP://cn={3B592B29-4CD4-432B-8748-68A56C55C6DD},cn=policies,cn=system,DC=kangaroo-mg,DC=int;0][LDAP://cn={5F89A9E6-3F74-4F09-9208-ABE584D0A36B},cn=policies,cn=system,DC=kangaroo-mg,DC=int;0][LDAP://cn={46BA7711-6A15-4394-ACFE-66C00743E8E1},cn=policies,cn=system,DC=kangaroo-mg,DC=int;0][LDAP://cn={2D9F29B8-6592-47C4-AE28-E4FC7AE459DD},cn=policies,cn=system,DC=kangaroo-mg,DC=int;0][LDAP://cn={C4C581AD-EB13-4136-A3A3-8000A21A28D3},cn=policies,cn=system,DC=kangaroo-mg,DC=int;0][LDAP://CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=kangaroo-mg,DC=int;0]
gPLink: [LDAP://CN={6AC1786C-016F-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=kangaroo-mg,DC=int;0]
gPLink:: IA==
gPLink:: IA==

Moin,

… gPLink:: IA== …

Diese Einträge sind’s wohl, die zumindest das »samba-tool« aus dem Tritt bringen. Denn der Code erwartet, dass jeder Link mit der Zeichenkette »[LDAP://« beginnt, und das ist bei diesen nicht der Fall.

Die zwei Doppelpunkte :: sagen, dass der folgende Inhalt (»IA==«) Base64-encodiert ist. Aber auch wenn man das wieder zurückwandelt (z.B. indem man das Tool »ldapsearch-decode64« in die Pipe mit einfügt), so ist klar, dass der Inhalt garantiert nicht mit »[LDAP://« anfangen kann.

Finden Sie doch mal heraus, bei welchen Objekten diese Attribute vorhanden sind, z.B. indem Sie »univention-s4search | ldapsearch-wrapper | less« ausführen und dann suchen. Die DNs der etroffenen Einträge (sind laut Ihrer Ausgabe genau drei) wären interessant.

Edit: Sie müssen natürlich »univention-s4search« nutzen, nicht »univention-ldapsearch«.

Gruß,
mosu

Hallo
also die referenzierten Objekte werden auch gefunden.
Habe mit samba-tool noch mal zwei Abfragen gemacht und folgende Fehler erhalten:

root@dcmg:~# samba-tool gpo aclcheck -k yes
Password for [administrator@KANGAROO-MG.INT]:
ERROR: Invalid GPO ACL O:LAG:DAD:P(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;EA)(A;OICIIO;0x001f01ff;;;CO)(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;SY)(A;OICI;0x001200a9;;;AU)(A;OICI;0x001200a9;;;ED) on path (kangaroo-mg.int\Policies{31B2F340-016D-11D2-945F-00C04FB984F9}), should be O:DAG:DAD:P(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;EA)(A;OICIIO;0x001f01ff;;;CO)(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;SY)(A;OICI;0x001200a9;;;AU)(A;OICI;0x001200a9;;;ED)

und nochmal:
root@dcmg:~# samba-tool ntacl sysvolcheck -k yes
ERROR(<class ‘samba.provision.ProvisioningError’>): uncaught exception - ProvisioningError: DB ACL on GPO directory /var/lib/samba/sysvol/kangaroo-mg.int/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9} O:LAG:DAD:P(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;EA)(A;OICIIO;0x001f01ff;;;CO)(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;SY)(A;OICI;0x001200a9;;;AU)(A;OICI;0x001200a9;;;ED) does not match expected value O:DAG:DAD:P(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;EA)(A;OICIIO;0x001f01ff;;;CO)(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;SY)(A;OICI;0x001200a9;;;AU)(A;OICI;0x001200a9;;;ED) from GPO object
File “/usr/lib/python2.7/dist-packages/samba/netcmd/init.py”, line 175, in _run
return self.run(*args, **kwargs)
File “/usr/lib/python2.7/dist-packages/samba/netcmd/ntacl.py”, line 249, in run
lp)
File “/usr/lib/python2.7/dist-packages/samba/provision/init.py”, line 1733, in checksysvolacl
direct_db_access)
File “/usr/lib/python2.7/dist-packages/samba/provision/init.py”, line 1684, in check_gpos_acl
domainsid, direct_db_access)
File “/usr/lib/python2.7/dist-packages/samba/provision/init.py”, line 1631, in check_dir_acl
raise ProvisioningError(’%s ACL on GPO directory %s %s does not match expected value %s from GPO object’ % (acl_type(direct_db_access), path, fsacl_sddl, acl))

Den letzten Fehler habe ich gestern auch auf einem frisch installertem Testserver erhalten auf dem ich noch keinerlei Konfiguration vorgenommen habe.
Dieser Fehler tritt anscheinend auf jedem unserer Sever auf. Könnte sein dies ein Bug ist?

Wir haben jetzt in mehrern Geschäftsstellen eine kleine UCS Domäne eingerichtet - immer ein Standalone Server als DC und dann 5 -10 Win 7 Rechner dran.
Also eigentlich nichts großartiges. Haben aber überall die gleichen Probleme.

  1. Wie hier schon beschrieben das die neuangelegten User sich die GPO’s nicht ziehen.
  2. Die Server gespeicherten Profile könne öfter nicht gezogen werden - sprich die Anmeldung dauert ewig.
  3. Die Datendatei von Outlook 2016 ist am laufendem Band beschädigt
    Wir sind uns jetzt unsicher ob das alles einzelne Probleme sind oder ob das alles doch irgendwie zusammen hängt.

Moin,

uff, Sie schmeißen hier ganz schön viele Probleme auf den Tisch. Bei ACL-Problemen immer erst mal die ACLs wiederherstellen lassen: »samba-tool ntacl sysvol-reset«.

Dass der Check auch auf einem frisch installierten System so einen Fehler wirft, scheint wohl bekannt zu sein.

Gruß,
mosu

Tschuldigung
aber erwarte bestimmt nicht das sie jetzt alle meine Probleme lösen . Bin ja echt froh das es Leute wie Sie gibt die sich überhaupt bereit erkären hier zu supporten.
nochmals vielen Dank dafür
samba-tool ntacl sysvolreset hatte ich schon durchgeführt aber hat nichts gebracht. Nach Abfrage mit samba-tool ntacl sysvolcheck kommen die gleichen Fehler.

LG

Moin,

ja, dieser Fehler taucht bei praktisch jedem UCS-System momentan auf, wobei mich das schon wundert. Das komplette Programm »samba-tool« ist ein Bestandteil von Samba selber und keine Univention-Eigenentwicklung. Somit sollte man davon ausgehen können, dass ein »sysvolreset« das auch wirklich tut und ein nachfolgender »sysvolcheck« keine Fehler mehr wirft.

Nun ja.

Ich möchte noch mal auf Ihr LDAP zurückkommen, weil ich glaube, dass »sysvolcheck« eine falsche Fährte ist. Bitte schauen Sie noch mal meinen Post hier genau durch, und suchen Sie diejenigen DNs heraus (und posten Sie sie hier), bei denen das Attribut »gPLink« eben nicht die Form »[LDAP://…]« hat. Denn die sollten so oder so nicht existieren.

Gruß,
mosu

Hallo
hier sind die Objekte:

record 67

dn: OU=KeyAccount,DC=kangaroo-mg,DC=int

objectClass: top

objectClass: organizationalUnit

ou: KeyAccount
instanceType: 4

whenCreated: 20160202132226.0Z

uSNCreated: 3950

name: KeyAccount

objectGUID: 1fce442d-6df8-4448-ba8f-ee50dd0a2ebd

objectCategory: CN=Organizational-Unit,CN=Schema,CN=Configuration,DC=kangaroo-mg,DC=int

gPLink:: IA==

whenChanged: 20160202150815.0Z

uSNChanged: 4050

distinguishedName: OU=KeyAccount,DC=kangaroo-mg,DC=int

record 184

dn: OU=AlleMA,DC=kangaroo-mg,DC=int

objectClass: top

objectClass: organizationalUnit

ou: AlleMA
instanceType: 4

whenCreated: 20160202151713.0Z

uSNCreated: 4052

name: AlleMA

objectGUID: bffd2624-0278-4c06-a764-4b50af052f0d

objectCategory: CN=Organizational-Unit,CN=Schema,CN=Configuration,DC=kangaroo-mg,DC=int

gPLink:: IA==
whenChanged: 20160216114404.0Z

uSNChanged: 4434

distinguishedName: OU=AlleMA,DC=kangaroo-mg,DC=int

record 244

dn: OU=alle Benutzer,DC=kangaroo-mg,DC=int
objectClass: top

objectClass: organizationalUnit

ou: alle Benutzer

instanceType: 4

whenCreated: 20160205073519.0Z
uSNCreated: 4274

name: alle Benutzer
objectGUID: c727535d-e4a5-472d-b3ad-5a1235cba7af

objectCategory: CN=Organizational-Unit,CN=Schema,CN=Configuration,DC=kangaroo-mg,DC=int

gPLink:: IA==
whenChanged: 20160210095225.0Z

uSNChanged: 4375
distinguishedName: OU=alle Benutzer,DC=kangaroo-mg,DC=int

Moin,

hmm, ich denke, Sie sollten diese gPLink-Attribute löschen und anschließend erneut versuchen, sich die ACLs des betroffenen Users anzeigen zu lassen (»samba-tool gpo list Username«).

Zum Entfernen kann das Tool »ldapmodify« mit einem entsprechenden LDIF genutzt werden. Nach Ihren Suchergebnissen sollte die angehängte LDIF funktionieren. Zuerst sollten Sie das Einspielen mit folgendem Befehl testen:

ldapmodify -n -h $(ucr get ldap/master) -p $(ucr get ldap/master/port) -D $(ucr get ldap/hostdn) -y /etc/machine.secret -f remove-bad-gplinks.ldif

Das testet das Ganze insofern, als dass es die Datei einmal liest und auf Syntaxfehler prüft. Es führt aber noch keine Änderung durch. Die Ausgabe sollte so aussehen:

[code]!modifying entry “OU=KeyAccount,DC=kangaroo-mg,DC=int”

!modifying entry “OU=AlleMA,DC=kangaroo-mg,DC=int”

!modifying entry “OU=alle Benutzer,DC=kangaroo-mg,DC=int”
[/code]

Anschließend führen Sie die Änderungen wie folgt durch:

ldapmodify -h $(ucr get ldap/master) -p $(ucr get ldap/master/port) -D $(ucr get ldap/hostdn) -y /etc/machine.secret -f remove-bad-gplinks.ldif

Gleicher Befehl wie vorher, nur ohne die Option »-n«.

Zu guter Letzt probieren Sie das Auflisten der GPOs für den User aus.

Gruß,
mosu
remove-bad-gplinks.ldif (271 Bytes)

muss leider nochmal doof nachfragen.
Die ldif- datei muss ich wohin kopieren?

guten Morgen;

habe sie direkt ins /etc Verzeichnis kopiert hoffe das es richtig war
erste Ausgabe nach Testlauf:
!modifying entry “OU=KeyAccount,DC=kangaroo-mg,DC=int”

!modifying entry “OU=AlleMA,DC=kangaroo-mg,DC=int”

!modifying entry “OU=alle Benutzer,DC=kangaroo-mg,DC=int”

Anzeige nach zweitem Befehl :

modifying entry “OU=KeyAccount,DC=kangaroo-mg,DC=int”
ldap_modify: Undefined attribute type (17)
additional info: gPLink: attribute type undefined

Moin,

oops, my bad. Mit dem von mir geposteten Befehl würde die Änderung gegen das OpenLDAP durchgeführt, sie muss aber gegen das Samba4-LDAP durchgeführt werden. Bitte führen Sie daher den folgenden Befehl aus:

ldbmodify -H /var/lib/samba/private/sam.ldb remove-bad-gplinks.ldif

Ja, der Ort, wo die Datei auf dem Server liegt, ist egal, da sie nur einmalig vom angegebenen Befehl (»ldbmodify«) eingelesen und danach nicht mehr benötigt wird. Sie müssen nur beim Befehl den Pfad zur Datei richtig angeben, sofern sie nicht im aktuellen Verzeichnis liegen sollte.

Gruß,
mosu

super vielen Dank

in einer anderen Niederlassung habe ich nur einen gplink der ins leere läuft.

record 249

dn: OU=alleMA,DC=kangaroo-un,DC=int
objectClass: top
objectClass: organizationalUnit
ou: alleMA
instanceType: 4
whenCreated: 20160705090953.0Z
uSNCreated: 5081
name: alleMA
objectGUID: 8ca906eb-2030-4d5b-903c-3bc62cc66ff0
objectCategory: CN=Organizational-Unit,CN=Schema,CN=Configuration,DC=kangaroo-un,DC=int
gPOptions: 0
gPLink:: IA==
whenChanged: 20160706081029.0Z
uSNChanged: 5165
distinguishedName: OU=alleMA,DC=kangaroo-un,DC=int

müsste die entsprechende ldif-datei dann so aussehen?

dn: OU=OU=alleMA,DC=kangaroo-un,DC=intchangetype: modifydelete: gPLinkgPLink:: IA==-dn:

Ist gerade sehr schwer zu lesen, da das Forum Zeilenumbrüche ignoriert. Bitte stecken Sie solche Sachen in Code-Tags, also [ code ]Inhalt[/ code ] (ohne die Leerzeichen nach und vor den eckigen Klammern). Dann kann man das deutlich besser erkennen.

Generell: aus der von mir erzeugten LDIF einfach nur den ersten der drei Blöcke behalten und dort die DN ersetzen.

ok vielen lieben Dank

dn: OU=alleMA,DC=kangaroo-un,DC=intchangetype: modifydelete: gPLinkgPLink:: IA==-dn:

Da fehlen jetzt Zeilenumbrüche :slight_smile:

Falls Sie sich meine .ldif-Datei in einem Editor ansehen: nutzen Sie auf keinen Fall das Notepad von Windows, das kann mit Unix-Zeilenumbrüchen nicht umgehen und zeigt alles in einer Zeile! Nutzen Sie statt dessen z.B. das hervorragende Open-Source-Tool Notepad++.

Oh Mann ich werde hier noch verrückt.
gerade rief mich eine user an das er jetzt mehrfach versucht hat den Rechner zu starten aber er zieht sich das Roamin Profile nicht.
bin dann runter hab mich dann an der Kiste als domain admin angmeldet( ohne roaming profil) dann wieder als User - hat bisehr immer funktioniert.
wieder nichts.
in der Ereignisanzeige finde ich die Fehler ID 7001, 7320, 7017.

kann das was mit den gerade gelöschten gplinks zu tun haben.

Mastodon