Jump to content
Melde dich an, um diesen Inhalt zu abonnieren  
chromaker

AD Konzept für neues AD / SSO

Empfohlene Beiträge

Hallo zusammen,

 

ich würde gerne in Erfahrung bringen ob ihr ggfs. sinnvolle Vorschläge habt um das Neu-Einrichten eines AD im Falle unserer Situation.

 

- Aktuell haben wir eine lokale Domäne mit User Verzeichnis auf einem Samba inkl. ldap laufen. Userlogins finden hauptsächlich aufs Linux Filesystem statt oder unsere Webanwendungen wie Ticketsystem, gitlab..

- Alle unsere User haben ein Office 365 Konto mit Business Premium

- Alle User mit Win10 Notebooks, 1-3 Linux / Mac User.

 

Nun würden wir gerne die User logins generell vereinfachen am liebsten mit SSO und evtl der Möglichkeit nach her mit 2FA "auf zu werten". Dabei hauptsächlich auf die Office 365 Accounts als "Haupt Login" zu setzen.

 

 

Eine meiner Ideen war auf Azure AD zu setzen und zunächst ohne einem lokalen AD. 

Dabei hatte z.B. bei meinem Testgerät mit einem Office 365 User lokal unter Windows 10 (nachdem ich die Einrichtung unter Win10 mit dem Organisationprofil und Azure Konto abgeschlossen habe) div. Probleme wie dass mir unter Win10 ein tatsächlich lokales Konto gefehlt hat für z.B. die Installation/Einrichtung von "Docker for Windows" oder beim Verbinden von Netzlaufwerken welche ja noch aktuell das alte Samba-Ldap nutzen.

Die beiden Probleme hängen evtl nicht zwingend mit einander zusammen, aber dass mir ein lokales Windows Konto fehlt und durch Azure hierbei Nachteile habe, könnte in Zukunft ja noch weitere Probleme bereiten.

 

Eine weitere Idee war auf Azure Connect zu setzen und einen neuen lokalen AD zu installieren bspw 2012R2 oder 2016 und dies mit Azure AD zu syncen. Hier wäre dann vermutlich meine lokale Domäne die "Hauptdomäne" auch was die Einrichtung der Windows Clients angeht.

Nur vor der Migration vom lokalen Win Account zu dem Domänen Account graust es mir. Sowie die Handhabung von Home-Office Gängern, dass da nicht alles reibungslos klappt.

 

Oder anstelle von einem lokalen Windows Server absehen und auf eine Linux Lösung setzen wie freeIPA. Auch wenn sich linux und MS näher kommen, könnte ich mir da einige Hürden vorstellen.

 

Wie löst ihr derartiges? Setzt ihr auf SSO?

 

Vielen Dank und viele Grüße,

chrom

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Moin,

 

an der Stelle wäre zuvörderst zu klären, was du mit "SSO" meinst. Zu dem Thema haben zehn Leute üblicherweise elf differierende Auffassungen.

Dann wäre natürlich relevant, wie groß die Umgebung ist und welche allgemeinen Anforderungen bestehen.

 

Alles Dinge, die man in einem Forum erfahrungsgemäß nicht gut klären kann. Zur Illustration mein Lieblingsvergleich: Deine Frage ist ähnlich wie "Ich hätte gern ein Fahrzeug, was würdet ihr empfehlen?".

 

Gruß, Nils

 

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Stimmt Türgriffe wollte ich auch :D

 

Habt da natürlich recht, deshalb fasse ich so einmal zusammen:
 

Auf der Client Seite ist unsere Umgebung ~30 Clients/Mitarbeiter groß.
Auf der anderen Seite haben wir um die zehn Services welche wir aktuell über unseren samba ldap verwenden wie Gitlab, Jenkins, Ticketsystem redmine, Graylog, älteren Development Server, File Server, Groupware, Intranet, Extranet

 

Also unsere Anforderungen lauten:


Single-Sign-On soll die Nutzerfreundlichkeit verbessern, sowohl für den User als auch Administrator
 - die Passwort Änderung soll auf einer zentralen Ebene geschehen
 - 2fa / Mehr-Faktor Authentifizierung soll in jedem Fall möglich sein
 - mit Sicherheit lassen sich nicht alle Anwendungen so einbinden, doch zumindest die wesentlichen und aktuellen wie: File Server (wird nachdem AD entsprechend angepasst bzw. auf etwas gesetzt was kompatibel ist), Gitlab, Ticketsystem, Graylog, Intranet/Extranet, WLAN und ggfs. Synology für Client-Backups
   Damit sind haben wir einige Web-Anwendungen intern als auch extern. Mobile Anwendungen in Zukunft nicht.
 - Self-Service also das eigenständige Passwortrücksetzen wäre wünschenswert

 

 

Die Clients selbst sollen durch die Domäne nicht stark eingeschränkt werden:
 - durch Gruppen via AD sollen hauptsächlich die Zugriffe für die User vergeben/beschränkt werden können
 - es sind großteils Entwicklicker die in der Installation von Anwendungen nicht eingeschränkt werden sollen
 - Gruppenrichtlinien sind weniger gefordert bzw hatten wir bislang nicht "vermisst"

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte überlege Dir, ob es nicht sinnvoller ist ein neues Thema zu erstellen.

Erstelle ein Benutzerkonto oder melde dich an, um zu kommentieren

Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!

Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde dich hier an.

Jetzt anmelden
Melde dich an, um diesen Inhalt zu abonnieren  

×