<span class="q">&gt; &nbsp; Какая, например, информация из DHCP может использоваться, будучи<br>
&gt; &nbsp; помещённой в LDAP?<br><br>Как недавно прозвучало, нужно наверное озвучивать проблему, писать ТЗ, а уже потом подбирать инструментарий...<br><br></span>В общем, мысль какая:<br>В том же ActiveDirectory компьютер - это объект довольно навороченный. Можно и расположение его указать и отдел, к которому он прикреплен и т.п. Что само по себе удобно - конфиг и коммент в одном флаконе. Это раз.<br>
<br>Два состоит в том, чтобы минимизировать и автоматизировать настройки клиентов, без потери гибкости управления. Для того, чтобы опознавать машины, нужна привязка к железу. Сетевые карточки меняются редко. И, как правило, админ в курсе (или имеет полное право быть в курсе) каких-то изменений [sample message: &quot;в сети появился объект с неопознанным mac-адресом. Тревога/Игнор/Заполнить_информацию_о_компьютере&quot;]. Так что естественным идентификатором системного блока, который необходимо хранить в центральной базе будет mac. Там же должны быть статические или динамические ip+hostname. Если всё это известно и информация всегда актуальна, то можно и в мониторинге использовать человеческие адреса, а-ля &quot;третий слева на втором этаже в бухгалтерии&quot; и те же настройки firewall привязывать к mac-адресам и мало ли чего еще напридумывать можно по этому поводу (например, агрегировать статистику по трафику по отделам, фильтруя учетные записи по комментам к учеткам компов или веткам, в которых эти учетки лежат).<br>
<br>Три состоит в том, что без самбы сеть малого и среднего офиса - скорее исключение, чем правило. А в самбе есть SambaMachineAccount, который в свою очередь требует создание PosixAccount. Это не добавляет особых удобств - скорее создает новые ограничения. Имя машины в SambaMachineAccount не должно отличаться от dhcp-hostname, к примеру. Так что лучше будет, если объект &quot;компьютер&quot; будет иметь и objectclass=PosixAccount, и objectclass=SambaAccount. И группу под такие объекты желательно заводить сразу. И редактировать из одного места, чтобы накладок не было.<br>
<br>И, наконец, четыре: желательно фиксировать/задавать доп. параметры объекта &quot;пользователь&quot;. IP, mac, proxy, правила доступа в какой-то форме или ссылка на объект с правилами. Типа того, как здесь: <a href="http://www.samba.org.ua/articles/?section=1&amp;articleid=71">http://www.samba.org.ua/articles/?section=1&amp;articleid=71</a><br>
<br>А чтобы меньше было геморроя, нужен еще и механизм наследования разрешений от групп, в которые входит этот пользователь и машин, с которых он выходит (Васе Пупкину, как члену группы админов домена, дозволено всё, но только не с компа главного бухгалтера). Хочу акцентировать внимание читающих, что сложность с точки зрения внутренней кухни, компенсируется дальнейшей интуитивностью в обслуживании (по мотивам etcnet). <br>
<br>Опять же, по мотивам, etcnet, почему бы не расписать рекомендации, по организации хранилища этих записей. <br>Например, есть ветка cn=AdminsGroup,dc=domain,dc=loc. Почему бы не договориться, что все соотв. учетные записи юзеров-админов, должны храниться в этой ветке, а если учетная запись нужна еще в какой-то ветке (cn=Users,ou=Samara,o=CompanyLtd,c=ru), то там нужно ставить ссылку на этот &quot;лист&quot;. &quot;Примат соглашений над конфигурациями&quot; сделает внедрение, сопровождение и поддержку этого хозяйства более унифицированным.<br>
<br>Ввиду идеологии использования LDAP, первоначальное проектирование имеет решающее значение, ибо обновление схемы - процедура нежелательная. Поэтому закладывание в проект не самых востребованных атрибутов &quot;на вырост&quot; и &quot;про запас&quot;, мне кажется оправданным.<br>
<br>А зоны ДИНАМИЧЕСКОГО DNS в LDAP помещать удобнее, потому что потом удобнее залезть и поправить что-то ручками, а не применять nsupdate, который для эпизодического встревания в процесс подходит... неидеально. Абсолютно все статические записи резервировать и помещать в dns через dhcp мне кажется спорным, хотя... Если будет так, то зоны dns в ldap действительно не нужны.<br>
<br><br>