Có * ai * có Windows SVNServe xác thực với AD/Kerberos qua SASL/GSSAPI không?

Question

Kịch bản: Máy chủ Windows trong miền AD lưu trữ một kho lưu trữ Subversion chỉ sử dụng SVNSERVE (không có Apache) và không VisualSVN.

Mục tiêu: Xác thực người dùng vào kho lưu trữ Subversion qua SASL thông qua GSSAPI đến miền Windows qua Kerberos.

Đăng thường xuyên ở nhiều trang web cho biết người dùng thường xuyên chết trong cấu hình này với "Không thể lấy danh sách các cơ chế SASL". Tôi đã không nhìn thấy bất kỳ trường hợp nơi này thực sự đang chạy. Có ai có hoạt động này không?

Tôi đặt câu hỏi này là kết quả của bài đăng trong diễn đàn Gentoo, trong đó một người nào đó trong kịch bản chính xác này xem xét các tệp nguồn có liên quan và kết luận rằng trong khi đó, một cấu hình có thể hoạt động, vì nó không còn trong nguồn.

GEntoo forum discussion where poster claims svnserve+gssapi+sasl worked at one time, but no longer does.

Bây giờ, tôi không khẳng định tuyên bố rằng là chính xác, nhưng tôi biết tôi đang bị mắc kẹt tại một cách chính xác cùng một điểm, và tôi đã chưa thấy bất kỳ bài viết rằng tuyên bố "chiến thắng" trên một thiết lập như vậy. Nếu bạn có, xin vui lòng tư vấn chi tiết!

Rất cám ơn trước.

Answer 1

Sau khi giành được huy hiệu "tumbleweed" cho câu hỏi chưa được trả lời này và nghiên cứu bổ sung đáng kể của riêng tôi, tôi đã đi đến kết luận rằng sự kết hợp chủ đề cho Subversion trong Windows, trên thực tế, không thể theo mã hiện tại căn cứ. Tôi tin rằng một cái gì đó trong lớp xác thực SASL là vấn đề ở đây, với một số nguồn bị loại bỏ hoặc thay đổi đáng kể để "phá vỡ" những gì đã làm, tôi tin rằng, làm việc tại một thời điểm.

Giải pháp của tôi là thêm Apache vào danh sách kết hợp với mod_auth_sspi và trong khi nó làm chậm lưu trữ một số, xác thực hoạt động hoàn hảo. Điều này dường như là "sửa lỗi" cho yêu cầu xác thực.

Answer 2

Tôi đã thực hiện xác thực đối với AD với SASL + LDAP, nhưng không phải là SASL + GSSAPI và với một cảnh báo nhỏ: Tôi phải sử dụng và chạy svnserve từ Cygwin trong Windows.

1) Thật dễ dàng để có được người dùng xác thực svnserve thông qua SASL + LDAP/AD trong Linux (tôi biết câu hỏi là về svnserve trong Windows, nhưng chịu đựng với tôi). Phần quan trọng để có được xác thực làm việc với LDAP/AD là saslauthd và kiểm tra xác thực bằng cách sử dụng testsaslauthd.

Sử dụng Ubuntu như một ví dụ:

1a) /etc/sasl2/svn.conf

pwcheck_method: saslauthd 
mech_list: PLAIN 

này cho lật đổ/svnserve sử dụng saslauthd để làm chứng thực trên danh nghĩa của nó.

1b) /etc/saslauthd.conf

ldap_servers: ldap://yourADserver.dept.org 
ldap_search_base: DC=dept,DC=org 
ldap_bind_dn: cn=bindaccount,dc=dept,dc=org 
ldap_bind_pw: passwordOfbindaccount 

ldap_deref: never 
ldap_restart: yes 
ldap_scope: sub 
ldap_use_sasl: no 
ldap_start_tls: no 
ldap_version: 3 
ldap_auth_method: bind 
ldap_filter: sAMAccountName=%u 
ldap_password_attr: userPassword 
ldap_timeout: 10 
ldap_cache_ttl: 5 
ldap_cache_mem: 32768 

1c) Thực hiện kiểm tra qua testsaslauthd

testsaslauthd -u myusername -p mypassword 

1d) Nếu thành công, sau đó chạy saslauthd, và bắt đầu svnserve. và sử dụng bất kỳ ứng dụng khách svn nào để kiểm tra xác thực.

2) Vấn đề là, không có cổng gốc của Cyrus 'saslauthd với Windows, và có lẽ sẽ không bao giờ xảy ra. Câu trả lời là sử dụng Cygwin, có svnserve, testsaslauthd và saslauthd.

Chỉ cần lặp lại các bước trên .. nhưng vị trí của svn.conf có thể khác.

Answer 3

Tôi vừa quản lý (sau gần 30 giờ trầy xước đầu, biên dịch và gỡ lỗi mã nguồn để nhận mã lỗi phong nha) để nhận svnserve + SASL + GSSAPI hoạt động! Thiết lập của tôi như sau:

• Máy chủ AD là Samba 4.1.0 trên Debian 7.2 (được xây dựng từ nguồn).
• Máy chủ lật đổ là lật đổ 1.8.5 trên Solaris Express (SunOS 5.11 snv_151a i86pc i386 i86pc). Được xây dựng cho x64 từ nguồn sử dụng bản địa (Sun) SASL.
• Khách hàng là Windows 7 x64 với TortoiseSVN 1.8.2 (bản phát hành nhị phân x64) và Heimdal 1.5.1 (x64 nhị phân từ điểm cuối an toàn).
• Như với bất cứ điều gì liên quan đến Kerberos, bạn cần phải có về phía trước và ngược DNS làm việc trơn tru, đồng hồ đồng bộ vv

bước vào một hộp Windows với creds miền:

• Tạo một "svnserve "tài khoản người dùng (không phải tài khoản máy tính) cho máy chủ Subversion.
• Chạy "ktpass -princ svn/server.domain.local@DOMAIN.LOCAL -mapuser DOMAIN.LOCAL \ svnserve -crypto Mật khẩu RC4-HMAC-NT -pass -ptype KRB5_NT_PRINCIPAL -out svnserve.keytab". Bạn làm không phải muốn bật DES cho tài khoản này hoặc Windows 7 sẽ từ chối xác thực cho tài khoản đó. Tôi bật nó lên trên (sau công thức nấu ăn) và phải tắt nó lần nữa để nó hoạt động.

bước cho máy chủ Subversion:

• Thiết lập /etc/krb5/krb5.conf

  [libdefaults] 
      default_realm = DOMAIN.LOCAL 
  
  [realms] 
      DOMAIN.LOCAL = { 
       kdc = pdc.domain.local 
       admin_server = pdc.domain.local 
      } 
  
  [domain_realm] 
      .domain.local = DOMAIN.LOCAL 
      domain.local = DOMAIN.LOCAL 
  
  # Other defaults left as-is. 
  

• Thiết lập repo/conf/svnserve.conf:

  [general] 
  anon-access = none 
  authz-db = authz 
  realm = DOMAIN.LOCAL 
  
  [sasl] 
  use-sasl = true 
  min-encryption = 0 
  max-encryption = 256 
  

• Thiết lập repo/conf/authz: ​​

  [aliases] 
  
  [groups] 
  
  [/] 
  * = 
  # Still investigating whether access to the server can be controlled through an AD group. 
  # Below is for user@DOMAIN.LOCAL, the realm appears to get lost. 
  user = rw 
  

• Thiết lập /etc/sasl/svn.conf:

  mech_list: GSSAPI 
  

• Drop svnserve.keytab để /etc/krb5/krb5.keytab (keytab trong cấu hình SASL không dường như làm bất cứ điều gì).

• Bắt đầu svnserve.

bước cho khách hàng:

• Cài đặt TortoiseSVN và Heimdal.
• Chỉnh sửa C: \ ProgramData \ Kerberos \ krb5.conf thành /etc/krb5/krb5.conf trên máy chủ Subversion.Có một số mặc định khác trong đó mà tôi để lại một mình.
• Thực hiện thanh toán, không cần mật khẩu!

Một vấn đề với quy trình này là quy trình svnserve phải có khả năng đọc /etc/krb5/krb5.keytab, vì vậy các quyền trên đó cần phải được khắc phục một chút. svnserve đang đi vào khu vực riêng của mình mặc dù vậy đây không phải là một vấn đề đối với tôi. Tôi cũng đã bị lỗi mslsa_cc.dll trong khi kiểm tra mọi thứ, nhưng tôi đã không thấy bất kỳ sự cố nào khi tôi đã sắp xếp mọi thứ.

Với một số tranh cãi, bạn cũng có thể làm việc này cho svnserve trên Windows. Tôi đã thử MIT Kerberos trên máy khách Windows nhưng nó bị hỏng mỗi khi khởi động nên tôi đã từ bỏ nó. Bạn có thể có may mắn hơn.

Cập nhật: Đã tìm ra sự cố lỗi - đó là lỗi trong mslsa_cc.dll (tương tự như https://github.com/krb5/krb5/commit/7acb524f5aa00274771dbbfac19d2dd779aad409, cũng bị sai một chút vì nOutStringLen cần được chia cho 2 theo cách mà ANSIToUnicode được gọi). vá nhị phân trên mslsa_cc.dll là:

• offset 0xB46: Thay đổi từ FF 15 04 69 00 đến D1 EE 0F 1F 40.
• offset 0xB5E: Thay đổi từ 77 đến EB.