Ldap сървъра директория като удостоверяване на източника - интеграция с обява

Трудно е да си представим, модерна мрежа, в която няма да има работни станции и сървъри, базирани на Microsoft Windows. UNIX и Windows съжителство в хетерогенна мрежова среда определя своя характер, изразен включително несъвместимост метода за достъп до услугите, предоставяни от локалната мрежа. Най-типичният проблем в такива мрежи е наличието на най-малко две глобални бази данни за удостоверяване на потребителите за достъп до ресурси. В съвременните операционни системи от семейството на Windows е индустриален стандарт сървър е Active Directory, за UNIX-базирани системи, но за съжаление такъв единен подход не съществува, но в повечето конфигурации също се използват LDAP сървъри от различни доставчици. Очевидно е, че наличието на две (или повече) от независим съхранение на данни за удостоверяване се превърне в пречка, когато имате нужда от достъп до ресурсите на UNIX-базирани сървъри с машини, работещи под Windows, както и обратното.

Има най-малко две ефективни подходи към решаването на този проблем

1. Samba софтуер на UNIX акцентиран проблемите на взаимодействието и Windows-базирани системи (конвергенция от страна на UNIX-базирани системи). Този метод позволява на потребителите на Windows, за да бъдат потвърдени с дисплей UNIX съответно. Windows сметки за определен кръг потребители IDs UNIX;

2. услуги на Microsoft за Unix (ДЛ), дава възможност за добавяне на допълнителни атрибути потребителски Directory активни профили, които са типични за UNIX-базирани системи и по този начин се адаптира АД за базата данни за удостоверяване UNIX.

Вторият метод на реални конфигурации, използвайки сравнително рядко поради необходимостта от по-съществено изменение на АД, изискващи абсолютни административни привилегии, както и относителната ненадеждността: Microsoft Corporation може да се променя спецификациите на рекламата и ТОИ доста често, че в някои ситуации, може да създаде трудности не само в прехода към новата версия на операционната система на сървъра Windows, но дори и при неговото начално актуализация.

Тук ще опишем само първия метод в контекста на използването на LDAP-директория като хранилище на информация за потребителския акаунт е получил от Active Directory.

  1. Търсене в DNS зона контролер SRV-писане на домейн и Kerberos център за дистрибуция, за да получи информация за ролята и функционалната структура на мрежата на Windows;
  2. искания RPC-Domain Controller;
  3. Директно четене на АД чрез LDAP протокол.

За дадена REALM'a (аналогов домейн) Winbind извлича информация за съществуващите сметки и използването на IDMap прави показването им в модула за подкрепа UNIX. При това се използват стандартни механизми UNIX да се работи с системно ниво обект: НСС (Име Включване Space) и PAM (за включване Authentication Modules), описан в статия на "LDAP сървър директория като източник на удостоверяване - НСС конфигурация и PAM". За такъв дисплей е необходимо да се определи метод за установяване на съответствие между идентификатори на обекти (потребители, групи) АД и уникални идентификатори UNIX (uidNumber, gidNumber съответно). В случай на сухожилията Winbind + IDMap в зависимост от метода на избор съвпадение може да бъде значително (т.е. предсказуем, недвусмислено) и случаен (neprediktivnym). Ясни методи се опитват с помощта на хеш функция единица да получават директно от полето RID (Относителен ID) атрибут objectSID потребителски акаунт в AD стойност uidNumber / gidNumber респ. неговия еквивалент UNIX обект. Източникът на проблема тук е основната разлика между методите на структурно представяне на сметките за UNIX и Windows. Както е известно, на обектите в Windows мрежи са логически групирани в йерархична структура въз основа на принадлежността на домейна, в UNIX като стандарт е така наречения плосък съхранение схема Информация за обектите в плоски структури маси на по-високо ниво, обединени в някакво подобие на относителна база данни, в която основната ключове са стойностите UID и GID на обекти. Пряко следствие от горното, е, че по време на мач потребителски имена за UNIX - аномалия, и в Windows - йерархия, състояща се от множество взаимно доверие един на други домейни, тази ситуация е абсолютно нормално. По този начин, ако има в различни домейни, потребителите със същото име, в UNIX, те трябва да се показват като различни потребители, за които е добавено част на домейн с името на потребителя, като незадължителен компонент, разделени от така наречената сепаратор - "разделител".

Възможност за избор на домейн отчасти се дължи на факта, че първият домейн в мрежата може да бъде само един, а всъщност имаме една и съща планарна структура, че да UNIX, и второ - на нивото на договор може да се предположи, че потребителските имена са уникални в рамките на гората , И в действителност, и в двата случая може да нареди на дисплея на имената без част на домейна.

Аз ще се опитам да обясня разбираемо целите на намалените възможности:

idmap задния - определя типа на задния IDMap (Пример: LDAP) и параметрите минута за гръб (URI-път към сървъра директория, например LDAP: //127.0.0.1 или LDAPS: //ds.mydomain.com: 1636)
LDAP наставка - LDAP дърво наставка, която идентифицира на базата данни;
LDAP idmap наставка - отместване от суфикса до корена на дисплея на дърво ID objectSID / uidNumber - Строго погледнато, на името на опцията подвеждащо, защото въпреки семантично сходство с наставка LDAP, всъщност, този параметър определя относителната база за търсене на съответствията (съпоставяне), но Тя не разполага с никаква връзка с идеята за наставка (корен) директория дърво;
LDAP администратор DN - DN потребител, от чието име ще получите достъп до Великобритания. Този потребител трябва да имат право да създава нови записи в целта за клон, пътят към която се дава съвместно от параметрите «LDAP наставка» и «LDAP idmap наставка»;
winbind ENUM групи. winbind потребители ENUM - winbind показват необходимостта да се рекурсивно всички достъпни части на гората на домейн, за да формират пълен списък на обектите, които попадат в "зона на интерес» winbind (потребители, групи, мрежи от работни станции). Необходимостта от такова прехвърляне се случва рядко - например, при използване на програма getent
winbind UID. winbind GID - граници на числови идентификатори и потребителски групи, за които, чрез превръщането на таблицата показва кореспонденция съответно, групите и потребителите от Active Directory.

По този начин, за IDMap запазени басейн числови идентификатори, в който реда на показване последователност и контрол на достъпа обекти зависи от настройките IDMap;

шаблон черупка. шаблон homedir - потребител черупка от АД по подразбиране. След като инсталирате Microsoft Services За Unix е възможно да добавите UNIX-конкретни характеристики на групи и потребители на Windows домейн, така че тази опция не се отнася за всички потребители в домейна, но само за тези, които респ. атрибути да бъдат определени. Ясно е, че ако ТОИ във всеки контролер АД домейн не се използва или на стойностите на атрибутите, специфични за UNIX никъде инсталирани ценности шаблон черупка и шаблон homedir стане световен;

smbpasswd -w «парола»

Имайте предвид, че въпреки че името на потребителя и не се дава на екипа на smbpasswd, парола TDB-файл все още ще бъде въведен заедно с уникалното име администратор LDAP IDMap-клонове, така че ако се промени LDAP администратор DN, трябва да стартирате тази команда дори ако паролата новата DN същото е и с старата парола. Също така, има две важни точки, които да имате предвид, когато конфигурирате Windows дисплей -> UNIX в пространството на определен клон на Великобритания:

1. При липса на възможност за точно уточни потребителите рамкови, дълбочина и филтър, търсещи в АД (по мое мнение, това е значителен пропуск winbind), броя на записите, които са създадени, показани в LDAP-директория, може да бъде много значимо. В резултат на това на доста сложни топологии на домейни се насърчават да установят IDMap база на собствените си независим наставка, в противен случай ще получите рязък спад в представянето на рекурсивни заявки SK с обхват = суб

2. При възлагане на разрешенията за профила LDAP администратор DN, трябва да бъде позволено да се промени obekta- "корен" клон на дисплея, тъй като тя се променя Winbind'om: добавете objectClass = sambaUnixIdPool, uidNumber и gidNumber атрибути. В посочените по-горе характеристики IDMap съхранява номера и uidNumber gidNumber, които се използват за изграждане на нов потребител / група - приема стойността на тези атрибути, възлага на новосъздадения обект, а след това нова увеличава стойност е написано върху старата четене. Ако IDMap маса отделени от основната клон на директорията и се съхраняват в отделна база данни, която е за предпочитане от гледна точка на производителност (виж по-горе), най-лесният начин е да се използва администратор на база данни сметка. Спомнете си, че за OpenLDAP този параметър се задава като стойност, съответстваща rootdn slapd.conf конфигурационен файл секции, както и за по-голямата част от Обединеното кралство, които са на базата на Netscape код, по подразбиране е «CN = Directory Мениджър».

Не забравяйте, че след въвеждането на необходимите промени във файла smb.conf, трябва да ги прилага, рестартирайте сървъра и SMB winbind на.

След завършване на конфигурацията Samba, стартирайте testparm команда за проверка на синтаксиса на коректността на smb.conf. Уверете се, че всичко е в ред, нека се опитаме да влезе в сървъра, за да домейна:

Тук SMBLINUX - името на машината и My.Domain.Ru - царството на това, в този случай съвпада с името на DNS-домейн.
Ако присъединяването към домейна всичко върви добре (което наистина искате, не от слухове знае как може да е трудно). Ние сега дават познатите ключ услуга Пространствата от имена (НСС) на необходимостта от използване на WinBind за потребителски акаунти и групи от Active Directory. За да направите това, редактирате файла /etc/nsswitch.conf да добавите winbind модул в последователността на исканите от НЗК при търсене на обекти в базите за цялата система (от имена) ако съществува, група и сянка услуги. Например, ако заявки НСС вече обработени с помощта на файлове на базата данни и LDAP, winbind е конфигуриран с получената линия в nsswitch.conf трябва да се появи, както следва:

WORKGROUP - името на работната група АД от същия параметър на smb.conf;
WB_DELIMITER - сепаратор между домейна и част от името;
USERNAME - име на потребител обект в АД.

      Статии, свързани с тази тема: