Verschiedene Benutzerstämme nach LDAP kopieren?

[Mag 11]

Hallo allerseits,

 

in meinem Unternehmen hier, steht es gerade zur Debatte eine zentrale Userverwaltung einzuführen um die verschiedensten Subsysteme später auch vielleicht mit einer SingleSignOn Lösung zu benutzen.

 

Nun sieht es in der PRaxis so aus, dass wir z.B. einen AD Benutzerstamm sowie einen im SAP haben. Nun kann man beispielsweise die Benutzer aus dem SAP einmalig nach LDAP kopieren um eine Grundlage zu haben. Später erfolgt der abgleich ja nur noch in die andere Richtung, dass im LDAP angelegt wird und die Subsysteme darauf zugreifen.

 

Wenn ich soweit richtig liege, andernfalls korrigiert mich bitte.

 

Wie kann ich nun den Benutzerpool aus dem AD damit verknüpfen? So weiß das LDAP ja nicht welche Benutzer aus SAP und AD wirklich zusammen gehören?!?!

 

Kann mir da jemand mal auf die Sprünge helfen, ich arbeite mich zur Zeit noch in das Thema ein.

[hekmek 10]

Hallo Mag,

 

eine Verknüpfung findet nicht statt. Wir sind jedenfalls auch dabei so etwas zu implementieren aber das funktioniert, soweit ich weiß, etwas anders. Wir haben eine zentrale DB, die über LDAP angesprochen wird, dort werden alle Anwender eingepflegt, die in das Unternehmen kommen oder gehen(ist gleichzeit unsere int. Telefonliste). Diese DB ist über sogenannte Konnektoren an die verschiedenen Verzeichnisdienste (SAP,Notes,ADS,Novell...) gekoppelt. Findet jetzt eine Änderung statt, so wird es von der zentralen DB in die verschiedenen System repliziert. Es findet also keine Verknüpfung statt, sondern das, was ma sonst manuell machen würde, wird automatisiert. Welche Attribute wann und wie beeinflusst werden muss natürlich vorher alles mühselig eingestellt werden. Wir nutzten eine Lösung von Novell (Nsure Identity Manager), es gibt aber auch noch andere Anbieter z.B. MS bietet dem MIIS an.

[Mag 11]

Danke für die schnelle Antwort.

Ja es gibt da die vielfältigsten Systeme, bishn zu komplexen System von Siemens in denen alles hübsch automatisiert abläuft mit wenigen Clicks.

 

Das mit der Telefonliste etc, haben wir so auch vor.

 

Mein Problem an der Sache ist eher der Start des Systems. Denn wir legen ja nun nicht alle Benutzer neu an, es gibt ja schon einige Tausend und wie ich der zentralen DB beibringe dass die diversen Benutzer aus Stamm A und B zusammen gehören ist mir noch nicht so klar.

[Zearom 10]

Mein Problem an der Sache ist eher der Start des Systems. Denn wir legen ja nun nicht alle Benutzer neu an, es gibt ja schon einige Tausend und wie ich der zentralen DB beibringe dass die diversen Benutzer aus Stamm A und B zusammen gehören ist mir noch nicht so klar.

da die User in deinem AD (oder adam etc) bereits existieren musst du natürlich in deiner Datenbank erst mal ein urladen machen. Danach hast du ja alle AD-Accounts in deiner Datenbank. Schliesst man dann noch andere Datenbanken an (telefon, OrganisationsDatenbanken etc etc) kann man meistens auch andere Datenbanken vervollständigen weil nun die Datenzentralisiert zur Verfügung stehen. Zusammengeführt werden verschiedene Datenstämme über Key-Fehler wie die Personalnummer, oder der sAMAccountname. Kommt halt drauf an wie eure Info-DBs aufgebaut sind.

 

 

Wir machen dieses Theater auch gerade mit, wir haben hier eine große SAP-DB mit allen infos, die AD-Infos werden in diese Datenbank einmalig urgeladen und anschliessend via MIIS synchronisiert. Natürlich muss die IT die Userdaten nichtmehr im AD-Direkt herumwerkeln sondern in deiner Datenbank (und das bring mal einem SysAdmin bei...).

 

wenn man noch etwas .Net.KnowHow im Unternehmen hat ist der MIIS ein ziemlich flexibles Werkzeug. nur mal so als kleine Tip von uns.

 

nachtrag:

12:46h hab den Text etwas überarbeiten müssen.

[BuzzeR 10]

Hallo zusammen.

 

Man muß sich vor Augen führen, daß OpenLDAP, AD, NDS, ... nur Verzeichnisdienste (DS)

sind, denen ein Schema zugrunde liegt und dieses Schema ist nicht statisch, sondern

kann sehr wohl geändert werden. Man kann so ziemlich alles in seinem DS verwalten und

wenn es Rezepte für Cocktails sind.

 

Unter Windows Server 2003 geht das zum Beispiel so:

 

• Eingabeaufforderung -> regsvr32 schmmgmt.dll
  
• mmc /a
  
• Datei -> SnapIn hinzufügen/entfernen -> Hinzufügen -> Active Directory Schema
  
• Schließen -> OK
  
• Active Directory Schema -> Attribute (rechtklick) -> Neu -> Attribut ...
  
• Active Directory Schema -> Klassen -> user -> Eigenschaften -> Attribute -> hinzufügen
  

 

Ich kann also in meinem DS zum Beispiel die Zugangsdaten zu einer Applikation xy

speichern auf die ich mich dann später mit diesen Daten einloggen könnte. Es müßen

also nicht unbedingt weitere Systeme, oder Connectoren sein, wobei dies natürlich

von dem jeweiligen Fall abhängt.

 

Zum angegebenen Szenario SAP kann ich nichts sagen, da ich mich mit SAP ungefähr

so gut auskenne, wie eine Kuh Ahnung vom fliegen hat. :D ;)

 

LG

Marco

[Mag 11]

Ooooohja richtig,

 

Ein gemeinsames Feld, wie die Personalnummer wird wohl die Lösung sein, wobei ich dass dann noch in der AD mühsam pflegen müsste. Denn AD Benutzer gibt es, dank des tollen Forest und lokaler Admins, wie Sand am Meer:D