Re: [Freeipa-users] Invalid UID in persistent keyring name while getting default cache. on OEL 7.1

[Christopher Lamb]

Now it works:

First I edited /etc/login.defs UID_MIN to 500

Then I ran "authconfig --update" to make the change(s) to login.defs
active.

After that, users with uids >=500 were able to login again.

In our case we have both system users (application) and "long term
employees, user account predates LDAP" with such low ids.

Chris



From:   Christopher Lamb/Switzerland/IBM@IBMCH
To: Sumit Bose 
Cc: freeipa-users@redhat.com
Date:   19.11.2015 11:20
Subject:Re: [Freeipa-users] Invalid UID in persistent keyring name
while getting default cache. on OEL 7.1
Sent by:freeipa-users-boun...@redhat.com



Hi Sumit

Thanks, I too have found /etc/login.defs

https://fedoraproject.org/wiki/Features/1000SystemAccounts

I have changed the UID_MIN to 500, and rebooted, but it seems to have no
effect.

Reading between the lines in the link above, it looks like this value may
have to be set pre-install.

Maybe I need to do something else to change the value?

Chris





Inactive hide details for Sumit Bose ---19.11.2015 10:38:49---On Thu, Nov
19, 2015 at 10:25:02AM +0100, Christopher Lamb wrote:Sumit Bose
---19.11.2015 10:38:49---On Thu, Nov 19, 2015 at 10:25:02AM +0100,
Christopher Lamb wrote: > HI

From: Sumit Bose 
To: Christopher Lamb/Switzerland/IBM@IBMCH
Cc: Jakub Hrozek , freeipa-users@redhat.com
Date: 19.11.2015 10:38
Subject: Re: [Freeipa-users] Invalid UID in persistent keyring name while
getting default cache. on OEL 7.1



On Thu, Nov 19, 2015 at 10:25:02AM +0100, Christopher Lamb wrote:
> HI
>
> The plot thickens. I think I actually have 2 issues:
>
> The first issue is that in the title of this thread, and was caused by
"the
> wrong kernel".
>
> The second issue, that some ipa users cannot log on (but mine can), is
> (probably) unrelated.
>
> The clue was my point below "no obvious horrible error".
>
> That led my to look in /var/log/secure, where I found the following:
>
> Nov 19 09:06:59 my-ipahost sshd[6075]: pam_unix(sshd:auth):
authentication
> failure; logname= uid=0 euid=0 tty=ssh ruser=
> rhost=xx.my-domain.xx.domain.com  user=bimbo
> Nov 19 09:06:59 my-ipahost sshd[6075]: pam_succeed_if(sshd:auth):
> requirement "uid >= 1000" not met by user "bimbo"
> Nov 19 09:07:01 my-ipahost sshd[6075]: Failed password for bimbo from
> 9.164.17.110 port 49332 ssh2
>
> Both my user, and an additional test user this morning have uids > 1000,
> and can successfully login -->OK
>
> The 2 other users I tested with yesterday (one application user, and one
> real user) have ids < 1000, and therefore (on this host) cannot logon.
>
> Now I need to google further to find where this rule is configured /
> hidden.

The '1000' is written by authconfig into the pam configuration. Afaik
authconfig uses the UID_MIN form /etc/login.defs here.

HTH

bye,
Sumit

>
> Cheers
>
> Chris
>
>
>
>
>
> From: Christopher Lamb/Switzerland/IBM@IBMCH
> To: Jakub Hrozek 
> Cc: freeipa-users@redhat.com
> Date: 19.11.2015 10:05
> Subject: Re: [Freeipa-users] Invalid UID in persistent keyring name
> while getting default cache. on OEL 7.1
> Sent by: freeipa-users-boun...@redhat.com
>
>
>
> Hi Jakub
>
> I have restarted sssd with debug_level=6
>
> Then I made one (failed) attempt to login via ssh with the user "bimbo".
>
> Logs, anonymised are attached.
>
> To my untrained eyes, nothing shouts "horrible error" to me.
>
> Chris
>
> (See attached file: sssd_logs.zip)
>
>
> Inactive hide details for Jakub Hrozek ---18.11.2015 19:30:29---On Wed,
Nov
> 18, 2015 at 04:34:39PM +0100, Christopher Lamb wrotJakub Hrozek
> ---18.11.2015 19:30:29---On Wed, Nov 18, 2015 at 04:34:39PM +0100,
> Christopher Lamb wrote: >
>
> From: Jakub Hrozek 
> To: freeipa-users@redhat.com
> Date: 18.11.2015 19:30
> Subject: Re: [Freeipa-users] Invalid UID in persistent keyring name while
> getting default cache. on OEL 7.1
> Sent by: freeipa-users-boun...@redhat.com
>
>
>
> On Wed, Nov 18, 2015 at 04:34:39PM +0100, Christopher Lamb wrote:
> >
> > I have a newly installed OEL 7.1 server (7.0 DVD, then yum updated to
> 7.1)
> > The ipa-client is installed, making this server an ipa host.
> >
> >
> >
> > > getent passwd 
> >
> > is successful for ipa users.  -->OK
> >
> > However I cannot log on to the host with ipa users (direct or ssh). -->
> NOT
> >
> > OK
> >
> >
> >
> > When logged on as root (local user), I can “su -“ to my ipa user. -->OK
> >
> >
> >
> > "> systemctl status sssd" and "> kinit"
> >
> > both show:
> >
> > “Invalid UID in persistent keyring name while getting default cache.”
> >
> >
> >
> > Having googled with this error, I saw some indications that it could be
> >
> > related to the kernel.
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1017683
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1029110
> >
> >
> >
> > For a fresh OEL install, the default kernel is the uek version. "Aha" I
> >
> > 

Re: [Freeipa-users] FreeIPA user can't login to linux.

[zhiyong xue]

Rob, where can I get more error information beside the log?
[16/Nov/2015:02:52:59 +] managed-entries-plugin - mep_del_post_op:
failed to delete managed entry
(member=syncopex5,cn=groups,cn=accounts,dc=example,dc=com) - error (32)

2015-11-16 13:43 GMT+08:00 zhiyong xue :

> I am using IPA 4.1 in CenOS7.  And I can login to system after "id
> syncopex5", maybe it's cache problem.
>
> 2015-11-16 11:24 GMT+08:00 Rob Crittenden :
>
>> zhiyong xue wrote:
>> > We integrated the Apache Syncope server with FreeIPA server. So user can
>> > self register ID from Apache Syncope then synchronize to FreeIPA. The
>> > problems are:
>> > *1) User created from Apache Syncope can't login to linux. The user
>> > created from FreeIPA web gui works well.*
>>
>> For login issues see https://fedorahosted.org/sssd/wiki/Troubleshooting
>> This is unlikely to fix things but it will help with later debugging.
>>
>> This likely revolves around how you are creating these accounts. We'll
>> need information on what you're doing. The more details the better.
>>
>> > *2) The user also can't be deleted from web UI and CLI. It said
>> > "syncopex5: user not found".*
>>
>> Again, you probably aren't creating the users correctly.
>>
>> I can only assume that you are creating the users directly via an LDAP
>> add. This is working around the IPA framework which does additional work.
>>
>> Knowing what version of IPA this is would help too.
>>
>> You'll probably also want to read this:
>> http://www.freeipa.org/page/V4/User_Life-Cycle_Management . This is in
>> IPA 4.2.
>>
>> rob
>> rob
>>
>
>
-- 
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] Invalid UID in persistent keyring name while getting default cache. on OEL 7.1

[Christopher Lamb]

HI

The plot thickens. I think I actually have 2 issues:

The first issue is that in the title of this thread, and was caused by "the
wrong kernel".

The second issue, that some ipa users cannot log on (but mine can), is
(probably) unrelated.

The clue was my point below "no obvious horrible error".

That led my to look in /var/log/secure, where I found the following:

Nov 19 09:06:59 my-ipahost sshd[6075]: pam_unix(sshd:auth): authentication
failure; logname= uid=0 euid=0 tty=ssh ruser=
rhost=xx.my-domain.xx.domain.com  user=bimbo
Nov 19 09:06:59 my-ipahost sshd[6075]: pam_succeed_if(sshd:auth):
requirement "uid >= 1000" not met by user "bimbo"
Nov 19 09:07:01 my-ipahost sshd[6075]: Failed password for bimbo from
9.164.17.110 port 49332 ssh2

Both my user, and an additional test user this morning have uids > 1000,
and can successfully login -->OK

The 2 other users I tested with yesterday (one application user, and one
real user) have ids < 1000, and therefore (on this host) cannot logon.

Now I need to google further to find where this rule is configured /
hidden.

Cheers

Chris





From:   Christopher Lamb/Switzerland/IBM@IBMCH
To: Jakub Hrozek 
Cc: freeipa-users@redhat.com
Date:   19.11.2015 10:05
Subject:Re: [Freeipa-users] Invalid UID in persistent keyring name
while getting default cache. on OEL 7.1
Sent by:freeipa-users-boun...@redhat.com



Hi Jakub

I have restarted sssd with debug_level=6

Then I made one (failed) attempt to login via ssh with the user "bimbo".

Logs, anonymised are attached.

To my untrained eyes, nothing shouts "horrible error" to me.

Chris

(See attached file: sssd_logs.zip)


Inactive hide details for Jakub Hrozek ---18.11.2015 19:30:29---On Wed, Nov
18, 2015 at 04:34:39PM +0100, Christopher Lamb wrotJakub Hrozek
---18.11.2015 19:30:29---On Wed, Nov 18, 2015 at 04:34:39PM +0100,
Christopher Lamb wrote: >

From: Jakub Hrozek 
To: freeipa-users@redhat.com
Date: 18.11.2015 19:30
Subject: Re: [Freeipa-users] Invalid UID in persistent keyring name while
getting default cache. on OEL 7.1
Sent by: freeipa-users-boun...@redhat.com



On Wed, Nov 18, 2015 at 04:34:39PM +0100, Christopher Lamb wrote:
>
> I have a newly installed OEL 7.1 server (7.0 DVD, then yum updated to
7.1)
> The ipa-client is installed, making this server an ipa host.
>
>
>
> > getent passwd 
>
> is successful for ipa users.  -->OK
>
> However I cannot log on to the host with ipa users (direct or ssh). -->
NOT
>
> OK
>
>
>
> When logged on as root (local user), I can “su -“ to my ipa user. -->OK
>
>
>
> "> systemctl status sssd" and "> kinit"
>
> both show:
>
> “Invalid UID in persistent keyring name while getting default cache.”
>
>
>
> Having googled with this error, I saw some indications that it could be
>
> related to the kernel.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1017683
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1029110
>
>
>
> For a fresh OEL install, the default kernel is the uek version. "Aha" I
>
> thought, let’s change back to the standard RHEL kernel.
>
> After a reboot with the RHEL kernel, I was still not able to log in with
my
>
> ipa user.
>
>
>
> I then logged on as root, and changed to my ipa user via su.
>
> > klist -l
>
> produced:
>
> KEYRING:persistent:93397:krb_cache_76B9lf2 (Expired)

I'm surprised you had any ccache at all, because login as root bypasses
PAM.

But in general, if you login with sssd and the cache is expired a long
time ago (1970), that means sssd logged you in offline and the ccache is
a placeholder for when sssd switches to online mode.

>
>
>
> I therefore deleted the key:
>
> > kdestroy -A
>
> Then I stopped the sssd service, and cleared the cache
in /var/lib/sss/db/,
>
> then restarted sssd
>
>
>
> After that I was now able to log on with my ipa user (both direct and via
>
> ssh).
>
>
>
> However I cannot get any other ipa users to logon to this host!  --> NOT
OK
>
> The same users can successfully logon to other ipa hosts in the same
>
> domain.
>
>
>
> My ipa user was the one used to enroll the host.
>
>
>
> Any ideas?

Not without logs, 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

[attachment "sssd_logs.zip" deleted by Christopher Lamb/Switzerland/IBM] --

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] Invalid UID in persistent keyring name while getting default cache. on OEL 7.1

[Sumit Bose]

On Thu, Nov 19, 2015 at 10:25:02AM +0100, Christopher Lamb wrote:
> HI
> 
> The plot thickens. I think I actually have 2 issues:
> 
> The first issue is that in the title of this thread, and was caused by "the
> wrong kernel".
> 
> The second issue, that some ipa users cannot log on (but mine can), is
> (probably) unrelated.
> 
> The clue was my point below "no obvious horrible error".
> 
> That led my to look in /var/log/secure, where I found the following:
> 
> Nov 19 09:06:59 my-ipahost sshd[6075]: pam_unix(sshd:auth): authentication
> failure; logname= uid=0 euid=0 tty=ssh ruser=
> rhost=xx.my-domain.xx.domain.com  user=bimbo
> Nov 19 09:06:59 my-ipahost sshd[6075]: pam_succeed_if(sshd:auth):
> requirement "uid >= 1000" not met by user "bimbo"
> Nov 19 09:07:01 my-ipahost sshd[6075]: Failed password for bimbo from
> 9.164.17.110 port 49332 ssh2
> 
> Both my user, and an additional test user this morning have uids > 1000,
> and can successfully login -->OK
> 
> The 2 other users I tested with yesterday (one application user, and one
> real user) have ids < 1000, and therefore (on this host) cannot logon.
> 
> Now I need to google further to find where this rule is configured /
> hidden.

The '1000' is written by authconfig into the pam configuration. Afaik
authconfig uses the UID_MIN form /etc/login.defs here.

HTH

bye,
Sumit

> 
> Cheers
> 
> Chris
> 
> 
> 
> 
> 
> From: Christopher Lamb/Switzerland/IBM@IBMCH
> To:   Jakub Hrozek 
> Cc:   freeipa-users@redhat.com
> Date: 19.11.2015 10:05
> Subject:  Re: [Freeipa-users] Invalid UID in persistent keyring name
> while getting default cache. on OEL 7.1
> Sent by:  freeipa-users-boun...@redhat.com
> 
> 
> 
> Hi Jakub
> 
> I have restarted sssd with debug_level=6
> 
> Then I made one (failed) attempt to login via ssh with the user "bimbo".
> 
> Logs, anonymised are attached.
> 
> To my untrained eyes, nothing shouts "horrible error" to me.
> 
> Chris
> 
> (See attached file: sssd_logs.zip)
> 
> 
> Inactive hide details for Jakub Hrozek ---18.11.2015 19:30:29---On Wed, Nov
> 18, 2015 at 04:34:39PM +0100, Christopher Lamb wrotJakub Hrozek
> ---18.11.2015 19:30:29---On Wed, Nov 18, 2015 at 04:34:39PM +0100,
> Christopher Lamb wrote: >
> 
> From: Jakub Hrozek 
> To: freeipa-users@redhat.com
> Date: 18.11.2015 19:30
> Subject: Re: [Freeipa-users] Invalid UID in persistent keyring name while
> getting default cache. on OEL 7.1
> Sent by: freeipa-users-boun...@redhat.com
> 
> 
> 
> On Wed, Nov 18, 2015 at 04:34:39PM +0100, Christopher Lamb wrote:
> >
> > I have a newly installed OEL 7.1 server (7.0 DVD, then yum updated to
> 7.1)
> > The ipa-client is installed, making this server an ipa host.
> >
> >
> >
> > > getent passwd 
> >
> > is successful for ipa users.  -->OK
> >
> > However I cannot log on to the host with ipa users (direct or ssh). -->
> NOT
> >
> > OK
> >
> >
> >
> > When logged on as root (local user), I can “su -“ to my ipa user. -->OK
> >
> >
> >
> > "> systemctl status sssd" and "> kinit"
> >
> > both show:
> >
> > “Invalid UID in persistent keyring name while getting default cache.”
> >
> >
> >
> > Having googled with this error, I saw some indications that it could be
> >
> > related to the kernel.
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1017683
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1029110
> >
> >
> >
> > For a fresh OEL install, the default kernel is the uek version. "Aha" I
> >
> > thought, let’s change back to the standard RHEL kernel.
> >
> > After a reboot with the RHEL kernel, I was still not able to log in with
> my
> >
> > ipa user.
> >
> >
> >
> > I then logged on as root, and changed to my ipa user via su.
> >
> > > klist -l
> >
> > produced:
> >
> > KEYRING:persistent:93397:krb_cache_76B9lf2 (Expired)
> 
> I'm surprised you had any ccache at all, because login as root bypasses
> PAM.
> 
> But in general, if you login with sssd and the cache is expired a long
> time ago (1970), that means sssd logged you in offline and the ccache is
> a placeholder for when sssd switches to online mode.
> 
> >
> >
> >
> > I therefore deleted the key:
> >
> > > kdestroy -A
> >
> > Then I stopped the sssd service, and cleared the cache
> in /var/lib/sss/db/,
> >
> > then restarted sssd
> >
> >
> >
> > After that I was now able to log on with my ipa user (both direct and via
> >
> > ssh).
> >
> >
> >
> > However I cannot get any other ipa users to logon to this host!  --> NOT
> OK
> >
> > The same users can successfully logon to other ipa hosts in the same
> >
> > domain.
> >
> >
> >
> > My ipa user was the one used to enroll the host.
> >
> >
> >
> > Any ideas?
> 
> Not without logs, 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
> 
> [attachment "sssd_logs.zip" 

Re: [Freeipa-users] 4.2 Packages for RHEL/CentOS 7.1

[Christopher Young]

I recall that original message about the packaging before RHEL 7.2 and
how few of us expressed interest.  I believe I did respond to the
positive that I could use these packages, but I certainly understand
additional effort.  I just hate to be waiting on RH's cycle to get
updates to one of the pieces of my infrastructure where features are
in-demand and getting added more often.  I prefer my base server OS's
to stay as stable as possible, but FreeIPA is an exception for me.  In
any case, I appreciate the effort and the response.

Just so that I'm clear, this basically means that we should wait until
the RHEL 7.2 release (and the following CentOS 7.2 release) before
this will generally available?  I want to make sure I pay attention to
that as it gets released.

Thanks,

Chris

On Thu, Nov 12, 2015 at 3:45 AM, Alexander Bokovoy  wrote:
> On Wed, 11 Nov 2015, Christopher Young wrote:
>>
>> Do we know what the status of getting these packages prepped and into the
>> mainstream repos (like EPEL, I suppose)?
>>
>> I'm just curious as I try and keep my repos minimal on servers (for
>> obvious
>> reasons), but I would really like to begin testing/using the functionality
>> in 4.2.
>
> I believe EPEL's policy prevents you from packaging software which
> exists in RHEL proper. FreeIPA 4.2 is coming with RHEL 7.2, it is
> already published as part of RHEL 7.2 beta in September.
>
> I want to remind  that during this summer I ran few queries here
> (freeipa-users@) and elsewhere to solicit opinions whether people want
> to have FreeIPA 4.2 packages available for CentOS before RHEL 7.2
> release. Very few responses came back and there wasn't any convincing
> feedback that would have justified additional effort to make the
> repository and maintenance reasonable.
>
> https://www.redhat.com/archives/freeipa-users/2015-July/msg00243.html
>
> --
> / Alexander Bokovoy

-- 
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] Upgrading from 3.0.0 CentOS6 to 4.2.3 CentOS7

[Natxo Asenjo]

On Thu, Nov 19, 2015 at 11:03 PM, Ash Alam  wrote:

> Hello All
>
> I am looking for some advice on upgrading. Currently our FreeIPA servers
> are 3.0.0 on centos 6.6. We are looking to go to 4.2.3 Centos7. This
> upgrade path is not possible per IPA documentation. Minimum version
> required is 3.3.x. I have also found that cenos6 does not provide anything
> past 3.0.0.
>
>
do you mean upgrading the systems themselves? Why don't you install a
centos 7 host and join it as domain controller to the existing realm?

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

I have tested the procedure a couple of times and it works really well. I
just came up with one issue which you can read here:

https://www.redhat.com/archives/freeipa-users/2015-September/thread.html#00161

-- 
groet,
natxo
-- 
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] Upgrading from 3.0.0 CentOS6 to 4.2.3 CentOS7

[Ash Alam]

Hello All

I am looking for some advice on upgrading. Currently our FreeIPA servers
are 3.0.0 on centos 6.6. We are looking to go to 4.2.3 Centos7. This
upgrade path is not possible per IPA documentation. Minimum version
required is 3.3.x. I have also found that cenos6 does not provide anything
past 3.0.0.

One idea is to upgrade to 3.3.x first and then upgrade to 4.2.3 on centos7.
This is harder since centos does not provide this. The other issue is if
3.0/3.3 client will be supported with 4.2.3 server.

Thank You
-- 
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] Python IndexError: list index out of range with ipa-server-install --external-cert-file

[Gilbert Wilson]

> On Nov 4, 2015, at 5:49 AM, Rob Crittenden  wrote:
> 
> Gilbert Wilson wrote:
>> Apologies ahead of time as this is my first post to the list and interaction 
>> with the FreeIPA project. If I should be taking this question to a different 
>> forum please point me in the right direction!
>> 
>> The error condition I知 encountering is mentioned a few times on the list, 
>> but the threads die off without any conclusions. The most recent mention of 
>> it that I could find is here:
>> 
>> https://www.redhat.com/archives/freeipa-users/2015-March/msg00271.html
>> 
>> It also looks like this has shown up as a bug that was fixed here:
>> 
>> https://fedorahosted.org/freeipa/ticket/4397
>> 
>> I知 using CentOS Linux release 7.1.1503 (Core) system running FreeIPA 
>> VERSION: 4.1.0, API_VERSION: 2.112.
>> 
>> The error happens when attempting to finish an ipa-server-install using a 
>> cert signed by an external CA:
>> 
>>  ipa-server-install -d --external-cert-file=/path/to/certificate.pem 
>> --external-cert-file=/path/to/certificate_authority.pem
>> 
>> The install proceeds as normal, but then when trying to create the RA 
>> certificate it errors out with:
>> 
>> ipa : DEBUGThe ipa-server-install command failed, exception: 
>> IndexError: list index out of range
>> Unexpected error - see /var/log/ipaserver-install.log for details:
>> IndexError: list index out of range
>> [root@ipa ‾]# ipa : DEBUGstderr=
>> all/cainstance.py", line 520, in configure_instance
>>self.start_creation(runtime=210)
>> 
>>  File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 
>> 382, in start_creation
>>run_step(full_msg, method)
>> 
>>  File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 
>> 372, in run_step
>>method()
>> 
>>  File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", 
>> line 1149, in __request_ra_certificate
>>self.requestId = item_node[0].childNodes[0].data
>> 
>> ipa : DEBUGThe ipa-server-install command failed, exception: 
>> IndexError: list index out of range
>> Unexpected error - see /var/log/ipaserver-install.log for details:
>> IndexError: list index out of range
>> 
>> Unlike the bug and thread I linked to above we are not using a Windows CA. 
>> Our CA is based on openssl. Since I知 fairly new to FreeIPA I知 not sure what 
>> logs would be most helpful to troubleshoot, but my bumbling about seemed to 
>> indicate that the the error condition is in the server痴 xml-based web api 
>> request/response logic. I知 not sure if the error is localized to that part 
>> of the system or if there痴 some precondition that failed beforehand. The 
>> installation is left in a pretty broken/useless state. If I try to run 
>> `ipa-server-install -d --external-cert-file=/path/to/certificate.pem 
>> --external-cert-file=/path/to/certificate_authority.pem` again it instructs 
>> me that I have to run `ipa-server-install --external-ca` (essentially, start 
>> over from scratch). An aside question: is there some way to rerun the setup 
>> from where it broke down so that I don稚 have to bother our CA admin to sign 
>> my CSR each time? That said, I can reliably produce this error condition and 
>> am willing!
>  to put in
> some time to do data collection to track it down, and our CA admin is willing 
> to humor me for a little while! But, where do I start? What information would 
> be most useful to collect?
> 
> You're seeing a symptom, not the problem. You'd need to look at the
> install log referenced above plus the debug log somewhere in
> /var/log/pki/pki-ca/
> 
> And unfortunately right now you need to start over after a failed install.


Rob,

Thanks for the reply. It turns out that there were a couple things wrong, but 
the biggest one was that the certificate I was getting back from our CA had CA 
set to false! So yeeeaaahh… *facepalm* once I went on a detour of setting up my 
own offline root CA with openssl (a nice learning experience) the installation 
worked as expected.

The only thing I can think of on the FreeIPA side that would be helpful is an 
additional pre-test that read the external certificate and immediately errors 
out if it finds that basic constraints have been set to CA:false.

Gil


Gilbert Wilson
Systems Administrator
The Omni Group
+1 206-523-4152
+1 206-523-5896 (Fax)



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
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 Internal Server Error

[holo]

I checked again my web UI and it starts working - i really did not
change anything. Right now i'm getting list of records immediately
without "Waiting" inscription and no errors in log file. What could be
a reason of such behave, how to fix it if it appear again? I think
problem was that long execute time like Rob wrote, but what might have
caused it?
On Thu, 2015-11-19 at 07:52 +0100, Unknown wrote:
> On Wed, 2015-11-18 at 13:49 -0500, Rob Crittenden wrote:
> > Unknown wrote:
> > > I'm new here so first of all want to say hello to everyone.
> > > 
> > > I'm implementing FreeIPA in our environment. Everything was fine
> > > till i
> > > figure out listing of one domain stops working. When im trying to
> > > list
> > > zone via web panel i'm getting "Internal Server Error". It is
> > > happening
> > > only for default one zone/domain which is used by kerberos too.
> > > Here are
> > > http error logs:
> > > 
> > > [Wed Nov 18 06:13:45.226059 2015] [:error] [pid 11045] (70007)The
> > > timeout specified has expired: [client 172.16.0.117:48072]
> > > mod_wsgi
> > > (pid=11045): Unable to get bucket brigade for request., referer:
> > > https://freeipa01.domain.local/ipa/ui/
> > > [Wed Nov 18 06:13:45.226607 2015] [:error] [pid 3929] ipa: ERROR:
> > > non-public: IOError: request data read error
> > > [Wed Nov 18 06:13:45.226645 2015] [:error] [pid 3929] Traceback
> > > (most
> > > recent call last):
> > > [Wed Nov 18 06:13:45.226672 2015] [:error] [pid 3929]   File
> > > "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line
> > > 339, in
> > > wsgi_execute
> > > [Wed Nov 18 06:13:45.226680 2015] [:error] [pid 3929] data =
> > > read_input(environ)
> > > [Wed Nov 18 06:13:45.226685 2015] [:error] [pid 3929]   File
> > > "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line
> > > 187, in
> > > read_input
> > > [Wed Nov 18 06:13:45.226693 2015] [:error] [pid 3929] return
> > > environ['wsgi.input'].read(length)
> > > [Wed Nov 18 06:13:45.226698 2015] [:error] [pid 3929] IOError:
> > > request
> > > data read error
> > > [Wed Nov 18 06:13:45.226964 2015] [:error] [pid 3929] ipa: INFO:
> > > [jsonserver_session] admin@DOMAIN.LOCAL 
> > > L>:
> > > None: IOError
> > > [Wed Nov 18 06:13:45.227879 2015] [:error] [pid 3929] [remote
> > > 172.16.0.117:164] mod_wsgi (pid=3929): Exception occurred
> > > processing
> > > WSGI script '/usr/share/ipa/wsgi.py'.
> > > [Wed Nov 18 06:13:45.227932 2015] [:error] [pid 3929] [remote
> > > 172.16.0.117:164] IOError: failed to write data
> > 
> > More context would be helpful. I'm assuming that this took a VERY
> > long
> > time to execute? It looks like the wsgi request timed out.
> > 
> > Can you duplicate this on the CLI using the ipa tool?
> > 
> CLI is working without any problems i can list, add, delete records,
> problem only appear in web interface when i want to list my default
>  zone (others are working for now).
> 
> According to that long time execute. Internal server error appears
> for around 10 sec. I'm not familiar with wsgi but i tried to add
> " inactivity-timeout=60" option to "WSGIDaemonProcess" in ipa.conf
> like bellow:
> 
> WSGIDaemonProcess ipa processes=2 threads=1 maximum-requests=500
> inactivity-timeout=60
> 
> but it did not help.
> 
> 
> > > I realize that it stops working after i try to add Ubuntu
> > > instance but
> > > Ubuntu client is not work properly. What is strange when im using
> > > command client i don't have problem to list it.
> > 
> > I'm not sure I follow. Was it a coincidence after registering an
> > Ubuntu
> > client or do you think it's the cause?
> I noticed it after i tried to add ubuntu instance to my freeipa maybe
> this is not connected with it.
> 
> > rob
> > -- 
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] Invalid UID in persistent keyring name while getting default cache. on OEL 7.1

[Sumit Bose]

On Thu, Nov 19, 2015 at 11:28:10AM +0100, Christopher Lamb wrote:
> Now it works:
> 
> First I edited /etc/login.defs UID_MIN to 500
> 
> Then I ran "authconfig --update" to make the change(s) to login.defs
> active.

yes, it is expected that you have to run authconfig after changing the
value in login.defs to update the pam configuration.

bye,
Sumit

> 
> After that, users with uids >=500 were able to login again.
> 
> In our case we have both system users (application) and "long term
> employees, user account predates LDAP" with such low ids.
> 
> Chris
> 
> 
> 
> From: Christopher Lamb/Switzerland/IBM@IBMCH
> To:   Sumit Bose 
> Cc:   freeipa-users@redhat.com
> Date: 19.11.2015 11:20
> Subject:  Re: [Freeipa-users] Invalid UID in persistent keyring name
> while getting default cache. on OEL 7.1
> Sent by:  freeipa-users-boun...@redhat.com
> 
> 
> 
> Hi Sumit
> 
> Thanks, I too have found /etc/login.defs
> 
> https://fedoraproject.org/wiki/Features/1000SystemAccounts
> 
> I have changed the UID_MIN to 500, and rebooted, but it seems to have no
> effect.
> 
> Reading between the lines in the link above, it looks like this value may
> have to be set pre-install.
> 
> Maybe I need to do something else to change the value?
> 
> Chris
> 
> 
> 
> 
> 
> Inactive hide details for Sumit Bose ---19.11.2015 10:38:49---On Thu, Nov
> 19, 2015 at 10:25:02AM +0100, Christopher Lamb wrote:Sumit Bose
> ---19.11.2015 10:38:49---On Thu, Nov 19, 2015 at 10:25:02AM +0100,
> Christopher Lamb wrote: > HI
> 
> From: Sumit Bose 
> To: Christopher Lamb/Switzerland/IBM@IBMCH
> Cc: Jakub Hrozek , freeipa-users@redhat.com
> Date: 19.11.2015 10:38
> Subject: Re: [Freeipa-users] Invalid UID in persistent keyring name while
> getting default cache. on OEL 7.1
> 
> 
> 
> On Thu, Nov 19, 2015 at 10:25:02AM +0100, Christopher Lamb wrote:
> > HI
> >
> > The plot thickens. I think I actually have 2 issues:
> >
> > The first issue is that in the title of this thread, and was caused by
> "the
> > wrong kernel".
> >
> > The second issue, that some ipa users cannot log on (but mine can), is
> > (probably) unrelated.
> >
> > The clue was my point below "no obvious horrible error".
> >
> > That led my to look in /var/log/secure, where I found the following:
> >
> > Nov 19 09:06:59 my-ipahost sshd[6075]: pam_unix(sshd:auth):
> authentication
> > failure; logname= uid=0 euid=0 tty=ssh ruser=
> > rhost=xx.my-domain.xx.domain.com  user=bimbo
> > Nov 19 09:06:59 my-ipahost sshd[6075]: pam_succeed_if(sshd:auth):
> > requirement "uid >= 1000" not met by user "bimbo"
> > Nov 19 09:07:01 my-ipahost sshd[6075]: Failed password for bimbo from
> > 9.164.17.110 port 49332 ssh2
> >
> > Both my user, and an additional test user this morning have uids > 1000,
> > and can successfully login -->OK
> >
> > The 2 other users I tested with yesterday (one application user, and one
> > real user) have ids < 1000, and therefore (on this host) cannot logon.
> >
> > Now I need to google further to find where this rule is configured /
> > hidden.
> 
> The '1000' is written by authconfig into the pam configuration. Afaik
> authconfig uses the UID_MIN form /etc/login.defs here.
> 
> HTH
> 
> bye,
> Sumit
> 
> >
> > Cheers
> >
> > Chris
> >
> >
> >
> >
> >
> > From: Christopher Lamb/Switzerland/IBM@IBMCH
> > To: Jakub Hrozek 
> > Cc: freeipa-users@redhat.com
> > Date: 19.11.2015 10:05
> > Subject: Re: [Freeipa-users] Invalid UID in persistent keyring name
> > while getting default cache. on OEL 7.1
> > Sent by: freeipa-users-boun...@redhat.com
> >
> >
> >
> > Hi Jakub
> >
> > I have restarted sssd with debug_level=6
> >
> > Then I made one (failed) attempt to login via ssh with the user "bimbo".
> >
> > Logs, anonymised are attached.
> >
> > To my untrained eyes, nothing shouts "horrible error" to me.
> >
> > Chris
> >
> > (See attached file: sssd_logs.zip)
> >
> >
> > Inactive hide details for Jakub Hrozek ---18.11.2015 19:30:29---On Wed,
> Nov
> > 18, 2015 at 04:34:39PM +0100, Christopher Lamb wrotJakub Hrozek
> > ---18.11.2015 19:30:29---On Wed, Nov 18, 2015 at 04:34:39PM +0100,
> > Christopher Lamb wrote: >
> >
> > From: Jakub Hrozek 
> > To: freeipa-users@redhat.com
> > Date: 18.11.2015 19:30
> > Subject: Re: [Freeipa-users] Invalid UID in persistent keyring name while
> > getting default cache. on OEL 7.1
> > Sent by: freeipa-users-boun...@redhat.com
> >
> >
> >
> > On Wed, Nov 18, 2015 at 04:34:39PM +0100, Christopher Lamb wrote:
> > >
> > > I have a newly installed OEL 7.1 server (7.0 DVD, then yum updated to
> > 7.1)
> > > The ipa-client is installed, making this server an ipa host.
> > >
> > >
> > >
> > > > getent passwd 
> > >
> > > is successful for ipa users.  -->OK
> > >
> > > However I cannot log on to the host with ipa users (direct or ssh). -->
> > NOT
> > >
> > > OK
> > >
> > >
> > >
> > > When logged on as root (local 

Re: [Freeipa-users] Invalid UID in persistent keyring name while getting default cache. on OEL 7.1

[Christopher Lamb]

Hi Sumit

Thanks, I too have found /etc/login.defs

https://fedoraproject.org/wiki/Features/1000SystemAccounts

I have changed the UID_MIN to 500, and rebooted, but it seems to have no
effect.

Reading between the lines in the link above, it looks like this value may
have to be set pre-install.

Maybe I need to do something else to change the value?

Chris







From:   Sumit Bose 
To: Christopher Lamb/Switzerland/IBM@IBMCH
Cc: Jakub Hrozek , freeipa-users@redhat.com
Date:   19.11.2015 10:38
Subject:Re: [Freeipa-users] Invalid UID in persistent keyring name
while getting default cache. on OEL 7.1



On Thu, Nov 19, 2015 at 10:25:02AM +0100, Christopher Lamb wrote:
> HI
>
> The plot thickens. I think I actually have 2 issues:
>
> The first issue is that in the title of this thread, and was caused by
"the
> wrong kernel".
>
> The second issue, that some ipa users cannot log on (but mine can), is
> (probably) unrelated.
>
> The clue was my point below "no obvious horrible error".
>
> That led my to look in /var/log/secure, where I found the following:
>
> Nov 19 09:06:59 my-ipahost sshd[6075]: pam_unix(sshd:auth):
authentication
> failure; logname= uid=0 euid=0 tty=ssh ruser=
> rhost=xx.my-domain.xx.domain.com  user=bimbo
> Nov 19 09:06:59 my-ipahost sshd[6075]: pam_succeed_if(sshd:auth):
> requirement "uid >= 1000" not met by user "bimbo"
> Nov 19 09:07:01 my-ipahost sshd[6075]: Failed password for bimbo from
> 9.164.17.110 port 49332 ssh2
>
> Both my user, and an additional test user this morning have uids > 1000,
> and can successfully login -->OK
>
> The 2 other users I tested with yesterday (one application user, and one
> real user) have ids < 1000, and therefore (on this host) cannot logon.
>
> Now I need to google further to find where this rule is configured /
> hidden.

The '1000' is written by authconfig into the pam configuration. Afaik
authconfig uses the UID_MIN form /etc/login.defs here.

HTH

bye,
Sumit

>
> Cheers
>
> Chris
>
>
>
>
>
> From:  Christopher Lamb/Switzerland/IBM@IBMCH
> To:Jakub Hrozek 
> Cc:freeipa-users@redhat.com
> Date:  19.11.2015 10:05
> Subject:   Re: [Freeipa-users] Invalid UID in persistent keyring
name
> while getting default cache. on OEL 7.1
> Sent by:   freeipa-users-boun...@redhat.com
>
>
>
> Hi Jakub
>
> I have restarted sssd with debug_level=6
>
> Then I made one (failed) attempt to login via ssh with the user "bimbo".
>
> Logs, anonymised are attached.
>
> To my untrained eyes, nothing shouts "horrible error" to me.
>
> Chris
>
> (See attached file: sssd_logs.zip)
>
>
> Inactive hide details for Jakub Hrozek ---18.11.2015 19:30:29---On Wed,
Nov
> 18, 2015 at 04:34:39PM +0100, Christopher Lamb wrotJakub Hrozek
> ---18.11.2015 19:30:29---On Wed, Nov 18, 2015 at 04:34:39PM +0100,
> Christopher Lamb wrote: >
>
> From: Jakub Hrozek 
> To: freeipa-users@redhat.com
> Date: 18.11.2015 19:30
> Subject: Re: [Freeipa-users] Invalid UID in persistent keyring name while
> getting default cache. on OEL 7.1
> Sent by: freeipa-users-boun...@redhat.com
>
>
>
> On Wed, Nov 18, 2015 at 04:34:39PM +0100, Christopher Lamb wrote:
> >
> > I have a newly installed OEL 7.1 server (7.0 DVD, then yum updated to
> 7.1)
> > The ipa-client is installed, making this server an ipa host.
> >
> >
> >
> > > getent passwd 
> >
> > is successful for ipa users.  -->OK
> >
> > However I cannot log on to the host with ipa users (direct or ssh). -->
> NOT
> >
> > OK
> >
> >
> >
> > When logged on as root (local user), I can “su -“ to my ipa user. -->OK
> >
> >
> >
> > "> systemctl status sssd" and "> kinit"
> >
> > both show:
> >
> > “Invalid UID in persistent keyring name while getting default cache.”
> >
> >
> >
> > Having googled with this error, I saw some indications that it could be
> >
> > related to the kernel.
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1017683
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1029110
> >
> >
> >
> > For a fresh OEL install, the default kernel is the uek version. "Aha" I
> >
> > thought, let’s change back to the standard RHEL kernel.
> >
> > After a reboot with the RHEL kernel, I was still not able to log in
with
> my
> >
> > ipa user.
> >
> >
> >
> > I then logged on as root, and changed to my ipa user via su.
> >
> > > klist -l
> >
> > produced:
> >
> > KEYRING:persistent:93397:krb_cache_76B9lf2 (Expired)
>
> I'm surprised you had any ccache at all, because login as root bypasses
> PAM.
>
> But in general, if you login with sssd and the cache is expired a long
> time ago (1970), that means sssd logged you in offline and the ccache is
> a placeholder for when sssd switches to online mode.
>
> >
> >
> >
> > I therefore deleted the key:
> >
> > > kdestroy -A
> >
> > Then I stopped the sssd service, and cleared the cache
> in /var/lib/sss/db/,
> >
> > then 

Re: [Freeipa-users] FreeIPA user can't login to linux.

[Rob Crittenden]

zhiyong xue wrote:
> Rob, where can I get more error information beside the log?
> [16/Nov/2015:02:52:59 +] managed-entries-plugin - mep_del_post_op:
> failed to delete managed entry
> (member=syncopex5,cn=groups,cn=accounts,dc=example,dc=com) - error (32)

I can still only assume what you're doing: manually adding the entries
directly by LDAP. To do this you need to follow IPA conventions, or use
the new user lifecycle framework added in 4.2.

I'm guessing it can't delete the managed entry because either it doesn't
exist or it is missing an objectclass/attribute marking it as managed.

rob

> 
> 2015-11-16 13:43 GMT+08:00 zhiyong xue  >:
> 
> I am using IPA 4.1 in CenOS7.  And I can login to system after "id
> syncopex5", maybe it's cache problem.
> 
> 2015-11-16 11:24 GMT+08:00 Rob Crittenden  >:
> 
> zhiyong xue wrote:
> > We integrated the Apache Syncope server with FreeIPA server. So 
> user can
> > self register ID from Apache Syncope then synchronize to FreeIPA. 
> The
> > problems are:
> > *1) User created from Apache Syncope can't login to linux. The
> user
> > created from FreeIPA web gui works well.*
> 
> For login issues see
> https://fedorahosted.org/sssd/wiki/Troubleshooting
> This is unlikely to fix things but it will help with later
> debugging.
> 
> This likely revolves around how you are creating these accounts.
> We'll
> need information on what you're doing. The more details the better.
> 
> > *2) The user also can't be deleted from web UI and CLI. It said
> > "syncopex5: user not found".*
> 
> Again, you probably aren't creating the users correctly.
> 
> I can only assume that you are creating the users directly via
> an LDAP
> add. This is working around the IPA framework which does
> additional work.
> 
> Knowing what version of IPA this is would help too.
> 
> You'll probably also want to read this:
> http://www.freeipa.org/page/V4/User_Life-Cycle_Management . This
> is in
> IPA 4.2.
> 
> rob
> rob
> 
> 
> 

-- 
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] proftpd with ipa

[Rob Crittenden]

patrickcprove...@eaton.com wrote:
> I don't have that one enabled.  I have use one that allows only my Unix 
> admins to have access to all systems.

Ok, I'd start with typical SSSD troubleshooting then:
https://fedorahosted.org/sssd/wiki/Troubleshooting

rob

> 
> -Original Message-
> From: Rob Crittenden [mailto:rcrit...@redhat.com] 
> Sent: Thursday, November 19, 2015 10:51 AM
> To: Provenzo, Patrick C; freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] proftpd with ipa
> 
> patrickcprove...@eaton.com wrote:
>> I cannot get proftpd to authenticate with IPA.  I received the 
>> following messages in /var/log/secure
>>
>>  
>>
>> proftpd[21477]: 151.##.##.## (151.#.##.##[151.##.##.##]) - USER
>> e0026887: no such user found from 151.##.##.## [151.##.##.##] to 
>> 151.##.##.##
>>
> 
> Just throwing this out there, but what HBAC rules do you have? Do you still 
> have the allow_all rule enabled?
> 
> rob
> 
>>  
>>
>> Here are all the versions I have installed
>>
>>  
>>
>> RHEL - 6.7
>>
>> IPA - 3.0.0-47.el6
>>
>> proftpd.x86_64  1.3.3g-4.el6 
>>
>> proftpd-ldap.x86_64 1.3.3g-4.el6
>>
>>  
>>
>> I have attached my proftpd.conf file also.
>>
>>  
>>
>> Patrick Provenzo
>>
>> www.eaton.com 
>>
>> Specialist.IT.EIS-E.Design & Engineering**
>>
>> patrickcprove...@eaton.com
>>
>>  
>>
>>
>>
> 

-- 
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] 4.2 Packages for RHEL/CentOS 7.1

[Baird, Josh]

RHEL 7.2 went GA today.  

> On Nov 19, 2015, at 7:59 PM, Christopher Young  wrote:
> 
> I recall that original message about the packaging before RHEL 7.2 and
> how few of us expressed interest.  I believe I did respond to the
> positive that I could use these packages, but I certainly understand
> additional effort.  I just hate to be waiting on RH's cycle to get
> updates to one of the pieces of my infrastructure where features are
> in-demand and getting added more often.  I prefer my base server OS's
> to stay as stable as possible, but FreeIPA is an exception for me.  In
> any case, I appreciate the effort and the response.
> 
> Just so that I'm clear, this basically means that we should wait until
> the RHEL 7.2 release (and the following CentOS 7.2 release) before
> this will generally available?  I want to make sure I pay attention to
> that as it gets released.
> 
> Thanks,
> 
> Chris
> 
>> On Thu, Nov 12, 2015 at 3:45 AM, Alexander Bokovoy  
>> wrote:
>>> On Wed, 11 Nov 2015, Christopher Young wrote:
>>> 
>>> Do we know what the status of getting these packages prepped and into the
>>> mainstream repos (like EPEL, I suppose)?
>>> 
>>> I'm just curious as I try and keep my repos minimal on servers (for
>>> obvious
>>> reasons), but I would really like to begin testing/using the functionality
>>> in 4.2.
>> 
>> I believe EPEL's policy prevents you from packaging software which
>> exists in RHEL proper. FreeIPA 4.2 is coming with RHEL 7.2, it is
>> already published as part of RHEL 7.2 beta in September.
>> 
>> I want to remind  that during this summer I ran few queries here
>> (freeipa-users@) and elsewhere to solicit opinions whether people want
>> to have FreeIPA 4.2 packages available for CentOS before RHEL 7.2
>> release. Very few responses came back and there wasn't any convincing
>> feedback that would have justified additional effort to make the
>> repository and maintenance reasonable.
>> 
>> https://www.redhat.com/archives/freeipa-users/2015-July/msg00243.html
>> 
>> --
>> / Alexander Bokovoy
> 
> -- 
> 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

[Freeipa-users] proftpd with ipa

[PatrickCProvenzo]

I cannot get proftpd to authenticate with IPA.  I received the following 
messages in /var/log/secure

proftpd[21477]: 151.##.##.## (151.#.##.##[151.##.##.##]) - USER e0026887: no 
such user found from 151.##.##.## [151.##.##.##] to 151.##.##.##

Here are all the versions I have installed

RHEL - 6.7
IPA - 3.0.0-47.el6
proftpd.x86_64  1.3.3g-4.el6
proftpd-ldap.x86_64 1.3.3g-4.el6

I have attached my proftpd.conf file also.

Patrick Provenzo
www.eaton.com
Specialist.IT.EIS-E.Design & Engineering
patrickcprove...@eaton.com



proftpd.conf
Description: proftpd.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] proftpd with ipa

[Rob Crittenden]

patrickcprove...@eaton.com wrote:
> I cannot get proftpd to authenticate with IPA.  I received the following
> messages in /var/log/secure
> 
>  
> 
> proftpd[21477]: 151.##.##.## (151.#.##.##[151.##.##.##]) - USER
> e0026887: no such user found from 151.##.##.## [151.##.##.##] to
> 151.##.##.##
> 

Just throwing this out there, but what HBAC rules do you have? Do you
still have the allow_all rule enabled?

rob

>  
> 
> Here are all the versions I have installed
> 
>  
> 
> RHEL – 6.7
> 
> IPA - 3.0.0-47.el6
> 
> proftpd.x86_64  1.3.3g-4.el6 
> 
> proftpd-ldap.x86_64 1.3.3g-4.el6
> 
>  
> 
> I have attached my proftpd.conf file also.
> 
>  
> 
> Patrick Provenzo
> 
> www.eaton.com 
> 
> Specialist.IT.EIS-E.Design & Engineering**
> 
> patrickcprove...@eaton.com
> 
>  
> 
> 
> 

-- 
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] proftpd with ipa

[Jakub Hrozek]

On Thu, Nov 19, 2015 at 11:32:32AM -0500, Rob Crittenden wrote:
> patrickcprove...@eaton.com wrote:
> > I don't have that one enabled.  I have use one that allows only my Unix 
> > admins to have access to all systems.
> 
> Ok, I'd start with typical SSSD troubleshooting then:
> https://fedorahosted.org/sssd/wiki/Troubleshooting
> 
> rob

In addition the proftpd message says "no such user", can you resolve the
user on the proftpd server with 'getent passwd $username' ?

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