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

Я использую встроенный сервер 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");
}

приложение.свойства

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 или что?

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


spring-boot ldap openldap spring-ldap spring-security-ldap
person Balram Chauhan    schedule 19.10.2019    source источник

Ответы (1)


arrow_upward
0
arrow_downward

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

Ваш 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: [email protected]
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
person EricLavault    schedule 20.10.2019
comment
Спасибо @Eric. Я сделал ту же ошибку, что и вы, я не сосредоточился на пользовательских данных внутри файла ldif. Теперь он работает нормально. Спасибо за помощь! - person Balram Chauhan; 21.10.2019