Ubuntu 12.04 서버에 외부에서 익명으로 액세스할 수 있는 LDAP 디렉터리를 설정해야 하며 인증 및 내부 데이터를 다른 하위 트리에 보관하고 싶습니다.
LDAP 레이아웃의 예
dc=example.com,dc=com
organizationUnit: ou=hie_ext,dc=example,dc=com
organizationUnit: ou=group1,ou=hie_ext,dc=example,dc=com
inetOrgPerson: cn=user1,ou=group1,ou=hie_ext,dc=example,dc=com
inetOrgPerson: cn=user2,ou=group1,ou=hie_ext,dc=example,dc=com
organizationUnit: ou=group2,ou=hie_ext,dc=example,dc=com
organizationUnit: ou=group_auth,dc=example,dc=com
account: uid=group1,password=XXX,ou=group_auth,dc=example,dc=com
아이디어는 uid=group1 인증이 ou=hie_ext,ou=group1 아래 항목을 추가/편집(기본적으로 "쓰기")할 수 있다는 것입니다. 다음과 같은 ACL 규칙을 시도했습니다.
access to dn.children="ou=hie_ext,dc=example,dc=com"
by set="this/ou & user/uid" write
by * none
하지만 slapacl을 사용하여 쓰기 권한을 테스트할 때 테스트하면 "ALLOWED"가 표시됩니다.
"ou=group1,ou=hie_ext,dc=example,dc=com"
하지만 내가 테스트할 때는 "거부"되었습니다.
"cn=user1,ou=group1,ou=hie_ext,dc=example,dc=com"
나에게는 조금 이상해 보인다.
나는 아마도 명백한 것을 간과하고 있는 것 같습니다(이 시점에서 나는 LDAP에 대해 매우 녹색입니다). slapacl에 "-d Trace" 옵션을 실행하는 것은 내가 무엇을 보고 있는지 전혀 모르기 때문에 별로 도움이 되지 않았습니다. :)
업데이트:
따라서 "-d Trace"는 너무 복잡해서 나에게는 전혀 쓸모가 없지만 "-d acl"이 아마도 훨씬 더 도움이 될 것이라는 것을 알게 되었습니다.
그래서 내가 달리면
slapacl -f slapd.conf -D"uid=group1,ou=servers,dc=example,dc=com" \
-b "cn=user1,ou=group1,ou=hie_ext,dc=example,dc=com" "sn/write" -d acl
디버그 출력은 다음과 같습니다.
52d544e1 => access_allowed: write access to "cn=test,ou=group1,ou=hie_ext,dc=example,dc=com" "sn" requested
52d544e1 => dn: [1]
52d544e1 => dn: [2] ou=hie_ext,dc=example,dc=com
52d544e1 => acl_get: [2] matched
52d544e1 => acl_get: [2] attr sn
52d544e1 => acl_mask: access to entry "cn=test,ou=group1,ou=hie_ext,dc=example,dc=com", attr "sn" requested
52d544e1 => acl_mask: to all values by "uid=group1,ou=servers,dc=example,dc=com", (=0)
52d544e1 <= check a_set_pat: this/ou & user/uid
52d544e1 => bdb_entry_get: found entry: "uid=group1,ou=servers,dc=example,dc=com"
52d544e1 ACL set[0]=group1
52d544e1 ACL set: empty
52d544e1 <= check a_dn_pat: *
52d544e1 <= acl_mask: [2] applying read(=rscxd) (stop)
52d544e1 <= acl_mask: [2] mask: read(=rscxd)
52d544e1 => slap_access_allowed: write access denied by read(=rscxd)
52d544e1 => access_allowed: no more rules
write access to sn: DENIED
그러나 레코드별 CN을 삭제합니다.
slapacl -f slapd.conf -D"uid=group1,ou=servers,dc=example,dc=com" \
-b "ou=group1,ou=hie_ext,dc=example,dc=com" "sn/write" -d 128
그리고 그것은 작동합니까?
52d545ef => access_allowed: write access to "ou=group1,ou=hie_ext,dc=example,dc=com" "sn" requested
52d545ef => dn: [1]
52d545ef => dn: [2] ou=hie_ext,dc=example,dc=com
52d545ef => acl_get: [2] matched
52d545ef => acl_get: [2] attr sn
52d545ef => acl_mask: access to entry "ou=group1,ou=hie_ext,dc=example,dc=com", attr "sn" requested
52d545ef => acl_mask: to all values by "uid=group1,ou=servers,dc=example,dc=com", (=0)
52d545ef <= check a_set_pat: this/ou & user/uid
52d545ef ACL set[0]=group1
52d545ef => bdb_entry_get: found entry: "uid=group1,ou=servers,dc=example,dc=com"
52d545ef ACL set[0]=group1
52d545ef ACL set[0]=group1
52d545ef <= acl_mask: [1] applying write(=wrscxd) (stop)
52d545ef <= acl_mask: [1] mask: write(=wrscxd)
52d545ef => slap_access_allowed: write access granted by write(=wrscxd)
52d545ef => access_allowed: write access granted by write(=wrscxd)
write access to sn: ALLOWED
ACL 파서가 첫 번째 예와 두 번째 예 사이에서 "this/ou"에 대해 다른 값 세트를 얻는 이유가 무엇인지 잘 모르겠습니다. 현재 상황이 그런 것 같습니다.
답변1
ACL의 작동 방식을 오해한 것 같습니다. 분명히, 내가 하려고 했던 것처럼 "상속된" 속성에 대해 테스트할 수는 없습니다. DN의 속성은 지정된 개체의 일부가 아닙니다. 이는 초보자 LDAP 사용자에게 귀중한 교훈입니다.
내가 뭘 잘못하고 있는지 알아낸 후에 해결책은 매우 간단했습니다.
인증 개체[0]의 uid와 일치하는 inetorgperson 레코드에 "ou" 요소를 추가했습니다. "마법처럼" 일이 작동하기 시작했습니다.
by set="this/ou & user/uid" write
[0] 각 인증 계정이 특정 단위에 연결되어 있기 때문에 스키마의 오용은 아닌 것 같습니다. 약속하다!