Aanmaken AD user + mailbox

[Yarisken]

Hallo,

Ik ben hier intern aan het kijken om het aanmaken van AD users + mailbox automatisch te laten lopen.
We krijgen nu van HR een ticket waar een aanvraag instaat.
Meestal is deze info onvolledig en te laat :-).
Ik had gedacht om een webinterface te voorzien waar ze "verplichte" velden kunnen invullen. Eens ze op submit klikken wordt er een csv aangemaakt.
Deze csv wordt via powershell uitgelezen en de user + mailbox wordt aangemaakt.
Zijn er mensen die op een andere / betere manier werken ?

[Breezers]

Wat je ook verzint, als er aan je eerste voorwaarde niet voldaan wordt:

"...Meestal is deze info onvolledig en te laat...."

Dan lost dit je probleem ook niet op ?


Kan je niet beter je tijd steken in een correcte werkinstructie met een kleine training (mompelt iets over de oorzaak oplossen en niet het gevolg bestrijden )

[Yarisken]

Breezers schreef op dinsdag 08 september 2015 @ 18:02:
Wat je ook verzint, als er aan je eerste voorwaarde niet voldaan wordt:

"...Meestal is deze info onvolledig en te laat...."

Dan lost dit je probleem ook niet op ?


Kan je niet beter je tijd steken in een correcte werkinstructie met een kleine training (mompelt iets over de oorzaak oplossen en niet het gevolg bestrijden )

Wel ik denk wel dat het zo gaat opgelost zijn :-). HR moet dan "verplichte" velden invullen alvorens er een csv wordt gegenereerd. Doen ze dit niet of onvolledig dan is er geen user en geen mailbox :-).

[Killah_Priest]

Ik ben zelf toevallig (als ik geen andere klussen heb) voor een klant bezig met een web API (c#, ASP.NET) waar uiteraard ook een pagina met een form oid bij hoort puur om AD users aan te maken (een csv oid genereren adv de input vind ik een stap teveel). Hiermee kunnen wij de verantwoordelijkheid voor het onboarden neerleggen bij HR (ook vaak laat met onboard verzoeken - excel sheet is wel altijd compleet) zodat het hun eigen probleem wordt als zij te laat zijn met onboard verzoeken.

Ik heb zelf meerdere dingen overwogen voor ik hiervoor koos :
- excel sheets processen via een folder die ik monitor met een filesystemwatcher object in powershell.
- Een mailbox monitoren (via de exchange web API) en dan een attachment processen.

In beide gevallen was het plan om dit in eerste instantie in Powershell te doen : uiteindelijk toch maar gekozen voor een web oplossing : en als ik dat toch doe dan wil ik het zonder csv oid hebben.
Zelf ben ik nog wel aan het twijfelen : of ik doe alles in c# of ik kies voor de "easy way out" en embed powershell code in mijn api...(de PS scripts heb ik al zovaak geschreven, met username volgens naming convention van het bedrijf en rekening houdend met achternamen met spaties erin, check op duplicate namen enz. AD groepen, mailbox access etc staan ook weer via een xml bestand waar ik alles in heb gezet per afdeling en functie etc)

[ Voor 12% gewijzigd door Killah_Priest op 08-09-2015 18:46 ]

[Yarisken]

Thx voor de reply Killah_Priest. Ik ben geen programmeur, anders zou ik ook wel voor zo'n oplossing kiezen.

[Linke Loe]

Als je bereid bent om hiervoor software aan te schaffen zal AD Manager Plus van ManageEngine een goede oplossing bieden. Hiermee kan IT het aanmaken van AD accounts (inclusief Exchange en Lync) uitbesteden aan HR personeel. Vooraf kunnen verschillende afdelingen gedefinieerd worden, waardoor accounts in de juiste OU aangemaakt worden. HR hoeft dan alleen maar de gegevens in te vullen, die gevraagd worden...

[Semt-x]

Het zelf maken van een script is naar mijn mening een slecht idee.

• je bent de enige die in het bedrijf dit script kent en je blijft daar net werken tot je 67e.
• verkijk je niet op de complexiteit, de situatie van "bert de vries" en "bart de vries", username en mail adres automatisch generen in je script.
• automatisch bijwerken van accounts, als iemand van afdeling verandert.
• automatisch decomssionen van een account. ( meestal in 2 fases, bijv 3 maanden disable, daarna archive en delete)
• als er AD geintegreerde apps veranderen, bijv on-premise exchange wordt nu exchange online. Dat heeft grote gevolegen voor je script en vergt veel werk.

Het schijrijven van zon script is ogenschijnlijk eenvoudig, maar als het een solide oplossing moet worden is het als snel een maandenlang project. Er wordt dan tijd geinvesteerd in een product dat allang op de markt is, dat alle complexiteit adresseert, als standaard kan worden gezien. de kennis van dit product niet afhankelijk is van 1 persoon. en de implementatie van dit product met hulp van de leverancier kan gebeuren.

Tot slot ben ik geen fan van een CSV gebruik als bron, spreek een view aan in de HR database. en verwerk die gegevens. Het kenmerk waarop je de link legt tussen de HR DB en AD mag niet de BSN zijn, dit is bij wet verboden.

[akimosan]

Het kenmerk waarop je de link legt tussen de HR DB en AD mag niet de BSN zijn, dit is bij wet verboden.

Heb je hier een bron van? Bij een opdrachtgever weet ik dat deze link gebruikt wordt namelijk.

Mag het wel met een "hash" van de BSN? Het BSN zelf wordt niet vastgelegd maar een encrypted versie hiervan wel.

[Killah_Priest]

Semt-x schreef op woensdag 09 september 2015 @ 16:44:
Het zelf maken van een script is naar mijn mening een slecht idee.

• je bent de enige die in het bedrijf dit script kent en je blijft daar net werken tot je 67e.
• verkijk je niet op de complexiteit, de situatie van "bert de vries" en "bart de vries", username en mail adres automatisch generen in je script.
• automatisch bijwerken van accounts, als iemand van afdeling verandert.
• automatisch decomssionen van een account. ( meestal in 2 fases, bijv 3 maanden disable, daarna archive en delete)
• als er AD geintegreerde apps veranderen, bijv on-premise exchange wordt nu exchange online. Dat heeft grote gevolegen voor je script en vergt veel werk.

Het schijrijven van zon script is ogenschijnlijk eenvoudig, maar als het een solide oplossing moet worden is het als snel een maandenlang project. Er wordt dan tijd geinvesteerd in een product dat allang op de markt is, dat alle complexiteit adresseert, als standaard kan worden gezien. de kennis van dit product niet afhankelijk is van 1 persoon. en de implementatie van dit product met hulp van de leverancier kan gebeuren.

Ik ben het hier niet mee eens :
Sinds wanneer is het voor jou een nadeel als jij de enige bent die weet hoe iets werkt? Tevens is het goed kunnen documenteren van een script (meestal simpelweg door deze van comments te voorzien) kan dit overigens ook gewoon tegengaan. Anders zou in-house ontwikkelde software waar 1 persoon aan werkt ook plotsklaps waardeloos kunnen worden (daarom dus documenteren).

Maandenlang bezig zijn met een degelijk script? Komop, ik klop in een aantal uur een dergelijk script in elkaar hoor en ik weet zeker dat er genoeg tweakers zijn met voldoende PS kennis om dat ook te kunnen. Met een beetje testen en finetunen kom je dan uit op 1 volle werkdag, geen maanden werk.

Door je scripts in de basis al een goede opbouw te geven kom je al een heel eind. Ik bouw meerdere functies in een PS script welke allemaal weer parameters als input hebben en eventueel een output genereren : Denk hierbij aan functies voor het connecten naar Exchange, mailbox aanmaken, checken op dubbele AD accounts, AD user aanmaken, AD groepen toekennen, enz. Hierdoor kan ik erg snel een functie wijzigen als bv de klant overgaat naar bv Exchange Online (ik pas dan de code aan in de functie voor de Exchange connectie en in het aanmaken van bv de mailbox - omdat ik ervoor zorg dat bv de parameter input gelijk blijft hoef ik dus weinig aan het script zelf te wijzigen). Ook zorg ik ervoor dat bv de exchange server als globale variable toegekend is bovenaan het script evenals een aantal andere specifieke settings zodat je deze ook kan hergebruiken in andere omgevingen (hoewel dat niet eens noodzakelijk is ivm de modulaire opbouw van mijn scripts).

Je kan wel allemaal oplossingen gaan bedenken met 3rd party software maar vergeet niet : het aanmaken wordt nu blijkbaar met de hand gedaan (wat ik overigens vaak tegenkom). Veel bedrijven willen hier ook geen geld voor vrijmaken, ook gezien het aantal users wat er paar maand wordt aangemaakt : je gaat toch geen duur software pakket kopen voor 5 users per maand?

[ Voor 6% gewijzigd door Killah_Priest op 09-09-2015 20:36 ]

[Question Mark]

Yarisken schreef op dinsdag 08 september 2015 @ 18:27:
[...]


Wel ik denk wel dat het zo gaat opgelost zijn :-). HR moet dan "verplichte" velden invullen alvorens er een csv wordt gegenereerd. Doen ze dit niet of onvolledig dan is er geen user en geen mailbox :-).

Als je bij een onvolledig verzoek invullen, stuur je het toch simpelweg retour met de opmerking om de juiste info in te vullen? Doen ze dit niet of onvolledig, dan is er geen user en geen mailbox.

Het is gangbaarder dat er bij een useraanvraag een templateformulier oid ingevuld moet worden. Niet volledig of onjuist ingevulde formulieren worden simpelweg niet in behandeling genomen.

Da's veel simpeler dan een extra website, custom powershell scripts en een nieuwe scheiding van beheer op AD gebied ten opzichte van nu.

Killah_Priest schreef op woensdag 09 september 2015 @ 20:32:
[...]
Je kan wel allemaal oplossingen gaan bedenken met 3rd party software maar vergeet niet : het aanmaken wordt nu blijkbaar met de hand gedaan (wat ik overigens vaak tegenkom). Veel bedrijven willen hier ook geen geld voor vrijmaken, ook gezien het aantal users wat er paar maand wordt aangemaakt : je gaat toch geen duur software pakket kopen voor 5 users per maand?

It all depends... De eerder genoemde AD Manager kost 500 dollar. 5 users per maand met de hand aanmaken kost ong. een kwartiertje per user. Die businesscase is wel redelijk vlot gemaakt. De terugverdientijd is nog geen twee jaar (uitgaande van een beheerder die 3K bruto per maand verdiend).

[Killah_Priest]

Natuurlijk mag goede software best wel wat kosten (en 500 euro is natuurlijk niets in software land). Maar......
Zolang veel bedrijven (vooral in het mkb) al proberen te bezuinigen op een noodzakelijke server en ondertussen wel in een auto rijden met een bijtelling waar je u tegen zegt zie ik 500 euro vrijmaken niet zo 123 gebeuren bij veel bedrijven (ze zien vaak het belang er niet van in als het niet direct geld oplevert, ik heb zelfs meegemaakt dat een klant geen ssl cert voor hun exchange server wilden want die paar tientjes vonden ze zonde : helaas de keiharde realiteit voor veel beheerders in het mkb).
Vergeet ook niet dat je als beheerder vaak ook even wat rustigere momenten hebt (ik zit regelmatig duimen te draaien omdat er op dat moment geen incidenten zijn om nog wat mee te doen en alle taken voor de dag gedaan zijn) : ik bewaar zulke momenten vaak voor dingen als user accounts aanmaken, AD opschonen, werken aan PS scripts etc. Omdat ik dus genoeg momenten heb waarbij ik even een user aan kan maken tussendoor kost het mij geen tijd die ik aan andere zaken had moeten besteden (waarbij de terugverdientijd wel een stuk langer als 2 jaar zou worden in mijn geval ).

[ Voor 5% gewijzigd door Killah_Priest op 09-09-2015 21:35 ]

[Yarisken]

Killah_Priest schreef op woensdag 09 september 2015 @ 21:33:
Natuurlijk mag goede software best wel wat kosten (en 500 euro is natuurlijk niets in software land). Maar......
Zolang veel bedrijven (vooral in het mkb) al proberen te bezuinigen op een noodzakelijke server en ondertussen wel in een auto rijden met een bijtelling waar je u tegen zegt zie ik 500 euro vrijmaken niet zo 123 gebeuren bij veel bedrijven (ze zien vaak het belang er niet van in als het niet direct geld oplevert, ik heb zelfs meegemaakt dat een klant geen ssl cert voor hun exchange server wilden want die paar tientjes vonden ze zonde : helaas de keiharde realiteit voor veel beheerders in het mkb).

Klopt, wij zitten binnenkort met een storage die 4 keer minder kost dan de licenties van oracle ..... Dus die kut software kost 4 keer meer .... heb het nu al 2 keer gezegd ... .

Soit, bij ons is het omgekeerd. De mensen hier op de helpdesk hebben het heel heel druk. Mijn baas zit contant aan mijn mouw te schudden om zaken wat te vereenvoudigen en te versnellen.
Wij zitten aan ongeveer 10 nieuwe users per maand. Heel veel werk is dit inderdaad niet om dit aan te maken, wel veel tijd verliezen ze met HR die te laat zijn of onvolledig.

[Killah_Priest]

Yarisken schreef op donderdag 10 september 2015 @ 09:40:
[...]


Klopt, wij zitten binnenkort met een storage die 4 keer minder kost dan de licenties van oracle ..... Dus die kut software kost 4 keer meer .... heb het nu al 2 keer gezegd ... .

Soit, bij ons is het omgekeerd. De mensen hier op de helpdesk hebben het heel heel druk. Mijn baas zit contant aan mijn mouw te schudden om zaken wat te vereenvoudigen en te versnellen.
Wij zitten aan ongeveer 10 nieuwe users per maand. Heel veel werk is dit inderdaad niet om dit aan te maken, wel veel tijd verliezen ze met HR die te laat zijn of onvolledig.

Een goede tip om het rustiger te krijgen : leer Powershell.
Een aantal jaren geleden had ik het ook constant druk : er werd ook gewoon erg inefficiënt gewerkt. Ik heb mij daarom volledig op Powershell gestort. Het gevolg is nu dus dat ik regelmatig tijd over heb.

Laatst moest ik bv bij een klant DFS inrichten : ik was binnen 15 minuten klaar (10 minuten om een script te bouwen die alles voor mij deed) omdat ik de boel gescript had. Met de hand zou ik daar 2 uur mee bezig zijn geweest. Zo heb ik nog tig andere voorbeelden waarbij ik dmv zaken scripten veel handmatig werk automatiseer en daardoor dus meer tijd vrij kan maken voor andere zaken.
(Wij hebben ook een private cloud voor klanten : een nieuwe tenant aanmaken kostte eerst ook veel tijd EN mensen maakten daar snel fouten bij het handmatig aanmaken : 2 uurtjes gezeten voor een script om de OU structuur, default policies en alle Exchange gerelateerde zaken aanmaakt waardoor dat proces nu foutloos gaat EN binnen 10 seconden klaar)

[Yarisken]

Killah_Priest schreef op donderdag 10 september 2015 @ 09:58:
[...]


Een goede tip om het rustiger te krijgen : leer Powershell.
Een aantal jaren geleden had ik het ook constant druk : er werd ook gewoon erg inefficiënt gewerkt. Ik heb mij daarom volledig op Powershell gestort. Het gevolg is nu dus dat ik regelmatig tijd over heb.

Laatst moest ik bv bij een klant DFS inrichten : ik was binnen 15 minuten klaar (10 minuten om een script te bouwen die alles voor mij deed) omdat ik de boel gescript had. Met de hand zou ik daar 2 uur mee bezig zijn geweest. Zo heb ik nog tig andere voorbeelden waarbij ik dmv zaken scripten veel handmatig werk automatiseer en daardoor dus meer tijd vrij kan maken voor andere zaken.
(Wij hebben ook een private cloud voor klanten : een nieuwe tenant aanmaken kostte eerst ook veel tijd EN mensen maakten daar snel fouten bij het handmatig aanmaken : 2 uurtjes gezeten voor een script om de OU structuur, default policies en alle Exchange gerelateerde zaken aanmaakt waardoor dat proces nu foutloos gaat EN binnen 10 seconden klaar)

Je hebt helemaal gelijk. Ik gebruik powershell ook constant maar niet om te scripten. Meestal op exchange om iets aan te passen op een mailbox of om rapporten te trekken.
Als ik een klein script moet maken dan schakel ik nog regelmatig over naar dos ... :-).
Ik ga je raad opvolgen.

[Verwijderd]

Is er hier iemand die met AD-profielen werkt?
Bv persoon X komt in dienst en moet het profiel krijgen van gebruiker Y op de dienst Boekhouding bv?

Bij ons is hiernaar al jaren de vraag naar. In theorie is dit prachtig maar in praktijk ... .

Elke user krijgt na verloop van tijd een toegang extra voor welke reden dan ook.
Bijgevolg is geen één user dezelfde binnen de dienst.

Als je dan zegt "wij willen wel met profielen werken maar dan moet iedereen steeds dezelfde toegang krijgen" , dan is dit niet mogelijk voor de directie. Onbegonnen werk dus.

hoe zit dit bij jullie?

[Question Mark]

Dat heet RBAC (Role Based Access Control). Of het werkt is afhankelijk van het soort organisatie...

Bij organisatie met vastgelegde werkzaamheden en functieprofielen werkt het fantastisch (denk bank/verzekeraar). Bij een bedrijf met heel veel verschillende functieprofielen, werkzaamheden en verantwoordelijkheden werkt het voor geen meter...

[Semt-x]

Zoals anderen aangeven is het vooral een kwestie van schaal, voor 5 man heeft het weinig zin (niet anders dan een technische training voor jezelf) maar rond de 200 man ligt ongeveer het punt waarin het goedkoper/beter is om het met een extern product te kiezen.

Maandenlang bezig zijn met een degelijk script? Komop ..
Met een beetje testen en finetunen kom je dan uit op 1 volle werkdag, geen maanden werk.

Misschien komt ons beeld van de functie van dat script niet overeen. Ik zie het als totaal oplossing voor user provisioning; het aanmaken, bijwerken en verwijderen van gebruikeraccounts.
Met dat in het achterhoofd vind ik de inschatting van die ene dag het schoolvoorbeeld van onderschatten van de complexiteit van de taak. Complexiteit zoals:

• Gebruikers met een conflicterende naam (Bert en Bart de Vries)
• Gebruikers met dezelfde naam
• Gebruikers die trouwen en weer scheiden en dus hun naam verandert, en de gebruikersnaam verandert (en dus bijv home directory en er komt een exchange alias bij)
• Iemand die weer in dienst komt voordat de vorige gebruikersnaam werd gearchiveerd.
• Is er in het HR systeem al een legale (dus geen BSN) uniek personeelsnummer dat niet verandert als iemand van een tijdelijk contract naar een vast contract gaat? dit is vaker niet, dan wel het geval.
  Bovendien heb ik in de 10 jaar dat ik deze opdracht tegenkom nog nooit een foutloos gevulde HR database gezien, dat komt boven water bij een klus als deze.
• Het automatisch lid maken van bepaalde AD groepen op basis van een combinatie van de functie en afdeling.

Dat doe je in een dag? of bouw je een scriptje in één dag dat enkele eigenschappen doorvoert en zodra er iets geks in in de werknemer data zit niet meer werkt, of veel erger, AD overhoop haalt?
Bedenk je het moment waarop je het script voor het eerst laat synchroniseren. Voordat je dat wil doen, moet er een log functie inzitten die elke aanpassing logt, zodat je exact weet wat er gaat gebeuren als je het in productie start. Het bouwen van die log functie, analiseren van de output en oplossing van de gevonden problemen zit ook binnen diezelfde ene dag?
Nog een ander ding aan TS: Gebruik nooit een csv (plain text) met personeelsdata. Spreek vanuit het script een view aan in de HR DB of de meeste (grotere) HR oplossingen hebben een API waar je tegen aan kan scripten.

Het als enige hebben van kennis van een essentieel proces binnen een bedrijf maakt iets niet meteen waardeloos maar het vormt een risico. Als na het vertrek van diegene het script een foutmelding geeft, grijpen ze mis.
Hoe groter en langer een script is, hoe minder waardevol in-script-comments zijn, omdat ze alleen lokale functies beschrijven en bijna nooit inzicht geven in de opbouw van het script. ik ben nog nooit script documentatie gelezen die dat probleem adresseert. Ook die documentatie schrijf je in diezelfde dag?
Bovendien worden er met zon script extra eisen gesteld aan diegene die taak van de vertrokken beheerder overneemt, geavanceerd scripter. Dat maakt het vervullen van een vacature nog moeilijker.
Dat risico loopt men als er custom one-of-a-kind script oplossing wordt gebruikt.

Ik ken de kracht van powershell wel, ik heb enkele jaren geleden voor het verschijnen van DSC een oplossing gebouwd voor het deployen van 20+ Hyper-V clusters. waarin storage, netwerkkaarten, virtual switches, hardware model afhankelijkheid, tussentijds rebooten, alles volledig automatisch geconfigureerd, en bij elke stap zat fout afvanging en een resume functie.
Echter na het inrichten van deze 20+ clusters vervult dit script geen grote rol meer. Het sporadisch opnieuw opbouwen van een server na het vervangen van een blade server doet dat script prima. maar verder is het script dood.
Na die opdracht ben ik bij een andere opdrachtgever ander werk gaan doen en heb nooit 1 telefoontje gehad met vragen over dat script. Het maken van dat script kostte 3 maanden werk.

Scripting is voor mij een tool om een eindige functie te vergemakkelijken zoals een migratie, permanent gebruik van scripts vermijd ik. Permanente scripts worden al snel een houtje-touwtje oplossing, die bij de eerste de beste migratie/upgrade stuk gaan.

[SirDarkAngel]

_{Ik vraag me af hoe je daar 3 maanden over gedaan hebt.}

Daarbij vraagt de topic starter om het aanmaken van een gebruikers account en een mailbox. Wat is er precies mis met een CSV bestand laten generen? Aan de hand van de gegevens een SAM/UPN/Alias te generen en met wat simpele regels een gebruiker en mailbox aan te maken? Dat script is vervolgens leesbaar voor iedereen, want geen rocket science. Je bent binnen een (halve) dag klaar en het voldoet aan de wensen. Hoe haalt zo'n script mogelijk een AD overhoop? Wat voor commando's wil je gaan gebruiken dat dat mogelijk is?

Het is echt GoT op zijn best deze dagen. Iemand vraagt om een makkelijke/automatische manier gebruikers account te laten creëren en het lijdt tot guidelines om een compleet gebruikers account management systeem te maken inclusief gebruik van API’s van het HR systeem en een RBAC systeem wat er blijkbaar bij verzonnen wordt. Software voor dat soort taken zijn er genoeg en kosten minder dan het zelf ontwikkelen, maar er werd gevraagd om een script om gebruikers en een mailbox aan te maken.

[Yarisken]

Hallo SirDarkAngel, ik heb wel gevraagd of er "betere" manieren waren om een account + mailbox aan te maken via csv.
Persoonlijk vind ik de reply's wel heel interessant :-). Het gaat idd wel veel verder dan ik nodig heb op dit moment.

@Sem-x, via een api naar het HR systeem is een no-go :-). Dat is echt een rommelbak. In AD staan alle gebruikers juist met wie hun manager is, welke locatie ze werken, wat hun functie is etc... . Als we dat zouden syncen :-).

Thx voor de reply's allemaal. Wat ik meeneem is dat het toch complexer is als ik dacht. Aan fout afvanging heb ik niet veel aandacht besteed en aan al de mogelijkheden om een nieuwe gebruiker direct in een groep te zetten etc.. ook niet.
Ik moet nu nog is nadenken hoever ik wil gaan. Het gaat niet over 200 gebruikers per maand. Eerder 5 a 10.

[Question Mark]

SirDarkAngel schreef op donderdag 10 september 2015 @ 15:25:
Software voor dat soort taken zijn er genoeg en kosten minder dan het zelf ontwikkelen, maar er werd gevraagd om een script om gebruikers en een mailbox aan te maken.

Dat mensen vaak een uitgebreider antwoord geven dan de originele vraag komt omdat de mensen die reageren vaak wel wat ervaringen hebben met dit soort systemen.

Dit soort systemen groeien ook vaak. Nu wordt er gevraagd om een systeem om nieuwe users aan te maken. Stel TS bouwt dat en het werkt prima.

• Een maand later wil HR ook een functie om persoonsleden te disablen
• Nog een maand later wil HR ook een functie om persoonsleden te verwijderen, en mail laten doorsturen naar collega's
• Ohwja, HR wil ook namen van medewerkers kunnen wijzigen

Het hele simpele tooltje van TS is nu ineens integraal onderdeel van het HR proces. Dit heeft gewoon invloed op security, beschikbaarheid, logging, etc. Dat zijn wel zaken die vooraf goed overwogen moeten worden.

[SirDarkAngel]

<sub>@Yarisken
True, maar van een betere manier voor een account/maibox via een CSV naar een script welke gaat hangen aan een API van de HR systeem is wel een hele grote stap. Dat is als een vraag hoe je de 5 km welke je elke dag naar een station moet fietsen aangenamer kan maken en als suggestie "een Tesla kopen" krijgt aangeboden.

@Question Mark
Uitgebreider antwoord jep, maar er wordt vaak zoveel bij verzonnen, en door andere het moeilijker/professioneler gemaakt dan de initiële vraag dat je de topicstarter niet meer terug ziet, omdat de initiële vraag verloren gaat. (Hoe interessant de discussies uiteindelijk ook worden)

Anyway, dit helpt de inhoudelijke discussie ook niet dus om maar on-topic te reageren:</sub>


Welke tool/script je ook aan gaat bieden. Zorg voor een duidelijke scope en communicatie. Dan weet HR wat ze kunnen verwachten en krijg je niet de vragen welke Mark neerzet. Wil HR een uitgebreider systeem, dan kan dat, maar moet dat worden aangeschaft en mag HR voor budget zorgen. Deze tool moet jou ontlasten en dat HR daar ook een voordeel door krijgt (het snel krijgen van een gebruikersaccount) is mooi mee genomen voor hun. Maak dat inderdaad vooraf duidelijk, want daar zit inderdaad een goede valkuil.

[Yarisken]

Klopt Mark en SirDarkAngel, dit begint simpel om complex te eindigen.
De reden dat ik het ook via csv wilde is omdat ik wat huiverig ben om zomaar changes toe te laten op AD. Ik ben nogal voorzichtig van aard :-).
Met een csv heb ik nog controle.
Soit ik ga er nog wat over nadenken.
Thx allemaal.

[Wim-Bart]

akimosan schreef op woensdag 09 september 2015 @ 19:32:
[...]


Heb je hier een bron van? Bij een opdrachtgever weet ik dat deze link gebruikt wordt namelijk.

Mag het wel met een "hash" van de BSN? Het BSN zelf wordt niet vastgelegd maar een encrypted versie hiervan wel.

Zolang het niet decrypted kan worden mag het, maar kan het wel decrypted worden dan mag het niet. Oplossing is gewoon, personeelsnummer gebruiken :-)

[Wim-Bart]

Je kan ook kijken naar:
http://www.ressoftware.co...e-suite-2015/architecture koppel je personeelssysteem mee aan alle services die je maar wil. Werknemer wordt ingevoerd, res pakt het op, bepaald aan de hand van regels (rbac) welke groepen een gebruiker moet hebben bijvoorbeeld, maakt users aan in verschillende systemen zoals ad, sql, oracle, Linux et cetera volgens eigen regels.

Je kan ook kijken naar: https://www.tools4ever.nl...cess-management-software/ Ook een heel goed product, kan je bepaalde acties bij eindgebruikers neerleggen.