Re: [Freeipa-users] SSSD Cache and Service Tickets
On 2017-05-15 21:27, Jakub Hrozek wrote: [...] On Mon, May 15, 2017 at 03:54:22PM +0200, Ronald Wimmer wrote: Hi, I am confronted with a behaviour for which I do not have an explanation for. I am using NFS4 Kerberos automounted homeshares and and recently I got a permission denied (reproducible when I restart autofs on the server I want to connect to) from the Windows Domain. So here's what I tried: 1) Connected via PuTTY from a Windows Machine in the windows domain Kerberos-based login works but I get a "Permission Denied" on my home directory; klist shows no tickets No tickets at all? Not even an expired ticket? Unfortunately no tickets. Does running klist in cmd.exe show anything? Yes, it does: -bash-4.2$ klist klist: Credentials cache keyring 'persistent:1073895519:1073895519' not found And again... If I connect from my linux machine (within the ipa domain), tickets are there: -bash-4.2$ klist Ticket cache: KEYRING:persistent:1073895519:1073895519 Default principal: myu...@mywindowdomain.at Valid starting Expires Service principal 2017-05-16 11:29:04 2017-05-16 15:43:45 nfs/ipanfs.myipadomain...@myipadomain.at 2017-05-16 11:25:09 2017-05-16 15:43:45 krbtgt/mywindowdomain...@mywindowdomain.at renew until 2017-05-16 15:43:45 From this point on login from windows (AD domain) does - of course - work. Any ideas how to bring some light into this? -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] SSSD Cache and Service Tickets
Hi, I am confronted with a behaviour for which I do not have an explanation for. I am using NFS4 Kerberos automounted homeshares and and recently I got a permission denied (reproducible when I restart autofs on the server I want to connect to) from the Windows Domain. So here's what I tried: 1) Connected via PuTTY from a Windows Machine in the windows domain Kerberos-based login works but I get a "Permission Denied" on my home directory; klist shows no tickets 2) I try to connect form a Linux machine belonging to the IPA domain Kerberos-based login works, I can also access my home directory; klist shows nfs/ipanfs.ipadomain...@ipadomain.at and the krbtgt for the windows domain 3) Now - of course - using the homeshares works from both domains windows and ipa 4) When I do a kdestroy on the machine, using the homeshare when logged in from windows still works - My question is WHY? Does SSSD cache the NFS ticket? (and why don't I get an nfs ticket when coming from the windows domain?) Regards Ronald -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] oddjob_mkhomedir troubles
On 2017-04-19 13:06, Ronald Wimmer wrote: [...] as the default directory (by setting override_homedir in sssd.conf) oddjob_mkhomedir creates the user directory but I still get a permission denied when logging in for the first time. (cd /home/user works) The only thing I see in the logs is: Apr 20 13:10:02 testclient systemd: Starting Session 1260 of user myu...@mydomain.at. Apr 20 13:10:02 testclient oddjob-mkhomedir[15879]: error setting permissions on /home/mydomain.at/myuser: Operation not permitted Apr 20 13:10:02 testclient dbus[770]: [system] Activating service name='org.freedesktop.problems' (using servicehelper) Apr 20 13:10:02 testclient dbus-daemon: dbus[770]: [system] Activating service name='org.freedesktop.problems' (using servicehelper) Apr 20 13:10:02 testclient dbus[770]: [system] Successfully activated service 'org.freedesktop.problems' Apr 20 13:10:02 testclient dbus-daemon: dbus[770]: [system] Successfully activated service 'org.freedesktop.problems' This is where PAM put the module: /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 Maybe it is not placed in the right line in /etc/pam.d/system-auth: session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd.so session optional pam_oddjob_mkhomedir.so umask=0077 session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so Is there a PAM expert around who can tell? Regards, Ronald -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] oddjob_mkhomedir troubles
I am trying to automount homeshares (defined in FreeIPA). Now I ran into a problem with oddjob_mkhomedir. By default an AD user would get a homedir that looks like /home/domain/user In this case oddjob_mkhomedir creates the domain-directory but not more. If I configure a client to use /home/user as the default directory (by setting override_homedir in sssd.conf) oddjob_mkhomedir creates the user directory but I still get a permission denied when logging in for the first time. (cd /home/user works) Neither case 1 nor case 2 are satisfying. Any ideas/hints/tricks/workarounds? Regards, Ronald -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] How to use automounted home shares?
Hi, I am implementing automounted home shares for all my IPA users. When thinking a little more about the topic two fundamental questions arose: - Is it a good idea to automount /home even if no local users exist at the moment? - Would it be better to leave local users in /home and place IPA users to e.g. /mnt/ipausers/home In both cases an IPA user would have 1 homedirectory for all ipa machines. This would mean 1 set of configuration files for RHEL 6/7, CentOS 6/7, Suse, Ubuntu and maybe some new distros to come at some point in time. Is this a good idea? How to solve the problem that some files (e.g. .profile or .bash_history) do only make sense on a per-host basis whereas others can be centrally managed? Your thoughts on this matter are highly appreciated! Regards, Ronald -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Problem automounting home shares
Here are my findings. The problem seems to be related to mkhomedir. By default my homedir looks like /home/%d/%u. In this case, when a user logs in for the first time /home/%d gets created and the %u part is missing. If I create it manually everything works fine. If i set override_homedir to /home/%u in the testclients sssd (nss section) settings the directory gets created and almost everything works fine. On the first login I get a "Could not chdir to home directory /home/myuser: No such file or directory" - the directory seems to get created to late. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Problem automounting home shares
I got a little further. Now the share also automounts on the client with sec set to krb5 but the user still gets a "Permission denied" and cannot access his home directory. Can it be related to the fact that the user comes from AD? (Unfortunately, I cannot test with a native IPA user due to another issue.) -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Problem automounting home shares
On 2017-04-13 14:24, Ronald Wimmer wrote:
> [...]
> It was my own fault. I somehow messed up the /etc/krb5.keytab on the
> testclient. After correcting it everything works like a charm.
No. It was notI was mistaken. The problem is:
- sec=sys
when I set sec=sys, the share gets automounted and the directory gets
created
with the right permissions but the user gets a "Permission denied"
fore some reason
- sec=krb5
the share does not even get automounted
sec=krb5p:
Apr 14 13:30:06 testclient automount[17792]: lookup_mount: lookup(sss):
looking up /home
Apr 14 13:30:06 testclient automount[17792]: lookup_mount: lookup(sss):
/home -> -fstype=nfs4,rw,sec=krb5p ipanfs.linux.mydomain.at:/homeshare
Apr 14 13:30:06 testclient automount[17792]: parse_mount: parse(sun):
expanded entry: -fstype=nfs4,rw,sec=krb5p
ipanfs.linux.mydomain.at:/homeshare
Apr 14 13:30:06 testclient automount[17792]: parse_mount: parse(sun):
gathered options: fstype=nfs4,rw,sec=krb5p
Apr 14 13:30:06 testclient automount[17792]: parse_mount: parse(sun):
dequote("ipanfs.linux.mydomain.at:/homeshare") ->
ipanfs.linux.mydomain.at:/homeshare
Apr 14 13:30:06 testclient automount[17792]: parse_mount: parse(sun):
core of entry: options=fstype=nfs4,rw,sec=krb5p,
loc=ipanfs.linux.mydomain.at:/homeshare
Apr 14 13:30:06 testclient automount[17792]: sun_mount: parse(sun):
mounting root /home, mountpoint /home, what
ipanfs.linux.mydomain.at:/homeshare, fstype nfs4, options rw,sec=krb5p
Apr 14 13:30:06 testclient automount[17792]: mount_mount: mount(nfs):
root=/home name=/home what=ipanfs.linux.mydomain.at:/homeshare,
fstype=nfs4, options=rw,sec=krb5p
Apr 14 13:30:06 testclient automount[17792]: mount_mount: mount(nfs):
nfs options="rw,sec=krb5p", nobind=0, nosymlink=0, ro=0
Apr 14 13:30:06 testclient automount[17792]: get_nfs_info: called with
host ipanfs.linux.mydomain.at(10.66.39.164) proto 6 version 0x40
Apr 14 13:30:06 testclient automount[17792]: get_nfs_info: nfs v4 rpc
ping time: 0.000265
Apr 14 13:30:06 testclient automount[17792]: get_nfs_info: host
ipanfs.linux.mydomain.at cost 265 weight 0
Apr 14 13:30:06 testclient automount[17792]: prune_host_list: selected
subset of hosts that support NFS4 over TCP
Apr 14 13:30:06 testclient automount[17792]: mount_mount: mount(nfs):
calling mkdir_path /home
Apr 14 13:30:06 testclient automount[17792]: mount_mount: mount(nfs):
calling mount -t nfs4 -s -o rw,sec=krb5p
ipanfs.linux.mydomain.at:/homeshare /home
Apr 14 13:30:06 testclient automount[17792]: spawn_mount: mtab link
detected, passing -n to mount
Apr 14 13:30:06 testclient gssproxy: gssproxy[889]: (OID: { 1 2 840
113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more
information, No credentials cache found
Apr 14 13:30:06 testclient automount[17792]: >> mount.nfs4: access
denied by server while mounting ipanfs.linux.mydomain.at:/homeshare
Apr 14 13:30:06 testclient automount[17792]: mount(nfs): nfs: mount
failure ipanfs.linux.mydomain.at:/homeshare on /home
Apr 14 13:30:06 testclient automount[17792]: dev_ioctl_send_fail: token
= 55
Apr 14 13:30:06 testclient automount[17792]: failed to mount /home
Apr 14 13:30:06 testclient automount[17792]: handle_packet: type = 5
Apr 14 13:30:06 testclient automount[17792]:
handle_packet_missing_direct: token 56, name /home, request pid 17808
Apr 14 13:30:06 testclient automount[17792]: dev_ioctl_send_fail: token
= 56
Apr 14 13:30:06 testclient automount[17792]: handle_packet: type = 5
Apr 14 13:30:06 testclient automount[17792]:
handle_packet_missing_direct: token 57, name /home, request pid 17808
Apr 14 13:30:06 testclient automount[17792]: dev_ioctl_send_fail: token
= 57
I would like to start with sec=sys - why doest the user get a permission
denied even if its home directory appears to have the right permissions?
Where do I have to look into?
Regards,
Ronald Wimmer
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Problem automounting home shares
On 2017-04-13 12:47, Ronald Wimmer wrote: On 2017-04-12 17:21, Jason B. Nance wrote: [...] You can still use autofs and mkhomdir, just use a direct mount for /home instead of indirect mounts. In other words, mount "/home" entirely vs. "/home/" individually. Thanks for clarification. I made a direct map for /home now that looks like: /home-fstype=nfs4,rw,sec=sys ipanfs.mydomain.at:/homeshare If i try to login on my testclient, the user home directory gets created. Permissions (UID/GID) are set correctly but the directory is still inaccessible for the user. My question is why? Is it because i set sec to sys here? When I set it to krb5, automount does not even mount /home It was my own fault. I somehow messed up the /etc/krb5.keytab on the testclient. After correcting it everything works like a charm. Regards, Ronald -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Problem automounting home shares
On 2017-04-12 17:21, Jason B. Nance wrote: [...] You can still use autofs and mkhomdir, just use a direct mount for /home instead of indirect mounts. In other words, mount "/home" entirely vs. "/home/" individually. Thanks for clarification. I made a direct map for /home now that looks like: /home-fstype=nfs4,rw,sec=sys ipanfs.mydomain.at:/homeshare If i try to login on my testclient, the user home directory gets created. Permissions (UID/GID) are set correctly but the directory is still inaccessible for the user. My question is why? Is it because i set sec to sys here? When I set it to krb5, automount does not even mount /home -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Problem automounting home shares
On 2017-04-12 14:55, Jason B. Nance wrote: [...] You cannot use indirect mounting and enablemkhomedir at the same time. Indirect mounts require that the directory you are attempting to mount already exists on the NFS server and that you let autofs fully manage the "parent" directory on the client machine. In this case, no one other than autofs can create directories in the top-level of /home on your clients (/home/ is a different story). So you either need to pre-create the home directories on your NFS server (including ownership, permissions, and any "skel" stuff you want in there like a default .bashrc) or you need to direct mount /home altogether and lose the benefits of indirect mounting (which may not matter to you). [...] So this means I can either use /home mounted as NFS share conventionally (without autofs) in combination with mkhomedir or use autofs magic with pre-created directories. As my users come from AD I do not even know which directories would have to be created in advance. So I will have to go for option 1. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] Problem automounting home shares
Hi, I am trying to automount user home shares from an NFS server. Up to now, without success. Some details regarding my setup: I have a CentOS 7.3 machine acting as an NFS server. It is a host within my IPA domain and enrolled as an IPA client. [root@ipanfs ~]# cat /etc/exports /homeshare *(rw,sec=krb5:krb5i:krb5p) I followed this guide https://blog.delouw.ch/2015/03/14/using-ipa-to-provide-automount-maps-for-nfsv4-home-directories/ I defined a automount location called ipauserhome. In this location I have a map called auto.home with this content: * -fstype=nfs4,rw,sec=krb5 ipanfs.linux.oebb.at:/homeshare/& On an ipa client I just did "ipa-client-automount --location=ipauserhome" and "authconfig --enablemkhomedir --update". When I login on the ipa client I get the error message "Could not chdir to home directory [...] No such file or directory.". I see that home is mounted on the client auto.home on /home type autofs (rw,relatime,fd=12,pgrp=1079,timeout=300,minproto=5,maxproto=5,indirect) [root@testclient ~]# ls -alh /home total 4,0K drwxr-xr-x. 2 root root0 12. Apr 10:22 . dr-xr-xr-x. 17 root root 4,0K 11. Apr 17:52 .. but for some reason it works not as expected. SELinux is set to permissive on both NFS server and the ipa client. Nevertheless, I get a suspicious message in /var/log/messages: Apr 12 10:22:48 testclient dbus[804]: [system] Successfully activated service 'org.fedoraproject.Setroubleshootd' Apr 12 10:22:48 testclient dbus-daemon: dbus[804]: [system] Successfully activated service 'org.fedoraproject.Setroubleshootd' Apr 12 10:22:49 testclient setroubleshoot: SELinux is preventing /usr/libexec/oddjob/mkhomedir from write access on the directory /. For complete SELinux messages. run sealert -l 76dd44bd-9ba6-4bf3-ba75-72834533cb0e Apr 12 10:22:49 testclient python: SELinux is preventing /usr/libexec/oddjob/mkhomedir from write access on the directory /.#012#012* Plugin catchall (100. confidence) suggests **#012#012If you believe that mkhomedir should be allowed write access on the directory by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'mkhomedir' --raw | audit2allow -M my-mkhomedir#012# semodule -i my-mkhomedir.pp#012 Apr 12 10:22:49 testclient setroubleshoot: SELinux is preventing /usr/libexec/oddjob/mkhomedir from write access on the directory /. For complete SELinux messages. run sealert -l 76dd44bd-9ba6-4bf3-ba75-72834533cb0e Apr 12 10:22:49 testclient python: SELinux is preventing /usr/libexec/oddjob/mkhomedir from write access on the directory /.#012#012* Plugin catchall (100. confidence) suggests **#012#012If you believe that mkhomedir should be allowed write access on the directory by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'mkhomedir' --raw | audit2allow -M my-mkhomedir#012# semodule -i my-mkhomedir.pp#012 Apr 12 10:22:49 testclient setroubleshoot: SELinux is preventing /usr/libexec/oddjob/mkhomedir from write access on the directory /. For complete SELinux messages. run sealert -l 76dd44bd-9ba6-4bf3-ba75-72834533cb0e Apr 12 10:22:49 testclient python: SELinux is preventing /usr/libexec/oddjob/mkhomedir from write access on the directory /.#012#012* Plugin catchall (100. confidence) suggests **#012#012If you believe that mkhomedir should be allowed write access on the directory by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'mkhomedir' --raw | audit2allow -M my-mkhomedir#012# semodule -i my-mkhomedir.pp#012 Apr 12 10:23:51 testclient automount[1079]: st_expire: state 1 path /home Apr 12 10:23:51 testclient automount[1079]: expire_proc: exp_proc = 139761696524032 path /home Apr 12 10:23:51 testclient automount[1079]: expire_cleanup: got thid 139761696524032 path /home stat 0 Apr 12 10:23:51 testclient automount[1079]: expire_cleanup: sigchld: exp 139761696524032 finished, switching from 2 to 1 Apr 12 10:23:51 testclient automount[1079]: st_ready: st_ready(): state = 2 path /home Apr 12 10:25:06 testclient automount[1079]: st_expire: state 1 path /home Where to look next? Regards, Ronald -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] SSSD setting memcache_timeout on ipa master
On 2017-04-10 13:23, Jakub Hrozek wrote: [...] This shouldn't be the case with 1.14+ and wasn't in my testing. Did you remove the cache (really remove, not just expire with sss_cache) after you upgraded from 1.13 to 1.14? If yes, can you run some simple systemtap scripts? I did not upgrade from an older version. I experienced the problems with SSSD 1.14. I followed the steps in the performance tuning guide and moved the cache directory into RAM. After that I deleted the directory's content and restarted SSSD. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] SSSD setting memcache_timeout on ipa master
On 2017-04-10 12:16, Lukas Slebodnik wrote: [...] sssd_be consumed a lot of CPU and produced a lot of I/O in the sssd cache directory. After following https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-ipa-ad-trust-deployments/ the problems did nod reappear. Did you try all recommended steps or just few? Do you know which one was the most useful in your case? I think the biggest benefit came from moving the sssd cache into RAM. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Password-based authentication with AD users does not work
On 2017-04-07 10:28, Sumit Bose wrote: [...] I'm not aware of any limitation here. Have you tried to run 'ipa trust-fetch-domains ad.forest.root' to update the list? If this does not help please add 'log level = 100' to /usr/share/ipa/smb.conf.empty so that it looks like: [global] log level = 100 and run trust-fetch-domains again. The debug output can then be found in /var/log/httpd/error_log. [...] Not one error in the error_log - absolutely nothing. Our AD guys confirmed that there are many more UPN suffixes than the five I can see when I run ipa trust-find. Can somebody confirm that this UPN suffix mismatch is exactly the problem preventing password-based login in my case? -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] SSSD setting memcache_timeout on ipa master
On 2017-04-08 12:53, Lukas Slebodnik wrote: On (04/04/17 09:41), Ronald Wimmer wrote: On 2017-03-31 13:35, Lukas Slebodnik wrote: On (29/03/17 10:47), Ronald Wimmer wrote: Hi, yesterday I suddenly was unable to use the webinterface of my ipa master. SSH login (with root user) did not work also. When I uncommented the setting "memcache_timeout = 600" in the sssd config file of the master everything seemed to work fine again. (my ipa setup has a trust to AD) I doubt it had anything to do memcache_timeout. I would say that restart of sssd helped. But it difficult to say without log files. either sssd logs or at least /var/log/secure (journald for pam). You were right. I uncommented the setting and the problem ocurred again. Did you find anything suspicious in journald? Is sssd_be busy (or any other process)? high CPU, IO operations ... It would be good to know more details. Restarting sssd is not a solution. sssd_be consumed a lot of CPU and produced a lot of I/O in the sssd cache directory. After following https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-ipa-ad-trust-deployments/ the problems did nod reappear. Regards, Ronald -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] SSSD hangs on IPA master
On 2017-04-08 12:49, Lukas Slebodnik wrote: [...] May I ask which version of sssd do you use? SSSD 1.14 -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Password-based authentication with AD users does not work
On 2017-04-06 20:50, Sumit Bose wrote: On Thu, Apr 06, 2017 at 01:55:02PM +0200, Ronald Wimmer wrote: On 2017-04-06 12:16, Sumit Bose wrote: On Thu, Apr 06, 2017 at 12:58:32PM +0200, Ronald Wimmer wrote: [...] AD trust: mydomain.at (forest root) xyz (subdomain -> where myuser resides) BCC (appearing in krb5_child.log) is not a domain here. It is my company's name and might derive from some information in the AD. Yes, it is about the userPrincipalName attribute read from AD. Which IPA server version do you use? Since RHEL-7.3 IPA supports those principals coming from AD. For older versions you should add a workaround which is e.g. described at the end of https://www.redhat.com/archives/freeipa-users/2016-November/msg00069.html HTH bye, Sumit I am using an up-to-date RHEL 7.3 IPA master. Is there no possibility to override it? Please check on the server with ipa trust-find if the BCC domain is listed as 'UPN suffixes:'. If not please try ipa trust-fetch-domains and check again. If the domain is listed then a 7.3 IPA client should be able to detect it automatically on older clients you should set 'krb5_use_enterprise_principal = True' manually in sssd.conf. I just checked with our AD guys. ipa trust-find only shows five UPN suffixes. There are many more which are not shown inlcuding bcc.mydomain.at Any idea why only a subset is shown? -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Password-based authentication with AD users does not work
Zitat von Sumit Bose <sb...@redhat.com>: On Thu, Apr 06, 2017 at 01:55:02PM +0200, Ronald Wimmer wrote: On 2017-04-06 12:16, Sumit Bose wrote: > On Thu, Apr 06, 2017 at 12:58:32PM +0200, Ronald Wimmer wrote: > [...] > > AD trust: > > mydomain.at (forest root) > > xyz (subdomain -> where myuser resides) > > > > BCC (appearing in krb5_child.log) is not a domain here. It is my company's > > name and might derive from some information in the AD. > Yes, it is about the userPrincipalName attribute read from AD. Which IPA > server version do you use? Since RHEL-7.3 IPA supports those principals > coming from AD. For older versions you should add a workaround which is > e.g. described at the end of > https://www.redhat.com/archives/freeipa-users/2016-November/msg00069.html > > HTH > > bye, > Sumit I am using an up-to-date RHEL 7.3 IPA master. Is there no possibility to override it? Please check on the server with ipa trust-find if the BCC domain is listed as 'UPN suffixes:'. If not please try ipa trust-fetch-domains and check again. If the domain is listed then a 7.3 IPA client should be able to detect it automatically on older clients you should set 'krb5_use_enterprise_principal = True' manually in sssd.conf. Unfortunately, ipa trust-find shows some UPN suffixes but BCC is not in the list. Any other options left? -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Password-based authentication with AD users does not work
On 2017-04-06 12:16, Sumit Bose wrote: On Thu, Apr 06, 2017 at 12:58:32PM +0200, Ronald Wimmer wrote: [...] AD trust: mydomain.at (forest root) xyz (subdomain -> where myuser resides) BCC (appearing in krb5_child.log) is not a domain here. It is my company's name and might derive from some information in the AD. Yes, it is about the userPrincipalName attribute read from AD. Which IPA server version do you use? Since RHEL-7.3 IPA supports those principals coming from AD. For older versions you should add a workaround which is e.g. described at the end of https://www.redhat.com/archives/freeipa-users/2016-November/msg00069.html HTH bye, Sumit I am using an up-to-date RHEL 7.3 IPA master. Is there no possibility to override it? -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Password-based authentication with AD users does not work
On 2017-04-06 12:58, Ronald Wimmer wrote: [...] BCC (appearing in krb5_child.log) is not a domain here. It is my company's name and might derive from some information in the AD. After doing an LDAP search on the domain controller of my AD domain (xyz.mydomain.at) I found out that my userPrincipalName is myu...@bcc.mydomain.at - this can definitely not be changed! -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Password-based authentication with AD users does not work
On 2017-04-06 11:21, Sumit Bose wrote: On Thu, Apr 06, 2017 at 12:10:29PM +0200, Ronald Wimmer wrote: Hi, when I try to login to an IPA client with my AD user it works perfectly when I already have a kerberos ticket for my user. When I do not and I try a password-based login it fails: Please send the sssd_domain.log and krb5_child.log form the same time as well. AD trust: mydomain.at (forest root) xyz (subdomain -> where myuser resides) BCC (appearing in krb5_child.log) is not a domain here. It is my company's name and might derive from some information in the AD. sssd_domain.log snippet: [] (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [sbus_dispatch] (0x4000): dbus conn: 0x7f14f467feb0 (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [sbus_dispatch] (0x4000): Dispatching. (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.dataprovider.pamHandler on path /org/freedesktop/sssd/dataprovider (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [dp_pam_handler] (0x0100): Got request with the following data (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [pam_print_data] (0x0100): command: SSS_PAM_AUTHENTICATE (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [pam_print_data] (0x0100): domain: XYZ (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [pam_print_data] (0x0100): user: myu...@xyz.mydomain.at (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [pam_print_data] (0x0100): service: sshd (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [pam_print_data] (0x0100): tty: ssh (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [pam_print_data] (0x0100): ruser: (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [pam_print_data] (0x0100): rhost: chupacabra.ipa.mydomain.at (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [pam_print_data] (0x0100): authtok type: 1 (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [pam_print_data] (0x0100): newauthtok type: 0 (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [pam_print_data] (0x0100): priv: 1 (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [pam_print_data] (0x0100): cli_pid: 31812 (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [pam_print_data] (0x0100): logon name: not set (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [dp_attach_req] (0x0400): DP Request [PAM Authenticate #15]: New request. Flags []. (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [dp_attach_req] (0x0400): Number of active DP request: 1 (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [krb5_auth_queue_send] (0x1000): Wait queue of user [myu...@xyz.mydomain.at] is empty, running request [0x7f14f4670f70] immediately. (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [krb5_setup] (0x4000): No mapping for: myu...@xyz.mydomain.at (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7f14f468c030 (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x7f14f468c0f0 (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [ldb] (0x4000): Running timer event 0x7f14f468c030 "ltdb_callback" (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [ldb] (0x4000): Destroying timer event 0x7f14f468c0f0 "ltdb_timeout" (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [ldb] (0x4000): Ending timer event 0x7f14f468c030 "ltdb_callback" (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7f14f46aad10 (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x7f14f468c4a0 (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [ldb] (0x4000): Running timer event 0x7f14f46aad10 "ltdb_callback" (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [ldb] (0x4000): Destroying timer event 0x7f14f468c4a0 "ltdb_timeout" (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [ldb] (0x4000): Ending timer event 0x7f14f46aad10 "ltdb_callback" (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [get_server_status] (0x1000): Status of server 'ipa1.ipa.mydomain.at' is 'working' (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [get_port_status] (0x1000): Port status of port 0 for server 'ipa1.ipa.mydomain.at' is 'working' (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6 seconds (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [get_s
[Freeipa-users] Password-based authentication with AD users does not work
Hi, when I try to login to an IPA client with my AD user it works perfectly when I already have a kerberos ticket for my user. When I do not and I try a password-based login it fails: Password-based: (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_check_user_search] (0x0400): Returning info for user [myu...@xyz.mydomain.at@xyz.mydomain.at] (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pd_set_primary_name] (0x0400): User's primary name is myu...@xyz.mydomain.at (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending request with the following data: (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): command: SSS_PAM_PREAUTH (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): domain: XYZ (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): user: myu...@xyz.mydomain.at (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): service: sshd (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): rhost: chupacabra.ipa.mydomain.at (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 0 (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 31816 (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): logon name: myuser (Thu Apr 6 10:39:12 2017) [sssd[pam]] [sbus_add_timeout] (0x2000): 0x7f4c122ed450 (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_dom_forwarder] (0x0100): pam_dp_send_req returned 0 (Thu Apr 6 10:39:12 2017) [sssd[pam]] [sbus_remove_timeout] (0x2000): 0x7f4c122ed450 (Thu Apr 6 10:39:12 2017) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f4c122e59c0 (Thu Apr 6 10:39:12 2017) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_dp_process_reply] (0x0200): received: [4 (System error)][XYZ] (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [4]: System error. (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_reply] (0x0200): blen: 20 (Thu Apr 6 10:39:12 2017) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x7f4c122f4640][21] When I have a Kerberos ticket: (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_check_user_search] (0x0400): Returning info for user [myu...@xyz.mydomain.at@xyz.mydomain.at] (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pd_set_primary_name] (0x0400): User's primary name is myu...@xyz.mydomain.at (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending request with the following data: (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): command: SSS_PAM_OPEN_SESSION (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): domain: XYZ (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): user: myu...@xyz.mydomain.at (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): service: sshd (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): rhost: chupacabra.ipa.mydomain.at (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 0 (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 31841 (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): logon name: myuser (Thu Apr 6 10:41:00 2017) [sssd[pam]] [sbus_add_timeout] (0x2000): 0x7f4c122ec4a0 (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_dom_forwarder] (0x0100): pam_dp_send_req returned 0 (Thu Apr 6 10:41:00 2017) [sssd[pam]] [sbus_remove_timeout] (0x2000): 0x7f4c122ec4a0 (Thu Apr 6 10:41:00 2017) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f4c122e59c0 (Thu Apr 6 10:41:00 2017) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_dp_process_reply] (0x0200): received: [0 (Success)][XYZ] (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [0]: Success. (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_reply] (0x0200): blen: 20 (Thu Apr 6 10:41:00 2017) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x7f4c122f4640][21] My question is why? Regards, Ronald -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] SSSD hangs on IPA master
On 2017-04-04 11:19, Jakub Hrozek wrote: On Tue, Apr 04, 2017 at 09:51:04AM +0200, Ronald Wimmer wrote: Hi, my IPA master has an AD trust (several thousand users). Since the trust has been set up I am experiencing that I cannot login on the web interface. Even connecting via SSH does not work or takes extremely long. When I managed to log in as root via SSH (after waiting and trying several times or rebooting the machine) I could not restart SSSD (systemctl restart sssd). I had to kill the SSSD processes manually and then everything seemed to work fine again. What could be going on? Could the SSSD cache be to big (122M)? Where should I take a deeper look? Any hints are highly appreciated! SSSD logs that capture the problem are always a good start. I found out that the CPU was quite busy (sssd_be process) and that there was a lot I/O in the cache directory. So I upgraded from 1 to 4 virtual CPUs and followed your recommendations regarding large deployments: https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-ipa-ad-trust-deployments/ No problems so far... Regards, Ronald -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] SSSD hangs on IPA master
Hi, my IPA master has an AD trust (several thousand users). Since the trust has been set up I am experiencing that I cannot login on the web interface. Even connecting via SSH does not work or takes extremely long. When I managed to log in as root via SSH (after waiting and trying several times or rebooting the machine) I could not restart SSSD (systemctl restart sssd). I had to kill the SSSD processes manually and then everything seemed to work fine again. What could be going on? Could the SSSD cache be to big (122M)? Where should I take a deeper look? Any hints are highly appreciated! Regards, Ronald -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] SSSD setting memcache_timeout on ipa master
On 2017-03-31 13:35, Lukas Slebodnik wrote: On (29/03/17 10:47), Ronald Wimmer wrote: Hi, yesterday I suddenly was unable to use the webinterface of my ipa master. SSH login (with root user) did not work also. When I uncommented the setting "memcache_timeout = 600" in the sssd config file of the master everything seemed to work fine again. (my ipa setup has a trust to AD) I doubt it had anything to do memcache_timeout. I would say that restart of sssd helped. But it difficult to say without log files. either sssd logs or at least /var/log/secure (journald for pam). You were right. I uncommented the setting and the problem ocurred again. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Register IPA-Clients within AD domain
On 2017-03-29 11:06, Alexander Bokovoy wrote: On ke, 29 maalis 2017, Ronald Wimmer wrote: [...] Read http://www.freeipa.org/page/V4/IPA_Client_in_Active_Directory_DNS_domain There are also higher level description at http://rhelblog.redhat.com/2016/07/13/i-really-cant-rename-my-hosts/ Thanks a lot! -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] SSSD setting memcache_timeout on ipa master
Hi, yesterday I suddenly was unable to use the webinterface of my ipa master. SSH login (with root user) did not work also. When I uncommented the setting "memcache_timeout = 600" in the sssd config file of the master everything seemed to work fine again. (my ipa setup has a trust to AD) Can anybody explain why this was happening? Regards, Ronald -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] Register IPA-Clients within AD domain
Hi, the documentation states "[...] Client machines do not need to be in the same domain as FreeIPA servers. For example, FreeIPA may be a domain ipa.example.com and clients in domain clients.example.com, there just need to be a clear mapping between DNS domain and Kerberos realm. [...]" Can clients be registered properly if the clients.example.com domain is an existing Active Directory domain which - of course - already has _kerberos entries in DNS? Regards, Ronald -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
