Comments 10
Ну это. Нехороший администратор LDAP? По сути, это уже конец всякой защиты. Я с тем же успехом могу взять чужой аккаунт, поменять пароль и ходить куда мне вздумается. Патч защитой то не назовешь. Поэтому комментарии разработчиков gitlab не удивляют.
А так, в настройках LDAP можно использовать фильтры, чтобы ограничить аутентификацию по принадлежности к какой-то группе, что собственно у нас и сделано.
А так, в настройках LDAP можно использовать фильтры, чтобы ограничить аутентификацию по принадлежности к какой-то группе, что собственно у нас и сделано.
Совершенно согласен, «нехороших» администраторов быть не должно да и киберпреступников тоже и других плохих людей. Если такие администраторы есть, то это действительно ничего хорошего не сулит. Но… они бывают!!! Бывают не совсем нехорошие, а просто не вполне квалифицированные и очень любопытные. Ситуации бывают всякие.
А, то что фактически информационное поле в LDAP является ключом к аккаунту считаю тоже не совсем правильным.
Тем не менее хочу поблагодарить авторов GitLab — это отличная система управления версиями, очень динамично развивается, быстро исправляются ошибки, добавляются новые фичи.
Ну и на самом деле я совершенно нормально воспринял реакцию авторов. Они действительно продекларировали такое поведение, а чтобы правильно и качественно изменить его, конечно-же одним патчем не обойдешься.
А я просто предложил свой вариант решения проблемы (вернее того, что я считаю проблемой) и возможно это решение понадобится еще кому-нибудь.
Также, я нисколько не сомневаюсь, что в будущем GitLab станет еще лучше, поэтому мы и выбрали эту систему для управления своим исходным кодом.
А, то что фактически информационное поле в LDAP является ключом к аккаунту считаю тоже не совсем правильным.
Тем не менее хочу поблагодарить авторов GitLab — это отличная система управления версиями, очень динамично развивается, быстро исправляются ошибки, добавляются новые фичи.
Ну и на самом деле я совершенно нормально воспринял реакцию авторов. Они действительно продекларировали такое поведение, а чтобы правильно и качественно изменить его, конечно-же одним патчем не обойдешься.
А я просто предложил свой вариант решения проблемы (вернее того, что я считаю проблемой) и возможно это решение понадобится еще кому-нибудь.
Также, я нисколько не сомневаюсь, что в будущем GitLab станет еще лучше, поэтому мы и выбрали эту систему для управления своим исходным кодом.
быстро исправляются ошибки, добавляются новые фичи.
жаль только вот ошибке с определением не-UTF-8-кодировки содержимого файлов уже пара лет и, судя по комменту, в ноябре 2015-го воз был всё там же
А если нехороший администратор заменит пароль у атакуемого пользователя, предварительно сохранив текущий хэш, залогинится, а потом вернёт хэш назад?
Организация с кучей очень далеко разбросанных филиалов.
Для филиала А остальные филиалы (например B,C,D) — конкурирующие организации. Адмнистратор филиала А ничего не может делать с пользователями других филиалов (достигается делегированием полномочий), но может создать в своем OU левого пользователя и указав e-mail пользователя практически другой для него организации завладеть аккаунтом.
Для филиала А остальные филиалы (например B,C,D) — конкурирующие организации. Адмнистратор филиала А ничего не может делать с пользователями других филиалов (достигается делегированием полномочий), но может создать в своем OU левого пользователя и указав e-mail пользователя практически другой для него организации завладеть аккаунтом.
т.е. почитать документацию и заюзать фильтры в конфигурации gitlab'a сложнее, чем манкипатчить проект?
http://doc.gitlab.com/ee/integration/ldap.html#configuring-gitlab-for-ldap-integration
http://doc.gitlab.com/ee/integration/ldap.html#configuring-gitlab-for-ldap-integration
А почему Вы решили что другие филиалы не должны использовать Гитлаб?
потому что если вы хотите разграничить доступ к гиту в филиалах, проще поднять в каждом филиале свой гит сервер (и ближе и администрировать проще) и настроить аутентификацию только по OU филиала. Таким образом гит сервер находится и в сети филиала, недоступной для других и аутентификация по OU недоступной для других. Тоже самое справедливо и для локальной конторы с множеством отделов — выносить гит в vlan отдела и аутентификация только по OU отдела.
Sign up to leave a comment.
Небезопасный способ авторизации в GitLab CE с использованием LDAP аккаунтов и метод устранения уязвимости