Lijkt me dat je lokale beheerswachtwoorden gewoon niet moet willen gebruiken in een omgeving met 2600 servertjes, hooguit als laatste redmiddel. En dan is een 20-tekens willekeurig wachtwoord in een verzegelde envelop in een kluis een prima oplossing. Als je desondanks bang bent voor misbruik zet je maar een alert op het gebruik van deze niet-te-gebruiken logins. Niet moeilijk gaan doen met maandelijks veranderen, dat doe je maar met je dagelijks-gebruik beheerswachtwoorden, en die kunnen mooi in een gecentraliseerd systeem. Het systeem moet wel werkbaar blijven.

Sommige organisaties doen het zo voor Windows:
Hernoem de locale administrator naar iets onzinnigs (random karakters). Geef deze een wachtwoord, die niet met Ophcrack te achterhalen is.
Maak een nieuwe administrator zonder rechten.

Doe het beheer met een domain-admin account. Open geen mail met dergelijke accounts, maar geef de administrators een extra normaal account voor het openen van mail.

"Hernoem de locale administrator naar iets onzinnigs (random karakters). Geef deze een wachtwoord, die niet met Ophcrack te achterhalen is.
Maak een nieuwe administrator zonder rechten."


Dit heeft weinig tot geen effect; in principe is elk wachtwoord te kraken met Lopht als je maar lang genoeg wacht.

het hernoemen heeft ook weinig zin; bij het enumeraten van de accounts op een server zie je direct welk account de echte administrator is; (Security ID) eindigt op 500.
uit ervaring zou ik eerst enumeraten voor ik een bruteforce los zou laten om de hoeveelheid werk te beperken.

Voor de rest heeft Yobi wel gelijk; al admin niet aanloggen met extra rechten anders dan de mogelijkheid om een remote desktop naar een stepstone server te verbinden.


Uitgaande van het feit dat alle servers in AD staan kun je eenvoudig een script gebruiken wat alle computer accounts list en dat dan gebruikt om remote de machines te benaderen en het wachtwoord te wijzigen; geen rocketscience. Een wachtwoord gebaseerd op input + machinenaam = nieuwe wachtwoord oid


Voor standalone servers kun je een inputfile gebruiken met dezelfde functionaliteit.

Niet goedkoop, wel erg goed: Cyber-Ark Enterprise Password Vault.

Het is in feite een wachtwoord kluis met daarbij de mogelijkheid om die wachtwoorden geheel geautomatiseerd te beheren op de achterliggende systemen. Via de front end kunnen eindgebruikers toegang krijgen tot een of meerdere passwords.

Het kan accounts op veel platforms beheren zoals Active Directory, lokale Windows servers, Unix Linux etc., maar voor databases, appliances (firewalls etc.) maar de lijst is veel langer.

Enorme mogelijkheden met parameterisering, policies, gebruik van groepsgewijze wachtwoorden, verschillende authenticatie methodes voor eindgebruikers (= administrators), multifactor authenticatie etc.

Ik ben al zo'n 2 jaar bezig met de implementatie hiervan in meerdere grote internationale organisaties.
Implementatie vergt zeker de nodige inspanning, maar dat mag duidelijk zijn met zo veel mogelijkheden.

Voor resp. *nix en de routers hebben wij gewoon authoriatie op basis van openldap cq. radius/AAA. Centraliseren die inlog's dus. En anders is er nog iets als puppet, cfengine en familieleden.

Je noemt 600 systemen. Als je nog nooit over dit soort 'randspul' eromheen hebt nagedacht, dan doen jullie jezelf al jaren tekort.

Aan windows opmerkingen brandt ik mijn vingers in dit forum niet.

De echte oplossing voor dit soort zaken zit hem in dit soort produkten:

http://www.ca.com/us/privileged-user.aspx

Nee ik heb geen aandelen en ik werk er ook niet, er zijn vast meer alternatieven.

Wij doen dit maandelijks met powershell op Windows servers.
En het password is telkens random aangemaakt voor een bepaalde groep servers (Exchange, SQL, SCCM, etc).
Ik zou ook de passwords op Linux en Windows servers verschillend houden.

$strcomputers = Get-Content d:\scripts\passwords\servers.txt
foreach ($strcomputer in $strcomputers) {
$admin=[adsi]("WinNT://" + $strComputer + "/Administrator") `
$admin.psbase.invoke("SetPassword", "Password") }

Gebruik smart cards. Met op de smart card gegenereerde sleutelparen. Certificeer de publieke sleutels. Distribueer de publieke sleutels. Vergeet wachtwoorden. Onthou je PIN. Helaas niet overal toepasbaar (luister je, Apple?).

Bedank allemaal voor de vele reacties, Omdat Cyber-Ark Enterprise Password Vault. toch behoorlijk prijzig was hebben we een pilot gedaan met password manager pro, waar we alle onpersoonlijke accounts in wilden plaatsen. Omdat PMP voor een dergelijke grote omgeving te licht is (het beheer zou een nachtmerrie worden) hebben we het project na de pilot niet gecontinueerd. Ik ga ook kijken naar het product van anoniem 15:29. Verder deel ik de mening dat we alleen via domein beheeraccounts en niet via lokale beheeraccounts moeten inloggen, Voor sommige systemen zoals profilemachines voor Citrix , standalone en DMZ servers moeten we toch iets bedenken.

Ik heb ook aan powershell gedacht en dan via remote administration. alleen voor DMZ server wordt dit lastig door de communicatie via wmi met wisselende poorten. We zitten nog niet op 2012 die gebruik maakt van CIM (http(s)

Het idee wat ik had is het volgende: Bij ons is HP-OM de standaard monitoringtool. Op alle Windows en *nix systemen staan de HP-OM agents. Via de centrale HP-OM console kunnen we allemaal scripts afvuren op (groepen) machines. Mijn idee is om een script te schrijven die de wachtwoorden van alle systemen middels een scheduled job in HP-OM afvuurt naar groepen systemen. Hierdoor voldoe ik aan de eis dat er 1 methodiek moet zijn voor alle systemen. Als is het script voor *nix uiteraard anders dan voor Windows, en dat deel laat ik graag aan onze *nix beheerders over (Ik zit zelf in een Windows beheerteam). De volgende vraag die ik heb is of de communicatie tussen HP-OM en de machines secure is, anders moet ik hier ook iets voor gaan regelen. Het moet allemaal wel allemaal secure.