När du behöver omkonfigurera en befintlig Cognos -miljö för att använda en annan extern säkerhetskälla (t.ex. Active Directory, LDAP, etc) finns det en handfull metoder du kan ta. Jag gillar att kalla dem ”det goda, det onda och det fula”. Innan vi utforskar dessa goda, dåliga och fula tillvägagångssätt, låt oss ta en titt på några vanliga scenarier som tenderar att driva autentiseringens namnutrymmeändringar i en Cognos -miljö.
Vanliga affärsdrivrutiner:
Uppdaterar maskinvara eller operativsystem - Modernisering av BI -hårdvara/infrastruktur kan vara en frekvent drivrutin. Medan resten av Cognos kan köra som en mästare på din snygga nya hårdvara och moderna 64-bitars operativsystem, lycka till med att migrera din cirka 2005-version av Access Manager över till den nya plattformen. Access Manager (släpptes först med serie 7) är ett ärevärdigt kvarstående från tidigare dagar för många Cognos -kunder. Det är den enda anledningen till att många kunder behåller den där gamla gamla versionen av Windows Server 2003. Skrivet har funnits på väggen för Access Manager ganska länge. Det är äldre programvara. Ju tidigare du kan gå bort från det, desto bättre.
Standardisering av applikationer- Organisationer som vill konsolidera autentiseringen av alla sina applikationer mot en centralt administrerad företagskatalogserver (t.ex. LDAP, AD).
Fusioner och förvärv- Företag A köper företag B och behöver företag B: s Cognos -miljö för att peka på företagets katalogserver, utan att orsaka problem med deras befintliga BI -innehåll eller konfiguration.
Företagsavyttringar- Det här är motsatsen till koncentrationsscenariot, en del av ett företag delas upp i sin egen enhet och måste nu rikta sin befintliga BI -miljö mot den nya säkerhetskällan.
Varför Namespace Migrations kan vara rörigt
Att peka en Cognos-miljö mot en ny säkerhetskälla är inte så enkelt som att lägga till den nya namnadressen med samma användare, grupper och roller, koppla bort det gamla namnutrymmet och VOILA!- alla dina Cognos-användare i det nya namnområdet matchas med deras innehåll. Faktum är att du ofta kan få en blodig röra på dina händer, och här är anledningen ...
Alla Cognos säkerhetsprinciper (användare, grupper, roller) refereras av en unik identifierare som kallas CAMID. Även om alla andra attribut är lika, CAMID för en användare i en befintliga namnutrymmet för autentisering kommer inte att vara samma som CAMID för den användaren i ny namnrymd. Detta kan förstöra en befintlig Cognos -miljö. Även om du bara har några få Cognos -användare måste du inse att CAMID -referenser finns på Många olika platser i din Content Store (och kan till och med existera utanför din Content Store i Framework -modeller, transformatormodeller, TM1 -applikationer, kuber, planeringsapplikationer etc. ).
Många Cognos -kunder tror felaktigt att CAMID egentligen bara spelar roll för Min mapps innehåll, användarinställningar etc. Detta kan inte vara längre från sanningen. Det handlar inte bara om antalet användare du har, det är mängden Cognos -objekt som du behöver vara orolig för. Det finns över 140 olika typer av Cognos -objekt bara i Content Store, varav många kan ha flera CAMID -referenser.
Till exempel:
- Det är inte ovanligt att ett enda schema i din Content Store har flera CAMID -referenser (schemaläggarens CAMID, användarens CAMID schemat ska köras som, varje användares CAMID eller distributionslista som det ska generera rapportutdata via e -post till , etc.).
- Varje objekt i Cognos har en säkerhetspolicy som styr vilka användare som kan komma åt objektet (tänk "Fliken Behörigheter"). En enda säkerhetspolicy som hänger den mappen i Cognos Connection har en CAMID -referens för varje användare, grupp och roll som anges i den policyn.
- Förhoppningsvis förstår du poängen - den här listan fortsätter och fortsätter!
Det är inte ovanligt att en stor innehållsbutik innehåller tiotusentals CAMID -referenser (och vi har sett några stora med hundratusentals).
Beräkna nu vad som finns ditt Cognos -miljö och du kan se att du potentiellt har att göra med horder av CAMID -referenser. Det kan vara en mardröm! Om du byter (eller konfigurerar om) ditt autentiseringsnamnutrymme kan alla dessa CAMID-referenser lämnas i ett olöst tillstånd. Detta leder oundvikligen till Cognos innehåll och konfigurationsproblem (t.ex. scheman som inte längre körs, innehåll som inte längre är säkrat som du tror det är, paket eller kuber som inte längre korrekt implementerar datanivåsäkerhet, förlust av Min mappinnehåll och användare preferenser etc.).
Cognos namnområdesövergångsmetoder
Nu när vi vet att en Cognos -miljö kan ha tiotusentals CAMID -referenser som kräver att hitta, kartlägga och uppdatera till sitt motsvarande nya CAMID -värde i det nya autentiseringsnamnutrymmet, låt oss diskutera de goda, dåliga och fula metoderna för att lösa detta problem.
The Good: Ersättning av namnutrymme med Persona
Den första metoden (Namespace Replacement) använder Motio'S, Persona IQ produkt. Med detta tillvägagångssätt ersätts ditt befintliga namnutrymme med ett speciellt namnområde för Persona som låter dig virtualisera alla säkerhetsprinciper som utsätts för Cognos. Befintliga säkerhetsprinciper kommer att exponeras för Cognos med exakt samma CAMID som tidigare, även om de kan backas upp av ett antal externa säkerhetskällor (t.ex. Active Directory, LDAP eller till och med Persona-databasen).
Den vackra delen med detta tillvägagångssätt är att det kräver NULL ändringar av ditt Cognos -innehåll. Detta beror på att Persona kan behålla CAMID: er från redan existerande huvudmän, även när de stöds av en ny källa. Så ... alla dessa tiotusentals CAMID -referenser i din Content Store, externa modeller och historiska kuber? De kan stanna precis som de är. Det krävs inget arbete.
Detta är den minst riskfyllda metod med lägst effekt du kan använda för att överföra din befintliga Cognos -miljö från en extern säkerhetskälla till en annan. Det kan göras på under en timme med cirka 5 minuters Cognos -stillestånd (den enda Cognos -stilleståndstiden är att starta om Cognos när du har konfigurerat namnområdet för Persona).
The Bad: Migration av namnrymd med hjälp av Persona
Om det enkla, lågriskmetoden bara inte är din kopp te, så finns det is ett annat alternativ.
Persona kan också användas för att utföra en namnrymdmigrering.
Detta innebär att du installerar ett andra autentiseringsnamnutrymme i din Cognos -miljö, kartlägger (förhoppningsvis) alla dina befintliga säkerhetsprinciper (från det gamla namnområdet) till motsvarande huvudmän i det nya namnområdet, sedan (här är den roliga delen), hittar, kartlägger och uppdaterar alla enda CAMID -referens som finns i din Cognos -miljö: din innehållsbutik, rammodeller, transformatormodeller, historiska kuber, TM1 -applikationer, planeringsprogram, etc.
Detta tillvägagångssätt tenderar att vara stressigt och processintensivt, men om du är den typen av Cognos -administratör som behöver lite adrenalinkick för att känna sig levande (och inte har något emot sena kvällar / tidiga morgonsamtal), så kanske ... detta är alternativet du letar efter?
Persona kan användas för att automatisera delar av denna process. Det hjälper dig att skapa en kartläggning mellan de gamla säkerhetsprinciperna och de nya säkerhetsprinciperna, automatisera brute force “hitta, analysera, uppdatera” logiken för innehåll i din innehållsbutik etc. Vad Persona kan automatisera några av uppgifterna här, mycket av arbetet i detta tillvägagångssätt involverar "människor och process" snarare än faktisk teknik.
Till exempel - att sammanställa information om varje Framework Manager -modell, varje transformatormodell, varje Planning / TM1 -applikation, varje SDK -applikation, som äger dem och planera hur de ska uppdateras och omfördelas kan vara mycket arbete. Koordinering av avbrott för var och en av Cognos -miljöerna som du vill försöka med detta och underhållsfönster under vilka du kan försöka migreringen kan innebära planering och Cognos "stilleståndstid". Att komma på (och genomföra) en effektiv testplan för efter din migration kan också vara en ganska björn.
Det är också ganska normalt att du först vill göra denna process i en icke-produktionsmiljö innan provar det i produktion.
Medan Namespace Migration with Persona fungerar (och det är mycket bättre än det "fula" tillvägagångssättet nedan), är det mer invasivt, mer riskabelt, involverar mycket mer personal och tar mycket fler arbetstimmar att utföra än Namespace Replacement. Vanligtvis måste migreringar göras under "lediga tider", medan Cognos -miljön fortfarande är online, men begränsad formanvändning av slutanvändare.
Den fula: Manuell namnrymdmigrationstjänster
Den fula metoden innebär att det inte är avundsvärt att försöka manuellt migrera från ett autentiseringsnamnutrymme till ett annat. Detta innebär att du ansluter ett andra autentiseringsnamnutrymme till din Cognos -miljö och sedan försöker flytta eller återskapa mycket av det befintliga Cognos -innehållet och konfigurationen manuellt.
Till exempel kan en Cognos -administratör med denna metod försöka:
- Återskapa grupperna och rollerna i det nya namnområdet
- Återskapa medlemskapen för dessa grupper och roller i det nya namnområdet
- Kopiera innehållet i mina mappar manuellt, användarinställningar, portalflikar etc. från varje källkonto till varje målkonto
- Hitta varje policyuppsättning i Content Store och uppdatera den för att referera till motsvarande huvudmän i det nya namnutrymmet på exakt samma sätt som den refererade till huvudmän från det gamla namnområdet
- Återskapa alla scheman och fyll dem med motsvarande referenser, mottagare, etc.
- Återställ alla egenskaper för "ägare" och "kontakt" för alla objekt i Content Store
- [Cirka 40 andra saker i Content Store som du kommer att glömma]
- Samla alla FM -modeller med säkerhet på objekt- eller datanivå:
- Uppdatera varje modell i enlighet därmed
- Publicera om varje modell
- Omfördela den modifierade modellen tillbaka till originalförfattaren
- Liknande arbete för transformatormodeller, TM1 -applikationer och planeringsapplikationer som är säkrade mot det ursprungliga namnområdet
- [och många fler]
Medan vissa Cognos -masochister i hemlighet kan fnissa av glädje över tanken att klicka 400,000 XNUMX gånger i Cognos Connection, tenderar detta tillvägagångssätt för de flesta vettiga människor att vara extremt tråkigt, tidskrävande och felaktigt. Det är dock inte det största problemet med detta tillvägagångssätt.
Det största problemet med detta tillvägagångssätt är att det nästan alltid leder till en ofullständig migration.
Med detta tillvägagångssätt hittar du (smärtsamt) och försöker kartlägga de CAMID -referenser som du känner till ... men tenderar att lämna alla dessa CAMID -referenser som du vet inte om.
När du tror du är klar med detta tillvägagångssätt, det är du ofta inte verkligen Klart.
Du har objekt i din innehållsbutik som inte längre är säkrade som du tror att de är ... du har scheman som inte körs som de brukade köra, du har data som inte längre är säkrad som du tror det är, och du kan till och med ha oförklarliga fel för vissa operationer som du kan inte riktigt sätta fingret på.
Anledningar till att de dåliga och fula metoderna kan vara fruktansvärda:
- Automatiserade namnområdesmigrationer lägger stor vikt på Content Manager. Inspektionen och den potentiella uppdateringen av varje enskilt objekt i din Content Store kan ofta resultera i tiotusentals SDK -samtal till Cognos (som nästan alla flödar genom Content Manager). Denna onormala sökfråga ökar vanligtvis minnesanvändning / belastning och riskerar att innehållshanteraren kraschar under migreringen. Om du redan har någon instabilitet i din Cognos -miljö bör du vara väldigt rädd för detta tillvägagångssätt.
- Namespace Migrations kräver ett stort underhållsfönster. Cognos måste vara uppe, men du vill inte att människor gör ändringar under migreringsprocessen. Detta kräver vanligtvis att namnrymdmigrering startar när ingen annan arbetar, låt oss säga klockan 10 på en fredagskväll. Ingen vill starta ett stressigt projekt klockan 10 på en fredagskväll. För att inte tala om, dina mentala förmågor är förmodligen inte de bästa arbetskvällarna och helgerna på ett projekt som gör kräver att du är skarp!
- Jag har nämnt att namnrymdmigrationer är tid- och arbetskrävande. Här är lite mer om det:
- Innehållskartläggningsprocessen bör göras med precision och det kräver teamsamarbete och många arbetstimmar.
- Flera torrkörningar krävs för att kontrollera om det finns fel eller problem med en migrering. En typisk migration går inte perfekt på första försöket. Du behöver också en giltig säkerhetskopia av din Content Store som kan återställas i sådana fall. Vi har sett många organisationer som inte har en bra säkerhetskopia tillgänglig (eller har en säkerhetskopia som de inte inser är ofullständig).
- Du måste identifiera allt utanför innehållsbutiken som kan komma att påverkas (rammodeller, transformatormodeller etc.). Denna uppgift kan innebära samordning mellan flera team (särskilt i stora delade BI -miljöer).
- Du behöver en bra testplan som involverar representativa personer med varierande åtkomst till ditt Cognos -innehåll. Nyckeln här är att verifiera kort efter att migrationen är klar att allt är fullt migrerat och fungerar som du förväntar dig. Det är vanligtvis opraktiskt att verifiera allt, så du slutar verifiera vad du hoppas är representativa prover.
- Du måste ha broad kunskap om Cognos -miljön och saker som är beroende av den. Till exempel måste historiska kuber med anpassade vyer byggas om om du går NSM -rutten.
- Vad händer om du eller företaget du har outsourcat namnrymdmigrationen till att glömma något, till exempel ... SDK -applikationer? När du väl har vridit omkopplaren slutar dessa saker att fungera om de inte uppdateras korrekt. Har du rätt kontroll för att märka detta omedelbart, eller kommer det att ta flera veckor / månader innan symtomen börjar dyka upp?
- Om du har genomgått många Cognos -uppgraderingar kan du eventuellt ha objekt i din Content Store som är inkonsekventa. Om du inte arbetar med SDK kan du inte se vilka objekt som är i det här läget.
Varför byte av namnutrymme är det bästa alternativet
De viktigaste riskfaktorerna och tidskrävande stegen som jag nyss skisserade elimineras när metoden för ersättning av personnamnsutrymme används. Genom att använda Namespace Replacement -metoden har du fem minuters Cognos -stillestånd och inget av ditt innehåll behöver ändras. "Bra" -metoden verkar för mig som en skuren och torr "no-brainer". Fredagskvällar är till för att koppla av, inte stressa över det faktum att din Content Manager precis kraschade mitt i en namnrymdmigrering.
