Wanneer u een bestaande Cognos-omgeving opnieuw moet configureren om een andere externe beveiligingsbron te gebruiken (bijv. Active Directory, LDAP, enz.), zijn er een aantal benaderingen die u kunt volgen. Ik noem ze graag 'The Good, the Bad, and the Ugly'. Voordat we deze goede, slechte en lelijke benaderingen onderzoeken, laten we eens kijken naar enkele veelvoorkomende scenario's die de neiging hebben om de naamruimte van authenticatie te wijzigen in een Cognos-omgeving.
Veelvoorkomende zakelijke drijfveren:
Hardware of besturingssysteem bijwerken – Modernisering van BI-hardware/-infrastructuur kan een veelvoorkomende driver zijn. Hoewel de rest van Cognos als een kampioen kan draaien op uw gestroomlijnde nieuwe hardware en moderne 64-bits besturingssysteem, moet u veel succes hebben met het migreren van uw circa 2005-versie van Access Manager naar dat nieuwe platform. Access Manager (voor het eerst uitgebracht met Series 7) is voor veel Cognos-klanten een eerbiedwaardig overblijfsel uit vervlogen tijden. Het is de enige reden dat veel klanten die slordige oude versie van Windows Server 2003 bij zich hebben. Het schrijven voor Access Manager hangt al geruime tijd aan de muur. Het is legacy-software. Hoe eerder je er vanaf kunt stappen, hoe beter.
Toepassingsstandaardisatie– Organisaties die de authenticatie van al hun applicaties willen consolideren tegen één centraal beheerde bedrijfsdirectoryserver (bijv. LDAP, AD).
Fusies en overnames– Bedrijf A koopt bedrijf B en heeft de Cognos-omgeving van bedrijf B nodig om naar de directoryserver van bedrijf A te verwijzen, zonder problemen te veroorzaken met hun bestaande BI-inhoud of configuratie.
Bedrijfsafstotingen– Dit is het tegenovergestelde van het fusiescenario, een deel van een bedrijf wordt afgesplitst in een eigen entiteit en moet nu zijn bestaande BI-omgeving naar de nieuwe beveiligingsbron richten.
Waarom naamruimtemigraties rommelig kunnen zijn
Het verwijzen van een Cognos-omgeving naar een nieuwe beveiligingsbron is niet zo eenvoudig als het toevoegen van de nieuwe naamruimte met dezelfde gebruikers, groepen en rollen, het loskoppelen van de oude naamruimte en VOILA! - al uw Cognos-gebruikers in de nieuwe naamruimte komen overeen met hun inhoud. In feite kun je vaak eindigen met een bloederige puinhoop op je handen, en dit is waarom ...
Er wordt naar alle Cognos-beveiligings-principals (gebruikers, groepen, rollen) verwezen door een unieke id die een CAMID wordt genoemd. Zelfs als alle andere attributen gelijk zijn, is de CAMID voor een gebruiker in een bestaand authenticatie naamruimte zal niet hetzelfde zijn als de CAMID voor die gebruiker in de nieuwe naamruimte. Dit kan grote schade aanrichten aan een bestaande Cognos-omgeving. Zelfs als je maar een paar Cognos-gebruikers hebt, moet je je realiseren dat CAMID-referenties op VEEL verschillende plaatsen in je Content Store bestaan (en zelfs buiten je Content Store kunnen bestaan in Framework-modellen, Transformer Models, TM1-applicaties, Cubes, Planning Applications enz. ).
Veel Cognos-klanten denken ten onrechte dat CAMID's eigenlijk alleen van belang zijn voor de inhoud van Mijn map, gebruikersvoorkeuren, enz. Dit kan niet minder waar zijn. Het gaat niet alleen om het aantal gebruikers dat u heeft, maar ook om het aantal Cognos-objecten waarmee u rekening moet houden. Er zijn meer dan 140 verschillende soorten Cognos-objecten alleen in de Content Store, waarvan vele meerdere CAMID-referenties kunnen hebben.
Bijvoorbeeld:
- Het is niet ongebruikelijk dat een enkel schema in uw inhoudswinkel meerdere CAMID-referenties heeft (de CAMID van de eigenaar van het schema, de CAMID van de gebruiker die het schema zou moeten uitvoeren, de CAMID van elke gebruiker of distributielijst waarnaar het gegenereerde rapport moet worden gemaild). , enzovoort.).
- Elk object in Cognos heeft een beveiligingsbeleid dat bepaalt welke gebruikers toegang hebben tot het object (denk aan het tabblad 'Machtigingen'). Een enkel beveiligingsbeleid dat aan die map in Cognos Connection hangt, heeft een CAMID-referentie voor elke gebruiker, groep en rol die in dat beleid is gespecificeerd.
- Hopelijk snap je het punt - deze lijst gaat maar door!
Het is niet ongebruikelijk dat een omvangrijke inhoudswinkel tienduizenden CAMID-referenties bevat (en we hebben enkele grote gezien met honderdduizenden).
Nu, reken uit wat er in zit jouw Cognos-omgeving en je kunt zien dat je mogelijk te maken hebt met hordes CAMID-referenties. Het kan een nachtmerrie zijn! Het wisselen (of opnieuw configureren) van uw authenticatienaamruimte kan al deze CAMID-referenties in een onoplosbare toestand achterlaten. Dit leidt onvermijdelijk tot content- en configuratieproblemen van Cognos (bijv. schema's die niet meer werken, inhoud die niet langer is beveiligd zoals u denkt dat het is, pakketten of kubussen die de beveiliging op gegevensniveau niet langer correct implementeren, het verlies van My Folder-inhoud en gebruikers voorkeuren, enz.).
Overgangsmethoden voor Cognos-naamruimte
Nu we weten dat een Cognos-omgeving tienduizenden CAMID-referenties kan hebben die moeten worden gevonden, in kaart gebracht en bijgewerkt naar de bijbehorende nieuwe CAMID-waarde in de nieuwe naamruimte voor authenticatie, laten we de Good, Bad & Ugly-benaderingen bespreken om dit probleem op te lossen.
De Goede: Vervanging van naamruimte door Persona
De eerste methode (Namespace Replacement) maakt gebruik van: Motio'S, Persoonlijk IQ Product. Met deze aanpak wordt uw bestaande naamruimte "vervangen" door een speciale Persona-naamruimte waarmee u alle beveiligings-principals die aan Cognos worden blootgesteld, kunt virtualiseren. Reeds bestaande beveiligings-principals worden blootgesteld aan Cognos met exact dezelfde CAMID als voorheen, ook al kunnen ze worden ondersteund door een willekeurig aantal externe beveiligingsbronnen (bijv. Active Directory, LDAP of zelfs de Persona-database).
Het mooie van deze aanpak is dat er GEEN wijzigingen in uw Cognos-inhoud nodig zijn. Dit komt omdat Persona de CAMID's van reeds bestaande principals kan behouden, zelfs wanneer ze worden ondersteund door een nieuwe bron. Dus… al die tienduizenden CAMID-referenties in je Content Store, externe modellen en historische kubussen? Ze kunnen precies blijven zoals ze zijn. Er is geen werk vereist.
Dit is verreweg de minst risicovolle aanpak met de minste impact die u kunt gebruiken om uw bestaande Cognos-omgeving over te zetten van de ene externe beveiligingsbron naar de andere. Het kan in minder dan een uur worden gedaan met ongeveer 5 minuten uitvaltijd van Cognos (de enige uitvaltijd van Cognos is het opnieuw opstarten van Cognos nadat u de Persona-naamruimte hebt geconfigureerd).
De Slechte: Migratie van naamruimte met Persona
Als de gemakkelijke aanpak met een laag risico gewoon niet jouw ding is, dan is er is andere optie.
Persona kan ook worden gebruikt om een naamruimtemigratie uit te voeren.
Dit omvat het installeren van een tweede authenticatienaamruimte in uw Cognos-omgeving, waarbij (hopelijk) al uw bestaande beveiligings-principals (van de oude naamruimte) worden toegewezen aan overeenkomstige principals in de nieuwe naamruimte, en vervolgens (hier is het leuke gedeelte), elke enkele CAMID-referentie die in uw Cognos-omgeving aanwezig is: uw inhoudswinkel, raamwerkmodellen, transformatormodellen, historische kubussen, TM1-toepassingen, planningstoepassingen, enz.
Deze aanpak is vaak stressvol en procesintensief, maar als je het soort Cognos-beheerder bent die een beetje adrenaline nodig heeft om zich levend te voelen (en het niet erg vindt om 's avonds laat / 's ochtends vroeg te bellen), dan is misschien... dit is de optie die u zoekt?
Persona kan worden gebruikt om delen van dit proces te automatiseren. Het zal u helpen een toewijzing te maken tussen de oude beveiligings-principals en de nieuwe beveiligings-principals, de brute kracht "vinden, analyseren, bijwerken"-logica voor inhoud in uw inhoudswinkel te automatiseren, enz. Wat Persona kan sommige van de taken hier automatiseren, veel van het werk in deze benadering betreft 'mensen en processen' in plaats van daadwerkelijke technologie.
Bijvoorbeeld: het verzamelen van informatie over elk Framework Manager-model, elk Transformer-model, elke Planning / TM1-toepassing, elke SDK-toepassing, wie de eigenaar is, en het plannen van hoe ze zullen worden bijgewerkt en opnieuw gedistribueerd, kan veel werk zijn. Het coördineren van uitval voor elk van de Cognos-omgevingen waarin u dit wilt proberen en de onderhoudsperiodes waarin u de migratie kunt proberen, kan planning en Cognos "downtime" met zich meebrengen. Het bedenken (en uitvoeren) van een effectief testplan voor na je migratie kan ook een hele klus zijn.
Het is ook heel normaal dat je dit proces eerst wilt doen in een niet-productieomgeving vaardigheden proberen in productie.
Hoewel Namespace Migration met Persona werkt (en het is veel beter dan de "Ugly" benadering hieronder), is het invasiever, riskanter, er is veel meer personeel bij betrokken en het kost veel meer manuren om uit te voeren dan Namespace Replacement. Doorgaans moeten migraties worden uitgevoerd buiten kantooruren, terwijl de Cognos-omgeving nog steeds online is, maar het formuliergebruik door eindgebruikers beperkt is.
The Ugly: Handmatige migratieservices voor naamruimte
De Ugly-methode omvat de niet-benijdenswaardige benadering van het proberen om handmatig migreren van de ene authenticatienaamruimte naar de andere. Dit houdt in dat u een tweede naamruimte voor authenticatie aansluit op uw Cognos-omgeving en vervolgens probeert om een groot deel van de bestaande Cognos-inhoud en -configuratie handmatig te verplaatsen of opnieuw te maken.
Met deze aanpak kan een Cognos-beheerder bijvoorbeeld proberen om:
- Maak de groepen en rollen opnieuw aan in de nieuwe naamruimte
- Maak de lidmaatschappen van die groepen en rollen opnieuw aan in de nieuwe naamruimte
- Kopieer handmatig de inhoud van mijn mappen, gebruikersvoorkeuren, portaltabbladen, enz. van elk bronaccount naar elk doelaccount
- Vind elke beleidsset in de Content Store en werk deze bij om te verwijzen naar equivalente principals in de nieuwe naamruimte op exact dezelfde manier als naar principals uit de oude naamruimte
- Maak alle schema's opnieuw en vul ze met bijbehorende referenties, ontvangers, enz.
- Reset alle eigenschappen "eigenaar" en "contact" van alle objecten in de inhoudswinkel
- [Ongeveer 40 andere dingen in de Content Store die je gaat vergeten]
- Verzamel alle FM-modellen met beveiliging op object- of gegevensniveau:
- Werk elk model dienovereenkomstig bij
- Publiceer elk model opnieuw
- Distribueer het gewijzigde model terug naar de oorspronkelijke auteur
- Vergelijkbaar werk voor Transformer-modellen, TM1-applicaties en planningsapplicaties die zijn beveiligd tegen de oorspronkelijke naamruimte
- [en nog veel meer]
Hoewel sommige Cognos-masochisten in het geheim giechelen van vreugde bij het idee om 400,000 keer in Cognos Connection te klikken, is deze aanpak voor de meest verstandige mensen buitengewoon vervelend, tijdrovend en foutgevoelig. Dat is echter niet het grootste probleem met deze aanpak.
Het grootste probleem met deze aanpak is dat het bijna altijd leidt tot een onvolledige migratie.
Door deze aanpak te gebruiken, vind je (pijnlijk) die CAMID-referenties die je kent, en probeer je ze in kaart te brengen... weet er niets van.
Als je eenmaal denken je bent klaar met deze aanpak, vaak ben je dat niet werkelijk gedaan.
Je hebt objecten in je content store die niet langer beveiligd zijn zoals je denkt dat ze zijn... je hebt schema's die niet meer werken zoals ze vroeger liepen, je hebt gegevens die niet langer beveiligd zijn zoals je denkt het is, en u kunt zelfs onverklaarbare fouten hebben voor bepaalde bewerkingen die: je kan er niet echt de vinger op leggen.
Redenen waarom de slechte en lelijke benaderingen vreselijk kunnen zijn:
- Geautomatiseerde naamruimtemigraties leggen veel druk op de Content Manager. De inspectie en mogelijke update van elk afzonderlijk object in uw Content Store kan vaak leiden tot tienduizenden SDK-aanroepen naar Cognos (vrijwel allemaal via de Content Manager). Deze abnormale bevraging veroorzaakt doorgaans een piek in het geheugengebruik/belasting en brengt de Content Manager met het risico te crashen tijdens de migratie. Als u al enige mate van instabiliteit in uw Cognos-omgeving heeft, zou u erg bang moeten zijn voor deze aanpak.
- Naamruimtemigraties vereisen een aanzienlijk onderhoudsvenster. Cognos moet actief zijn, maar u wilt niet dat mensen wijzigingen aanbrengen tijdens het migratieproces. Dit vereist meestal dat de migratie van de naamruimte begint wanneer niemand anders aan het werk is, laten we zeggen om 10 uur op een vrijdagavond. Niemand wil op vrijdagavond om 10 uur aan een stressvol project beginnen. Om nog maar te zwijgen van het feit dat je mentale vermogens waarschijnlijk niet op hun best zijn door nachten en weekenden te werken aan een project dat doet vereist dat je scherp bent!
- Ik heb al gezegd dat naamruimtemigraties tijdrovend en arbeidsintensief zijn. Hier is wat meer over:
- Het content mapping-proces moet met precisie worden uitgevoerd en dat vereist teamsamenwerking en veel manuren.
- Er zijn meerdere dry runs nodig om te controleren op fouten of problemen met een migratie. Een typische migratie verloopt bij de eerste poging niet perfect. Je hebt ook een geldige back-up van je Content Store nodig die in dergelijke gevallen kan worden hersteld. We hebben veel organisaties gezien die geen goede back-up beschikbaar hebben (of een back-up hebben waarvan ze niet beseffen dat deze onvolledig is).
- Je moet alles identificeren buiten de Content Store die mogelijk wordt beïnvloed (raamwerkmodellen, transformatormodellen, enz.). Deze taak kan coördinatie over meerdere teams inhouden (met name in grote gedeelde BI-omgevingen).
- U hebt een goed testplan nodig waarbij representatieve mensen betrokken zijn met verschillende mate van toegang tot uw Cognos-inhoud. De sleutel hier is om kort nadat de migratie is voltooid te controleren of alles volledig is gemigreerd en functioneert zoals u verwacht. Het is meestal onpraktisch om alles te verifiëren, dus u verifieert uiteindelijk wat u hoopt dat het representatieve steekproeven zijn.
- Je moet b . hebbenroad kennis van de Cognos-omgeving en de dingen die daarvan afhankelijk zijn. Historische kubussen met aangepaste weergaven MOETEN bijvoorbeeld opnieuw worden opgebouwd als u de NSM-route volgt.
- Wat als u of het bedrijf waaraan u de migratie van de naamruimte hebt uitbesteed, iets vergeet, zoals... SDK-applicaties? Zodra u de schakelaar hebt omgedraaid, werken deze dingen niet meer als ze niet correct worden bijgewerkt. Heeft u de juiste controles om dit onmiddellijk op te merken, of zal het enkele weken / maanden duren voordat de symptomen naar boven komen?
- Als u meerdere Cognos-upgrades hebt ondergaan, kunt u mogelijk objecten in uw Content Store hebben die in een inconsistente staat verkeren. Als u niet met de SDK werkt, kunt u niet zien welke objecten deze status hebben.
Waarom naamruimte vervangen de beste optie is
De belangrijkste risicofactoren en tijdrovende stappen die ik zojuist heb geschetst, worden geëlimineerd wanneer de Persona Namespace Replacement-methode wordt gebruikt. Als u de Namespace Replacement-aanpak gebruikt, heeft u 5 minuten Cognos-downtime en hoeft uw inhoud niet te veranderen. De "Goede" methode lijkt mij een geknipte en droge "no-brainer". Vrijdagavonden zijn om te ontspannen, niet om je druk te maken over het feit dat je Content Manager net is gecrasht tijdens een naamruimtemigratie.
