Xác thực Apache HTTPd với nhiều máy chủ LDAP bằng tài khoản đã hết hạn


8

Chúng tôi đang sử dụng mod_authnz_ldap và mod_authn_alias trong Apache 2.2.9 (như được vận chuyển trong Debian 5.0, 2.2.9-10 + lenny7) để xác thực với nhiều miền Active Directory để lưu trữ kho lưu trữ Subversion. Cấu hình hiện tại của chúng tôi là:

# Turn up logging
LogLevel debug

# Define authentication providers
<AuthnProviderAlias ldap alpha>
  AuthLDAPBindDN "CN=Subversion,OU=Service Accounts,O=Alpha"
  AuthLDAPBindPassword [[REDACTED]]
  AuthLDAPURL ldap://dc01.alpha:3268/?sAMAccountName?sub?
</AuthnProviderAlias>

<AuthnProviderAlias ldap beta>
  AuthLDAPBindDN "CN=LDAPAuth,OU=Service Accounts,O=Beta"
  AuthLDAPBindPassword [[REDACTED]]
  AuthLDAPURL ldap://ldap.beta:3268/?sAMAccountName?sub?
</AuthnProviderAlias>

# Subversion Repository
<Location /svn>
  DAV svn
  SVNPath /opt/svn/repo
  AuthName "Subversion"
  AuthType Basic
  AuthBasicProvider alpha beta
  AuthzLDAPAuthoritative off
  AuthzSVNAccessFile /opt/svn/authz
  require valid-user
</Location>

Chúng tôi đang gặp sự cố với người dùng có tài khoản ở cả Alpha và Beta, đặc biệt là khi tài khoản của họ đã hết hạn (nhưng vẫn còn; chính sách của công ty là các tài khoản tồn tại tối thiểu 1 năm). Ví dụ: khi người dùng x (đã hết tài khoản trong Alpha và tài khoản hợp lệ trong Beta), nhật ký lỗi Apache báo cáo như sau:

[Tue May 11 13:42:07 2010] [debug] mod_authnz_ldap.c(377): [client 10.1.1.104] [14817] auth_ldap authenticate: using URL ldap://dc01.alpha:3268/?sAMAccountName?sub?
[Tue May 11 13:42:08 2010] [warn] [client 10.1.1.104] [14817] auth_ldap authenticate: user x authentication failed; URI /svn/ [ldap_simple_bind_s() to check user credentials failed][Invalid credentials]
[Tue May 11 13:42:08 2010] [error] [client 10.1.1.104] user x: authentication failure for "/svn/": Password Mismatch
[Tue May 11 13:42:08 2010] [debug] mod_deflate.c(615): [client 10.1.1.104] Zlib: Compressed 527 to 359 : URL /svn/

Cố gắng xác thực là người dùng không tồn tại (nonecool) dẫn đến hành vi truy vấn chính xác cả hai máy chủ LDAP:

[Tue May 11 13:42:40 2010] [debug] mod_authnz_ldap.c(377): [client 10.1.1.104] [14815] auth_ldap authenticate: using URL ldap://dc01.alpha:3268/?sAMAccountName?sub?
[Tue May 11 13:42:40 2010] [warn] [client 10.1.1.104] [14815] auth_ldap authenticate: user nobodycool authentication failed; URI /svn/ [User not found][No such object]
[Tue May 11 13:42:40 2010] [debug] mod_authnz_ldap.c(377): [client 10.1.1.104] [14815] auth_ldap authenticate: using URL ldap://ldap.beta:3268/?sAMAccountName?sub?
[Tue May 11 13:42:44 2010] [warn] [client 10.1.1.104] [14815] auth_ldap authenticate: user nobodycool authentication failed; URI /svn/ [User not found][No such object]
[Tue May 11 13:42:44 2010] [error] [client 10.1.1.104] user nobodycool not found: /svn/
[Tue May 11 13:42:44 2010] [debug] mod_deflate.c(615): [client 10.1.1.104] Zlib: Compressed 527 to 359 : URL /svn/

Làm cách nào để định cấu hình Apache để truy vấn Beta chính xác nếu nó gặp tài khoản đã hết hạn trong Alpha?

Câu trả lời:


4

Lệnh AuthzLDAPAuthoritative offsẽ cho phép xác thực rơi vào mô-đun tiếp theo chỉ khi người dùng không thể khớp với một DN trong truy vấn. Hiện tại mặc dù người dùng đã hết hạn, có vẻ như tài khoản của họ vẫn sẽ được trả về do kết quả khi truy vấn LDAP được thực hiện.

Tôi không biết đủ về lược đồ LDAP của ActiveDirectory để đưa ra câu trả lời chắc chắn ở đây, nhưng nếu bạn có thể thêm bộ lọc vào lệnh của mình AuthLDAPURLđể lọc ra các tài khoản đã hết hạn thì sẽ dẫn đến tên người dùng không khớp với bất kỳ DN nào trong truy vấn. Điều này sẽ dẫn đến việc xác thực rơi vào mô-đun tiếp theo.


1
Thêm một bộ lọc làm việc. CNTT đã đủ tử tế để đặt một chuỗi nhất quán trong trường mô tả của những người dùng đã được chuyển từ Alpha sang Beta (đây là lý do tại sao các tài khoản đã hết hạn). URL sau hoạt động chính xác: AuthLDAPURL ldap: //dc01.alpha:?? 3268 / sAMAccountName phụ (! & (ObjectClass = user) ((description = * chuyển-to-Beta *)))
Brian Bassett
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.