OpenLDAP ACL'lerini tanımlamak zordur.
Çoğu zaman ACL sorunları, ACL'lerin kendilerinin ve kimin cümleciklerinin (... tarafından) işlenme sırasından ve ACL'lerin by * none
kontrol akışını durdurma ile dolaylı olarak sona ermesinden kaynaklanır .
Cn = config ile dinamik konfigürasyon kullanıyorsunuz ve bu
şemadaki olcAccess gibi bazı nitelik değerlerinin sırasını korumak için X-ORDERED uzantısını kullanıyor .
Dolayısıyla, EKL’lerinizin işlenme sırası şöyledir:
{0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="cn=admin,dc=mydomain" write by * none
{1}to dn.subtree="dc=something,dc=mydomain" by dn="uid=someone,ou=users,dc=mydomain" write by * read
{2}to dn.base="" by * read
{3}to dn.exact="dc=mydomain" attrs=entry by users search by * none
{4}to dn.subtree="ou=users,dc=mydomain" by self read
{5}to * by self write by dn="cn=admin,dc=mydomain" write by * none
Öyleyse ACL'lerinizi ayrıntılı olarak inceleyelim:
{0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="cn=admin,dc=mydomain" write by * none
Bu, muhtemelen bazı varsayılan yapılandırmalardan alınmış bir kuraldır. Başlamak sorun değil ama bazı faktörleri yeniden düşünmenizi öneririm:
- LDAP gölge kavramı kırıldığından, shadowLastChange niteliğini atlayın . Ve eğer gölge haritalar kullanırsanız, bu ACL kullanıcının gölge şifresini sona erdirmesini önler.
- Kim-cümlelerinin sırasını değiştirin. Genel olarak, önce "daha yüksek" ayrıcalıklardan bahsetmek için kuralı izleyin.
- Eğer cn = admin, dc = etkialanim zaten bu veritabanının kökü ise, o maddeye gerek duymazsınız .
- Bir gruba daha iyi şifre yönetici hakları verin.
- Kapsayıcı
writeerişim ile hiç okuma imtiyazı vermeyin , =wbunun yerine sadece yazma ayrıcalığını kullanın.
Daha iyi kullanım:
{0}to attrs=userPassword by group="cn=admins,ou=groups,dc=mydomain" =w by self =w by anonymous auth by * none
{1}to dn.subtree="dc=something,dc=mydomain" by dn="uid=someone,ou=users,dc=mydomain" write by * read
Eğer dc=mydomainveritabanı eki olan bu ACL Sorunuzun bağlamında bana çok mantıklı değil. Belki bazı testlerden kalanlar?
{2}to dn.base="" by * read
Bu, veritabanı yapılandırma girişinize yerleştirildiğinde etkili değildir. Bu cn = config ön-uç config girişine eklenmelidir (önceden herhangi bir veritabanı bölümünden önce statik config slapd.conf içinde
).
{3}to dn.exact="dc=mydomain" attrs=entry by users search by * none
ACL listesinin sonuna böyle bir ACL yerleştiririm, böylece bu noktada girmeye erişimi durdurmaz . Ve ou = users, dc = mydomain gibi rasgele arama tabanlarını kullanmak istiyorsanız, bu aramayı tüm alt ağaca vermeniz gerekir.
Öyleyse bunu ACL'nizin sonuna yerleştirin ve {3} veya ...
{6}to dn.subtree="dc=mydomain" attrs=entry by users search by * none
... bu kuralı taşı:
{4}to dn.subtree="ou=users,dc=mydomain" by self read
Muhtemelen en son ACL olmalı ve {3} yerine. {5} için yoruma bakınız.
{5}to * by self write by dn="cn=admin,dc=mydomain" write by * none
Buradaki sorunlar:
by self writeNedeniyle ulaşmak asla by self readin {4}.- Bu ACL'ye
by * none{4} içerisindeki örtüklük nedeniyle hiç ulaşılmadı .
- tekrar: rootdn'a erişim vermek gerekli değildir
- tekrar: daha iyi bir gruba yönetici erişimi ver
- who-cümle sıralarını daha iyi kullanmak
- Kullanıcının tüm özelliklerine gerçekten yazma izni vermek istiyorsanız yeniden gözden geçirin.
Daha iyi:
{5}to * by group="cn=admins,ou=groups,dc=mydomain" write by self write by * none
En önemli hata ayıklama seçeneğinden biri , ACL işlemlerini günlüğe kaydederek tokatlamaya başlamaktır :
/usr/sbin/slapd … -d config,stats,stats2,acl
Bu yüzden bu ipuçları, sorunlarınızı kendiniz çözerek ACL'leriniz üzerinde çalışmaya başlamanızı sağlamalıdır. Her zaman iki kere düşün. Bana öyle geliyor ki kurallarınızda biraz çelişkili varsayımlar var.
Ancak, dokümanlar arasında derinlemesine dalış yapmanın kesinlikle bir yolu yok:
ACL'leri ayrıntılı olarak anlamak istiyorsanız, çeşitli çevrimiçi belgelere başvurmalısınız: