LDAP AD and SAMCompatibleName
Hello, I use rlm_ldap to authenticate users in the AD directory. Part of my ldap config: identity = cn=admin,cn=users,dc=example,dc=com base_dn = cn=users,dc=example,dc=com filter = "(userPrincipalName=%{%{Stripped-User-Name}:-%{User-Name}})" So I can use upn form for authentication, for example echo "User-Name=user@example.com,User-Password=password" | radclient localhost:1812 auth testing123 -x Is it possible for rlm_ldap to use not only upn form, but also SAMCompatibleName form like echo "User-Name=REALM\user,User-Password=password" | radclient localhost:1812 auth testing123 -x ? Thanks, Andrei
On Mon, 18 Mar 2024, Andrei Katsuk wrote:
Hello, I use rlm_ldap to authenticate users in the AD directory. Part of my ldap config:
identity = cn=admin,cn=users,dc=example,dc=com base_dn = cn=users,dc=example,dc=com
filter = "(userPrincipalName=%{%{Stripped-User-Name}:-%{User-Name}})"
So I can use upn form for authentication, for example echo "User-Name=user@example.com,User-Password=password" | radclient localhost:1812 auth testing123 -x
Is it possible for rlm_ldap to use not only upn form, but also SAMCompatibleName form like echo "User-Name=REALM\user,User-Password=password" | radclient localhost:1812 auth testing123 -x ?
Thanks, Andrei
Are you sure about that 'SAMCompatibleName' attribute name? Our AD forest only has 'sAMAccountName' and it doesn't contain the "REALM\" part of the value only "sAMAccountName=user". Be that as it may, the way to do that is to augment your search filter using LDAP syntax: filter = "(|(userPrincipalName=%{%{Stripped-User-Name}:-%{User-Name}})(sAMAccountName=%{%{Stripped-User-Name}:-%{User-Name}}))" Adjust that 'sAMAccountName' attribute name to meet your needs. -- Dave Funk University of Iowa <dbfunk (at) engineering.uiowa.edu> College of Engineering 319/335-5751 FAX: 319/384-0549 1256 Seamans Center, 103 S Capitol St. Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527 #include <std_disclaimer.h> Better is not better, 'standard' is better. B{
Are you sure about that 'SAMCompatibleName' attribute name? Our AD forest only has 'sAMAccountName' and it doesn't contain the "REALM\" part of the value only "sAMAccountName=user".
You are right, there is no SAMCompatibleName attribute and sAMAccountName contains only username. SAMCompatibleName is just the format of a legacy account name (example REALM\user, where REALM is netbios name) It seems we can not use a simple filter in this case but maybe there are some other ways ? Thanks, Andrei
On Mar 19, 2024, at 12:36 PM, Andrei Katsuk <steep8@gmail.com> wrote:
You are right, there is no SAMCompatibleName attribute and sAMAccountName contains only username. SAMCompatibleName is just the format of a legacy account name (example REALM\user, where REALM is netbios name) It seems we can not use a simple filter in this case but maybe there are some other ways ?
To do *what* specifically? If you have e-mails of the form "bob@company.com", is the sAMAccountName for that user always going to be "bob"? Or will it be something else? In order to give advice here, we'll need some more detailed information about exactly what transformation you're trying to do. Alan DeKok.
To do *what* specifically?
Someone can enter bob@company.com or REALM\bob , where REALM is the netbios name of AD server. The first format is UserPrincipalName and it can be easily handled by setting up a filter in rlm_ldap config The second format is SAMCompatibleName and is not handled out-of-the-box.
If you have e-mails of the form "bob@company.com", is the sAMAccountName for that user always going to be "bob"? Or will it be something else?
It seems sAMAccountName contains only "bob" . Thanks, Andrei
On Mar 19, 2024, at 1:30 PM, Andrei Katsuk <steep8@gmail.com> wrote:
Someone can enter bob@company.com or REALM\bob , where REALM is the netbios name of AD server. The first format is UserPrincipalName and it can be easily handled by setting up a filter in rlm_ldap config The second format is SAMCompatibleName and is not handled out-of-the-box.
If you have e-mails of the form "bob@company.com", is the sAMAccountName for that user always going to be "bob"? Or will it be something else?
It seems sAMAccountName contains only "bob" .
So why not just look up "bob"? The "realm" module can look up suffixes "bob@example.com", and prefixes "REALM\bob". See mods-available/realm You can use both realms in sites-available/default: # # Look for realms in user@domain format suffix # ntdomain Just uncomment "ntdomain". Then define two realms in proxy.conf, one for each format: realm company.com { } realm REALM { } This tells the "realm" module to allow those two names for realms. When the server receives a packet, it will run the "default" virtual server, and then both "suffix" and "ntdomain". After those modules have been run, the Stripped-User-Name attribute will always contain the user name ("bob"). And the Realm attribute will always contain either "example.com" or "REALM" Then configure the LDAP module to look up: filter = "(&(objectClass=user)(sAMAccountName=%{%{Stripped-User-Name} ... This is in the default configuration in mods-available/ldap. It's commented out, so just uncomment it, and comment out any other "filter" line. After that, it should work. Alan DeKok.
So why not just look up "bob"?
The "realm" module can look up suffixes "bob@example.com", and prefixes "REALM\bob". See mods-available/realm
What if the user enters the wrong REALM (for example we expect EXAMPLE\bob but the user writes WRONG\bob ) ? Will the user be authenticated in this case? I want to reject authentication in this case. Also rlm_ldap supports several ldap servers and it seems we can not just compare all REALMs with known constants. Thanks, Andrei
On Mar 20, 2024, at 12:33 PM, Andrei Katsuk <steep8@gmail.com> wrote:
What if the user enters the wrong REALM (for example we expect EXAMPLE\bob but the user writes WRONG\bob ) ? Will the user be authenticated in this case?
Of course not. FreeRADIUS doesn't randomly authenticate users. The point of configuring the "realm" module and the sample "realm foo { ... }" configurations was to define those as known quantities. Other realms won't be known, and therefore won't work. You could test this yourself in 5 minutes by trying it, and reading the debug outposts.
I want to reject authentication in this case. Also rlm_ldap supports several ldap servers and it seems we can not just compare all REALMs with known constants.
I have no idea what that means. If you want to define known realms, I've shown you the template for how to do that. If you want the server to authenticate other realms, then please explain that requirement in detail. What isn't helpful is the "peek a boo" approach of gradually explaining more requirements across multiple messages. Explain what you want to. Be specific. It is much more difficult to help people when the requirements are vague and changing. Alan DeKok.
Currently I want to authenticate users who enter EXAMPLE\bob or bob@example.com. Also I don't want to grant access to users who enter EXAMPLE.COM\bob or bob@EXAMPLE. To do this I defined two realms in proxy.conf: realm example.com { } realm EXAMPLE { } and modify server configuration: suffix if (ok) { find_dot_in_realm if (notfound) { reject } else { update control { &control:Tmp-String-0 := "(userPrincipalName=%{User-Name})" } } } ntdomain if (ok) { find_dot_in_realm if (ok) { reject } else { update control { &control:Tmp-String-0 := "(samaccountname=%{%{Stripped-User-Name}:-%{User-Name}})" } } } where find_dot_in_realm defined in policy: find_dot_in_realm_regexp = "^(.+)\.(.+)$" find_dot_in_realm { if (Realm && (Realm =~ /${policy.find_dot_in_realm_regexp}/)){ ok } else { notfound } } and defined filter for rlm_ldap configuration as filter = &control:Tmp-String-0 Is it the right approach or something can be done in a better or easier way ? Thanks, Andrei
On Mar 22, 2024, at 5:04 AM, Andrei Katsuk <steep8@gmail.com> wrote:
Currently I want to authenticate users who enter EXAMPLE\bob or bob@example.com. Also I don't want to grant access to users who enter EXAMPLE.COM\bob or bob@EXAMPLE.
Why does it matter?
Is it the right approach or something can be done in a better or easier way ?
If it works, it's OK. Perhaps the "realm" module could be updated to mark if the realm is suffix or prefix. As always, patches are welcome. Alan DeKok.
Currently I want to authenticate users who enter EXAMPLE\bob or bob@example.com. Also I don't want to grant access to users who enter EXAMPLE.COM\bob or bob@EXAMPLE.
Why does it matter?
When realm is defined as realm EXAMPLE it grants access for EXAMPLE\bob and bob@EXAMPLE. Currently we do not support the last format that is why I want to reject bob@EXAMPLE.
Perhaps the "realm" module could be updated to mark if the realm is suffix or prefix. As always, patches are welcome.
What should the modified "realm" module update ? Should it return some extra values or fill in some new attributes ?
On Mar 26, 2024, at 1:48 AM, Andrei Katsuk <steep8@gmail.com> wrote:
When realm is defined as realm EXAMPLE it grants access for EXAMPLE\bob and bob@EXAMPLE.
Yes, I know...
Currently we do not support the last format that is why I want to reject bob@EXAMPLE.
i.e. "it doesn't do anything wrong, but we don't want people using it". So just *don't tell people* that it works? Document what works, and it should be fine. For that matter, why support EXAMPLE/user *and* user@example.com? There is few good reasons to allow multiple formats for the same user. Why not simplify things, and just pick one of them? 99% of sites use either a bare name "user", or an email address "user@example.com".
Perhaps the "realm" module could be updated to mark if the realm is suffix or prefix. As always, patches are welcome.
What should the modified "realm" module update ? Should it return some extra values or fill in some new attributes ?
The "realm" data structure can be modified to support a "format" string like the "realms" module. See src/modules/rlm_realm/rlm_realm.c for the handling of data structures + parsing for "format = suffix". See src/include/realms.h for the "realm" data structure. See src/main/realms.c for parsing of the data structure. Once all of that is fixed, the rlm_realms.c file can be modified to check that "realm->format == inst->format", and therefore ignore mismatched realms. Alan DeKok.
On 26/03/2024 10:48, Alan DeKok wrote:
On Mar 26, 2024, at 1:48 AM, Andrei Katsuk <steep8@gmail.com> wrote:
When realm is defined as realm EXAMPLE it grants access for EXAMPLE\bob and bob@EXAMPLE.
Yes, I know...
The "filter_username" policy (in the default config) already stops bob@EXAMPLE. It's invalid because it doesn't have a "." in the realm. Which just leaves EXAMPLE\bob, bob@example.com and example.com\bob To stop the latter, just use unlang. filter_username ... suffix ntdomain if (ok && &Realm =~ /\./) { reject } I agree, for the number of people actually discovering that it works and then getting excited because they can do something different from everyone else that gives them no extra benefits, it's probably not worth the CPU cycles. -- Matthew
On Tue, 19 Mar 2024, Andrei Katsuk wrote:
Are you sure about that 'SAMCompatibleName' attribute name? Our AD forest only has 'sAMAccountName' and it doesn't contain the "REALM\" part of the value only "sAMAccountName=user".
You are right, there is no SAMCompatibleName attribute and sAMAccountName contains only username. SAMCompatibleName is just the format of a legacy account name (example REALM\user, where REALM is netbios name) It seems we can not use a simple filter in this case but maybe there are some other ways ?
Thanks, Andrei
Could you get people to use "username@REAL" syntax instead of "REALM\username" ? There's code in Radius land to deal with username@something" Alternatively if all your users are going to be in the same "REALM\" you could add a local ulang snippet to test for your expected "REALM\", strip it off and then test the "username" via sAMAccountName -- Dave Funk University of Iowa <dbfunk (at) engineering.uiowa.edu> College of Engineering 319/335-5751 FAX: 319/384-0549 1256 Seamans Center, 103 S Capitol St. Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527 #include <std_disclaimer.h> Better is not better, 'standard' is better. B{
Could you get people to use "username@REAL" syntax instead of "REALM\username" ? There's code in Radius land to deal with username@something"
Could you point me out to a reference or modules where it happens (Is "something" something different from "company.com")?
Alternatively if all your users are going to be in the same "REALM\" you could add a local ulang snippet to test for your expected "REALM\", strip it off and then test the "username" via sAMAccountName
Suppose we have several REALMs as rlm_ldap supports several ldap servers. Should I write ulang snippet for each REALM separately or maybe there is some kind of construct to handle them as a list ? Thanks, Andrei
participants (5)
-
Alan DeKok -
Andrei Katsuk -
Dave Funk -
David B Funk
-
Matthew Newton