Re: [Freeipa-users] login/su problem on ubuntu

[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] unable to decode: {replica

[lejeczek]

On 28/02/17 09:45, Petr Vobornik wrote:

On 02/26/2017 11:35 AM, lejeczek wrote:

hi everyone

I first time see:

unable to decode: {replica 60} 586eaffd000a003c 
586eaffd000a003c

Replica Update Vectors:


on all four servers. What would be a correct 
troubleshooting and fixing this

problem?
many thanks,
L.





Hello,

what is the version and OS of your IPA servers and DS?

 $ rpm -q ipa-server freeipa-server 389-ds-base

well I run a Centos 7.x and
~]$ rpm -q ipa-server freeipa-server 389-ds-base
ipa-server-4.4.0-14.el7.centos.4.x86_64
package freeipa-server is not installed
389-ds-base-1.3.5.10-15.el7_3.x86_64

I searched the net and archives but failed to find anything 
flagged as "solved".





Similar issues happened last year, you can search the 
archives for "unable to decode" but a 389-ds fix improved 
the situation. So if you have older version then maybe 
update and then manual cleanup of RUVs 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

[Freeipa-users] login/su problem on ubuntu

[Karl Forner]

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)
Feb 28 16:48:32 nyx su[26394]: pam_acct_mgmt: Permission denied
Feb 28 16:48:32 nyx su[26394]: FAILED su for joe by karl

This computer is setup exactly like a dozen of others that work fine.
What could be the problem ?

Thanks,
Karl Forner

P.S
Description:Ubuntu 14.04.5 LTS
3.16.0-76-generic #98~14.04.1-Ubuntu SM
-- 
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-replica-conncheck wants listener on port 7389

[Ian Pilcher]

On 02/28/2017 03:37 AM, Standa Laznicka wrote:

Please, rather check what the problem is. Port 7389 is not required for
the newer system, but the old 6.x system has to be listening on it so
that we can replicate agains the older Dogtag database. From the
previous mail I believe you were following the right documentation,
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html#migrating-ipa-proc,
correct?


Yes, but I hit this issue when setting up replication from a (temporary)
CentOS 7 system back to the newly re-installed system.

I believe that I understand the issue.

The ipa-replica-conncheck man page at
https://linux.die.net/man/1/ipa-replica-conncheck says this:

  -c, --check-ca
  Include in a check also a set of dogtag connection requirements.
  When a replica is self-sign this option is not needed.

But the man page in CentOS 7 says:

  -c, --check-ca
  Include in a check also a set of dogtag connection requirements.
  Only needed when the master was installed with Dogtag 9 or lower.

As a system administrator who is unfamiliar with the inner workings of
FreeIPA, neither version really helped me to figure out if I should be
passing that option.  (The answer appears to be "yes" when the existing
server was CentOS 6, but "no" when the existing server is CentOS 7.)

--

Ian Pilcher arequip...@gmail.com
 "I grew up before Mark Zuckerberg invented friendship" 


--
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] CentOS 6 -> 7 migration

[Ian Pilcher]

On 02/28/2017 03:49 AM, Petr Vobornik wrote:

On 02/26/2017 04:58 PM, Rob Verduijn wrote:

Sounds feasable, however I'm not sure which solution entails the most
work.


+1

Just in case, I'll mention migration documentation:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html#migrating-ipa-proc


There are some manual steps regarding CA which should not be skipped.



Thanks for mentioning that.  I thought that I was done, but I had missed
that part.

--

Ian Pilcher arequip...@gmail.com
 "I grew up before Mark Zuckerberg invented friendship" 


--
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 install, unsupported format?

[Steve Huston]

On Tue, Feb 28, 2017 at 4:26 AM, Standa Laznicka  wrote:
> On 02/27/2017 04:51 PM, Steve Huston wrote:
>> It seems there might be two issues here; the one I originally reported
>> was that the ipa-server packages installed on a client machine are
>> unable to talk to the server, even though it obviously knows what the
>> server is (the "unsupported format" error I originally shared).  The
>> second is with setting up a replica in general.
>
> The server rpm packages should have no impact on client settings if neither
> server nor replica are installed on the given machine. IIRC client only uses
> the NSS database in /etc/ipa/nssdb, you may want to check the permissions
> there (should be o+xr for the folder, o+r for the *.db files there).

I'll look into this more later, since it's less of an issue (I don't
plan on having the server packages installed on a machine that isn't a
server, and once it's a server it works fine).

> I believe your machine might have been in some kind of undecided state when
> you tried to promote a client to a replica. What happens during replica
> installation on domain level 1 is that client installation is checked first.
> If client is installed the installation continues with other steps, if it's
> not, it tries to install the client.
> In your case, you probably had your client installed at first and tried to
> install replica. Something bad happened, can't be sure what, the
> installation failed and tried to uninstall the client but that might have
> failed, too. Eventually, you uninstalled the client yourself successfully,
> all files were removed and its records were also removed from the server.
> This made it possible to eventually successfully install a replica.
> I wouldn't bet my life on it but I'd think the installation could have gone
> successfully even if you installed a client and tried to promote it again :)

Quite possible - I thought I accounted for everything, but I'll admit
that when a client gets installed and provisioned it's not with
ipa-client-install but via puppet.  I did this because I needed a
programmatic way to determine if a host was already provisioned
(preferably locally) and execute the proper commands to do so, and in
my experimenting I found following the instructions for provisioning
manually worked well and use the presence of /etc/krb5.keytab as an
indicator of "has this host been provisioned" (its absence is a
negative).  It's likely that ipa-client-install does something else
that I never noticed, which ipa-replica-install relies on to know
what's going on - especially since when I run on a client, it first
uninstalls the client and then tries to reinstall it, and that's where
it fails.  I may experiment with that a bit too since it won't take
long to do.

> Anyway, I am sorry to hear you had such troubles, the replica installation
> is not usually such a painful process, I hope you will have more luck with
> FreeIPA in the future.

While it has been frustrating, it has definitely been a learning
experience.  I grow more confident in the system's abilities as I
discover more about it, and that means should something break in the
future I'm already in a position of knowledge of some of the internals
and less afraid to poke gently to fix it.  The support on this mailing
list has also been wonderful, so thank you all for that!

-- 
Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci
  Princeton University  |ICBM Address: 40.346344   -74.652242
345 Lewis Library   |"On my ship, the Rocinante, wheeling through
  Princeton, NJ   08544 | the galaxies; headed for the heart of Cygnus,
(267) 793-0852  | headlong into mystery."  -Rush, 'Cygnus X-1'

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Migration of FreeIPA issue tracker - Trac and git repo to pagure.io

[Petr Vobornik]

On 02/27/2017 12:46 PM, Petr Vobornik wrote:

Hello list,

today and tomorrow a migration of FreeIPA issue tracker[1] and git repo
will take place.

It is due to FedoraHosted sunset [2]. Both will be migrated to pagure.io
[3].

During this migration it won't be possible to add new tickets and
comments to Trac or Pagure.

[1] https://fedorahosted.org/freeipa/
[2] https://communityblog.fedoraproject.org/fedorahosted-sunset-2017-02-28/
[3] https://pagure.io/

Thank you for understanding,


Issue tracker and git repo were migrated. They can be used now.

https://pagure.io/freeipa

Additional steps will follow
- redirection of old URLs to new
- sync with github

--
Petr Vobornik

Associate Manager, Engineering, Identity Management
Red Hat, Inc.

--
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] CentOS 6 -> 7 migration

[Petr Vobornik]

On 02/26/2017 04:58 PM, Rob Verduijn wrote:

Sounds feasable, however I'm not sure which solution entails the most work.


+1

Just in case, I'll mention migration documentation: 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html#migrating-ipa-proc 



There are some manual steps regarding CA which should not be skipped.



In step 3 you loose all the extra functionalities( cups/squid/ntp ) as well,
while these stay preserved by a p2v including a nice backup.
You do need a backup of all the functions before proceeding with step3.

Rob Verduijn

2017-02-26 14:40 GMT+01:00 Ian Pilcher >:

On 02/26/2017 05:08 AM, Rob Verduijn wrote:

You should consider setting up a temporary vm to migrate from.
On one of your client systems, I assume you got at least 1 ipa client

Try looking at http://libguestfs.org/virt-p2v.1.html
 to migrate your
current system to a vm  (side effect : instant full backup)

When you got the vm up and running you can reinstall your main system
with the new os and ipa.
Then replicate the old ipa to the new one.


Hmm.  The system that runs IPA is the "network server" in my home
network.  It runs various services -- DNS, NTP, CUPS, squid, etc. -- as
well as routing between various VLANs.  So simply P2V'ing it would be
a major project in its own right.

What about this, though ...

1.  Set up a new CentOS 7 VM running IPA

2.  Replicate the IPA data from the old CentOS 6 system to the VM.

3.  Install CentOS 7 on the original system

4.  Replicate the IPA data back from the VM

Will this work?

--

Ian Pilcher arequip...@gmail.com 
 "I grew up before Mark Zuckerberg invented friendship" 


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







--
Petr Vobornik

Associate Manager, Engineering, Identity Management
Red Hat, Inc.

--
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 decode: {replica

[Petr Vobornik]

On 02/26/2017 11:35 AM, lejeczek wrote:

hi everyone

I first time see:

unable to decode: {replica 60} 586eaffd000a003c 586eaffd000a003c
Replica Update Vectors:


on all four servers. What would be a correct troubleshooting and fixing this
problem?
many thanks,
L.





Hello,

what is the version and OS of your IPA servers and DS?

 $ rpm -q ipa-server freeipa-server 389-ds-base

Similar issues happened last year, you can search the archives for 
"unable to decode" but a 389-ds fix improved the situation. So if you 
have older version then maybe update and then manual cleanup of RUVs 
might help.


--
Petr Vobornik

--
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-replica-conncheck wants listener on port 7389

[Standa Laznicka]

On 02/28/2017 09:59 AM, Tomas Krizek wrote:

On 02/27/2017 11:24 PM, Ian Pilcher wrote:

I'm part way through my CentOS 6 to 7 "upgrade".  I've reached the
point of trying to set up my new IPA server as a replica of a temporary
VM.

ipa-replica-conncheck is complaining, because nothing on the temporary
server is listening on port 7389.

The documentation here:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/prepping-replica.html


Says:

   In a purely Red Hat Enterprise Linux 7 environment, port 7389 is not
   required.

Which seems to indicate that nothing *should* be listening on that port
on a CentOS 7 IPA server.

So who's right?  And if something (pki-tomcatd?) should be listening on
that port, how do I make it do so?

Thanks!


On a CentOS 7 IPA server, port 7389 should not be required. You can
bypass the check with --skip-conncheck when running ipa-replica-install.



Please, rather check what the problem is. Port 7389 is not required for 
the newer system, but the old 6.x system has to be listening on it so 
that we can replicate agains the older Dogtag database. From the 
previous mail I believe you were following the right documentation, 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html#migrating-ipa-proc, 
correct?
-- 
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 install, unsupported format?

[Standa Laznicka]

On 02/27/2017 04:51 PM, Steve Huston wrote:

On Mon, Feb 27, 2017 at 5:56 AM, Standa Laznicka  wrote:

Sorry for the hold up. Two questions - is this domain level 1 or 0 (you can
run `ipa domainlevel-get` on the master if you don't know)? Did you have a
client installed prior to ipa-replica-install?

It's level 1.  I did have a couple clients installed, and the machine
I was trying to promote to a replica was one of them.  This whole
instance is a testing instance, with live data but not in production,
while I make sure everything works as expected before I deploy it, so
the servers and their data are new as of a couple weeks ago and began
life as a RHEL7.3 install.

It seems there might be two issues here; the one I originally reported
was that the ipa-server packages installed on a client machine are
unable to talk to the server, even though it obviously knows what the
server is (the "unsupported format" error I originally shared).  The
second is with setting up a replica in general.
The server rpm packages should have no impact on client settings if 
neither server nor replica are installed on the given machine. IIRC 
client only uses the NSS database in /etc/ipa/nssdb, you may want to 
check the permissions there (should be o+xr for the folder, o+r for the 
*.db files there).

I had tried the various methods outlined in the RedHat IdM
documentation, including promoting a client via an administrators TGT,
adding the client to the ipaservers group on the server, etc.  What
did finally work was unprovisioning the client, setting a one-time
password, and running "ipa-replica-install -v
--domain=astro.princeton.edu --server=ipa.astro.princeton.edu
--realm=ASTRO.PRINCETON.EDU --hostname=syrinx.astro.princeton.edu
--setup-ca -p foobar" - this yielded a fully working replica when it
finished.  All of the previous failures happened in the same way as
mentioned before - it seems to unprovision the client for some reason,
then fail in reprovisioning it.
I believe your machine might have been in some kind of undecided state 
when you tried to promote a client to a replica. What happens during 
replica installation on domain level 1 is that client installation is 
checked first. If client is installed the installation continues with 
other steps, if it's not, it tries to install the client.
In your case, you probably had your client installed at first and tried 
to install replica. Something bad happened, can't be sure what, the 
installation failed and tried to uninstall the client but that might 
have failed, too. Eventually, you uninstalled the client yourself 
successfully, all files were removed and its records were also removed 
from the server. This made it possible to eventually successfully 
install a replica.
I wouldn't bet my life on it but I'd think the installation could have 
gone successfully even if you installed a client and tried to promote it 
again :)


Anyway, I am sorry to hear you had such troubles, the replica 
installation is not usually such a painful process, I hope you will have 
more luck with FreeIPA in the future.

One problem which has cropped up before and caused problems is with
DNS capitalization.  DNS reports the domain name of "Princeton.EDU"
for hosts here, which means in order to do just about anything with a
FreeIPA server I have to manually add the host to /etc/hosts with all
lowercase letters.  I also have to force all of the host names via
command line switches so that DNS is not consulted for lookups, which
will return the StudlyCaps names and fail.  I suppose I should raise
that as a separate issue, because my understanding is that
hostnames/domainnames should be case insensitive so I'm not sure why
FreeIPA cares (and it may be easier to steer the entire project to not
care than convince those in control of DNS here to change it :D )



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

[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] ipa-replica-conncheck wants listener on port 7389

[Tomas Krizek]

On 02/27/2017 11:24 PM, Ian Pilcher wrote:
> I'm part way through my CentOS 6 to 7 "upgrade".  I've reached the
> point of trying to set up my new IPA server as a replica of a temporary
> VM.
>
> ipa-replica-conncheck is complaining, because nothing on the temporary
> server is listening on port 7389.
>
> The documentation here:
>
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/prepping-replica.html
>
>
> Says:
>
>   In a purely Red Hat Enterprise Linux 7 environment, port 7389 is not
>   required.
>
> Which seems to indicate that nothing *should* be listening on that port
> on a CentOS 7 IPA server.
>
> So who's right?  And if something (pki-tomcatd?) should be listening on
> that port, how do I make it do so?
>
> Thanks!
>
On a CentOS 7 IPA server, port 7389 should not be required. You can
bypass the check with --skip-conncheck when running ipa-replica-install.

-- 
Tomas Krizek




signature.asc
Description: OpenPGP digital signature
-- 
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] Needs help understand this timeout issue

[Troels Hansen]

Hi all


Just wanted to follow up on this as I created a case with RedHat, and here is 
their findings, for all of you to share:

>From RedHat support:

--

As per the current discussion with our engineering team.

---
The client requests info about a user. This goes to the IPA DS which calls into 
SSSD on the client which does a sequence of:
1) getgrouplist -> returns a list of GIDs the user is a member of
2) for gid in list_of_gids:
getgrgid(gid)

now, the problem is that the getgrgid on the server doesn't go directly to the 
domain the GID comes from -- in the general case this is not possible, because 
at least in the case of POSIX GIDs set by the admin we don't know which domain 
the GID is from. So what happens instead is that we search all the subdomains 
in the order they are discovered. Observe here:
(Mon Feb 27 09:27:29 2017) [sssd[nss]] [sss_dp_get_account_msg] (0x0400): 
Creating request for [lx.dr.dk][0x2][BE_REQ_GROUP][1][idnumber=235088:-]
 -- this is the NSS responder searching the IPA domain. This is very fast since 
the SSSD and the IPA server are on the same machine
(Mon Feb 27 09:27:29 2017) [sssd[nss]] [sss_dp_get_account_msg] (0x0400): 
Creating request for [place.dr.dk][0x2][BE_REQ_GROUP][1][idnumber=235088:-]
 -- but here we are searching the place.dr.dk domain
(Mon Feb 27 09:27:29 2017) [sssd[nss]] [sss_dp_get_account_msg] (0x0400): 
Creating request for [net.dr.dk][0x2][BE_REQ_GROUP][1][idnumber=235088:-]
 -- then the net.dr.dk domain

I'm not sure we can do much in 7.3, unfortunately. But 7.4 will help in the 
sense that when the NSS responder is checking the caches and considering which 
back end server to contact, it would first loop over all the caches  and try to 
first see if this ID already belongs to some domain as kind of a hint and first 
try to check this domain. In other words, instead of checking cache-server, 
cache-server it would check cache, cache, then server, server.

The other thing is, the back end could also, if the domain uses algorithmic ID 
mapping, decide sooner if the ID comes from its domain (as I said earlier, it's 
not possible in the general case if the admin assigns the POSIX IDs). There, we 
could reconstruct the SID from the GID and if the SID comes from a different 
domain, just abort the request.
---

We will be opening bug based on our observation and update you further.






So, this is an actual bug or maybe just not optimal design, but being made into 
an actual bug at RedHat.

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