- Linux и Windows: помощь админам и пользователям
- Администрируем и настраиваем Windows, Linux.
- Присоединение Windows 7 к домену
- Предварительные требования
- Метод #1 — Традиционный способ
- Метод #2 — Используем NETDOM
- Windows 10 Home в организации
- Ответы (4)
- [Конспект админа] Домены, адреса и Windows: смешивать, но не взбалтывать
- Дедушка NetBIOS
- Стандарт наших дней – DNS
- Порядок разрешения имен
- Active Directory и суффиксы
Linux и Windows: помощь админам и пользователям
Администрируем и настраиваем Windows, Linux.
Присоединение Windows 7 к домену
Ввод компьютера в домен позволяет использовать все преимущества домена, такие как централизированное управление, групповые политики и многое, многое другое.
Предварительные требования
Перед вводом компьютера под управлением Windows 7 в домен убедитесь что следующие предварительные требования соблюдены:
Используется Windows 7 Professional, Ultimate или Enterprise — только эти редакции Windows 7 могут быть подключены к домену.
У вас есть сетевая карта — собсвенно без комментариев, думаю вы не забыли об этом
Вы подключены к локальной сети— Убедитесь что вы подключены к локальной сети. Хотя Windows 7 может быть присоединена к домену Windows Server 2008 R2 в оффлайн режca, это тема для отдельной статьи.
Вы имеете правильный IP адрес — Ещё раз убедитесь что вы подключены к сети и получили правильный IP адрес. Адрес может быть настроен вручную, получен от DHCP сервера или может быть получен APIPA address (который начинается с 169.254.X.Y). Если вами получен APIPA адрес, вы гарантированно получите потенциальные проблемы, так как APIPA и AD не работают совместно.
Вам доступны котроллеры домена — или как минимум один из них. Вы должны проверить связь с контроллером домена, например пропинговав его, хотя успешный пинг не гарантирует что контроллер домена полностью доступен.
Вы должны иметь правильно настроенный DNS сервер — Без правильно настроенного DNS сервера вы гарантированно получите проблемы при вводе в домен, во время работы и прочее.
Вам доступны DNS сервера — Проверьте ваше подключение к DNS серверам с помощью программы PING и выполните запрос NSLOOKUP.
Проверьте свои права на локальной системе — Для успешного ввода в домен у вас должны быть права локального администратора компьютера.
Знайте ваше доменное имя, имя администратора и пароль
Существует два способа ввода компьютера в домен. В данной статье мы рассмотрим оба способа
Метод #1 — Традиционный способ
1. Откройте свойства системы, нажав кнопку Start, затем правой кнопкой мыши на ярлыке «Computer», и нажмите «Properties».
2. В разделе «Computer name, domain, and workgroup settings» нажмите «Change settings».
3. Перейдите в вкладку Computer Name и нажмите «Change».
4. В разделе Member of кликните Domain.
5. Введите имя домена, к которому вы хотите подключиться и нажмите OK.
Вам будет предложено ввести имя пользователя домена и пароль.
После успешного ввода компьютера в домен вам будет предложено перегрузиться. Для завершения ввода сделайте это.
Метод #2 — Используем NETDOM
С помощью NETDOM мы можем выполнить ввод компьютера в домен из командной строки с помощью всего одной команды.
NETDOM в Windows 7 включен в операционную систему, в отличие от Windows 2000/XP/2003 где необходимо было устанавливать Support Tools.
Откройте командную строку от имени администратора :
и введите следующую команду:
Замечание: Замените DOMAIN.COM и DOMAIN на ваше имя домена и естественно укажите ваше доменные логин и пароль. Обратите внимание также на дополнительную «d» в «user» и «password», это НЕ опечатка.
Для заверешения процедуры перегрузите компьютер.
Windows 10 Home в организации
Навязший в зубах вопрос о легальности использования Win 10 Home в организации:
Есть компьютеры, собираемся приобрести Windows. Предлагают такой, как самый дешевый вариант:
Программное обеспечение: Windows 10 Home 32-bit/64-bit Russian Russian Only USB RS(KW9-00500)
При звонке в Майкрософт, сотрудники отдела продаж рьяно уверяют, что использовать этот продукт (и не только этот, а вообще Win 10 Home) в организации нельзя. Ссылаются на пункт 12 лицензионного соглашения.
Даже при ситуации, когда приобретается компьютер или ноутбук с предустановленной Windows 10 Home, нужно её удалить и установить Windows 10 Pro.
В поисках истины, нашел ссылку на такое письмо от Майкрософта:
В нем вроде написано, что «Продукты семейства Windows 10 за исключением Windows 10 Pro не предназначены для использования на коммерческих устройствах». Но это письмо о каких-то «специализированных устройствах».
Опять же, фраза «не предназначены» не говорит о том, что их нельзя использовать.
Может сама Майкрософт даст один конкретный ответ. Можно на главной странице сайта, огромными буквами. Достала уже эта юридическая казуистика: «можно, если прямо не запрещено», «а в Соглашении прямого запрета нет» и т.д.
Или может как-то получить разъяснение у проверяющих органов (например, ГСБЭП )? Опять же, как у них спросить?
Где получить конкретный ответ, БУМАГУ, которую в случае проверки можно предъявить проверяющим органам?
Ответы (4)
Добрый день.
Home, это только название продукта. Оно носит рекомендательный характер. Да, у домашней редакции ограниченный функционал для использования на предприятии. Но если вам не требуется доменная структура, и вполне устраивает одноранговая сеть предприятия, то пожалуйста, используйте.
У сотрудника отдела продаж задача продать. Надо связываться с юристами компании. Сотрудники проверяющих органов вполне грамотные и вменяемые люди. Они никогда не предъявят претензии при использовании домашней на предприятии. Главное чтобы не было контрафактных(пиратских) экземпляров на вашем предприятии.
35 польз. нашли этот ответ полезным
Был ли этот ответ полезным?
К сожалению, это не помогло.
Отлично! Благодарим за отзыв.
Насколько Вы удовлетворены этим ответом?
Благодарим за отзыв, он поможет улучшить наш сайт.
Насколько Вы удовлетворены этим ответом?
Благодарим за отзыв.
9 польз. нашли этот ответ полезным
Был ли этот ответ полезным?
К сожалению, это не помогло.
Отлично! Благодарим за отзыв.
Насколько Вы удовлетворены этим ответом?
Благодарим за отзыв, он поможет улучшить наш сайт.
Насколько Вы удовлетворены этим ответом?
Благодарим за отзыв.
Здравствуйте.
Цитата: «Ссылаются на пункт 12 лицензионного соглашения.»
12 пункт EULA под названием «Права потребителей, региональные отличия.» вообще ни коим боком не относиться к якобы ограничениям.:) Наверное «манагеры» пытались ссылаться на п. 13.d.: «Если приобретенная вами версия программного обеспечения отмечена или иным образом предназначена для конкретного или ограниченного использования, то вы можете использовать его только в соответствии с его предназначением. Вы не можете использовать такие версии программного обеспечения для коммерческой, некоммерческой или приносящей доход деятельности.»? Вот только дальнейшее описание в подпунктах (I, ii, iii, iv) расшифровывает, на какие именно версии ОС наложены эти ограничения (в плане коммерческой деятельности). И простыми словами это переводиться:
i. Для образовательных учреждений. Есть такая редакция ОС — Еducation (хотя может использоваться в таких учреждениях также Home и Pro)
ii. В целях оценки. Microsoft предоставляет для IT специалистов и представителей предприятий редакцию Корпоративная с ознакомительным периодом. Как видите — редакция Домашняя тут вообще не фигурирует.
iii. Метка NFR (не для перепродажи) — здесь, надеюсь и так понятно.:)
iv. Предварительная версия (инсайдерская) — обладает всеми «преимуществами» сырой версии. Ну и в магазинах, соответственно, не продаётся, а доступна (на добровольной основе) участникам программы предварительной оценки Windows. В названии редакции есть слово «Preview». К Windows 10 Home 32-bit/64-bit Russian Russian Only USB RS(KW9-00500) не имеет никакого отношения (если, конечно, на вашем предприятии не надумают вступить в инсайдеры).
Как то вот так.
EULA Windows 10: https://www.microsoft.com/en-us/Useterms/Retail.
P.S. Согласен с уточнением коллеги по поводу мотивов сотрудников отдела продаж. 🙂
21 польз. нашли этот ответ полезным
Был ли этот ответ полезным?
К сожалению, это не помогло.
Отлично! Благодарим за отзыв.
Насколько Вы удовлетворены этим ответом?
Благодарим за отзыв, он поможет улучшить наш сайт.
[Конспект админа] Домены, адреса и Windows: смешивать, но не взбалтывать
В очередном «конспекте админа» остановимся на еще одной фундаментальной вещи – механизме разрешения имен в IP-сетях. Кстати, знаете почему в доменной сети nslookup на все запросы может отвечать одним адресом? И это при том, что сайты исправно открываются. Если задумались – добро пожаловать под кат. .
Для преобразования имени в IP-адрес в операционных системах Windows традиционно используются две технологии – NetBIOS и более известная DNS.
Дедушка NetBIOS
NetBIOS (Network Basic Input/Output System) – технология, пришедшая к нам в 1983 году. Она обеспечивает такие возможности как:
регистрация и проверка сетевых имен;
установление и разрыв соединений;
связь с гарантированной доставкой информации;
связь с негарантированной доставкой информации;
В рамках этого материала нас интересует только первый пункт. При использовании NetBIOS имя ограниченно 16 байтами – 15 символов и спец-символ, обозначающий тип узла. Процедура преобразования имени в адрес реализована широковещательными запросами.
Широковещательным называют такой запрос, который предназначен для получения всеми компьютерами сети. Для этого запрос посылается на специальный IP или MAC-адрес для работы на третьем или втором уровне модели OSI.
Для работы на втором уровне используется MAC-адрес FF:FF:FF:FF:FF:FF, для третьего уровня в IP-сетях адрес, являющимся последним адресом в подсети. Например, в подсети 192.168.0.0/24 этим адресом будет 192.168.0.255
Интересная особенность в том, что можно привязывать имя не к хосту, а к сервису. Например, к имени пользователя для отправки сообщений через net send.
Естественно, постоянно рассылать широковещательные запросы не эффективно, поэтому существует кэш NetBIOS – временная таблица соответствий имен и IP-адреса. Таблица находится в оперативной памяти, по умолчанию количество записей ограничено шестнадцатью, а срок жизни каждой – десять минут. Посмотреть его содержимое можно с помощью команды nbtstat -c, а очистить – nbtstat -R.
Пример работы кэша для разрешения имени узла «хр».
Что происходило при этом с точки зрения сниффера.
В крупных сетях из-за ограничения на количество записей и срока их жизни кэш уже не спасает. Да и большое количество широковещательных запросов запросто может замедлить быстродействие сети. Для того чтобы этого избежать, используется сервер WINS (Windows Internet Name Service). Адрес сервера администратор может прописать сам либо его назначит DHCP сервер. Компьютеры при включении регистрируют NetBIOS имена на сервере, к нему же обращаются и для разрешения имен.
В сетях с *nix серверами можно использовать пакет программ Samba в качестве замены WINS. Для этого достаточно добавить в конфигурационный файл строку «wins support = yes». Подробнее – в документации.
В отсутствие службы WINS можно использовать файл lmhosts, в который система будет «заглядывать» при невозможности разрешить имя другими способами. В современных системах по умолчанию он отсутствует. Есть только файл-пример-документация по адресу %systemroot%\System32\drivers\etc\lmhost.sam. Если lmhosts понадобится, его можно создать рядом с lmhosts.sam.
Сейчас технология NetBIOS не на слуху, но по умолчанию она включена. Стоит иметь это ввиду при диагностике проблем.
Стандарт наших дней – DNS
DNS (Domain Name System) – распределенная иерархическая система для получения информации о доменах. Пожалуй, самая известная из перечисленных. Механизм работы предельно простой, рассмотрим его на примере определения IP адреса хоста www.google.com:
если в кэше резолвера адреса нет, система запрашивает указанный в сетевых настройках интерфейса сервер DNS;
сервер DNS смотрит запись у себя, и если у него нет информации даже о домене google.com – отправляет запрос на вышестоящие сервера DNS, например, провайдерские. Если вышестоящих серверов нет, запрос отправляется сразу на один из 13 (не считая реплик) корневых серверов, на которых есть информация о тех, кто держит верхнюю зону. В нашем случае – com.
после этого наш сервер спрашивает об имени www.google.com сервер, который держит зону com;
Наглядная схема прохождения запроса DNS.
Разумеется, DNS не ограничивается просто соответствием «имя – адрес»: здесь поддерживаются разные виды записей, описанные стандартами RFC. Оставлю их список соответствующим статьям.
Сам сервис DNS работает на UDP порту 53, в редких случаях используя TCP.
DNS переключается на TCP с тем же 53 портом для переноса DNS-зоны и для запросов размером более 512 байт. Последнее встречается довольно редко, но на собеседованиях потенциальные работодатели любят задавать вопрос про порт DNS с хитрым прищуром.
Также как и у NetBIOS, у DNS существует кэш, чтобы не обращаться к серверу при каждом запросе, и файл, где можно вручную сопоставить адрес и имя – известный многим %Systemroot%\System32\drivers\etc\hosts.
В отличие от кэша NetBIOS в кэш DNS сразу считывается содержимое файла hosts. Помимо этого, интересное отличие заключается в том, что в кэше DNS хранятся не только соответствия доменов и адресов, но и неудачные попытки разрешения имен. Посмотреть содержимое кэша можно в командной строке с помощью команды ipconfig /displaydns, а очистить – ipconfig /flushdns. За работу кэша отвечает служба dnscache.
На скриншоте видно, что сразу после чистки кэша в него добавляется содержимое файла hosts, и иллюстрировано наличие в кэше неудачных попыток распознавания имени.
При попытке разрешения имени обычно используются сервера DNS, настроенные на сетевом адаптере. Но в ряде случаев, например, при подключении к корпоративному VPN, нужно отправлять запросы разрешения определенных имен на другие DNS. Для этого в системах Windows, начиная с 7\2008 R2, появилась таблица политик разрешения имен (Name Resolution Policy Table, NRPT). Настраивается она через реестр, в разделе HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DnsClient\DnsPolicyConfig или групповыми политиками.
Настройка политики разрешения имен через GPO.
При наличии в одной сети нескольких технологий, где еще и каждая – со своим кэшем, важен порядок их использования.
Порядок разрешения имен
Операционная система Windows пытается разрешить имена в следующем порядке:
проверяет, не совпадает ли имя с локальным именем хоста;
смотрит в кэш DNS распознавателя;
если в кэше соответствие не найдено, идет запрос к серверу DNS;
если имя хоста «плоское», например, «servername», система обращается к кэшу NetBIOS. Имена более 16 символов или составные, например «servername.domainname.ru» – NetBIOS не используется;
если не получилось разрешить имя на этом этапе – происходит запрос на сервер WINS;
если постигла неудача, то система пытается получить имя широковещательным запросом, но не более трех попыток;
Для удобства проиллюстрирую алгоритм блок-схемой:
Алгоритм разрешения имен в Windows.
То есть, при запуске команды ping server.domain.com NetBIOS и его широковещательные запросы использоваться не будут, отработает только DNS, а вот с коротким именем процедура пойдет по длинному пути. В этом легко убедиться, запустив простейший скрипт:
Выполнение второго пинга происходит на несколько секунд дольше, а сниффер покажет широковещательные запросы.
Сниффер показывает запросы DNS для длинного имени и широковещательные запросы NetBIOS для короткого.
Отдельного упоминания заслуживают доменные сети – в них запрос с коротким именем отработает чуть по-другому.
Active Directory и суффиксы
Active Directory тесно интегрирована с DNS и не функционирует без него. Каждому компьютеру домена создается запись в DNS, и компьютер получает полное имя (FQDN — fully qualified domain name) вида name.subdomain.domain.com.
Для того чтоб при работе не нужно было вводить FQDN, система автоматически добавляет часть имени домена к хосту при различных операциях – будь то регистрация в DNS или получение IP адреса по имени. Сначала добавляется имя домена целиком, потом следующая часть до точки.
При попытке запуска команды ping servername система проделает следующее:
если в кэше DNS имя не существует, система спросит у DNS сервера о хосте servername.subdomain.domain.com;
При этом к составным именам типа www.google.com суффиксы по умолчанию не добавляются. Это поведение настраивается групповыми политиками.
Настройка добавления суффиксов DNS через групповые политики.
Настраивать DNS суффиксы можно также групповыми политиками или на вкладке DNS дополнительных свойств TCP\IP сетевого адаптера. Просмотреть текущие настройки удобно командой ipconfig /all.
Суффиксы DNS и их порядок в выводе ipconfig /all.
Однако утилита nslookup работает немного по-другому: она добавляет суффиксы в том числе и к длинным именам. Посмотреть, что именно происходит внутри nslookup можно, включив диагностический режим директивой debug или расширенный диагностический режим директивой dc2. Для примера приведу вывод команды для разрешения имени ya.ru:
Из-за суффиксов утилита nslookup выдала совсем не тот результат, который выдаст например пинг:
Это поведение иногда приводит в замешательство начинающих системных администраторов.
Лично сталкивался с такой проблемой: в домене nslookup выдавал всегда один и тот же адрес в ответ на любой запрос. Как оказалось, при создании домена кто-то выбрал имя domain.com.ru, не принадлежащее организации в «большом интернете». Nslookup добавляла ко всем запросам имя домена, затем родительский суффикс – com.ru. Домен com.ru в интернете имеет wildcard запись, то есть любой запрос вида XXX.com.ru будет успешно разрешен. Поэтому nslookup и выдавал на все вопросы один ответ. Чтобы избежать подобных проблем, не рекомендуется использовать для именования не принадлежащие вам домены.
При диагностике стоит помнить, что утилита nslookup работает напрямую с сервером DNS, в отличие от обычного распознавателя имен. Если вывести компьютер из домена и расположить его в другой подсети, nslookup будет показывать, что всё в порядке, но без настройки суффиксов DNS система не сможет обращаться к серверам по коротким именам.
Отсюда частые вопросы – почему ping не работает, а nslookup работает.
В плане поиска и устранения ошибок разрешения имен могу порекомендовать не бояться использовать инструмент для анализа трафика – сниффер. С ним весь трафик как на ладони, и если добавляются лишние суффиксы, то это отразится в запросах DNS. Если запросов DNS и NetBIOS нет, некорректный ответ берется из кэша.
Если же нет возможности запустить сниффер, рекомендую сравнить вывод ping и nslookup, очистить кэши, проверить работу с другим сервером DNS.
Кстати, если вспомните любопытные DNS-курьезы из собственной практики – поделитесь в комментариях.