Kada trebate ponovno konfigurirati postojeće Cognos okruženje za korištenje drugog vanjskog sigurnosnog izvora (npr. Active Directory, LDAP itd.), Postoji nekoliko pristupa koje možete poduzeti. Volim ih nazivati "dobrim, lošim i ružnim". Prije nego što istražimo ove dobre, loše i ružne pristupe, pogledajmo neke uobičajene scenarije koji imaju tendenciju da pokreću promjene imena prostora autentifikacije u Cognos okruženju.
Uobičajeni pokretači poslovanja:
Ažuriranje hardvera ili OS -a - Modernizacija BI hardvera/infrastrukture može biti čest pokretač. Dok bi ostatak Cognosa mogao raditi kao šampion na vašem elegantnom novom hardveru i modernom 64-bitnom OS-u, sretno s prelaskom vaše verzije Access Managera iz 2005. na tu novu platformu. Access Manager (prvi put objavljen sa Serijom 7) je vrijedno čuvanje iz prošlih dana za mnoge korisnike Cognosa. To je jedini razlog što se mnogi korisnici drže te stare verzije Windows Servera 2003. Pisanje je već neko vrijeme na zidu za Access Manager. To je stari softver. Što prije možete odstupiti od toga, to bolje.
Standardizacija aplikacija- Organizacije koje žele objediniti provjeru autentičnosti svih svojih aplikacija na jednom centralno administriranom korporacijskom poslužitelju direktorija (npr. LDAP, AD).
Spajanja i preuzimanja- Kompanija A kupuje Kompaniju B i treba joj Cognos okruženje kompanije B da pokaže na server direktorija Kompanije A, bez izazivanja problema u njihovom postojećem BI sadržaju ili konfiguraciji.
Korporativne prodaje- Ovo je suprotno scenariju spajanja, dio kompanije je izdvojen u svoj entitet i sada mora usmjeriti svoje postojeće BI okruženje na novi izvor sigurnosti.
Zašto migracije prostora imena mogu biti neuredne
Usmjeravanje Cognos okruženja na novi sigurnosni izvor nije tako jednostavno kao dodavanje novog imena sa istim korisnicima, grupama i ulogama, prekidanje veze sa starim imenskim prostorom i VOILA!- svi vaši Cognos korisnici u novom imenskom prostoru su usklađeni sa njihov sadržaj. U stvari, često možete završiti s krvavim neredom na rukama, a evo zašto ...
Svi principi Cognos sigurnosti (korisnici, grupe, uloge) referencirani su jedinstvenim identifikatorom koji se naziva CAMID. Čak i ako su svi drugi atributi jednaki, CAMID za korisnika u postojeće prostor za provjeru autentičnosti neće biti isti kao CAMID za tog korisnika u novi imenski prostor. Ovo može uništiti postojeće Cognos okruženje. Čak i ako imate samo nekoliko korisnika Cognosa, morate shvatiti da CAMID reference postoje na MNOGO različitih mjesta u vašoj trgovini sadržaja (pa čak mogu postojati i izvan vaše trgovine sadržajem u okvirnim modelima, modelima transformatora, TM1 aplikacijama, kockama, aplikacijama za planiranje itd.) ).
Mnogi korisnici Cognosa pogrešno vjeruju da je CAMID zaista bitan samo za sadržaj Moje mape, korisničke postavke itd. To ne može biti dalje od istine. Ne radi se samo o broju korisnika koje imate, već o količini Cognos objekata koje trebate zabrinuti. Postoji samo 140 različitih vrsta Cognos objekata samo u Content Store -u, od kojih mnogi mogu imati više CAMID referenci.
Na primjer:
- Nije neuobičajeno da jedan raspored u vašoj trgovini sadržaja ima više CAMID referenci (CAMID vlasnika rasporeda, CAMID korisnika po kojem bi se raspored trebao izvoditi, CAMID svakog korisnika ili distribucijske liste koju bi trebao poslati generiranim izvještajem putem itd.).
- Svaki objekt u Cognosu ima sigurnosnu politiku koja određuje koji korisnici mogu pristupiti objektu (pomislite na “Kartica Dozvole”). Jedna sigurnosna politika koja visi iz tog foldera u Cognos Connection -u ima CAMID referencu za svakog korisnika, grupu i ulogu koja je navedena u toj politici.
- Nadam se da ste shvatili poentu - ovaj popis se nastavlja i nastavlja!
Nije neuobičajeno da velika trgovina sadržaja sadrži desetine hiljada CAMID referenci (a vidjeli smo i neke velike sa stotinama hiljada).
Sada izračunajte šta ima vaš Cognos okruženju i možete vidjeti da se potencijalno bavite hordama CAMID referenci. To može biti noćna mora! Prebacivanjem (ili ponovnim konfiguriranjem) vašeg imenskog prostora za provjeru autentičnosti možete ostaviti sve ove CAMID reference u nerješivom stanju. Ovo neizbježno dovodi do problema sa sadržajem i konfiguracijom Cognosa (npr. Rasporedi koji se više ne izvode, sadržaj koji više nije osiguran onako kako mislite, paketi ili kocke koji više ne primjenjuju ispravno sigurnost na razini podataka, gubitak sadržaja i mape Moje mape sklonosti itd.).
Cognos metode prijelaza u prostor imena
Sada, znajući da Cognos okruženje može imati desetine hiljada CAMID referenci koje će zahtijevati pronalaženje, mapiranje i ažuriranje na odgovarajuću novu CAMID vrijednost u novom imenskom prostoru za provjeru autentičnosti, hajde da razgovaramo o dobrim, lošim i ružnim pristupima za rješavanje ovog problema.
Dobro: Zamjena prostora imena sa Persona
Prva metoda (zamjena prostora imena) koristi Motioje, Persona IQ proizvod. Koristeći ovaj pristup, vaš postojeći imenski prostor je „zamijenjen“ posebnim Persona imenskim prostorom koji vam omogućava da virtualizirate sve sigurnosne principe koji su izloženi Cognosu. Već postojeći principali sigurnosti bit će izloženi Cognosu sa potpuno istim CAMID-om kao i prije, iako mogu biti podržani bilo kojim brojem vanjskih sigurnosnih izvora (npr. Active Directory, LDAP ili čak baza podataka Persona).
Lijep dio ovog pristupa je to što zahtijeva NULA promjena vašeg Cognos sadržaja. To je zato što Persona može održavati CAMID-ove već postojećih principala, čak i ako su podržani iz novog izvora. Dakle ... svih tih desetina hiljada CAMID referenci u vašoj Content Store, vanjskih modela i povijesnih kockica? Mogu ostati tačno takvi kakvi jesu. Nije potreban nikakav posao.
Ovo je daleko najmanje rizičan pristup s najmanjim utjecajem koji možete koristiti za prelazak vašeg postojećeg Cognos okruženja s jednog vanjskog sigurnosnog izvora na drugi. To se može učiniti za manje od sat vremena s oko 5 minuta zastoja programa Cognos (jedino vrijeme zastoja Cognosa je ponovno pokretanje programa Cognos nakon što konfigurirate prostor imena Persona).
Loše: Migracija prostora imena pomoću Persone
Ako jednostavan, niskorizični pristup jednostavno nije vaša šalica čaja, onda postoji is druga opcija.
Persona se također može koristiti za izvođenje migracije prostora imena.
To uključuje instaliranje drugog prostora za provjeru autentičnosti u vašem Cognos okruženju, mapiranje (nadamo se) svih vaših postojećih principala sigurnosti (iz starog prostora imena) u odgovarajuće principale u novom prostoru imena, zatim (evo zabavnog dijela), pronalaženje, mapiranje i ažuriranje svakog jedna CAMID referenca koja postoji u vašem Cognos okruženju: vaša trgovina sadržaja, okvirni modeli, modeli transformatora, historijske kocke, TM1 aplikacije, aplikacije za planiranje itd.
Ovaj pristup ima tendenciju biti stresan i intenzivan na procese, ali ako ste vrsta Cognos administratora kojem je potrebno malo adrenalina da se osjeća živo (i ne smetaju mu kasni noćni / rani jutarnji telefonski pozivi), možda ... ovo je opcija koju tražite?
Persona se može koristiti za automatizaciju dijelova ovog procesa. Pomoći će vam u stvaranju preslikavanja između starih principa sigurnosti i novih principa sigurnosti, automatizirati grubu silu „pronađi, analiziraj, ažuriraj“ logiku sadržaja u vašoj trgovini sadržaja itd. Što Persona može automatizirati neke od zadataka ovdje rad na ovom pristupu uključuje „ljude i proces“, a ne stvarnu tehnologiju.
Na primjer - sastavljanje informacija o svakom modelu Framework Managera, svakom Transformer modelu, svakoj aplikaciji Planning / TM1, svakoj SDK aplikaciji, čiji je vlasnik, te planiranje načina na koji će se ažurirati i preraspodijeliti može biti veliki posao. Koordiniranje ispada za svako Cognos okruženje u kojem želite to pokušati i prozori održavanja tijekom kojih možete pokušati izvršiti migraciju mogu uključivati planiranje i Cognos "vrijeme zastoja". Smišljanje (i izvršavanje) efikasnog plana testiranja nakon vaše migracije također može biti prilično vrijedno.
Takođe je sasvim normalno da ćete ovaj proces prvo htjeti obaviti u neproizvodnom okruženju prije isprobavajući u proizvodnji.
Iako migracija prostora imena s Personom djeluje (i daleko je bolja od dolje navedenog pristupa "Ružan"), ona je invazivnija, rizičnija, uključuje mnogo više osoblja i zahtijeva mnogo više radnih sati nego zamjena prostora imena. Uobičajeno je da se migracije moraju obaviti za vrijeme „van radnog vremena“, dok je Cognos okruženje još uvijek na mreži, ali krajnji korisnici ograničeno koriste obrazac.
The Ugly: Usluge ručne migracije prostora imena
Ružna metoda uključuje nezavidan pristup pokušaja ručno migrirati iz jednog prostora za provjeru autentičnosti u drugi. Ovo uključuje povezivanje drugog prostora za provjeru autentičnosti u vaše Cognos okruženje, zatim pokušaj ručnog premještanja ili ponovnog stvaranja većeg dijela postojećeg Cognos sadržaja i konfiguracije.
Na primjer, koristeći ovaj pristup, administrator Cognosa mogao bi pokušati:
- Ponovo stvorite grupe i uloge u novom prostoru imena
- Ponovo stvorite članstva tih grupa i uloge u novom prostoru imena
- Ručno kopirajte sadržaj mojih mapa, korisničke postavke, kartice portala itd. Sa svakog izvornog računa na svaki ciljni račun
- Pronađite svaki skup pravila u skladištu sadržaja i ažurirajte ga na referencu ekvivalentnih principala u novom imenskom prostoru na isti način na koji se poziva na principale iz starog imenskog prostora
- Ponovo stvorite sve rasporede i popunite ih odgovarajućim vjerodajnicama, primateljima itd.
- Poništite sva svojstva „vlasnika“ i „kontakta“ svih objekata u skladištu sadržaja
- [Oko 40 drugih stvari u trgovini sadržaja na koje ćete zaboraviti]
- Okupite sve FM modele sa zaštitom na nivou objekta ili podataka:
- U skladu s tim ažurirajte svaki model
- Ponovo objavite svaki model
- Redistribuirajte izmijenjeni model natrag originalnom autoru
- Sličan rad za modele Transformer, TM1 aplikacije i aplikacije za planiranje koje su zaštićene od izvornog prostora imena
- [i još mnogo toga]
Iako bi se neki Cognos mazohisti mogli potajno nasmijati od radosti na ideju da kliknu 400,000 puta u Cognos Connection, za većinu razumnih ljudi ovaj pristup ima tendenciju da bude izuzetno dosadan, dugotrajan i sklon greškama. Međutim, to nije najveći problem s ovim pristupom.
Najveći problem s ovim pristupom je taj što je gotovo uvijek dovodi do nepotpune migracije.
Koristeći ovaj pristup, (bolno) pronalazite i pokušavate mapirati one CAMID reference za koje znate ... ali nastojite ostaviti sve one CAMID reference koje poznajete ne znam za.
Jednom ti misliti završili ste sa ovim pristupom, često niste stvarno završeno.
U vašoj trgovini sadržaja imate objekte koji više nisu osigurani onako kako mislite da jesu ... imate rasporede koji se ne izvode onako kako su se nekad izvodili, imate podatke koji više nisu osigurani na način na koji mislite jeste, a možda čak imate i neobjašnjive greške za određene operacije koje ne možeš staviti prst.
Razlozi zašto loš i ružan pristup mogu biti užasni:
- Automatizirane migracije prostora imena stavljaju veliki stres na Upravitelja sadržaja. Pregled i potencijalno ažuriranje svakog pojedinog objekta u vašoj trgovini sadržaja često mogu rezultirati desetinama hiljada SDK poziva Cognosu (gotovo svi teku kroz Content Manager). Ovo nenormalno postavljanje upita obično povećava potrošnju / učitavanje memorije i dovodi Content Manager u opasnost od pada tijekom migracije. Ako već imate bilo kakvu količinu nestabilnosti u svom Cognos okruženju, trebali biste se jako bojati ovog pristupa.
- Migracije prostora imena zahtijevaju značajan period održavanja. Cognos mora biti aktiviran, ali ne želite da ljudi unose promjene tokom procesa migracije. Ovo će obično zahtijevati da migracija prostora imena počne kada niko drugi ne radi, recimo u 10 sata navečer u petak navečer. Nitko ne želi započeti stresni projekt u petak navečer u 10 sata. Da ne spominjem, vaše mentalne sposobnosti vjerovatno nisu u najboljim radnim noćima i vikendima na projektu koji radi zahtevaju da budete oštri!
- Spomenuo sam Migracije prostora imena zahtijevaju vrijeme i rad. Evo malo više o tome:
- Proces mapiranja sadržaja treba biti obavljen s preciznošću i to zahtijeva timsku suradnju i mnogo radnih sati.
- Za provjeru grešaka ili problema s migracijom potrebno je više pokušaja. Tipična migracija ne ide savršeno iz prvog pokušaja. Trebat će vam i valjana sigurnosna kopija vaše trgovine sadržaja koja se može vratiti u takvim slučajevima. Vidjeli smo mnoge organizacije koje nemaju dostupnu dobru sigurnosnu kopiju (ili imaju sigurnosnu kopiju za koju ne smatraju da je nepotpuna).
- Morate sve identifikovati van skladište sadržaja na koje može doći potencijalni utjecaj (okvirni modeli, modeli transformatora itd.). Ovaj zadatak može uključivati koordinaciju između više timova (posebno u velikim zajedničkim BI okruženjima).
- Potreban vam je dobar plan testiranja koji uključuje reprezentativne ljude sa različitim stepenom pristupa vašem Cognos sadržaju. Ovdje je ključno provjeriti nedugo nakon završetka migracije je li sve u potpunosti migrirano i funkcionira li kako očekujete. Uobičajeno je nepraktično provjeriti sve pa na kraju provjerite ono za što se nadate da su reprezentativni uzorci.
- Morate imati broad poznavanje Cognos okruženja i stvari koje od njega zavise. Na primjer, povijesne kocke s prilagođenim prikazima MORAJU se obnoviti ako krenete NSM rutom.
- Šta ako ste vi ili kompanija koju ste prepustili migraciji prostora imena zaboravili na nešto, poput ... SDK aplikacija? Nakon što prebacite prekidač, ove stvari prestaju raditi ako nisu ispravno ažurirane. Imate li odgovarajuće provjere da to odmah primijetite ili će proći nekoliko sedmica / mjeseci prije nego što simptomi počnu isplivati na površinu?
- Ako ste prošli brojne nadogradnje Cognosa, potencijalno možete imati objekte u svojoj trgovini sadržaja koji su u nedosljednom stanju. Ako ne radite sa SDK -om, nećete moći vidjeti koji su objekti u ovom stanju.
Zašto je zamjena prostora imena najbolja opcija
Ključni faktori rizika i dugotrajni koraci koje sam upravo opisao eliminiraju se kada se koristi metoda zamjene prostora imena Persona. Koristeći pristup zamjene prostora imena, imate 5 minuta zastoja programa Cognos i ništa se od vašeg sadržaja ne mora mijenjati. "Dobra" metoda mi se čini kao "suvišna" metoda. Petak navečer služi za opuštanje, a ne za naglašavanje činjenice da se vaš Content Manager upravo srušio usred migracije prostora imena.
