Страница 2 из 4

СообщениеДобавлено: 07 фев 2005, 20:58
Михаил Григорьев
Про сквид все просто:

Ставим Squid с поддержкой LDAP

Далее правим squid.conf

Если предполагаем доступ без групп:

auth_param basic program /usr/local/libexec/squid/squid_ldap_auth -b "o=SKBKontur" -h 192.168.100.3 -f "(&(cn=%s)(objectClass=Person))" -s sub

С группами:

auth_param basic program /usr/local/libexec/squid/squid_ldap_auth -b "o=SKBKontur" -h 192.168.100.3 -D cn=Admin,o=SKBKontur -w 12345 -f "(&(cn=%s)(objectClass=Person)(securityequals=cn=Squid,o=SKBKontur))" -s sub

или

auth_param basic program /usr/local/libexec/squid/squid_ldap_auth -b "o=SKBKontur" -h 192.168.100.3 -D cn=Admin,o=SKBKontur -w 12345 -f "(&(&(cn=%s)(objectClass=Person))(securityequals=cn=Squid,o=SKBKontur))" -s sub

или

auth_param basic program /usr/local/libexec/squid/squid_ldap_auth -b "o=SKBKontur" -h 192.168.100.3 -D cn=Admin,o=SKBKontur -w 12345 -f "(&(cn=%s)(objectClass=Person)(|(securityequals=cn=Squid,o=SKBKontur)))" -s sub

или много групп

auth_param basic program /usr/local/libexec/squid/squid_ldap_auth -b "o=SKBKontur" -h 192.168.100.3 -D cn=Admin,o=SKBKontur -w 12345 -f "(&(cn=%s)(objectClass=Person)(|(securityequals=cn=Squid,o=SKBKontur)(securityequals=cn=Squid1,o=SKBKontur)(securityequals=cn=Squid2,o=SKBKontur)))" -s sub

Пишем ACL'ки:

acl ldap proxy_auth REQUIRED
acl vpn_kontur_src src 192.168.201.0/255.255.255.0

http_access allow vpn_kontur_src
http_access allow ldap


УСЁ !!!

ACL vpn_kontur_src как раз под VPN написана, ибо у нас с рабочих станция до сервере VPN тунель, а далее Squid, NAT и еще куча всего.

P.S:

o=SKBKontur - BaseDN
192.168.100.3 - IP NW сервера
cn=Admin,o=SKBKontur - ну это понятно
12345 - пароль админа
cn=Squid,o=SKBKontur
cn=Squid1,o=SKBKontur
cn=Squid2,o=SKBKontur - это группы членам которых разрешено ходить в инет.

Почему в случае с группами нужно авторизоваться админом (лучше конечно же завести другого юзера) потому что нужно читать аттрибут securityequals а его при анонимном подключении читать нельзя.

Про остальное (VPN и NAT) и единой регистрации я уже раз 5-10 писал на форуме, поищите по слову squid и найдете массу всего
Например: http://novell.org.ru/forum/viewtopic.php?t=5254

СообщениеДобавлено: 08 фев 2005, 02:16
Багинский Константин
Пардон за тупость, но ничего не понял.

От клиента до прокси у Вас VPN. Отлично. У нас, кстати, тоже. Но для авторизации в VPN откуда ttptd берет информацию? Где именно хранится информация логин/пароль?

Я так понимаю, что после VPN уже сам SQUID по принадлежностям к группам из Дерева раздает права и никаких логинов и паролей не спрашивает. А NAT как пользователей различает? Как их трафик делится? Ну и про SMTP сервис я тоже пока не задаю вопрос, но он следующий. Для него как быть? А для внутреннего веб-сервера? А для внутреннего FTP? Причем ведь хочется добиться прозрачности. Чтобы пользователь забыл о многократном введении пароля.

Ну и про стороннее приложение вопрос открытый. :cry:

СообщениеДобавлено: 08 фев 2005, 13:14
Михаил Григорьев
Багинский Константин писал(а):Пардон за тупость, но ничего не понял.

От клиента до прокси у Вас VPN. Отлично. У нас, кстати, тоже. Но для авторизации в VPN откуда ttptd берет информацию? Где именно хранится информация логин/пароль?

Я так понимаю, что после VPN уже сам SQUID по принадлежностям к группам из Дерева раздает права и никаких логинов и паролей не спрашивает. А NAT как пользователей различает? Как их трафик делится? Ну и про SMTP сервис я тоже пока не задаю вопрос, но он следующий. Для него как быть? А для внутреннего веб-сервера? А для внутреннего FTP? Причем ведь хочется добиться прозрачности. Чтобы пользователь забыл о многократном введении пароля.

Ну и про стороннее приложение вопрос открытый. :cry:


http://novell.org.ru/forum/viewtopic.php?t=5254

Там детально описано как у нас что сделано, повторять просто уже сил нет, чесное слово.

Сквид у нас вообще без авторизации стоит, у него прописана 1 единственная ACLка:

acl vpn_kontur_src src 192.168.201.0/255.255.255.0
http_access allow vpn_kontur_src

База пользователей - OpenLDAP (в принципе никто не мешает и NW LDAP использовать, НО возникает ряд проблем, оин в топике описаны)
NAT вообще никак не регулируемый всё из сетки 192.168.201.0 заворачивать наружу, ну естественно кроме конектов на 80-й и 443-й порты, а как разгребать кто куда и сколько (допустим SMTP или другой трафик то это я тоже писал тоже в топике)

Для Apache есть замечательный модуль для LDAP авторизации, работает без проблем как с OpenLDAP так и с NWLDAP

доступ к серверу по FTP это уже PAM_LDAP+NSS_LDAP, объяснять что это есть долго, работает тоже как с OpenLDAP так и с NWLDAP и даже с AD без проблем.

Почтовик аналогично...

СообщениеДобавлено: 08 фев 2005, 13:30
Vladimir Kozak
Григорьев Михаил писал(а):Чёт я не пойму, кто на кого авторизуется? squid авторизуется на eDir или как? если речь про сквида то решение то есть же, ставится за 30 мин.


Отработка информации через клиента - это конечно, во многих случаях решение, и неплохое. Но, мне бы тоже хотелось в некоторых случаях решить вопрос aaa "имея на руках" только свою программу, ip и eDir.

СообщениеДобавлено: 08 фев 2005, 20:26
Багинский Константин
Внимательно прочитал Ваш топик. Собственно у нас сделано абсолютно точно также. Только вместо радиуса был написан патч для pptpd, который к LDAP-у (на базе eDir) обращается напрямую. Но основной вопрос остается открытым. Как RADIUS берет пароль в LDAP -e? Как этот пароль хранится в LDAPe? Ведь LDAP - это просто каталог. Он не предназначен изначально для инфраструктуры безопасности. Для этого существует KERBEROS. Но это отдельная большая тема, про которую почемуто никто вообще не вспоминает.

И еще вопрос. Может ну его LDAP? Ведь почему-то есть eDir. Может проще изначально его фичи использовать? Тем более утверждается, что он как раз и обязан повышать безопасность сетевых соединений. Но где этот механизм? Ответ на developer.novell.com звучит слегка издевательски. :cry:

СообщениеДобавлено: 09 фев 2005, 11:53
Михаил Григорьев
Багинский Константин писал(а):Внимательно прочитал Ваш топик. Собственно у нас сделано абсолютно точно также. Только вместо радиуса был написан патч для pptpd, который к LDAP-у (на базе eDir) обращается напрямую. Но основной вопрос остается открытым. Как RADIUS берет пароль в LDAP -e? Как этот пароль хранится в LDAPe? Ведь LDAP - это просто каталог. Он не предназначен изначально для инфраструктуры безопасности. Для этого существует KERBEROS. Но это отдельная большая тема, про которую почемуто никто вообще не вспоминает.


Radius берёт пароль очень просто, он это умеет.

Привожу пример /usr/local/etc/raddb/radiusd.conf

Код: Выделить всё
....
modules {
.....
        mschap {
                authtype = MS-CHAP
        }
        ldap {
                server = "127.0.0.1"
                identity = "cn=Manager,o=MyORG,c=RU"
                password = 12345
                basedn = "ou=Users,o=MyORG,c=RU"
                filter = "(uid=%{Stripped-User-Name:-%{User-Name}})"
                base_filter = "(objectclass=radiusprofile)"
                start_tls = no
                access_attr = "radiusFramedIPAddress"
                dictionary_mapping = ${raddbdir}/ldap.attrmap
                ldap_connections_number = 5
                password_attribute = sambaNTPassword
                timeout = 4
                timelimit = 3
                net_timeout = 1
        }
.....
}

authorize {
               preprocess
               suffix
               ldap
               mschap
}

authenticate {
        Auth-Type MS-CHAP {
                mschap
        }
}

...


Пароль в OpenLDAP лежит в виде NTHash и в виде LMHash для NT4

По поводу KERBEROS, как раз в openldap-2.3.1alpha (он сейчас в бете есть) написан модуль smbk5pwd он как раз при вызове API OpenLDAP по смене пароля закомпанию меняет пароли в Samb'е и Kerberos.
Как раз вчера вечером мой друг написал port для FreeBSD для openldap-2.3.1alpha, сегодня сижу и тестирую сиё счастье :)

Так что керберос это очень интересная вещь про которую никто и не забывал :)

СообщениеДобавлено: 09 фев 2005, 14:51
Сергей Дубров
Григорьев Михаил писал(а):Так что керберос это очень интересная вещь про которую никто и не забывал :)

Кстати, Новелл поддержку Kerberos-а в Edir тоже сделал (спасибо NMAS), не сильно об этом распространяясь. Я наткнулся на упоминание об этом на сайте Мичиганского университета (один из любимых Новелом полигонов для обкатки новый технологий). С полгода назад он был ещё в бетах, сейчас, как я понял, уже работает всерьёз:

http://www.novell.com/coolsolutions/feature/5873.html
http://www.umich.edu/~lannos/novell/kerberos.html

СообщениеДобавлено: 09 фев 2005, 17:13
Михаил Григорьев
Сергей Дубров писал(а):Кстати, Новелл поддержку Kerberos-а в Edir тоже сделал (спасибо NMAS), не сильно об этом распространяясь. Я наткнулся на упоминание об этом на сайте Мичиганского университета (один из любимых Новелом полигонов для обкатки новый технологий). С полгода назад он был ещё в бетах, сейчас, как я понял, уже работает всерьёз:

http://www.novell.com/coolsolutions/feature/5873.html
http://www.umich.edu/~lannos/novell/kerberos.html


Не знал однако :( Но теперь буду знать :) Век живи, век учись! :)

СообщениеДобавлено: 09 фев 2005, 18:40
Юрий Беляков
Багинский Константин писал(а):Внимательно прочитал Ваш топик. Собственно у нас сделано абсолютно точно также. Только вместо радиуса был написан патч для pptpd, который к LDAP-у (на базе eDir) обращается напрямую. Но основной вопрос остается открытым. Как RADIUS берет пароль в LDAP -e? Как этот пароль хранится в LDAPe? Ведь LDAP - это просто каталог. Он не предназначен изначально для инфраструктуры безопасности. Для этого существует KERBEROS. Но это отдельная большая тема, про которую почемуто никто вообще не вспоминает.

И еще вопрос. Может ну его LDAP? Ведь почему-то есть eDir. Может проще изначально его фичи использовать? Тем более утверждается, что он как раз и обязан повышать безопасность сетевых соединений. Но где этот механизм? Ответ на developer.novell.com звучит слегка издевательски. :cry:


Поправлю путаницу: LDAP - это протокол обращения к службе каталогов. Для безопасности можно использовать шифрование (LDAPS). Собственно мы так и делаем для авторизации пользователей в самописных веб-приложениях в службе каталогов eDirectory.

СообщениеДобавлено: 09 фев 2005, 20:16
Багинский Константин
Собственно в eDir пароль хранится в novell хэш :? И хочется собственно этот пароль и брать для всех процедур авторизации. А так получается, что необходимо заводить доп атрибут, где хранить NThash. Причем необходима процедура автоматической смены этого (и прочих) хэшей при смене пользователем пароля. И еще ньюанс. К новельному хэшу доступ несколько затруднен. Даже админу. А вот когда его ставишь атрибутом пользователя, то он сразу доступен всем. Говорят в последних версиях это исправлено и можно установить права как надо. Но пока так.

Но даже задачи синхронизации хэшей хватит с головой. Или опять для каждого сервиса свой пароль. :cry:

СообщениеДобавлено: 09 фев 2005, 20:49
Andrey Karyagin
2 Февраля сего года по адресу http://www.novell.com/coolsolutions/appnote/11468.html
была опубликована статья под названием
Extending Kerberos Single Sign-On to eDirectory with the NMAS Kerberos Method
С ее помощью можно попробовать что-нибудь свое.

СообщениеДобавлено: 10 фев 2005, 01:49
Багинский Константин
Вы пытались осознать, что там написано?

во-первых, получается, что пароль eDir подменяется паролем Kerberos. Т.е. сразу вопрос, что происходит при попытке смены пароля в eDir? Или уменяйся хоть до посинения, но истинный пароль в Kerberos.

во-вторых, что делать с Линукс клиентами? Если у Вас таких нет, то у меня есть.

Есть, конечно, еще личная проблема. Я пока еще не уяснил до конца, что за зверь этот керберос (кроме как большая псина ;-) ). Например механизм смены пароля не ясен. Точнее даже интерфейс. И механизм интеграции кербероса с другими приложениями. Например с тем же pptpd. И что делать с клиентскими приложениями, которые не понимают керберос? Еще с серверными приложениями можно теоретически разобраться. Их не очень много. А пользовательских приложений на порядки больше. Да и не хочется заморачиваться с клиентами. В этом смысле для меня идеал решения - бордюр. Есть маленький агентик, который берет на себя все ньюансы общения. А браузеру (любому!) остается только идти в инет как он может. Но вот выясняется, что даже когда предлагаешь под заказ сделать такую конфигурацию, никто ничего путного не предлагает. :cry:

И вообще встает философский вопрос. Читая все предложенные и самостоятельно найденные TID-ы начинаешь себя спрашивать - а на хрена мне сдался eDir? Взять OpenLDAP, скрестить его с керберосом, и не жужать. Единственное, что меня заставляет мучиться с eDir-ом, это использование зена. Вот ему то реальной замены никакой. Сейчас заказали 6.5. Будем играться, смотреть, как он чем может рулить и в каком ключе.

СообщениеДобавлено: 10 фев 2005, 10:20
Владимир Горяев
Багинский Константин писал(а):Собственно в eDir пароль хранится в novell хэш :? И хочется собственно этот пароль и брать для всех процедур авторизации.
А зачем брать?

СообщениеДобавлено: 10 фев 2005, 11:13
PavelKHTW
Владимир Горяев писал(а):
Багинский Константин писал(а):Собственно в eDir пароль хранится в novell хэш :? И хочется собственно этот пароль и брать для всех процедур авторизации.
А зачем брать?

Видимо затем чтобы сравнить с введенным, причем хочется иметь его в открытом виде :). Короче говоря, человеку нужно почитать литературу по системам безопасности.

СообщениеДобавлено: 10 фев 2005, 11:42
Михаил Григорьев
Вобщем я скажу одно, было бы желание и терпение, а сделать можно всё !!! :wink: