From: Jaroslaw R. <ra...@ra...> - 2022-05-25 22:22:03
Attachments:
ldap_auto_uid.patch
|
Hello, recently I needed to configure ProFTPd to authenticate users in Microsoft AD domain. I think it's a well-known fact that AD LDAP directory by default does not contain any "uidNumber" and "gidNumber" (or equivalent) attribute. If you configure system-wide authentication to AD with sssd (according to many guides available on the net), it can use a special algorithm to map "objectSid" values present in the AD directory to UIDs and GIDs, therefore "producing" specific UID/GID values for each user. However, ProFTPd's mod_ldap module cannot use this information and therefore one needs to force all users logging in via AD to the same LDAPDefaultUID and LDAPDefaultGID values. This is not always acceptable. In my case, I needed the users logging in via FTP to have the same UID/GID values as the ones provided to them via sssd when logging in interactively (otherwise they wouldn't be able to write to their home directories!). I wonder that nobody has written nowhere about this obvious (and very common) problem and didn't suggest any solution for it. Therefore I created a simple patch to mod_ldap.c, allowing to use a special value "auto" for LDAPDefaultUID or LDAPDefaultGID directive in config file (actually the value "auto" is internally converted to UID/GID equal to -2, so one can obtain the same result specifying -2 as the value for LDAPDefaultUID/LDAPDefaultGID). If LDAPDefaultUID or LDAPDefaultGID is set to "auto", the correct value of UID or GID is obtained via getpwnam() call from the username. This is enough to make use of the mapping provided by sssd. The patch is enclosed. It is a patch against the current version on Github (it should work also with 1.3.7d), although I haven't tested it with that version. My ProFTPd is version 1.3.4a, so I initially patched mod_ldap distributed with that version, which is a bit different. But the patch is so simple that I hope I have changed it properly for the new version :). I don't know what is the correct way to submit this for considering to be included in the distribution, so I'm simply sending the patch for your use in whatever way appropriate. -- Regards, Jaroslaw Rafa ra...@ra... -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." |
From: TJ S. <tj...@ca...> - 2023-09-10 18:06:01
|
> recently I needed to configure ProFTPd to authenticate users in Microsoft AD > domain. I think it's a well-known fact that AD LDAP directory by default > does not contain any "uidNumber" and "gidNumber" (or equivalent) attribute. > If you configure system-wide authentication to AD with sssd (according to > many guides available on the net), it can use a special algorithm to map > "objectSid" values present in the AD directory to UIDs and GIDs, therefore > "producing" specific UID/GID values for each user. Going through some old emails, I ran across this. I've filed a GitHub issue for tracking this: https://github.com/proftpd/proftpd/issues/1716 Cheers, TJ |
From: Jaroslaw R. <ra...@ra...> - 2023-09-10 20:23:51
|
Dnia 10.09.2023 o godz. 10:49:18 TJ Saunders pisze: > > > recently I needed to configure ProFTPd to authenticate users in Microsoft AD > > domain. I think it's a well-known fact that AD LDAP directory by default > > does not contain any "uidNumber" and "gidNumber" (or equivalent) attribute. > > If you configure system-wide authentication to AD with sssd (according to > > many guides available on the net), it can use a special algorithm to map > > "objectSid" values present in the AD directory to UIDs and GIDs, therefore > > "producing" specific UID/GID values for each user. > > Going through some old emails, I ran across this. I've filed a GitHub issue for tracking this: > > https://github.com/proftpd/proftpd/issues/1716 Thank you. There is however another issue related to this. When I initially implemented this, some users were unable to login, because their usernames were internally stored as uppercase in the AD (while others were lowercase), and ProFTPd was unable to find home directory for the user, because it searched for "/home/USERNAME" while the actual directory was "/home/username". It returned a failure and the user was unable to login. So I needed also to introduce another patch (I don't have it at hand now, since I don't work on that server anymore) that lowercases the username before searching for home directory. I made this lowercasing mandatory, but of course there also can be a configuration setting controlling this. So while I don't have the actual patch right now, I kindly ask you to implement this. -- Regards, Jaroslaw Rafa ra...@ra... -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." |
From: TJ S. <tj...@ca...> - 2023-09-11 16:31:07
|
>> Going through some old emails, I ran across this. I've filed a GitHub issue for tracking this: >> >> https://github.com/proftpd/proftpd/issues/1716 > > Thank you. There is however another issue related to this. When I initially > implemented this, some users were unable to login, because their usernames > were internally stored as uppercase in the AD (while others were lowercase), > and ProFTPd was unable to find home directory for the user, because it > searched for "/home/USERNAME" while the actual directory was > "/home/username". It returned a failure and the user was unable to login. > So I needed also to introduce another patch (I don't have it at hand now, > since I don't work on that server anymore) that lowercases the username > before searching for home directory. You might be able to implement this now, without any patches, using the mod_rewrite module, and RewriteHome; see: http://www.proftpd.org/docs/modules/mod_auth.html#RewriteHome For example, something like this might work for your use case: <IfModule mod_rewrite.c> RewriteEngine on RewriteLog /path/to/rewrite.log # Define a map that uses the internal "tolower" function RewriteMap lowercase int:tolower RewriteCondition %m REWRITE_HOME RewriteRule (.*) ${uppercase:$1} </IfModule> Hope this helps, TJ |
From: TJ S. <tj...@ca...> - 2023-09-11 16:34:01
|
> For example, something like this might work for your use case: > > <IfModule mod_rewrite.c> > RewriteEngine on > RewriteLog /path/to/rewrite.log > > # Define a map that uses the internal "tolower" function > RewriteMap lowercase int:tolower > > RewriteCondition %m REWRITE_HOME > RewriteRule (.*) ${uppercase:$1} > </IfModule> Oops. I was copy/pasting this together from multiple different examples, and missed a spot; that's meant to be using "lowercase": <IfModule mod_rewrite.c> RewriteEngine on RewriteLog /path/to/rewrite.log # Define a map that uses the internal "tolower" function RewriteMap lowercase int:tolower RewriteCondition %m REWRITE_HOME RewriteRule (.*) ${lowercase:$1} </IfModule> Cheers, TJ |