Kui teil on vaja olemasolev Cognos -keskkond uuesti konfigureerida, et kasutada mõnda muud välist turvaallikat (nt Active Directory, LDAP jne), võite kasutada käputäis meetodeid. Mulle meeldib neid nimetada: "Hea, halb ja inetu". Enne nende heade, halbade ja inetute lähenemisviiside uurimist vaatame mõningaid tavalisi stsenaariume, mis kipuvad Cognose keskkonnas muutma autentimise nimeruumi.
Tavalised ärijuhid:
Riistvara või OS -i värskendamine - BI -riistvara/-infrastruktuuri kaasajastamine võib sageli kaasa aidata. Kuigi ülejäänud Cognos võib teie klanitud uuel riistvaral ja kaasaegsel 64-bitisel operatsioonisüsteemil töötada nagu tšempion, on palju õnne, kui teisaldate oma umbes 2005. aasta Access Manageri versiooni sellele uuele platvormile. Juurdepääsuhaldur (esmakordselt välja antud seeriaga 7) on paljude Cognose klientide jaoks auväärne möödunud päevade varustus. See on ainus põhjus, miks paljud kliendid hoiavad seda kohutavat vana Windows Server 2003 versiooni. Kirjutis on Access Manageri jaoks seina peal olnud juba mõnda aega. See on pärandtarkvara. Mida varem saate sellest eemale minna, seda parem.
Rakenduste standardimine- organisatsioonid, kes soovivad koondada kõigi oma rakenduste autentimise ühe tsentraalselt hallatava ettevõtte kataloogiserveri (nt LDAP, AD) vastu.
Ühinemised ja omandamised- Ettevõte A ostab ettevõtte B ja vajab ettevõtte B Cognose keskkonda, et osutada ettevõtte A kataloogiserverile, tekitamata probleeme nende olemasolevale BI sisule või konfiguratsioonile.
Ettevõtete loovutamised- See on ühinemisstsenaariumi vastand - osa ettevõttest eraldatakse oma üksuseks ja peab nüüd suunama oma olemasoleva BI -keskkonna uuele turvaallikale.
Miks võib nimeruumi migratsioon olla segane?
Cognose keskkonna suunamine uuele turvalisuse allikale ei ole nii lihtne kui uute nimede kogumi lisamine samade kasutajate, rühmade ja rollidega, vana nimeruumi lahtiühendamine ja VOILA!- kõik teie Cognose kasutajad uues nimeruumis on vastavuses nende sisu. Tegelikult võite sageli oma kätes verise segaduse saada ja siin on põhjus, miks…
Kõigile Cognose turvapõhimõtetele (kasutajatele, rühmadele, rollidele) viitab kordumatu identifikaator, mida nimetatakse CAMID -iks. Isegi kui kõik muud atribuudid on võrdsed, on CAMID kasutaja jaoks olemasolevate autentimise nimeruum ei ole sama, mis selle kasutaja CAMID uus nimeruum. See võib hävitada olemasoleva Cognose keskkonna. Isegi kui teil on vaid mõned Cognose kasutajad, peate mõistma, et CAMID -viited on teie sisupoes PALJUD erinevates kohtades (ja võivad eksisteerida isegi väljaspool teie sisupoodi raamistiku mudelites, trafo mudelites, TM1 rakendustes, kuubikutes, planeerimisrakendustes jne) ).
Paljud Cognose kliendid usuvad ekslikult, et CAMID on tõesti oluline ainult minu kausta sisu, kasutajate eelistuste jms osas. See ei saa olla tõest kaugemal. Küsimus ei ole ainult kasutajate arvus, vaid Cognose objektide arv, millega peate muretsema. Sisupoes on üle 140 erinevat tüüpi Cognose objekti, millest paljudel võib olla mitu CAMID -viidet.
Näiteks:
- Pole haruldane, et teie sisupoe ühel ajakaval on mitu CAMID -viidet (ajakava omaniku CAMID, kasutaja CAMID, kellena ajakava peaks töötama, iga kasutaja või jaotusloendi CAMID, kuhu see peaks saatma aruande väljundi) , jne.).
- Igal Cognose objektil on turvapoliitika, mis määrab, millised kasutajad saavad objektile juurde pääseda (mõelge vahekaardile „Load”). Ühel turvapoliitikal, mis ripub selle kausta all Cognos Connectionis, on CAMID -viide igale poliitikale määratud kasutajale, rühmale ja rollile.
- Loodetavasti saate mõttest aru - seda nimekirja saab jätkata!
Pole haruldane, et suur sisupood sisaldab kümneid tuhandeid CAMID -viiteid (ja me oleme näinud suuri sadu tuhandeid).
Nüüd tehke arvutusi selle kohta, mis seal on oma Cognose keskkonda ja näete, et tegelete potentsiaalselt CAMID -viidete hordidega. See võib olla õudusunenägu! Autentimise nimeruumi vahetamine (või uuesti konfigureerimine) võib jätta kõik need CAMID-viited lahendamatuks. See toob paratamatult kaasa Cognose sisu- ja konfiguratsiooniprobleemid (nt ajakavad, mis enam ei tööta, sisu, mis ei ole enam teie arvates kaitstud, paketid või kuubikud, mis ei rakenda enam andmetaseme turvalisust, Minu kausta sisu ja kasutaja kadumine eelistused jne).
Cognose nimeruumi üleminekumeetodid
Nüüd, teades, et Cognose keskkonnas võib olla kümneid tuhandeid CAMID -viiteid, mis vajavad uue autentimisnimeruumi vastava uue CAMID -väärtuse leidmist, kaardistamist ja värskendamist, arutame selle probleemi lahendamiseks häid, halbu ja koledaid lähenemisviise.
Hea: Nimeruumi asendamine Personaga
Esimene meetod (nimeruumi asendamine) kasutab Motioon, Persona IQ toode. Seda lähenemisviisi kasutades asendatakse teie olemasolev nimeruum spetsiaalse Persona nimeruumiga, mis võimaldab teil virtualiseerida kõik Cognosega kokku puutuvad turvapõhimõtted. Olemasolevad turvameetmed puutuvad Cognosega kokku sama CAMID-iga nagu varem, kuigi neid võivad toetada mitmed välised turvaallikad (nt Active Directory, LDAP või isegi Persona andmebaas).
Selle lähenemisviisi ilus osa on see, et see nõuab teie Cognose sisus null muudatust. Selle põhjuseks on asjaolu, et Persona suudab säilitada olemasolevate printsipaalide CAMID-i isegi siis, kui neid toetab uus allikas. Niisiis ... kõik need kümned tuhanded CAMID -viited teie sisupoes, välismudelid ja ajaloolised kuubikud? Nad võivad jääda täpselt selliseks, nagu nad on. Tööd ei nõuta.
See on kaugelt kõige vähem riskantne ja väikseima mõjuga lähenemisviis, mida saate kasutada oma olemasoleva Cognose keskkonna üleminekuks ühest välisest turvaallikast teise. Seda saab teha vähem kui tunni jooksul umbes 5 -minutilise Cognose seisakuga (ainus Cognose seisak on Cognose taaskäivitamine pärast Persona nimeruumi konfigureerimist).
Bad: Nimeruumi migreerimine Persona abil
Kui lihtne ja madala riskiga lähenemisviis pole just teie tass teed, siis seal is teine variant.
Persona saab kasutada ka nimeruumi migreerimiseks.
See hõlmab teise autentimisnimeruumi installimist oma Cognose keskkonda, kõigi loodetavasti turbepõhimõtete (vanast nimeruumist) vastendamist uue nimeruumi vastavate printsipaalidega, seejärel (siin on lõbus osa), iga faili leidmist, kaardistamist ja värskendamist üks CAMID -viide, mis on teie Cognose keskkonnas olemas: teie sisupood, raammudelid, trafomudelid, ajaloolised kuubikud, TM1 -rakendused, planeerimisrakendused jne.
See lähenemisviis kipub olema stressirohke ja protsessimahukas, kuid kui olete selline Cognose administraator, kes vajab natuke adrenaliinilaksu, et end elusana tunda (ega pahanda hilisõhtut / varahommikust telefonikõnet), siis võib -olla… see on see variant mida otsid?
Persona saab kasutada selle protsessi osade automatiseerimiseks. See aitab teil luua kaardistamise vanade ja uute turbepõhimõtete vahel, automatiseerida teie sisupoe sisu loogika „leida, analüüsida, värskendada” jne. Mis Persona saab siin mõningaid ülesandeid automatiseerida Selle lähenemisviisi töö hõlmab pigem inimesi ja protsessi kui tegelikku tehnoloogiat.
Näiteks - teabe kogumine iga raamistikuhalduri mudeli, iga transformerimudeli, iga Planning / TM1 rakenduse, iga SDK -rakenduse kohta, kellele need kuuluvad, ning nende uuendamise ja ümberjaotamise kavandamine võib olla palju tööd. Katkestuste koordineerimine iga Cognose keskkonna jaoks, mida soovite proovida, ja hooldusaknad, mille jooksul saate üleviimist proovida, võib hõlmata planeerimist ja Cognose seisakuid. Tõhusa testimisplaani koostamine (ja selle täitmine) pärast rännet võib olla ka üsna karu.
Samuti on üsna normaalne, et soovite seda protsessi kõigepealt teha tootmiskeskkonnas enne proovides seda tootmises.
Kuigi nimeruumi migratsioon Personaga toimib (ja see on palju parem kui allpool toodud „inetu” lähenemisviis), on see invasiivsem, riskantsem, hõlmab palju rohkem töötajaid ja võtab palju rohkem töötunde kui nimeruumi asendamine. Tavaliselt tuleb üleviimine toimuda väljaspool tööaega, samal ajal kui Cognose keskkond on endiselt võrgus, kuid lõppkasutajatel on vormide kasutamine piiratud.
Inetu: Käsitsi nimeruumi migreerimisteenused
Inetu meetod hõlmab kadestamisväärset lähenemisviisi käsitsi rännata ühest autentimisnimeruumist teise. See hõlmab teise autentimisnimeruumi ühendamist teie Cognose keskkonnaga, seejärel suure osa olemasoleva Cognose sisu ja konfiguratsiooni käsitsi teisaldamist või uuesti loomist.
Näiteks võib seda lähenemisviisi kasutades Cognose administraator proovida:
- Looge rühmad ja rollid uues nimeruumis uuesti
- Looge nende rühmade ja rollide liikmeskonnad uues nimeruumis
- Kopeerige käsitsi minu kaustade sisu, kasutaja -eelistused, portaalikaardid jne igast lähtekontolt igale sihtkontole
- Leidke sisupoest iga poliitikakomplekt ja värskendage see uue nimeruumi samaväärsetele printsipaalidele täpselt samamoodi, nagu see viitas vana nimeruumi põhimõtetele
- Looge kõik ajakavad uuesti ja lisage neile vastavad volikirjad, adressaadid jne.
- Lähtestage sisupoe kõigi objektide kõik „omanik” ja „kontakt” atribuudid
- [Umbes 40 muud asja sisupoes, mille te unustate]
- Koguge kokku kõik FM -mudelid, millel on objekti- või andmetaseme turvalisus:
- Värskendage iga mudelit vastavalt
- Avaldage iga mudel uuesti
- Jagage muudetud mudel tagasi algsele autorile
- Sarnane töö trafode mudelite, TM1 rakenduste ja planeerimisrakenduste jaoks, mis on kaitstud algse nimeruumi vastu
- [ja paljud teised]
Kuigi mõned Cognose masohhistid võivad salaja itsitada rõõmu pärast ideest klõpsata Cognos Connectionis 400,000 XNUMX korda, kipub see lähenemine enamiku mõistlike inimeste jaoks olema äärmiselt tüütu, aeganõudev ja vigadeohtlik. See pole aga selle lähenemisviisi suurim probleem.
Selle lähenemisviisi suurim probleem on see, et peaaegu alati toob kaasa mittetäieliku migratsiooni.
Seda lähenemisviisi kasutades leiate (valusalt) ja proovite kaardistada need CAMID -viited, millest teate… kuid jätate tavaliselt kõik need CAMID -viited, mida te ei tea umbes.
Kui olete mõtlema kui olete selle lähenemisega lõpetanud, siis sageli mitte tõesti teha.
Teie sisupoes on objekte, mis ei ole enam nii kaitstud, nagu te arvate, et teil on… ajakavad, mis ei tööta enam nii, nagu nad varem töötasid, teil on andmeid, mis pole enam nii, nagu te arvate see on nii ja teatud toimingute puhul võib teil olla isegi seletamatuid vigu sa ei saa tõesti näppu panna.
Põhjused, miks halvad ja inetud lähenemisviisid võivad olla kohutavad:
- Automaatne nimeruumi migratsioon paneb sisuhaldurile palju rõhku. Teie sisupoe iga objekti kontrollimine ja võimalik uuendamine võib sageli kaasa tuua kümneid tuhandeid SDK -kõnesid Cognosesse (peaaegu kõik need toimuvad läbi sisuhalduri). See ebatavaline päring suurendab tavaliselt mälu kasutamist / koormust ja seab sisuhalduri üleviimise ajal krahhi ohtu. Kui teie Cognose keskkonnas on juba ebastabiilsust, peaksite seda lähenemist väga kartma.
- Nimeruumi migratsioonid nõuavad suurt hooldusakent. Cognos peab olema üleval, kuid te ei soovi, et inimesed teeksid üleviimisprotsessi käigus muudatusi. Tavaliselt nõuab see nimeruumi migratsiooni alustamist, kui keegi teine ei tööta, näiteks reede õhtul kell 10. Keegi ei taha reede õhtul kell 10 alustada pingelist projekti. Rääkimata sellest, et teie vaimsed võimed ei ole projekti ajal ilmselt parimal tööl ja nädalavahetustel ei nõuab, et oleksite terav!
- Olen maininud, et nimeruumi migratsioonid on aja- ja töömahukad. Siin on natuke rohkem selle kohta:
- Sisu kaardistamise protsess tuleks teha täpselt ja see nõuab meeskonna koostööd ja palju töötunde.
- Ülekandega seotud vigade või probleemide kontrollimiseks on vaja mitu kuivkäiku. Tüüpiline ränne ei lähe esimesel katsel ideaalselt. Teil on vaja ka sisupoe kehtivat varukoopiat, mida saab sellistel juhtudel taastada. Oleme näinud paljusid organisatsioone, kellel pole head varukoopiat saadaval (või millel on varukoopia, millest nad ei tea, et see on puudulik).
- Peate kõik tuvastama väljaspool sisupood, mida see võib mõjutada (raammudelid, trafo mudelid jne). See ülesanne võib hõlmata koordineerimist mitme meeskonna vahel (eriti suurtes jagatud BI -keskkondades).
- Teil on vaja head testimiskava, mis hõlmab esinduslikke inimesi, kellel on erineval määral juurdepääs teie Cognose sisule. Peamine on kontrollida kohe pärast üleviimist, et kõik on täielikult üle viidud ja toimib ootuspäraselt. Tavaliselt on ebapraktiline kõike kontrollida, nii et kontrollite lõpuks loodetavasti representatiivseid proove.
- Teil peab olema broad teadmised Cognose keskkonnast ja sellest sõltuvatest asjadest. Näiteks tuleb kohandatud vaadetega ajaloolised kuubikud NSM -i marsruudil uuesti üles ehitada.
- Mis saab siis, kui teie või ettevõte, kellele tellisite nimeruumi migratsiooni, unustate midagi, näiteks… SDK -rakendused? Kui olete lüliti keeranud, lakkavad need asjad töötamast, kui neid ei värskendata korralikult. Kas teil on vajalikud kontrollid, et seda kohe märgata, või möödub mitu nädalat / kuud, enne kui sümptomid hakkavad ilmnema?
- Kui olete läbinud mitmeid Cognose täiendusi, võib teie sisupoes olla objekte, mis on ebajärjekindlas olekus. Kui te SDK -ga ei tööta, ei näe te selles olekus olevaid objekte.
Miks on nimeruumi asendamine parim valik
Peamised riskitegurid ja aeganõudvad sammud, mille ma äsja kirjeldasin, elimineeritakse Persona nimeruumi asendamise meetodi kasutamisel. Kasutades nimeruumi asendamise lähenemisviisi, on teil 5 minutit Cognose seisakuid ja ükski teie sisu ei pea muutuma. “Hea” meetod tundub mulle lõikav ja kuiv “no-brainer”. Reede õhtud on mõeldud lõõgastumiseks, mitte stressi tekitamiseks asjaolu pärast, et teie sisuhaldur kukkus just nimeruumi migratsiooni keskel kokku.
