Når du skal omkonfigurere et eksisterende Cognos -miljø til at bruge en anden ekstern sikkerhedskilde (f.eks. Active Directory, LDAP osv.), Er der en håndfuld tilgange, du kan tage. Jeg kan godt lide at kalde dem "Det gode, det onde og det grimme." Inden vi udforsker disse gode, dårlige og grimme tilgange, lad os tage et kig på nogle almindelige scenarier, der har tendens til at drive ændringer i autentificering af navnerum i et Cognos -miljø.
Fælles forretningsdrivere:
Opdatering af hardware eller operativsystem - Modernisering af BI -hardware/infrastruktur kan være en hyppig driver. Mens resten af Cognos kan køre som en mester på din slanke nye hardware og moderne 64-bit OS, vil held og lykke migrere din circa 2005-version af Access Manager over på den nye platform. Access Manager (først udgivet med serie 7) er et ærværdigt tilbagehold fra tidligere dage for mange Cognos -kunder. Det er den eneste grund til, at mange kunder beholder den gamle gamle version af Windows Server 2003. Skrivningen har været på væggen for Access Manager i et stykke tid. Det er ældre software. Jo før du kan skifte væk fra det, jo bedre.
Standardisering af applikationer- Organisationer, der ønsker at konsolidere godkendelsen af alle deres applikationer mod en centralt administreret virksomhedskatalogserver (f.eks. LDAP, AD).
Fusioner og erhvervelser- Virksomhed A køber virksomhed B og har brug for virksomhed B's Cognos -miljø for at pege på virksomhedens A -katalogserver uden at forårsage problemer med deres eksisterende BI -indhold eller konfiguration.
Virksomhedsfrasalg- Dette er det modsatte af fusionsscenariet, en del af en virksomhed spaltes i sin egen enhed og skal nu pege det eksisterende BI -miljø på den nye sikkerhedskilde.
Hvorfor navneområdet Migrationer kan være rodet
At pege et Cognos-miljø på en ny sikkerhedskilde er ikke så simpelt som at tilføje det nye navneskema med de samme brugere, grupper og roller, afbryde det gamle navnerum og VOILA!- alle dine Cognos-brugere i det nye navneområde matches med deres indhold. Faktisk kan du ofte ende med et blodig rod på dine hænder, og her er hvorfor ...
Alle Cognos sikkerhedsprincipper (brugere, grupper, roller) refereres til af en unik identifikator kaldet et CAMID. Selvom alle andre attributter er ens, er CAMID for en bruger i en eksisterende godkendelsesnavneområde vil ikke være det samme som CAMID for den pågældende bruger i ny navnerum. Dette kan ødelægge et eksisterende Cognos -miljø. Selvom du kun har nogle få Cognos -brugere, skal du indse, at CAMID -referencer findes på MANGE forskellige steder i din Content Store (og kan endda eksistere uden for din Content Store i Framework -modeller, transformatormodeller, TM1 -applikationer, terninger, planlægningsapplikationer osv. ).
Mange Cognos -kunder tror fejlagtigt, at CAMID virkelig kun betyder noget for Min mappe -indhold, brugerpræferencer osv. Dette kunne ikke være længere fra sandheden. Det er ikke kun et spørgsmål om antallet af brugere, du har, det er mængden af Cognos -objekter, du skal bekymre dig om. Der er over 140 forskellige typer Cognos -objekter bare i Content Store, hvoraf mange kan have flere CAMID -referencer.
For eksempel:
- Det er ikke ualmindeligt, at et enkelt skema i din Content Store har flere CAMID -referencer (skemaejerens CAMID, brugerens CAMID, skemaet skal køre som, CAMID for hver bruger eller distributionsliste, det skal generere rapportoutput til e -mail til , etc.).
- Hvert objekt i Cognos har en sikkerhedspolitik, der styrer, hvilke brugere der kan få adgang til objektet (tænk "Fanen Tilladelser"). En enkelt sikkerhedspolitik, der hænger ud af mappen i Cognos Connection, har en CAMID -reference for hver bruger, gruppe og rolle, som er angivet i denne politik.
- Forhåbentlig får du pointen - denne liste bliver ved og ved!
Det er ikke ualmindeligt, at en betydelig indholdsbutik indeholder titusinder af CAMID -referencer (og vi har set nogle store med hundredtusinder).
Gør nu regnestykket om, hvad der er i din Cognos -miljø, og du kan se, at du potentielt har at gøre med horder af CAMID -referencer. Det kan være et mareridt! Hvis du skifter (eller re-konfigurerer) dit godkendelsesnavnerum, kan alle disse CAMID-referencer forblive i en uløselig tilstand. Dette fører uundgåeligt til Cognos indhold og konfigurationsproblemer (f.eks. Tidsplaner, der ikke længere kører, indhold, der ikke længere er sikret, som du tror, det er, pakker eller terninger, der ikke længere korrekt implementerer datanivåsikkerhed, tab af indhold i Min mappe og bruger præferencer osv.).
Cognos navneområdeovergangsmetoder
Nu, vel vidende at et Cognos -miljø kan have titusinder af CAMID -referencer, der vil kræve at finde, kortlægge og opdatere til deres tilsvarende nye CAMID -værdi i det nye autentificeringsnavneområde, lad os diskutere de gode, dårlige og grimme tilgange til at løse dette problem.
Det Gode: Udskiftning af navneområde med Persona
Den første metode (Namespace Replacement) anvender Motio'S, Persona IQ produkt. På denne måde "erstattes" dit eksisterende navnerum med et særligt Persona -navneområde, der giver dig mulighed for at virtualisere alle sikkerhedsprincipper, der udsættes for Cognos. Eksisterende sikkerhedsprincipper vil blive udsat for Cognos med nøjagtig samme CAMID som før, selvom de kan blive bakket op af et vilkårligt antal eksterne sikkerhedskilder (f.eks. Active Directory, LDAP eller endda Persona-databasen).
Den smukke del ved denne tilgang er, at det kræver NUL ændringer i dit Cognos -indhold. Dette skyldes, at Persona kan opretholde CAMID'er fra allerede eksisterende forstandere, selv når de understøttes af en ny kilde. Så ... alle de titusinder af CAMID -referencer i din Content Store, eksterne modeller og historiske kuber? De kan blive nøjagtig som de er. Der kræves ikke noget arbejde.
Dette er langt den mindst risikable metode med lavest effekt, du kan bruge til at overføre dit eksisterende Cognos -miljø fra en ekstern sikkerhedskilde til en anden. Det kan gøres på under en time med cirka 5 minutters Cognos -nedetid (den eneste Cognos -nedetid genstarter Cognos, når du har konfigureret Persona -navneområdet).
The Bad: Migration af navneområder ved hjælp af Persona
Hvis den lette metode med lav risiko bare ikke er din kop te, så er der is en anden mulighed.
Persona kan også bruges til at udføre en navneoverførsel.
Dette indebærer at installere et andet autentificeringsnavneområde i dit Cognos -miljø, kortlægge (forhåbentlig) alle dine eksisterende sikkerhedsprincipper (fra det gamle navnerum) til tilsvarende principper i det nye navnerum, derefter (her er den sjove del), finde, kortlægge og opdatere alle enkelt CAMID -reference, der findes i dit Cognos -miljø: din Content Store, rammemodeller, transformatormodeller, historiske kuber, TM1 -applikationer, planlægningsapplikationer osv.
Denne tilgang har en tendens til at være stressende og procesintensiv, men hvis du er den slags Cognos -administrator, der har brug for lidt adrenalinkick for at føle sig i live (og ikke har noget imod sene aften- / tidlige morgenopkald), så måske ... denne er den mulighed du leder efter?
Persona kan bruges til at hjælpe med at automatisere dele af denne proces. Det vil hjælpe dig med at oprette en kortlægning mellem de gamle sikkerhedsprincipper og de nye sikkerhedsprincipper, automatisere brute force "find, analyser, opdater" logikken for indhold i din indholdsbutik osv. Hvad Persona kan automatisere nogle af opgaverne her, meget af arbejdet i denne tilgang involverer "mennesker og proces" frem for egentlig teknologi.
For eksempel - at indsamle oplysninger om hver Framework Manager -model, hver Transformer -model, hver Planning / TM1 -applikation, hver SDK -applikation, hvem der ejer dem, og planlægge, hvordan de vil blive opdateret og omfordelt, kan være meget arbejde. Koordinering af afbrydelser for hvert af de Cognos -miljøer, du ønsker at prøve dette i, og vedligeholdelsesvinduer, hvor du kan prøve at migrere, kan indebære planlægning og Cognos "nedetid". At komme med (og udføre) en effektiv testplan for efter din migration kan også være en ganske bjørn.
Det er også helt normalt, at du først vil udføre denne proces i et ikke-produktionsmiljø før prøver det i produktionen.
Selvom Namespace Migration with Persona virker (og det er langt bedre end den "grimme" metode herunder), er det mere invasivt, mere risikabelt, involverer langt mere personale og tager langt flere mandetimer at udføre end Namespace Replacement. Typisk skal migrationer udføres i "slukketid", mens Cognos -miljøet stadig er online, men begrænset formbrug af slutbrugere.
Den grimme: Manuel navneområdet Migration Services
Den grimme metode indebærer den misundelsesværdige tilgang til forsøg på at manuelt migrere fra et godkendelsesnavnområde til et andet. Dette indebærer tilslutning af et andet godkendelsesnavneområde til dit Cognos -miljø og derefter forsøg på manuelt at flytte eller genskabe meget af det eksisterende Cognos -indhold og -konfiguration.
For eksempel ved hjælp af denne fremgangsmåde kan en Cognos -administrator forsøge at:
- Genskab grupper og roller i det nye navneområde
- Genskab medlemskaberne af disse grupper og roller i det nye navneområde
- Kopier indholdet af mine mapper manuelt, brugerpræferencer, portalfaner osv. Fra hver kildekonto til hver målkonto
- Find hvert policysæt i Content Store, og opdater det til henvisning til ækvivalente principper i det nye navnerum på nøjagtig samme måde, som det henviste til principper fra det gamle navnerum
- Genskab alle tidsplanerne, og udfyld dem med tilhørende legitimationsoplysninger, modtagere osv.
- Nulstil alle egenskaberne "ejer" og "kontakt" for alle objekter i Content Store
- [Omkring 40 andre ting i Content Store, som du kommer til at glemme]
- Saml alle FM -modellerne med sikkerhed på objekt- eller dataniveau:
- Opdater hver model i overensstemmelse hermed
- Udgiv hver model igen
- Omfordel den ændrede model tilbage til den originale forfatter
- Lignende arbejde for Transformer -modeller, TM1 -applikationer og planlægningsprogrammer, der er sikret mod det originale navnerum
- [og mange flere]
Mens nogle Cognos -masochister i hemmelighed kan fnise af glæde ved tanken om at klikke 400,000 gange i Cognos Connection, har denne tilgang en tendens til at være ekstremt kedelig, tidskrævende og tilbøjelig til fejl. Det er dog ikke det største problem med denne tilgang.
Det største problem med denne tilgang er, at den næsten altid fører til en ufuldstændig migration.
Ved hjælp af denne tilgang finder du (smerteligt) og forsøger at kortlægge de CAMID -referencer, du kender til ... men har en tendens til at efterlade alle de CAMID -referencer, som du ved ikke om.
Når du tror du er færdig med denne tilgang, det er du ofte ikke virkelig Færdig.
Du har objekter i din indholdsbutik, der ikke længere er sikret, som du tror, de er ... du har skemaer, der ikke kører, som de plejede at køre, du har data, der ikke længere er sikret, som du tror det er, og du kan endda have uforklarlige fejl for visse operationer, der du kan ikke rigtig sætte fingeren på.
Årsager til, at de dårlige og grimme tilgange kan være frygtelige:
- Automatiserede navnespace -migrationer lægger stor vægt på Content Manager. Inspektionen og den potentielle opdatering af hvert enkelt objekt i din Content Store kan ofte resultere i titusindvis af SDK -opkald til Cognos (stort set alle flyder gennem Content Manager). Denne unormale forespørgsel øger typisk hukommelsesforbrug / belastning og sætter Content Manager i fare for at gå ned under migrationen. Hvis du allerede har en vis grad af ustabilitet i dit Cognos -miljø, skal du være meget bange for denne tilgang.
- Navnepladsoverførsler kræver et stort vedligeholdelsesvindue. Cognos skal være oppe, men du vil ikke have, at folk foretager ændringer under migrationsprocessen. Dette vil typisk kræve, at navneområdet -migrering starter, når ingen andre arbejder, lad os sige kl. 10 en fredag aften. Ingen ønsker at starte et stressende projekt klokken 10 en fredag aften. For ikke at nævne, dine mentale evner er sandsynligvis ikke i deres bedste arbejdsnætter og weekender på et projekt, der gør kræver, at du er skarp!
- Jeg har nævnt, at navneområdet Migrationer er tidskrævende og arbejdskrævende. Her er lidt mere om det:
- Indholdskortlægningsprocessen skal udføres med præcision, og det kræver teamsamarbejde og mange mandetimer.
- Der kræves flere tørkørsler for at kontrollere, om der er fejl eller problemer med en migration. En typisk migration går ikke perfekt i første forsøg. Du skal også bruge en gyldig sikkerhedskopi af din Content Store, der kan gendannes i sådanne tilfælde. Vi har set mange organisationer, der ikke har en god backup tilgængelig (eller har en backup, som de ikke er klar over er ufuldstændig).
- Du skal identificere alt uden for Content Store, der kan blive påvirket (rammemodeller, transformatormodeller osv.). Denne opgave kan indebære koordinering på tværs af flere teams (især i store delte BI -miljøer).
- Du har brug for en god testplan, der involverer repræsentative mennesker med forskellige grader af adgang til dit Cognos -indhold. Nøglen her er at verificere kort tid efter, at migrationen er fuldført, at alt er fuldstændigt migreret og fungerer, som du forventer. Det er typisk upraktisk at verificere alt, så du ender med at kontrollere, hvad du håber er repræsentative prøver.
- Du skal have broad kendskab til Cognos -miljøet og ting, der afhænger af det. For eksempel SKAL historiske kuber med tilpassede visninger genopbygges, hvis du går NSM -ruten.
- Hvad hvis du eller virksomheden, du har outsourcet navneområdet, til at glemme noget som f.eks. SDK -applikationer? Når du har vendt kontakten, holder disse ting op med at fungere, hvis de ikke opdateres korrekt. Har du den korrekte kontrol på plads for at bemærke dette med det samme, eller vil der gå flere uger / måneder, før symptomerne begynder at dukke op?
- Hvis du har gennemgået mange Cognos -opgraderinger, kan du muligvis have objekter i din Content Store, der er i en inkonsekvent tilstand. Hvis du ikke arbejder med SDK, kan du ikke se, hvilke objekter der er i denne tilstand.
Hvorfor udskiftning af navnerum er den bedste løsning
De vigtigste risikofaktorer og tidskrævende trin, jeg lige har skitseret, elimineres, når metoden til udskiftning af Persona Namespace bruges. Ved at bruge Namespace Replacement -metoden har du 5 minutters nedetid i Cognos, og intet af dit indhold skal ændres. "God" -metoden virker for mig som en klippet og tør "no-brainer". Fredag aftener er til afslapning, ikke stresset over det faktum, at din Content Manager lige styrtede ned midt i en navneoverførsel.
