StefanWe

Genau das ist der Punkt und da stell ich mir die Frage ob Byok ohne eigenes him, überhaupt etwas bringt oder eben nur Schutz vorgaukelt.

Datendiebstahl, bzw. Das MS selbst nicht an die Daten kommt.

Hallo, ich würde gern mal eure Meinung zum Thema BYOK hören. Ist es sicherer? Immerhin ist der Key im keyvault abgespeichert, auf welchen MS sicherlich irgendwie Zugriff hat.

Genau so hab ich’s ja. Nur entra meckert. Aber scheinbar ist es nen Cache Problem von entra. Jetzt scheint es zu gehen.

Hallo, ich habe hier im Entra CBA konfiguriert, welches auch funktioniert, solange ich keine Sperrlistenprüfung aktiviere. Grundsätzlich ist die Sperrliste in meiner PKI konfiguriert und von extern erreichbar und downloadbar. Windows meldet hier auch keine Probleme. Im Entra Portal unter Security->PKI habe ich eine PKI angelegt und dort mein Root Zertifikat hochgeladen. Auf der Root, habe ich die URL für die Sperrliste und Delta Sperrliste konfiguriert. Anschließend unter Authentication Methods die CBA aktiviert und dort das CRL Checking aktiviert und keine CA Ausnahme konfiguriert. Wenn sich nun ein User anmeldet erhält dieser die Fehlermeldung AADSTS2205018: Certificate Authority:'........' does not have a CRL specified and fails 'Require CRL validation' check. Ich habe den Fehler sowohl in meinem Lab (Root CA ist gleichzeitig die Issuing CA) als auch in einer anderen Umgebung, wo es eine Root CA und eine Issuing CA gibt. Nun die Frage, das Zertifikat der Root CA besitzt ja nie einen Verweis auf eine Sperrliste, erst die Issuing CA, bzw. die User Zertifikate. Nun die Frage, muss ich für die Root CA eine Ausnahme konfigurieren? oder woran kann es liegen?

ok, das klingt nicht vielversprechend und bestätigt, das ich nichts übersehen habe. Danke euch.

Ja genau, das ist der Punkt. Wenn ich das Master Image hochfahre, passiert ja viel Magie... und zig tausend update Prozesse laufen im Hintergrund los und ich weiß gar nicht welche Anwendung aktualisiert wird. Ich hätte da gern etwas mehr Kontrolle drüber, oder ist das auch alte Hasen Technik und man macht nur noch "druff da" ? ;)

Hallo, wir setzen Windows 11 als VDI Desktop ein. Mittlerweile gibt es neben den Windows Updates ja auch Software die aus dem Windows Store kommt. Z.B. die Windows-App (AVD Client) Da wir unsere VDI Images regelmäßig aus dem Master Image neu erstellen, stellen wir uns die Frage, wie wir die Software am besten pflegen und updaten und vor allem kontrolliert updaten. Wie geht ihr da mittlerweile mit um? Wie ist der aktuelle Stand der Dinge?

Hab es übrigens recht einfach selber lösen können. In der resourceID ist ja ganz hinten der Name untergebracht. Dementsprechend kann man die Split Funktion in Verbindung mit concat verwenden. name: concat('vnetlink-', split(vnet, '/')[8])

Hallo, ich baue gerade das ein oder andere größere Bicep Deployment. In einem Fall möchte ich gerne es etwas schöner lösen, komme aber nicht weiter. Ich habe ein main.bicep Script, welches als targetscope = 'Subscription' läuft um meine Resource Gruppen zu erstellen. Alle anderen Ressourcen werden dann als Module aus dem main Script gestartet. Ich lege im ersten Modul mehrere virtuelle Netze an. In diesem Script gebe ich über output die ResourceID der erstellten virtuellen Netze zurück. Anschließend habe ich im main Script eine Variable als array erstellt var Netzids = [ VirtualNetworks.outputs.vnet2id VirtualNetworks.outputs.vnet3id VirtualNetworks.outputs.vnet4id ] ich rufe nun das Modul für meine privaten DNS Zonen und deren vnet verlinkungen auf und übergebe das array als Parameter module PrivateDNSZones 'privatedns.bicep' = { scope: resourceGroup(rg_000.name) name: 'Deployment-Private-DNS-Zones' params: { vnetlinkids: Netzids } dependsOn: [ VirtualNetworks ] } Das funktioniert soweit ohne Probleme. Allerdings nun in der for Schleife komme ich mit dem Namen nicht zurecht. Dieser muss ja eindeutig sein: resource vnetlinkblob 'Microsoft.Network/privateDnsZones/virtualNetworkLinks@2024-06-01' = [for vnet in vnetlinkids: { name: 'link-${vnet}' parent: PrivatLinkBlob location: 'global' properties: { registrationEnabled: false virtualNetwork: { id: vnet } } }] In vnet steht allerdings die ID drin und nicht der Name vom Subnet. Damit läuft das Deployment auf die Nase. Ich glaube ansonsten würde es funktionieren. Die Frage ist nun, wie komme ich an den Namen des vnets um für den Link einen eindeutigen Namen zu haben?

Gibt es eigentlich noch die Begrenzung, dass Office auf den ltsc Versionen nicht supported / erlaubt war? Oder spielt dies keine Rolle?

Die meisten Cloud Applikationen sind doch idr. auch eher kleine Tools die die Fachabteilung unbedingt haben möchte. Das Große ERP, CRM, sonstwas Tool wird dann ja schon eher Unternehmensweit ausgerollt und sollte dann durch die IT gesteuert / berechtigt werden. Aber gerade bei diesen kleinen Tools finde ich die Berechtigungsvergabe innerhalb der Applikation ganz praktisch. Und damit eben auch auf das AGDLP Prinzip zu verzichten. Ähnliches gilt ja auch, wenn man Cloud Tools mit externen Partnern zusammen nutzt. Hier bietet es sich doch an, direkt den Firmenaccount des jeweiligen in der Applikation zu berechtigen, anstatt demjenigen erst einen AD Account zu erstellen, im schlimmsten Fall noch ein Postfach, damit er die Onboardingbestätigungsmail akzeptieren kann. Bin mal auf weitere Meinungen gespannt.

Hallo, mich würde gerne einmal interessieren, bzw. Diskutieren, wie ihr das Berechtigungskonzept in der modernen Cloud Umgebung seht. ich für meinen Fall habe in der klassischen On Prem Welt stark auf das AGDLP Prinzip bzw. Plus U Gruppen gesetzt. D.h. Egal welche Anwendung wurde ans AD angebunden und Berechtigungen innerhalb dieser an Gruppen im AD vergeben. Jedenfalls wo es möglich war. Mit Entra Id in einer Hybriden Welt ist dies zum Teil für Cloud Anwendungen, welche mittels Saml/oauth angebunden werden möglich. Man könnte nun im AD Gruppen anlegen und diese synchronisieren oder matchen lassen. Je Nachdem was die Cloud Anwendung unterstützt. Alternativ könnte man Benutzer aber auch individuell der Anwendung zuweisen und Berechtigungen innerhalb der Anwendung direkt an die Benutzer vergeben. Oder Benutzer innerhalb der Anwendung in die Anwendungsgruppen packen. Bei letzterem ist eine Delegation der Berechtigungen auch an Fachabteilungen möglich. Sie können so Leute innerhalb ihrer Projekte berechtigen. Wie seht ihr das?

Den einzigen Schutz, wenn man es so nennen kann, ist der IP Filter auf die von ms benutzten Ranges. ziemlich ka**e. Ja.

https://learn.microsoft.com/en-us/exchange/hybrid-deployment-prerequisites pre Auth ist explizit nicht supported. Ms selbst supported keinen reverse Proxy. Wenn es nicht funktioniert, musst du selbst sorgen das es geht.