Farklı Bir Cognos Güvenlik Kaynağına Geçiş

Mevcut bir Cognos ortamını farklı bir harici güvenlik kaynağı (örneğin Active Directory, LDAP, vb.) kullanmak için yeniden yapılandırmanız gerektiğinde, uygulayabileceğiniz birkaç yaklaşım vardır. Onlara “İyi, Kötü ve Çirkin” demeyi seviyorum. Bu İyi, Kötü ve Çirkin yaklaşımları keşfetmeden önce, bir Cognos ortamında kimlik doğrulama ad alanı değişikliklerini yönlendirme eğiliminde olan bazı yaygın senaryolara bir göz atalım.

Ortak İş Sürücüleri:

Donanımı veya İşletim Sistemini Güncelleme – İş Zekası donanımını/altyapısını modernize etmek sık karşılaşılan bir sürücü olabilir. Cognos'un geri kalanı şık yeni donanımınız ve modern 64-bit işletim sisteminizde bir şampiyon gibi çalışabilirken, Access Manager'ın yaklaşık 2005 sürümünü bu yeni platforma geçirmede iyi şanslar. Access Manager (ilk olarak 7 Serisi ile piyasaya sürüldü) birçok Cognos müşterisi için geçmiş günlerden kalan saygıdeğer bir mirastır. Pek çok müşterinin Windows Server 2003'ün o eski püskü sürümünü kullanmaya devam etmesinin tek nedeni budur. Yazılar, Access Manager için bir süredir duvarda duruyor. Eski bir yazılımdır. Ondan ne kadar çabuk uzaklaşırsan o kadar iyi.

Uygulama Standardizasyonu– Tüm uygulamalarının kimlik doğrulamasını merkezi olarak yönetilen tek bir kurumsal dizin sunucusunda (örn. LDAP, AD) birleştirmek isteyen kuruluşlar.

Birleşme ve Devralmalar– A Şirketi, B Şirketini satın alır ve mevcut BI içeriği veya yapılandırmasında sorunlara neden olmadan A Şirketinin dizin sunucusunu işaret etmek için B Şirketinin Cognos ortamına ihtiyaç duyar.

Kurumsal Elden Çıkarmalar– Bu, birleşme senaryosunun tam tersidir, bir şirketin bir kısmı kendi varlığına bölünür ve şimdi mevcut BI ortamını yeni güvenlik kaynağına yönlendirmesi gerekir.

Ad Alanı Taşımaları Neden Dağınık Olabilir?

Bir Cognos ortamını yeni bir güvenlik kaynağına yönlendirmek, aynı kullanıcılar, gruplar ve rollerle yeni ad alanı eklemek, eski ad alanının bağlantısını kesmek ve VOILA! kadar basit değildir - yeni ad alanındaki tüm Cognos kullanıcılarınız aşağıdakilerle eşleştirilir: onların içeriği. Aslında, genellikle ellerinizde kanlı bir karışıklık ile karşılaşabilirsiniz ve işte bu yüzden…

Tüm Cognos güvenlik ilkelerine (kullanıcılar, gruplar, roller), CAMID adı verilen benzersiz bir tanımlayıcı tarafından başvurulur. Diğer tüm nitelikler eşit olsa bile, bir kullanıcı için CAMID mevcut kimlik doğrulama ad alanı, o kullanıcı için CAMID ile aynı olmayacaktır. yeni ad alanı. Bu, mevcut bir Cognos ortamına zarar verebilir. Yalnızca birkaç Cognos kullanıcınız olsa bile, CAMID referanslarının Content Store'unuzda BİRÇOK farklı yerde bulunduğunu (ve hatta Framework modellerinde, Transformer Modellerinde, TM1 Uygulamalarında, Küplerde, Planlama Uygulamalarında vb. İçerik Mağazanızın dışında da bulunabileceğini) anlamanız gerekir. ).

Pek çok Cognos müşterisi, yanlışlıkla CAMID'nin gerçekten yalnızca Klasörüm içeriği, kullanıcı tercihleri ​​vb. için önemli olduğuna inanır. Bu, gerçeğin ötesinde olamazdı. Bu sadece sahip olduğunuz kullanıcı sayısı meselesi değil, ilgilenmeniz gereken Cognos nesnelerinin miktarı meselesidir. Yalnızca Content Store'da, çoğu birden fazla CAMID referansına sahip olabilen 140'ın üzerinde farklı Cognos nesnesi türü vardır..

Örneğin:

1. Content Store'unuzdaki tek bir Çizelgenin birden çok CAMID referansına (program sahibinin CAMID'si, programın çalışması gereken kullanıcının CAMID'si, her kullanıcının CAMID'si veya e-postayla oluşturulacak rapor çıktısını e-postayla göndermesi gereken dağıtım listesi) olması alışılmadık bir durum değildir. , vesaire.).
2. Cognos'taki her nesnenin, hangi kullanıcıların nesneye erişebileceğini yöneten bir güvenlik politikası vardır ("İzinler Sekmesi"ni düşünün). Cognos Connection'da o klasörde asılı duran tek bir güvenlik ilkesi, o ilkede belirtilen her kullanıcı, grup ve rol için bir CAMID referansına sahiptir.
3. Umarım konuyu anlamışsınızdır - bu liste uzayıp gidiyor!

Büyük bir Content Store'un on binlerce CAMID referansı içermesi alışılmadık bir durum değildir (ve yüzbinlerce büyük referansı gördük).

Şimdi, içindekilerin matematiğini yap senin Cognos ortamında ve potansiyel olarak bir sürü CAMID referansıyla uğraştığınızı görebilirsiniz. Bir kabus olabilir! Kimlik doğrulama ad alanınızı değiştirmek (veya yeniden yapılandırmak), bu CAMID referanslarının tümünü çözülemez bir durumda bırakabilir. Bu, kaçınılmaz olarak Cognos içerik ve yapılandırma sorunlarına yol açar (örneğin, artık çalışmayan programlar, artık düşündüğünüz şekilde güvenli olmayan içerik, veri düzeyi güvenliğini artık doğru şekilde uygulamayan paketler veya küpler, Klasörüm içeriği ve kullanıcı kaybı tercihler vb.)

Cognos Ad Alanı Geçiş Yöntemleri

Şimdi, bir Cognos ortamının, yeni kimlik doğrulama ad alanında karşılık gelen yeni CAMID değerine karşılık gelen bulmayı, eşleştirmeyi ve güncellemeyi gerektirecek on binlerce CAMID referansına sahip olabileceğini bilerek, bu sorunu çözmek için İyi, Kötü ve Çirkin yaklaşımlarını tartışalım.

İyi: Persona ile Ad Alanı Değiştirme

İlk yöntem (Ad Alanı Değiştirme) kullanır MotioVar, Kişilik IQ'su ürün. Bu yaklaşımı benimseyerek, mevcut ad alanınız, Cognos'a maruz kalan tüm güvenlik ilkelerini sanallaştırmanıza olanak tanıyan özel bir Persona ad alanıyla "değiştirilir". Önceden var olan güvenlik sorumluları, herhangi bir sayıda harici güvenlik kaynağı (örneğin, Active Directory, LDAP ve hatta Persona veritabanı) tarafından desteklenebilseler bile, öncekiyle tamamen aynı CAMID ile Cognos'a sunulacaktır.

Bu yaklaşımın güzel yanı, Cognos içeriğinizde SIFIR değişiklik gerektirmesidir. Bunun nedeni, Persona'nın yeni bir kaynak tarafından desteklenseler bile önceden var olan müdürlerin CAMID'lerini koruyabilmesidir. Yani… Content Store, harici modeller ve geçmiş küplerdeki on binlerce CAMID referansı mı? Tam olarak oldukları gibi kalabilirler. Gerekli bir çalışma yok.

Bu, mevcut Cognos ortamınızı bir harici güvenlik kaynağından diğerine geçirmek için kullanabileceğiniz açık ara en az riskli, en düşük etkiye sahip yaklaşımdır. Yaklaşık 5 dakikalık Cognos kapalı kalma süresiyle bir saatten daha kısa bir sürede yapılabilir (tek Cognos kapalı kalma süresi, Persona ad alanını yapılandırdıktan sonra Cognos'u yeniden başlatmaktır).

Kötü: Persona kullanarak Ad Alanı Geçişi

Kolay, düşük riskli yaklaşım sizin için bir fincan çay değilse, o zaman orada is başka seçenek.

Persona, Ad Alanı Geçişi gerçekleştirmek için de kullanılabilir.

Bu, Cognos ortamınıza ikinci bir kimlik doğrulama ad alanı yüklemeyi, (umarım) tüm mevcut güvenlik ilkelerinizi (eski ad alanından) yeni ad alanındaki karşılık gelen ilkelerle eşleştirmeyi, ardından (işte eğlenceli kısım), her birini bulmayı, eşleştirmeyi ve güncellemeyi içerir. Cognos ortamınızda bulunan tek CAMID referansı: İçerik Deponuz, Çerçeve Modelleriniz, Transformer Modelleriniz, Tarihsel küpler, TM1 Uygulamaları, Planlama Uygulamaları vb.

Bu yaklaşım stresli ve süreç yoğun olma eğilimindedir, ancak canlı hissetmek için biraz adrenaline ihtiyaç duyan (ve gece geç saatlerde / sabah erken telefon görüşmelerini umursamayan) bir Cognos yöneticisiyseniz, o zaman belki…  Re-Tweet aradığınız seçenek mi?

Persona, bu sürecin bölümlerini otomatikleştirmeye yardımcı olmak için kullanılabilir. Eski güvenlik ilkeleri ile yeni güvenlik ilkeleri arasında bir eşleme oluşturmanıza, içerik deponuzdaki içerik için kaba kuvvet "bul, analiz et, güncelle" mantığını otomatikleştirmenize vb. yardımcı olacaktır. Bu yaklaşımdaki işin en önemli kısmı gerçek teknolojiden ziyade “insanları ve süreci” içerir.

Örneğin – her Framework Manager modeli, her Transformer modeli, her Planning / TM1 uygulaması, her SDK uygulaması, bunların sahibi hakkında bilgi derlemek ve bunların nasıl güncellenip yeniden dağıtılacağını planlamak çok fazla iş olabilir. Bunu denemek istediğiniz Cognos ortamlarının her biri için kesintileri ve geçişi deneyebileceğiniz bakım pencerelerini koordine etmek, planlamayı ve Cognos'un "kapalı kalma süresini" içerebilir. Geçişinizden sonra için etkili bir test planı oluşturmak (ve yürütmek) de oldukça zor olabilir.

Bu işlemi önce üretim dışı bir ortamda yapmak istemeniz de oldukça normaldir. önce üretimde deniyoruz.

Persona ile Ad Alanı Geçişi işe yarasa da (ve aşağıdaki “Çirkin” yaklaşımdan çok daha iyidir), daha istilacıdır, daha risklidir, çok daha fazla personel gerektirir ve yürütülmesi Ad Alanı Değiştirme'den çok daha fazla adam saati alır. Genellikle taşıma işlemlerinin "kapalı saatlerde", Cognos ortamı hala çevrimiçiyken, ancak son kullanıcılar tarafından form kullanımı kısıtlanmışken yapılması gerekir.

Çirkin: Manuel Ad Alanı Taşıma Hizmetleri

Çirkin yöntem, kıskanılmayan bir yaklaşımı içerir. el ile bir kimlik doğrulama ad alanından diğerine geçiş yapın. Bu, Cognos ortamınıza ikinci bir kimlik doğrulama ad alanı bağlamayı ve ardından mevcut Cognos içeriği ve yapılandırmasının çoğunu manuel olarak taşımayı veya yeniden oluşturmayı denemeyi içerir.

Örneğin, bu yaklaşımı kullanarak bir Cognos yöneticisi şunları yapmaya çalışabilir:

1. Yeni ad alanında grupları ve rolleri yeniden oluşturun
2. Yeni ad alanında bu grupların ve rollerin üyeliklerini yeniden oluşturun
3. Klasörlerim içeriğini, kullanıcı tercihlerini, portal sekmelerini vb. her kaynak hesaptan her hedef hesaba manuel olarak kopyalayın
4. Content Store'daki her İlke Kümesini bulun ve eski ad alanındaki ilkelere başvurduğu şekilde yeni ad alanındaki eşdeğer ilkelere başvurmak için güncelleyin
5. Tüm programları yeniden oluşturun ve bunları ilgili kimlik bilgileri, alıcılar vb. ile doldurun.
6. Content Store'daki tüm nesnelerin tüm "sahip" ve "iletişim" özelliklerini sıfırlayın
7. [Content Store'da unutacağınız yaklaşık 40 şey daha]
8. Nesne veya veri seviyesi güvenliği ile tüm FM modellerini toplayın:
   1. Her modeli buna göre güncelleyin
   2. Her modeli yeniden yayınla
   3. Değiştirilen modeli orijinal yazara geri dağıtın
9. Orijinal ad alanına karşı güvence altına alınan Transformer modelleri, TM1 Uygulamaları ve Planlama Uygulamaları için benzer çalışma
10. [ve daha fazlası]

Bazı Cognos mazoşistleri Cognos Connection'da 400,000 kez tıklama fikrine gizlice neşeyle kıkırdayabilirken, çoğu mantıklı insan için bu yaklaşım son derece sıkıcı, zaman alıcı ve hataya açık olma eğilimindedir. Ancak bu yaklaşımdaki en büyük sorun bu değil.

Bu yaklaşımla ilgili en büyük sorun, neredeyse her zaman tamamlanmamış bir göçe yol açar.

Bu yaklaşımı kullanarak, (acı verici bir şekilde) hakkında bilgi sahibi olduğunuz CAMID referanslarını bulup eşleştirmeye çalışırsınız…ama bildiğiniz tüm CAMID referanslarını bırakma eğilimindesinizdir. hakkında bilmiyorum.

Sonra düşünmek bu yaklaşımla işiniz bitti, genellikle değilsiniz Gerçekten mi bitti.

İçerik deponuzda artık düşündüğünüz şekilde güvenli olmayan nesneleriniz var… eskiden olduğu gibi çalışmayan programlarınız var, artık düşündüğünüz şekilde güvenli olmayan verileriniz var öyledir ve bazı işlemler için açıklanamayan hatalara bile sahip olabilirsiniz. gerçekten parmağını koyamazsın.

Kötü ve Çirkin Yaklaşımların Korkunç Olmasının Nedenleri:

• Otomatik Ad Alanı Geçişleri, İçerik Yöneticisi üzerinde çok fazla stres yaratır. Content Store'unuzdaki her bir nesnenin incelenmesi ve potansiyel güncellemesi, genellikle Cognos'a on binlerce SDK çağrısıyla sonuçlanabilir (neredeyse tümü Content Manager aracılığıyla akar). Bu anormal sorgulama tipik olarak bellek kullanımını/yükünü artırır ve İçerik Yöneticisi'ni taşıma sırasında çökme riskine sokar. Cognos ortamınızda zaten herhangi bir miktarda kararsızlık varsa, bu yaklaşımdan çok korkmanız gerekir.
• Ad Alanı Geçişleri, oldukça büyük bir bakım penceresi gerektirir. Cognos'un çalışması gerekiyor, ancak insanların geçiş sürecinde değişiklik yapmasını istemiyorsunuz. Bu genellikle ad alanı geçişinin başka hiç kimse çalışmadığında (diyelim ki bir Cuma gecesi saat 10:10'de) başlamasını gerektirir. Hiç kimse bir Cuma gecesi saat XNUMX'de stresli bir projeye başlamak istemez. Zihinsel yetilerinizin muhtemelen geceleri ve hafta sonları bir projede en iyi şekilde çalışmadıklarından bahsetmiyorum bile. yok keskin olmanızı gerektirir!
• Ad Alanı Geçişlerinin zaman ve emek yoğun olduğundan bahsetmiştim. İşte bununla ilgili biraz daha:
  • İçerik eşleme süreci hassas bir şekilde yapılmalıdır ve bu, ekip işbirliğini ve birçok çalışma saatini gerektirir.
  • Geçişle ilgili hataları veya sorunları kontrol etmek için birden çok kuru çalıştırma gerekir. Tipik bir geçiş, ilk denemede mükemmel gitmez. Ayrıca, bu gibi durumlarda geri yüklenebilecek geçerli bir Content Store yedeğine ihtiyacınız olacaktır. Kullanılabilir iyi bir yedeği olmayan (veya eksik olduğunu anlamadıkları bir yedeği olan) birçok kuruluş gördük.
  • her şeyi tanımlaman gerek dışında potansiyel olarak etkilenebilecek Content Store (çerçeve modelleri, dönüştürücü modelleri vb.). Bu görev, birden fazla ekip arasında koordinasyonu içerebilir (özellikle büyük paylaşılan BI ortamlarında).
  • Cognos içeriğinize farklı derecelerde erişime sahip temsili kişileri içeren iyi bir test planına ihtiyacınız var. Buradaki anahtar, geçiş tamamlandıktan kısa bir süre sonra her şeyin tamamen taşındığını ve beklediğiniz gibi çalıştığını doğrulamaktır. Her şeyi doğrulamak genellikle pratik değildir, bu nedenle temsili örnekler olduğunu umduğunuz şeyi doğrularsınız.
• b'ye sahip olmalısınroad Cognos ortamı ve ona bağlı olan şeyler hakkında bilgi. Örneğin, NSM yoluna giderseniz özel görünümlere sahip geçmiş küplerin yeniden oluşturulması ZORUNLUDUR.
• Ya siz ya da şirket, SDK uygulamaları gibi bir şeyi unutmak için ad alanı geçişini dışarıdan temin ettiyseniz? Anahtarı çevirdikten sonra, düzgün bir şekilde güncellenmezlerse bu şeyler çalışmayı durdurur. Bunu hemen fark etmek için uygun kontrolleriniz var mı, yoksa semptomların ortaya çıkması birkaç hafta/ay mı sürecek?
• Çok sayıda Cognos yükseltmesinden geçtiyseniz, Content Store'unuzda tutarsız durumda olan nesneler olabilir. SDK ile çalışmazsanız, hangi nesnelerin bu durumda olduğunu göremezsiniz.

Neden Ad Alanı Değiştirme En İyi Seçenektir?

Az önce özetlediğim temel risk faktörleri ve zaman alıcı adımlar, Persona Ad Alanı Değiştirme yöntemi kullanıldığında ortadan kalkar. Ad Alanı Değiştirme yaklaşımını kullanarak, 5 dakikalık Cognos kapalı kalma süreniz olur ve hiçbir içeriğinizin değişmesi gerekmez. “İyi” yöntem bana kesin ve kuru bir “beyinsiz” gibi görünüyor. Cuma geceleri rahatlamak içindir, İçerik Yöneticinizin bir Ad Alanı Geçişinin ortasında çökmesi gerçeğini strese sokmamak içindir.