OpenLDAP, Samba và lão hóa mật khẩu

Tôi đang định cấu hình một hệ thống trong đó tất cả các tài nguyên CNTT có sẵn thông qua một cặp mật khẩu người dùng duy nhất, có thể truy cập shell trên các máy chủ, đăng nhập vào miền Samba, WiFi, OpenVPN, Mantis, v.v. (có quyền truy cập vào các dịch vụ cụ thể được quản lý theo thành viên nhóm hoặc các trường đối tượng người dùng). Vì chúng tôi có dữ liệu cá nhân trong mạng của mình, chúng tôi cần thực hiện lão hóa mật khẩu, theo Chỉ thị bảo vệ dữ liệu của EU (hay đúng hơn là phiên bản tiếng Ba Lan của nó).

Vấn đề là tài khoản Samba và POSIX trong LDAP sử dụng thông tin băm mật khẩu và lão hóa khác nhau. Mặc dù tự đồng bộ hóa mật khẩu rất dễ dàng (việc ldap password sync = Yesnhập smb.conf), việc thêm lão hóa mật khẩu vào hỗn hợp sẽ phá vỡ mọi thứ: Samba không cập nhật ShadowLastChange. Cùng với việc obey pam restrictions = Yestạo một hệ thống trong đó người dùng windows không thể thay đổi mật khẩu cũ, nhưng nếu tôi không sử dụng nó, các thư mục chính sẽ không được tạo tự động. Cách khác là sử dụng thao tác mở rộng LDAP để thay đổi mật khẩu, nhưng smbk5pwdmô-đun cũng không đặt. Tệ hơn nữa, người bảo trì OpenLDAP sẽ không cập nhật nó / chấp nhận các bản vá vì trường này được coi là không dùng nữa.

Vì vậy, câu hỏi của tôi là, giải pháp tốt nhất là gì? Những mặt trái và mặt trái của chúng là gì?

1. Sử dụng LDAP ppolicyvà lão hóa mật khẩu LDAP nội bộ?

   1. Nó hoạt động tốt như thế nào với các mô-đun NSS, PAM, samba, các hệ thống khác?
   2. Các mô-đun NSS và PAM có cần phải được cấu hình theo cách đặc biệt để sử dụng ppolicy chứ không phải bóng không?
   3. Liệu GOsa² làm việc với ppolicy?
   4. Có công cụ quản trị nào khác có thể hoạt động với ppolicyLDAP đã bật không?

2. Hack cùng một tập lệnh thay đổi mật khẩu cập nhật trường trong LDAP. (để lại khả năng chính người dùng sẽ cập nhật trường mà không thay đổi mật khẩu)

Tôi đã viết lớp phủ OpenLDAP của riêng mình được gọi shadowlastchangeđể cập nhật shadowLastChangethuộc tính mỗi khi xảy ra thay đổi mật khẩu EXOP. Nó được kích hoạt trong slapd.conf:

moduleload smbk5pwd
moduleload shadowlastchange
...

database bdb
...
overlay smbk5pwd
overlay shadowlastchange

Tôi đã cấu hình smb.confđể thay đổi mật khẩu thông qua EXOP:

ldap passwd sync = Only

Sau đó, đối với mỗi tài khoản, được đặt thành shadowMaxsố ngày mật khẩu hợp lệ. Các mô-đun OpenLDAP chăm sóc phần còn lại!

Như một khoảng trống tôi đã tạo tập lệnh cho Samba sẽ cập nhật shadowLastChangethay đổi mật khẩu:

#!/bin/sh
# script to update shadowLastChange when samba updates passwords
# it's not needed when using 'passwd', it does update the field,
# even if pam_ldap is using LDAP Extented Operation to change password

LDAP_MODIFY="/usr/bin/ldapmodify"
LDAP_SEARCH="/usr/bin/ldapsearch"
LDAP_USER="uid=shadow-update,ou=Services,dc=example,dc=com"
LDAP_PASSWORD="change-me"
LDAP_HOST="localhost"

# get date
SLC=$((`date '+%s'` / 24 / 3600))

# get user login name
user=$1

# find user's DN
dn=$($LDAP_SEARCH -x -h $LDAP_HOST -LLL -b dc=example,dc=com "(uid=$user)" dn)
dn=${dn#dn:}

# check if DN is not base64 encoded
if [ "${dn:0:1}" = ":" ]; then
        # update password change date
        echo "dn:$dn
changetype: modify
replace: shadowLastChange
shadowLastChange: $SLC" | cat | $LDAP_MODIFY -x -h "$LDAP_HOST" \
 -D "$LDAP_USER" -w "$LDAP_PASSWORD" > /dev/null 2>&1
else
        # update password change date
        echo "dn: $dn
changetype: modify
replace: shadowLastChange
shadowLastChange: $SLC" | cat | $LDAP_MODIFY -x -h "$LDAP_HOST" \
 -D "$LDAP_USER" -w "$LDAP_PASSWORD" > /dev/null 2>&1
fi

err=$?

if [ ! $err -eq 0 ]; then
   echo "error: can't update shadowLastChange: $err"
   echo "`date`: shadow.sh: can't update shadowLastChange: $err"\
       >> /var/log/shadow-update.log
   exit;
fi

echo OK

Trong cấu hình Samba, nó cần unix password syncđược đặt thành yes, passwd chatđược đặt thành *OK*và passwd programở trên tập lệnh với "%u"tham số là param.

Một tài khoản được chỉ định LDAP_USERcần phải được tạo trong LDAP và được cấp quyền đọc trên uidtất cả người dùng Samba và quyền viết shadowLastChange.

(công việc đang tiến hành, tôi sẽ thêm chi tiết sau)

Tin vui nhé mọi người! Tôi đã làm toàn bộ công việc, ít nhiều ..., trong môi trường thử nghiệm ...:

1. Chính sách mật khẩu (cả chất lượng và thời gian khôn ngoan) được thi hành trên mức OpenLDAP (nhờ ppolicy, not24getvà passwdqc)
2. Mật khẩu được đồng bộ hóa giữa Samba và POSIX theo cả hai cách (nhờ smbk5pwd). Lưu ý: Việc kiểm tra chất lượng với Samba và ppolicy là không rõ ràng: password check script( pwqcheck -1từ passwdqc) cần thực hiện kiểm tra tương tự LDAP hoặc người dùng sẽ nhận được Quyền từ chối thay vì "Mật khẩu quá dễ dàng, hãy thử khác nhau".
3. Cả PAM và Samba đều cảnh báo người dùng rằng mật khẩu sẽ sớm hết hạn.
4. Thư mục người dùng được tạo bằngpam_mkhomedir
5. GOsa² triển khai RFC2307bis (và lược đồ được liên kết) chèn uidvào các mục nhập nhóm, vì vậy các ứng dụng mong đợi NIS (hầu hết các công cụ "UNIXy") hoặc lược đồ RFC2307bis (hầu hết các ứng dụng "được thiết kế cho AD") đều hoạt động tốt.

Vấn đề duy nhất là việc vô hiệu hóa tài khoản yêu cầu sử dụng các công cụ CLI (hoặc viết tập lệnh postmodify GOsa) hoặc tài khoản sẽ không bị khóa ở cấp LDAP, chỉ dành cho PAM và Samba. Việc hết hạn mật khẩu sẽ vẫn được thực thi, vì vậy đây không phải là vấn đề lớn.

Tôi đã có câu trả lời từ một trong những nhà phát triển GOsa. Tại thời điểm này, GOsa không hỗ trợ lớp phủ ppolicy theo bất kỳ cách nào.