Django-auth-ldap и запросы к Active Directory | Forum

26 Sept. 2013, 12:58
d.kharlamov

Posts: 16
Location: Москва

26 Sept. 2013, 12:58
d.kharlamov

Posts: 16
Location: Москва

Приветствую! Делаю на Django приложение по управлению учетными записями в своей конторе. Цель - управление учетками из одного места. Источники учетных записей - AD(Win2008), CommuniGate... и др. Аутентификацию в приложении сделал через django-auth-ldap+AD. Теперь озадачился вопросом как использовать соединение с AD, которое создает django-auth-ldap при входе пользователя, для запросов к AD уже из самого приложения. Например чтобы получить список всех пользователей домена с нужным набором атрибутов или чтобы создать(изменить) нужную учетную запись. Или все же придется создавать новое соединение?

С Django и Python общаюсь всего месяца 3, поэтому многие вещи еще непонятны.

Заранее спасибо, Дмитрий

Sysinfo: Django v1.5.4 Python v2.7.3 Ubuntu 12.04

Answer | 0

27 Sept. 2013, 8:36 RaD Posts: 2823 Location: Снегири, МО	27 Sept. 2013, 8:36 RaD Posts: 2823 Location: Снегири, МО Как разберётесь, напишите рецепт ;) Если ничего не помогает, прочтите документацию, наконец!
	Answer \| 0

27 Sept. 2013, 12:11
d.kharlamov

Posts: 16
Location: Москва

27 Sept. 2013, 12:11
d.kharlamov

Posts: 16
Location: Москва

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

Вчера ковырялся и понял, что поставил вопрос не совсем корректно. Правильней было бы сказать так: как обратиться к django_auth_ldap, чтобы вести дальнейшую работу с AD от имени аутентифицированного пользователя?

Если соединяться с AD-LDAP как обычно, то выглядит это так:

Функция установки соединения:

def ad_connect():
    ldap.set_option(ldap.OPT_X_TLS_REQUIRE_CERT, ldap.OPT_X_TLS_NEVER)
    dc = 'ldaps://domain.org:636'
    aduser = 'aduser@domain.org'
    password = 'password'
    try:
        l = ldap.initialize(dc)
        l.set_option(ldap.OPT_REFERRALS, 0)
        l.set_option(ldap.OPT_PROTOCOL_VERSION, 3)
        l.set_option(ldap.OPT_X_TLS, ldap.OPT_X_TLS_DEMAND)
        l.set_option(ldap.OPT_X_TLS_DEMAND, True)
        l.set_option(ldap.OPT_DEBUG_LEVEL, 255)
        l.simple_bind_s(aduser, password)
    except ldap.LDAPError, error_message:
        connectError = 'Error connecting to LDAP server: ' + str(error_message)
        return False
    return l

Далее при запросе к LDAP просто обращаемся к функции установки соединения.

def ad_getdata():
    base_dn = 'ou=Users,dc=domain,dc=org'    # Где ищем
    filter = '(&(objectClass=user)(objectCategory=person)(!(objectClass=computer)))'    # Фильтр 
    connect = ad_connect()
    search = connect.seach_s(
    base_dn,
    ldap.SCOPE_SUBTREE,
    filter,
    [список запрашиваемых LDAP-атрибутов]
    ......

Если есть мысли буду очень признателен :)

PS: Огромное спасибо авторам перевода документации! Очень сильно помогает.

Answer | 0

27 Sept. 2013, 12:47 kobzar Posts: 111	27 Sept. 2013, 12:47 kobzar Posts: 111 у вас есть такая переменная как Юзер - встроенная! Добавьте во вьюхе в рендер "user": user После чего можете использовать имя залогиненого юзера как обычную переменную Кто полнял жизнь - тот не спешит...
	Answer \| 0

27 Sept. 2013, 13:13
d.kharlamov

Posts: 16
Location: Москва

27 Sept. 2013, 13:13
d.kharlamov

Posts: 16
Location: Москва

Тут дело не во вьюхе.

Результаты LDAP-запроса проходят дополнительную обработку, затем плэйсятся в БД. Вьюха затем отдает данные из БД. Засада в том, как сделать из самого приложения запрос к LDAP используя механизм django_auth_ldap. Первоначальный вариант, который у меня был я привел, но он избыточен. Всегда хорошо использовать единый механизм аутентификации/авторизации.

Answer | 0

27 Sept. 2013, 14:15 kobzar Posts: 111	27 Sept. 2013, 14:15 kobzar Posts: 111 эм я возможно не знаю что именно вы хотите - но зачем результаты писать в бд а не смотреть напрмяую? Кто полнял жизнь - тот не спешит...
	Answer \| 0

27 Sept. 2013, 15:05
d.kharlamov

Posts: 16
Location: Москва

27 Sept. 2013, 15:05
d.kharlamov

Posts: 16
Location: Москва

Дело в том, что задача несколько шире, чем просто найти или создать пользователя в LDAP. Например - данные из АД и других источников пересекаются между собой и нужно эти данные поженить между собой, а затем этот микс уже отображать.

Пока, на мой взгляд, основную логику удобней и проще реализовать на уровне БД, чем на уровне LDAP-запросов.

Answer | 0

27 Sept. 2013, 15:32
d.kharlamov

Posts: 16
Location: Москва

27 Sept. 2013, 15:32
d.kharlamov

Posts: 16
Location: Москва

у вас есть такая переменная как Юзер - встроенная!

Добавьте во вьюхе в рендер "user": user

После чего можете использовать имя залогиненого юзера как обычную переменную

Туплю уже однако :( Вы оказались правы. Нужно через вьюшку передать функции, которая делает запросы, имя и пароль текущего пользователя.

А можно немного подробней?

Я использовал декоратор @login_required и теперь не могу понять, как обратиться к этой переменной :(

Answer | 0

27 Sept. 2013, 15:57 kobzar Posts: 111	27 Sept. 2013, 15:57 kobzar Posts: 111 `@login_required def profile(request): user = request.user # сам юзер return render(request, 'profile.html',{"user": user}) #Передача юзера в шаблон` Кто полнял жизнь - тот не спешит...
	Answer \| 0

27 Sept. 2013, 16:30
d.kharlamov

Posts: 16
Location: Москва

27 Sept. 2013, 16:30
d.kharlamov

Posts: 16
Location: Москва

А можно так писать?:

def ad_sync(request):
    user = request.user
    ldap_user = user.username
    ldap_pass = user.password
    ad_sync = sync_data(ldap_user, ldap_pass) # обращение к функции, которая делает запросы
    .....

попробовал, но в ответ получил:

Exception Type: INVALID_CREDENTIALS

Exception Value: {'info': '80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1', 'desc': 'Invalid credentials'}

Судя по логам имя берет нормально, а пароль в виде: ldap_pasword u'!'

Answer | 0

27 Sept. 2013, 16:39 wdstrm Posts: 834	27 Sept. 2013, 16:39 wdstrm Posts: 834 логично, джанго не хранит пароли в открытом виде - только в хэше. зайдите в БД, в auth_user и посмотрите поле password 71% добра
	Answer \| 0

27 Sept. 2013, 16:45 d.kharlamov Posts: 16 Location: Москва	27 Sept. 2013, 16:45 d.kharlamov Posts: 16 Location: Москва а как его тогда можно получить и использовать в данной ситуации?
	Answer \| 0

27 Sept. 2013, 16:48 RaD Posts: 2823 Location: Снегири, МО	27 Sept. 2013, 16:48 RaD Posts: 2823 Location: Снегири, МО Лучше для AD завести отдельный пароль и хранить его в открытом виде. Если ничего не помогает, прочтите документацию, наконец!
	Answer \| 0

27 Sept. 2013, 16:58
d.kharlamov

Posts: 16
Location: Москва

27 Sept. 2013, 16:58
d.kharlamov

Posts: 16
Location: Москва

Для обычных запросов так оно и сделано. Однако создание и модификация учетных записей требует полномочий доменного админа, пароль которого хранить в открытом виде ни есть хорошо :) Плюс админов несколько.

Похоже все идет к тому, что видимо придется делать отдельную авторизацию на "опасные" операции.

Answer | 0

27 Sept. 2013, 16:59 wdstrm Posts: 834	27 Sept. 2013, 16:59 wdstrm Posts: 834 Либо пароли сотрудникам выдавать в виде хэша из джанги))) 71% добра
	Answer \| 0

27 Sept. 2013, 17:06 d.kharlamov Posts: 16 Location: Москва	27 Sept. 2013, 17:06 d.kharlamov Posts: 16 Location: Москва Не оценят :) Есть еще вариант на этапе входа в приложение сохранять имя и пароль в переменных, которые потом использовать для LDAP. Вот только в каком месте их воткнуть пока не соображу.
	Answer \| 0

27 Sept. 2013, 17:18 wdstrm Posts: 834	27 Sept. 2013, 17:18 wdstrm Posts: 834 можно в сессию :) 71% добра
	Answer \| 0

28 Sept. 2013, 14:11 d.kharlamov Posts: 16 Location: Москва	28 Sept. 2013, 14:11 d.kharlamov Posts: 16 Location: Москва Использование текущей сессии и подразумевалось в первоначальном вопросе, но этой темы я вообще еще не касался в изучении Django :(
	Answer \| 0

1 Oct. 2013, 17:22
d.kharlamov

Posts: 16
Location: Москва

1 Oct. 2013, 17:22
d.kharlamov

Posts: 16
Location: Москва

Если я правильно понял, то объекты хранимые в session нужно задавать самому. По идее, нужно добавить следующее:

username = request.POST['username']
password = request.POST['password']
request.session['ldap_user'] = username
request.session['ldap_password'] = password

а затем обращаться уже других вьюшек:

ldap_user = request.session['ldap_user']
ldap_password = request.session['ldap_password']

Но как это использовать с @login_required чет как-то не пойму (( Переписывать базовый login() вроде смысла нет...

Answer | 0

1 Oct. 2013, 18:18 RaD Posts: 2823 Location: Снегири, МО	1 Oct. 2013, 18:18 RaD Posts: 2823 Location: Снегири, МО Все телодвижения с сессией внутри представления, окутанного декоратором `@login_required`, привязаны к конкретному пользователю. Если ничего не помогает, прочтите документацию, наконец!
	Answer \| 0

2 Oct. 2013, 7:02
d.kharlamov

Posts: 16
Location: Москва

2 Oct. 2013, 7:02
d.kharlamov

Posts: 16
Location: Москва

То есть я могу все выше приведенное разместить в любой вьюшке где применен @login_required? Правильно я понял?

Например на стартовой странице приложения:

@login_required
def index(request):
    username = request.POST['username']
    password = request.POST['password']
    request.session['ldap_user'] = username
    request.session['ldap_password'] = password
    return render_to_response('index.html')

Одно, правда, непонятно. Механизм аутентификации же такой: при обращении по адресу (в нашем случае: чего-то.там/index.html) @login_required подгружает contrib.auth.login, который собственно и обрабатывает запросы request.POST переданные из формы аутентификации. Если данные валидные, то пускает дальше, если нет, редиректит снова на login.

Непонятно, как данные request.POST попадут во вьюшку index?

Answer | 0

2 Oct. 2013, 8:51

RaD

Posts: 2823
Location: Снегири, МО

2 Oct. 2013, 8:51

RaD

Posts: 2823
Location: Снегири, МО

Хех. Пароли Django расшифровать нельзя, поэтому их невозможно использовать для LDAP.

Допустим, вы не доверяете админу БД (вдруг, она у вас в соседнем здании находится), с которой работает ваш сайт. Следовательно, нельзя пароли для LDAP хранить в открытом виде.

Берём библиотеку GnuPG, генерируем пару ключей, сохраняем их на файловой системе. Шифруем закрытым ключом пароль на LDAP и кладём результат в модель пользователя. Когда надо залезть в LDAP, берём шифрованный пароль из БД, расшифровываем открытым ключом и обращаемся к БД.

Проблема хранения паролей LDAP решена.

Про сессии и @login_required. Если вам надо сохранить данные в сессии авторизованного пользователя, то лучше это делать не на первом шаге. Если вы внимательно читали документацию на сессии, то могли заметить, что там рекомендуется сначала проверить возможность работы с сессиями вообще. Вдруг у пользователя отключены cookie (сессии используют cookie для передачи своего идентификатора между браузером и сервером), тогда никаких сессий не будет. Измените логику сайта так, чтобы пользователь попадал на представление, которое сохраняет данные в сессии, только после его авторизации.

Если ничего не помогает, прочтите документацию, наконец!

Answer | 0

2 Oct. 2013, 11:54
d.kharlamov

Posts: 16
Location: Москва

2 Oct. 2013, 11:54
d.kharlamov

Posts: 16
Location: Москва

При аутентификации в AD через django-auth-ldap пароль в БД не сохраняется (в поле пароля стоит "!"). Насчет хранения в открытом виде вы совершенно правы. Был озадачен, когда прочитал, что данные сессии можно просто получить через decode. Правда в моем случае это не особо критично, поскольку приложение сугубо для нашего подразделения (нет админа БД, которому не доверяем). Но если делать как универсальное средство, то это вырастает в большую проблему.

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

На счет проверки включенных куки читал, поэтому и хотел воспользоваться базовым contrib.auth.login в котором эта проверка делается. Логика сайта так и построена, что пользователь попадает в него только после аутентификации и проверки, что он член группы AD "Domain Admins". Но если сохранять данные сессии (как вы предлагаете) после, того как пользователь уже вошел, то это так же предполагает повторный запрос пары username/password.

Похоже без повторного запроса не обойтись ((( Хотя, может это и к лучшему. У админа будет возможность еще раз подумать прежде чем сделать "опасную" операцию :)))

Answer | 0

2 Oct. 2013, 12:23

RaD

Posts: 2823
Location: Снегири, МО

2 Oct. 2013, 12:23

RaD

Posts: 2823
Location: Снегири, МО

Я не предлагаю сохранять в сессии. Я предлагаю сразу писать логин и пароль (последний в зашифрованном виде) в профиль пользователя (т.е. в БД) и брать его оттуда, когда потребуется.

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

Вы меня неправильно поняли. Пару ключей надо сделать для сервера. Один раз, руками. Прописать пути до них в конфигурации сайта и использовать их для шифрации/дешифрации пароля LDAP. Хотя генерация на лету, тоже возможно - проверял тут http://djbook.ru/forum/topic/71/

Если ничего не помогает, прочтите документацию, наконец!

Answer | 0

2 Oct. 2013, 14:20
d.kharlamov

Posts: 16
Location: Москва

2 Oct. 2013, 14:20
d.kharlamov

Posts: 16
Location: Москва

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

С GnuPG и правда недопонял малость. Как-то автоматом подумал про генерацию персональных ключей.

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

PS/ Если кому нужен работоспособный конфиг с django-auth-ldap могу выложить.

Answer | 0