Jump to content

4zap

Members
  • Gesamte Inhalte

    296
  • Registriert seit

  • Letzter Besuch

Reputation in der Community

13 Neutral

1 Benutzer folgt diesem Benutzer

Über 4zap

  • Rang
    Member
  1. Ist doch gar nicht Montag heute...anstatt des Thumbprints nimmt man besser den öffentlichen Schlüssel... ich Hasenhirn. Falls der Fehler mit dem Zertifikatsnamen auftaucht muss es nicht unbedingt daran liegen. Es geht jetzt....cer als base64 x509 exportieren, mit Textdatei öffnen, der Öffentlichen Schlüssel rauskopieren und in die Spalte public certificate data eintragen.
  2. Moin, ich hab ihm Azure ein neues ARM Vnet aufgespannt mit Vnet Gatway. Dort versuche ich die point2site Verbindung einzurichten mit einem selbstsignierten Zertifikat. Vor drei Jahren hab ich im alten classic model die fast identische Konfig ausgerollt. Wenn ich im Azure portal da rein schaue sehe ich den zertifikatsnamen mit "CN=FIRMA-ENT-CA,corp,DC=fima,DC=com" in der alten classic Verbindung. Irgendwie hab ich es damals über Powershell geschafft das RootCer für die p2s Verbindung ins azure zu laden. Ich will ja nur den NAmen und den Thumbprint ins Azure schreiben, jedoch erhalten ich beim Zertifikatsnamen einen Error. Zertifikatsname ist nicht gülitg.... Egal wie ich den Namen setzen will, azure nimmts nicht. Das Zerti ist ausgestellt für: FIRMA-ENT-CA, so steht es auch auf dem Zertifikat. Weder die CN Schreibweise noch den reinen String vom Zertifikatsnamen wird akzeptiert. Ich weiß das ich damals auch Ärger hatte das zu integrieren und ich weiß nicht mehr genau wie ich es geschafft habe. Ich versuchs nochmal das Zertifikat über PS ins Azure zu laden aber eigentlich ist das schon vorhanden im Zertifikatsspeicher, es würde reichen Thumbprint und NAme zu definieren. Hat von euch jemand noch einen Tipp? Google Workarounds haben nicht geholfen und ich erinner mich nicht mehr wie es damals hingekriegt hab. :( ah ich sehe in der Doku im alten Portal gabs einen Button zum Upload.... so hats also damals funktioniert... beim neuen Portal muss es wohl mit PS gehen.
  3. Das wäre auch meine erste Frage.... müsste ja der DC sein auf dem auch AAD Connect läuft.... sonst rennt man ins Leere.
  4. WIN10 VM mit Azure AD verbinden

    Die Frage wäre was du erreichen willst? Windows10 VM kannst du dir erstellen in Azure aber wieso "anmelden"? Versteh ich nciht. AaD Connector ist ein reines Sync Tool, damit syncst du die gewünschten Daten und Attribute von onrpem AD zu Azure AD. Daher verstehe ich die Frage nicht richtig .... Zwingend benötigt wird es nicht. Soll im Azure ein AD aufgespannt werden oder willst du nur einzelne Maschinen dort hochziehen?
  5. Da bin ich ganz bei dir. Aber manche Entscheidungen vom Management setzt man um, da nutzt kein Diskutieren mehr. Die sind da absolut beratungsresistent. Bei Outlook2016 reicht es wenn ich in die Reg ein paar Keys reinschreibe und der Mailabruf erfolgt dann tatsächlich erst nach Ablauf der gesetzten Zeit. Die GPO schreibt folgendes in die Client reg um den Mailabruf alle 6h auszuführen (falls mal jemand danach suchen sollte)
  6. Hi ich soll einer AD Gruppe per GPO den Mailabrufintervall zentral steuern, d. h. diese Gruppe soll nur alle 6h in Outlook Emails empfangen. Zu allen anderen Zeiten sollen die Emails nicht automatisch eintrudeln. Eine ADMX Vorlage für Outlook2016 hab ich nicht finden können. Mit Procmon hab ich versucht die Reg Änderungen zu erfassen die erfolgen wenn ich das in Outlook selbst ändere, aber da sieht man den Wald vor lauter Bäumen nicht mehr. Hat das schonmal jemand umgesetzt und kann mir Tipps geben? Entweder schreib ich die Werte in der Registrierung um oder es gibt eine ADMX Vorlage, das war zumindest der Plan. (Config: Office365 und Outlook 2016, AD in Azure und onprem) Danke und Grüße Rainer
  7. Huhu kurze Info zum Build 1803. Wir haben den gestern schon über den Business Channel eingespielt bekommen. Offiziell sind wir noch auf 1709. Frisch deployte Win10 Enterprise Maschinen mit 1709 holten sich gestern die 1803 ab, versuchten die Installation und machten dann einen Rollback zu 1709. Es bleiben aber diverse 1803 Steuerungselemente in Windows hängen. Das heißt Installation von Language Packs sind nicht mehr möglich, der Installer kommt nicht mehr klar und so einige andere Geschichten. DAbei ist 1803 noch nichtmal final...also noch beta soweit ich das sehen konnte. Seid vorsichtig mit 1803.... testen ist erstmal angesagt.... am besten erstmal Tee trinken und abwarten mit Upgrade.
  8. Hallo Norbert danke, ticket läuft bereits. Werde berichten worans lag.
  9. Huhu Konstellation Office365 und lokales Outlook2016. über das O365 Portal richten wir für diverse User Vollzugriff auf andere Postfächer ein (Postfachstellvertretung für Urlaubsvertretung etc.). Das Postfach erscheint dann im Outlook nach ein paar Minuten nach Outlook Neustart. Entfernt man den Vollzugriff im O365 Portal von diesen Konten bleibt das Konto als Eintrag aber im Outlook 2016 weiter sichtbar. Ich hab zwar keinen zugriff, kann die Ordnerstruktur nicht mehr erweitern, aber bei mir stapeln sich inzwischen die Postfächer links in der Postfachliste von Outlook. Ich sehe immer noch alle Postfächer, die verschwinden nicht mehr. Stellvertreter bin ich schon lange nicht mehr dafür. Per PS hab ich alle Postfachberechtigungen abgefragt, dort sind keine Stellvertretungen mehr zu sehen. Scheint also ein Bug zu sein. Weiß da jemand wie ich die Postfächer da wieder "unsichtbar" mache? Danke und Gruß
  10. 80% dieser Art von Problemen sind DNS basiert. Die DC's müssen sich sehen können und DNS muss beidseitig in beiden Netzen funktionieren. Trust wird verweigert wenn die Hostnamen bzw. die netbios namen der DC's gleich sind. (was häufig vorkommt). Normalerweise kommt beim Herstellen des Trust die Login Afbrage für den anderen Domänenadmin. Wenn der schon nicht erscheint und der RPC Fehler ausgegeben wird ist es meistens ein DNS oder Firewall Problem. DNS läuft bei unseren Trusts über bedingte Weiterleitung im DNS...
  11. Firewall bei IPSec/IKEv2 Ports aufmachen bzw. weiterleiten. 4500, 500, 50, 51 (glaub ich für ipsec) dazu nehmen.... wenn du einen RRAS betreibst müssen die ports zu diesre IP geforwarded werden. Am Server müssen die ports auch offen sein.... sonst kommten die Verhandlungen über den Tunnel nicht zum Ende.
  12. Hallo Nils, ist ne firmenpolitische Entscheidung, muss ich so akzeptieren. AD FS hat auch Nachteile... Das Azure hat mich gerettet. Der Gastzugriff auf die Services funktioniert auch in der Art wie wir das brauchen. Ist etwas mehr Verwaltungsaufwand aber die Funktion am Ende ist ähnlich und da wird eh jetzt fast zu 100% in der Cloud unterwegs sind passt das so. Ziel erreicht.
  13. Das wäre mögich aber damit werden die mit AaD Connect nicht in Azure repliziert, das war mein Ziel dahinter. Ich hab diverse Unternehmes Apps erstellt die im Office Portal publiziert sind, darauf wollte ich Zugriff gewähren ohne einen ext. AD Account erstellen zu müssen. Auf der anderen SEite müssen brauchen wir die Zugriffsberechtigung auf diverse Sharepoint Instanzen in Asien von unserem Partnerunternehmen. Ist leider ein hybride Struktur, beim Partner etwas mehr als bei uns. Wir könnten evtl. die Azure ADs verheiraten, aber AD FS ist nicht gewünscht. Wie ich das jetzt hinkriegen soll weiß ich jetzt auch nicht. :(
  14. Danke Nils, das hab ich mir schon gedacht. Schade....
  15. Hai musste mal wieder zwei ADs verheiraten. Diesmal bin ich aber "ausgerutscht", d. h. was wir erreichen wollten geht nicht. Ich kann User aus der trusted Domäne B zu unseren lokalen Gruppen an Domäne A hinzufügen. Das geht nur auf lokaler Ebene. Bei globalen oder universellen Gruppen geht die Zuweisung nicht. Ich kann die User aber aus Domäne B für die Clients im AD berechtigen. Die sind ja auch nicht lokal, die replizieren sich ja auch über die DC's über den globalen Katalog. Es ging eigentlich darum User aus der Domäne B globalen GRuppen zuzuordnen. Egal wie ich das verschachtele, sobald ich das versuche heißt es immer das ich die Mitglieder nicht hinzufügen kann. Um mein Ziel zu erreichen müsste ich eigentlich jetzt eine übergeordnete Gesamtdomäne erstellen und bei Domänen als Subdomänen aufnehmen. Das ist aber juristisch nicht möglich, die Möglichkeit fällt weg. Kennt jemand einen Weg User aus Domäne B über den Trust zu globalen Sicherheitsgruppen in Domäne A hinzuzufügen`? Ich vermute nicht... aber ich hab noch Hoffnung. viele Grüße
×