Inofficiell Guide till säkerhet i Microsoft Dynamics SL 7.0


Det här dokumentet tillhandahålls AS-är och är avsedd att hjälpa Förstå säkerhet strukturen av SL 7.0-databaser. Feedback är Välkommen på detta dokument, fel eller utelämnanden inte utgör en defekt i produkten.  

Informationen i det här dokumentet kommer från observerar databasstrukturen i SQL Management Studio och kör spår av olika processer i SQL Profiler. Ingår ingen information som härrör från kompilerad kod.

Om inte annat anges är informationen i detta dokument antar användning av "Verifiering".

 

 

Innehåll:

SQL-användare och roller:

07718158D19D4f5f9D23B55DBF5DF1- Kallas även "The superanvändare entiteten". Det här kontot ska visas som inaktiverade.  Inloggningen skapas genom databasunderhåll som "icke-interaktiva", vilket innebär att du inte kan logga in med det här kontot.  Den används endast för personifiering inom SL.

Detta användar-id används när en lagrad procedur som behöver åtkomst till objekt i databasen systemet SL och SL. Pp_cleanwrkrelease lagrad procedur är ett bra exempel. Denna procedur körs ett delete-uttryck från en tabell i SL programdatabasen utifrån informationen i Access-tabellen i databasen för SL-systemet. (Den lagrade proceduren blir till Access-tabell med hjälp av vyn VS_Access i app-databasen). Inom proceduren är ett uttryck som ser ut så här:

MED Kör som "07718158D19D4f5f9D23B55DBF5DF1"

Detta betyder att istället för att använda vår windows-inloggning som får sina rättigheter från rollen MSDSL program vi ska personifiera användaren 07718158D19D4f5f9D23B55DBF5DF1 när du kör det här en proc. detta behövs eftersom SQL-tillämpningsroller (som MSDSL) inte fungerar över databaser. Om personifiering "Med kör" inte användes, vi skulle få följande felmeddelande:

---------------------------
SQL Server-meddelande 916
---------------------------
Servern huvudsakliga "domän\användarnamn" går inte att komma åt databasen "SLSYS" under den aktuella säkerhetskontexten.
---------------------------
OK  
---------------------------

07718158D19D4f5f9D23B55DBF5DF1 användare har åtkomst till de flesta vyerna vs_ och några av tabellerna i programdatabasen SL och de flesta av tabellerna i databasen för SL-systemet. 07718158D19D4f5f9D23B55DBF5DF1 användaren eller personifiering också relaterar till databasens ägare på grund av ägande chaining. Ägare av System för SL och SL-databaser behöver matcha... om de inte och du får det här felet:

---------------------------
SQL Server-meddelande 916
---------------------------
Huvudmannen server "07718158D19D4f5f9D23B55DBF5DF1" är inte kan komma åt databasen "SLSYS" under den aktuella säkerhetskontexten.
---------------------------
OK  
---------------------------

Det verkar inte roll som databasens ägare så länge som alla SL-program och databaser för SL-systemet har samma ägare. Finns i "Databasens ägare" avsnittet Mer information. Se även http://msdn2.microsoft.com/en-us/library/ms188676.aspx för mer information om ägarskap chaining.

 

E7F575915A2E4897A517779C0DD7CE- Kallas också "För användaren". Detta användar-ID används tillsammans med en ODBC-anslutning och ditt användar-ID för windows för att köra Crystal Reports. Användaren verkar ha Välj rättigheter till alla tabeller och vyer och köra rättigheter för alla lagrade procedurer i databaser för SL-systemet och SL.  

Användaren måste välja/köra behörighet för alla anpassade objekt som används i en anpassad rapport eller får du följande felmeddelande:

---------------------------
Crystal rapporter hjälpprogram för Solomon IV
---------------------------
Det gick inte att hämta SQL-fråga

Rapport: C:\Program Files\Microsoft Dynamics SL\Usr_Rpts\03730DET. RPTHUVUD

Skriv ut Crystal motorfel: 709 - fel i filen C:\Program Files\Microsoft Dynamics SL\Usr_Rpts\03730DET. RPTHUVUD:

Tabellen kunde inte hittas.
---------------------------
OK  
---------------------------

Om kontot är inaktiverat eller om kontots lösenord har ändrats, får du följande felmeddelande när du kör en rapport:

---------------------------
Crystal rapporter hjälpprogram för Solomon IV
---------------------------
Det gick inte att hämta SQL-fråga

Rapport: C:\Program Files\Microsoft Dynamics\SL\Applications\GL\01650.RPT

Skriv ut Crystal motorfel: 536 - fel i filen C:\Program Files\Microsoft Dynamics\SL\Applications\GL\01650.RPT:

Det går inte att ansluta: felaktig inloggning parametrar.
---------------------------
OK  
---------------------------

 

MASTER60SP- Master användaren från SL 6.0 SP1 - SL 6.5 säkerhetsmodellen. Användaren fortfarande används om kör SL 7.0 under "SQL-autentisering". i en databas windows autentiseras användaren finns inte normalt och inte används. Användaren är ungefär motsvarar "Master" användaren i 6.0 SL och äldre.

I en databas med windows-autentiserade är master60sp användaren ägare till databasen program för SL och SL ger fullständig kontroll över alla objekt i dessa databaser. All kontakt mellan SL skärmar och rapporter görs även om användaren master60sp... windows user ID inte används alls. Användarens lösenord kan ändras genom att gå till skärmen databasadministration (98.270.00) i SL.

Användaren är också fortfarande används i FRx. detta kan vara ett problem Eftersom i en databas windows autentiseras användaren master60sp inte finns. KB 941591 förklarar hur du kan kringgå det här problemet.

 

Användare med CD7359B5576446f85EB67E824B4770- "Ett" användaren från SL 6.0 SP1 - 6.5 säkerhetsmodellen. Användaren används också om du kör SL 7.0 under "SQL-autentisering". I en SL-7.0 windows autentiseras databas, användaren finns inte normalt och inte används. Användaren är ungefär motsvarar "MasterRO"-användaren i 6.0 SL och äldre.

Användaren har endast åtkomst till systemdatabasen. Det inte ha rättigheter till programdatabasen eller så kan du få problemet som beskrivs i KB 896321. Kan välja från flera olika tabeller och köra flera lagrade procedurer. Kan också infoga/Uppdatera/ta bort i tabellen domän- och rptextra.  

Under inloggningsprocessen utför CD7359B5576446f85EB67E824B4770 användaren följande uppgifter:

  • Kontrollerar vilken version av SQL
  • Certifikatversionen SL-databas
  • Kontroller för registrering nycklar
  • Hämtar en lista över företag i databasen
  • Händer på behandling av master60sp användare

 

MSDynamicsSL databasrollen- Alla SL användare är medlem i rollen. Roll i SL systemdatabas har körbehörighet till getAuthenticationType, GetInfo, och getVersion lagrade procedurer på systemdatabasen. Roll i programdatabasen SL har ingen behörighet. Det är inte känt vad är syftet med den här rollen fungerar i SL programdatabasen. Om användare är en medlem av databasrollen MSDynamicsSL på SL-systemet DB eller om MSDynamicsSL databasroll på SL-systemet saknar körbehörighet till getauthenticationtype lagrad procedur, sedan inloggning. EXE att krascha när icke-administratörer att logga in på SL.

 

Roll för tillämpningen av MSDSL- Den här rollen har behörighet för alla objekt i databasen.  

Betydelsen av denna som en roll "program" i stället för en normal "databas" roll är att behörigheten gäller bara när åtkomst till databasen från SL- programmet. Så att även om användaren kan ha rättigheter att lägga till ett nytt konto i fönstret diagram konton Underhåll i SL, de inte har behörighet att köra ett INSERT-kommando på kontot tabell i SQL Server Management Studio.

Rollen är specifik databas... vilket innebär att MSDSL roll i en databas är inte samma roll som rollen MSDSL i en annan databas även om de heter samma sak. "MSDSL"-rollen i programdatabasen SL har behörighet över objekten i databasen. Och "MSDSL"-rollen i databasen för SL-systemet har behörighet över objekten i systemdatabasen.  

Lösenordet för den här rollen är felaktigt, kan orsaka följande felmeddelande vid inloggning (synkronisera äganderätt och säkerhet scenario rättar detta om det inte finns flera SL systemdatabaser som pekar till samma programdatabasen):

---------------------------
INLOGGNING
---------------------------
Allvarligt SQL fel 15161 vid inloggning företag
---------------------------
OK  
---------------------------

Om sync scenario inte rättar felet, sedan du manuellt gå igenom varje databas i SQLServer och kör du följande för att se om det råkar finnas flera system DBs peka på samma app DB.  Om du tycker att detta ska vara fallet i systemet DBs behöver avlägsnas eller åtminstone slutat gilla från app DB.

Väljdatabasnamn, * fråndomän
Väljdatabasnamn, * frånföretag

Ger- En annan förändring i 7.0 är användarens windows-inloggningar läggs nu till i SQL-databasen. Du kan se detta SQL Management Studio genom att expandera på en SL-databaser -> Säkerhet -> användare. Användarkontona som inte har något av sin egen behörighet, de få några rättigheter genom att vara medlem i rollen som MSDynamicsSL, men rättigheterna som beviljas huvudsakligen av SL med rollen MSDSL tillämpning. Undantaget är om användaren är medlem i gruppen Administratörer på SL. Finns i avsnittet i "SL Groups" nedan för mer info.

Genom att ha användarkonton i SQL, kommer användarna har behörighet att logga in på SQL Server Management Studio utan att behöva känna till lösenordet för "sa". Som tur eftersom tillämpningsroller används har inte behörighet att faktiskt göra någonting efter att du loggat modulen

 

BusinessPortalUser- Den här SQL Server-användare skapas när du installerar Business Portal. Används för samverkan mellan business portal och SQL. Har inga egna rättigheter. Får sin ström från att vara en medlem av databasrollen BFGROUP.  

 

Databasrollen för BFGROUP- Denna roll används för att ge "SELECT, UPDATE, INSERT, DELETE" behörigheter till alla SL-objekt. I BusinessPortalUser bör vara den enda medlemmen i den här rollen. Ibland rollen inte har rätt behörighet till olika objekt som kan orsaka fel i business portal. Mer information finns i KB 906715.

SL-grupper:

Gruppen Administratörer- Som namnet antyder är medlem i den här gruppen ger användaren administratörsbehörighet i SL. alla medlemmar i gruppen blir detsamma som "SYSADMIN" användaren i tidigare versioner. Individuella rättigheter inte har tilldelats till gruppen "Administratörer" Access Rights Underhåll skärmen... i stället som en medlem i gruppen automatiskt ger fullständig behörighet för alla raster och rapporter.

Som medlem i gruppen Administratörer ger också vissa ytterligare behörigheter:

  • Endast administratörer kan se gruppen standard "Administration" modul i menyn
  • Endast administratörer kan lägga till nya användare i systemet
  • Administratörer ges automatiskt "sysadmin"-serverrollen på SQL-servern. Det är viktigt att känna till eftersom användaren kommer nu att kunna logga in på SQL Server Management Studio och utföra alla uppgifter i en databas.
    • Anmärkning: Till debatten om detta är bättre/ändras på 7.0 Fp1 med "ge användarbehörighet att skapa SQL server-inloggningar och användare"

Detta innebär bör medlemskap i gruppen begränsas till att endast de användare som behöver den absolut.

 

Alla grupp- Motsatsen till vad namnet antyder att alla användare inte är automatiskt medlem av gruppen "alla" grupp. Måste du manuellt lägga till nya användare alla grupp. Som standard den här gruppen används för att ge användarna på menyn standard. Gruppen ger inte någon behörighet som standard.

Du synkronisera alla ägare & Security Update Scenario:

I det här scenariot i databasunderhåll (98.290.00) kan lösa olika problem och bör första steget i felsökningen all säkerhet eller närliggande problem att logga in. När du kör scenariot synkroniseras alla databaser som finns på servern, oavsett vilka en väljs i databasunderhåll. Här finns information om vad processen innebär:

· Windows autentiseras databaser

o   Anger DB-ägare

§  I 7.0 anges ägare till inloggning ID används för att logga in på databasunderhåll.  

§  I 7.0 SP1 är ägare inställd på "sa"

o   Skapar 07718158D19D4f5f9D23B55DBF5DF1 och E7F575915A2E4897A517779C0DD7CE användare på SQL Server endast om de saknas.

o   Sjunker sedan lägger E7F575915A2E4897A517779C0DD7CE användaren från systemet för SL och SL-databaser.

o   Beviljar rättigheter till E7F575915A2E4897A517779C0DD7CE användare.

o   Beviljar rättigheter till 07718158D19D4f5f9D23B55DBF5DF1 användare.

o   Ställer in egenskapen säker på systemet SL och SL-databaser till TRUE.

o   Skapar rollen MSDynamicsSL databasen om det saknas och tilldelas rättigheter men inte igen till en användare till rollen. Se bug 15135.

§  I SL 7.0 endast skapas igen rollen i databasen för SL-systemet

§  I SL 7.0 Sp1 återskapas den rollen i systemet för SL och SL-databaser.  

o   Skapar rollen MSDSL tillämpning på System och program DBs endast om de saknas

o   Tilldelar rättigheter för rollen MSDSL i DB-systemet. På grund av programfel 15053 rättigheter inte tilldelas rollen MSDSL i app db om rollen som saknades. Detta kan leda till ett Systemmeddelande 10232 vid inloggning. Se bugg i lösningen.

o   Återställer och synkroniserar MSDSL app roll lösenord.

o   Återställer E7F575915A2E4897A517779C0DD7CE användarens lösenord.

o   Återställer 07718158D19D4f5f9D23B55DBF5DF1 användarens lösenord.

· SQL-autentiserad databaser

o   Anger ägaren av systemet för SL och SL-databaser till master60sp.

o   Skapar master60sp-användare på servern om saknas.

o   Skapar CD7359B5576446f85EB67E824B4770 användaren om saknas.

o   Sjunker sedan lägger CD7359B5576446f85EB67E824B4770 användaren från systemet för SL och SL-databaser.

o   Beviljar rättigheter till CD7359B5576446f85EB67E824B4770 användare.

o   Ställer in egenskapen säker på systemet SL och SL-databaser till TRUE.

o   Synkroniserar lösenord för master60sp.

o   Återställer CD7359B5576446f85EB67E824B4770 användarens lösenord.

Databasens ägare:

Databasens ägare får anges under databasunderhåll (98.290.00). i version 6.0 Sp1 – 6.5 eller SL 7.0 använder SQL-autentisering, ägaren av databasen är master60sp. SL-7.0, ägare av databaser ska anges till användar-ID för inloggning till databasunderhåll. I SL 7.0 Service Pack 1, ägare av databaser att få in som sa.

Databasens ägare ärver full kontroll över alla objekt i databasen. Det vanligtvis spelar ingen roll som ägare av databaser så länge samma användare äger alla SL-databaser. Det finns ett undantag. Om databasens ägare är en domänanvändare och för vissa skäl SQL Server har problem att kontakta en domänkontrollant visas kanske följande felmeddelande i en mängd olika platser:

---------------------------
SQL Server-meddelande 15404
---------------------------
Kunde inte hämta information om Windows NT grupp/användare domän\användarnamn, felkod 0x54b.
---------------------------
OK  
---------------------------

För att bli ägare till databasen kan inte redan vara en användare i databasen. Detta har potential att orsaka följande fel i databasunderhåll:

---------------------------
9829000
---------------------------
SetOwner fel-2147206394: [Microsoft] [ODBC SQL Server Driver] [SQL Server] föreslagna nya databasägaren är redan en användare eller alias i databasen.
---------------------------
OK  
---------------------------

Mer information om felet finns i KB 942450.

För att undvika detta bör du göra ägare av databaser som SQL-användaren som "sa" (vilket sker automatiskt i 7.0 servicepack 1)

 

 

Diverse:

SQL Server-tjänstkontot. Kontot kan vara ett konto, men det måste ha läsbehörighet för user-kontoobjekt i active directory. Annat får du följande felmeddelande när du försöker lägga till användare i SL:

---------------------------
SQL Server-meddelande 15404
---------------------------
Kunde inte hämta information om Windows NT grupp/användare domän\användarnamn, felkod 0x54b.
---------------------------
OK  
---------------------------

SQL Server-tjänstkontot kan ställas in genom att gå till Start -> Inställningar -> Kontrollpanelen -> Administrationsverktyg -> tjänster. Rulla ned till "SQL Server (MSSQLSERVER)", höger Klicka och välj Egenskaper. Klicka sedan på fliken inloggning.

ODBC-anslutningar. När du kör en crystal-rapport på en ny arbetsstation första en ODBC-anslutning skapas för SL-systemet och SL-databaser på fliken användar-DSN på datakällor (ODBC). Den här anslutningen ska vara inställd på att använda SQL-autentisering, även om du använder Windows-autentisering för att logga in på Dynamics SL. om anslutningen ändras om du vill använda windows-autentisering eller en System-DSN läggs och använder windows-autentisering, kan användare se följande fel:

---------------------------
Crystal rapporter hjälpprogram för Solomon IV
---------------------------
Det gick inte att hämta SQL-fråga
Rapport: C:\Program Files\Microsoft Dynamics\SL\Applications\GL\01720.RPT
Skriv ut Crystal motorfel: 709 - fel i filen C:\Program Files\Microsoft Dynamics\SL\Applications\GL\01720.RPT:
Tabellen kunde inte hittas.
---------------------------
OK  
---------------------------

Det är säkert att ta bort användar-DSN-poster som skapas de automatiskt igen. Du kan visa transaktioner genom att gå till Start -> Kontrollpanelen -> Administrationsverktyg -> datakällor (ODBC).

 

Egenskapen "Trustworthy" i databasen. Det verkar vara något nytt i SQL 2005. När en databas är först kopplat till en SQL Server, egenskapen "säker" i databasen anges till FALSE. Detta innebär att alla objekt i databasen som försöker få åtkomst till objekt i en annan databas (t ex vs_company i programdatabasen SL) misslyckas. Detta kan leda till följande felmeddelande i en mängd olika platser, inklusive öppna skärmar i SL:

---------------------------
SQL Server-meddelande 916
---------------------------
Huvudmannen server "07718158D19D4f5f9D23B55DBF5DF1" är inte kan komma åt databasen "SLSYS" under den aktuella säkerhetskontexten.
---------------------------
OK  
---------------------------

Du kan se aktuell status för egenskapen genom att gå till SQL Server Management Studio -> höger Klicka på databasen -> Välj Egenskaper -> Mappalternativ. Den pålitliga egenskap är under avsnittet Miscellaneous.  

Synkronisera alla ägare & säkerhet databas Underhåll scenario visas om du vill ange värdet SANT för alla SL-databaser.

Mer information hittar du här:

http://msdn2.microsoft.com/en-us/library/ms187861.aspx

 

Lägga till användare på skärmen användarunderhåll. Även om en användare har uppdatera, infoga, ta bort rättigheter till skärmen Underhåll användare (98.260.00) inte fortfarande kan lägga till nya användare eller lägga till användare i gruppen Administratörer. När du försöker ange Windows-användarnamn och fliken ut får du följande felmeddelande:

---------------------------
SQL Server-meddelande 229
---------------------------
EXECUTE-behörighet nekades på objektet 'xp_logininfo', databasen mssqlsystemresource, schema sys.
---------------------------
OK  
---------------------------

Om du försöker lägga till en användare i gruppen Administratörer får du följande felmeddelande:

---------------------------
SQL Server-meddelande 15247
---------------------------
Användaren har inte behörighet att utföra den här åtgärden.
---------------------------
OK  
---------------------------

Du måste vara i gruppen Administratörer för SL att lägga till användare eller lägga till användare i gruppen Administratörer. När du lägger till ett nytt användar-ID, processen faktiskt lägger till windows-användare som en ny SQL Server-användare. Detta kräver en förhöjd nivå av SQL-rättigheter som inte ger enbart MSDSL roll. Så måste du vara i SL-administratörsgruppen.

 

Flytta databaser till en ny server. i en databas windows autentiseras varje windows-inloggning för användare som ID läggs till i SQL Server under SQL Server -> Säkerhet -> inloggningar. De inloggningar läggs sedan till databasen under SLDATABASE -> Säkerhet -> användare. , Men om du säkerhetskopierar databasen och återställa den till en ny server inloggnings-ID läggs inte automatiskt till SQL Server. Så att inloggnings-ID i databasen är överbliven. Se bug 15024 som bör åtgärdas i 7.0 FP1. Om du vill rätta till detta måste du köra följande skript mot SL System DB på den nya servern. Om du inte gör detta kommer användare "inloggning. EXE har stött på ett problem och måste avslutas. Vi beklagar besväret"fel när du försöker logga in

deklarera @windowsuseracct som char(85)
deklarera @execString som char(200)
DEKLARERA user_cursor MARKÖREN för
Välj olika windowsuseracct från userrec
kvar koppling sys.server_principals slogins på userrec.windowsuseracct=slogins.name
om windowsuseracct <>'' och slogins.name är null
       OPEN user_cursor
Hämta nästa från user_cursor INTO @windowsuseracct
När @@FETCH_STATUS = 0
       BEGIN
ange @execString = skapa inloggning + QUOTENAME (rtrim(@windowsuseracct)) + "Från WINDOWS med DEFAULT_DATABASE = [Original]"
              exec (@execString)
Hämta nästa från user_cursor INTO @windowsuseracct
       END
Stäng user_cursor
DEALLOCATE user_cursor