как определить DN для файла ldif, если DC не указан при настройке с помощью весенней загрузки - PullRequest
Новая
       91

как определить DN для файла ldif, если DC не указан при настройке с помощью весенней загрузки

2 голосов
/ 19 октября 2019

Я использую встроенный ldap-сервер с весенней загрузкой для тестирования моего файла ldif и его учетных данных, но, как я обнаружил, мой формат файла ldif немного отличается от обычного ldif, поскольку dc не является приватным, внутри dn указывается только o.

Я пробовал другую конфигурацию для указанного выше формата ldif, но он по-прежнему показывает экран Bad Credentials, но он отлично работает с другими файлами ldif.

Файл ldif 

# id=00000001
dn: o=COMPANY
objectClass: organization
structuralObjectClass: organization
o: COMPANY
entryCSN: 20130409162114.626166Z#000000#000#000000
entryUUID: 3e7f8668-357d-1032-8a6b-c5bcf7f703f0
creatorsName: cn=Manager,o=COMPANY
createTimestamp: 20130409162114Z
modifiersName: cn=Manager,o=COMPANY
modifyTimestamp: 20130409162114Z
contextCSN: 20130702105648.506150Z#000000#000#000000
contextCSN: 20191018052018.692119Z#000000#001#000000
contextCSN: 20191018044350.858888Z#000000#002#000000
contextCSN: 20191018053729.621549Z#000000#003#000000

# id=00000002
dn: ou=department,o=COMPANY
objectClass: organizationalUnit
structuralObjectClass: organizationalUnit
ou: department
entryCSN: 20130409162455.623488Z#000000#000#000000
entryUUID: c2390a06-357d-1032-8a6c-c5bcf7f703f0
creatorsName: cn=Manager,o=COMPANY
createTimestamp: 20130409162455Z
modifiersName: cn=Manager,o=COMPANY
modifyTimestamp: 20130409162455Z

WebSecurityConfig

@Override
    public void configure(AuthenticationManagerBuilder auth) throws Exception {
        auth
            .ldapAuthentication()
                .userDnPatterns("uid={0},ou=department")
                .contextSource()
                    .url("ldap://localhost:8389/o=COMPANY")
                    .and()
                .passwordCompare()
                    .passwordEncoder(new LdapShaPasswordEncoder())
                    .passwordAttribute("userPassword");
}

application.properties 

spring.ldap.embedded.base-dn= o=COMPANY
spring.ldap.embedded.ldif=classpath:ldap-server-2.ldif
spring.ldap.embedded.port= 8389
spring.ldap.embedded.validation.enabled=false

После того, как, настроив все вышеперечисленные детали, приложение работает хорошо, и я получаю экран аутентификации, но событие после правильных учетных данных, я получаю экран Bad Credentials. Я не понимаю, в чем дело, будь то имя dn для ldif или как?

Пожалуйста, предоставьте ваши ценные предложения. Заранее спасибо!

1 Ответ

0 голосов
/ 20 октября 2019

Само по себе не проблема иметь o=COMPANY в качестве корневой записи вместо использования DC.

Ваш ldif кажется правильным, но то, что показано здесь, не содержит никакой пользовательской записи (просто id=00000001 и id=00000002).

Итак, согласно userDnPatterns("uid={0},ou=department"), пользовательские записи должны содержаться в ou=department и, таким образом, определены после в вашем файле ldif, например. : 

# id=00000003
dn: uid=test,ou=department,o=COMPANY
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
uid: test
mail: test@domain.com
cn: Firstname Lastname
givenName: Firstname
sn: Lastname

Кроме того, большинство серверов не принимают анонимные привязки, и самому запросу аутентификации может потребоваться привязка к серверу для поиска данной записи и проверки ее учетных данных, просто добавьте managerDn()и managerPassword() в методе configure WebSecurityConfig: 

.contextSource()
  .url('ldap://localhost:8389/o=COMPANY')
  .managerDn('admin')
  .managerPassword('password')
  .and()
...

Вы также можете установить эти параметры ContextSource в application.properties : 

spring.ldap.embedded.credential.username= uid=admin
spring.ldap.embedded.credential.password= password
...