Я развернул AADDS в своем домене AzureAD.
Я изменил пароли пользователей для создания начального хэша синхронизации.
Я создал виртуальную машину FreeRADIUS под Ubuntu 18.04 LTS, способную подключаться через LDAP внутри подсети ADDDS с пользователем из группы «Администраторы AAD DC».
Я настроил беспроводную сеть Ubiquiti Uni-Fi UAP nanoHD WPA2 Enterprise с профилем RADIUS для аутентификации с виртуальной машиной FreeRADIUS.
Тестирование входа по Wi-Fi с iPhone XR и ноутбуком с Windows 10.
Первоначальная аутентификация LDAP для привязки прошла успешно.
Пользователь успешно найден в каталоге.
Пользовательские атрибуты обрабатываются с предупреждениями.
(2) ldap: Processing user attributes
(2) ldap: WARNING: No "known good" password added. Ensure the admin user has permission to read the password attribute
(2) ldap: WARNING: PAP authentication will *NOT* work with Active Directory (if that is what you were trying to configure)
Аутентификация не удалась, так как нет доступного сопоставленного атрибута «User-Password».
(2) [ldap] = ok
(2) if ((ok || updated) && User-Password) {
(2) if ((ok || updated) && User-Password) -> FALSE
(2) [expiration] = noop
(2) [logintime] = noop
(2) } # authorize = ok
(2) ERROR: No Auth-Type found: rejecting the user via Post-Auth-Type = Reject
(2) Failed to authenticate the user
Я исследовал и попробовал следующее.
"ntlm_auth" в настоящее время невозможен из-за ограничений Samba (только для файлов Azure).
Изменение значения «dsHeuristics» в настройках Active Directory для включения атрибута «userPassword» невозможно из-за ограничений разрешений AADDS.
***Call Modify...
ldap_modify_s(ld, 'CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=example,DC=com',[1] attrs);
Error: Modify: Insufficient Rights. <50>
Server error: 00002098: SecErr: DSID-03150E49, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0
Error 0x2098 Insufficient access rights to perform the operation.
Мои настройки точно такие, как показано на https://stackoverflow.com/a/55931232/5163441.
Этот человек утверждает, что это работает так же, как и для него, поэтому он находит атрибут для сравнения пароля.
Я не вижу никакого соответствующего атрибута, который я мог бы использовать для аутентификации.
Dn: CN=John Smith,OU=AADDC Users,DC=example,DC=com
accountExpires: 9223372036854775807 (never);
badPasswordTime: 0 (never);
badPwdCount: 0;
cn: John Smith;
codePage: 0;
countryCode: 0;
displayName: John Smith;
distinguishedName: CN=John Smith,OU=AADDC Users,DC=example,DC=com;
dSCorePropagationData (2): 8/13/2019 7:53:04 PM Coordinated Universal Time; 0x0 = ( );
instanceType: 0x4 = ( WRITE );
lastLogoff: 0 (never);
lastLogon: 8/14/2019 6:17:50 PM Coordinated Universal Time;
lastLogonTimestamp: 8/14/2019 4:05:51 PM Coordinated Universal Time;
logonCount: 4;
mail: [email protected];
memberOf (13): OU=AADDC Users,DC=example,DC=com; CN=AAD DC Administrators,OU=AADDC Users,DC=chr,DC=cl;
msDS-AzureADMailNickname: jsmith;
msDS-AzureADObjectId: <ldp: Binary blob 16 bytes>;
name: John Smith;
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=example,DC=com;
objectClass (4): top; person; organizationalPerson; user;
objectGUID: a8123123-3f4f-4123-9123-b530ff123123;
objectSid: S-1-5-21-545123123123-358123123-844123123-1123;
preferredLanguage: en-US;
primaryGroupID: 513 = ( GROUP_RID_USERS );
pwdLastSet: 8/14/2019 2:19:10 PM Coordinated Universal Time;
sAMAccountName: jsmith;
sAMAccountType: 805306368 = ( NORMAL_USER_ACCOUNT );
userAccountControl: 0x200 = ( NORMAL_ACCOUNT );
userPrincipalName: [email protected];
uSNChanged: 30696;
uSNCreated: 20588;
whenChanged: 8/14/2019 4:06:06 PM Coordinated Universal Time;
whenCreated: 8/13/2019 7:21:29 PM Coordinated Universal Time;
Мне еще предстоит протестировать Kerberos и, возможно, OAuth2.
ИЗМЕНИТЬ:
Я не проверял пакеты, которые отправлял клиент, и было кое-что, чего я раньше не изучал.
При отправке простого текстового логина с помощью такого инструмента, как NTRadPing, он будет правильно аутентифицирован, поскольку будет содержать атрибут «User-Password».
С другой стороны, попытка входа через Wi-Fi обычно будет хешированным паролем «EAP».
(10) Received Access-Request Id 21 from 10.0.0.50:56480 to 10.0.0.10:1812 length 217
(10) User-Name = "[email protected]"
(10) NAS-Identifier = "18e829123123"
(10) Called-Station-Id = "18-E5-39-B1-E3-D1:Test"
(10) NAS-Port-Type = Wireless-802.11
(10) Service-Type = Framed-User
(10) Calling-Station-Id = "C0-91-C0-58-BA-AC"
(10) Connect-Info = "CONNECT 0Mbps 802.11a"
(10) Acct-Session-Id = "7394227D45123123"
(10) WLAN-Pairwise-Cipher = 1123123
(10) WLAN-Group-Cipher = 1123123
(10) WLAN-AKM-Suite = 1123123
(10) Framed-MTU = 1400
(10) EAP-Message = 0x02fe001231236d617274696e657a40636872123123
(10) Message-Authenticator = 0x5fd0a8123123984b6b996f2941123123
Я продолжу исследования.
ИЗМЕНИТЬ 2:
Я не могу найти жизнеспособный способ сделать это на данный момент, но я нашел другой способ заставить RADIUS работать через NPS с AADDS.
- Создайте виртуальную машину Windows Server в подсети AADDS и установите роль NPS.
- Настройте NPS, но не регистрируйте его в домене, так как он не будет работать, поскольку AADDS не дает вам необходимых для этого разрешений.
- Настройте свой клиент RADIUS так, чтобы он нацеливался на этот сервер NPS, и он все равно будет работать, сервер NPS не должен быть зарегистрирован в домене для работы RADIUS.
