Re: [Freeipa-users] Freeipa and limiting access by group (memberOf)

2017-05-18 Thread Jakub Hrozek
On Thu, May 18, 2017 at 10:37:57AM -0600, Janet Houser wrote:
> 
> 
> On 5/17/17 9:22 AM, Jakub Hrozek wrote:
> > On Tue, May 16, 2017 at 07:56:38AM -0600, Janet Houser wrote:
> > > Hi Folks,
> > > 
> > > Last week I deployed freeipa on a CentOS7 VM.   The installation went very
> > > smoothly using:
> > > 
> > >  yum install ipa-server
> > > 
> > > and
> > > 
> > >  ipa-server-install
> > > 
> > > 
> > > My issue is with connecting a CentOS 7 client.  On my client, I yum
> > > installed  ipa-client and ipa-admintools.
> > > I than ran  "ipa-client-install"  and answered the setup questions (very
> > > easy and smooth).
> > > 
> > > The "getent passwd" command didn't return any users, but the "getent 
> > > passwd
> > > jdoe" does give the information
> > > for the user.   I found in the archives that I can set "enumerate=True" 
> > > so I
> > > get a complete user listing.   That
> > > seems to be working, and I was able to login with the account "jdoe"
> > > (brilliant!).
> > I would discourage enumeration especially if you're planning on a large
> > domain. The performance right now is not great. Moreover, the way the
> > trusted accounts are retrieved doesn't support enumeration at all
> > either.
> 
> Copy that.  Enumeration is set to true just for testing.  It will be
> disabled later.
> > 
> > > Problem 1:
> > > 
> > > 
> > > I created a user group on the ipa server  with the following attributes:
> > > 
> > > name = xyx,  gid = 1000
> > > 
> > > I changed the user "jdoe" to have gid = 1000, but when I ssh into the ipa
> > > client, I get the following message after
> > > logging in:
> > > 
> > > /usr/bin/id: cannot find name for group ID 1000
> > > 
> > > A "getent group" command does list the group: xyz:*:1000:
> > > 
> > > A "groups" command issued by the user shows:   xyz
> > > 
> > > files created by the user show the correct ownership and group.
> > I would first try to remove the sssd caches because uid/gid renumbering
> > doesn't work great. If that doesn't help, please check the sssd logs.
> 
> Didn't work, and the logs aren't really being helpful, but I'll dig further.

Feel free to paste some sanitized snippet here..

> 
> > 
> > By the way, 1000 is quite low and would most probably clash with local
> > accounts. I would strongly suggest to stick to ID numbers within the
> > configured ID range (ipa idrange-find)
> > 
> > > Problem 2:
> > > ===
> > > 
> > > I've been looking through the freeipa groups and literature and I can't
> > > figure out how to limit user login access to
> > > an ipa client by a memberOf group.
> > > 
> > > When I was using CentOS 6 and 7 I could use the nslcd.conf file to put in 
> > > a
> > > group filter like:
> > > 
> > > passwd 
> > > (&(objectClass=posixAccount)(memberOf=CN=test,OU=Groups,DC=abc,DC=xyx,DC=edu))
> > > 
> > > 
> > > I tried changing the access_provider to simple and using the
> > > "simply_allow_groups = test", but that didn't work.
> > > However, using "access_provider = ipa" and "filter_users" did allow me to
> > > filter out a user from the "getent passwd" command.
> > > 
> > > I tried changing the access_provider to ldap and using the filter
> > > "ldap_access_filter = memberOf=cn=test=OU=Groups,DC=abc,DC=xyx,DC=edu
> > > but that failed too.
> > Please check out "ipa help hbac"
> > 
> I just realized hbac is host based access control.   I can't really use this
> since I need to restrict certain users
> to resources.   Since freeipa is based on directory server 389, I'm assuming
> it can do group / memberOf filtering.

What are the resources we're talking about here?

> 
> Any suggestions would be appreciated.

-- 
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] Freeipa and limiting access by group (memberOf)

2017-05-17 Thread Jakub Hrozek
On Tue, May 16, 2017 at 07:56:38AM -0600, Janet Houser wrote:
> Hi Folks,
> 
> Last week I deployed freeipa on a CentOS7 VM.   The installation went very
> smoothly using:
> 
> yum install ipa-server
> 
> and
> 
> ipa-server-install
> 
> 
> My issue is with connecting a CentOS 7 client.  On my client, I yum
> installed  ipa-client and ipa-admintools.
> I than ran  "ipa-client-install"  and answered the setup questions (very
> easy and smooth).
> 
> The "getent passwd" command didn't return any users, but the "getent passwd
> jdoe" does give the information
> for the user.   I found in the archives that I can set "enumerate=True" so I
> get a complete user listing.   That
> seems to be working, and I was able to login with the account "jdoe"
> (brilliant!).

I would discourage enumeration especially if you're planning on a large
domain. The performance right now is not great. Moreover, the way the
trusted accounts are retrieved doesn't support enumeration at all
either.

> 
> Problem 1:
> 
> 
> I created a user group on the ipa server  with the following attributes:
> 
>name = xyx,  gid = 1000
> 
> I changed the user "jdoe" to have gid = 1000, but when I ssh into the ipa
> client, I get the following message after
> logging in:
> 
> /usr/bin/id: cannot find name for group ID 1000
> 
> A "getent group" command does list the group: xyz:*:1000:
> 
> A "groups" command issued by the user shows:   xyz
> 
> files created by the user show the correct ownership and group.

I would first try to remove the sssd caches because uid/gid renumbering
doesn't work great. If that doesn't help, please check the sssd logs.

By the way, 1000 is quite low and would most probably clash with local
accounts. I would strongly suggest to stick to ID numbers within the
configured ID range (ipa idrange-find)

> 
> Problem 2:
> ===
> 
> I've been looking through the freeipa groups and literature and I can't
> figure out how to limit user login access to
> an ipa client by a memberOf group.
> 
> When I was using CentOS 6 and 7 I could use the nslcd.conf file to put in a
> group filter like:
> 
> passwd 
> (&(objectClass=posixAccount)(memberOf=CN=test,OU=Groups,DC=abc,DC=xyx,DC=edu))
> 
> 
> I tried changing the access_provider to simple and using the
> "simply_allow_groups = test", but that didn't work.
> However, using "access_provider = ipa" and "filter_users" did allow me to
> filter out a user from the "getent passwd" command.
> 
> I tried changing the access_provider to ldap and using the filter
> "ldap_access_filter = memberOf=cn=test=OU=Groups,DC=abc,DC=xyx,DC=edu
> but that failed too.

Please check out "ipa help hbac"

-- 
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 Cache and Service Tickets

2017-05-15 Thread Jakub Hrozek
First, I'm sorry if this mail is not helpful enough, I'm really just replying
to the part I'm familiar with

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?

Does running klist in cmd.exe show anything?

> 
> 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?

It does not. The only code in SSSD that caches anything Kerberos related
is the KRB5CCNAME variable value.

> (and why don't I get an nfs ticket when coming from the windows domain?)

-- 
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] Users can't login on some systems.

2017-05-05 Thread Jakub Hrozek
On Fri, May 05, 2017 at 11:58:42AM +, Lakshan Jayasekara wrote:
> Ipa user authentication failure on centos client. Login using a valid account 
> and login success for other ipa client servers. It would be great if you can 
> provide any hind or any modification to overcome the situation.

Things I'd try are:
- make sure the user resolves on the target system
- run ipa hbactest to see if the user should be permitted access
- check /var/log/secure and see what does pam_sss return
- increase debug_level in sssd.conf on the client and see what the sssd debug 
logs yield

-- 
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] ubuntu 16.04 freeipa-client + sssd + sudo: "policy plugin returns 0"

2017-05-03 Thread Jakub Hrozek
On Wed, May 03, 2017 at 09:04:05AM +0100, Brian Candler wrote:
> Hi,
> 
> I have FreeIPA set up under CentOS 7.  When I use freeipa-client to add an
> ubuntu 14.04 client it works fine (*). However when do the same with ubuntu
> 16.04, sudo always refuses to run:
> 
> $ sudo -s
> [sudo] password for brian.candler:
> brian.candler is not allowed to run sudo on api-dev.int.example.com.  This
> incident will be reported.
> 
> I have a simple one-entry sudo policy which says that for all users in
> groups X and Y, on all hosts, run all commands.  (**)
> 
> If I crank up sudo logging by setting this in /etc/sudo.conf:
> 
> Debug sudo /var/log/sudo-debug all@info
> 
> then on the working 14.04 machine I see
> 
> ... various settings ...
> May  2 22:05:27 sudo[19175] settings: plugin_dir=/usr/lib/sudo/
> May  2 22:05:27 sudo[19175] user_info: user=brian.candler
> May  2 22:05:27 sudo[19175] user_info: pid=19175
> ... lots more user_info, perms, netgroups etc ...
> May  2 22:05:29 sudo[19175] policy plugin returns 1
> ...
> 
> but on the failing 16.04 machine I see only this:
> 
> May  3 07:44:56 sudo[21118] will restore signal 13 on exec
> May  3 07:44:56 sudo[21118] comparing dev 34817 to /dev/pts/1: match! @
> sudo_ttyname_dev() ./ttyname.c:336
> May  3 07:44:56 sudo[21118] settings: run_shell=true
> May  3 07:44:56 sudo[21118] settings: progname=sudo
> May  3 07:44:56 sudo[21118] settings: network_addrs=x.x.x.x/255.255.255.0
> :::::230/:::::::
> fe80::1:::/:::::
> May  3 07:44:56 sudo[21118] settings: plugin_dir=/usr/lib/sudo/
> May  3 07:44:58 sudo[21118] policy plugin returns 0
> 
> That's all that gets logged - nothing more.  It seems that a return of 0
> means failure:
> 
> https://www.sudo.ws/man/1.8.15/sudo_plugin.man.html
> 
> "open()
> ...
> Returns 1 on success, 0 on failure, -1 if a general error occurred, or -2 if
> there was a usage error."
> 
> But I have no idea what sort of failure or why.
> 
> /var/log/auth.log shows:
> 
> May  3 08:00:14 api-dev sudo: pam_unix(sudo:auth): authentication failure;
> logname=brian.candler uid=121103 euid=0 tty=/dev/pts/1
> ruser=brian.candler rhost=  user=brian.candler
> May  3 08:00:14 api-dev sudo: pam_sss(sudo:auth): authentication success;
> logname=brian.candler uid=121103 euid=0 tty=/dev/pts/1
> ruser=brian.candler rhost= user=brian.candler
> May  3 08:00:14 api-dev sudo: brian.candler : user NOT in sudoers ;
> TTY=pts/1 ; PWD=/home/brian.candler ; USER=root ; COMMAND=/bin/bash
> 
> (which shows I gave the correct FreeIPA password, but not why the sudoers
> lookup failed)
> 
> I really can't see where else to look. Both machines have "sudo: files sss"
> in /etc/nsswitch.conf, and both have the same /etc/sssd/sssd.conf.  Setting
> "sss_debuglevel 7" and "sss_cache -UG" shows a lot of noise but no obvious
> errors.

do you have 'sudo: files sss" or "sudoers: files sss"? The former
doesn't do anything, the latter is correct.

if you crank up debugging in the sudo section in sssd.conf do you see
any activity at all?

do you have '/usr/lib64/libsss_sudo.so' installed? On fedora/rhel, this
is provided by libsss_sudo, I don't know what provides it on Debian.

> 
> I've also upgraded to the latest sudo_1.8.19-3_amd64.deb package from
> https://www.sudo.ws/download.html, but this makes no difference.
> 
> Has anyone seen this problem before, or have some ideas where else to look?
> 
> Thanks,
> 
> Brian Candler.
> 
> 
> (*) In Ubuntu 14.04 I had to manually add sudo to the list of sssd services:
> 
> |[sssd]|
> |services = nss, pam, ssh, sudo|
> 
> but this was done automatically by freeipa-client in Ubuntu 16.04.
> 
> (**) Therefore I'm pretty sure this is not the netgroups problem, for which
> the fix has been released anyway:
> https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1607666

> -- 
> 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

-- 
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] add trust between FreeIPA and Samba AD DC

2017-04-28 Thread Jakub Hrozek
On Fri, Apr 28, 2017 at 07:27:20PM +0200, Tiemen Ruiten wrote:
> Hello Alexander, list,
> 
> I did get further by specifying --external=true in the ipa trust-add
> command, it works now for *both* the Windows and the Samba domain:
> 
> ipa trust-add office.rdmedia.com --type=ad --admin Administrator --password
> --two-way=false --external=true
> 
> IPA reports the trust is established successfully and I can also see it in
> Active Directory Domains and Trusts. However, adding users/groups to an
> external group fails:
> 
> [root@ipa-ams-01 tiemen]# ipa group-add-member office_admins_external
> --external "OFFICE\domain admins"
> [member user]:
> [member group]:
>   Group name: office_admins_external
>   Description: office.rdmedia.com admins external map
>   Failed members:
> member user:
> member group: *OFFICE\domain admins: trusted domain object not found*
> -
> Number of members added 0
> -

Domain Admins is a domain-local group typically. I would advise against
using those for cross-forest trust memberships in general.

Can you also check if you can resolve objects from the trusted AD/Samba
domain? Try:
getent passwd administra...@office.rdmedia.com
for example.

-- 
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] Malformed representation of principal - krb5_child.log

2017-04-28 Thread Jakub Hrozek
On Fri, Apr 28, 2017 at 03:28:31PM +, Sullivan, Daniel [CRI] wrote:
> Hi, Sumit,
> 
> Thank you for taking the time to respond to me.  I tried that; it did not 
> work.  I am using sssd 1.14.0-3.el6.  Any other support you (or anybody else) 
> could provide would be greatly appreciated.

Do you remember where did you install this RPM from? I don't think we ever
released 1.14 for el6 via RHEL.

(yum info sssd would tell you I think)

-- 
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] How do you have users be given a local group?

2017-04-25 Thread Jakub Hrozek
On Tue, Apr 25, 2017 at 02:43:11PM -0400, g...@greg-gilbert.com wrote:
> I saw this question come up way back in the archives, so I thought I'd
> ask to see if there's a better way to do it. 
> 
> Basically I want users who log into my servers that run the FreeIPA
> client to be given the local usergroup DOCKER.

I think this is what you're looking for:
https://sourceware.org/glibc/wiki/Proposals/GroupMerging

If you're running a libc version that supports this feature, you'd
define the docker group on the IPA side with the same GID, then SSSD
would deliver the group to libc and libc would merge the results from
the local and the remote groups.

> Is there a way to do
> that? Is it controlled from the FreeIPA server, or is it something (e.g.
> PolicyKit?) that needs to be run on each client? 

PolicyKit is the piece that enforces a policy decision based on the
group membership, the trick here is to merge local and remove groups.

> 
> If it matters, the clients are running Ubuntu 16.04. 

I'm sorry, I don't know if this feature is present Ubuntu 16.04..

-- 
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] ldap.conf

2017-04-12 Thread Jakub Hrozek
On Wed, Apr 12, 2017 at 09:47:06AM +0200, Jakub Hrozek wrote:
> You can drop this line as well, it's the default for the AD provider.
s/AD/IPA/

-- 
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] ldap.conf

2017-04-12 Thread Jakub Hrozek
On Wed, Apr 12, 2017 at 09:30:38AM +0200, Christoph Kaminski wrote:
> Hi
> 
> are the files /etc/ldap.conf and /etc/openldap/ldap.conf for ipa client 
> and/or server systeme necessary? What is the function of them?

They configure the openldap library. If you have an application (like
ldapsearch) that links against libldap, it reads the config from these
files. That's the same as libkrb5 and /etc/krb5.conf btw.

-- 
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] ldap.conf

2017-04-12 Thread Jakub Hrozek
On Wed, Apr 12, 2017 at 09:34:59AM +0200, Christoph Kaminski wrote:
> Hi
> 
> is this ok as config for sssd on centos 7 AND 6?
> 
> [domain/hso]
> cache_credentials = True
> krb5_store_password_if_offline = True
> id_provider = ipa
> ldap_tls_cacert = /etc/ipa/ca.crt

You can drop this line as well, it's the default for the AD provider.

> 
> [sssd]
> services = nss, pam, ssh, sudo, autofs
> config_file_version = 2
> domains = hso
> 
> [nss]
> 
> [pam]
> 
> [sudo]
> 
> [autofs]
> 
> [ssh]
> 
> I mean it works but would I get any problems with it?

No, the configs are supposed to be minimal.

You can even drop the empty service sections like [nss].

-- 
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] SSH access to only specific hosts useding ssh keys

2017-04-12 Thread Jakub Hrozek
On Tue, Apr 11, 2017 at 10:50:34PM -0400, Tym Rehm wrote:
> So I want a user "bob" to ssh into server1 as the username of "support"
> with support@server1, but not let Bob ssh into support@server2. I have
> Bob's ssh public key added to the support user. I can block Bob from
> server1 or server2 with HBAC, but I have to add support to both servers and
> since Bob's keys are added to Support. The support account is able to ssh
> into both servers.

Yeah, I think id views could help here, but I haven't tested it myself.

> 
> I've looked into ID view, but I'm having troubles find a good document on
> how to setup ID views.

Does this help?

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/id-views.html

-- 
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

2017-04-10 Thread Jakub Hrozek
On Mon, Apr 10, 2017 at 01:07:08PM +0200, Ronald Wimmer wrote:
> 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.

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?

-- 
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] SSH access to only specific hosts useding ssh keys

2017-04-10 Thread Jakub Hrozek
On Mon, Apr 10, 2017 at 12:04:58AM -0400, Tym Rehm wrote:
> Hey all, New user here.
> 
> I have a user "user1" that I want to allow a couple of different users
> "userX and userY" to be allowed to ssh into "server1" and "server2", but
> not both servers using ssh-keys.
> 
> So as an example. UserX will ssh user1@server2 with ssh-key, but I don't
> want userY to be able to successfully run the same command.
> 
> I currently have userX and userY's public ssh-key attached to user1 and I
> have created a HBAC rule to allow user1 to connect with ssh on both server1
> and server2. This is allowing user1 to connect to both servers fine,
> without a password. It also is allowing users (X & Y) to ssh user1@server1
> and user1@server2.
> 
> How can stop that to restrict userX to be able to ssh as user1 on server1,
> but not server2?
> 
> Do I need to do something with the keytabs or add the ssh-keys for userX to
> the server1 host only?

I'm honestly not sure if I understand the problem well, but would it be
helpful to add SSH keys to an ID view that is attached to one of the
servers only?

-- 
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] Fwd: Marking subdomain offline

2017-04-07 Thread Jakub Hrozek
On Thu, Apr 06, 2017 at 02:39:02PM -0400, Chris Dagdigian wrote:
> 
> I see similar things in our environment where IPA is used as "glue" between
> AD Forests that have a 1-way trust relationship. We believe that the root
> cause has something to do with the 30+ domain controllers the IPA client
> tries to make contact with (in seemingly random order) across the AD Forest.

When an AD user logs to an IPA client, there are actually two actions --
a user lookup and the authentication.

The user lookup is in fact done by the SSSD instance running on one of
the IPA masters, the clients just talks to the masters, but the SSSD on
the master talks to one AD DCs.

Authentication is done directly against one of AD DCs.


> Very hard to reproduce but the "subdomain marked offline" problem is one we
> see often in the sssd logs. We think that there are some AD servers in our
> sprawling environment that we either can't reach properly over the network
> (firewalls, etc.) or are just plain not configured to talk properly to us.
> Login success depends on hitting a happy domain controller.
> 
> We are VERY interested in the recent updates to IPA server that seem to
> indicate we can 'pin" clients to certain specific AD controllers and from my
> understanding we just need to wait until the SSSD software gets broad
> support for this feature as well. Once we can do that we plan to pin our
> clients to named controllers and see if that helps with any of the
> intermittent login problems.

I don't think there are any changes needed to the the IPA server (maybe
some management framework), but in general you're looking for this
feature:
https://docs.pagure.org/SSSD.sssd/design_pages/subdomain_configuration.html

(after we migrated the upstream projects from fedorahosted to pagure,
our documentation is still in a bit of a flux, but we're migrating the
docs gradually..)

As the design page says, you will be able to set up the AD DCs the IPA
masters talk to using the subdomain configuration, but the DCs the
clients authenticate to must currently be set in krb5.conf on the
clients until https://pagure.io/SSSD/sssd/issue/3336 is implemented.

> 
> One workaround we've started to use for power users is collecting public SSH
> keys and hosting them in the IPA server -- as long as IPA knows that the
> user "exists" in AD and has a roughly complete group membership list than
> logging in with SSH key instead of AD password bypasses the transient
> password checking failures and is very quick.

Another workaround (for the IPA masters at least) would be to put the
reachable AD DCs into a site and assign the IPA masters to this site.

-- 
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] Fwd: Marking subdomain offline

2017-04-06 Thread Jakub Hrozek
On Thu, Apr 06, 2017 at 07:21:01PM +0200, m...@chinewalking.com wrote:
> Hi,
> 
> My IPA<->AD trust setup experiences intermittent failures during login
> events. The AD subdomain goes in an inactive/offline state and users logging
> in are put into a 'delayed authentication' queue. Usually logging in after a
> minute or so succeeds as the subdomain is reset and the user is cached for
> following events. At all times getent/id and kinit's are succesfull, even
> with a purged sssd cache.
> SRV records are correctly resolved, except for _kerberos-master.
> 
> I have not been able to further troubleshoot the intermittent failures.
> Traffic captures show no strange behaviour, yet the sssd_domain log is
> clearly showing AD to be unreachable at times. All AD servers are W2012 and
> DNS masking _ldap and _kerberos to single nodes, factoring out any faulty
> Windows configs, so far has not had any effect (Would it?).
> 
> sssd's data_provider_fo.c :> be_fo_reset_svc() calls fo_get_service(), which
> returns EOK. I'm not familiar yet with the variables at play, would adding
> debug statements here reveal faults that may cause this?

Could you paste a bit more context? I think what would work is to trim
the logs (truncate --size 0), then reproduce the issue and search for
the first occurence of "NOT_WORKING" message from any of the fo_*
functions.

-- 
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] How long should it take to propagate user role changes?

2017-04-06 Thread Jakub Hrozek
On Thu, Apr 06, 2017 at 09:11:32AM +0200, Martin Bašti wrote:
> 
> 
> On 06.04.2017 01:57, Greg Gilbert wrote:
> > Hey. I'm a bit new to FreeIPA, so apologies if this has already been
> > addressed. For reference, I'm running FreeIPA 4.4 server on CentOS 7,
> > and FreeIPA client 4.3.1 on Ubuntu nodes.
> > 
> > I've noticed that when I make changes to policies, it either takes a
> > long time to propagate out to the client nodes, or requires a manual
> > restart of the sssd service. In this case, I'm testing adding and
> > removing a user from a sudo rule. Is this the correct behavior, or is
> > there a misconfiguration on my part somewhere?
> > 
> > - greg
> > 
> 
> Hello,
> 
> it is caused by SSSD caches, to refresh particular objects in cache see `man
> sss_cache`.
> 
> You can lower TTL for records in cache, but the lower TTL, the higher load
> on server (`man sssd.conf` search for cache).

btw the sudo caching is a bit more complex, but man sssd-sudo hopefully
explains it well.

Also please check in the sssd debug logs if the sssd client is 'online'.

-- 
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

2017-04-04 Thread Jakub Hrozek
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.

-- 
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] ipa_add_ad_memberships_get_next errors

2017-04-03 Thread Jakub Hrozek
On Mon, Apr 03, 2017 at 06:32:49PM +0300, Alexander Bokovoy wrote:
> On ma, 03 huhti 2017, Orion Poplawski wrote:
> > On 04/03/2017 02:10 AM, Alexander Bokovoy wrote:
> > > On ma, 03 huhti 2017, Jakub Hrozek wrote:
> > > > On Fri, Mar 31, 2017 at 04:07:16PM -0600, Orion Poplawski wrote:
> > > > > I'm seeing messages like this:
> > > > > 
> > > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]]
> > > > > [ipa_add_ad_memberships_get_next] (0x0020): There are unresolved 
> > > > > external
> > > > > group memberships even after all groups have been looked up on the 
> > > > > LDAP
> > > > > server.
> > > > > 
> > > > > and wondering it is anything to worry about.
> > > > > 
> > > > > 
> > > > > Some context:
> > > > > 
> > > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] 
> > > > > [sysdb_cache_search_groups]
> > > > > (0x2000): Search groups with filter:
> > > > > (&(objectclass=group)(originalDN=ipaUniqueID=12d2026e-a5cd-11e5-a14e-00163e2d6456,cn=hbac,dc=nwra,dc=com))
> > > > > 
> > > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] 
> > > > > [sysdb_cache_search_groups]
> > > > > (0x2000): No such entry
> > > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] 
> > > > > [sysdb_cache_search_groups]
> > > > > (0x2000): Search groups with filter:
> > > > > (&(objectclass=group)(originalDN=cn=nwra,cn=groups,cn=accounts,dc=nwra,dc=com))
> > > > > 
> > > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [merge_msg_ts_attrs] 
> > > > > (0x2000):
> > > > > No such DN in the timestamp cache:
> > > > > name=n...@nwra.com,cn=groups,cn=nwra.com,cn=sysdb
> > > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] 
> > > > > [sysdb_merge_res_ts_attrs]
> > > > > (0x2000): TS cache doesn't contain this DN, skipping
> > > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] 
> > > > > [sdap_get_groups_next_base]
> > > > > (0x0400): Searching for groups with base [cn=accounts,dc=nwra,dc=com]
> > > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_print_server] 
> > > > > (0x2000):
> > > > > Searching 10.10.41.4:389
> > > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] 
> > > > > [sdap_get_generic_ext_step]
> > > > > (0x0400): calling ldap_search_ext with
> > > > > [(&(cn=12d2026e-a5cd-11e5-a14e-00163e2d6456)(|(objectClass=ipaUserGroup)(objectClass=posixGroup))(cn=*)(&(gidNumber=*)(!(gidNumber=0][cn=accounts,dc=nwra,dc=com].
> > > > > 
> > > > 
> > > > I think this might be the reason why SSSD reports unresolved
> > > > memberships. It'trying to resolve the group using the cn attribute, ut
> > > > the object's RDN attribute seems to be ipaUniqueID. So I don't think
> > > > this is harmful, just confusing.
> > > > 
> > > > Can you please check what the object is on the IPA side with this
> > > > ipaUniqueID?
> > > It is HBAC group -- see above in the log:
> > > (&(objectclass=group)(originalDN=ipaUniqueID=12d2026e-a5cd-11e5-a14e-00163e2d6456,cn=hbac,dc=nwra,dc=com))
> > 
> > This is our "allow employees access" HBAC group.  So it applies to our 
> > "nwra"
> > host group as well as a couple individual machines, and to our "nwra" IPA 
> > group.
> It is HBAC group, not a normal POSIX user group, so SSSD shouldn't even
> look at it for a POSIX user membership.

Right, I'll try to reproduce at least the error message locally to try
if we can suppress it (by skipping the HBAC group). At the very least
the error message is confusing for admins.

-- 
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] libsemanage updates fail due to AD user with space

2017-04-03 Thread Jakub Hrozek
On Mon, Apr 03, 2017 at 11:00:21AM +1000, Lachlan Musicman wrote:
> Hola,
> 
> I've reported this issue before (with a different symptom iirc), but
> thought I should mention again, as I have no idea how to competently report
> it to selinux.
> 
> With SSSD/IPA in use, in a one way trust to AD, and AD users have spaces in
> their names, libsemanage fails to update:
> 
> eg from recent monthly upgrade cycle:
> 
> Updating   :
> selinux-policy-targeted-3.13.1-102.el7_3.16.noarch
> 3/14
> libsemanage.parse_assert_ch: expected character ':', but found 'f'
> (/etc/selinux/targeted/tmp/seusers.local: 5):
> lastname firstn...@domain.com:unconfined_u:s0-s0:c0.c1023 (No such file or
> directory).
> libsemanage.seuser_parse: could not parse seuser record (No such file or
> directory).
> libsemanage.dbase_file_cache: could not cache file database (No such file
> or directory).
> libsemanage.semanage_base_merge_components: could not merge local
> modifications into policy (No such file or directory).
> 

Hi,
according to my quick testing this is solved with this PR:
https://github.com/SSSD/sssd/pull/189
(Please note that we haven't ran all regression tests on this PR so I
can't in fact tell if it's correct or not. The code does look OK,
though).

I was also able to work around the issue by setting:
override_space = _
in sssd.conf

-- 
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] subdomain errors

2017-04-03 Thread Jakub Hrozek
On Fri, Mar 31, 2017 at 05:08:13PM -0600, Orion Poplawski wrote:
> I seem to be having some issues with users/groups that may be leading to
> errors in the subdomain status.  Can anyone parse this for me?
> 
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_cache_entry_attr]
> (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object 
> (32)]
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_entry_attr]
> (0x0080): Cannot set ts attrs for
> name=u...@ad.nwra.com,cn=users,cn=ad.nwra.com,cn=sysdb

This can be ignored, it's just a minor performance annoyance we track
upstream.

> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_cache_entry_attr]
> (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object 
> (32)]
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_entry_attr]
> (0x0080): Cannot set ts attrs for
> name=u...@ad.nwra.com,cn=users,cn=ad.nwra.com,cn=sysdb
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]]
> [ipa_initgr_get_overrides_step] (0x0040): The group
> name=u...@nwra.com,cn=groups,cn=nwra.com,cn=sysdb has no UUID attribute
> objectSIDString, error!

But this seems strange. Before you sanitized (presumably?) the logs, did
the DN name=u...@nwra.com,cn=groups,cn=nwra.com,cn=sysdb correspond to
an IPA object?

Did you run the sidgen task when setting up trusts or did you make sure
all replicas are either trust controllers or trust agents? Does the
entry on the IPA LDAP side have ipaNTSecurityIdentifier attribute?

> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]]
> [ipa_id_get_groups_overrides_done] (0x0040): IPA resolve user groups overrides
> failed [22].
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_srv_ad_acct_lookup_done]
> (0x0040): ipa_get_*_acct request failed: [22]: Invalid argument.
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_subdomain_account_done]
> (0x0040): ipa_get_*_acct request failed: [22]: Invalid argument.
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [dp_reply_std_set] (0x0080):
> DP Error is OK on failed request?
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_cache_entry_attr]
> (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object 
> (32)]
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_entry_attr]
> (0x0080): Cannot set ts attrs for
> name=u...@ad.nwra.com,cn=users,cn=ad.nwra.com,cn=sysdb
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]]
> [ipa_initgr_get_overrides_step] (0x0040): The group
> name=u...@nwra.com,cn=groups,cn=nwra.com,cn=sysdb has no UUID attribute
> objectSIDString, error!
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]]
> [ipa_id_get_groups_overrides_done] (0x0040): IPA resolve user groups overrides
> failed [22].
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_srv_ad_acct_lookup_done]
> (0x0040): ipa_get_*_acct request failed: [22]: Invalid argument.
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_subdomain_account_done]
> (0x0040): ipa_get_*_acct request failed: [22]: Invalid argument.
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [dp_reply_std_set] (0x0080):
> DP Error is OK on failed request?
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]]
> [sdap_ad_tokengroups_get_posix_members] (0x0080): Domain not found for SID
> S-1-5-32-545
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_cache_entry_attr]
> (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object 
> (32)]
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_entry_attr]
> (0x0080): Cannot set ts attrs for
> name=u...@ad.nwra.com,cn=users,cn=ad.nwra.com,cn=sysdb
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]]
> [ipa_add_ad_memberships_get_next] (0x0020): There are unresolved external
> group memberships even after all groups have been looked up on the LDAP 
> server.
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]]
> [ipa_id_get_account_info_orig_done] (0x0080): Object not found, ending request
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_srv_ad_acct_lookup_done]
> (0x0080): Sudomain lookup failed, will try to reset sudomain..
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [be_fo_reset_svc] (0x0080):
> Cannot retrieve service [ad.nwra.com]
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_srv_ad_acct_lookup_done]
> (0x0040): ipa_get_*_acct request failed: [1432158270]: Subdomain is inactive.
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_subdomain_account_done]
> (0x0040): ipa_get_*_acct request failed: [1432158270]: Subdomain is inactive.
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [dp_reply_std_set] (0x0080):
> DP Error is OK on failed request?
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]]
> [ipa_id_get_account_info_orig_done] (0x0080): Object not found, ending request
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_srv_ad_acct_lookup_done]
> (0x0080): Sudomain lookup failed, will try to reset sudomain..
> (Fri Mar 31 16:54:26 2017) 

Re: [Freeipa-users] ipa_add_ad_memberships_get_next errors

2017-04-03 Thread Jakub Hrozek
On Fri, Mar 31, 2017 at 04:07:16PM -0600, Orion Poplawski wrote:
> I'm seeing messages like this:
> 
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]]
> [ipa_add_ad_memberships_get_next] (0x0020): There are unresolved external
> group memberships even after all groups have been looked up on the LDAP 
> server.
> 
> and wondering it is anything to worry about.
> 
> 
> Some context:
> 
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_cache_search_groups]
> (0x2000): Search groups with filter:
> (&(objectclass=group)(originalDN=ipaUniqueID=12d2026e-a5cd-11e5-a14e-00163e2d6456,cn=hbac,dc=nwra,dc=com))
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_cache_search_groups]
> (0x2000): No such entry
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_cache_search_groups]
> (0x2000): Search groups with filter:
> (&(objectclass=group)(originalDN=cn=nwra,cn=groups,cn=accounts,dc=nwra,dc=com))
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [merge_msg_ts_attrs] (0x2000):
> No such DN in the timestamp cache:
> name=n...@nwra.com,cn=groups,cn=nwra.com,cn=sysdb
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_merge_res_ts_attrs]
> (0x2000): TS cache doesn't contain this DN, skipping
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_groups_next_base]
> (0x0400): Searching for groups with base [cn=accounts,dc=nwra,dc=com]
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_print_server] (0x2000):
> Searching 10.10.41.4:389
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step]
> (0x0400): calling ldap_search_ext with
> [(&(cn=12d2026e-a5cd-11e5-a14e-00163e2d6456)(|(objectClass=ipaUserGroup)(objectClass=posixGroup))(cn=*)(&(gidNumber=*)(!(gidNumber=0][cn=accounts,dc=nwra,dc=com].

I think this might be the reason why SSSD reports unresolved
memberships. It'trying to resolve the group using the cn attribute, ut
the object's RDN attribute seems to be ipaUniqueID. So I don't think
this is harmful, just confusing.

Can you please check what the object is on the IPA side with this
ipaUniqueID?

Could you describe the hierarchy so I can set up and reproduce something
similar locally?

> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step]
> (0x1000): Requesting attrs: [objectClass]
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step]
> (0x1000): Requesting attrs: [posixGroup]
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step]
> (0x1000): Requesting attrs: [cn]
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step]
> (0x1000): Requesting attrs: [userPassword]
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step]
> (0x1000): Requesting attrs: [gidNumber]
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step]
> (0x1000): Requesting attrs: [member]
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step]
> (0x1000): Requesting attrs: [ipaUniqueID]
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step]
> (0x1000): Requesting attrs: [ipaNTSecurityIdentifier]
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step]
> (0x1000): Requesting attrs: [modifyTimestamp]
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step]
> (0x1000): Requesting attrs: [entryUSN]
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step]
> (0x1000): Requesting attrs: [ipaExternalMember]
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step]
> (0x2000): ldap_search_ext called, msgid = 17
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_op_add] (0x2000): New
> operation 17 timeout 6
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_process_result]
> (0x2000): Trace: sh[0x7fc2ae9e9d90], connected[1], ops[0x7fc2aea403c0],
> ldap[0x7fc2ae9b60b0]
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_process_result]
> (0x2000): Trace: end of ldap_result list
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_process_result]
> (0x2000): Trace: sh[0x7fc2ae9e9d90], connected[1], ops[0x7fc2aea403c0],
> ldap[0x7fc2ae9b60b0]
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_op_finished]
> (0x0400): Search result: Success(0), no errmsg set
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_op_destructor] (0x2000):
> Operation 17 finished
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_groups_process]
> (0x0400): Search for groups, returned 0 results.
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_cache_search_groups]
> (0x2000): Search groups with filter:
> (&(objectclass=group)(originalDN=ipaUniqueID=12d2026e-a5cd-11e5-a14e-00163e2d6456,cn=hbac,dc=nwra,dc=com))
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_cache_search_groups]
> (0x2000): No such entry
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]]
> [ipa_add_ad_memberships_get_next] (0x0020): There are 

Re: [Freeipa-users] Trying To Debug AD Trust Quirks

2017-03-29 Thread Jakub Hrozek
On Tue, Mar 28, 2017 at 11:59:27AM -0500, Jason B. Nance wrote:
> Hello,
> 
> I'm using AD trusts with FreeIPA 4.4.0 and am having a heck of a time with 
> strange behavior.  Some examples include:
> 
> - Trust user's home directory sporadically getting set to '/' instead of 
> /home/domain/user
> - Trust user losing HBAC privileges (granted via group membership)
> - Trust user losing sudo privileges (granted via group membership)
> - OS logging that trust user's account has expired when it hasn't
> 
> I'm currently unable to predict/reproduce occurrences of these issues.  I can 
> say that they aren't tied to a specific user or host.  For example, a user 
> will login to a host without any issues and then later that same user's home 
> directory (as reported by getent) will suddenly be set to / instead of 
> /home/...
> 
> My first step, of course, is to gather logs.  Should I be focusing on the 
> SSSD on the client or on the IPA servers?  I'm not entirely clear how/where 
> lots of this data get assigned/queried.
> 
> My other question is if there is a way to pin down a client to [temporarily] 
> use a specific IPA server and specific AD server (even if it means a firewall 
> rule that only allows the host to communicate with one IPA and one AD host).

Normally time-correlated logs from both the server's domain and nss sections
of sssd.conf and the client's domain section are a good start.

-- 
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] Trying To Debug AD Trust Quirks

2017-03-29 Thread Jakub Hrozek
On Tue, Mar 28, 2017 at 11:59:27AM -0500, Jason B. Nance wrote:
> My other question is if there is a way to pin down a client to
> [temporarily] use a specific IPA server 

using the ipa_server directive in sssd.conf

> and specific AD server (even if
> it means a firewall rule that only allows the host to communicate with
> one IPA and one AD host).

the clients don't talk to ADs to resolve user information, only the
servers do. The clients only talk to AD DCs for authentication (to make
this a bit more complex, the authentication also involves parsing a
Kerberos PAC blob by the authentication helper in SSSD which also
includes the group memberships).

And unfortunately until RHEL-7.4 and SSSD 1.15 are out, then pinning the
SSSD on the IDM servers to a specific AD DC is only possible by
modifying the DNS SRV records or creating an AD site for the IDM server.

-- 
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 dyndns_update on machine with multiple IP address

2017-03-27 Thread Jakub Hrozek
On Mon, Mar 27, 2017 at 06:34:24PM +0200, David Goudet wrote:
> Hi,
> 
> Thanks to dyndns_update=True parameter, SSSD service on client machine 
> updating host DNS entry in FreeIPA.
> Everything is fine on machines which have only one IP adress on network 
> interface.
> I have problem with machines which have more that one IP address on network 
> interface: if machine have two IP address, SSSD update host DNS entry with 
> these two IP address.
> 
> To reproduce the problem:
> Host have -IP1- and i add -IP2-
> ip addr add -IP2-/26 dev em1
> 
> ip addr list:
> em1:  mtu 1496 qdisc mq state UP qlen 1000
> link/ether 
> inet -IP1-/26 brd  scope global em1
> inet -IP2-/26 scope global secondary em1
>valid_lft forever preferred_lft forever
> 
> DNS resolution (dig) before restarting sssd returns only -IP1-. After 
> restarting sssd returns -IP1- & -IP2-
> 
> In dyndns_update manpage, we have "The IP address of the IPA LDAP connection 
> is used for the updates", what does it means? Is it IP address of the DNS 
> server (used to update the DNS entry)? or is it IP address on client machine 
> used during LDAP TCP bind (-IP1- in my case)?
> 
> dyndns_update (boolean)
>Optional. This option tells SSSD to automatically update the DNS 
> server built into FreeIPA v2 with the IP address of this client.
>The update is secured using GSS-TSIG. The IP address of the IPA 
> LDAP connection is used for the updates, if it is not otherwise
>specified by using the “dyndns_iface” option.
> 
> Is it normal behaviour that SSSD add in host DNS entry every IPs enabled on 
> client machine?

Looks like this was a deliberate change:
https://pagure.io/SSSD/sssd/issue/2558
but to be honest, I forgot why exactly we did this. Martin, do you know?

> Is it possible to configure SSSD to update DNS with only IP address "primary" 
> in ip addr list or which is used to FreeIPA server communication (-IP1- used 
> on TCP binding)?

Only if the IP addresses are of different families (v4/v6), then it's
possible to restrict one of the families.

-- 
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] Data Provider is offline

2017-03-22 Thread Jakub Hrozek
On Wed, Mar 22, 2017 at 05:30:34PM +0100, Michaël Van de Borne wrote:
> Hi all,
> 
> So I have 2 Centos7 hosts, with same sssd and nsswitch configs.
> One does find the users in IPA, and the other doesn't.
> Looks like the Data Provider is offline.
> I sent the SIGUSR2 signal to sssd which is supposed to bring him online.
> Didn't help.
> The hosts can resolve the IPA server hostname. SElinux is enforced. Iptables
> is disabled.
> 
> here's my sssd.conf
> 
> [domain/vgt.vito.be]
> cache_credentials = True
> krb5_store_password_if_offline = True
> ipa_domain = vgt.vito.be
> id_provider = ipa
> auth_provider = ipa
> access_provider = ipa
> ipa_hostname = epoddev8.vgt.vito.be
> chpass_provider = ipa
> ipa_server = _srv_, epoddev5.vgt.vito.be
> ldap_tls_cacert = /etc/ipa/ca.crt
> debug_level = 7
> [sssd]
> services = nss, sudo, pam, ssh
> domains = vgt.vito.be
> [nss]
> homedir_substring = /home
> debug_level = 7
> [pam]
> [sudo]
> [autofs]
> [ssh]
> [pac]
> [ifp]
> 
> 
> here's the log of sssd_nss.log
> 
> (Wed Mar 22 16:27:22 2017) [sssd[nss]] [accept_fd_handler] (0x0400): Client
> connected!
> (Wed Mar 22 16:27:22 2017) [sssd[nss]] [sss_cmd_get_version] (0x0200):
> Received client version [1].
> (Wed Mar 22 16:27:22 2017) [sssd[nss]] [sss_cmd_get_version] (0x0200):
> Offered version [1].
> (Wed Mar 22 16:27:22 2017) [sssd[nss]] [nss_cmd_getbynam] (0x0400): Running
> command [17][SSS_NSS_GETPWNAM] with input [vdbornem].
> (Wed Mar 22 16:27:22 2017) [sssd[nss]] [sss_parse_name_for_domains]
> (0x0200): name 'vdbornem' matched without domain, user is vdbornem
> (Wed Mar 22 16:27:22 2017) [sssd[nss]] [nss_cmd_getbynam] (0x0100):
> Requesting info for [vdbornem] from []
> (Wed Mar 22 16:27:22 2017) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100):
> Requesting info for [vdbor...@vgt.vito.be]
> (Wed Mar 22 16:27:22 2017) [sssd[nss]] [get_dp_name_and_id] (0x0400): Not a
> LOCAL view, continuing with provided values.
> (Wed Mar 22 16:27:22 2017) [sssd[nss]] [sss_dp_issue_request] (0x0400):
> Issuing request for [0x7f7ffd1d1880:1:vdbor...@vgt.vito.be@vgt.vito.be]
> (Wed Mar 22 16:27:22 2017) [sssd[nss]] [sss_dp_get_account_msg] (0x0400):
> Creating request for
> [vgt.vito.be][0x1][BE_REQ_USER][1][name=vdbor...@vgt.vito.be:-]
> (Wed Mar 22 16:27:22 2017) [sssd[nss]] [sss_dp_internal_get_send] (0x0400):
> Entering request [0x7f7ffd1d1880:1:vdbor...@vgt.vito.be@vgt.vito.be]
> (Wed Mar 22 16:27:22 2017) [sssd[nss]] [sss_dp_get_reply] (0x0010): The Data
> Provider returned an error [org.freedesktop.sssd.Error.DataProvider.Offline]
> (Wed Mar 22 16:27:22 2017) [sssd[nss]] [nss_cmd_getby_dp_callback] (0x0040):
> Unable to get information from Data Provider
> Error: 3, 5, Failed to get reply from Data Provider
> Will try to return what we have in cache
> (Wed Mar 22 16:27:22 2017) [sssd[nss]] [sss_dp_req_destructor] (0x0400):
> Deleting request: [0x7f7ffd1d1880:1:vdbor...@vgt.vito.be@vgt.vito.be]
> (Wed Mar 22 16:27:22 2017) [sssd[nss]] [client_recv] (0x0200): Client
> disconnected!

Restart sssd, which starts from a clean slate, then look for the first
occurence of "Going offline" or "Not working" in the logs, then check
which operation triggered that..

-- 
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] shadow netgroups with wrong domains - sudo problem

2017-03-20 Thread Jakub Hrozek
On Fri, Mar 17, 2017 at 01:52:17PM +, Bob Hinton wrote:
> On 17/03/2017 12:48, Lukas Slebodnik wrote:
> > On (17/03/17 10:40), Bob Hinton wrote:
> >> On 17/03/2017 08:41, Jakub Hrozek wrote:
> >>> On Fri, Mar 17, 2017 at 06:50:34AM +, Bob Hinton wrote:
> >>>> Morning,
> >>>>
> >>>> We have a collection of hosts within prod1.local.lan. However, the
> >>>> domain section of the shadow netgroups for the hosts is
> >>>> mgmt.prod.local.lan. This seems to prevent sudo rules working on these
> >>>> hosts unless they specify all hosts -
> >>>>
> >>>> -sh-4.2$ getent netgroup oepp_hosts
> >>>> oepp_hosts   
> >>>> (oeppsdas001.z2.prod1.local.lan,-,mgmt.prod.local.lan)
> >>>> (oeppsdas002.z2.prod1.local.lan,-,mgmt.prod.local.lan)
> >>>> (oeppservice001.z2.prod1.local.lan,-,mgmt.prod.local.lan)
> >>>> (oeppredis002.z4.prod1.local.lan,-,mgmt.prod.local.lan)
> >>>> (oeppredis001.z4.prod1.local.lan,-,mgmt.prod.local.lan)
> >>>> -sh-4.2$ hostname
> >>>> oeppredis001.z4.prod1.local.lan
> >>>> -sh-4.2$ nisdomainname
> >>>> local.lan
> >>>> -sh-4.2$ domainname
> >>>> local.lan
> >>>>
> >>>> The VMs associated with these hosts have recently been migrated and
> >>>> re-enrolled against a new IPA server. The originals all had netgroup
> >>>> domains of local.lan so something must have gone wrong in the migration
> >>>> process. Is there a way to correct the netgroup domains of these hosts,
> >>>> or is the only option to run ipa-client-install --uninstall followed by
> >>>> ipa-client-install to reattach them ?
> >>> Did you remove the sssd cache after the migration?
> >>> rm -f /var/lib/sss/db/*.ldb
> >>>
> >>> (please make sure the clients can reach the server or maybe mv the cache
> >>> instead of rm so you can restore cached credentials if something goes
> >>> wrong..)
> >>>
> >> Hi Jakub,
> >>
> >> I've now tried removing the sssd cache on one of the offending servers
> >> and it's not made any difference.
> >>
> >> getent netgroup oepp_hosts
> >>
> >> when run from any host enrolled to the new IPA servers, including the
> >> IPA masters themselves produces the results with "mgmt.prod" included
> >> and the same thing run on any of the pre-migrated servers that are still
> >> commissioned produces them without, so I assume that the netgroup domain
> >> information is coming from the IPA masters rather than the local host.
> >>
> > Could you provide content of LDIF from IPA server?
> > For this netgroup/hostgroup
> >
> > LS
> 
> Hi Jakub,
> 
> I extracted the following from the userRoot ldif produced by "ipa-backup
> --data".
> 
> It appears to have the incorrect domain set against nisDomainName. Could
> this be changed with ldapmodify ?

Sorry, I'm not sure. I hope someone with better insight into the IPA
framework knows.

-- 
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] shadow netgroups with wrong domains - sudo problem

2017-03-17 Thread Jakub Hrozek
On Fri, Mar 17, 2017 at 06:50:34AM +, Bob Hinton wrote:
> Morning,
> 
> We have a collection of hosts within prod1.local.lan. However, the
> domain section of the shadow netgroups for the hosts is
> mgmt.prod.local.lan. This seems to prevent sudo rules working on these
> hosts unless they specify all hosts -
> 
> -sh-4.2$ getent netgroup oepp_hosts
> oepp_hosts   
> (oeppsdas001.z2.prod1.local.lan,-,mgmt.prod.local.lan)
> (oeppsdas002.z2.prod1.local.lan,-,mgmt.prod.local.lan)
> (oeppservice001.z2.prod1.local.lan,-,mgmt.prod.local.lan)
> (oeppredis002.z4.prod1.local.lan,-,mgmt.prod.local.lan)
> (oeppredis001.z4.prod1.local.lan,-,mgmt.prod.local.lan)
> -sh-4.2$ hostname
> oeppredis001.z4.prod1.local.lan
> -sh-4.2$ nisdomainname
> local.lan
> -sh-4.2$ domainname
> local.lan
> 
> The VMs associated with these hosts have recently been migrated and
> re-enrolled against a new IPA server. The originals all had netgroup
> domains of local.lan so something must have gone wrong in the migration
> process. Is there a way to correct the netgroup domains of these hosts,
> or is the only option to run ipa-client-install --uninstall followed by
> ipa-client-install to reattach them ?

Did you remove the sssd cache after the migration?
rm -f /var/lib/sss/db/*.ldb

(please make sure the clients can reach the server or maybe mv the cache
instead of rm so you can restore cached credentials if something goes
wrong..)

-- 
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] Slow logins on one ipa client- due to SSS_PAM_ACCT_MGMT

2017-03-17 Thread Jakub Hrozek
On Thu, Mar 16, 2017 at 08:24:42PM +, Kilborn, Jim wrote:
> Greetings,
> 
> My first post to the forum.
> 
> We are running centos7 with freeipa. Syncing from AD, with one linux replica.
> The ipa clients are getting installed by puppet. All the clients are 
> performing fine, except one. I am getting slow ssh logins to one host, as 
> well as slow 'id' and 'who', etc.
> 
> I turned up the sss-debuglevel to 6, and compared the slow client to another, 
> and I am seeing a section in the logs that is unique to the slow system, 
> basically its doing a SSS_PAM_ACCT_MGMT, and I don't have any clue why. Same 
> user logging in to both clients, one client does the SSS_PAM_ACCT_MGMT, 
> followed by the SSS_PAM_OPEN_SESSION. While the other client only does 
> SSS_PAM_OPEN_SESSION, and is much faster. (1 second vs 2-8 seconds)
> It seems the SSS_PAM_ACCT_MGMT is the slow culprit, and I don't know why its 
> running.
> 
> Any idea what would cause this or where I should look?

The timestamps from the logs are missing, so it's not clear which call
is taking long. No server lookups should be performed in the account
phase, though, so I can only think of the selinux label setting in
libselinux, which is also done in the account phase to be taking long.

can you try to disable the selinux provider for a test?
selinux_provider=none
btw why is the 'fast' client not running the account phase at all? Is
pam_sss in the account stack in the PAM configuration? Is the
access_provider set to anything else than IPA in the sssd.conf file?

-- 
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] HBAC not working, freeipa 4.4, sssd 1.15.1

2017-03-17 Thread Jakub Hrozek
On Fri, Mar 17, 2017 at 08:35:42AM +1100, Lachlan Musicman wrote:
> Which logs do you want from the server?

NSS and domain

-- 
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] HBAC not working, freeipa 4.4, sssd 1.15.1

2017-03-16 Thread Jakub Hrozek
On Thu, Mar 16, 2017 at 07:56:58PM +1100, Lachlan Musicman wrote:
> Yes. What I do would you like? Current debug levels are at 8

Logs and id output from the server and the client at the same time..

-- 
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] HBAC not working, freeipa 4.4, sssd 1.15.1

2017-03-16 Thread Jakub Hrozek
On Thu, Mar 16, 2017 at 11:36:57AM +1100, Lachlan Musicman wrote:
> I'm experiencing issues with HBAC and I think it's a bug in sssd. Not sure
> if better to report to here or sssd mailing list. Also sssd in pagure is
> bare and I didn't want to sully the blank slate.  (
> https://pagure.io/sssd/issues )
> 
> The details:
> 
> env: CentOS 7.3, FreeIPA 4.4, sssd 1.15.1 from COPR
> 
> On the IPA server:
> 
> - "ipa hbactest ..." returns TRUE, so everything seems set up correctly.
> 
> 
> When I try to login to the test client, I get denied.
> 
> On the test client:
> 
>  - hbac_eval_user_element is returning a wrong value. This is seen in
> sssd_domain.log, it's returning 25. My test user is in 37 groups. This is
> seen on the IPA server via id username. On the test client id username
> returns 36 groups, the one missing is an IPA (not AD) group that was made
> for HBAC rules. I have sanitized logs available.
> 
>  -  taking ldbsearch -H /var/lib/sss/db/cache_domain.com.ldb
> '(objectclass=user)' and finding the record in question shows the same 36
> groups available. The missing group shouldn't affect ability to login via
> HBAC
> 
>  - getent group (groupname) works as expected. Also worth noting that the
> group missing from id username shows that user in getent.
> 
> For reference, on the client the sssd service was stopped, the cache
> deleted, and the service started again the night before after which the
> server wasn't accessed by anyone. I find that this is necessary for the
> cache to populate.
> 
> Should I put in a bug report against SSSD or FreeIPA?
> 
> While HBAC is in FreeIPA, I think that this is an issue in SSSD
> (specifically ?

Yes, SSSD.

I remember you had some intermittent issues in the past, is this one
reproducable?

-- 
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] Announcing SSSD 1.15.2

2017-03-15 Thread Jakub Hrozek
SSSD 1.15.2
===

The SSSD team is proud to announce the release of version 1.15.2 of the
System Security Services Daemon.

The tarball can be downloaded from https://releases.pagure.org/SSSD/sssd/

RPM packages will be made available for Fedora shortly.

Feedback

Please provide comments, bugs and other feedback via the sssd-devel or
sssd-users mailing lists:
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Highlights
--
 * It is now possible to configure certain parameters of a trusted domain
   in a configuration file sub-section. In particular, it is now possible
   to configure which Active Directory DCs the SSSD talks to with a
   configuration like this::

[domain/ipa.test]
# IPA domain configuration. This domain trusts a Windows domain win.test

[domain/ipa.test/win.test]
ad_server = dc.win.test

 * Several issues related to socket-activating the NSS service, especially
   if SSSD was configured to use a non-privileged userm were fixed.
   The NSS service now doesn't change the ownership of its log files to
   avoid triggering a name-service lookup while the NSS service is not
   running yet. Additionally, the NSS service is started before any other
   service to make sure username resolution works and the other service
   can resolve the SSSD user correctly.

 * A new option "cache_first" allows the administrator to change the way
   multiple domains are searched. When this option is enabled, SSSD will
   first try to "pin" the requested name or ID to a domain by searching
   the entries that are already cached and contact the domain that contains
   the cached entry first. Previously, SSSD would check the cache and the
   remote server for each domain. This option brings performance benefit
   for setups that use multiple domains (even auto-discovered trusted
   domains), especially for ID lookups that would previously iterate over
   all domains. Please note that this option must be enabled with care as the
   administrator must ensure that the ID space of domains does not overlap.

 * The SSSD D-Bus interface gained two new methods:
   "FindByNameAndCertificate" and "ListByCertificate". These methods
   will be used primarily by IPA and
   `mod_lookup_identity <https://github.com/adelton/mod_lookup_identity/>
   to correctly match multple users who use the same certificate for Smart
   Card login.

 * A bug where SSSD did not properly sanitize a username with a newline
   character in it was fixed.

Packaging Changes
-
None in this release

Documentation Changes
-
 * A new option "cache_first" was added. Please see the Highlights
   section for more details

 * The "override_homedir" option supports a new template expansion "l"
   that expands to the first letter of username


Tickets Fixed
-
Please note that due to a bug in the pagure.io tracker, some tickets that
have dependencies set to other tickets cannot be closed at the moment.

 * <https://pagure.io/SSSD/sssd/issue/3317> - Newline characters (\n) must be 
sanitized before LDAP requests take place
 * <https://pagure.io/SSSD/sssd/issue/3316> - sssd-secrets doesn't exit on idle 
 * <https://pagure.io/SSSD/sssd/issue/3314> - sssd ignores entire groups from 
proxy provider if one member is listed twice 
 * <https://pagure.io/SSSD/sssd/issue/3164> - when group is invalidated using 
sss_cache dataExpireTimestamp entry in the domain and timestamps cache are 
inconsistent 
 * <https://pagure.io/SSSD/sssd/issue/2668> - [RFE] Add more flexible 
templating for override_homedir config option 
 * <https://pagure.io/SSSD/sssd/issue/2599> - Make it possible to configure AD 
subdomain in the server mode 
 * <https://pagure.io/SSSD/sssd/issue/3322> - chown in ExecStartPre of 
sssd-nss.service hangs forever 
 * <https://pagure.io/SSSD/sssd/issue/843>  - Login time increases strongly if 
more than one domain is configured 
 * <https://pagure.io/SSSD/sssd/issue/2320> - use the sss_parse_inp request in 
other responders than dbus 

Detailed Changelog
--
* Fabiano Fidêncio (7):

  * RESPONDER: Wrap up the code to setup the idle timeout
  * SECRETS: Shutdown the responder in case it becomes idle
  * CACHE_REQ: Move cache_req_next_domain() into a new tevent request
  * CACHE_REQ: Check the caches first
  * NSS: Don't set SocketUser/SocketGroup as "sssd" in sssd-nss.socket
  * NSS: Ensure the NSS socket is started before any other services' sockets
  * NSS: Don't call chown on NSS service's ExecStartPre

* Ignacio Reguero (1):

  * UTIL: first letter of user name template for override_homedir

* Jakub Hrozek (9):

  * Updating the version for the 1.15.2 release
  * Allow manual start for ss

Re: [Freeipa-users] SSSD bug found? FreeIPA vs SSSD

2017-03-09 Thread Jakub Hrozek
On Thu, Mar 09, 2017 at 11:32:35AM +0200, Alexander Bokovoy wrote:
> On to, 09 maalis 2017, Jakub Hrozek wrote:
> > On Thu, Mar 09, 2017 at 01:37:46PM +1100, Lachlan Musicman wrote:
> > > Hola,
> > > 
> > > On CentOS 7.3, using FreeIPA VERSION: 4.4.0, API_VERSION: 2.213 and sssd
> > > (via COPR) 1.15.1, which has a one way trust to an AD domain. 
> > > unix.name.org
> > > -> name.org
> > > 
> > > I've seen some interesting behaviour.
> > > 
> > > Being part of a large organisation with a smaller nix environment and a
> > > larger Windows environment we see all the best of odd AD management
> > > behaviour (eg spaces in usernames...).
> > > 
> > > Turns out some of the groups in AD have an @ symbol in them.
> > > 
> > > The behavioural difference we see is: given userA in group "name @ of
> > > group" that on the FreeIPA server:
> > > 
> > > [r...@vmpr-freeipa.unix.name.org ~]# id us...@name.org
> > > 
> > > works as expected.
> > > 
> > > But on a client
> > > 
> > > [r...@vmpr-linuxclient1.unix.name.org ~]# id us...@name.org
> > > 
> > > returns nothing.
> > 
> > Yes, it is a know issue:
> >https://pagure.io/SSSD/sssd/issue/3219
> > 
> > There were some users who reported this works better with a modified
> > re_expression:
> >re_expression = ((?P.+)@(?P[^@]+$))
> > but I agree we should fix this by default. However, the fix must be done
> > at both the SSSD level and the IPA extdom plugin, which also searches
> > for the @-sign in the user and group names.
> Luckily, a change for extdom plugin seem to be straightforward -- search
> for the *last* occurence of the domain separator, not the first one. We
> had a similar issue with nfs idmapd code too.

Yes, the most tricky part would be testing, to make sure the new regular
expression doesn't break anything. I used the one I showed to unblock
some RHEL customers that were complaining and were a bit stuck, but I
didn't have enough time to run all our available tests with it, that's
why we didn't switch by default..

-- 
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 bug found? FreeIPA vs SSSD

2017-03-09 Thread Jakub Hrozek
On Thu, Mar 09, 2017 at 01:37:46PM +1100, Lachlan Musicman wrote:
> Hola,
> 
> On CentOS 7.3, using FreeIPA VERSION: 4.4.0, API_VERSION: 2.213 and sssd
> (via COPR) 1.15.1, which has a one way trust to an AD domain. unix.name.org
> -> name.org
> 
> I've seen some interesting behaviour.
> 
> Being part of a large organisation with a smaller nix environment and a
> larger Windows environment we see all the best of odd AD management
> behaviour (eg spaces in usernames...).
> 
> Turns out some of the groups in AD have an @ symbol in them.
> 
> The behavioural difference we see is: given userA in group "name @ of
> group" that on the FreeIPA server:
> 
> [r...@vmpr-freeipa.unix.name.org ~]# id us...@name.org
> 
> works as expected.
> 
> But on a client
> 
> [r...@vmpr-linuxclient1.unix.name.org ~]# id us...@name.org
> 
> returns nothing.

Yes, it is a know issue:
https://pagure.io/SSSD/sssd/issue/3219

There were some users who reported this works better with a modified
re_expression:
re_expression = ((?P.+)@(?P[^@]+$))
but I agree we should fix this by default. However, the fix must be done
at both the SSSD level and the IPA extdom plugin, which also searches
for the @-sign in the user and group names.
> 
> We believe it is because of the group with the @ in the name.
> 
> The AD management team agreed to change the name of one group with an @ in
> it's name, and that has solved the problem - id us...@name.org now works on
> the sssd client.
> 
> Putting aside the critiques of having an @ in a group name, I believe that
> if there isn't a bug, there is at least an inconsistency, between how
> FreeIPA and sssd handle this situation.
> 
> This was a guess based on seeing this in the logs:
> 
> (Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]]
> [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with
> [(&(objectClass=ipaUserOverride)(uid=awong))][cn=Default Trust
> View,cn=views,cn=accounts,dc=unix,dc=name,dc=org].
> (Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [sdap_parse_entry]
> (0x1000): OriginalDN:
> [ipaanchoruuid=:SID:S-1-5-21-55386287-1424373824-1154838474-83519,cn=Default
> Trust View,cn=views,cn=accounts,dc=unix,dc=name,dc=org].
> (Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]]
> [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no
> errmsg set
> (Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state]
> (0x1000): Domain unix.name.org is Active
> (Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state]
> (0x1000): Domain name.org is Active
> (Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [ipa_s2n_exop_send]
> (0x0400): Executing extended operation
> (Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [ipa_s2n_exop_done]
> (0x0400): ldap_extended_operation result: Success(0), (null).
> (Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state]
> (0x1000): Domain unix.name.org is Active
> (Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state]
> (0x1000): Domain name.org is Active
> ...
> (Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state]
> (0x1000): Domain unix.name.org is Active
> (Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state]
> (0x1000): Domain name.org is Active
> (Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state]
> (0x1000): Domain unix.name.org is Active
> (Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state]
> (0x1000): Domain name.org is Active
> (Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [add_v1_user_data]
> (0x0040): find_domain_by_name failed.
> (Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]]
> [s2n_response_to_attrs] (0x0040): add_v1_user_data failed.
> (Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]]
> [ipa_s2n_get_user_done] (0x0040): s2n_response_to_attrs failed.
> 
> 
> The last three lines tipped off a colleague who was debugging why this
> userA couldn't login to anything.
> 
> Since then we have created IPA over rides for the groups with @ symbols in
> them. This also works as a solution. It's not our preferred solution, but
> we are users, not managers, of the AD system.
> 
> Cheers
> 
> L.
> 
> 
> 
> 
> 
> --
> The most dangerous phrase in the language is, "We've always done it this
> way."
> 
> - Grace Hopper

> -- 
> 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

-- 
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] pam_hbac for aix

2017-03-06 Thread Jakub Hrozek
On Mon, Mar 06, 2017 at 12:36:20PM +0100, Iulian Roman wrote:
> On Mon, Mar 6, 2017 at 12:20 PM, Jakub Hrozek <jhro...@redhat.com> wrote:
> 
> > On Mon, Mar 06, 2017 at 10:59:12AM +0100, Iulian Roman wrote:
> > > Hello,
> > >
> > > Does anyone know what is the status with the support for AIX in the
> > > pam_hbac tool ? I've heard from a RH presentation that it is available,
> > > although on the project site it does not seem to be supported yet.
> > >
> > > I would like to know if there are any plans in that direction ,  because
> > > our migrations of thousands of AIX machines to IPA is conditioned by the
> > > availability of pam_hbac.  The HBAC rules/policy design depends as well
> > on
> > > the method you use to parse the rules.
> >
> > It's in progress, but delayed due to the current work we are doing for
> > RHEL-7.4. I've merged HP-UX support a couple of weeks ago and AIX
> > support is next on the list.
> >
> > Any chance we can prioritize  that by creating  an RFE ?  We have quite a
> big environment and it would simplify a lot the access control if we can
> make use of pam_hbac.

We already have:
https://github.com/jhrozek/pam_hbac/issues/74

> 
> > If you'd like to help with the port, any help is appreciated :-)
> >
> > I am willing to , at least with testing it on different OS versions. If
> there is anything else i can do , please let me know.

Testing patches when there are would be nice. You can subscribe to the
github issue to receive updates.

-- 
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] pam_hbac for aix

2017-03-06 Thread Jakub Hrozek
On Mon, Mar 06, 2017 at 10:59:12AM +0100, Iulian Roman wrote:
> Hello,
> 
> Does anyone know what is the status with the support for AIX in the
> pam_hbac tool ? I've heard from a RH presentation that it is available,
> although on the project site it does not seem to be supported yet.
> 
> I would like to know if there are any plans in that direction ,  because
> our migrations of thousands of AIX machines to IPA is conditioned by the
> availability of pam_hbac.  The HBAC rules/policy design depends as well on
> the method you use to parse the rules.

It's in progress, but delayed due to the current work we are doing for
RHEL-7.4. I've merged HP-UX support a couple of weeks ago and AIX
support is next on the list.

If you'd like to help with the port, any help is appreciated :-)

-- 
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] LDAP based autofs map redundancy

2017-03-05 Thread Jakub Hrozek
On Sun, Mar 05, 2017 at 02:59:39PM -0500, William Muriithi wrote:
> Jakub,
> 
> >>
> >> It does look though like kerberos is not affected as all systems can
> >> authenticate fine, so looks like its autofs issue alone
> >>
> >> This is the error I am noticing on the logs.
> >>
> >> Mar  2 14:18:29 platinum automount[2887]: key "brad" not found in map 
> >> source(s).
> >> Mar  2 14:19:18 platinum automount[2887]: bind_ldap_simple:
> >> lookup(ldap): Unable to bind to the LDAP server: (default), error
> >> Can't contact LDAP server
> >> Mar  2 14:19:21 platinum automount[2887]: bind_ldap_simple:
> >> lookup(ldap): Unable to bind to the LDAP server: (default), error
> >> Can't contact LDAP server
> >
> > I guess /etc/nsswitch.conf uses ldap for automount and not sssd?
> >
> Actually no.  We are using SSSD
> 
> Just checked to confirm and looks like below:
> 
> services:   files sss
> netgroup:   files sss
> publickey:  nisplus
> automount: sss files
> aliases:files nisplus
> sudoers: files sss

Then I suspect automounter used to use the ldap module and then was
not restarted after nsswitch.conf was set to include sss. Because the
error messages like include error messages directly from libldap and I
wouldn't expect to see those with 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] Can kerberos SSSD provider be used against IPA

2017-03-04 Thread Jakub Hrozek
On Fri, Mar 03, 2017 at 07:10:40PM -0500, William Muriithi wrote:
> Hello,
> 
> I just came across this document.
> 
> https://www.susecon.com/doc/2015/sessions/TUT19343.pdf
> 
> If you look at page 8, that diagram imply that kerberos provider can
> only be used against active directory back end.

The AD and IPA authentication providers are more or less wrappers around
the Kerberos provider with some extra options such as the support for
enterprise principals.

-- 
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] ipa-client-install generates bad sssd.conf

2017-03-03 Thread Jakub Hrozek
On Fri, Mar 03, 2017 at 09:56:55AM +0100, Harald Dunkel wrote:
> Hi Jakub,
> 
> On 03/03/17 09:32, Jakub Hrozek wrote:
> > On Fri, Mar 03, 2017 at 08:45:10AM +0100, Harald Dunkel wrote:
> >> Hi folks,
> >>
> >> running freeipa client 4.3.2-5 and sssd 1.15.0-3 on
> >> Debian Stretch
> >   ~~
> > This is important I guess.
> > 
> > Since SSSD 1.15, SSSD allows to socket-activate the services, so it is
> > no longer required to have them explicitly listed in the services line
> > of the sssd section. But:
> > - there were some nasty bugs in the first version of the socket
> >   activation. We will be releasing 1.15.1 today to address those
> >   issues
> > - the sockets must be enabled (systemctl status sssd-nss.socket). I
> >   understand Debian is doing this but I'm neither Debian user nor
> >   developer. I would suggest to ask on some Debian-specific forum or
> >   file a bug report if the resulting configurationd doesn't work.
> > 
> 
> This is systemd-only?
> 
> Wouldn't it be better to create a working sssd.conf, no matter
> what?

It is up to whoever is creating the sssd.conf. As I said, the change is
backwards-compatible. If you want the services to be started by sssd,
then list them in the services line. If you want to have them started on
demand and have a simpler configuration, you rely on the systemd services
manager.

-- 
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] ipa-client-install generates bad sssd.conf

2017-03-03 Thread Jakub Hrozek
On Fri, Mar 03, 2017 at 08:45:10AM +0100, Harald Dunkel wrote:
> Hi folks,
> 
> running freeipa client 4.3.2-5 and sssd 1.15.0-3 on
> Debian Stretch
  ~~
This is important I guess.

Since SSSD 1.15, SSSD allows to socket-activate the services, so it is
no longer required to have them explicitly listed in the services line
of the sssd section. But:
- there were some nasty bugs in the first version of the socket
  activation. We will be releasing 1.15.1 today to address those
  issues
- the sockets must be enabled (systemctl status sssd-nss.socket). I
  understand Debian is doing this but I'm neither Debian user nor
  developer. I would suggest to ask on some Debian-specific forum or
  file a bug report if the resulting configurationd doesn't work.

> ipa-client-install creates a bad sssd.conf file, e.g.
> 
>   [domain/example.com]
> 
>   cache_credentials = True
>   krb5_store_password_if_offline = True
>   ipa_domain = example.com
>   id_provider = ipa
>   auth_provider = ipa
>   access_provider = ipa
>   ldap_tls_cacert = /etc/ipa/ca.crt
>   ipa_hostname = stretch1.vs.example.com
>   chpass_provider = ipa
>   ipa_server = _srv_, ipa1.example.com
>   dns_discovery_domain = example.com
>   [sssd]
>   domains = example.com
>   services = sudo

btw I find it strange that sudo is listed. I would expect either all or
no services to be listed. The feature is backwards-compatible, so if you
list the services explicitly, the sssd process would still start them
explicitly, just as it did with previous versions.

>   [sudo]
> 
> 
> Esp. the services for nss, pam and ssh are not setup. Is this
> as expected?
> 
> 
> Every helpful comment is highly appreciated.
> Harri
> 
> -- 
> 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

-- 
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] LDAP based autofs map redundancy

2017-03-02 Thread Jakub Hrozek
On Thu, Mar 02, 2017 at 03:28:38PM -0500, William Muriithi wrote:
> Afternoon,
> 
> 
> I have noticed that even when a network has two IPA for redundancy,
> autofs don't seem to be able to take advantage of the remaining IPA
> should one of the IPA goes down.
> 
> Is this a know issue with LDAP based maps or is it a configuration
> that need to be adjusted. By the way, only about half of the systems
> are affected and I have noticed they have this on sssd.conf
> 
> 
> ipa_server = _srv_, hydrogen.eng.example.com
> 
> It does look though like kerberos is not affected as all systems can
> authenticate fine, so looks like its autofs issue alone
> 
> This is the error I am noticing on the logs.
> 
> Mar  2 14:18:29 platinum automount[2887]: key "brad" not found in map 
> source(s).
> Mar  2 14:19:18 platinum automount[2887]: bind_ldap_simple:
> lookup(ldap): Unable to bind to the LDAP server: (default), error
> Can't contact LDAP server
> Mar  2 14:19:21 platinum automount[2887]: bind_ldap_simple:
> lookup(ldap): Unable to bind to the LDAP server: (default), error
> Can't contact LDAP server

I guess /etc/nsswitch.conf uses ldap for automount and not 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] Switch sudoers to IPA

2017-03-02 Thread Jakub Hrozek
On Thu, Mar 02, 2017 at 09:50:41PM +0530, deepak dimri wrote:
> Hi Jakub, Actually that is what i am doing. i am creating the user with
> same UID in IPA and then if i delete the user locally then i can
> authenticate via IPA. Is there anyway i can do this without deleting the
> user? This is just to use the same GID and avoid recreation of
> home/directories.

I think you'd need to modify the PAM stack to keep going even if
authentication against pam_unix fails. I /think/ (but haven't tested )
that modifying the lines that deal with pam_unix/pam_sss like this:

auth [default=2 success=ok] pam_localuser.so
auth sufficient pam_unix.so nullok try_first_pass
auth [success=done ignore=ignore default=die] pam_sss.so use_first_pass

could work. The other lines in the PAM auth stack and all the other
stacks should be left intact.

(Please keep a root shell around if you're going to tinker with PAM
settings and preferably try this out on a test box first.)

-- 
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] Switch sudoers to IPA

2017-03-02 Thread Jakub Hrozek
On Thu, Mar 02, 2017 at 07:09:41PM +0530, deepak dimri wrote:
> Hi List,
> 
> I have sudo and normal users accessing linux systems using their private
> key without IPA. I have IPA fully functioning and now i want to switch the
> users from local file login to IPA.
> 
> Any new user i create in IPA can SSH into ipa client jump boxes fine. I
> want to know how i can migrate existing local sudoers users to IPA.  This
> is what i have done to achieve this:
> 
> 1-  Created a new user in IPA with the same name as i have in Jumpbox.
> 2 - Added the public key of that user in IPA.
> 3-  Added the user to jumpbox_usergroup as my sshd.conf forces the users of
> this group to authenticate against the pam/sssd
> 
> Now when i try to ssh into jumpbox using as i was doing before i still logs
> into the jumpbox via unix pam and not IPA.  What should i be doing so that
> the "existing" local unix users can login via IPA?

But do you need to keep the local users around? Why not create the IPA
user with the same UID as the local user and remove the local user?

Typically, if there is a user both in the local files and a remote
source, the system (as configured in nsswitch.conf) would first return
the local user and the PAM stack then only authenticates this user using
pam_unix.so

-- 
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] login/su problem on ubuntu

2017-02-28 Thread Jakub Hrozek
On Tue, Feb 28, 2017 at 06:13:42PM +0100, Karl Forner wrote:
> I just registered a new computer running ubuntu to our freeIPA system.
> Some users (all I tried except me) are not able to login using lightdm.
> 
> The message on screen is "Permission denied".
> On the system the user (joe) is created, its home directory also,  but it
> only contains a .kde/ subdir and a .bash_history.
> 
> On my session, if I type:
> $sudo su - joe
> I get:
> su: Permission denied
> (Ignored)
> 
> 
> The only log file that is modified is /var/log/auth.log.
> The relevant lines during the graphical login are:
> 
> Feb 28 16:44:29 nyx lightdm: pam_unix(lightdm:auth): authentication
> failure; logname= uid=0 euid=0 tty=:0 ruser= rhost=  user=joe
> Feb 28 16:44:41 nyx lightdm: pam_sss(lightdm:auth): authentication success;
> logname= uid=0 euid=0 tty=:0 ruser= rhost= user=joe
> Feb 28 16:44:41 nyx lightdm: pam_kwallet(lightdm:auth): pam_sm_authenticate
> Feb 28 16:44:43 nyx lightdm: pam_sss(lightdm:account): Access denied for
> user joe: 6 (Permission denied)
> Feb 28 16:44:54 nyx lightdm: pam_succeed_if(lightdm:auth): requirement
> "user ingroup nopasswdlogin" not met by user "joe"
> 
> The relevant lines during the "sudo su - joe":
> Feb 28 16:48:32 nyx su[26394]: pam_sss(su:account): Access denied for user
> joe: 6 (Permission denied)

You need to enable SSSD debugging:
https://fedorahosted.org/sssd/wiki/Troubleshooting
and check the sssd logs, probably the HBAC access control is kicking you
out.

-- 
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] FreeIPA Read Only Replica

2017-02-28 Thread Jakub Hrozek
On Mon, Feb 27, 2017 at 11:19:15PM +, Andrey Ptashnik wrote:
> Team,
> 
> Is it possible to setup read only replica for use in DMZ for example?

Not at the moment:
https://pagure.io/freeipa/issue/5569

-- 
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] AD Sites and Trusts

2017-02-27 Thread Jakub Hrozek
On Mon, Feb 27, 2017 at 01:50:50PM -0600, Jason B. Nance wrote:
> Hello,
> 
> I was wondering if this thread regarding AD trusts and sites is still correct:
> 
> https://www.redhat.com/archives/freeipa-users/2015-December/msg00214.html
> 
> (no way to make use of AD sites)

Well, you can configure krb5.conf on the client..but there is still no
automatic configuration.

> 
> If so, is there already an RFE for this that I can vote for and track?

RHEL:
https://bugzilla.redhat.com/show_bug.cgi?id=1416528
upstream:
https://pagure.io/SSSD/sssd/issue/3291

This is a stretch goal for the next upstream release, but given our
timeline and the fact that nobody started on this RFE, I think the
release after the next one is more realistic.

-- 
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] ID Mapping

2017-02-26 Thread Jakub Hrozek
On Sun, Feb 26, 2017 at 12:12:23PM -0800, Hanoz Elavia wrote:
> Hey guys,
> 
> Is it possible to disable ID mapping for AD users in a FreeIPA AD trust
> setup?
> 
> The version report is as follows:
> 
> AD: Windows 2008 R2
> FreeIPA Server: 4.4.0-14
> FreeIPA Client: 4.4.0-14
> SSSD: 1.14.0-43
> Linux version: CentOS 7.3 x64_86
> 
> I've tried setting ldap_id_mapping = False in sssd.conf in the IPA domain
> sectionwith no success.
> 
> Regards,
> 
> Hanoz

In IPA-AD trust environment the mapping is managed on the server. So
you'd need to remove the algorithmical range and add a POSIX range
instead (see  ipa help idrange-add, --type=['ipa-ad-trust-posix',
'ipa-ad-trust', 'ipa-local'])

Note that clients cannot modify the range type at the moment, so you
also need to remove the cache from all clients in the domain.

-- 
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] New user group not shown on IPA client

2017-02-24 Thread Jakub Hrozek
On Fri, Feb 24, 2017 at 12:36:03PM +0100, Gerald Zabos wrote:
> Hello *,
> 
> i just created a new user group 'it_testusers' (9068) on one of
> the IPA servers and added three existing users:
> 
> 'test' (9065)
> 'ipajoin' (9061)
> 'ldaptest' (9063).
> 
> When look up the group membership of these users on one of our IPA
> clients with 'id ' it shows uid, gid and groups=, but
> the new group 'it_testusers' is still missing.
> 
> Looking up group membership with 'id ' on all of our IPA
> servers works, i can see the new group in the list of user's groups.
> 
> Server OS: Redhat 7.3
> ipa-server: ipa-server-4.4.0-14.el7_3.4
> 
> Client OS: CentOS 7.3
> ipa-client: ipa-client-4.4.0-14.el7.centos.4
> 
> I've read https://www.redhat.com/archives/freeipa-users/2015-May/msg00463.html
> as it seems to be a similar problem.
> 
> I stopped sssd, removed the files in /var/lib/sss/db and started sssd
> on the client -> still can't see the new group
> 
> I rebooted the client -> still can't see the new group

I'm afraid you need to look into sssd logs on the client:
https://fedorahosted.org/sssd/wiki/Troubleshooting

-- 
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] IPA and SSSD sudo

2017-02-15 Thread Jakub Hrozek
On Wed, Feb 15, 2017 at 02:44:18PM +0100, Troels Hansen wrote:
> The same rule works as expected if defined in the local sudoers file.

Then I guess this might be a bug..

> 
> I think the problem is that secure_path in "Options" from IPA isn't taken 
> into account.

options should be treated just as any other attribute, so more or les
transparently.

Could you run an ldbsearch of the database to check how was the sudo
rule stored to the sssd cache?

See:
https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO

-- 
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] IPA and SSSD sudo

2017-02-15 Thread Jakub Hrozek
On Wed, Feb 15, 2017 at 11:04:47AM +0100, Troels Hansen wrote:
> Hi there 
> 
> We have a strange problem... 
> 
> We're trying to override options in sudo rules from IPA, in this case 
> secure_path: 
> 
> sudo -ll reports: 
> 
> RunAsUsers: root 
> Options: requiretty, lecture=always, timestamp_timeout=0, !authenticate, 
> secure_path=/bin:/usr/bin:/usr/local/bin 
> Commands: 
> stopinst 
> /usr/local/bin/stopinst 
> /usr/local/bin/startinst 
> /bin/mount /rman 
> /usr/bin/su - root 
> 
> /usr/local/bin is also in my local path: 
> 
> $ echo $PATH 
> /usr/local/bin:/usr/bin:/usr/local/sbin.. 
> 
> For easyness, stopinst is currently quite simple: 
> 
> $ cat /usr/local/bin/stopinst 
> #!/bin/bash 
> echo stopinst 
> echo "Path: $PATH" 
> 
> I can execute the script a normal user, using full path or just the command: 
> $ stopinst 
> stopinst 
> Path: 
> /usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/net.dr.dk/drextrha/.local/bin:/home/net.dr.dk/drextrha/bin
>  
> 
> However, trying to execute the script using sudo fails: 
> $ sudo stopinst 
> [sudo] password for drextrha: 
> sudo: stopinst: command not found 
> 
> Unless using full path: 
> $ sudo /usr/local/bin/stopinst 
> stopinst 
> Path: /bin:/usr/bin:/usr/local/bin 
> 
> Secure path in sudoers is: 
> # grep secure_path /etc/sudoers 
> Defaults secure_path = /sbin:/bin:/usr/sbin:/usr/bin 
> 
> If I change the secure_path in local sudoers to include /usr/local/bin: 
> # grep secure_path /etc/sudoers 
> Defaults secure_path = /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin 
> 
> I can execute the command using sudo: 
> 
> $ sudo stopinst 
> stopinst 
> Path: /bin:/usr/bin:/usr/local/bin 
> 
> S.. something gets overwritten somewhere that shouldn't??? 

We shouldn't rewrite anything on the SSSD side. In general, when it
comes to delivering SUDO rules, SSSD should more or less just act as a
proxy.

Did you try to define a similar rule locally in /etc/sudoers to see if
the same issue happens with a local rule? That should at least confirm
or deny that the issue might be in 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] Where in the login process is KRB5CCNAME being set

2017-02-08 Thread Jakub Hrozek
On Wed, Feb 08, 2017 at 09:59:52AM +0100, Kees Bakker wrote:
> Hi,
> 
> This is a follow-up on the problem I had with
>   klist: Invalid UID in persistent keyring name while getting default ccache
> (See "How to enable krb5_child log" earlier this month.)
> 
> The situation is that we have local users with the same name that exist in 
> IPA,
> but the UIDs are different. We have this on several systems, and it is because
> we are in the process of setting up a FreeIPA server.
> 
> Now (so far), on one system the environment variable KRB5CCNAME is set during
> login. (Login via display manager or console, does not matter. If logged via 
> SSH
> then the variable is not set.)
> 
> My question: where / how is that variable being set? I'd like to understand 
> why
> this one system is different from the rest.

The variable is set by pam_sss.so during the authentication phase.

I suspect the difference might be in the PAM stack -- maybe on the
systems where KRB5CCNAME is not set, the PAM stack is configured using
pam_localuser.so so that if the username exists in /etc/passwd, only
pam_unix.so is tried?

> 
> Other details: Ubuntu 16.04 (server and clients).
> 
> BTW. The klist / kinit problem can easily be solved by unsetting that 
> environment
> variable.
> -- 
> Kees
> 
> 
> -- 
> 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

-- 
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] freeipa hostbased auth "connection closed"

2017-02-05 Thread Jakub Hrozek
On Sun, Feb 05, 2017 at 07:47:43PM +0530, Rakesh Rajasekharan wrote:
> Hi,
> 
> I am running a freeipa server version 4.4.0 and have setup hbac rules which
> work fine
> 
> However, just on one single host , I am seeing this issue wherein it is not
> allowing me ssh access.
> When I check my hbac permissions.. it say access granted but on trying to
> login.. it blocks me
> 
> On the Freeipa server
> ipa hbactest --user=p-testhbac --host=>my-test-host> --service=sshd
> 
> 
> Access granted: True
> 
>   Matched rules: ipa-alluser-access
>   Not matched rules: ipa-alluser-sudo-access
> 
> On the client I get this message while doing an ssh "Connection closed by
> 10.0.30.28".
> 
> In /var/log/secure I see these messages
> Feb  5 13:57:41 10 sshd[26692]: pam_sss(sshd:auth): authentication success;
> logname= uid=0 euid=0 tty=ssh ruser= rhost=10.0.4.6 user=p-testhbac
> Feb  5 13:57:41 10 sshd[26692]: pam_sss(sshd:account): Access denied for
> user p-testhbac: 4 (System error)

If SSSD throws a System Error, you really need to look into SSSD's logs
-- System Error is kind of an unhandled exception in SSSD's code.

> Feb  5 13:57:41 10 sshd[26692]: Failed password for p-testhbac from
> 10.0.4.6 port 40540 ssh2

-- 
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] Can too many group memberships for an AD user cause SSSD or IPA problems?

2017-02-04 Thread Jakub Hrozek
On Fri, Feb 03, 2017 at 09:54:01AM -0500, Chris Dagdigian wrote:
> 
> I've got a case where "id @AD-DOMAIN" hangs forever after partially
> resolving and I think it may because they are in way too many AD groups?

I don't think id should hang totally (at the very least, there is a NSS
timeout that should eventually kick in).

> 
> The 'id' command resolve the user but hangs before completing. There is a
> large amount of group data returned from the AD forest for this user and the
> 'id' command seems to pause/hang right at the 3024th character returned.
> 
> Looking for pointers / tips. I'm thinking the AD user is in way too many
> groups but I don't know if this is a real limit or what the limit may be.
> Any other reason why an 'id' command may start to work but hang before
> completion for an AD-defined user?

I would tail the sssd logs on the client and server to see if the
command really hangs or 'just' processes some super-large group.

Also, see:

https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-ipa-ad-trust-deployments/

-- 
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] How to enable krb5_child log

2017-02-03 Thread Jakub Hrozek
On Fri, Feb 03, 2017 at 09:45:34AM +0100, Kees Bakker wrote:
> On 02-02-17 17:32, Jakub Hrozek wrote:
> > On Thu, Feb 02, 2017 at 05:19:07PM +0100, Kees Bakker wrote:
> >> Hi
> >>
> >> Sorry, I did search wherever I could but I couldn't find it.
> >> How do I enable krb5_child debug log? I'm on an Ubuntu
> >> system which by default writes an empty /var/log/krb5_child.log
> >>
> >> Is it a section in /etc/sssd/sssd.conf? Is it in /etc/krb5.conf? What
> >> do I have to add where to get logging in krb5_child.log?
> > add debug_level= to the [domain] section.
> 
> OK. I've done that before with 0x3ff0 , but this time I used level 6
> (which I read somewhere as being the old method). And now I see
> output in krb5_child.log
> Thanks
> 
> What's weird though. On another system I'm doing the exactly same.
> Nothing is logged in krb5_child.log.
> 
> >
> >> BTW. I'm trying to debug a problem that results in
> >>   "Invalid UID in persistent keyring"
> >> The weird thing is, if I become root (via another ssh login) and
> >> then do a "su - user" (the same user with the error), the problem
> >> does not show up. Meanwhile that user keeps getting the above
> >> error (for klist kdestroy, klist).
> > su as root gets automatically authenticated by the pam_rootok.so
> > module..
> >
> 
> Hmm.
> I'm not sure if you understood what I was doing:
> 
> The "root" way
> $ ssh r...@xyz.example.com
> # su - someuser

As you can see you were not prompted for a password. This is the
pam_rootok.so module in action that just flipped the current user to
someuser.

> $ klist someuser
> klist: Credentials cache keyring 'persistent:1013:1013' not found

This is expected, since pam_sss.so wasn't invoked because the PAM
conversation finished after pam_rootok.so was called.

> $ kinit someuser
> Password for someu...@example.com:
> The latter seems to be working (I can't finish because I don't have that
> password).

Then you won't be able to kinit as the user because you need either to
know the password or have the keytab to decrypt the KDC response with.

> 
> Then, at the very same time user "someuser", on his own login, gets this:
> $ klist
> klist: Invalid UID in persistent keyring name while getting default ccache
> 
> One more thing I should mention. It may be of influence. The "someuser"
> is a local user in /etc/passwd, _and_ it is a user in IPA, with different 
> uid's.
> Could that trigger the error?

Yes, if the UID of the local user and the IPA user differ.

If you need to use the user from passwd and authenticate the user with
his IPA credentials, then you can't use id_provider=ipa in sssd.conf,
but id_provider=proxy and auth_provider=krb5.

-- 
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] How to enable krb5_child log

2017-02-02 Thread Jakub Hrozek
On Thu, Feb 02, 2017 at 05:19:07PM +0100, Kees Bakker wrote:
> Hi
> 
> Sorry, I did search wherever I could but I couldn't find it.
> How do I enable krb5_child debug log? I'm on an Ubuntu
> system which by default writes an empty /var/log/krb5_child.log
> 
> Is it a section in /etc/sssd/sssd.conf? Is it in /etc/krb5.conf? What
> do I have to add where to get logging in krb5_child.log?

add debug_level= to the [domain] section.

> 
> BTW. I'm trying to debug a problem that results in
>   "Invalid UID in persistent keyring"
> The weird thing is, if I become root (via another ssh login) and
> then do a "su - user" (the same user with the error), the problem
> does not show up. Meanwhile that user keeps getting the above
> error (for klist kdestroy, klist).

su as root gets automatically authenticated by the pam_rootok.so
module..

-- 
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] Is WinSync A Bad Choice?

2017-02-02 Thread Jakub Hrozek
On Wed, Feb 01, 2017 at 04:19:39PM -0600, Jason B. Nance wrote:
> >> - Users can't login to a Linux box using just "username" 
> >> (user@ad.domain is
> >> used)
> > 
> > In the current version you can use the 'default_domain_suffix' option in
> > sssd.conf on the clients. In RHEL-7.4 we are looking into making this
> > limitation go away.
> 
> Thank you very much, Jakub.  That is helpful information!  Are you saying 
> that there will basically be a domain search order or something for users 
> that login without specifying a domain?

For the IPA-AD case, probably:
https://fedorahosted.org/sssd/ticket/3210
For the direct AD integration case (which will share the underlying code
with the IPA-AD integration case), the admin would opt-in with a
sssd.conf option, essentially saying 'let me always use shortnames for
all domains, there are no name conflicts' and then sssd would not
require shortnames for trusted domains.

The ticket that tracks the shortname-for-trusted-domains case in general
is:
https://fedorahosted.org/sssd/ticket/3001

Please note the tickets are in the "Future releases" milestone at the
moment, but we do plan them for the next RHEL release; the upstream
milestones just need a bit more grooming.

-- 
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] Is WinSync A Bad Choice?

2017-02-01 Thread Jakub Hrozek
On Wed, Feb 01, 2017 at 03:00:55PM -0600, Jason B. Nance wrote:
> Hello everyone,
> 
> I'm about to deploy a fresh IPA domain that needs to integrate with Active 
> Directory.  In my lab environment I've setup a trust with AD and the 
> following items are driving me away from using the trust:
> 
> - Users can't login to a Linux box using just "username" (user@ad.domain 
> is used)

In the current version you can use the 'default_domain_suffix' option in
sssd.conf on the clients. In RHEL-7.4 we are looking into making this
limitation go away.

(I won't reply to the other two questions because they are outside my
knowledge domain, sorry)

-- 
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] caching of lookups / performance problem

2017-02-01 Thread Jakub Hrozek
On Wed, Feb 01, 2017 at 02:35:00PM +, Sullivan, Daniel [CRI] wrote:
> Jakub,
> 
> Thank you for getting back to me.  Yeah, I agree with what you are saying.  
> The problem that I’m really trying to solve is the how to get them requested 
> reasonably often part.  A good use case for my problem is basically;
> 
> 1) Somebody starts an interactive job on a compute node (this is somewhat 
> unusual in it of itself).  There’s a decent chance that nobody has done this 
> for weeks or months months in the first place.  Since a large number of our 
> 1000 or so users aren’t compute users theres a high probablity that we have a 
> substantial number of expired cached entries, possibly 500 or more for users 
> in /home.
> 2) They are navigating around on the filesystem and cd into /home and type 
> ‘ls -l’
> 
> This command will actually take upwards of an hour to execute (although it 
> will complete eventually).  If an ‘ls -l’ on a Linux system takes more than a 
> few seconds people will think there’s a problem with the system.
> 
> Based on my experience even ‘nowait percentage’ has a difficult time with a 
> large number of records past the nowait threshold.  For example, if there are 
> 500 records past the expiration percentage threshold, the data provider will 
> get ‘busy’ which seems to effectively appears to block the nss responder, 
> instead of returning all 500 of those records from the cache and then 
> queueing 500 data provider requests in the background to refresh the cache.

Yes, when the cache is totally expired, the request would block.

> 
> Right now the only ways I can seem to get around this is to do a regular ‘ls 
> -l’ to refresh the cache on our nodes, or just defer the problem by setting a 
> really high entry cache timeout.  The cron approach is a little bit 
> challenging because we need to randomize invocation times because bulk cache 
> refreshes across the environment are going to cause high load on our domain 
> controllers (I know this because a single cache refresh causes ns-slapd to 
> hit 100% and sustain CPU utilization for the duration of the enumeration).
> 
> Is there anything crazy about setting the entry cache timeout on the client 
> to something arbitrarily high, like 5 years (other than knowing the cache is 
> not accurate)?  Based on my knowledge a user’s groups are evaluated at login 
> so this should be a non-issue from a security standpoint.

I think a long expiration together with the nowait percentage might be
a way to go.

-- 
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] caching of lookups / performance problem

2017-02-01 Thread Jakub Hrozek
On Tue, Jan 31, 2017 at 08:05:18PM +, Sullivan, Daniel [CRI] wrote:
> Hi,
> 
> I figured out what was going on with this issue.  Basically cache timeouts 
> were causing a large number of uid numbers in an arbitrarily-timed directory 
> listing to have expired cache records, which causes those records to be 
> looked up again by the data provider (and thus blocking ‘ls -l’).  To work 
> around this issue now we currently setting the entry_cache_timeout to 
> something arbitrarily high, i.e. 99, I’m questioning whether or not this 
> is the best approach.  I’d like to use something like 
> refresh_expired_interval, although based on my testing it appears that this 
> does not update records for a trusted AD domain.  I’ve also tried using 
> enumeration, and that doesn’t seem to work either.
> 
> I suppose my question is this; is there a preferred method to keep cache 
> records up-to-date for a trusted AD domain?  Right now I am thinking about 
> cron-tabbing an ‘ls -l’ of /home and allowing entry_cache_nowait_percentage 
> to fill this function, although that seems hacky to me.
> 
> Any advisement that could be provided would be greatly appreciated.

Hi,

If the entries are requested reasonably often (typically at least once
per cache lifetime), then maybe just lowering the
'entry_cache_nowait_percentage' value so that the background check is
performed more often might help.

-- 
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] sudo sometimes doesn't work

2017-01-30 Thread Jakub Hrozek
On Fri, Jan 27, 2017 at 02:15:16PM -0700, Orion Poplawski wrote:
> EL7.3
> Users are in active directory via AD trust with IPA server
> 
> sudo is configured via files - users in our default "nwra" group can run
> certain sudo commands, e.g.:
> 
> Cmnd_Alias WAKEUP = /sbin/ether-wake *
> %nwra,%visitor,%ivm   ALL=NOPASSWD: WAKEUP
> 
> However, sometimes when I run sudo /sbin/ether-wake I get prompted for my
> password.  Other times it works fine.  I've attached some logs from failed
> attempt.

So the sudo command is successfull in the end, it 'just' prompts for a
password?

I think the sudo logs would be the most important part here, see:
https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO
there is a section called ' a) How do I get sudo logs?' that explains
how to generate them..

-- 
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 doesn't cache, as it seems

2017-01-21 Thread Jakub Hrozek

> On 21 Jan 2017, at 06:46, Harald Dunkel  wrote:
> 
> On 01/20/17 18:42, Simo Sorce wrote:
>> 
>> Is your server being used for authentication ?
>> SSSD, by default, always refreshes user credentials on authentication,
>> but you can use the cached_auth_timeout setting to relax this
>> requirement in SSSD, and reduce the roundtrips for auth attempts.
>> 
> 
> I have set both pam_id_timeout and cached_auth_timeout to 30.
> No change, still several requests per second for each user.
> 
> ???
> Harri
> 

Can you check what kind of query do you see in the LDAP server log?

Do the server logs correlate with debug logs from the nss and domain sections 
of sssd?

Are you sure there is no other NSS module in nsswitch.conf other than files and 
sss?

> -- 
> 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


-- 
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] ipa_server and ipa_backup_server failover time

2017-01-09 Thread Jakub Hrozek
(please keep CC-ing the list..)

On Mon, Jan 09, 2017 at 04:39:04PM +0800, Matrix wrote:
> Sorry, i did not trigger authentication at all. Just to check sssd logs. 
> around 15 minutes later, I saw below messages shown:
> 
> (Mon Jan  9 01:46:35 2017) [sssd[be[fwmrm.net]]] [fo_set_port_status] 
> (0x0100): Marking port 0 of server 'ipa02.example.com' as 'working'
> 
> Re-check it with authentication, failover will be happened immediately. 

Yes, then that is expected, the identity lookup was probably answered from
the cache.

> 
> >> No, sorry, the timeouts for switching between back up and primary
> >> servers are hardcoded.
> 
> May I know how long it will take for worst case? 

Seems to be 30 minutes:

https://github.com/SSSD/sssd/blob/master/src/providers/data_provider_fo.c#L49

-- 
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] Kerberos Clock Skew too great

2017-01-09 Thread Jakub Hrozek
On Mon, Jan 09, 2017 at 02:07:21PM +0530, Rakesh Rajasekharan wrote:
> yes on the IPA server as well.. the offset isn't that high
> 
>  remote   refid  st t when poll reach   delay   offset
> jitter
> ==
> *ip-10-10-1-150.e 132.163.4.1012 u  119  128  3770.431   -0.279
> 0.348
> 
> So, my NTP server, the ipa client and the IPA master.. all seems to not
> have a high offset or a jitter.
> 
> There were about 1500 hosts that were alerting for "clock skew" and the
> issue went away only after I did a resync using ntpdate on all those hosts
> 
> Is it possible that so many higher number of minor offsets adds up and
> causes it. Coz from the individual offset it looks much below the 5min limit
> 
> Or, is there a way to tell whats the offset limit its actually looking for.

Sorry, I'm a bit out of my depth here, the only other suggestion I have
is to try kinit with KRB5_TRACE=/dev/stderr when that happens, which
should at least dump which KDC is the client talking to (if you have
multiple masters..)

> 
> Thanks,
> Rakesh
> 
> 
> 
> On Mon, Jan 9, 2017 at 1:42 PM, Jakub Hrozek <jhro...@redhat.com> wrote:
> 
> > On Mon, Jan 09, 2017 at 01:07:06PM +0530, Rakesh Rajasekharan wrote:
> > > Hi,
> > >
> > > I am using a Freeipa 4.2.0 server.
> > >
> > > I sometimes see, "clock skew too great" errors in /var/log/krb5kdc.log.
> > And
> > > when this happens, usually logins or new ipa-cleint-install fails.
> > >
> > > When I checked on one of the hosts for which the clock skew was reported,
> > >
> > > #> ntpq -p
> > > remote   refid  st t when poll reach   delay   offset
> > > jitter
> > > 
> > ==
> > > *ip-10-10-1-150.e 171.66.97.1262 u  869 1024  3770.4480.047
> > > 0.142
> >
> > In general, 5 minutes is OK at least. But are you sure the server is also
> > in sync or just the client against an NTP server (iow, are you sure you
> > are checking the difference between a client and the KDC as well?)
> >
> > --
> > 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
> >

-- 
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] Kerberos Clock Skew too great

2017-01-09 Thread Jakub Hrozek
On Mon, Jan 09, 2017 at 01:07:06PM +0530, Rakesh Rajasekharan wrote:
> Hi,
> 
> I am using a Freeipa 4.2.0 server.
> 
> I sometimes see, "clock skew too great" errors in /var/log/krb5kdc.log. And
> when this happens, usually logins or new ipa-cleint-install fails.
> 
> When I checked on one of the hosts for which the clock skew was reported,
> 
> #> ntpq -p
> remote   refid  st t when poll reach   delay   offset
> jitter
> ==
> *ip-10-10-1-150.e 171.66.97.1262 u  869 1024  3770.4480.047
> 0.142

In general, 5 minutes is OK at least. But are you sure the server is also
in sync or just the client against an NTP server (iow, are you sure you
are checking the difference between a client and the KDC as well?)

-- 
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] freeipa 4.4.0 and Ubuntu 14.04

2017-01-09 Thread Jakub Hrozek
On Fri, Jan 06, 2017 at 11:48:07AM -0500, Andy Brittingham wrote:
> Sorry for the delay, was doing some troubleshooting.
> 
> Here is what I know now:
> 
> The problem is on Ubuntu hosts using older sssd versions 1.11.8 (Ubuntu
> 14.04).
> 
> SSSD versions 1.13.4 (Ubuntu 16.04) and 1.13.3 (CentOS 6.8) both work.
> 
> Users in the admin group can't log into these hosts.
> 
> I created a newadmins group and assigned a new user to it. When I add the
> "User Administrator" role the new user can't log into the hosts with older
> sssd.
> 
> As soon as I delete the "User Administrator" role, new user has access
> again.

So is it a role membership or a group membership that makes the
difference?

> 
> I've pasted the last bit of logs from a sssd_domain log below. I'd be happy
> to forward the entire log, or additional logs if they will be helpful.

The log only captures a user lookup, not a login, sorry..

(This might be expected if you log in e.g. with an SSH key, in which
case journald should be the first thing to look at at least to poinpoint
which piece denied access..)

-- 
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] freeipa 4.4.0 and Ubuntu 14.04

2017-01-06 Thread Jakub Hrozek
On Fri, Jan 06, 2017 at 09:01:12AM -0500, Andy Brittingham wrote:
> Hi,
> 
> I upgraded my Freeipa servers to 4.4.0-14 on CentOS 7 yesterday. None of my
> Ubuntu clients with versions < 16.04 (sssd version 1.13.4) can authenticate
> against the upgraded servers. It appears the problem is the version of sssd
> that is installed in the earlier Ubuntu versions. Is this a know issue and
> does anyone know of a work around for this? The sssd package in the PPA repo
> for 14.04 ( 1.12.5-1~trusty) didn't fix the issue.

What do the sssd logs say?

-- 
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] FreeIPA sudo not working on ububtu xenial sssd version 1.13.4-1ubuntu1.1

2017-01-05 Thread Jakub Hrozek
On Thu, Jan 05, 2017 at 01:36:56PM +, James Harrison wrote:
> Hi all,I having problems with a FreeIPA client running Ububtu Xenial.
> I can authenticate OK, I get a kerberos ticket, but cannot run sudo.
> I get 1 rule returned, which I expect.
> Many thanks,James Harrison

I would check if (with the help of ldbsearch against the sssd cache or
with the help of the sudo logs) if the rule is really the one you are
expecting or if it's just the cn=defaults rule.

If it's just cn=defaults, then I would check if the rules are downloaded
(sssd always downloads all rules applicable for the host IIRC) or if
they just don't match the filter that you can see in the debug message
from sudosrv_get_sudorules_query_cache. Keep in mind that this is a
filter that applies for the sssd cache, not LDAP.

And lastly, if the rules are downloaded as expected, the sudo rules
would tell you why the rule didn't match.

All in all, this document:
https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO
describes how to troubleshoot the sudo integration.

-- 
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] Unable to resolve AD users from IPA clients

2017-01-03 Thread Jakub Hrozek
On Tue, Jan 03, 2017 at 03:39:19PM +0100, Jan Karásek wrote:
> Hi, 
> 
> I have trouble with resolving AD users from my IPA clients. 
> 
> Environment: 2x IPA server with trust into AD - both IPA servers and clients 
> running latest rhel 7.3. 
> 
> IPA domain: vs.example.com 
> AD domain: example.com, cen.example.com 
> 
> All tstx users are in cen.example.com but their UPN is set to 
> tstxx...@example.com 
> 
> I can run id and getent passwd commands without problem from both IPA 
> servers: 
> 
> id tst99...@example.com 
> uid=20018(tst99...@cen.example.com) gid=5001(csunix) 
> groups=5001(csunix),93008(final_test_group) 
> 
> getent tst99...@example.com 
> tst99...@cen.example.com:*:20018:5001:ipa_test:/home/cen.example.com/tst99655:/bin/bash
>  
> 
> But from client: 
> 
> root@trh7clnt02:~# id tst99...@example.com 
> id: tst99...@example.com: no such user 
> root@trh7clnt02:~#getent passwd tst99...@example.com 
> ... no reply 
> 
> 
> But when I run on client: 
> getent group csu...@cen.example.com - it takes more then 30s 
> csu...@cen.example.com:*:5001:  and really long list of users 
> 
> Then again from client: 
> 
> root@trh7clnt02:~# id tst99...@example.com 
> uid=20018(tst99...@cen.example.com) gid=5001(csunix) groups=5001(csunix) 
> 
> root@trh7clnt02:~# getent passwd tst99...@example.com 
> tst99...@cen.example.com:*:20018:5001:ipatest:/home/cen.example.com/tst99655:/bin/bash
>  
> 
> This time it works and it keeps working until I clean the sssd cache on 
> client. Then I have to run that getent group csunix command again. 
> 
> I would say it is some timeout issue with enumerating csunix group. I have 
> tried to fix it by adding: 
> 
> ldap_search_timeout = 50 

I don't think this would be related to the searches timing out but
probably parsing and storing the entries on the server and the client.

Could you try adding this on the server side's sssd.conf?

[domain/domname]
subdomain_inherit = ignore_group_members
ignore_group_members = True

By the way, did you install 7.3 cleanly or did you upgrade? And if you
upgraded, did you ever removed the cache post-upgrade on the server?

There's been some improvements related to performance in 7.3 and even
more are coming in 7.4.

-- 
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] Any good CLI methods for testing connectivity from IPA replica to remote AD servers?

2017-01-02 Thread Jakub Hrozek
On Wed, Dec 28, 2016 at 08:52:41AM -0500, Chris Dagdigian wrote:
> 
> Hi folks,
> 
> I may have network blocks between one of my IPA replicas and the *many*
> remote AD servers that need to be queried but I can only see evidence of
> this in the authentication failures and the debug level logging.
> 
> Not sure how to test from the command line to verify connectivity or narrow
> down which ports may be getting blocked.
> 
> Are there any common CLI techniques, ldaps:// search queries or other
> commands that could be run from an IPA replica to confirm basic
> communication with a remote AD controller?

1) kinit with the trust keytab. The exact principals depend on your IPA
and Windows realm names, in my test setup it is:

# ls /var/lib/sss/keytabs/
win.trust.test.keytab
#kinit -kt /var/lib/sss/keytabs/win.trust.test.keytab 'IPA$@WIN.TRUST.TEST'
(the principal is taken from the keytab, see klist -k
/var/lib/sss/keytabs/win.trust.test.keytab)

2) search the DC
#ldapsearch -Y GSSAPI -H ldap://dc.win.trust.test -b dc=win,dc=trust,dc=test -s 
base 

btw at the moment it is not possible to set custom DCs to talk to. This
feature will come in the next version (sssd-1-15).

-- 
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] Unable to sudo with just one user on only a few servers

2017-01-02 Thread Jakub Hrozek
On Sat, Dec 31, 2016 at 07:43:20AM +, pgb205 wrote:
> I have followed troubleshooting procedure outlined hereTroubleshooting - 
> FreeIPA
> 
>   
> |  
> |   
> |   
> |   ||
> 
>|
> 
>   |
> |  
> |   |  
> Troubleshooting - FreeIPA
>|   |
> 
>   |
> 
>   |
> 
>  
> Additionally I have done contrast and compare with a working server for the 
> following 
> files/etc/hosts/etc/resolv.conf/etc/sudo-ldap.conf/etc/krb5.conf/etc/sssd.conf/etc/nssswitch.conf
> all are identical other than host specific information.
> In addition I have also enabled debug_level in sssd.conf in all stanzas, but 
> noticed that sudo log is not being generated.I can however provide other logs.
> I have also enabled sudo_debug=2 in /etc/sudo-ldap.confbut not sure where to 
> look for that log file.
> A and PTR records exist for problematic servers in FreeIPA DNS.
> As mentioned above the user-id can  ssh just fine but not sudo for any 
> command even though that id should be able to do ANY ANY.
> I have checked the the user-id is in the correct sudo groups that are applied 
> for the host-groups for broken servers.
> To add to the oddity we somehow managed to fix the problem on several servers 
> but as it was a lot blind trial and error we are not surewhat the corrective 
> steps actually were. 
> Please let me know what else I can/should take a look at. I can also provide 
> logs if needed.
> thanks

If the sudo log is not being generated at all, then I would assume that
sudo is not talking to sssd at all. Did you check the sudo logs (the
logs of the sudo binary, not the sssd-sudo responder) already?

The howto is here:
https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO

-- 
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] replica running trust-agents can't resolve AD users - which of these sssd errors should I be focusing on?

2016-12-23 Thread Jakub Hrozek
On Thu, Dec 22, 2016 at 11:34:01PM +0200, Alexander Bokovoy wrote:
> On to, 22 joulu 2016, Chris Dagdigian wrote:
> > Hi folks,
> > 
> > Summary:  Replica w/ Trust agents can't resolve AD users. Not sure which
> > debug_level=log error I should focus on. Would appreciate extra eyeballs
> > on this ..
> > 
> > Have a brand new replica (v4.4) running and after installing the AD
> > trust agents I still can't recognize users who exist in the trusted AD
> > domains.
> > 
> > Running at debug_level=10 for logging as usual however deleting the logs
> > and doing a fresh reboot followed by trying to resolve a users still
> > make 4000+ log entries so rather than include it here I've posted a
> > sanitized sssd_domain.log file here:
> > 
> > http://chrisdag.me/sssd_companyidm.org.log.txt
> > 
> > There are two sets of messages in that massive log file that concern me
> > but I don't know enough yet to figure out which one to focus on.
> > 
> > The first set of messages show what appears to be a fatal error in
> > connecting to the local ldap:// server on the replica.
> > 
> > However -
> > - dirsirv logs look fine
> > - the various ldapsearch commands in the Free-IPA troublehooting page
> > work to query both the replica and the remote master
> > - 'ipactl status' shows directory services running
> > - no firewall blocking and AWS VPC flowLogs show no REJECT traffic
> > whatsoever for the NIC on the replica
> Can you show us ldap_child.log and krb5_child.log from /var/log/sssd on
> the replica?
> 
> There seem to be something weird with networking stack, because at
> 15:43:13 the next attempt to connect gets 'connection refused'. May be
> 389-ds is just warming up and there is not enough CPU or I/O to handle
> the load?
> 
> (Thu Dec 22 15:43:13 2016) [sssd[be[companyidm.org]]]
> [be_resolve_server_process] (0x0200): Found address for server 
> usaeilidmp002.companyidm.org: [10.127.66.11] TTL 7200
> (Thu Dec 22 15:43:13 2016) [sssd[be[companyidm.org]]]
> [sssd_async_socket_init_send] (0x4000): Using file descriptor [27] for the 
> connection.
> (Thu Dec 22 15:43:13 2016) [sssd[be[companyidm.org]]]
> [sssd_async_socket_init_send] (0x0400): Setting 6 seconds timeout for 
> connecting
> (Thu Dec 22 15:43:13 2016) [sssd[be[companyidm.org]]]
> [sssd_async_connect_done] (0x0020): connect failed [111][Connection refused].
> (Thu Dec 22 15:43:13 2016) [sssd[be[companyidm.org]]]
> [sssd_async_socket_init_done] (0x0020): sdap_async_sys_connect request 
> failed: [111]: Connection refused.
> 
> this is definitely is different from the result of two seconds before:
> 
> (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]]
> [sssd_async_socket_init_send] (0x4000): Using file descriptor [21] for the 
> connection.
> (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]]
> [sssd_async_connect_send] (0x0020): connect failed [101][Network is 
> unreachable].
> (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]]
> [sssd_async_socket_init_send] (0x0400): Setting 6 seconds timeout for 
> connecting
> (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]]
> [sssd_async_socket_init_done] (0x0020): sdap_async_sys_connect request 
> failed: [101]: Network is unreachable.
> (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]]
> [sssd_async_socket_state_destructor] (0x0400): closing socket [21] (Thu Dec
> 22 15:43:11 2016) [sssd[be[companyidm.org]]]
> [sss_ldap_init_sys_connect_done] (0x0020): sssd_async_socket_init request 
> failed: [101]: Network is unreachable.
> (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]]
> [sdap_sys_connect_done] (0x0020): sdap_async_connect_call request failed: 
> [101]: Network is unreachable.
> 
> Later, in a minute it seems to respond just well:
> 
> 
> (Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]]
> [sssd_async_socket_init_send] (0x4000): Using file descriptor [27] for the 
> connection.
> (Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]]
> [sssd_async_socket_init_send] (0x0400): Setting 6 seconds timeout for 
> connecting
> (Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]]
> [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to 
> [ldap://usaeilidmp002.companyidm.org:389/??base] with fd [27].
> (Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]]
> [sdap_get_rootdse_send] (0x4000): Getting rootdse
> (Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]]
> [sdap_print_server] (0x2000): Searching 10.127.66.11:389
> ...
> 
> (Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]] [sdap_parse_range]
> (0x2000): No sub-attributes for [supportedSASLMechanisms]
> (Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]] [sdap_parse_range]
> (0x2000): No sub-attributes for [defaultNamingContext]
> (Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]] [sdap_parse_range]
> (0x2000): No sub-attributes for [lastUSN]
> (Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]]
> [sdap_process_result] (0x2000): Trace: sh[0x7f4f63ace530], connected[1], 
> ops[0x7f4f63b283d0], ldap[0x7f4f63b28720]

Re: [Freeipa-users] Upgrade to 4.4.0 Breaks login.

2016-12-23 Thread Jakub Hrozek
On Thu, Dec 22, 2016 at 08:38:38PM -0500, Dan Kemp wrote:
> Hello,
> 
> I recently ran an upgrade of my freeipa servers, and most of the clients to
> 4.4.0 (Current with CentOS 7 repos) from version 4.2.0. After the install
> and server update, I can no longer log in to update clients via ssh. Login
> to non-update clients works as before.
> 
> The SSH connections fail with:
> 
> Connection closed by UNKNOWN
> 
> I ran sssd with debugging on a failing 4.4.0 client and got this error log:
> 
> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [ldb] (0x4000): commit
> ldb transaction (nesting: 2)
> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [ldb] (0x4000): commit
> ldb transaction (nesting: 1)
> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [ldb] (0x4000): commit
> ldb transaction (nesting: 0)
> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]]
> [selinux_child_create_buffer] (0x4000): buffer size: 45
> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_handler_setup]
> (0x2000): Setting up signal handler up for pid [437]
> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_handler_setup]
> (0x2000): Signal handler set up for pid [437]
> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [sdap_process_result]
> (0x2000): Trace: sh[0x560c04c37790], connected[1], ops[(nil)],
> ldap[0x560c04c32d60]
> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [sdap_process_result]
> (0x2000): Trace: end of ldap_result list
> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [write_pipe_handler]
> (0x0400): All data has been sent!
> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x0400):
> selinux_child started.
> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x2000):
> Running with effective IDs: [0][0].
> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x2000):
> Running with real IDs [0][0].
> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x0400):
> context initialized
> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [unpack_buffer]
> (0x2000): seuser length: 12
> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [unpack_buffer]
> (0x2000): seuser: unconfined_u
> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [unpack_buffer]
> (0x2000): mls_range length: 14
> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [unpack_buffer]
> (0x2000): mls_range: s0-s0:c0.c1023
> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [unpack_buffer]
> (0x2000): username length: 7
> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [unpack_buffer]
> (0x2000): username: ipauser
> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x0400):
> performing selinux operations
> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [sss_semanage_init]
> (0x0020): SELinux policy not managed
> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [get_seuser]
> (0x0020): Cannot create SELinux handle
> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437
> [seuser_needs_update] (0x2000): get_seuser: ret: 5 seuser: unknown mls:
> unknown
> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [sss_semanage_init]
> (0x0020): SELinux policy not managed
> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [set_seuser]
> (0x0020): Cannot init SELinux management
> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x0020):
> Cannot set SELinux login context.
> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x0020):
> selinux_child failed!
> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [read_pipe_handler]
> (0x0400): EOF received, client finished
> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [selinux_child_done]
> (0x0020): selinux_child_parse_response failed: [22][Invalid argument]
> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_req_done] (0x0400):
> DP Request [PAM SELinux #3]: Request handler finished [0]: Success
> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [_dp_req_recv]
> (0x0400): DP Request [PAM SELinux #3]: Receiving request data.
> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_req_destructor]
> (0x0400): DP Request [PAM SELinux #3]: Request removed.
> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_req_destructor]
> (0x0400): Number of active DP request: 0
> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_pam_reply]
> (0x1000): DP Request [PAM Account #2]: Sending result [4][domain.local]
> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_sig_handler]
> (0x1000): Waiting for child [437].
> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_sig_handler]
> (0x0020): child [437] failed with status [1].
> (Wed Dec 20 20:38:13 2016) [sssd[pam]] [sbus_remove_timeout] (0x2000):
> 0x55f4be11f4c0
> (Wed Dec 20 20:38:13 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn:
> 0x55f4be1191b0
> (Wed Dec 20 20:38:13 2016) [sssd[pam]] [sbus_dispatch] (0x4000):
> Dispatching.
> (Wed 

Re: [Freeipa-users] Sudo rule implementation

2016-12-20 Thread Jakub Hrozek
On Tue, Dec 20, 2016 at 01:19:15PM +0300, Ben .T.George wrote:
> Hi List,
> 
> please help me to implement sudo rules.
> 
> i have did below steps and still not working for me.
> 
> 1. created "Sudo Command Groups"
> 2. Added some command (/bin/yum) and included in sudo group
> 3. created "sudo Rule" on that
> * added sudo Option as "!authenticate"
>   * Added User Group.
>   * Added one Host
>   * And under Run command, selected the Sudo Rule Group.
> 4. entry on nsswitch.conf : sudoers: files sss
> 5. entry on sssd.conf : services = nss, sudo, pam, ssh
> 
> and i tried removing "!authenticate" and changed to Anyone, Any Host and Any
> Command,
> Also under As Whom to Anyone and Any Group
> - I tried logout and login again on client with IPA user which is member of
> user group.
> 
> When i am running yum, getting error that user is not allowed to execute
> command.
> 
> 
> Please anyone help to correct my steps.
> 
> Regards
> Ben

Please follow:
https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO
especially the sudo logs are often helpful to see what rules is sssd
returning to sudo.

-- 
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] How to implement sudo rules

2016-12-18 Thread Jakub Hrozek
I hope this helps pinpoint the issue:
https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO 


> On 18 Dec 2016, at 10:04, Ben .T.George  wrote:
> 
> Hi List,
> 
> please help me to implement sudo rules.
> 
> i have did below steps and still not working for me.
> 
> 1. created "Sudo Command Groups"
> 2. Added some command (/bin/yum) and included in sudo group
> 3. created "sudo Rule" on that
> * added sudo Option as "!authenticate"
>   * Added User Group.
>   * Added one Host
>   * And under Run command, selected the Sudo Rule Group.
> 
> I tried logout and login again on client with IPA user which is member of 
> user group. 
> 
> When i am running yum, getting error that user is not allowed to execute 
> command.
> 
> 
> Please anyone help to correct my steps.
> 
> Regards
> Ben
> -- 
> 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

-- 
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 with Free IPA Client Ubuntu Precise (12.04) authenticating with AD account

2016-12-07 Thread Jakub Hrozek
On Wed, Dec 07, 2016 at 06:19:06PM +, James Harrison wrote:
> Hi all,
> 
> I am trying to authenticate an ubuntu Precise (12.06) fully patched system. 
> Its enrolled into a FreeIPA server. The following trace is the output of 
> syslog auth sssd/*.log and full debug (-ddd) from the sshd service.
> 
> I am getting a PAM error at the end of the procedure. Also I cant seem to 
> authenticate against the public ssh key from the id override user.
> 
> I appreciate any help you can send my way.
> 
> Best regards,
> 
> James Harrison
> Below is more information
> 
> 
> root@jamesprecise:~# kinit x_james.harrison@AD.DOMAIN.LOCAL
> Password for x_james.harrison@AD.DOMAIN.LOCAL:
> 
> root@jamesprecise:~# klist
> Ticket cache: FILE:/tmp/krb5cc_0
> Default principal: x_james.harrison@AD.DOMAIN.LOCAL
> 
> Valid starting Expires    Service principal
> 07/12/16 17:56:30  08/12/16 03:56:30  krbtgt/AD.DOMAIN.LOCAL@AD.DOMAIN.LOCAL
>     renew until 08/12/16 17:56:23
> 
> root@jamesprecise:~# id x_james.harrison@AD.DOMAIN.LOCAL
> uid=1039812876(x_james.harrison@ad.domain.local) 
> gid=1039812876(x_james.harrison@ad.domain.local) 
> groups=1039812876(x_james.harrison@ad.domain.local)

HBAC denied the login, which is probably related to the supplementary
groups not being resolved. This ancient SSSD version doesn't support
returning supplementary groups unless you log in -- during the login
attempt, the PAC responder should be able to decode the group
memberships from the PAC and store the groups.

So I'd look if the PAC responder is enabled and running and see if the
krb5_child resolves the SIDs during password authentication (or if PAC
responder is contacted during password-less authentication).

> root@pul-lv-ipa-02 ~]# ipa  idoverrideuser-show External_AD_views 
> x_james.harrison@ad.domain.local
>   Anchor to override: x_james.harrison@ad.domain.local
>   User login: x_james.harrison
>   Login shell: /bin/bash
>   SSH public key: ssh-rsa
>   
> B3NzaC1yc2EDAQABAAABAQDK1pj2U7H9olLs1xKmcmZVEBMWpaHjxF2LttsdfqfQxm810qMru/WsvzHqu0m5Ugu0FYsPxRLQrAEB8WPsPoh5Y0q5qYPgm5aDOZZEXfCPyuRwdQ+XLfQJ3gnGjW4r/XLEiNVpO9eKsFs0ifspNAJ1n7h40rlHlOIqV/z8Omg6XnFBh9dIfiXtpYDOxe+512RpjtHE98s+NfIpUTT7MGNLHB5o/DqFXEJPH7Pp1bKwxWNvfCb5a71vcE695dQ31QYVYwpSwFmFogewgpV/OCb+S4SUdUq1xg0fmkhYr3d4UXFr91MDimyOBWk9Aai7NkOHPszmHJp
>   JamesHarrison

Overrides are not supported with this version.

> 
> 
> Here are the software versions:
> 
> root@jamesprecise:# dpkg -l | grep -i freeipa
> ii  freeipa-client 3.3.4-0ubuntu3.1~precise0.1
>     FreeIPA centralized identity framework -- client
> ii  libipa-hbac0   1.11.5-1ubuntu3~precise1   
>     FreeIPA HBAC Evaluator library
> ii  python-freeipa 3.3.4-0ubuntu3.1~precise0.1
>     FreeIPA centralized identity framework -- python modules
> ii  python-libipa-hbac 1.11.5-1ubuntu3~precise1   
>     Python bindings for the FreeIPA HBAC Evaluator library
> 
> root@jamesprecise:# dpkg -l | grep -i openssh-server
> ii  openssh-server 1:5.9p1-5ubuntu1.10
>     secure shell (SSH) server, for secure access from remote machines
> 
> 
> root@jamesprecise:/var/log# dpkg -l | grep -i sssd
> ii  libsss-idmap0  1.11.5-1ubuntu3~precise1   
>     ID mapping library for SSSD
> ii  sssd   1.11.5-1ubuntu3~precise1   
>     System Security Services Daemon -- metapackage
> ii  sssd-ad    1.11.5-1ubuntu3~precise1   
>     System Security Services Daemon -- Active Directory back end
> ii  sssd-ad-common 1.11.5-1ubuntu3~precise1   
>     System Security Services Daemon -- PAC responder
> ii  sssd-common    1.11.5-1ubuntu3~precise1   
>     System Security Services Daemon -- common files
> ii  sssd-ipa   1.11.5-1ubuntu3~precise1   
>     System Security Services Daemon -- IPA back end
> ii  sssd-krb5  1.11.5-1ubuntu3~precise1   
>     System Security Services Daemon -- Kerberos back end
> ii  sssd-krb5-common   1.11.5-1ubuntu3~precise1   
>     System Security Services Daemon -- Kerberos helpers
> ii  sssd-ldap  1.11.5-1ubuntu3~precise1   
>     System Security Services Daemon -- LDAP back end
> ii  sssd-proxy 1.11.5-1ubuntu3~precise1   
>     System Security Services Daemon -- proxy back end
> ii  sudo   1.8.9p5-1ubuntu1.1~sssd1   
>     Provide limited super user privileges to specific users

All is all, I would suggest to upgrade to something more recent..

-- 
Manage your subscription for the Freeipa-users mailing list:

Re: [Freeipa-users] mount lookup failure getautomntent_r

2016-11-28 Thread Jakub Hrozek
On Sun, Nov 27, 2016 at 05:34:20PM -0500, William Muriithi wrote:
> Jakub,
> 
> Thanks for response
> On 27 November 2016 at 15:43, Jakub Hrozek <jhro...@redhat.com> wrote:
> >
> >>
> >> I have noticed an error that pop up as the final line after running
> 
> >> lookup_read_map: lookup(sss): getautomntent_r: No such file or directory
> >>
> >>  failed to read map
> >>
> >> Have anyone found a way to clean up that error?
> >>
> >
> > No idea without more context, sorry. Does auto mounter actually work for 
> > you or are some maps missing?
> >
> The mount work fine actually. I only noticed the error because I have
> a script that is consuming the standard output from "automount -m"
> command.  I thought instead of filtering away the error, it would be
> more prudent to fix the root issue.

Yes..

> 
> > The message can really be harmless, because the client (=automounter) 
> > iterates over the maps returned by the server (=sssd in this context) until 
> > the server returns ENOENT. I agree though the message is confusing and 
> > we’ll be (most probably) looking at some autofs enhancements in the next 
> > sssd version..
> >
> Now that I have shared some context, is there any way I can track down
> whats might be causing it? Or better, whats are some of the candidate
> mistakes that can trigger it.

As long as all the maps are returned, though, this is really only a
confusing error message. I think the code that causes it is in SSSD's
automounter client code, around line 172 with the current master:

172 if (len == 0) {
173 /* There are no more records. */
174 *_key = NULL;
175 *_value = NULL;
176 ret = ENOENT;
177 goto done;
178 } 

what you see in the output is just strerror(ENOENT)..

-- 
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] mount lookup failure getautomntent_r

2016-11-27 Thread Jakub Hrozek

> On 27 Nov 2016, at 18:31, William Muriithi  wrote:
> 
> Hello,
> 
> I have noticed an error that pop up as the final line after running
> this command "
> automount -m". I suspect its related to selinux, but haven't seen how
> to fix it from the google search this morning.
> 
> I have autofs maps on IPA and using SSSD to read the maps.
> 
> 
> Mount point: /-
> 
> 
> source(s):
> 
> lookup_read_map: lookup(sss): getautomntent_r: No such file or directory
> 
>  failed to read map
> 
> Have anyone found a way to clean up that error?
> 

No idea without more context, sorry. Does auto mounter actually work for you or 
are some maps missing?

The message can really be harmless, because the client (=automounter) iterates 
over the maps returned by the server (=sssd in this context) until the server 
returns ENOENT. I agree though the message is confusing and we’ll be (most 
probably) looking at some autofs enhancements in the next sssd version..

> Regards,
> William
> 
> -- 
> 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


-- 
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] AD Trust users not resolving on clients: ipa_get_*_acct request failed

2016-11-23 Thread Jakub Hrozek
On Wed, Nov 23, 2016 at 05:58:58PM +1100, Robert Sturrock wrote:
> Hi All.
> 
> I’m having a problem getting trust users to resolve on *any* IPA client (this 
> _was_ working well and I’m not sure what’s changed that may have caused it to 
> start failing - although we have recently updated to IPA 4.4, plus IPA DNS 
> enabled with delegation of ipa.example.com).
> 
> Whenever I try to lookup a trust user on a client (Ubuntu 16.04 with 
> sssd-1.13.4-1ubuntu1.1) I see:
> 
> # id usern...@example.com
> id: ‘usern...@example.com': no such user
> 
> The error message block in the sssd/domain log is:
> 
> > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] 
> > [sysdb_search_by_name] (0x0400): No such entry
> > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_group_dn_list] 
> > (0x0040): find_domain_by_object_name failed.

The error happens here. Too bad we don't print the names of the group that
failed the find_domain_by_object_name() but I would guess a supplemetary
name is qualified with a domain that the client doesn't know for some reason.

The only suggestion I have is to run "id" for this user on the server
and check the domains of the supplementary groups that are returned.
Then check if the domains are expected. You can also run ldbsearch on
the client cache with objectclass=subdomain to check which trusted
domains the client knows about and whether they match the domains of the
supplementary groups on the server.

(This wouldn't fix the issue of course, but maybe help us understand
better where the error really is..)

Do you maybe use some non-default configuration on the server that
strips the domain names from the qualified name?

> > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] 
> > [ipa_s2n_get_user_done] (0x0040): get_group_dn_list failed.

> > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [sdap_id_op_done] 
> > (0x4000): releasing operation connection
> > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] 
> > [ipa_subdomain_account_done] (0x0040): ipa_get_*_acct request failed: [12]: 
> > Cannot allocate memory.
> > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [sdap_id_op_destroy] 
> > (0x4000): releasing operation connection
> > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [acctinfo_callback] 
> > (0x0100): Request processed. Returned 3,12,Out of memory
> 
> 
> A more complete log is below.
> 
> The domain users resolve fine on each of the three IPA servers (all RHEL7 
> with ipa-server-4.4.0-12.el7.x86_64).
> 
> IPA domain is ipa.example.com.  AD domain is example.com.
> 
> I have looked at https://fedorahosted.org/sssd/wiki/Troubleshooting, but no 
> particular ideas are coming from that, so I guess I’m after some hints about 
> what to check or any further tests to try.
> 
> Regards,
> 
> Robert.
> 
> 
> (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [sbus_dispatch] 
> (0x4000): dbus conn: 0xfd8480
> (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [sbus_dispatch] 
> (0x4000): Dispatching.
> (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [sbus_message_handler] 
> (0x2000): Received SBUS method 
> org.freedesktop.sssd.dataprovider.getAccountInfo on path 
> /org/freedesktop/sssd/dataprovider
> (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] 
> [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit
> (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [be_get_account_info] 
> (0x0200): Got request for [0x1001][FAST BE_REQ_USER][1][name=mib]
> (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [be_req_set_domain] 
> (0x0400): Changing request domain from [ipa.example.com] to [example.com]
> (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] 
> [sdap_id_op_connect_step] (0x4000): reusing cached connection
> (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] 
> [sdap_id_op_connect_step] (0x4000): reusing cached connection
> (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] 
> [ipa_get_ad_override_connect_done] (0x4000): Searching for overrides in view 
> [Default Trust View] with filter [(&(objectClass=ipaUserOverride)(uid=mib))].
> (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [sdap_print_server] 
> (0x2000): Searching 172.25.180.53
> (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] 
> [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with 
> [(&(objectClass=ipaUserOverride)(uid=mib))][cn=Default Trust 
> View,cn=views,cn=accounts,dc=ipa,dc=example,dc=com].
> (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] 
> [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 21
> (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [sdap_op_add] 
> (0x2000): New operation 21 timeout 6
> (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [sdap_process_result] 
> (0x2000): Trace: sh[0xfd76d0], connected[1], ops[0xff6420], ldap[0xfded70]
> (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [sdap_process_message] 
> (0x4000): Message 

Re: [Freeipa-users] Is there an simple way to add in sudo time window options in FreeIPA?

2016-11-20 Thread Jakub Hrozek

> On 18 Nov 2016, at 19:12, Robert Kleinberg  wrote:
> 
> Would like to establish valid sudo usage windows with sudonotbefore and 
> sudonotafter options.  However, I did not see an easy way to set this up 
> other than via an sudo options text entry line.  Is there another menu-driven 
> way that shows a schedule of allowed times?
>  

I think at the moment you need to —setattr or —addattr the sudo attributes,  I 
don’t think the sudo IPA UI allows settings these “natively”.

> Bob Kleinberg
> Lead System Engineer
>  
> KEYW Corporation|www.keywcorp.com 
> 7740 Milestone Parkway, Suite 400 | Hanover, MD 21076
> 443-737-9703
>  
> -- 
> 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

-- 
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] Rhel 7 client enroll to Rhel 6 IPA server

2016-11-16 Thread Jakub Hrozek
On Wed, Nov 16, 2016 at 09:56:59AM -0700, Sean Hogan wrote:
> [root@server1 read]# kinit -kt /etc/krb5.keytab host/server1.ipa.local
> kinit: Program lacks support for encryption type while getting initial
> credentials

OK, now there's at least the same error from kinit as sssd is
generating. Can you runs this command prepended with
KRB5_TRACE=/dev/stderr and perhaps also check the KDC logs for the same
time?

But frankly I don't know offhand what enctypes are supported by the
RHEL-6 server's KDC..

-- 
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] Rhel 7 client enroll to Rhel 6 IPA server

2016-11-16 Thread Jakub Hrozek
On Tue, Nov 15, 2016 at 07:24:38PM -0700, Sean Hogan wrote:
> 
> 
> Hello,
> 
> 
>I am starting to see some issues with a few RHEL7 boxes I have been
> enrolling to my RHEL 6 IPA server regarding encryption.
> 
> 
> RHEL 7 client
> Red Hat Enterprise Linux Server release 7.1 (Maipo)
> sssd-ipa-1.12.2-58.el7_1.18.x86_64
> ipa-client-4.1.0-18.el7_1.4.x86_64
> 
> RHEL 6 Server
> Red Hat Enterprise Linux Server release 6.8 (Santiago)
> sssd-ipa-1.13.3-22.el6_8.4.x86_64
> ipa-server-3.0.0-50.el6.1.x86_64
> 
> 
> The RHEL 7 client shows this in messages
> 
> Nov 15 21:13:02 server1 [sssd[ldap_child[26640]]]: Program lacks support
> for encryption type

Could you post a more verbose ldap_child log (debug_level=10 includes
KRB5_TRACE-level messages) so that we see what kind of crypto was used?

> Nov 15 18:08:51 server1 [sssd[ldap_child[7774]]]: Failed to initialize
> credentials using keytab [MEMORY:/etc/krb5.keytab]: Decrypt integrity check
> failed. Unable to create GSSAPI-encrypted LDAP connection.
> 
> I am also not seeing host certs for them on the ipa server but I do see
> them on the local box.
> 
> [root@server1 pam.d]# ktutil

Can you run klist -ke as well to see what encryption types are included
in the keytab?

Is it possible to run "kinit -k" on the client?

> ktutil:  rkt /etc/krb5.keytab
> ktutil:  l
> slot KVNO Principal
>  
> -
>11 host/server1.ipa.local@IPA.LOCAL
>21 host/server1.ipa.local@IPA.LOCAL
>31 host/server1.ipa.local@IPA.LOCAL
>41 host/server1.ipa.local@IPA.LOCAL
> ktutil:
> 
> 
> I have one RHEL 7 box with no issues as it was just enrolled (missing host
> certs in IPA though)  and I compared and IPA ID login with a box not
> working
> Work
> type=USER_AUTH msg=audit(1479259242.032:23532): pid=25040 uid=0
> auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023
> msg='op=PAM:authentication grantors=? acct="janedoe" exe="/usr/sbin/sshd"
> hostname=10.10.10.10 addr=10.10.10.10 terminal=ssh res=failed'
> 
> vs
> 
> Works
> type=USER_ACCT msg=audit(1479259478.378:709): pid=4721 uid=0
> auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023
> msg='op=PAM:accounting grantors=pam_unix,pam_sss,pam_permit acct="janedoe"
> exe="/usr/sbin/sshd" hostname=10.10.10.10 addr=10.10.10.10 terminal=ssh
> res=success'
> 
> Its almost as if the pam files are not being read?
> 
> 
> 
> Sean Hogan
> 
> 
> 
> 
> 
> 




> -- 
> 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

-- 
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] SUDO and group lookup in AD trust

2016-11-07 Thread Jakub Hrozek
On Mon, Nov 07, 2016 at 08:28:45AM +0100, Troels Hansen wrote:
> Hi there, I can see that RHEL 7.3 have left beta, and wanted to check this 
> shiny new release that should fix a lot of the problems and current quirks we 
> have, so I went through the release notes on SSSD in RHEL 7.3 and can't see 
> any patched being added since end September, and in particular a patch for 
> RHBZ# 1371152 in the SSSD 1.14 release ?

I'm not completely sure which release notes are you referring to, but
this bug was fixed in sssd-1.14.0-32.el7. It's also listed in the
changelog:

* Fri Sep  2 2016 Jakub Hrozek <jhro...@redhat.com> - 1.14.0-32
- Resolves: rhbz#1371152 - SSSD qualifies principal twice in IPA-AD trust
   if the principal attribute doesn't exist on the
   AD side

-- 
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] Remove AD domain in auth commands

2016-11-04 Thread Jakub Hrozek
On Fri, Nov 04, 2016 at 11:04:28AM +, James Harrison wrote:
> Hello,
> I've installed FreeIPA 4.2 master using Centos and I have a Windows 2012R2 
> with its AD schema emulating a Windows 2012 system
> I have established a trust between the two and it appears to work. I can 
> reference a user on the AD domain, but the only way is to add the AD domain. 
> 
> The only way to ssh to the master IPA server is like this:
> 
>  ssh "x_@IPAWIN.LOCAL"@10.10.10.10
> Another example is using kinit:
> I have to do the following to get a credential:kinit x_@IPAWIN.LOCAL
> Ideally I would not need or use the "@IPAWIN.LOCAL". 
> 
> Can anyone help?
> Best regards,James Harrison

Currently the only way is to use default_domain_suffix. This might
change in the upcoming version of sssd (1.15)

-- 
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] Service discovery and selection for IPA

2016-11-02 Thread Jakub Hrozek
On Tue, Nov 01, 2016 at 06:44:46PM -0400, Jake wrote:
> Hey All, 
> Quick question on IPA Service discover and selection (ldap/kerberos in ad 
> trust). 
> 
> Do IPA clients ping results of SRV records to determine which server they 
> send requests (for ldap/kerberos specifically)? 
> 
> I have 8 AD Domain controllers, 2 in each location, and 4 ipa servers (2 in 
> each of 2 locations), it seems the ipa servers rarely choose the local ad 
> controllers, is there a way to adjust this? Must I setup something like 
> geo-dns with different service weights per subnet? 

Please note that the identity lookups of AD users are mostly done by SSSD
on the IPA masters and the IPA clients read the AD user data from the
IPA masters. So I would make sure that the IPA masters are assigned to a
local site, then SSSD should prefer DCs from that site. The DNS queries
and the discovery should be visible in the SSSD domain logs on the IPA
masters.

Authentication is done by calling libkrb5 on the clients which is not
site-aware.

-- 
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] IPA-AD trust group membership: display 'short' group names for *two* AD domains?

2016-10-24 Thread Jakub Hrozek
On Mon, Oct 24, 2016 at 11:29:06AM -0400, William Muriithi wrote:
> Morning Jakub,
> 
> >>  However, I would like to tune this configuration to drop the domain
> >>  component of the user and group names.  I tried to do this by adding
> >>  these settings to the [sssd] section in sssd.conf on the client:
> >>
> >>default_domain_suffix = example.au
> >> full_name_format = %1$s
> >>
> >>  With this configuration, I can login as a staff domain user (example.au)
> >> successfully and I then see the short-name form of the groups:
> >>
> >> $ ssh -l r...@student.example.au ipa-client-rh7.ipa.example.au
> >> [rnst@ipa-client-rh7 ~]$ groups
> >> rnst
> >>
> >> Is this expected behaviour?  Is there a possible client configuration that
> >> will support our AD forest setup or is this simply not possible?
> >
> > What you did is quite correct, but unfortunately works only with
> > RHEL-7.3 or newer as it requires sssd-1.14 or newer, sorry.
> 
> Does one need  sssd-1.14 on the IPA server only or is this required on
> all the IPA clients too?

I haven't tested since I was working in this area, but I belive the clients
as well.

-- 
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] IPA-AD trust group membership: display 'short' group names for *two* AD domains?

2016-10-21 Thread Jakub Hrozek
On Fri, Oct 21, 2016 at 04:07:16PM +1100, Robert Sturrock wrote:
> > On Thu, Oct 20, 2016 at 04:46:01PM +1100, Robert Sturrock wrote:
> > […]
> > > However, when I try logging in as a student domain user 
> > > (student.example.au),
> > > I don't see any of the groups (there should be 8):
> > > 
> > > $ ssh -l rnst student example au ipa-client-rh7.ipa.example.au
> > > [rnst ipa-client-rh7 ~]$ groups
> > > rnst
> > > 
> > > Is this expected behaviour?  Is there a possible client configuration that
> > > will support our AD forest setup or is this simply not possible?
> > 
> > What you did is quite correct, but unfortunately works only with
> > RHEL-7.3 or newer as it requires sssd-1.14 or newer, sorry.
> 
> I tried the same configuration on FC24, which has sssd-1.14.1-3, but it 
> didn’t work for the student domain either:
> 
> $ ssh -l r...@student.example.au ipa-client-fc24.ipa.example.au
> -sh-4.3$ groups
> rnst
> 
> Is the version shipping with RHEL7.3 likely to be different?

No, it's pretty much the same. Can you take a look at the logs and
create a dump of the ldb cache, please?

See:
https://fedorahosted.org/sssd/wiki/Troubleshooting

-- 
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] IPA-AD trust group membership: display 'short' group names for *two* AD domains?

2016-10-20 Thread Jakub Hrozek
On Thu, Oct 20, 2016 at 04:46:01PM +1100, Robert Sturrock wrote:
> Hello,
> 
> We have an IPA (4.2) server setup on RHEL 7.2 in a trust arrangement with
> our University organisational AD.  The AD forest contains *two*
> domains:
> 
>   EXAMPLE.AU (staff users)
>   STUDENT.EXAMPLE.AU (student users)
> 
> The IPA domain that trusts these is called:
> 
>   IPA.EXAMPLE.AU
> 
> The basic configuration as described above works ok - we can login to
> IPA client hosts with user principals from either of the AD domains
> and we see correct group membership.
> 
> However, I would like to tune this configuration to drop the domain
> component of the user and group names.  I tried to do this by adding
> these settings to the [sssd] section in sssd.conf on the client:
> 
> default_domain_suffix = example.au
> full_name_format = %1$s
> 
> With this configuration, I can login as a staff domain user (example.au)
> successfully and I then see the short-name form of the groups:
> 
> $ ssh -l r...@example.au ipa-client-rh7.ipa.example.au
> [rns@ipa-client-rh7 ~]$ groups
> rns domain users d-750g 511all [..etc..]
> 
> However, when I try logging in as a student domain user (student.example.au),
> I don't see any of the groups (there should be 8):
> 
> $ ssh -l r...@student.example.au ipa-client-rh7.ipa.example.au
> [rnst@ipa-client-rh7 ~]$ groups
> rnst
> 
> Is this expected behaviour?  Is there a possible client configuration that
> will support our AD forest setup or is this simply not possible?

What you did is quite correct, but unfortunately works only with
RHEL-7.3 or newer as it requires sssd-1.14 or newer, sorry.

-- 
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] Unable to resolve AD users from IPA client

2016-10-17 Thread Jakub Hrozek
On Mon, Oct 17, 2016 at 01:27:40PM +0200, Jan Karásek wrote:
> Hi, 
> please can you help me with troubleshooting IPA clients in IPA - AD trust 
> scenario ? We have two IPA servers and couple of clients running on RHEl 6 
> and 7. IPA is running on RHEL 7.2. 
> AD servers are in domains example.cz, cen.example.cz. Test users sits in 
> cen.example.cz. IPA is subdomain of AD - vs.example.cz. 
> Trust is set as one-way trust. User's POSIX attributes are stored in AD. 
> 
> ipa idrange-find 
>  
> 3 ranges matched 
>  
> Range name: CEN.EXAMPLE.CZ 
> First Posix ID of the range: 9880 
> Number of IDs in the range: 20 
> Domain SID of the trusted domain: S-1-5-21-527237240-1482476501-682003330 
> Range type: Active Directory trust range with POSIX attributes 
> 
> Range name: EXAMPLE.CZ_id_range 
> First Posix ID of the range: 6880 
> Number of IDs in the range: 20 
> Domain SID of the trusted domain: S-1-5-21-73586283-1958367476-682003330 
> Range type: Active Directory trust range with POSIX attributes 
> 
> Range name: VS.EXAMPLE.CZ_id_range 
> First Posix ID of the range: 93000 
> Number of IDs in the range: 20 
> First RID of the corresponding RID range: 1000 
> First RID of the secondary RID range: 1 
> Range type: local domain range 
>  
> Number of entries returned 3 
>  
> 
> I have no problem to resolve AD users from both IPA server: 
> 
> IPA Server: 
> root#:id tst99...@cen.example.cz 
> uid=20019(tst99...@cen.example.cz) gid=5001(csunix) 
> groups=5001(csunix),93008(final_test_group) - this is correct 
> 
> but from IPA client: 
> root#:id tst99...@cen.example.cz 
> id: tst99...@cen.example.cz: no such user 
> 
> ==> sssd_vs.example.cz.log <== 
> (Mon Oct 17 12:24:29 2016) [sssd[be[vs.example.cz]]] [be_get_account_info] 
> (0x0200): Got request for [0x1001][1][name=tst99654] 
> (Mon Oct 17 12:24:29 2016) [sssd[be[vs.example.cz]]] [be_req_set_domain] 
> (0x0400): Changing request domain from [vs.example.cz] to [cen.example.cz] 
> (Mon Oct 17 12:24:29 2016) [sssd[be[vs.example.cz]]] 
> [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with 
> [(&(objectClass=ipaUserOverride)(uid=tst99654))][cn=Default Trust 
> View,cn=views,cn=accounts,dc=vs,dc=example,dc=cz]. 
> (Mon Oct 17 12:24:29 2016) [sssd[be[vs.example.cz]]] 
> [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg 
> set 
> (Mon Oct 17 12:24:29 2016) [sssd[be[vs.example.cz]]] [ipa_s2n_exop_send] 
> (0x0400): Executing extended operation 
> (Mon Oct 17 12:24:29 2016) [sssd[be[vs.example.cz]]] [ipa_s2n_exop_done] 
> (0x0400): ldap_extended_operation result: Success(0), (null). 
> (Mon Oct 17 12:24:29 2016) [sssd[be[vs.example.cz]]] [sysdb_search_by_name] 
> (0x0400): No such entry 
> (Mon Oct 17 12:24:29 2016) [sssd[be[vs.example.cz]]] [sysdb_search_by_name] 
> (0x0400): No such entry 
> (Mon Oct 17 12:24:29 2016) [sssd[be[vs.example.cz]]] [ipa_s2n_exop_send] 
> (0x0400): Executing extended operation 
> (Mon Oct 17 12:24:29 2016) [sssd[be[vs.example.cz]]] [ipa_s2n_exop_done] 
> (0x0040): ldap_extended_operation result: No such object(32), (null). 
> (Mon Oct 17 12:24:29 2016) [sssd[be[vs.example.cz]]] 
> [ipa_s2n_get_fqlist_next] (0x0040): s2n exop request failed. 
> (Mon Oct 17 12:24:29 2016) [sssd[be[vs.example.cz]]] 
> [ipa_s2n_get_fqlist_done] (0x0040): s2n get_fqlist request failed. 
> (Mon Oct 17 12:24:29 2016) [sssd[be[vs.example.cz]]] [acctinfo_callback] 
> (0x0100): Request processed. Returned 0,0,Success (Success) 
> 
> All IPA clients have the same result - No such user. On the other hand 
> kerberos works fine - I can do kinit with AD users both on IPA servers and 
> clients. All IPA clients use the same DNS server as IPA servers. 
> 
> 
> On IPA server, I can see that it is able to find test user in AD. Log is 
> captured during IPA client request for id: 
> 
> (Mon Oct 17 12:26:05 2016) [sssd[be[vs.example.cz]]] 
> [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with 
> [(&(sAMAccountName=tst99654)(objectclass=user)(sAMAccountName=*)(&(uidNumber=*)(!(uidNumber=0][dc=cen,dc=example,dc=cz].
>  
> (Mon Oct 17 12:26:05 2016) [sssd[be[vs.example.cz]]] 
> [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] 
> (Mon Oct 17 12:26:05 2016) [sssd[be[vs.example.cz]]] 
> [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sAMAccountName] 
> (Mon Oct 17 12:26:05 2016) [sssd[be[vs.example.cz]]] 
> [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [unixUserPassword] 
> (Mon Oct 17 12:26:05 2016) [sssd[be[vs.example.cz]]] 
> [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uidNumber] 
> (Mon Oct 17 12:26:05 2016) [sssd[be[vs.example.cz]]] 
> [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gidNumber] 
> (Mon Oct 17 12:26:05 2016) [sssd[be[vs.example.cz]]] 
> [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gecos] 
> 

Re: [Freeipa-users] diskless workstations in an IPA domain

2016-10-14 Thread Jakub Hrozek
On Fri, Oct 14, 2016 at 09:44:11AM +0200, Sumit Bose wrote:
> On Fri, Oct 14, 2016 at 12:41:23AM +0200, Jacquelin Charbonnel wrote:
> > Thank you for this information. Yes, /tmp is writable.
> > 
> > My problem is : access are sometimes definitively refused for random 
> > user
> > who wants to log in diskless workstations.
> > But if this banned user tries to connect to the single machine which 
> > mounts
> > the fs in rw mode, it's work, and this solve immediately its problem on all
> > the other stateless machines !? Strange...
> 
> Maybe it is the selinux_provider, iirc at least in older version it used
> to write some data somewhere below /etc/selinux/. You can easily test
> this by setting 'selinux_provider = none' in the domain section in
> ssd.conf.

Aah, that's probably it. We no longer write to the directory directly,
but we call libsemanage functions that do.

-- 
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] diskless workstations in an IPA domain

2016-10-14 Thread Jakub Hrozek
On Fri, Oct 14, 2016 at 12:41:23AM +0200, Jacquelin Charbonnel wrote:
>   Thank you for this information. Yes, /tmp is writable.
> 
>   My problem is : access are sometimes definitively refused for random 
> user
> who wants to log in diskless workstations.
>   But if this banned user tries to connect to the single machine which 
> mounts
> the fs in rw mode, it's work, and this solve immediately its problem on all
> the other stateless machines !? Strange...

I'm sorry, but without some logs from journald or syslog or sssd, I
don't know what to advice.

I just know that at least in the past there were people running SSSD on
diskless nodes because we still have a rwtab file in the sssd tree and
it contains just a single line:
dirs @sharedstatedir@/sss
(@sharedstatedir@ is an autoconf macro which normally expands to
/var/lib..)

-- 
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] diskless workstations in an IPA domain

2016-10-13 Thread Jakub Hrozek
On Thu, Oct 13, 2016 at 05:45:32PM +0200, Jacquelin Charbonnel wrote:
> Hi everybody,
> 
>   What is the best practice to enroll diskless Fedora24 workstations 
> (under
> stateless Linux) into a IPA domain ?
>   Each diskless workstation mounts its filesystem in RO mode from a single
> NFS share, with some specific directories (like /var/lib/sss) mapped RW in
> RAM.

I can't speak for other components, but /var/lib/sss/ is the only
directory sssd writes to (except tmpfiles, but I guess /tmp would also
be a writable fs?)

-- 
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 1.14.1, HBAC still not working?

2016-10-11 Thread Jakub Hrozek
On Tue, Oct 11, 2016 at 03:28:55PM +1100, Lachlan Musicman wrote:
> After further testing, I've discovered that the dev system wasn't working
> as well as I thought it was: HBAC and sshd don't seem to be playing well
> together on one server, but fine on the other?
> 
> ie, I can run the same commands from both ipa-server and ipa-client:
> 
> ipa hbactest  --user=user1 --host=ipa-server.unixdev.petermac.org.au
> --service=sshd
> ipa hbactest  --user=user1 --host=ipa-client.unixdev.petermac.org.au
> --service=sshd
> 
> 
> and every response is:
> 
> to the ipa-client
> 
> Access granted: True
> 
>   Matched rules: Admin Users (w sudo)
>   Matched rules: Users
> 
> to the ipa-server
> 
> Access granted: True
> 
>   Matched rules: Cluster Admin Users (sudo)
>   Not matched rules: Cluster Users
> 
> 
> but when I try to login to the ipa-server, I get an instance disconnect? I
> can login happily to the ipa-client no problems.
> 
> Is there a special rule about sshd and the ipa-server?

No, there shouldn't be. Can you generate sssd logs on the instance that
is acting up and send them to me? It's best to run date and expire the
cache before the test as well:
sss_cache -E; date; ssh user@host; date
so that we can cross-check the logs knowing the time of the test. If you
don't mind I'd like to share the logs with other SSSD developers because
I think I already tried to look into this issue and couldn't find the root
cause in the past, so maybe others will spot something..

-- 
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] Install IPA Servers with third-party certificate(external CA)

2016-09-30 Thread Jakub Hrozek
On Thu, Sep 29, 2016 at 10:03:08PM -0400, beeth beeth wrote:
> Thanks Florence and Rob! The replica worked after adding the certs during
> the replica preparation.
> 
> Now I got several IPA clients installed with user authentication(ssh login
> with the users in IPA) working after some work. However, one of them failed
> during login with the following messages in syslog:
> 
> Sep 29 21:41:13 ipaclient3 [sssd[krb5_child[2527]]]: Credentials cache
> permissions incorrect

This is RHEL-7, right? Then I'm not sure why would ccache permissions be
incorrect, maybe except for an SELinux issue.. (you are using the KEYRING
ccache, right?)

> Sep 29 21:41:13 ipaclient3 [sssd[krb5_child[2527]]]: Decrypt integrity
> check failed
> Sep 29 21:41:13 ipaclient3 [sssd[krb5_child[2527]]]: Decrypt integrity
> check failed

These two mean a wrong password was supplied.

You can enable sssd debugging and take a look into krb5_child.log. If
you crank up the debug_level all the way up to 10, then you'll also see
KRB5_TRACE-level messages..

-- 
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] HBAC rules stop working

2016-09-30 Thread Jakub Hrozek
On Thu, Sep 29, 2016 at 07:51:14PM -0600, Orion Poplawski wrote:
> server:
> ipa-server-4.2.0-15.sl7_2.19.x86_64
> sssd-1.13.0-40.el7_2.12.x86_64
> 
> client:
> sssd-1.14.1-3.el7.centos.x86_64
> 
> AD trust - users are in AD.  HBAC rule in place for client to allow a user
> to login/ssh/su/etc.
> 
> This seems to have happened a couple times now, and again today after
> rebooting the IPA server.  sssd was denying the user to ssh into the client
> by pam rules.  Logged on to the IPA server and disabled and then re-enabled
> the HBAC rule for the client and then was able to log back in again.  Has
> anyone else seen this before?
> 
> client sssd_pam just went from:
> 
> (Thu Sep 29 19:30:40 2016) [sssd[pam]] [pam_reply] (0x0200): pam_reply
> called with result [6]: Permission denied.
> 
> to
> 
> (Thu Sep 29 19:37:04 2016) [sssd[pam]] [pam_reply] (0x0200): pam_reply
> called with result [0]: Success.
> 
> so I assume I'll need to collect debug logs from sssd on the server next
> time.

Yes..please try to collect logs from a machine that exhibits the bug. I
suspect this is not related to HBAC per se, but rather to external group
memberships, so it would also be nice to check if the groups are
resolved on the faulty machine. And if they wouldn't be, please also
check if they are resolved on the server itself (and collect logs
there..)

-- 
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] external groups and /etc/group

2016-09-30 Thread Jakub Hrozek
On Thu, Sep 29, 2016 at 08:01:59PM -0400, Rusty Shackleford wrote:
> On Thu, Sep 29, 2016 at 4:47 PM, Jakub Hrozek <jhro...@redhat.com> wrote:
> 
> >
> > I think you are looking for:
> > https://sourceware.org/glibc/wiki/Proposals/GroupMerging
> >
> 
> Well that's a bummer. Thanks for getting back to me.

The functionality is already implemented and should work in newer
Fedoras. Unfortunately it is not backported to RHEL/centos..

-- 
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] external groups and /etc/group

2016-09-29 Thread Jakub Hrozek
On Thu, Sep 29, 2016 at 04:35:58PM -0400, Rusty Shackleford wrote:
> If I create an external group in freeIPA and add a user to that group, does
> that mean if that group exists on a host in /etc/group that the user will
> be a member of that group on that host? I've been trying to achieve that
> result but am failing and I don't know if I'm failing because I
> misunderstand what an external group is for, if I've missed a config option
> somewhere in freeipa or sssd, or if I'm simply using software that is too
> old. I'm using ipa-server-3.0.0-50.el6.centos.2 and sssd-1.13.3-22.el6_8.4
> from the centos 6 updates repo.

I think you are looking for:
https://sourceware.org/glibc/wiki/Proposals/GroupMerging

-- 
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] Sudo Rule not working

2016-09-29 Thread Jakub Hrozek
On Thu, Sep 29, 2016 at 08:22:03AM +, Deepak Dimri wrote:
> Hi All,
> 
> I have added sudo rule  having allowed command for sudo su for a test user. 
> When i login with this test user to my IPA client (ubuntu). I am getting a 
> message that "the user is not in the sudoers file.  This incident will be 
> reported." and it works fine if i add the user to sudoers file then the user 
> can switch to sudo and is able to run all the commands even the commands i 
> have included in "deny" list in my IPA server.
> 
> 
> Do we need to have  user/group added sudoers list for IPA sudo rule to work? 
> if so then how can i make it work with IPA sudo rules?

Please check out:
https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO

-- 
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] AD users can't login to IPA client

2016-09-21 Thread Jakub Hrozek
On Wed, Sep 21, 2016 at 05:43:29PM +0500, Alexander K wrote:
> Hello,
> 
> I'm having troubles with AD users authentication on IPA client.
> I have 3 VMs in my test inveronment:
> win-dc.windc.local 10.1.97.122 - AD DC server 2012R2
> fedora-dc.demo.loc 10.1.97.120 - fedora 24 + FreeIPA
> wks.demo.loc 10.1.97.121 - IPA client
> 
> I have done IPA AD trust setup
> https://www.freeipa.org/page/Active_Directory_trust_setup
> 
> AD user can access IPA server:
> login as: Administrator@windc.local
> Administrator@windc.local@10.1.97.120's password:
> Last login: Wed Sep 21 13:59:36 2016 from 192.168.70.26
> Could not chdir to home directory /home/windc.local/administrator: No such
> file or directory
> -sh-4.3$
> 
> IPA user can login IPA client:
> login as: admin
> admin@10.1.97.121's password:
> Last login: Wed Sep 21 16:12:31 2016 from 192.168.70.26
> [admin@wks ~]$
> 
> 
> But AD user can't access IPA client:
> login as: Administrator@windc.local
> Administrator@windc.local@10.1.97.121's password:
> Access denied
> 
> On another hand, ID works correct for AD users:
> [root@wks ~]# id Administrator@windc.local
> uid=429000500(administrator@windc.local)
> gid=429000500(administrator@windc.local)
> groups=429000500(administrator@windc.local),429000520(group policy creator
> owners@windc.local),429000519(enterprise admins@windc.local),429000513(domain
> users@windc.local),429000518(schema admins@windc.local),429000512(domain
> admins@windc.local)
> 
> I have attached logs
> (Last login time is 17:29-17:30)

The domain logs say the authentication takes too long, it might be
due to processing the PAC. Try increasing the authentication timeout
(krb5_auth_timeout).
> 
> 
> Any help would be appreciated!
> 
> 
> -- 
> Best regards,
> Alexander K





> -- 
> 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

-- 
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] login auth fails then success

2016-09-20 Thread Jakub Hrozek
On Tue, Sep 20, 2016 at 02:03:38PM +, Larry Rosen wrote:
> Thanks, that explains a lot (I didn't catch the difference in auth services).
> Would this be mitigated by putting sss in front of files in nsswitch.conf)?
> 
> /etc/nsswitchconf:
> passwd: files sss
> shadow: files sss
> group:  files sss

No, NSS is a separate interface. You can experiment with adding
pam_localuser.so before pam_unix, though.

btw this is how recent Fedora releases configure their PAM stack:
authrequired  pam_env.so
authsufficientpam_fprintd.so
auth[default=1 success=ok] pam_localuser.so
auth[success=done ignore=ignore default=die] pam_unix.so nullok 
try_first_pass
authrequisite pam_succeed_if.so uid >= 1000 quiet_success
authsufficientpam_sss.so forward_pass
authrequired  pam_deny.so

But watch out, PAM stacks are inherently distro-specific and I don't
remember what exactly you're running.

-- 
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


  1   2   3   4   5   6   7   8   9   >