Planung einer Zertifizierungshierarchie / Best Practice

[fsinani]

Hallo liebe Kollegen,

ich habe die verantwortungsvolle Aufgaben angenommen, eine Zertifizeirungshierarchie für unser unternehmen zu planen, da unsere bisherige eher mäßig überschaubar und nicht ganz leicht zu administrieren ist.

Um mir mal von Euch Profis ein paar Ideen zu holen, wie Ihr das so macht, habe ich gehofft, im BestPractice fündig zu werden. Leider gibt es dort nichts.

Habt Ihr eine Idee, wo man hierzu etwas finden kann?

Der Aufbau der Zertifiziererhierarchie sollte am Ende mit dem "/Firma" enden, so dass keine Querzulassungen notwendig werden. Der Rest sollte dann nur noch mit OUs gesteuert werden. Spräche da etwas aus Eurer Sicht dagegen? Verbaut man sich dadurch etwas?

Vielen Dank

[Tode]

Schon mal ein guter Ansatz. Weiterer Tipp: verzettle Dich nicht zu sehr mit den ous...jed mehr Du erstellst, desto häufiger musst Du die User rezertifizieren (User wechselt in eine andere Abteilung, oder User geht an einen anderen Standort (je nachdem wie du das aufbaust,)
Wenn ihr also nicht mehrere tausend user habt, dann würde ich mich mit maximal einer Ebene begnügen... Und selbst die würde ich nochnin Frage stellen.....
Im endeffekt geht es imho um drei Dinge bei der Erstellung der ous:
1. eindeutigkeit von Namen sicherstellen (wobei Du dann für die mailadressen trotzdem wieder eine Regelung bei doppelten Namen haben musst)
2. Administrierbarkeit erhöhen (admins bekommen Rechte für die Administration bestimmter ous)
3. Richtlinien (lassen sich auf diese Art schn hierarchisch zuordnen ohne manuellen Aufwand

Wenn das bei Euch alles nicht passt, würde ich absolut flach arbeiten (ganz ohne ous, oder mit nur wenigen spezial- ous)

Aber am besten lässt Du dich natürlich von einem erfahrenen Consultant beraten, denn sicher gibt es in Eurer Umgebung noch ganz andere Dinge zu beachten... Und wenn Ihrs schon mal "verbockt" habt, sollte das evtl. Nicht ein zweites Mal passieren ;-)

[fsinani]

Danke Tode,

genau das hab ich auch überlegt.
Wir haben weltweit ca. 4500 User. Dennoch sollten wir uns darauf beschränken, so wenig wie möglich und nur so viel wie nötig OUs einzusetzen.

Ich habe auch schon einmal daran gedacht, folgende OUs zu verwenden:

/emea/comp; /amer/comp; /apac/comp.

Das würde mir am Besten gefallen, jedoch sind bei uns in DE die meisten Mitarbeiter. Die Namensgleichheit würde also am Wahrscheinlichsten in /emea/comp.

Nach Abteilungen würde ich nicht machen wollen, da, wie Du schon sagst, häufige Wechsel zwischen den Abteilungen passieren.
Auch eine Trennung nach Ländern gefällt mir nicht so sehr, da wir Richtlinien eher auf Abteilungen pflegen. Das würde dann bedeuten, dass wir eine Richtlinie auf mehrere OUs ausrollen müssen, nur weil eine Abteilung (z.B. HR) in jedem Land vorkommt.

Andererseits haben wir Länderadmins. Da wäre die Aufteilung nach Ländern gerade richtig.

Ach man - das ist voll ätzend :-)

[Peter S.]

Die erste Überlegung gilt immer dem Zweck der Zulassungshierarchie.
Dient sie nur einer informellen Strukturierung für die Mitarbeiter?
Soll sie eine verteilte Administration unter Einhaltung von sicherheitstechnischen Abgrenzungen unterstützen?
Soll sie Namensdoubletten vermeiden?
Soll sie in Form von Wildcards zur Zugriffsteuerung genutzt werden?

Aus der Betrachtung und Bewertung obiger Fragen ergibt sich schon eine entsprechende Hierarchie.

Aber generell gilt:
Man kann Namensdoubletten mit dem Eintrag "Abteilung" vermeiden, das ist dann keine OU sondern ein Namensbestandteil.

Außerdem sehr genau darauf achten das man entweder "Country" (also z.B. /DE ) mitnutzt oder bei der "O" zwingend mindestens drei Buchstaben hat.
Ich habe zwar lange keine "O"s mehr gerechnet, aber ich weiß das es in älteren Notes Versionen möglich war "O"s mit zwei Buchstaben anzulegen.
Die wurden allerdings nachher von Domino als "C"s interpretiert. Mit lustigen Nebeneffekten bei der ersten Querzulassung.

Ansonsten hat es sich bewährt folgende OUs einzurichten

/adm(in)/firma = für Admin-IDs - wenn Administratoren mit zwei IDs arbeiten (Was sie tun sollten) - dann kann man in Zugriffsgruppen für Systemdatenbanken eine Wildcard benutzen

/srv/firma = alle Server eines Unternehmens - um per Wildcard oder Querzulassungen direkt User vom Serverzugriff auszuschließen

/sys(tem)/firma = für Signatur IDs zum Signieren von Templates

/tec/firma = für technische User z.B. Faxserver, Gateways, etc.

Wenn man automatisierte Benutzerverwaltungen einsetzt und mehrere Internetadressen, z.B. pro Location/Tochterfirma/Land, hat ist man ggf besser dran tatsächlich OUs zur Differenzierung der Internetmailadressen einzusetzen.
Damit ist es dann leichter aus der Zulassungshierarchie die korrekte zu vergebende Internetdomäne zu bestimmen.

[fsinani]

Danke Peter S. für die Tipps!

Das sind gute Hinweise. Ich habe auch schon daran gedacht, zumindest die Server in eine eigene OU zu stecken.

Aber vor allem finde ich die Fragen gut - anhand derer man in einer Gruppe gemeinsam entscheiden kann, welche Hierarchie für uns in Frage käme.

Vielen Dank