Dotaz: Samba jako PDC a problémy s tím spojené

[Zdeněk Zámečník]

Ahoj, po delší době jsem v práci zprovoznil Sambu jako PDC s autentizací vůči LDAPu s cestovními profily a teď neustále řeším nějaké problémy s oprávněním. Myslím si, že problém souvisí se souborem NTconfig.POL, který jsem se nejdříve snažil vytvořit, ale nakonec jsem použil původní, který jsem používal již několik let na jiném serveru a nebyl s ním problém.

Řeším tyto nectnosti: 1) Uživatelé v doméně nemohou přidávat sdílené tiskárny, administrator může. Zjistil jsem, že toto lze ve Windows obejít přes gpedit.msc vypnutím funkce Ukázat a tisknout. 2) Uživatelé nemohou vypalovat CD v žádném programu, administrator může.

Dokázal by mi někdo poradit, kde konkrétně hledat příčinu? S vytvořením vlastní politiky už jsem se natrápil víc než dost a nedostal to do funkčního konce, proto jsem použil tu starou. Víceméně ji tam mám jen proto, abych změnil umístění uživatelských profilů tak, aby byly uloženy přímo na serveru a neprobíhala při přihlašování a odhlašování synchronizace profilu.

Předem díky za jakékoliv nasměrování.

Odpovědi

[ET]

Zdar,

problem bude dost urcite v tom pol souboru - takze bud opravit ten a nebo napsat login script kterej to prebije pri prihlaseni [ reg.exe add ...]a pustit na vsechny pc/usery. Dost urcite to bude nejaka "krasna" hodnota v registrech, takze bud si to odchytis regmonem od sysinternals pri zmene v gpeditu nebo se koukni jak je ta politika definovana v template [%systemroot%/inf/*adm soubory] - predpokladam ze vis jak se ta politika v gpeditu jmenu/kde je v tom strome - najdi to v tom .adm souboru a mas klic kterej tim login scriptem budes prebijet. Davam to z hlavy, na widle jsem uz rok nesahnul...

good luck

[ET]

PS: pokud pouzivas ten pol soubor jen na ty home/profily mozna nebude od veci vygenerovat uplne cistej pouze s tou zmenou home/profile - dost urcite se ti tam dostalo neco co tiskarny/paleni zakazuje. To povoleni vypalovani je, co si pamatuju, hooodne velkej problem - u nera na to byl nakej jejich nastroj...

[li737]

Jen bych doplnil, že je potřeba myslet na to že jednou aplikované politiky na stroje tam zůstávají. Takže pokud se vám povedlo zakázat pro usery nějakou funkci tak je potřeba ji opět explicitně zapnout. Event. jak je napsáno výše přepsat to "ručně" skriptem po loginu. Čistší je to zapnout např. v gpo ou pro všechny nebo v gpo aplikovanem na konkrétní skupinu např. users pokud máte k dispozici w2k3 apod.

[Zdeněk Zámečník]

Já ještě pro změnu doplním, že politiky lze na stanicích znovu načíst příkazem gpupdate /force. Třeba se to někomu bude hodit. Mě to rozhodně ušetřilo hodně času.

[Zdeněk Zámečník]

Ok, zkusím udělat novej NTconfig.pol a snad se zadaří. Díky.

[ET]

jak tu psal li737 - aplikace cistyho .pol souboru nepomouze starym pc, ale na nove pridanych strojich se to zbytecne nezaflaka spatnym nastavenim

vzpomnel jsem si na takovej trik, mozna se bude hodit - vlez na pc s aplikovanou policy, pust gpedit.msc a nekde v menu je filtr - odfiltruj jen zmeneny polozky

[VSi]

Předpokládám, že jde o Windows XP.

Víceméně ji tam mám jen proto, abych změnil umístění uživatelských profilů tak, aby byly uloženy přímo na serveru a neprobíhala při přihlašování a odhlašování synchronizace profilu.

Toho se dá nějak dosáhnout? Je to někde zdokumentováno / máte to vyzkoušené? Dají se udělat "redirections" pro vybrané části profilu - Plocha, Data aplikací, ... A to nastavením v uživatelské větvi Registry, které se dá dělat i v rámci logon skriptu. Řekl bych, že minimálně soubor NTUSER.DAT musí být na lokálním disku - tedy se musí kopírovat ze serveru a zpět.

Já používám jen přesměrování Dokumentů a Plochy, a pro problémové aplikace je nastavený seznam složek z APPDATA, které se nekopírují zpět na server (různé cache). Je to vyhovující i v situaci, kdy se během pár minut přihlašuje přes 100 uživatelů - stažení profilu trvá max. desítky sekund, a to ještě mažeme lokální kopie profilů. Samozřejmě záleží na propustnosti storage a sítě.

Na NTconfig.pol bych se vykašlal, podle mě to je trochu magie a špatně se to ladí, byť teoreticky je to systémovější a čistější než jiná řešení. Stejně to nastavuje jen určité hodnoty v Registry, a to si můžu vyřešit přehledným skriptem, který pouštím v rámci přípravy PC na připojení do domény.

Uživatelé v doméně nemohou přidávat sdílené tiskárny, administrator může. Zjistil jsem, že toto lze ve Windows obejít přes gpedit.msc vypnutím funkce Ukázat a tisknout.

Výchozí chování bez nějakého NTconfig.POL a jiných úprav je, že normální uživatelé mohou přidávat tiskárny sdílené přes Windows sdílení (\\hostname\tiskarna), a asi i přes IPP (HTTP). Dokonce přidání tiskárny a nakopírování ovladačů proběhne automaticky při rozkliknutí tiskárny zobrazené přes "Místa v síti", nebo jak se to jmenuje. Jestli vám tohle nefunguje, tak to máte někde tak nastavené. Není dovoleno přidávat tiskárny sdílené třeba přes LPR, ty jsou společné pro všechny uživatele.

Neznám vaše prostředí, ale možná bych se víc zamyslel, co je cílem, resp. proč by měli uživatelé sami přidávat nějaké tiskárny. Já jsem měl naopak problém, že takto přidané tiskárny jsou trvale uložené v cestovním profilu, takže jsou stejné na všech PC. Když nějakou tiskárnu zrušíte, musí si ji všichni ručně odebrat. Nebo to lze zařídit přes logon skript, ale v rozsáhlejším prostředí je těžké udržet v tom pořádek, a na schopnosti uživatelů moc spoléhat nejde. Většinou jsem spíš potřeboval, aby různých počítačích uživatel viděl jen v místě fyzicky dostupné tiskárny + nějaké globálně přístupné.

Uživatelé nemohou vypalovat CD v žádném programu, administrator může.

To nesouvisí s doménou, je to obecná vlastnost, a konkrétní program si s tím musí umět poradit. Možná je na to nějaký obecný trik, to nevím. U starších verzí Nero se dal doinstalovat doplněk, kde to šlo nastavit. Teď používáme CDBurnerXP, a není problém, plně funguje i pod omezeným účtem.

[Zdeněk Zámečník]

No je to tak, jak říkáš - dají se nastavit umístění jen pro některé složky (Plocha, Data aplikací, Dokumenty...) a to mi bohatě stačí. Konkrétně největší problém pro mne byla synchronizace složky Data aplikací, kde někteří uživatelé mají i několik desítek GB a to pak někdy přihlášení/odhlášení opravdu trvá.

Ohledně tisku - cituji gpedit.msc>Konfigurace uživatele>Šablony pro správu>Ovládací panely>Tiskárny>Omezení funkce Ukázat a tisknout:

Toto nastavení zásad omezuje servery, ke kterým se klient může připojit za účelem tisku. Toto nastavení zásad se týká pouze klientů, kteří nejsou členy skupiny Print Administrators, a počítačů, které jsou členy domény. Pokud je toto nastavení zásad povoleno, může být klient omezen tak, aby mohl odkazovat a tisknout pouze na serverech ve vlastní doménové struktuře nebo v seznamu explicitně důvěryhodných serverů. Jestliže toto nastavení zásad není nakonfigurováno, lze ve výchozím nastavení odkazovat a tisknout pouze v rámci doménové struktury klienta. Pokud je toto nastavení zásad zakázáno, mohou klientské počítače odkazovat a tisknout na libovolném serveru.

Ve výchozím stavu je toto nastavení povoleno, tzn. doménové stanice jsou omezeny. Takže řešit by to šlo řešit také přidáním všech uživatelů do Print Administrators.

Ohledně tipu s CDBurnerXP díky, vyzkouším ho.

[VSi]

Konkrétně největší problém pro mne byla synchronizace složky Data aplikací, kde někteří uživatelé mají i několik desítek GB a to pak někdy přihlášení/odhlášení opravdu trvá.

Desítky GB, to je fakt hodně, a moc si neumím představit, jaká aplikace to tam může oprávněně ukládat. Možná nějaký poštovní klient s offline kopiemi mailů, ale tam se dá ukládání nastavit i jinam, nebo se vůbec zamyslet, jestli v prostředí s cestovními profily je tohle žádoucí. Já jsem spíš šel cestou, že velikost profilů sleduju, a pokud začne být nějaký enormně velký, je to většinou chyba v konfiguraci aplikace, nebo její špatná vlastnost. Zatím se mi to vždycky podařilo nějak vyřešit. Je pravda, že každou aplikaci na tohle předem testujeme, a často je třeba přes logon skript zajistit správné nastavení pro všechny uživatele.

Šablony pro správu>Ovládací panely>Tiskárny>Omezení funkce Ukázat a tisknout

To jsem neznal. Vždycky jsem zkoušel přidávat tiskárny jen ze serverů, které byly součástí domény, a u těch to ve výchozím nastavení jde.

Jinak u NTconfig.POL je třeba dát pozor na to, co už psali i jiní, že dochází k tzv. "registry tattooing". Když nějaké nastavení z politiky odstraníte, nevrátí se automaticky na výchozí stav. Je tedy nutné mít přehled o všech nastaveních, které se někde i přechodně používaly, a v aktuální politice pro ně mít nastavené výchozí hodnoty.

Mě se spíš osvědčilo mít skript (BAT, VBS), který tyhle věci nastavuje, a zároveň vrací zpět nastavení, která se dříve někde zkoušela jinak. Když udělám nějakou změnu, staré verze si schovávám. Takový skript se pouští před zařazením stroje do domény, a pak nějakým mechanismem na všech počítačích, když se v něm něco změní - buď přes psexec; nebo se dá nastavit Task, který se spouští při každém startu OS; nebo, pokud máte, přes obecný patch-management systém (dá se použít WPKG).

[Zdeněk Zámečník]

Odhadnul jsi to správně - v mém prostředí největší položkou v Data Aplikací jsou právě data Thunderbirdu a jednoduše se tomu nemohu vyhnout.

Co se týče těch tiskáren, dříve jsem se s tímto problémem vůbec nesetkal. Ty tiskárny mi běží přímo na tom PDC, tak nechápu, proč tam ten problém je, ale sžil jsem se s tím. Zjistil jsem, že nejsem sám, kdo kvůli tomu mění nastavení funkce Ukázat a tisknout.

Moc díky za tip s aplikováním změn politik. Přemýšlel jsem, jak to nějak podobně aplikovat, protože se v těch provedených změnách ztrácím.

[Zdeněk Zámečník]

Ještě bych měl jeden dotaz, když se tu sešlo tolik zkušených. Přesměrování uživatelských složek (tak aby se používaly přímo na serveru) s sebou nese také své problémy, resp. já vím o jednom - v případě, že dojde byť jen ke krátkému přerušení spojení se serverem anebo pokud provedu restart Samby, na všech stanicích se objeví hláška "Zápis se zpožděním se nezdařil..." a víceméně je v tu chvíli stanice nepoužitelná, dokud ji nerestartuji. V prostředí, kde jsou nepřetržitě využívány všechny klientské stanice, je to dost nepříjemné. Neřešil toto někdo? Resp. nebyl by nápad, jak to řešit?

[VSi]

Právě proto se profil kopíruje ze serveru a zpět ono to není vymyšlené zas tak špatně.

V praxi mi přesměrování funguje dobře u složky Dokumenty, tam se s tím aplikace nějak vyrovnají, nebo to nevede na celkovou nepoužitelnost. U složky Data Aplikací s tím problémy celkem očekávatelně jsou. Je to dané tím, s jakou sémantikou tuto složku aplikace používají - mají tam trvale otevřené / kontrolované / zapisované soubory, zámky a podobně. A prostě s druhem chyb, který nastává při ztrátě spojení na CIFS server ty aplikace absolutně nepočítají. Je teba si uvědomit, že ten "disk" připojený přes CIFS se ve Windows v mnoha situacích chová jinak než lokální disk, není to zdaleka transparentní.

Možná by to řešila nějaká writeback cache nad síťovým "diskem". Ale nevím o tom, že by něco takového existovalo, nehledě na velké nebezpečí vzniku nekonzistencí a "rozbití" profilu třeba při výpadku napájení. V Sambě jsou nějaké volby okolo "client side caching", ale mě to dělalo jen problémy, takže to mám všechno vypnuté.

Proto bych si vytipoval aplikace, které dělají s objemem dat v profilu problémy, a nastavil je tak, aby tyhle data ukládaly na síťový disk. Minimálně u toho Thunderbirdu to nebude problém, a pokud je uživatelů hodně, dá se na celé přenastavení a migraci udělat nástroj spuštěný z logon skriptu. Přesměrování celého APPDATA je podle mě trochu hazard. Zvlášť, když je za provozu třeba dělat dělat věci jako restart Samby nebo rozpojení sítě.

[Zdeněk Zámečník]

Bohužel máš asi pravdu. Zkoušel jsem s tím přes den různě experimentovat změnami jako je prodlužení timeoutu zápisu na disk, vypínáním opurtunistického zamykání, tebou zmíněné csc, ale je pravda, že nic z toho problém neřeší. Velice nadějně vypadalo csc, které se tiše chovalo jako kdyby vše bylo v pořádku, ale některé změny v souborech to na server stejně nesynchronizovalo (např. změnu domovské stránky ve FF nebo uložení hesla pro příjem pošty v TB) a hlavně jsem nenašel žádnou možnost, jak donutit stanici o co nejrychlejší reconnect a následnou synchronizaci. Možná by to šlo nějak doladit, ale mě se to nepodařilo.

Já mám právě největší problém s Thunderbirdem, resp. je to u nás jedna z nejpoužívanějších aplikací a mnoho uživatelů má v lokálních složkách jednotky až desítky GB pošty. Pokud Thunderbirdu, byť jen na moment, přeruším spojení se Sambou, systém velmi často brečí, že zápis se zpožděním do souboru Inbox.msf a podobných se nezdařil. Podotýkám, že Data aplikací mám lokální a nastavil jsem pouze umístění složky ImapMail/Local folders na síťový disk.

[VSi]

Já mám právě největší problém s Thunderbirdem, resp. je to u nás jedna z nejpoužívanějších aplikací a mnoho uživatelů má v lokálních složkách jednotky až desítky GB pošty. Pokud Thunderbirdu, byť jen na moment, přeruším spojení se Sambou, systém velmi často brečí, že zápis se zpožděním do souboru Inbox.msf a podobných se nezdařil. Podotýkám, že Data aplikací mám lokální a nastavil jsem pouze umístění složky ImapMail/Local folders na síťový disk.

S tím nepůjde nic moc dělat. Řešení je mít důsledně vše na lokálním (v LAN) IMAP serveru a v Thundebirdu vypnutou cache. Co mají v lokálních složkách, tak obejít, a přesunout na IMAP - dá se, v několika případech jsem to dělal. Před nedávnem navíc v Thunderbirdu z ničeho nic změnili výchozí chování tak, že je offline cache na IMAP zapnutá. Holt je třeba to ty lidi naučit s tím, že to musí mít připravené a nastavené co nejsnadněji, a nesmí toho moc zkazit. Mám takhle několik desítek uživatelů, někteří tam mají taky mnoho GB, z toho část zkopírovanou ze starého Outlook Express, všechno na IMAP serveru, a nejsou s tím problémy. Navrch ke všem zprávám můžou i přes webmail nebo z notebooku mimo síť.

Další možnost je umístit Thunderbird cache na jiné místo na lokálním disku, ale nevidím v tom moc význam, pokud nejde o notebook, co se odnáší mimo síť.