I'm having a problem getting pam_mkhomedir.so to make a user's home directory when it's specified using an LDAP attribute. The backend directory server is AD on Server 2008. The client is Ubuntu 12.04, sssd version 1.11.1.
First, my sssd.conf:
[sssd] config_file_version = 2 debug_level = 0 reconnection_retries = 3 sbus_timeout = 30 services = nss, pam domains = domain
[pam] debug_level = 0
[nss] debug_level = 0 filter_users = root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm filter_groups = root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm reconnection_retries = 3
[domain/domain] debug_level = 0 ad_domain = domain.local id_provider = ad auth_provider = ad chpass_provider = ad access_provider = ad enumerate = true cache_credentials = true # Will check unixHomeDirectory LDAP attribute for a value first fallback_homedir = /home/%u ldap_user_home_directory = unixHomeDirectory dyndns_update = true dyndns_update_ptr = true ldap_schema = ad ldap_id_mapping = true
I'm testing using the Guest user.
Guest, unlike all my other users, has a home directory set in the unixHomeDirectory attribute (/tmp/Guest). All other users rely on the fallback_homedir option. When a normal user signs in and does not have a home directory, I've configured pam to create one by adding this to the common-session file:
session required pam_mkhomedir.so umask=077
This all works fine when ldap_user_home_directory is empty; the home directory is created automatically upon logging in using the fallback_homedir option.
However, when unixHomeDirectory actually contains a path, no home directory is ever created and I'm always dropped in /.
Interestingly enough, "echo $HOME" as the Guest returns two different values depending on if fallback_homedir is set. If it is set, $HOME = /home/Guest. If it's commented out, $HOME = /tmp/Guest.
Any ideas? Thanks!
-Chris
On Wed, Oct 09, 2013 at 11:25:51AM -0400, Chris Hartman wrote:
I'm having a problem getting pam_mkhomedir.so to make a user's home directory when it's specified using an LDAP attribute. The backend directory server is AD on Server 2008. The client is Ubuntu 12.04, sssd version 1.11.1.
First, my sssd.conf:
[sssd] config_file_version = 2 debug_level = 0 reconnection_retries = 3 sbus_timeout = 30 services = nss, pam domains = domain
[pam] debug_level = 0
[nss] debug_level = 0 filter_users = root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm filter_groups = root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm reconnection_retries = 3
[domain/domain] debug_level = 0 ad_domain = domain.local id_provider = ad auth_provider = ad chpass_provider = ad access_provider = ad enumerate = true cache_credentials = true # Will check unixHomeDirectory LDAP attribute for a value first fallback_homedir = /home/%u ldap_user_home_directory = unixHomeDirectory dyndns_update = true dyndns_update_ptr = true ldap_schema = ad ldap_id_mapping = true
I'm testing using the Guest user.
Guest, unlike all my other users, has a home directory set in the unixHomeDirectory attribute (/tmp/Guest). All other users rely on the fallback_homedir option. When a normal user signs in and does not have a home directory, I've configured pam to create one by adding this to the common-session file:
session required pam_mkhomedir.so umask=077
This all works fine when ldap_user_home_directory is empty; the home directory is created automatically upon logging in using the fallback_homedir option.
However, when unixHomeDirectory actually contains a path, no home directory is ever created and I'm always dropped in /.
Interestingly enough, "echo $HOME" as the Guest returns two different values depending on if fallback_homedir is set. If it is set, $HOME = /home/Guest. If it's commented out, $HOME = /tmp/Guest.
Any ideas? Thanks!
-Chris
What does getent passwd Guest say? Which homedir do you get back?
getent passwd Guest returns:
guest:*:1596000501:1596000514:Guest:/:/bin/bash
Also, I'm wondering if this has something to do with case sensitivity? `getent passwd Guest` and `getent passwd guest` return the same result. Also, I can login with either Guest or guest. Just a thought.
-Chris
On Wed, Oct 9, 2013 at 11:32 AM, Jakub Hrozek jhrozek@redhat.com wrote:
On Wed, Oct 09, 2013 at 11:25:51AM -0400, Chris Hartman wrote:
I'm having a problem getting pam_mkhomedir.so to make a user's home directory when it's specified using an LDAP attribute. The backend directory server is AD on Server 2008. The client is Ubuntu 12.04, sssd version 1.11.1.
First, my sssd.conf:
[sssd] config_file_version = 2 debug_level = 0 reconnection_retries = 3 sbus_timeout = 30 services = nss, pam domains = domain
[pam] debug_level = 0
[nss] debug_level = 0 filter_users =
root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm
filter_groups =
root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm
reconnection_retries = 3
[domain/domain] debug_level = 0 ad_domain = domain.local id_provider = ad auth_provider = ad chpass_provider = ad access_provider = ad enumerate = true cache_credentials = true # Will check unixHomeDirectory LDAP attribute for a value first fallback_homedir = /home/%u ldap_user_home_directory = unixHomeDirectory dyndns_update = true dyndns_update_ptr = true ldap_schema = ad ldap_id_mapping = true
I'm testing using the Guest user.
Guest, unlike all my other users, has a home directory set in the unixHomeDirectory attribute (/tmp/Guest). All other users rely on the fallback_homedir option. When a normal user signs in and does not have a home directory, I've configured pam to create one by adding this to the common-session file:
session required pam_mkhomedir.so umask=077
This all works fine when ldap_user_home_directory is empty; the home directory is created automatically upon logging in using the fallback_homedir option.
However, when unixHomeDirectory actually contains a path, no home
directory
is ever created and I'm always dropped in /.
Interestingly enough, "echo $HOME" as the Guest returns two different values depending on if fallback_homedir is set. If it is set, $HOME = /home/Guest. If it's commented out, $HOME = /tmp/Guest.
Any ideas? Thanks!
-Chris
What does getent passwd Guest say? Which homedir do you get back? _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Hmm. This may be host-specific. I'm not able to reproduce this problem on other hosts.
Does getent use a cache that could be screwing things up? I've disabled caching and enumerating in SSSD temporarily for troubleshooting.
-Chris
On Wed, Oct 9, 2013 at 11:47 AM, Chris Hartman qrstuv@gmail.com wrote:
getent passwd Guest returns:
guest:*:1596000501:1596000514:Guest:/:/bin/bash
Also, I'm wondering if this has something to do with case sensitivity? `getent passwd Guest` and `getent passwd guest` return the same result. Also, I can login with either Guest or guest. Just a thought.
-Chris
On Wed, Oct 9, 2013 at 11:32 AM, Jakub Hrozek jhrozek@redhat.com wrote:
On Wed, Oct 09, 2013 at 11:25:51AM -0400, Chris Hartman wrote:
I'm having a problem getting pam_mkhomedir.so to make a user's home directory when it's specified using an LDAP attribute. The backend directory server is AD on Server 2008. The client is Ubuntu 12.04, sssd version 1.11.1.
First, my sssd.conf:
[sssd] config_file_version = 2 debug_level = 0 reconnection_retries = 3 sbus_timeout = 30 services = nss, pam domains = domain
[pam] debug_level = 0
[nss] debug_level = 0 filter_users =
root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm
filter_groups =
root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm
reconnection_retries = 3
[domain/domain] debug_level = 0 ad_domain = domain.local id_provider = ad auth_provider = ad chpass_provider = ad access_provider = ad enumerate = true cache_credentials = true # Will check unixHomeDirectory LDAP attribute for a value first fallback_homedir = /home/%u ldap_user_home_directory = unixHomeDirectory dyndns_update = true dyndns_update_ptr = true ldap_schema = ad ldap_id_mapping = true
I'm testing using the Guest user.
Guest, unlike all my other users, has a home directory set in the unixHomeDirectory attribute (/tmp/Guest). All other users rely on the fallback_homedir option. When a normal user signs in and does not have a home directory, I've configured pam to create one by adding this to the common-session file:
session required pam_mkhomedir.so umask=077
This all works fine when ldap_user_home_directory is empty; the home directory is created automatically upon logging in using the fallback_homedir option.
However, when unixHomeDirectory actually contains a path, no home
directory
is ever created and I'm always dropped in /.
Interestingly enough, "echo $HOME" as the Guest returns two different values depending on if fallback_homedir is set. If it is set, $HOME = /home/Guest. If it's commented out, $HOME = /tmp/Guest.
Any ideas? Thanks!
-Chris
What does getent passwd Guest say? Which homedir do you get back? _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Well, in a related development, it appears there is a hardware issue with the testing PC- bad hard disk. Will replace, reinstall OS, and re-test.
However, there is definitely a case sensitivity issue happening.
My other hosts only have an issue when logging in with Guest as opposed to guest. Guest causes /home/guest to be created despite what's in the unixHomeDirectory attribute; then I'm always dropped in / because "Could not chdir to home directory /tmp/Guest: No such file or directory." I imagine this because sssd is lowercasing usernames but PAM isn't? "getent passwd guest" always returns the same result: guest:*:1596000501:1596000514: Guest:/tmp/Guest:/bin/bash
If I login in with guest, everything works as expected (after the cache is cleared). It seems strange that I'm even allowed to auth with both guest and Guest. Shouldn't one fail? Is this a bug or feature?
-Chris
On Wed, Oct 9, 2013 at 11:50 AM, Chris Hartman qrstuv@gmail.com wrote:
Hmm. This may be host-specific. I'm not able to reproduce this problem on other hosts.
Does getent use a cache that could be screwing things up? I've disabled caching and enumerating in SSSD temporarily for troubleshooting.
-Chris
On Wed, Oct 9, 2013 at 11:47 AM, Chris Hartman qrstuv@gmail.com wrote:
getent passwd Guest returns:
guest:*:1596000501:1596000514:Guest:/:/bin/bash
Also, I'm wondering if this has something to do with case sensitivity? `getent passwd Guest` and `getent passwd guest` return the same result. Also, I can login with either Guest or guest. Just a thought.
-Chris
On Wed, Oct 9, 2013 at 11:32 AM, Jakub Hrozek jhrozek@redhat.com wrote:
On Wed, Oct 09, 2013 at 11:25:51AM -0400, Chris Hartman wrote:
I'm having a problem getting pam_mkhomedir.so to make a user's home directory when it's specified using an LDAP attribute. The backend directory server is AD on Server 2008. The client is Ubuntu 12.04, sssd version 1.11.1.
First, my sssd.conf:
[sssd] config_file_version = 2 debug_level = 0 reconnection_retries = 3 sbus_timeout = 30 services = nss, pam domains = domain
[pam] debug_level = 0
[nss] debug_level = 0 filter_users =
root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm
filter_groups =
root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm
reconnection_retries = 3
[domain/domain] debug_level = 0 ad_domain = domain.local id_provider = ad auth_provider = ad chpass_provider = ad access_provider = ad enumerate = true cache_credentials = true # Will check unixHomeDirectory LDAP attribute for a value first fallback_homedir = /home/%u ldap_user_home_directory = unixHomeDirectory dyndns_update = true dyndns_update_ptr = true ldap_schema = ad ldap_id_mapping = true
I'm testing using the Guest user.
Guest, unlike all my other users, has a home directory set in the unixHomeDirectory attribute (/tmp/Guest). All other users rely on the fallback_homedir option. When a normal user signs in and does not have
a
home directory, I've configured pam to create one by adding this to the common-session file:
session required pam_mkhomedir.so umask=077
This all works fine when ldap_user_home_directory is empty; the home directory is created automatically upon logging in using the fallback_homedir option.
However, when unixHomeDirectory actually contains a path, no home
directory
is ever created and I'm always dropped in /.
Interestingly enough, "echo $HOME" as the Guest returns two different values depending on if fallback_homedir is set. If it is set, $HOME = /home/Guest. If it's commented out, $HOME = /tmp/Guest.
Any ideas? Thanks!
-Chris
What does getent passwd Guest say? Which homedir do you get back? _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/09/2013 12:20 PM, Chris Hartman wrote:
Well, in a related development, it appears there is a hardware issue with the testing PC- bad hard disk. Will replace, reinstall OS, and re-test.
However, there is definitely a case sensitivity issue happening.
My other hosts only have an issue when logging in with Guest as opposed to guest. Guest causes /home/guest to be created despite what's in the unixHomeDirectory attribute; then I'm always dropped in / because "Could not chdir to home directory /tmp/Guest: No such file or directory." I imagine this because sssd is lowercasing usernames but PAM isn't? "getent passwd guest" always returns the same result: guest:*:1596000501:1596000514:Guest:/tmp/Guest:/bin/bash
Hmm, that would be an interesting interaction problem. Yeah, PAM gets passed *exactly* what you submit to it. Could you file a bug against pam_mkhomedir? We probably want to have it normalize the lookup by running getpwnam() itself to deal with aliased usernames (which is essentially how we deal with case-insensitivity in SSSD; we treat the name you passed in as an alias for the REAL user, which is the lowercase version.).
If I login in with guest, everything works as expected (after the cache is cleared). It seems strange that I'm even allowed to auth with both guest and Guest. Shouldn't one fail? Is this a bug or feature?
When running id_provider = ad, we default to operating in case-insensitive mode. That's a feature.
Now, if they're not returning the same information, that would be a bug.
Could you file a bug against pam_mkhomedir?
I can definitely do this, though I'm not exactly sure what the bug is because I don't think I understand the problem fully. "mkhomedir.so doesn't play nice with aliased usernames"? Can you offer a little more guidance and/or explanation?
When running id_provider = ad, we default to operating in case-insensitive
mode.
Is there a config option that exposes case sensitivity mode? If not, such a feature might be useful. Not sure if that is programmatically feasible/practical, though.
-Chris
On Wed, Oct 9, 2013 at 12:37 PM, Stephen Gallagher sgallagh@redhat.comwrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/09/2013 12:20 PM, Chris Hartman wrote:
Well, in a related development, it appears there is a hardware issue with the testing PC- bad hard disk. Will replace, reinstall OS, and re-test.
However, there is definitely a case sensitivity issue happening.
My other hosts only have an issue when logging in with Guest as opposed to guest. Guest causes /home/guest to be created despite what's in the unixHomeDirectory attribute; then I'm always dropped in / because "Could not chdir to home directory /tmp/Guest: No such file or directory." I imagine this because sssd is lowercasing usernames but PAM isn't? "getent passwd guest" always returns the same result: guest:*:1596000501:1596000514:Guest:/tmp/Guest:/bin/bash
Hmm, that would be an interesting interaction problem. Yeah, PAM gets passed *exactly* what you submit to it. Could you file a bug against pam_mkhomedir? We probably want to have it normalize the lookup by running getpwnam() itself to deal with aliased usernames (which is essentially how we deal with case-insensitivity in SSSD; we treat the name you passed in as an alias for the REAL user, which is the lowercase version.).
If I login in with guest, everything works as expected (after the cache is cleared). It seems strange that I'm even allowed to auth with both guest and Guest. Shouldn't one fail? Is this a bug or feature?
When running id_provider = ad, we default to operating in case-insensitive mode. That's a feature.
Now, if they're not returning the same information, that would be a bug.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlJVhi0ACgkQeiVVYja6o6PK4QCfer+OI1eaSSeXJt6Az+61O0my NXIAn3bG12hR9dStnSn4mY+lznj4LbaI =RxO6 -----END PGP SIGNATURE----- _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/09/2013 01:06 PM, Chris Hartman wrote:
Could you file a bug against pam_mkhomedir?
I can definitely do this, though I'm not exactly sure what the bug is because I don't think I understand the problem fully. "mkhomedir.so doesn't play nice with aliased usernames"? Can you offer a little more guidance and/or explanation?
Basically, when pam_mkhomedir.so is invoked, it has a substitution template that it fills in with the username. Apparently, it is taking the input value from PAM as this substitution value, but if you happen to be logging in the first time from an alias (anything other than the canonical version, which is the lower-case one in this example), it creates the directory with that instead of the canonical one.
When running id_provider = ad, we default to operating in case-insensitive mode.
Is there a config option that exposes case sensitivity mode? If not, such a feature might be useful. Not sure if that is programmatically feasible/practical, though.
- From the AD provider manpage (http://jhrozek.fedorapeople.org/sssd/1.11.1/man/sssd-ad.5.html): "Users, groups and other entities served by SSSD are always treated as case-insensitive in the AD provider for compatibility with Active Directory's LDAP implementation."
- From the sssd.conf manpage (http://jhrozek.fedorapeople.org/sssd/1.11.1/man/sssd.conf.5.html):
case_sensitive (boolean)
Treat user and group names as case sensitive. At the moment, this option is not supported in the local provider.
Default: True
Essentially, using 'id_provider = ad' implies 'case_sensitive = False'
I've opened a ticket on PAM's bug tracker: https://fedorahosted.org/linux-pam/ticket/22
Thanks to Stephen and Jakub for all your help!
-Chris
On Wed, Oct 9, 2013 at 2:00 PM, Stephen Gallagher sgallagh@redhat.comwrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/09/2013 01:06 PM, Chris Hartman wrote:
Could you file a bug against pam_mkhomedir?
I can definitely do this, though I'm not exactly sure what the bug is because I don't think I understand the problem fully. "mkhomedir.so doesn't play nice with aliased usernames"? Can you offer a little more guidance and/or explanation?
Basically, when pam_mkhomedir.so is invoked, it has a substitution template that it fills in with the username. Apparently, it is taking the input value from PAM as this substitution value, but if you happen to be logging in the first time from an alias (anything other than the canonical version, which is the lower-case one in this example), it creates the directory with that instead of the canonical one.
When running id_provider = ad, we default to operating in case-insensitive mode.
Is there a config option that exposes case sensitivity mode? If not, such a feature might be useful. Not sure if that is programmatically feasible/practical, though.
- From the AD provider manpage
(http://jhrozek.fedorapeople.org/sssd/1.11.1/man/sssd-ad.5.html): "Users, groups and other entities served by SSSD are always treated as case-insensitive in the AD provider for compatibility with Active Directory's LDAP implementation."
- From the sssd.conf manpage
(http://jhrozek.fedorapeople.org/sssd/1.11.1/man/sssd.conf.5.html):
case_sensitive (boolean)
Treat user and group names as case sensitive. At the moment, thisoption is not supported in the local provider.
Default: TrueEssentially, using 'id_provider = ad' implies 'case_sensitive = False' -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlJVmbIACgkQeiVVYja6o6PUQgCfU5J5mg7Q/XpZQ8Dwdv+ORjKa VZsAnjXosUGYG28bQmnTl+XwDkU5Mjx8 =ufaB -----END PGP SIGNATURE----- _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/09/2013 12:20 PM, Chris Hartman wrote:
Well, in a related development, it appears there is a hardware issue with the testing PC- bad hard disk. Will replace, reinstall OS, and re-test.
However, there is definitely a case sensitivity issue happening.
My other hosts only have an issue when logging in with Guest as opposed to guest. Guest causes /home/guest to be created despite what's in the unixHomeDirectory attribute; then I'm always dropped in / because "Could not chdir to home directory /tmp/Guest: No such file or directory." I imagine this because sssd is lowercasing usernames but PAM isn't? "getent passwd guest" always returns the same result: guest:*:1596000501:1596000514:Guest:/tmp/Guest:/bin/bash
Hmm, maybe I misunderstood something here. I just re-read in your original mail that this home directory was specified in LDAP, not as part of the fallback_homedir processing. So that makes sense for why it's leaving it capitalized; we always take that string from LDAP literally, regardless of case-sensitive operation.
So if that's the case, I'm somewhat at a loss for why it would be creating /home/guest at all (instead of what's in the passwd entry, which is /tmp/Guest and is therefore the directory that the shell tries to use).
Can you show me *exactly* what 'getent passwd Guest' returns and then also what 'getent passwd guest' shows on the same system? They are *supposed* to have identical output, whatever that output ends up being.
However, I suspect that this is going wrong somewhere. I really need to see those two outputs side-by-side, please.
If I login in with guest, everything works as expected (after the cache is cleared). It seems strange that I'm even allowed to auth with both guest and Guest. Shouldn't one fail? Is this a bug or feature?
When you log in as 'guest', what is the output of "echo $HOME"?
sssd-users@lists.fedorahosted.org
-
Chris Hartman -
Jakub Hrozek -
Stephen Gallagher