Thiết lập RADIUS + LDAP cho WPA2 trên Ubuntu


16

Tôi đang thiết lập một mạng không dây cho ~ 150 người dùng. Nói tóm lại, tôi đang tìm một hướng dẫn để đặt máy chủ RADIUS xác thực WPA2 dựa trên LDAP. Trên Ubuntu.

  • Tôi đã có một LDAP hoạt động, nhưng vì nó không được sử dụng trong sản xuất, nên nó có thể dễ dàng thích nghi với mọi thay đổi mà dự án này có thể yêu cầu.
  • Tôi đã xem FreeRADIUS, nhưng bất kỳ máy chủ RADIUS nào cũng được.
  • Chúng tôi có một mạng vật lý riêng chỉ dành cho WiFi, vì vậy không có quá nhiều lo lắng về bảo mật trên mặt trận đó.
  • AP của chúng tôi là những thứ dành cho doanh nghiệp cấp thấp của HP - họ dường như hỗ trợ bất cứ điều gì bạn có thể nghĩ tới.
  • Tất cả máy chủ Ubuntu, em yêu!

Và tin xấu:

  • Bây giờ tôi có người ít hiểu biết hơn tôi cuối cùng sẽ nắm quyền quản trị, vì vậy việc thiết lập phải "tầm thường" nhất có thể.
  • Cho đến nay, thiết lập của chúng tôi chỉ dựa trên phần mềm từ kho Ubuntu, ngoại trừ ứng dụng web quản trị LDAP của chúng tôi và một vài tập lệnh đặc biệt nhỏ. Vì vậy, không có "tìm nạp gói X, cho đến khi, ./có hình" nếu có thể tránh được.

CẬP NHẬT 2009-08-18:

Trong khi tôi tìm thấy một số tài nguyên hữu ích, có một trở ngại nghiêm trọng:

Ignoring EAP-Type/tls because we do not have OpenSSL support.
Ignoring EAP-Type/ttls because we do not have OpenSSL support.
Ignoring EAP-Type/peap because we do not have OpenSSL support.

Về cơ bản, phiên bản Ubuntu của FreeRADIUS không hỗ trợ SSL ( lỗi 183840 ), điều này làm cho tất cả các loại EAP an toàn trở nên vô dụng. Bummer.

Nhưng một số tài liệu hữu ích cho bất cứ ai quan tâm:

CẬP NHẬT 2009-08-19:

Tôi đã kết thúc việc biên soạn gói FreeRADIUS của riêng mình vào tối hôm qua - có một công thức thực sự tốt tại http://www.linuxinsight.com/building-debian-freeradius-package-with-eap-tls-ttls-peap-support.html (Xem các ý kiến ​​cho bài viết để được hướng dẫn cập nhật).

Tôi đã nhận được chứng chỉ từ http://CACert.org (có lẽ bạn sẽ nhận được chứng chỉ "thực" nếu có thể)

Sau đó, tôi đã làm theo các hướng dẫn tại http://vuksan.com/linux/dot1x/802-1x-LDAP.html . Liên kết này đến http://tldp.org/HOWTO/html_single/8021X-HOWTO/ , đây là một bài đọc rất đáng giá nếu bạn muốn biết cách bảo mật WiFi hoạt động.

CẬP NHẬT 2009-08-27:

Sau khi làm theo hướng dẫn ở trên, tôi đã có được FreeRADIUS để nói chuyện với LDAP:

Tôi đã tạo một người dùng thử nghiệm trong LDAP, bằng mật khẩu mr2Yx36M- điều này mang lại một mục nhập LDAP khoảng:

uid: testuser
sambaLMPassword: CF3D6F8A92967E0FE72C57EF50F76A05
sambaNTPassword: DA44187ECA97B7C14A22F29F52BEBD90
userPassword: {SSHA}Z0SwaKO5tuGxgxtceRDjiDGFy6bRL6ja

Khi sử dụng radtest, tôi có thể kết nối tốt:

> radtest testuser "mr2Yx36N" sbhr.dk 0 radius-private-password
Sending Access-Request of id 215 to 130.225.235.6 port 1812
    User-Name = "msiebuhr"
    User-Password = "mr2Yx36N"
    NAS-IP-Address = 127.0.1.1
    NAS-Port = 0
rad_recv: Access-Accept packet from host 130.225.235.6 port 1812, id=215, length=20
> 

Nhưng khi tôi thử qua AP, nó không bay - trong khi nó xác nhận rằng nó tìm ra mật khẩu NT và LM:

...
rlm_ldap: sambaNTPassword -> NT-Password == 0x4441343431383745434139374237433134413232463239463532424542443930
rlm_ldap: sambaLMPassword -> LM-Password == 0x4346334436463841393239363745304645373243353745463530463736413035
[ldap] looking for reply items in directory...
WARNING: No "known good" password was found in LDAP.  Are you sure that the user is configured correctly?
[ldap] user testuser authorized to use remote access
rlm_ldap: ldap_release_conn: Release Id: 0
++[ldap] returns ok
++[expiration] returns noop
++[logintime] returns noop
[pap] Normalizing NT-Password from hex encoding
[pap] Normalizing LM-Password from hex encoding
...

Rõ ràng là mật khẩu NT và LM khác với ở trên, nhưng thông báo [ldap] user testuser authorized to use remote access- và người dùng sau đó bị từ chối ...


Mật khẩu NT và LM được lưu trữ được mã hóa, vì vậy không rõ liệu chúng có khác nhau hay không. Bạn cần xác định mật khẩu nào đang được AP sử dụng và nếu mật khẩu được thông qua rõ ràng, MD5 đã được truyền vào đúng vị trí của nó, hoặc ... một cái gì đó khác. Máy khách RADIUS có thể sử dụng bất kỳ số lượng thuộc tính RADIUS nào để xác thực mật khẩu hoặc mật khẩu. Ngoài ra, hãy thử điền vào thuộc tính hết hạn.
kmarsh

Câu trả lời:


12

Tôi sẽ cố gắng trả lời câu hỏi LDAP ở đây.

Đây là câu trả lời ngắn: đảm bảo ldapmô-đun được xóa khỏi authenticatephần và đảm bảo mschapmô-đun có mặt trong cả phần authorizeauthenticatephần. Và chỉ cần bỏ qua mật khẩu 'Không biết "tốt".

Và bây giờ đây là câu trả lời (rất) dài.

Làm thế nào để mô-đun ldap hoạt động?

Khi bạn kích hoạt ldapmô-đun trong authorizephần, đây là những gì nó làm khi gói RADIUS được FreeRADIUS nhận được:

  1. nó cố gắng liên kết với máy chủ LDAP (với tư cách là người dùng khách hoặc sử dụng danh tính đã cho nếu được định cấu hình ldap.conf)
  2. nó tìm kiếm mục nhập DN của người dùng bằng bộ lọc trong DN cơ sở (được định cấu hình trong ldap.conf).
  3. nó tìm nạp tất cả các thuộc tính LDAP mà nó có thể nhận được trong số các thuộc tính được định cấu hình ldap.attrmapvà chuyển đổi chúng thành các thuộc tính RADIUS.
  4. nó thêm các thuộc tính đó vào danh sách các mục kiểm tra của gói RADIUS.

Khi bạn kích hoạt ldapmô-đun trong authenticatephần, đây là những gì FreeRADIUS làm:

  1. nó cố gắng liên kết với máy chủ LDAP với tư cách là người dùng .
  2. nếu nó có thể liên kết, thì đó là một xác thực thành công và một Radius-Acceptgói sẽ được gửi lại cho máy khách, hoặc nếu không, đó là một thất bại, dẫn đến một Radius-Rejectgói.

Vậy làm cách nào tôi có thể định cấu hình FreeRADIUS để làm cho PEAP / MS-CHAP-v2 hoạt động với LDAP?

Điểm quan trọng ở đây là ràng buộc vì người dùng sẽ chỉ hoạt động nếu máy chủ FreeRADIUS có thể truy xuất mật khẩu Cleartext của người dùng từ gói RADIUS mà họ nhận được. Đây chỉ là trường hợp khi các phương thức xác thực PAP hoặc TTLS / PAP được sử dụng (và có thể cả EAP / GTC). Chỉ có phương pháp TTLS / PAP là thực sự an toàn và nó không có sẵn theo mặc định trong Windows. Nếu bạn muốn người dùng của mình kết nối với TTLS / PAP, bạn cần yêu cầu họ cài đặt phần mềm thay thế TTLS, điều này hiếm khi là một tùy chọn. Hầu hết thời gian, khi triển khai WiFi với WPA Enterprise securiy, PEAP / MS-CHAP-v2 là lựa chọn hợp lý duy nhất.

Vì vậy, điểm mấu chốt là: trừ khi bạn đang sử dụng PAP hoặc TTLS / PAP, bạn có thể gỡ bỏ ldapmô-đun khỏi authenticatephần một cách an toàn và thực tế, bạn nên: ràng buộc vì người dùng sẽ không hoạt động.

Nếu thử nghiệm của bạn hoạt động khi bạn sử dụng radtest, điều đó có thể có nghĩa là ldapmô-đun được kích hoạt trong authenticatephần: nó sẽ cố gắng liên kết với tư cách người dùng và vì radtest sử dụng xác thực PAP, nên nó sẽ thành công. Nhưng nó sẽ thất bại nếu bạn cố gắng kết nối thông qua điểm truy cập, vì bạn đang sử dụng PEAP / MS-CHAP-v2.

Những gì bạn nên làm là loại bỏ ldapmô-đun khỏi authenticatephần này và đảm bảo bạn kích hoạt mschapmô-đun trong cả phần authorizeauthenticatephần. Điều sẽ xảy ra là mschapmô-đun sẽ đảm nhiệm việc xác thực bằng cách sử dụng NT-Passwordthuộc tính được lấy từ máy chủ LDAP trong authorizegiai đoạn.

Đây là những gì sites-enabled/defaulttập tin của bạn sẽ trông như thế nào (không có tất cả các ý kiến):

    ...
    authorize {
        preprocess
        suffix
        eap {
            ok = return
        }
        expiration
        logintime
    }
    authenticate {
        eap
    }
    ...

Và đây là sites-enabled/inner-tunneltập tin của bạn sẽ như thế nào:

    ...
    authorize {
        mschap
        suffix
        update control {
               Proxy-To-Realm := LOCAL
        }
        eap {
            ok = return
        }
        ldap
        expiration
        logintime
    }
    authenticate {
        Auth-Type MS-CHAP {
            mschap
        }
        eap
    }
    ...

Điều gì về cảnh báo 'Không biết "mật khẩu"?

Vâng, bạn có thể yên tâm bỏ qua nó. Nó chỉ ở đó bởi vì ldapmô-đun không thể tìm thấy một UserPasswordthuộc tính khi nó tìm nạp các chi tiết người dùng từ máy chủ LDAP trong authorizegiai đoạn. Trong trường hợp của bạn, bạn có NT-Passwordthuộc tính và điều đó hoàn toàn tốt để PEAP/MS-CHAP-v2xác thực.

Tôi đoán cảnh báo tồn tại bởi vì khi ldapmô-đun được thiết kế, PEAP/MS-CHAP-v2chưa tồn tại, do đó, điều duy nhất có vẻ hợp lý tại thời điểm đó là truy xuất thuộc tính UserPassword từ máy chủ LDAP, để sử dụng PAP, CHAP, EAP / MD5 hoặc các phương thức xác thực như vậy.


3

Tôi sẽ cố gắng trả lời câu hỏi OpenSSL tại đây: câu trả lời ngắn gọn là sử dụng FreeRADIUS 2.1.8 trở lên, bao gồm OpenSSL . Nó có sẵn trong các bản sao lưu Ubuntu Lucid và Debian Lenny (và có lẽ cũng sẽ có trong các bản sao lưu Ubuntu Karmic).

Đây là câu trả lời dài:

Thật không may, giấy phép OpenSSL từng không tương thích với giấy phép FreeRADIUS. Do đó, người Ubuntu đã chọn cung cấp nhị phân FreeRADIUS không được liên kết với OpenSSL. Nếu bạn muốn EAP / TLS, PEAP hoặc TTLS, bạn phải lấy các nguồn và biên dịch chúng với --with-openssltùy chọn (như công thức bạn đã sử dụng giải thích).

Nhưng gần đây, vấn đề cấp phép đã được khắc phục . Phiên bản FreeRADIUS 2.1.8 trở lên có thể được biên dịch và phân phối với OpenSSL. Tin xấu là bản phân phối Ubuntu ổn định gần đây nhất (Karmic Koala) chỉ bao gồm FreeRADIUS 2.1.0, không có OpenSSL (tương tự với Debian, vì Lenny chỉ chứa FreeRADIUS 2.0.4). Tôi đã kiểm tra các bản sao Karmic, nhưng có vẻ như FreeRADIUS 2.1.8 trở lên chưa được tải lên ở đó (nhưng nó có thể được thêm sớm, kiểm tra xem tại đây). Vì vậy, hiện tại, bạn phải chuyển sang Ubuntu Lucid (bao gồm FreeRADIUS 2.1.8) hoặc gắn bó với việc biên dịch. Đối với người dùng Debian, mọi thứ sáng sủa hơn một chút: các bản sao Lenny bao gồm FreeRADIUS 2.1.8. Vì vậy, nếu bạn muốn một cái gì đó rất ổn định, dễ cài đặt và bảo trì, tôi khuyên bạn nên triển khai một máy chủ với Debian Lenny và cài đặt gói FreeRADIUS được backport (nó cũng cung cấp cho bạn khả năng viết các mô-đun python miễn phí, mà không phải biên dịch lại với tất cả các mô-đun thử nghiệm).

Tôi đã nhận được chứng chỉ từ http://CACert.org (có lẽ bạn sẽ nhận được chứng chỉ "thực" nếu có thể)

Có một "gotcha" với chứng chỉ "thực" (trái ngược với chứng chỉ tự ký).

Tôi đã sử dụng một chữ ký của Thawte. Nó hoạt động tốt và người dùng thấy một chứng chỉ "hợp lệ" đẹp có tên như thế www.my-web-site.com. Khi người dùng chấp nhận chứng chỉ, máy tính của anh ta thực sự hiểu rằng tất cả các chứng chỉ được cấp bởi cùng một tổ chức chứng nhận nên được tin cậy (tôi đã thử nghiệm điều này với Windows Vista và MacOSX Snow Leopard)! Vì vậy, trong trường hợp của tôi, nếu một hacker có chứng chỉ www.some-other-web-site.com, cũng được ký bởi Thawte, thì anh ta có thể dễ dàng thực hiện một cuộc tấn công Man-in-the-middle một cách dễ dàng mà không có bất kỳ cảnh báo nào được hiển thị trên máy tính của người dùng!

Giải pháp cho vấn đề này nằm sâu trong cấu hình mạng của máy tính người dùng, để chỉ định cụ thể rằng chỉ nên tin tưởng "www.my-web-site.com". Chỉ mất một phút, nhưng hầu hết người dùng sẽ không biết cách định cấu hình này trừ khi bạn cung cấp cho họ quy trình rõ ràng và đảm bảo mọi người dùng đều tuân theo. Tôi vẫn sử dụng chứng chỉ "hợp lệ", nhưng thật lòng, thật đáng thất vọng khi thấy cả Windows và MacOSX đều chia sẻ "lỗi" này: tin tưởng vào Tổ chức phát hành chứng chỉ thay vì chứng chỉ cụ thể. Ôi ...


1

Theo báo cáo lỗi, việc xây dựng lại FreeRADIUS đơn giản sẽ khắc phục vấn đề hỗ trợ OpenSSH. Nó chỉ cần được thực hiện một lần.

Tôi không chắc quản trị có dễ dàng gì khi cài đặt. Thông thường, thiết lập càng liên quan và chi tiết, càng dễ quản trị, bởi vì thiết lập bao gồm tất cả các cơ sở. Bạn có nghĩa là cấu hình phải được loại bỏ trên các máy chủ khác một cách dễ dàng không? Bạn đang thiết lập bao nhiêu mạng LAN không dây?

Sau khi được cấu hình, Quản trị nên được giới hạn đối với người dùng LDAP thêm, xóa và sửa đổi. Chúng phải đủ dễ để tạo tập lệnh với ldapmodify (et al) hoặc tìm một giao diện đồ họa LDAP phong nha và ghi lại các quy trình bằng ảnh chụp màn hình.


Trước tiên, bạn phải biên dịch lại gói mỗi khi có bản cập nhật (ghen tị với Gentoo-folks ở đây :)). Về các phần khác, tôi hoàn toàn đồng ý - nếu thiết lập bao gồm tất cả các cơ sở, người kế nhiệm của tôi sẽ có ít việc phải làm hơn (và ít hack hơn cho kỹ sư đảo ngược).
Morten Siebuhr

0

Tôi gặp vấn đề tương tự. Tôi đã phải tải xuống các nguồn RADIUS và tự biên dịch chúng.


-1

Bạn có thể sử dụng FreeRADIUS2 (với OpenSSL) + EAP-TLS + WPA2-Enterprice. Đây là wery ditails CÁCH-TO . Windows XP SP3 có hỗ trợ riêng cho nó cũng như Windows 7, Android 2.3, iPhone, Symbian. Nhưng tôi không biết về khả năng tương thích với SLDAP trong một sơ đồ như vậy.

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.