Тысяча мелочей

ИНТЕГРАЦИЯ ДОМЕНОВ NT

При установке нового сервера и домена NT в вашем отделе может возникнуть проблема с его интеграцией с другими доменами NT.

Рассмотрим следующую ситуацию: вы создали домен отделения с шестью серверами Windows NT и 150 пользователями. Последние несколько недель пользователи обращались к вам с просьбой о доступе к ресурсам в корпоративном домене. Кроме того, пользователи из других отделов просили предоставить им доступ к ресурсам в домене вашего отделения.

К сожалению, ваши пользователи будут теперь иметь два бюджета и два пароля в NT. Кроме того, придется добавить бюджеты в ваш домен, хотя они уже были определены в корпоративном домене.

Чтобы как-то упорядочить вашу среду, вы решаете установить односторонние доверительные отношения с корпоративным доменом: домен вашего отделения будет "доверяющим", в то время как корпоративный - "доверяемым". Вы определяете бюджеты пользователей вашего отделения, производите необходимые настройки в группах и правах доступа и затем посылаете пользователям вашего отделения сообщение с информацией о том, что они должны теперь входить из корпоративного домена.

Сделав это, вы облегчите жизнь не только пользователям, которым теперь необходим лишь один пароль, но и себе. Теперь каждый пользователь имеет один бюджет, что облегчает защиту. Но вскоре, к вашему вящему недоумению, телефон начинает разрываться от звонков, и вы слышите снова и снова панические заявления, что регистрация в корпоративном домене привела к "удалению" программного обеспечения. На самом деле эти пользователи просто не видят привычных групп и пиктограмм.

Причина, по которой это происходит, заключается в том, что Windows NT хранит такую информацию, как группы, соединения с дисками и принтерами, обои и цвета в профайле пользователя. Профайл определяется комбинацией следующих параметров: UserName и Domain или Computer Name. Например, типичный ПК с именем компьютера Workstation01 может иметь следующие профайлы:

Profile
Administrator/Workstation01
Administrator/DepartmentalDomain
JoeUser/DepartmentalDomain
JoeUser/Workstation01
JoeUser/EnterpriseDomain
JoeHelper/DepartmentalDomain

Информация по каждому профайлу хранится в файле подкаталога %systemroot%system32config. Каждый раз, когда новый пользователь регистрируется на рабочей станции или текущий пользователь регистрируется из нового домена, создается файл с именем, составленным из первых пяти букв имени пользователя и следующими за ним тремя цифрами, увеличивающимися на единицу каждый раз при создании нового профайла. Новые профайлы создаются на основе принятого по умолчанию профайла, хранящегося в файле UserDef того же подкаталога config, что и профайлы пользователей.

Вышеупомянутые профайлы привели бы к созданию следующих файлов в подкаталоге config:

Разрешить проблему "отсутствия программного обеспечения" и удалить все ненужные профайлы с рабочих станций пользователей можно, выполнив несколько этапов следующей процедуры.

1. Зарегистрироваться на станции как Administrator.
2. Дважды щелкнуть на пиктограмме Windows NT Setup в окне Main.
3. В окне Windows NT Setup выбрать Delete User Profiles из меню Options.
4. Удалить все ненужные профайлы. На однопользовательской системе я бы советовал удалить все профайлы, за исключением профайла администратора и профайла, который пользователь хотел бы сохранить.
5. В подкаталоге %systemroot%system32config переименовать userdef в userdef.old.
6. Скопировать профайл пользователя в UserDef. (Например, скопировать joeus000 в userdef.).
7. Выйти и войти как пользователь из корпоративного домена. Это приведет к созданию нового профайла на основе userdef, который вы заменили на выбранный пользователем профайл.

Однако вопросы безопасности и чистки этим не исчерпываются. Что касается безопасности, пользователи корпоративного домена получают теперь доступ ко всему, к чему имеют право доступа все члены группы Everyone, а следовательно, права этой группы, возможно, потребуется изменить. Что касается чистки, вы, может быть, сочтете необходимым переименовать userdef.old обратно в userdef, чтобы новые профили были "чистыми" - другими словами, профайл пользователя по умолчанию не будет содержать каких-либо специальных настроек, особых соединений с дисками, дополнительных пиктограмм программ и т. д. Удачи!

НЕВОЗМОЖНО ПОДДЕЛАТЬ MESSAGE-ID?

В номере за февраль 1997 г. в разделе "Тысяча мелочей" опубликована статья "Рецепт против почтовых хулиганов". Могу предложить еще один.

Отправляете на ftpmail-сервер (практически любой) письмо примерно следующего содержания. (Конкретные команды необходимо уточнить в зависиомсти от конкретного сервера. В скобках - комментарии, их посылать не надо.)

Для команды get необходимо выбирать файлы побольше, ведь вас интересует объем, а не содержание... Команда reply-to (или аналогичная, доступная на данном ftpmail-сервере) должна содержать адрес, куда отправить все эти мегабайты. Но вы должны быть абсолютно уверены, что это реальный адрес реального обидчика. Кроме того, адрес вообще должен существовать, иначе вас ждут неприятности: вы рискуете получить письмо Unable to deliver to адрес-обидчика.домен и все, что вы там назаказывали послать. Если обидчик живет в России, то ему придется еще и заплатить за многомегабайтный трафик.

Честно говоря, я подобным образом ни разу не шутил и не собираюсь, поэтому описанный способ - чисто умозрителен.

Но вот насчет невозможности подделки Message-Id, так это автор зря так безапелляционно. Абсолютно не согласен. Посмотрите внимательно на заголовок письма, которое перед вами. И ведь все сделано обычным текстовым редактором! (Прим. редактора. Далее приведен заголовок письма, в котором данная заметка была прислана в адрес редакции LAN. Действительно, отправленная почта до ее отсылки в Internet обычно некоторое время лежит на локальном почтовом сервере. Если в это время исправить заголовок сообщения в любом текстовом редакторе, то можно подделать почти все поля заголовка, включая информацию о дате отправки, типе почтовой программы и, в том числе, Message-Id.)

From kiae!nbinar!government!Government.com.ru!Anatol 
          Mon Mar 24 23:47:42 1997
Received: by osp.msk.su (dMail for Windows v1.21P, 25Nov96);
          Mon, 24 Mar 1997 23:47:42 -0800
Received: by sequent.KIAE.su (UUMAIL/2.0); Mon, 24 Mar 97 23:48:09 +0300
Received: by Government.com.ru (M$-VirusMail for Dos 6.22, 06Sep94)
          id ZZ99999; Mon, 30 Mar 1997 25:62:76 +0200 (MSK)
To: lan@osp.ru
Message-Id: 
Date: Mon, 32 Feb 19997 25:62:75 +0200 (MSK)
X-Mailer: VirusMail Pro [v6.22 M$DOS]
From: Anatol@Government.com.ru (Anatoly Choobais)
Organization: Russian Government Ltd.
Subject: Невозможно подделать Message-Id ?  Ну что ж ...

ТАКОЙ НОВЫЙ МУЛЬТИМЕДИЙНЫЙ МИР

Многие ПК-совместимые компьютеры по-прежнему работают под Windows 3.1 и имеют 4-8 Мбайт RAM. Их пользователи сталкиваются с такими, например, проблемами, как поддержание сетевого соединения при выполнении интерактивных курсов.

С помощью одного трюка вы можете "обмануть" Windows, так что она будет считать, что оперативной памяти больше, чем есть на самом деле. Для этого вы должны добавить следующую строку в раздел [386 Enh] файла system.ini:

PageOverCommit=12

Значение по умолчанию равно 4, а максимальное возможное значение - 20. Этот редко используемый параметр применяется в Windows Resource Kit. Он весьма помог мне при работе с графическими приложениями, а также при выполнении нескольких приложений одновременно.

Комментарий редактора. Мы отыскали информацию о параметре PageOverCommit на Microsoft Developers Network CD-ROM. Очевидно, что увеличение значения этого параметра позволяет расширить объем линейного адресного пространства, используемого Windows.

Однако статья в MSDN предупреждает также, что чем выше значение параметра PageOverCommit, тем больше действий со страницами памяти, возможным побочным эффектом которых является снижение общей производительности системы. Мы позвонили мистеру Тимони и задали ему вопрос о производительности, но он уверил нас, что это снижение практически незаметно.

ВОССТАНОВЛЕНИЕ ДОВЕРИТЕЛЬНЫХ ОТНОШЕНИЙ

Недавно мы воспользовались командой ncopy для переноса всех файлов со старого сервера, FS1, на новый - FS2 - при обновлении оборудования. Мы выбрали этот метод потому, что диски с программным обеспечением резервного копирования были испорчены. После завершения обновления имя нового сервера FS2 было изменено на имя исходного сервера FS1. При тестировании нового сервера с моим ID с полномочиями супервизора я не встретил никаких проблем.

На следующее утро мы получили множество телефонных звонков с жалобами от пользователей, что они не могут запустить свои приложения после входа в сеть. Как оказалось, пользователи утеряли присвоенные полномочия доступа. После обращения к Network Support Encyclopedia мы решили использовать backup для NetWare 3.11 для переноса исходных таблиц связей и присвоенных полномочий доступа на новый сервер, и в этот раз все получилось.

Урок, который мы вынесли из этой ситуации, состоит в том, что присвоенные полномочия доступа не передаются при использовании ncopy для переноса файлов со старого сервера на новый. Еще один вывод - лучше использовать обычный ID вместо супервизорского или эквивалентного ID для тестирования нового сервера, так как такой тест полнее отражает ситуацию с точки зрения обычного пользователя.