Frågan#1
Någon som vet hur man fixar så jag slipper skriva in lösenord och trycka på enter(inloggnings rutan som med windows) vid start av win2k3 server standard edition?
Skulle vara tacksam för svar.
Slippa inloggningsrutan i win2k3?
22 svar · 860 visningar · startad av joxxe
The information in this article applies to:
Microsoft Windows XP Home Edition
Microsoft Windows XP Professional
Microsoft Windows XP 64-Bit Edition
INTE win2k3
Vad är syftet? :q
jag vill slippa logga in om servern skulle gå ner, tex idag gick den ner pga av elavbrott. sen upp igen men då startades ju inte alla program osv eftersom man måste logga in manuellt.
Se till så att de körs som services istället så slipper du äventyra säkerheten på servern.
hmm jo det kan jag ju göra, men endå, om jag verkligen vill...hur gör jag?
Flyttas från windows till nt.
joxxe skrev:
jag vill slippa logga in om servern skulle gå ner, tex idag gick den ner pga av elavbrott. sen upp igen men då startades ju inte alla program osv eftersom man måste logga in manuellt.
Vad kör du egentligen för program som kräver inloggning på en server!? :o :q
Men alltså, om jag stänger av min server. ( alltså stänger av strömmen typ) så måste man ju logga in på den när den startar upp. Skriva in lösenord etc. Sen när man gjort det kommer man ju in i windows, då startar alla program osv. Jag vill att den ska komma in i windows direkt utan att behöva skriva i lösen osv, som i tex windows XP. går det eller?
joxxe skrev:
The information in this article applies to:
Microsoft Windows XP Home Edition
Microsoft Windows XP Professional
Microsoft Windows XP 64-Bit EditionINTE win2k3
Jo. Det funkar till och med i NT 4. Varför inte bara prova?
Rikard skrev:
Att göra det du skriver om skulle jag tveklöst klassa som dumt.
Dum och dumt. Man kan ju alltid lägga ett anrop till:
rundll32.exe user32.dll, LockWorkStation
i en BAT-fil i autostart eller inne i en av applikationerna. Visst, lösenordet står fortfarande i klartext i registret, men det är ju å andra sidan bara tillgängligt för de som redan har behörighet (med rätt säkerhet på nycklarna).
Tycker personligen det är ett rätt smidigt sätt om man inte har tid/lust att skriva/avbugga precis varenda applikation som en äkta service.
Och därigenom har du publicerat ett kontonamn med administrativa rättigheter på nätet. ;)
Och därigenom har du publicerat ett kontonamn med administrativa rättigheter på nätet.
Om du med "nätet" menar ett (begränsat/privat) LAN och inte Internet så är det möjligt att du har rätt. Men du får gärna förklara hur. Hur kommer en användare som inte redan har administrativa rättigheter åt lösenordet (om registerrättigheterna är korrekta och "remote registry" eventuellt disablat)?
Om man är medveten om riskerna är det ju upp till en själv...
Det finns ju naturligtvis tillfällen då det inte är särskilt dumt även om tillfällena då det är dumt kanske är fler.
niko skrev:
Och därigenom har du publicerat ett kontonamn med administrativa rättigheter på nätet.
Om du med "nätet" menar ett (begränsat/privat) LAN och inte Internet så är det möjligt att du har rätt.
Pröva att köra följande kommando mot den "server" du har inloggad:
nbtstat -a \\datornamn
Titta särskilt på de rader som innehåller "<03> UNIQUE". Voilà, ett konto som uppenbarligen får logga in lokalt på servern.
Bra, då vet jag kontonamnet, då är det bara lösenord kvar.
Men du får gärna förklara hur. Hur kommer en användare som inte redan har administrativa rättigheter åt lösenordet (om registerrättigheterna är korrekta och "remote registry" eventuellt disablat)?
Det här är en fråga jag inte kan svara på i korta ordalag, men du kan ta nästan vilken säkerhetsbok eller hackerbok av lite klass så kommer du få ett flertal alternativa svar på din fråga. :)
Får jag föreslå Hacking Exposed?
Rikard skrev:
Bra, då vet jag kontonamnet, då är det bara lösenord kvar.
Ja, ja. Att man kan få fram kontonamnet tvivlar jag inte en sekund på.
Rikard skrev:
Det här är en fråga jag inte kan svara på i korta ordalag, men du kan ta nästan vilken säkerhetsbok eller hackerbok av lite klass så kommer du få ett flertal alternativa svar på din fråga.
Du får ursäkta men jag skulle gärna ta emot en konkret länk (om det finns nåt välkänt sätt). Jag ser det ungefär så här: Tar man bort läsrättigheter för alla utom System på nyckeln så borde(?) autoinloggingen fortfarande funka. Om en vanlig användare i nätet sen kan exekvera kod som System (och komma åt nyckeln) så har man ju ett säkerhetsproblem redan där.
Rikard skrev:
Och därigenom har du publicerat ett kontonamn med administrativa rättigheter på nätet.
Fast varför förutsätter du att man nödvändigtvis kör autoinloggningen mot ett konto med administrativa rättigheter? Det har ju ingen hävdat.
Någon bra länk har jag nog inte eftersom den mesta av kunskapen har införskaffats genom åren och genom böcker. Men jag ska försöka förklara varför, förhoppningsvis hyfsat pedagogiskt. ;)
Om det är "överdrivet pedagogiskt" så beror det främst på att jag försöker beskriva på en sådan nivå att även de utan din, som jag har uppfattat det, höga tekniska kompetens ska kunna förstå vad jag menar och varför. Jag vill även poängtera att jag beskriver detta ur ett serverperspektiv. I mina ögon är det stor skillnad på hur man hanterar en riktig server och en klient/arbetstation.
Låt mig börja med:
niko skrev:
Fast varför förutsätter du att man nödvändigtvis kör autoinloggningen mot ett konto med administrativa rättigheter? Det har ju ingen hävdat.
I normala fall har en vanlig användare synnerligen få rättigheter på en server. För att ett konto ska få logga in på en server måste det vara tilldelat rättigheten "Log on locally". Har ett konto eller en grupp den rättigheten kan man även logga in via en Terminal Services-session. (Det här kan vara ändrat i Windows 2003. Hmm..) En server som någon har fysisk åtkomst till är per definition osäker. Att kunna logga in via en terminal services-session är det som är närmst fysiskt åtkomst utan att fysiskt komma åt servern. Har man rättighet att logga in lokalt så har man öppnat möjligheten för en användare att spara filer och tillika köra filerna lokalt på servern. Om det är hackingprogram, trojaner eller något annat har du som administratör väldigt svårt för att kontrollera.
Av det skälet är rättigheten att logga in lokalt krafigt begränsad i samtliga windowsserver-miljöer. Om jag inte missminner mig så är det följande grupper som har rättigheten vid installation: Administrators, Backup Operators, Print Operators, Account Operators och så är det en till... Nåväl, Microsoft råder administratörer att frånta grupperna Account Operators och Print Operators denna rättighet, då den inte behövs för att administrera konton och/eller skrivarhantering.
Av detta kan vi dra slutsatsen att man ska undvika att ge konton rättigheter att logga in lokalt. Varför jag förutsätter att kontot som används för att logga in per automatik har någon form av administrativa rättigheter.
Det finns ytterligare argument varför ett sådant konto "måste" ha administrativa rättigheter. Något du, niko, redan har berört genom att skriva:
niko skrev:
Jag ser det ungefär så här: Tar man bort läsrättigheter för alla utom System på nyckeln så borde(?) autoinloggingen fortfarande funka. Om en vanlig användare i nätet sen kan exekvera kod som System (och komma åt nyckeln) så har man ju ett säkerhetsproblem redan där.
De flesta program som körs kräver någon form av rättigheter, både i registret och i filsystemet för att kunna lagra filer och variabler. Ett unikt konto som skapas, får vanliga användarrättigheter (users) samt rättigheten att logga in lokalt kommer med största sannolikhet inte att kunna köra ett program eftersom programmet använder sig av inloggad användares rättigheter både i registret och i filsystemet. Det här är något man även märker (i alla fall märkte) på arbetsstationer i kombination med Adobes produkter. Det var ett helvete att låta användaren vara vanlig användare (user inte power user) och köra Adobes program. D.v.s. för att programmet ska kunna köras kommer man, om man nu trots allt kör med en "vanlig användare", att tvingas göra en hel del rättighetsförändringar innan det kommer att fungera smärtfritt. Men, låt mig återkomma till detta dilemma.
Installerar man ett program som är gjort för att köras på en server frågar programmet under installationen i de flesta fall efter ett konto det kan använda sig av för att köras. Tyvärr ser man allt för ofta att program körs under kontot "administrator" vilket borde bestraffas med 1000 rader asp-kod. ;)
När nya applikationer ska köpas in hos oss på FHP har jag med följande checklista:
(det är ytterligare två punkter, men jag kommer inte ihåg de i huvudet och har inte listan här)
- Vilken typ av data skickas från klienten mot servern och vad innehåller den för data?
- Hur kommunicerar applikationen med klienten?
- Hur hanterar den autentiering?
- Har applikationen något eget säkerhetssystem?
- Vilka tjänster är applikationen beroende av?
- Hur ska applikationen hanteras? Kräver applikationen någon form av underhåll?
- Hur loggar den t.ex. till händelseloggen och vad?
- Vilka potentiella hot eller vilken sårbarhet kan vi utsättas för genom att låta applikationen installeras?
Kan leverantören inte svara på dessa frågor skickar jag ofta hem leverantörerna med hemläxa. Ja, jag har blivit idiotförklarad som kund ett par gånger. Men samtidigt vet jag att det finns en del leverantörer och programutvecklare som kan svara på detta. Och märkligt nog stiger man i aktning som kund hos dessa leverantörer - som kombinerar applikationsutveckling, kvalitetssäkring och säkerhetsfrågor i sina produkter.
Det är bara en tidsfråga innan majoriteten av kunderna kommer att kräva detta. Tyvärr tror jag att tiden är ett par år - minst...
Varför har vi ovanstående lista? Ja låt oss sätta det i följande situation:
"If the application has security holes, the best you can hope for is to slow the hackers down or limit the damage the attacker can do."
Vad händer om en applikation har rättigheter att skriva till hela registret, särskilt om applikationen har administrativa rättigheter! Hej och hå. In kommer en bugg, en trojan eller ett virus som får göra i stort sett vad som helst med servern. Servern är kompromentterad i bästa fall. I sämsta fall använder hackaren servern för att angripa resten av nätverket. Jag har sett en attack av det här slaget en enda gång och det är något som skrämmer mig. Har man inte sett det själv kanske man inte har respekten för effekterna...
Låt mig nu återgå till något som var uppe tidigare i denna avhandling:
Sätt rättighetsförändringarna jag talade om tidigare, för att ge ett vanligt användarkonto rättigheten att köra en applikation, i samband med kommentaren:
niko skrev:
Tycker personligen det är ett rätt smidigt sätt om man inte har tid/lust att skriva/avbugga precis varenda applikation som en äkta service.
Ska jag autoinlogga ett konto utan att ge det administrativa rättigheter kommer jag med stor sannolikhet att tvingas rota runt i registret och köra filemon/regmon* en bra stund innan det fungerar klockrent. Då väljer jag nog att kräva att programvaruleverantören fixar till sin, i mina ögon, slarvigt ihopslängda applikation istället för att lätta på säkerheten.
Puh, det här blev nog långt nog och då har jag ändå valt att utelämna saker som spårbarhet i register- och säkerhetsinställningar vilket ett gemensamt konto lätt leder till m.m.
Jag hoppas nu att mitt budskap framgår på ett lättförståeligt sätt trots att det fortfarande finns frågetecken som inte är uträtade.
*) applikationer du hittar på https://www.sysinternals.com
Jag reserverar mig för ev. skrivfel/stavfel och andra meningsbyggnadstjofräser - även i denna mening... ;)
Ja, nu misstänker jag att vi diskuterar ur ganska radikalt olika perspektiv. Jag menar ungefär så här:
Självfallet ska man så lång som möjligt i alla situationer undvika att strö klartextlösenord omkring sig. MEN (stort men) ibland uppkommer situationer då man måste köra en applikation (på en särskilt avsedd maskin) och inte kan/har möjlighet/får betalt för att köra/skriva den som en service. I det fallet menar jag nog att autoinloggning är en "OK" lösning som är (ungefär) så säker som man själv väljer att göra den: Man lägger upp ett konto med lokal inloggningsrätt med minimala, men tillräckliga, rättigheter (vilket trots allt är hyfsat lätt om man själv skrivit applikationen). Man begränsar läsrättigheterna på lösenordsnyckeln. Man kör med LockWorkStation (gärna på en timer).
Nästa fråga är, så klart, vad man lägger i ordet "server". Är det centralservern på riksbanken? En liten applikationsserver på Nisses plåtfirma? En hemmaserver? Jag uppfattar nog att joxxes fråga handlade om något som ligger närmast de två sista alternativen och ur det perspektivet menar jag nog trots allt att det inte är en särskilt "dum" lösning. Jag använder den ibland själv i de fall då det handlar om servrar som är avsatta enbart för "min" applikation och kunderna inte har några särskilda invändningar.