I noted before that we have a Kerberized mkhomedir. There’s a pam module, pam_kmkhomedir. It does a kerberized call to a service on the NFS server or some other system that has the file system mounted in a way that it can create directories. We did this because we use Kerberized NFS. Root can’t create home directories if NFS is kerberized. However presumably a daemon on the NFS server can. Since we use a Netapp, we had to do a non-Kerberos export to a secure service host, and run the daemon there. But normally I’d expect the daemon to run on the NFS server itself.
> On Mar 4, 2018, at 11:49 AM, TomK via FreeIPA-users > <freeipa-us...@lists.fedorahosted.org> wrote: > > On 3/4/2018 10:23 AM, Galen Johnson wrote: > Hey Galen / Trevor, > > Thanks for replying. Like other posters seem to be having, sssd / oddjobd / > mkhomedir isn't even trying to make a directory on /n which is an automounted > NFSv4 path: > > [root@ipaclient01 oddjobd.conf.d]# grep -Ei mkhomedir /etc/pam.d/* > /etc/pam.d/fingerprint-auth:session optional pam_oddjob_mkhomedir.so > umask=0077 > /etc/pam.d/fingerprint-auth-ac:session optional pam_oddjob_mkhomedir.so > umask=0077 > /etc/pam.d/password-auth:session optional pam_oddjob_mkhomedir.so > umask=0077 > /etc/pam.d/password-auth-ac:session optional pam_oddjob_mkhomedir.so > umask=0077 > /etc/pam.d/smartcard-auth:session optional pam_oddjob_mkhomedir.so > umask=0077 > /etc/pam.d/smartcard-auth-ac:session optional pam_oddjob_mkhomedir.so > umask=0077 > /etc/pam.d/system-auth:session optional pam_oddjob_mkhomedir.so > umask=0077 > /etc/pam.d/system-auth-ac:session optional pam_oddjob_mkhomedir.so > umask=0077 > [root@ipaclient01 oddjobd.conf.d]# > > > I have no_root_squash enabled temporarily as I test everything out (It's only > a LAB) and I can make the folder as root from within the client (ie by typing > the command in myself) but it just doesn't work from within oddjobd / > mkhomedir for some reason unless it's on a local UNIX filesystem. It appears > only able to change directory to an NFS v4 mount, not actually create > anything on it. > > What I'm trying to do is follow an earlier suggestion and send the directory > creation over to the NFS v4 Cluster I have by setting up a client-server type > of python code. The code opens up a port on the NFSv4 server and accepts a > set of messages. Then the client send the server a message and waits for a > reply, then the client logs the user in once directory is created and > available. I've succeeded so far as to get oddjobd to run my custom code and > send 'something' over to the server but I can't get oddjobd to give up the > user it's trying to create the directory for. > > To be perfectly open, I'm not yet convinced having this TCP/IP client-server > code would be much better then no_root_squash but optimistic that via python, > I can provide better security in the long run, if not the short run. > > Seems this might be related to the first problem above. Maybe I'm not > getting a user via oddjobd.conf because the NFSv4 mount isn't recognized? > (This is a guess and I'm really stretching here.) > > -- > Cheers, > Tom K. > ------------------------------------------------------------------------------------- > > Living on earth is expensive, but it includes a free trip around the sun. > > > Not to loose Trevor's reply, I'm including it here. > --------------------------------------- > On 3/4/2018 11:21 AM, Trevor Vaughan via FreeIPA-users wrote: > > I use this in a cron job that's dropped by Puppet. > > > > https://github.com/simp/pupmod-simp-simp_nfs/blob/master/templates/etc/cron.hourly/create_home_directories.rb.erb > > > > https://github.com/simp/pupmod-simp-simp_nfs/blob/master/manifests/create_home_dirs.pp > > > > There's really no way to do this in real time without a LOT of > > additional infrastructure since you're looking at rapid cross-system > > based on enterprise-wide log processing. Users can generally wait the > > <=60 minutes that a cron job will entail. > > > > Trevor > ---------------------------------------- > > > >> This is most likely due to the nfs mount having 'root_squash" set which >> prevents remote servers root from from writing as root (typically nobody or >> nfsnobody). If you are confident that the servers are secure, you could >> mount the NFS share with 'no_root_squash'. It has some security concerns >> but it would allow oddjob_mkhomedir to create homedirs. Another option >> would be to add '<allow user="apache"/>' in addition to root. >> =G= >> On Sun, Mar 4, 2018 at 3:53 AM, TomK <tomk...@mdevsys.com >> <mailto:tomk...@mdevsys.com>> wrote: >> On 2/28/2018 11:19 PM, TomK wrote: >> On 2/27/2018 3:40 AM, Alexander Bokovoy wrote: >> On ti, 27 helmi 2018, TomK via FreeIPA-users wrote: >> On 2/26/2018 1:27 AM, Alexander Bokovoy via >> FreeIPA-users wrote: >> Thanks Alex. + SSSD mailing list. >> Two remaining questions. >> 1) Creating the NFS user folders on the server itself is >> not a problem however I would like to trap events that >> indicate USER logged into a client host. On this event, >> a home directory could then be created on the FreeIPA >> side. Without such an event I can't precreate it. So >> when a user logs into a client machine, is there any >> SSSD call initiated to the FreeIPA server that would >> show up in a log for example that I could in turn use to >> run a small shell script to precreate the user's home >> folder, if it doesn't exist? >> This is not something FreeIPA can help with. We already have >> pam_oddjob_mkhomedir module and its default configuration >> provides you a >> way to create directories out of band using oddjob-mkhomedir >> helper. I >> think at the very least you can have a wrapper that: >> - would check some configuration and push a message to some >> server to >> create a home directory somewhere else >> - would wait for a response back that a directory is created >> (either by >> polling a home directory appearance or communicating >> some other way >> with the remote tool that creates a directory) >> - would otherwise call a standard helper provided by >> oddjob-mkhomedir >> See /etc/oddjobd.conf.d/oddjobd-mkhomedir.conf for details. >> Ty. Yes, thinking along those lines. Netcat w/ bash maybe >> (https://tinyurl.com/yat9k3hv), but simpler. Not sure yet. >> I'm able to write a small python job that will send the username >> logging in to the remote server for directory creation. Not great >> but a start. Not sure if this is the right place to ask but curious >> how get the user logging in and pass it to this script from within >> the oddjobd daemon? >> Anyway, I can't pass the user logging in into the code. >> # cat oddjobd-mkhomedir.conf >> . >> . >> . >> <interface name="com.redhat.oddjob_mkhomedir"> >> <method name="mkmyhomedir"> >> <helper exec="/bin/it.py" >> arguments="0" >> prepend_user_name="yes"/> >> <!-- no acl entries -> not allowed for anyone --> >> </method> >> <method name="mkhomedirfor"> >> <helper exec="/bin/it.py ITDNWORK" >> arguments="1" >> prepend_user_name="yes"/> >> <allow user="root"/> >> </method> >> </interface> >> . >> . >> . >> Btw, above mkhomedir doesn't work on NFS v4 mounted folders anyway. >> 2) Is there a way to get SSSD to retrieve the >> unixHomeDirectory that's defined in the UNIX Attribute >> on the AD side? Would be handy if I want to control all >> home directory locations on the AD side. The >> override_homedir works to force a folder but when I try >> the %o option to override_homedir, it appears to take >> the FreeIPA default home directory, not the AD one. >> unixHomeDirectory is the default for >> ldap_user_home_directory for AD >> provider. Since all IPA trusted subdomains are using AD >> provider, >> unixHomeDirectory would just be used automatically. >> Only override_homedir works for me. User 'tom' in AD has >> unixHomeDirectory set to /home/tom but on a unix client >> connected to FreeIPA home directory is always /home/my.dom/tom >> instead of just /home/tom . Scratching my head as to what I >> might be missing here or not understanding well enough. My config: >> [domain/nix.my.dom] >> cache_credentials = True >> krb5_store_password_if_offline = True >> ipa_domain = nix.my.dom >> id_provider = ipa >> auth_provider = ipa >> access_provider = ipa >> ipa_hostname = ipaclient01.nix.my.dom >> chpass_provider = ipa >> ipa_server = idmipa01.nix.my.dom, idmipa02.nix.my.dom >> ldap_tls_cacert = /etc/ipa/ca.crt >> autofs_provider = ipa >> ipa_automount_location = UserHomeDir01 >> # Added after below home dir variables didn't work. No effect. >> dyndns_update = true >> dyndns_update_ptr = true >> ldap_schema = ad >> ldap_id_mapping = true >> # override_homedir = /n/%d/%u >> # This did not work. >> fallback_homedir = /n/%d/%u >> ldap_user_home_directory = unixHomeDirectory >> [sssd] >> debug_level = 9 >> services = nss, sudo, pam, autofs, ssh >> config_file_version = 2 >> domains = nix.my.dom >> [nss] >> debug_level = 9 >> homedir_substring = /n >> [pam] >> debug_level = 9 >> [sudo] >> debug_level = 9 >> [autofs] >> . >> . >> . >> Cheers, >> Tom >> On su, 25 helmi 2018, TomK via FreeIPA-users wrote: >> Hey Guy's, >> For newly added AD or IPA users, is there a way >> to automatically create the user folders on the >> FreeIPA server under say /nfs/home/bill, for >> example so that when the remote client logs in, >> it sees the NFS mounted folder? >> Instructions that I can find right now require >> precreating the folders. Need them precreated >> via the FreeIPA master servers anytime someone >> attempts to login on a client using their AD >> credentials. Is this possible? Assume the NFS >> server will be local to the FreeIPA masters. >> One needs to create home directories on the NFS >> server itself. If home >> directories are mounted via NFS, then you need to >> have enough permission >> to create the folder at the NFS root which is not >> what you'd want to >> allow a regular user. Thus, it needs to be solved >> outside of a log-in >> flow. >> We don't provide any means to solve this in FreeIPA >> because file >> sharing/hosting is not a FreeIPA problem. If your >> NFS server is running >> on an IPA master, though, you might want to consider >> not using NFS >> mounts on that server itself. In this case a normal >> oddjob-based >> pam_mkhomedir would create the directories just fine. >> Found steps like the one below but step 5) still >> requires pre creation of the folders. >> >> https://www.redhat.com/archives/freeipa-users/2016-May/msg00380.html >> >> <https://www.redhat.com/archives/freeipa-users/2016-May/msg00380.html> >> >> https://serverfault.com/questions/705039/how-to-automate-directory-creation-on-nfs-server >> >> <https://serverfault.com/questions/705039/how-to-automate-directory-creation-on-nfs-server> >> -- Cheers, >> Tom K. >> >> ------------------------------------------------------------------------------------- >> Living on earth is expensive, but it includes a >> free trip around the sun. >> _______________________________________________ >> FreeIPA-users mailing list -- >> freeipa-us...@lists.fedorahosted.org >> <mailto:freeipa-us...@lists.fedorahosted.org> >> To unsubscribe send an email to >> freeipa-users-le...@lists.fedorahosted.org >> <mailto:freeipa-users-le...@lists.fedorahosted.org> >> -- Cheers, >> Tom K. >> >> ------------------------------------------------------------------------------------- >> Living on earth is expensive, but it includes a free >> trip around the sun. >> _______________________________________________ >> FreeIPA-users mailing list -- >> freeipa-us...@lists.fedorahosted.org >> <mailto:freeipa-us...@lists.fedorahosted.org> >> To unsubscribe send an email to >> freeipa-users-le...@lists.fedorahosted.org >> <mailto:freeipa-users-le...@lists.fedorahosted.org> >> -- Cheers, >> Tom K. >> >> ------------------------------------------------------------------------------------- >> Living on earth is expensive, but it includes a free trip around the >> sun. >> _______________________________________________ >> sssd-users mailing list -- sssd-users@lists.fedorahosted.org >> <mailto:sssd-users@lists.fedorahosted.org> >> To unsubscribe send an email to >> sssd-users-le...@lists.fedorahosted.org >> <mailto:sssd-users-le...@lists.fedorahosted.org> >> _______________________________________________ >> sssd-users mailing list -- sssd-users@lists.fedorahosted.org >> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org > > _______________________________________________ > FreeIPA-users mailing list -- freeipa-us...@lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
