ef8619
Goto Top

Active Directory, Open Directory für Apple Umgebung

Hallo liebes Forum,

wir sind ein kleines 8 Mann Unternehmen und bis auf eine Person besitzt jeder 2 OS X Geräte und 2 iOS Geräte. Die bereits genannte Person besitzt ein Windows Notebook und 2 iOS Geräte. Zusätzlich haben wir noch einen Apple xServe, auf dem zu Testzwecken Windows Maschinen unter Parallels Desktop virtualisiert werden.

Nun ist es leider so, dass, als ich in die Firma gekommen bin, keine zentrale User Verwaltung eingerichtet war. Das heisst, jeder User muss separat verwaltet werden und es gibt für die etlichen Login Möglichkeiten die man so hat (Websites, Applikationen usw.) stets einzelne Login-Daten. Administrativ ist das alles andere als vorteilhaft.

Welche Lösung müssen wir einsetzen um das Szenario zu unserem Vorteil zu verändern? Ich habe in einem Artikel etwas von einem magischen Dreieck gelesen. Da geht es um den Einsatz von Active Directory, Open Directory und OS X Server. Diese 3 Sachen stehen uns ja auch zur Verfügung (Active Directory mit einer virtualisierten Windows Server 2012 VM), die aber wiederum auf dem xServe läuft (Redundanz ist da garnicht da).

Zudem haben wir bei unseren eingesetzten Produkten (z.B. Office 365) oft die Möglichkeit mithilfe von Verzeichnissynchronisationstools die Verzeichnisse aus einem AD Server in die Cloud Datenbank zu schieben (so wie ich das verstanden habe).

Habt ihr hierzu vielleicht ein paar gute Ratschläge?

Content-Key: 226029

Url: https://administrator.de/contentid/226029

Printed on: April 16, 2024 at 06:04 o'clock

Member: quin83
quin83 Jan 07, 2014 at 18:31:10 (UTC)
Goto Top
Hallo,

OS X Server
bitte beachte dabei, dass der Server immer die neueste Version aller Apple Produkte haben muss (sollte ?), sonst verhalten sich die Clients unberechenbar.
(Steht in einem Apple Deployment Guide, Link finde ich gerade leider nicht...)
Meiner Erfahrung nach hat jedoch jede der letzten Versionen diverse Macken gehabt (Dienste starten nicht, beenden sich grundlos, etc.), so dass ich von einem Einsatz in einer Firma abraten würde.

Ich würde ein normales MS Active Directory nehmen.
Hier gibt es die meisten Ressourcen im Netz wenn mal was klemmt und es funktioniert bei uns absolut einwandfrei.

Grundsätzlich würde ich immer empfehlen, eine Redundanz zu haben.
Lieber 2 kleine Pizzableche, als ein großes.
Unabhängig davon, welcher Dienst drauf läuft...

Grüße,

Daniel
Member: aqui
aqui Jan 08, 2014 updated at 12:10:35 (UTC)
Goto Top
Gehört ja eigentlich in die Forumsrubrik "Apple"....aber egal...
Das obige stimmt de facto nicht. Ein Mountain Lion Server kann problemlos Maverick Clients verwalten und umgekehrt. Das wäre ja auch fatal wenn es nicht so wäre.
Stelle dir mal vor Winblows 2003 oder 2008 könnte nur XP Clients bedienen. Unsinn....also gleich vergessen.
Genauso wie mit einem völlig OS fremden Winblows Active Directory da rumzufummeln. Muss ja nicht sein da du gar keine Windows Gurken in dem Netzwerk hast...warum also den sehr teuren Aufwand der rein gar nichts bringt !

Da du aber ein reinrassiges OS-X Umfeld hast macht es ja Sinn simple 20 Euro in die Server App zu investieren (z.B. auf einem Mac mini) und ein gemanagtes Umfeld aufzubauen. Das ist unter OS-X Server schnell und einfach erledigt.
Dieses sehr gute Tutorial der ct' beschreibt dir ganz genau was du dazu zu machen hast:
https://www.heise.de/artikel-archiv/ct/2013/09/170_Gemeinsam-statt-einsa ...
...und Winblows Endgeräte kann man logischerweise auch einbeziehen.
Member: ef8619
ef8619 Jan 09, 2014 at 13:45:08 (UTC)
Goto Top
Hallo aqui,

das klingt für mich auch am logischsten. Allerdings unterstützen doch viele Cloud Anwendungen wie z.B. Office 365 kein OpenDirectory und ich habe wieder hohen Aufwand, da pro Benutzer pro Anwendung andere Zugangsdaten usw. anfallen.
Member: quin83
quin83 Jan 09, 2014 at 21:56:31 (UTC)
Goto Top
Hallo,

Das obige stimmt de facto nicht. Ein Mountain Lion Server kann problemlos Maverick Clients verwalten und umgekehrt.
Ich habe nicht gesagt, dass es nicht geht. Ich sagte "es verhält sich unberechenbar".
Wir haben in der Firma den OS X Server evaluiert und hatten bereits serverseitig diverse Stabilitäts-Probleme.
Damit sind wir wohl nicht allein, auch die Rezessionen im Apple Store beschreiben diese Probleme.
Das Thema wurde dann nicht weiter verfolgt.
Von anderen Firmen habe ich gehört, dass es auch dort zu Problemen kam, als iOS 7 und auch 10.9 ausgerollt wurde.

da du gar keine Windows Gurken in dem Netzwerk hast.
Hat er aber:
- Windows Client vorhanden
- Windows Testsysteme vorhanden
- Über den Einsatz weiterer Microsoft-Produkte wird anscheinend nachgedacht...

Allerdings unterstützen doch viele Cloud Anwendungen wie z.B. Office 365 kein OpenDirectory
Na ja, zentral für alle Cloud Anwendungen kann man das so nicht sagen.
Im Prinzip ist ein Active Directory eine Kombination aus einem LDAP Verzeichnis und einem DNS mit einigen Extras von Microsoft.

Die meisten Web- oder Cloud-Anwendungen (wie z.B. Wiki-Systeme, Collaboration-Systeme, Bugtracker, usw...), welche man meist an die Benutzerdatenbank anbinden möchte, verwenden meist (nicht immer!) eine einfache LDAP Anfrage.
Diesen Systemen ist es dann egal, ob da dann ein Active Directory, Open Directory oder einfach nur ein openLDAP Server steht.
Ich habe schon viele Produkte gesehen, welche auf der Webseite immer nur Active Directory schreiben (weils jeder kennt), aber dann einfach nur LDAP machen.

Anders sieht es bei Anwendungen aus dem Hause Microsoft, wie z.B. Microsoft Exchange (E-Mail), Microsoft SharePoint (Collaboration), Microsoft Lync (Kommunikation) oder Microsoft Office 365 aus.
Ich kenne zwar das neue Office nicht, aber ich kann dir sagen, dass Exchange, SharePoint und Lync einen Active Directory Zugriff benötigen, da dort bei der Installation das Schema entsprechend erweitert wird.
Vielleicht gibt es Möglichkeiten, das zu verbiegen und trotzdem zu betreiben... am Ende weint dann meist jemand.

Eine pauschale Aussage ist hier also nicht möglich.
Hier solltest du die Systemanforderungen der Produkte prüfen, welche du einsetzen möchtest.

Grüße,

Daniel