Gui om werknemers toe te voegen aan AD groepen

[Lagonas]

Bij mijn werkgever werken wij middels projecten waar groepen aan hangen op security niveau. In deze groepen worden dan weer werknemers toegevoegd om toegang te krijgen tot bepaalde mappen in het project. Hier is 5 de laagste toegang en 1 de hoogste, alleen omdat we globaal werken en vroeger alle landen op zichzelf werkte heeft elk land een andere wijze hoe deze groepen heten. Als voorbeeld zouden de groepen bijvoorbeeld als volgt zijn.

nl-projectnummer-5
nl-projectnummer-4
nl-projectnummer-3
nl-projectnummer-2
nl-projectnummer-1

projectnummer-kl5
projectnummer-kl4
projectnummer-kl3
projectnummer-kl2
projectnummer-kl1

projectnummer-5
projectnummer-4
projectnummer-3
projectnummer-2
projectnummer-1

Aangezien dit niet de enige issues zijn, wordt er al 4 jaar lang bekeken om het AD compleet opnieuw op te bouwen, maar daar komt helaas niet erg veel van terecht op het moment. Nu zoek ik al een lange tijd naar een oplossing die iedergeval voor mezelf alles wat makkelijker maakt. Ik zat zelf te denken aan een gui / powershell script / applicatie waar ik de gebruikersnaam invul, via een lijst / handmatig typen een projectnummer invul en daarna een keuze maak uit de mogelijke groepen.

Ik heb al vele uren versleten aan deze speurtocht maar helaas nog niks passend. Er zijn genoeg tools om mensen aan groepen toe te voegen, maar voor zover ik kan vinden geen waar je zelf te configueren lijsten in kan verwerken.


Weet iemand enige mogelijke oplossing hiervan? Ik weet mijn weg redelijk te vinden in Powershell programeren dus tips naar bruikbare mogelijkheden daarin zijn ook zeker welkom.

[Oogje]

Als je je wens in Powershell kan bouwen, er zijn tools waarmee je een GUI kan maken om je PS heen. En de goeroe’s bouwen de GUI in PS zelf.
Al eens gezocht op “powershell dropdown list”?

[ Voor 17% gewijzigd door Oogje op 21-11-2018 08:48 ]

[MAX3400]

De GUI wordt minder en minder in Windows; zoals @Oogje aangeeft, kan je zelf een GUI bouwen maar ik vermoed zelfs dat je misschien meer kan met een "goede" RBAC (role based access control).

Hierdoor kan je uiteindelijk met aanzienlijk minder werk & administratie ervoor zorgen dat de correcte medewerker de correcte permissies krijgt.

[Sandor_Clegane]

PowerShell wordt echt het nieuwe Access/Excel.

[Alex)]

Als het om een kortetermijnoplossing gaat, in afwachting van een herstructurering van de AD-groepen, is een tweetrapsraket met Excel en Powershell misschien nog wel het snelste gebouwd.

Als eerste bouw je een Excel-sheet. Die structureer je zodanig dat je op tab 1 de usernames kunt ingeven, en met behulp van INDIRECT kun je ervoor zorgen dat je dropdownlijsten krijgt om projecten en access levels te kiezen (deze sla je op tab 2 op). Uiteindelijk kan er dan in Excel de juiste AD-groepnaam uit komen rollen middels een VLOOKUP.

Sla een ingevulde versie op als CSV-file.

Vervolgens ga je aan de gang in Powershell. Met Import-Csv kun je de eerder gegenereerde CSV uitlezen, met Add-ADGroupMember (afkomstig uit de ActiveDirectory module) kun je principals toevoegen aan een AD-groep.

Verdient dit een schoonheidsprijs? Nee. Maar als kortetermijnoplossing voor 1 gebruiker is het denk ik voldoende.

[Killah_Priest]

Sandor_Clegane schreef op woensdag 21 november 2018 @ 15:07:
PowerShell wordt echt het nieuwe Access/Excel.

Wat een onzin. Access en Excel zijn geen scripttaal maar een database en een spreadsheet applicatie.
In Powershell kun je gewoon volledige applicaties bouwen (ik kan met PS bijna alles wat ik ook in C# kan) inclusief GUIs met Winforms of WPF (dit omdat je volledige toegang hebt tot .net)

[Sandor_Clegane]

Killah_Priest schreef op donderdag 22 november 2018 @ 19:15:
[...]


Wat een onzin. Access en Excel zijn geen scripttaal maar een database en een spreadsheet applicatie.
In Powershell kun je gewoon volledige applicaties bouwen (ik kan met PS bijna alles wat ik ook in C# kan) inclusief GUIs met Winforms of WPF (dit omdat je volledige toegang hebt tot .net)

[ Voor 4% gewijzigd door Sandor_Clegane op 22-11-2018 19:31 ]

[Killah_Priest]

Sandor_Clegane schreef op donderdag 22 november 2018 @ 19:29:
[...]

Ik volg jou niet.. Waarom zou je overigens wel een applicatie met een GUI in bv Python mogen maken maar is het slecht om dit in Powershell te doen? Leg het mij dan eens uit?

Ik doe zelf ontzettend veel met Powershell. Zelf heb ik geen behoefte aan GUIs bouwen (hoewel ik dat in het verleden wel gedaan heb, zowel volledig in code als met XAML - inclusief werkende databinding) omdat ik nou eenmaal graag in de console werk maar er is niets mis met dit soort zaken bouwen in een scripting taal zoals Powershell en ook totaal niet te vergelijken met bijvoorbeeld het misbruiken van excel voor een "database".

(Juist AD tools zijn perfect om met Powershell te bouwen)

[ Voor 44% gewijzigd door Killah_Priest op 22-11-2018 19:39 ]

[Sandor_Clegane]

Killah_Priest schreef op donderdag 22 november 2018 @ 19:33:
[...]


Ik volg jou niet.. Waarom zou je overigens wel een applicatie met een GUI in bv Python mogen maken maar is het slecht om dit in Powershell te doen? Leg het mij dan eens uit?

Iedereen kent toch wel de spreadsheet en Access applicaties die in het verleden tot zoveel mooie dingen hebben geleid? Ik zie powershell dezelfde kant op gaan zodat er met een paar jaar er allemaal mooie powershell "applicaties" bestaan en we het hele riedeltje weer opnieuw kunnen doen omdat het toch niet helemaal je van het is.

[Killah_Priest]

Sandor_Clegane schreef op donderdag 22 november 2018 @ 19:39:
[...]


Iedereen kent toch wel de spreadsheet en Access applicaties die in het verleden tot zoveel mooie dingen hebben geleid? Ik zie powershell dezelfde kant op gaan zodat er met een paar jaar er allemaal mooie powershell "applicaties" bestaan en we het hele riedeltje weer opnieuw kunnen doen omdat het toch niet helemaal je van het is.

In wezen is er weinig verschil tussen een applicatie welke in Powershell gebouwd is en een applicatie welke in C# gebouwd is (behalve dan dat de C# applicatie gecompiled wordt) voor een gebruiker hoor. En code is prima te testen met bv Pester. Source control kan ook als je dat wilt.

[Sandor_Clegane]

Killah_Priest schreef op donderdag 22 november 2018 @ 19:43:
[...]


In wezen is er weinig verschil tussen een applicatie welke in Powershell gebouwd is en een applicatie welke in C# gebouwd is (behalve dan dat de C# applicatie gecompiled wordt) voor een gebruiker hoor. En code is prima te testen met bv Pester. Source control kan ook als je dat wilt.

Tja, dan denk ik dat we er anders tegenaan kijken.

[mufana]

lagonas schreef op woensdag 21 november 2018 @ 08:42:
Bij mijn werkgever werken wij middels projecten waar groepen aan hangen op security niveau. In deze groepen worden dan weer werknemers toegevoegd om toegang te krijgen tot bepaalde mappen in het project. Hier is 5 de laagste toegang en 1 de hoogste, alleen omdat we globaal werken en vroeger alle landen op zichzelf werkte heeft elk land een andere wijze hoe deze groepen heten. Als voorbeeld zouden de groepen bijvoorbeeld als volgt zijn.

nl-projectnummer-5
nl-projectnummer-4
nl-projectnummer-3
nl-projectnummer-2
nl-projectnummer-1

projectnummer-kl5
projectnummer-kl4
projectnummer-kl3
projectnummer-kl2
projectnummer-kl1

projectnummer-5
projectnummer-4
projectnummer-3
projectnummer-2
projectnummer-1

Aangezien dit niet de enige issues zijn, wordt er al 4 jaar lang bekeken om het AD compleet opnieuw op te bouwen, maar daar komt helaas niet erg veel van terecht op het moment. Nu zoek ik al een lange tijd naar een oplossing die iedergeval voor mezelf alles wat makkelijker maakt. Ik zat zelf te denken aan een gui / powershell script / applicatie waar ik de gebruikersnaam invul, via een lijst / handmatig typen een projectnummer invul en daarna een keuze maak uit de mogelijke groepen.

Ik heb al vele uren versleten aan deze speurtocht maar helaas nog niks passend. Er zijn genoeg tools om mensen aan groepen toe te voegen, maar voor zover ik kan vinden geen waar je zelf te configueren lijsten in kan verwerken.


Weet iemand enige mogelijke oplossing hiervan? Ik weet mijn weg redelijk te vinden in Powershell programeren dus tips naar bruikbare mogelijkheden daarin zijn ook zeker welkom.

Je zou dit inderdaad in PowerShell kunnen bouwen. In de meest simpele vorm is het dan een vervanging voor AD Management Tooling. Ik weet niet of je daar op zit te wachten. Tenzij je het beheer wilt beleggen bij bv. een manager. Dan zou een eigen GUI tool best handig zijn. (En redelijk eenvoudig te bouwen).