Univention Bugzilla – Bug 23561
extended attributes ändern immer die (Reihenfolge von) objectClass
Last modified: 2012-12-12 21:10:04 CET
Bei einer Umgebung mit extended Attributes an computers/windows fiel auf, dass eine einfache Änderung (hier: univentionWindowsReinstall) immer auch einer Änderung des Attributs objectClass generiert, dabei wird nur die Reihenfolge verändert. Das verhindert die Definition von restriktiven LDAP-ACLs. Wahrscheinlich sind alle UDM-Module betroffen. Beispiel: # diff testw01_initial.ldif testw01_reinstall.ldif 12,17d11 < objectClass: top < objectClass: univentionHost < objectClass: univentionWindows < objectClass: posixAccount < objectClass: person < objectClass: sambaSamAccount 25a20,26 > univentionWindowsReinstall: 1 > objectClass: top > objectClass: univentionHost > objectClass: sambaSamAccount > objectClass: person > objectClass: univentionWindows > objectClass: posixAccount
Aufgefallen an Ticket 2011050910005547
UCS 3.1 will be the next release.
Nach Rücksprache mit Kevin tritt das Problem auf, wenn zwei Extended Attributes gesetzt werden. Ich konnte es aber bisher nicht reproduzieren: DN: cn=test1,cn=custom attributes,cn=univention,dc=deadlock5,dc=local ARG: None objectClass: univentionFreeAttributes groupPosition: None module: computers/windows overwritePosition: None hook: None overwriteTab: 0 shortDescription: test1 groupName: None version: 2 valueRequired: 0 CLIName: test1 fullWidth: 0 longDescription: Test1 doNotSearch: 0 tabName: Test1 syntax: string tabAdvanced: 0 name: test1 default: None mayChange: 1 multivalue: 0 ldapMapping: univentionFreeAttribute1 deleteObjectClass: 0 notEditable: 0 options: None tabPosition: 1 disableUDMWeb: 0 DN: cn=test2,cn=custom attributes,cn=univention,dc=deadlock5,dc=local ARG: None objectClass: univentionFreeAttributes groupPosition: None module: computers/windows overwritePosition: None hook: None overwriteTab: 0 shortDescription: test2 groupName: None version: 2 valueRequired: 0 CLIName: test2 fullWidth: 0 longDescription: Test2 doNotSearch: 0 tabName: Test2 syntax: string tabAdvanced: 0 name: test2 default: None mayChange: 1 multivalue: 0 ldapMapping: univentionFreeAttribute2 deleteObjectClass: 0 notEditable: 0 options: None tabPosition: 1 disableUDMWeb: 0 Ich habe dann einen Windows Rechner angelegt und dort die beiden Attribute gesetzt. Vor die "access to *" Regel habe ich folgendes eingefügt: access to dn="cn=win1,cn=computers,dc=deadlock5,dc=local" attrs=univentionOperatingSystemVersion by dn.base="cn=admin,dc=deadlock5,dc=local" write by dn.base="uid=Administrator,cn=users,dc=deadlock5,dc=local" write access to dn="cn=win1,cn=computers,dc=deadlock5,dc=local" by dn.base="cn=admin,dc=deadlock5,dc=local" write by dn.base="uid=Administrator,cn=users,dc=deadlock5,dc=local" read Dadurch kann Administrator nur noch das Attribut univentionOperatingSystemVersion ändern. Das funktioniert über den UDM problemlos. Auch wenn Administrator zusätzlich noch univentionFreeAttribute2 ändern darf geht das ohne Probleme.
Konnte das Problem ebenfalls nicht nachstellen. Getestet wurde mit 2 Extended Attributes mit unterschiedlichen Attributen und Objektklassen. Die Objektklassen "univentionFreeAttributes" und "univentionTestAttributes" sind nicht Bestandteil des Objektes gewesen. Die Checkbox "Objektklasse löschen" hat keine Auswirkungen auf das Verhalten gezeigt. Das Setzen eines oder beider ExtAttributes oder eines anderen Werts hat die Objektklasse nicht beeinflusst. Dies wurde durch zusätzliche LDAP-ACLs verifiziert. Changelogeintrag nicht notwendig → Verified
UCS 3.1-0 has been released: http://forum.univention.de/viewtopic.php?f=54&t=2125 If this error occurs again, please use "Clone This Bug".