StefanWe

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.

Schon ziemlich lang her. Gehts mittlerweile? reverse proxy ist nicht supported. Stell den Exchange ins Internet und begrenze den Zugriff von extern auf die Microsoft ips für Teams und Exchange. So läuft es bei uns. Alles andere ist Murks.

Toller Thread, ich hoffe noch nicht zu alt. wir haben das Tier Modell bei uns auch umgesetzt. Bis ich die alten Hasen erklärt habe, warum wir das tun, sind schon Monate vergangen. Der ein oder andere sagt heute noch, das die Arbeit kaum zu erledigen ist, weil der Verwaltungsoverhead enorm ist. Tier0 ist simpel. Bei Tier 1 und 2 wird’s haarig. Gerade Tier2. Wir haben dem normalen Useraccount das Tier2 Recht gegeben. Damit ist halbwegs normales arbeiten möglich. Nicht gut, ich weiß. paws haben wir noch nicht eingeführt, weil schlicht noch kein sauberes Konzept vorliegt, wie man auch aus dem Home Office diese nutzen kann. richtig Grenzwertig wurde es als wir 2 FA für die Tier User eingeführt haben. Zu erst mit Yubico als Smartcard. das geht aber nur sauber, wenn überall der yubico minidriver installiert wird. Da wir noch xp clients in der Produktion haben, hat uns dass das durchgängige Konzept verhagelt. Auch wollten wir nicht auf jedem Server den Treiber installieren. Ende vom Lied, kein durchgängiges Konzept, alle unzufrieden. als Lösung haben wir dann Silverfort gekauft, geniale Lösung. Auf einmal war jeder Netzwerkzugriff mit 2fa geschützt. Einzig, cached Credentials können es für die lokale Anmeldung außer Kraft setzen. Aber genau das war nun das Problem mit den eigenen Workstations. So richtig glücklich sind wir damit auch nicht. achja, die Tier1 Admins in die Protected User Gruppe aufnehmen? Schlechte Idee, wenn man Radius zur Anmeldung an den Switchen verwendet. Geht dann nämlich nicht mehr. also, eigener User zur Verwaltung der Switche? @wznutzer bei Service Accounts regelmäßig die Kennwörter zu ändern halte ich für nicht realistisch, jedenfalls nicht, wenn die IT normal bis unterbesetzt ist. das Thema ist so unfassbar komplex, es gibt nicht die eine Lösung. Aber sich damit zu beschäftigen und so viel wie möglich umzusetzen, ist schon mal ein sehr guter Schritt. @daabm mit welchen Usern verbindet ihr euch über cyberark mit den Servern? Gibt es da einen generellen Account und ihr verbindet euch mit dem persönlichen gegen cyberark?

um es abzuschließen, ist es dann auch eher aktuell ein "gehyptes" Thema, wo jedes Unternehmen sich zwar ärgert, dass es etwas teurer wird, aber die Kosten für einen Umbau stehen dann in keinem Verhältnis.

@zahni ich kenne aktuelle Preise von VMWare nicht, aber ein Abo Modell halte ich jetzt prinzipiell erstmal nicht für schlechter. Ja die Bestandslizenzen werden teurer, aber eine jährliche Preissteigerung ist auch bei Wartung nicht selten. Für 4000 Euro pro Jahr mehr ist das zwar Ärgerlich, der, der aber vorher schon Enterprise Plus hatte, wird auch die Features genutzt haben und für ihn gibt es derzeit keine wirkliche Alternative. vSphere Standard entfällt dann komplett? Für die Kunden wirds dann teuer. Da ist dann Hyper-V wohl eine Alternative. Ich möchte hier jetzt aber keinen "Vmware Lizenz Thread" von machen. Die Aussagen von @mwiederkehr und @cj_berlin sind ja schon ganz informativ. Ich höre im moment selbst viel von Azure Virtual Desktop, kann den Hype darüber aber selbst auch nicht ganz nachvollziehen.

Hallo, mich würde mal interessieren, was für Projekte und Anforderungen ihr so im Cloud Umfeld umsetzt. Für mich wirkt es so, als wenn niemand mehr sich um klassische on Prem Migrationen kümmert. AD updaten, oder ähnliches. allerdings fehlt es mir auch an Kreativität, zu erkennen, was heute alles umgesetzt wird. Lift and Shift? M365 Einführungen? Müsste doch mittlerweile jeder haben. eigene Programmierungen wo ich dann entsprechende Services von Azure nutze? Kann doch nicht jeder wollen. Ich freue mich auf eine rege Diskussion.

Hallo @NilsK, leider nicht ganz. Das könnte vielleicht funktionieren, wenn wir die Geräte undeployed und AzureAD only gejoined sind. Wir stellen die Geräte Active Directory und Azure AD hybrid gejoined zur Verfügung. Vermutlich ist das auch das große Problem an der Sache.

Hallo, wir würden gerne Hello for Business einsetzen. Es ist konfiguriert und funktioniert. Aber wir haben im Lifecycle noch folgende Fragen: Ziel soll es sein, Kennwortlos im Unternehmen zu arbeiten. Szenario A: Ein neuer Mitarbeiter fängt bei uns an und bekommt ein Gerät in die Hand, welches Mitglied unserer Active Directory Domäne und Hybrid gejoind ins Azure AD ist. Muss ich dem Mitarbeiter jetzt erstmalig ein Passwort mitgeben? Wie erzwinge ich anschließend, das er sich nur noch mit Hello for Business anmeldet und nicht weiter mit dem Passwort? Szenario B: Ein bereits vorhandener Mitarbeiter nutzt seit geraumer Zeit Hello for Business und kennt sein Passwort nicht mehr. Sein Gerät geht kaputt. Er bekommt ein neues Gerät. Muss er dann zwingend vom Help Desk ein neues Passwort erhalten? Wenn ich die GPO "Erzwinge Hello for Business oder Smart Card Anmeldung" für Computer aktiviere, kann sich ein Benutzer nicht neu an einem Gerät mit Password anmelden. Auch ein IT Mitarbeiter kann sich nicht an dem Gerät anmelden. Welche Erfahrung habt ihr im Lifecycle gemacht?

@PadawanDeluXe grundsätzlich guter Gedanke. Mit was automatisiert ihr? Ich denke da gerade an Ansible...