Lingering, lingering ….

Ilusad sõnad, tahaks peaaegu laulda, kui ei teaks nende sõnade halvamaigulist tähendus Active Directory kontekstis.

Lingering Objects – ehk siis jäänuk objektid (vabandust, pole õiget tõlget) on AD objektid mis on peamiselt tekkinud halvasti töötava replikatsiooni tagajärjel. Koos virtualiseerimise levikuga avanes veel üks võimalus – nn tagasikerimine, kus DC P2V muutmisel tehti vigu või DC taastati VM snapshotist  protseduure jälgimata.

Suurem tõenäosus jäänukobjekte kohata on suurtes AD implementatsioonides, mis hõlmavad paljusid DC sid ja paljusid ( sageli ebakindla Interneti VPN’iga) ühendatud andmekeskusi. Ja kui neid haldavad veel erinevad tiimid (erineva kompetentsi tasemega) siis …

Jäänukobjektide esimene avaldus on see, et AD ei taha enam replikeeruda – sellest saab mööda, kui lubada “non-strict” replikeerumisviis. KUID, see ei kõrvalda algpõhjust. Jäänukobjektide kõrvaldamine eeldas omajagu käsitööd ldp ja repadmin’ tööriistadega. See oli tüütu ja nõudis suurt täpsust.

Hiljuti sa MS AD team “valmis” (noh, betasse) SUUREPÄRASE tööriista – Lingering Object Liquidator (LOL) ’i. Seda ei jagata veel päris avalikult ja selle kasutamine nõuab veel siiski teadmisi ( ja õigusi ) aga siiski on tegu suure sammuga edasi.

Tervet kasutusjuttu pole mõtete ümber rääkida. Härrad ja Prouad – see on tõeline kullafond.

Advertisements

Kas 2012 (ja R2) hakkab rohkem valmis saama?

 

1401_admt1_png-550x0       See võib esmapilgul tunduda kohatu küsimusena, sest esimese GA’st möödub sügisel kaks aastat ja R2 on tsipake üle aasta noorem. Aga jah, kui Sinu infra on lihtne ja Sul pole tekkinud aastatega mingit kentsakat taaka vajadustest ja seostest teiste tarkvaratoodetega siis ei ole üldiselt probleeme juba esimesel päeval. Ainuke probleem võib-olla internetis leiduva dokumentatsioni ja teadmuste vähesuses. Sest, üldiselt on tehtud head tööd ta töötab.

Paraku võib-olla suuremate organisatsioonide juures vaja kasutada mingeid erifunktsionaalsusi või tööriistu, mis on disainitud eelmiste põlvkondade jaoks ja mis lihtsalt keelduvad uuel versioonil töötmast.  Üheks selliseks oli ADMT ( ehk Active Directory Migration Toolkit). ADMT on mõeldud AD objektide liigutamiseks metsade/domeenide vahel. Kõige lihtsam näide – Sinu töötaja Brasiiliast kolib Itaaliasse ja vaja liigutada tema kasutaja ja arvutiobjekt, nii et õigused ja ajalugu paika jääks. Või on vaja liita uus värskelt ostetud organistatsioon korporatsiooni AD’ga.

ADMT eelmine versioon töötas suurepäraselt senikaua, kuni domeen polnud uuendatud 2012 tasemele. Oli olemas ka hullumeelne variant migreerimise ajaks lisada 2008 Server ja domeeni taset PS abil madalamaks kruttida. See võib olla OK ühekordse migratsiooni puhul, aga igapäevaseks või sageli korduvaks tegevuseks see päris OK ei ole.

Nüüd juunis saadi siis valmis uus ADMT versioon (mis tegelikult ikka kannab 3.2 numbrit, kuna funktsionaalsus jäi samaks) mis toetab ka suurema keemiata uusi serveriversioone ja domeenitasemeid. Binaarid on otse loomulikult uued.

Dok – seal – http://www.microsoft.com/en-us/download/details.aspx?id=19188

Ja download ise  – http://connect.microsoft.com/site1164/content/content.aspx?ContentID=22983

Deploying .NET 4 = NOT Deploying .NET 4

image

Kurvastusega tuleb mainida, et MS on teinud liiga palju “traagilisi” muudatusi ja hetkel mina ei tea mehhanismi, kuidas levitad .NET 4 frameworki ei AD GPO ega SCCM Application Deploymenti abil.

Tuleb kasutada vanamoodsaid Login Script installe või Pakage Installi.

Võrgus on leitavad küll mõned trikitamised, kuid lõpptulemusena on tegemist väga suure tõenäosusega KATKISE .NET deploymendiga.

Jah, vanemate .NET versioonide deploy saab käima, kui kasutada exe lahtipakkimist ja MSI’dele transformide ettesöötmist (vältimaks hoiatust, et sa ikka setup’I kasutaksid). Versioon 4 on paraku väga pirtsakas.

Tundub, et teatud firmas teatud osakonnad ei räägi omavahel või siis on neil mingi kana (millest allakirjutanu ei tea) kitkuda. Igatahes kaasaegseks seda lähenemist nimetada ei saa.

Ühe variandina võib välja pakkuda levitamist WSUS / SCCM Software Updates kaudu.

image

Keywords: deploy, .NET 4 , MSI, SCCM.

Delegeerimine. Osa I

 

image

Delgeerimine on lahe!

Tänapäeval, kui moes on Self-Service kõikvõimalikes eluvaldkondades ja avaldustes – tankimine, pangatehingud, iseteeninduskassad, tarkvarapaigaldus, vabatahtlikud moderaatorid foorumis, firmwareuuendus/-hooldus saab enda adminni elu ka lihtsamaks teha ja osa igapäevaseid tööoperatsioone edasi delgeerida.

Väiksemas firmas on kõige lihtsam delgeerimine olukord, kus kõik teevad kõiki ja eeldame et kõik on firma heaolu eest väljas. Suuremas firmas seevastu tulevad mängu igasugused poliitilised, regulatoorsed ja korralduslikud takistused. No ja võimalik, et alati  pole täidesaatev isik ka teadmistelt kõige pädevam (või võtab täitmine ülemõistuse palju aega).

Nii et alustuseks, kui tahad midagi edasi delegeerida, mõtle enda jaoks selgeks:

  1. millist tööülesannet soovid volitada,
  2. kellele tahad volitada,
  3. kas tal on piisavad teadmised selleks täitmiseks,
  4. proovi talle võimaldada võimalikult lollikindel UI selle töö tegemiseks
      1. Süsteemiadministraatorite maailmas (Windowsi mäta otsast) on MS selle nimel nüüd aastaid vaeva näinud ja tasapisi hakkab asi mugavamaks minema. Kuigi palju on veel teha saab teatud tööülesandeid efektiivselt, lihtsalt ja turvaliselt edasi volitada.
          Allpool (ja järgnevalt) natuke näited, kuidas midagi töötab ja kuidas mitte.

          Active Directory ja objektid.

        AD objektide üle õiguste volitamine muutus saadavaks juba Windows 2000 ajal, kus toodi sisse Delegate Control Wizard.

        Delegate Control  viisard on “suhteliselt lollikindel” vahend lihtsamate operatsioonide edasivolitamiseks. Samas on Delegate Wizardil üks suur viga. Tehtud delegatsioone pole lihtne tagasi võtta – ehk – mõtle ennem hoolega kellele ja mida sa volitad.

        Siia näpunäide – loo endale AD’sse rolligrupp ja tee volitus grupile, siis on hiljem lihtne lisada või eemaldada reaalseid kasutaja kontosid, kes seda tegevust tegema peavad ning Sa ei pea uuesti delegeerimist tegema.

        Mida siis delgeerimisviisard teeb? Kogu tegevus seisneb tegelikult objekti (või omaduste) turbeomaduste muutmises. Ehk sedamasa saab teha ka Security saki kaudu, kui Sa tead mida Sa soovid teha. Security saki kaudu saab tegelikult ka vajadusel “unDelegate” teha, mis piiratud konteksti raames on isegi OK, kuid sealt kaudu terve metsa mingite objektide omaduste turbeomadusi näppida on väga kahtlane tegevus.

         

        Siia jutu juurde ka 1 praktiline näide.

        Olgu meil AD’s defineeritud mingi OU kuhu pannakse kõik tööjaamad, mis domeeni ühinevad. Iga harukontori jaoks on omaette OU, kus siis kohalikud administraatorid majandavad – lingivad GPO’sid, kustutavad kontosid jne. Selleks peaksid saidiadminid liigutama arvutid oma OU’sse.

        Delegeerimisviisardiga on lihtne anda saidiadminidele Create/Delete Computer objects õigusi, KUID selleks et tõsta (move) arvuti konto ühest OU’st teise sellest siiski ei piisa. Liigutamisel antakse üldine Access Denied veateade…

        WHAT!!

        Sügavamal uurimisel tuleb välja, et miinimum nõuded MOVE operatsiooniks on:

        1. lähte OU’s(konteineris) objekti kustamisõigus (tehtud);
        2. siht OU’s (konteineris) objekti loomisõigus (tehtud);
        3. WRITE PPROPERTY objekti kohta, mida liigutatakse ( ehk siis näiteks arvuti objekti liigutades, muutub tema  CN ja RDN. Ja seda Delegate Control ei teinud.

        Võimalik, et ühel ilusal päeval on ka move operatsiooni lihtne delgeerimisviisardiga paika sättida.

         

        Keywords: active directory, move object, access denied.