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:
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 <tomkcpr(a)mdevsys.com
<mailto:tomkcpr@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-creati...
<
https://serverfault.com/questions/705039/how-to-automate-directory-creati...
--
Cheers,
Tom K.
-------------------------------------------------------------------------------------
Living on earth is expensive, but it includes a
free trip around the sun.
_______________________________________________
FreeIPA-users mailing list --
freeipa-users(a)lists.fedorahosted.org
<mailto:freeipa-users@lists.fedorahosted.org>
To unsubscribe send an email to
freeipa-users-leave(a)lists.fedorahosted.org
<mailto:freeipa-users-leave@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-users(a)lists.fedorahosted.org
<mailto:freeipa-users@lists.fedorahosted.org>
To unsubscribe send an email to
freeipa-users-leave(a)lists.fedorahosted.org
<mailto:freeipa-users-leave@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(a)lists.fedorahosted.org
<mailto:sssd-users@lists.fedorahosted.org>
To unsubscribe send an email to
sssd-users-leave(a)lists.fedorahosted.org
<mailto:sssd-users-leave@lists.fedorahosted.org>
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org