date:20151005

Re: [Freeipa-users] re-initialize replica

2015-10-05 Thread Rob Crittenden

Andrew E. Bruno wrote:
> On Mon, Oct 05, 2015 at 12:40:42PM +0200, Martin Kosek wrote:
>> On 10/02/2015 06:00 PM, Andrew E. Bruno wrote:
>>> On Fri, Oct 02, 2015 at 09:56:47AM -0400, Andrew E. Bruno wrote:
 What's the best way to re-initialize a replica? 

 Suppose one of your replicas goes south.. is there a command to tell
 that replicate to re-initialize from the first master (instead of
 removing/re-adding the replica from the topology)?
>>>
>>> Found the command I was looking for:
>>>ipa-replica-manage re-initialize --from xxx
>>>
>>> However, one of our replicates is down and can't seem to re-initialize
>>> it. Starting ipa fails (via systemctl restart ipa):
>>>
>>> ipactl status
>>> Directory Service: RUNNING
>>> krb5kdc Service: STOPPED
>>> kadmin Service: STOPPED
>>> named Service: STOPPED
>>> ipa_memcached Service: STOPPED
>>> httpd Service: STOPPED
>>> pki-tomcatd Service: STOPPED
>>> ipa-otpd Service: STOPPED
>>> ipa: INFO: The ipactl command was successful
>>>
>>>
>>> Errors from the dirsrv show:
>>>
>>> : GSSAPI Error: Unspecified GSS failure.  Minor code may provide more 
>>> information (No Kerberos credentials available)) errno 0 (Success)
>>> [02/Oct/2015:11:45:05 -0400] slapi_ldap_bind - Error: could not perform 
>>> interactive bind for id [] authentication mechanism [GSSAPI]: error -2 
>>> (Local error)
>>> [02/Oct/2015:11:50:05 -0400] set_krb5_creds - Could not get initial 
>>> credentials for principal [ldap/server@realm] in keytab 
>>> [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for 
>>> requested realm)
>>> [02/Oct/2015:11:50:05 -0400] slapd_ldap_sasl_interactive_bind - Error: 
>>> could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 
>>> (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS 
>>> failure.  Minor code may provide more information (No Kerberos credentials 
>>> available)) errno 0 (Success)
>>> [02/Oct/2015:11:50:05 -0400] slapi_ldap_bind - Error: could not perform 
>>> interactive bind for id [] authentication mechanism [GSSAPI]: error -2 
>>> (Local error)
>>>
>>>
>>> Attempting to re-initialize fails:
>>>
>>> ipa-replica-manage re-initialize --from master
>>> Connection timed out.
>>>
>>>
>>> I verified time is in sync and DNS forward/reverse resolution is working.
>>>
>>> Any pointers on what else to try?
>>>
>>> Thanks!
>>>
>>> --Andrew
>>
>> Given that your Kerberos server instance is down, I would start investigating
>> Kerberos logs to see why.
> 
> 
> So looks like the dirsrv service comes up but with GSS errors about kerb
> credentials. However, the rest of the services including the krb5kdc
> fail to come up. Errors from the kdc logs suggest DNS:

DS complaining about GSS is somewhat normal during startup as it is a
bit noisy. The other errors suggest there is no data in the backend. An
ldapsearch would confirm that.

> 
>  LOOKING_UP_CLIENT: DNS/replica@REALM Server error
> 
> FreeIPA is configured to serve DNS and this replica resolves it's own
> DNS in /etc/resolv.conf (127.0.0.1)
> 
> I tried pointing /etc/resolv.conf to another (good) replica and even
> tried adjusting /etc/krb5.conf to point at another kdc to try and get a
> ticket however it still tries to connect to the local kdc (which fails
> to start).  
> 
> I'm inclined to re-install this replica and start fresh. I'm curious if
> we can re-kickstart this host from a fresh os/freeipa install and run
> the  ipa-replica-manage re-initialize --from master command. The replica
> will have the same name.. is this possible? Would we need to backup the
> /var/lib/ipa/replica-info-XXX.gpg file?

It needs to have its own principal in order to re-initialize. It sounds
like it has nothing which is why replication is failing.

I'd recommend generating a new replica file. There is no value in
re-using the old one and it could be harmful if the certificates are
expired.

You'll need to delete all replication agreements this master had and
you'll need to use the --force option since it won't be accessible. When
you re-install the master it will get all the current data as part of
the setup so no need to re-initialize after that.

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] More replication fun

2015-10-05 Thread Rob Crittenden

Janelle wrote:
> On 10/5/15 10:16 AM, Simo Sorce wrote:
>> On 05/10/15 11:11, Janelle wrote:
>>> So here is a fun question -- how is this possible?
>>>
>>> from ipa-replica-manage list-ruv
>>>
>>> ipa002.example.com 389  6
>>> ipa003.example.com 389  30   <-  Huh???
>>> ipa003.example.com 389  33   <-
>>> ipa004.example.com 389  24
>>
>> ipa003 was reinstalled but the RUV was not properly cleaned
>>
>> Simo.
>>
>>
> So there is no conflict even with a duplicate like that? I mean the
> server only physically exists once, so I guess it should not cause a
> problem. I mean replication seems to be working, it just seems odd that
> I saw that.  You would think that the normal ipa-replica-manage "del"
> options would do all the proper cleaning, but apparently not.

I'd recommend cleaning the unused RUV as it causes the directory server
to do work on it, even if it results in nothing.

The server should clean up RUVs upon deletion but it is done as a task
which can fail, but by that point the agreement is already gone.

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] More replication fun

2015-10-05 Thread Janelle


On 10/5/15 10:16 AM, Simo Sorce wrote:

On 05/10/15 11:11, Janelle wrote:

So here is a fun question -- how is this possible?

from ipa-replica-manage list-ruv

ipa002.example.com 389  6
ipa003.example.com 389  30   <-  Huh???
ipa003.example.com 389  33   <-
ipa004.example.com 389  24


ipa003 was reinstalled but the RUV was not properly cleaned

Simo.


So there is no conflict even with a duplicate like that? I mean the 
server only physically exists once, so I guess it should not cause a 
problem. I mean replication seems to be working, it just seems odd that 
I saw that.  You would think that the normal ipa-replica-manage "del" 
options would do all the proper cleaning, but apparently not.


Thanks for the clarification.
~J

--
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] re-initialize replica

2015-10-05 Thread Andrew E. Bruno

On Mon, Oct 05, 2015 at 12:40:42PM +0200, Martin Kosek wrote:
> On 10/02/2015 06:00 PM, Andrew E. Bruno wrote:
> > On Fri, Oct 02, 2015 at 09:56:47AM -0400, Andrew E. Bruno wrote:
> >> What's the best way to re-initialize a replica? 
> >>
> >> Suppose one of your replicas goes south.. is there a command to tell
> >> that replicate to re-initialize from the first master (instead of
> >> removing/re-adding the replica from the topology)?
> > 
> > Found the command I was looking for:
> >ipa-replica-manage re-initialize --from xxx
> > 
> > However, one of our replicates is down and can't seem to re-initialize
> > it. Starting ipa fails (via systemctl restart ipa):
> > 
> > ipactl status
> > Directory Service: RUNNING
> > krb5kdc Service: STOPPED
> > kadmin Service: STOPPED
> > named Service: STOPPED
> > ipa_memcached Service: STOPPED
> > httpd Service: STOPPED
> > pki-tomcatd Service: STOPPED
> > ipa-otpd Service: STOPPED
> > ipa: INFO: The ipactl command was successful
> > 
> > 
> > Errors from the dirsrv show:
> > 
> > : GSSAPI Error: Unspecified GSS failure.  Minor code may provide more 
> > information (No Kerberos credentials available)) errno 0 (Success)
> > [02/Oct/2015:11:45:05 -0400] slapi_ldap_bind - Error: could not perform 
> > interactive bind for id [] authentication mechanism [GSSAPI]: error -2 
> > (Local error)
> > [02/Oct/2015:11:50:05 -0400] set_krb5_creds - Could not get initial 
> > credentials for principal [ldap/server@realm] in keytab 
> > [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for 
> > requested realm)
> > [02/Oct/2015:11:50:05 -0400] slapd_ldap_sasl_interactive_bind - Error: 
> > could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 
> > (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS 
> > failure.  Minor code may provide more information (No Kerberos credentials 
> > available)) errno 0 (Success)
> > [02/Oct/2015:11:50:05 -0400] slapi_ldap_bind - Error: could not perform 
> > interactive bind for id [] authentication mechanism [GSSAPI]: error -2 
> > (Local error)
> > 
> > 
> > Attempting to re-initialize fails:
> > 
> > ipa-replica-manage re-initialize --from master
> > Connection timed out.
> > 
> > 
> > I verified time is in sync and DNS forward/reverse resolution is working.
> > 
> > Any pointers on what else to try?
> > 
> > Thanks!
> > 
> > --Andrew
> 
> Given that your Kerberos server instance is down, I would start investigating
> Kerberos logs to see why.


So looks like the dirsrv service comes up but with GSS errors about kerb
credentials. However, the rest of the services including the krb5kdc
fail to come up. Errors from the kdc logs suggest DNS:

 LOOKING_UP_CLIENT: DNS/replica@REALM Server error

FreeIPA is configured to serve DNS and this replica resolves it's own
DNS in /etc/resolv.conf (127.0.0.1)

I tried pointing /etc/resolv.conf to another (good) replica and even
tried adjusting /etc/krb5.conf to point at another kdc to try and get a
ticket however it still tries to connect to the local kdc (which fails
to start).  

I'm inclined to re-install this replica and start fresh. I'm curious if
we can re-kickstart this host from a fresh os/freeipa install and run
the  ipa-replica-manage re-initialize --from master command. The replica
will have the same name.. is this possible? Would we need to backup the
/var/lib/ipa/replica-info-XXX.gpg file?


--Andrew



-- 
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 Cross Realm Trust + AIX

2015-10-05 Thread David Fischer


Crony,

I also am trying to setup both AIX 6.1 and AIX 7 clients.

Is there anyway I could get you to post you  working configurations?

Thanks,
David
-Original Message-From: crony 
>
To: freeipa-users@redhat.com
Subject: [Freeipa-users] AD Cross Realm Trust + AIX
Date: Thu, 12 Feb 2015 19:06:59 +0100

Hi All,
can I ask you for some advice?

My setup is:
- updated RHEL7 as IPA server (UX.EXAMPLE.COM)  in trust 
with Active Directory 2008R2 domain (EXAMPLE.COM)
- AIX 7 as IPA client

I'm using compat tree for connecting AIX as client.

A lot of things work correctly:

# /usr/krb5/bin/kinit leszek
Password for ad_u...@example.com:

 # /usr/krb5/bin/klist
Ticket cache:  FILE:/var/krb5/security/creds/krb5cc_0
Default principal:  ad_u...@example.com
Valid starting ExpiresService principal
02/12/15 15:46:23  02/13/15 01:46:31  
krbtgt/example@example.com
Renew until 02/13/15 01:46:23

# lsldap -a passwd ad_u...@example.com
dn: 
uid=ad_u...@example.com,cn=users,cn=compat,dc=ux,dc=example,dc=com
objectClass: posixAccount
objectClass: extensibleObject
objectClass: top
gecos: ad_user
cn: ad_user
uidNumber: 1036620735
gidNumber: 1036620735
homeDirectory: /home/example.com/ad_user
ipaNTSecurityIdentifier: S-1-5-21--X-XX
uid: ad_u...@example.com
# id ad_u...@example.com
uid=1036620735(ad_u...@example.com) 
gid=1036620735(ad_u...@example.com) 
groups=1036620733(another_gr...@example.com)

Here I found the first problem:

# su - ad_u...@example.com
3004-614 Unable to change directory to "".
You are in "/home/guest" instead.
$ id
uid=1036620735(ad_u...@example.com) 
gid=1036620735(ad_u...@example.com) 
groups=1036620733(another_gr...@example.com)

The "3004-614 Unable to change directory to ""." appears after I added to 
/etc/methods.cfg:

KRB5A:
program = /usr/lib/security/KRB5A
program_64 = /usr/lib/security/KRB5A_64
options = authonly
LDAP:
program = /usr/lib/security/LDAP
program_64 =/usr/lib/security/LDAP64

Without these lines there is no error "about change to home directory", su from 
root works smoothly and entered the user to the homedirectory. But now I can't 
ssh to the system, because I have no correct registry.
-
I made another test: if I can log in by just IPA user, ex. admin. There is no 
such problem:

# id admin
uid=3(admin) gid=3(admins)

 # su - admin

-bash-3.2$ pwd
/export/home/admin

-bash-3.2$ id
uid=3(admin) gid=3(admins)
# ssh admin@localhost
admin@localhost's password:
***
* *
* *
*  Welcome to AIX Version 7.1!*
* *
* *
*  Please see the README file in /usr/lpp/bos for information pertinent to*
*  this release of the AIX Operating System.  *
* *
* *
***
-bash-3.2$ id

uid=3(admin) gid=3(admins)

Any idea what is wrong?

I have already changed the AIX max_logname from 8 to 40 characters. Maybe the 
"@" character in login name is a problem?


Thank you in advance. -- /lm




#
The information contained in this electronic mail message, including 
attachments, if any, is PetSmart confidential information. It is intended only 
for the use of the person(s) named above. If the reader of this message is not 
the intended recipient, or has received this message in error, you are hereby 
notified that any review, dissemination, distribution or copying of this 
communication is strictly prohibited. If you are not the intended recipient or 
have received this message in error, please notify the sender via e-mail and 
promptly delete the original message.
#

-- 
Manage your

Re: [Freeipa-users] Cannot connect to FreeIPA web UI anymore

2015-10-05 Thread Fujisan

Good morning,

Any suggestion what I should do?

I still have

$ ipa user-show admin
ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json': Unauthorized


Regards.


On Fri, Oct 2, 2015 at 5:04 PM, Fujisan  wrote:

> I only have this:
>
> $ keyctl list @s
> 1 key in keyring:
> 641467419: --alswrv 0 65534 keyring: _uid.0
> $
>
>
>
> On Fri, Oct 2, 2015 at 5:01 PM, Alexander Bokovoy 
> wrote:
>
>> On Fri, 02 Oct 2015, Fujisan wrote:
>>
>>> I forgot to mention that
>>>
>>> $ ipa user-show admin
>>> ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json':
>>> Unauthorized
>>>
>> This is most likely because of the cached session to your server.
>>
>> You can check if  keyctl list @s
>> returns you something like
>> [root@m1 ~]# keyctl list @s
>> 2 keys in keyring:
>> 496745412: --alswrv 0 65534 keyring: _uid.0
>> 215779962: --alswrv 0 0 user:
>> ipa_session_cookie:ad...@example.com
>>
>> If so, then notice the key number (215779962) for the session cookie,
>> and do:
>>  keyctl purge 215779962
>>  keyctl reap
>>
>> This should make a next 'ipa ...' command run to ask for new cookie.
>>
>>
>>> On Fri, Oct 2, 2015 at 4:44 PM, Fujisan  wrote:
>>>
>>> I still cannot login to the web UI.

 Here is what I did:

1. mv /etc/krb5.keytab /etc/krb5.keytab.save
2. kinit admin
Password for admin@OPERA:
3. ipa-getkeytab -s zaira2.opera -p host/zaira2.opera@OPERA -k
/etc/krb5.keytab
4. systemctl restart sssd.service
5. mv /etc/httpd/conf/ipa.keytab /etc/httpd/conf/ipa.keytab.save
6. ipa-getkeytab -s zaira2.opera -p HTTP/zaira2.opera@OPERA -k
/etc/httpd/conf/ipa.keytab
7. systemctl restart httpd.service


 The log says now:

 Oct 02 16:40:56 zaira2.opera krb5kdc[9065](info): AS_REQ (9 etypes {18
 17
 16 23 25 26 1 3 2}) 10.0.21.18: NEEDED_PREAUTH: HTTP/zaira2.opera@OPERA
 for krbtgt/OPERA@OPERA, Additional pre-authentication required



 On Fri, Oct 2, 2015 at 4:25 PM, Alexander Bokovoy 
 wrote:

 On Fri, 02 Oct 2015, Fujisan wrote:
>
> Well, I think I messed up when trying to configure cockpit to use
>> kerberos.
>>
>> What should I do to fix this?
>>
>> I have this on the ipa server:
>> $ klist -k
>> Keytab name: FILE:/etc/krb5.keytab
>> KVNO Principal
>> 
>>
>>
>> --
>>   2 host/zaira2.opera@OPERA
>>   2 host/zaira2.opera@OPERA
>>   2 host/zaira2.opera@OPERA
>>   2 host/zaira2.opera@OPERA
>>   1 nfs/zaira2.opera@OPERA
>>   1 nfs/zaira2.opera@OPERA
>>   1 nfs/zaira2.opera@OPERA
>>   1 nfs/zaira2.opera@OPERA
>>   3 HTTP/zaira2.opera@OPERA
>>   3 HTTP/zaira2.opera@OPERA
>>   3 HTTP/zaira2.opera@OPERA
>>   3 HTTP/zaira2.opera@OPERA
>>
>> You can start by:
>>
> 0. backup every file mentioned below
> 1. Move /etc/krb5.keytab somewhere
> 2. kinit as admin
> 3. ipa-getkeytab -s `hostname` -p host/`hostname` -k /etc/krb5.keytab
> 4. restart SSSD
> 5. Move /etc/httpd/conf/ipa.keytab somewhere
> 6. ipa-getkeytab -s `hostname` -p HTTP/`hostname` -k
> /etc/httpd/conf/ipa.keytab
> 7. Restart httpd
>
> Every time you run 'ipa-getkeytab', Kerberos key for the service
> specified by you is replaced on the server side so that keys in the
> keytabs become unusable.
>
> I guess cockpit instructions were for something that was not supposed
> to
> run on IPA master. On IPA master there are already all needed services
> (host/ and HTTP/) and their keytabs are in place.
>
>
>
> On Fri, Oct 2, 2015 at 3:45 PM, Alexander Bokovoy > >
>> wrote:
>>
>> On Fri, 02 Oct 2015, Fujisan wrote:
>>
>>>
>>> More info:
>>>

 I can initiate a ticket:
 $ kdestroy
 $ kinit admin

 but cannot view user admin:
 $ ipa user-show admin
 ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json':
 Unauthorized

 $ ipactl status
 Directory Service: RUNNING
 krb5kdc Service: RUNNING
 kadmin Service: RUNNING
 named Service: RUNNING
 ipa_memcached Service: RUNNING
 httpd Service: RUNNING
 pki-tomcatd Service: RUNNING
 smb Service: RUNNING
 winbind Service: RUNNING
 ipa-otpd Service: RUNNING
 ipa-dnskeysyncd Service: RUNNING
 ipa: INFO: The ipactl command was successful

 /var/log/messages:
 Oct  2 14:48:55 zaira2 [sssd[ldap_child[4991]]]: Failed to
 initialize
 credentials using keytab [MEMORY:/etc/krb5.keytab]: Decrypt
 integrity
 check

Re: [Freeipa-users] DNS forwarding configuration randomly breaks and stops working

2015-10-05 Thread Petr Spacek

On 3.10.2015 01:47, nat...@nathanpeters.com wrote:
> This issue has occured again and I am once again trying to troubleshoot it.
> 
> show forwarder
> --
> -bash-4.2$ ipa dnsconfig-show
>   Global forwarders: 10.21.0.14
>   Allow PTR sync: TRUE
> 
> attempt ping
> 
>   -bash-4.2$ ping stash.externaldomain.net
> ping: unknown host stash.externaldomain.net
> 
> -attempt nslookup
> -
> -bash-4.2$ nslookup
>> stash.externaldomain.net
> Server: 127.0.0.1
> Address:127.0.0.1#53
> 
> ** server can't find stash.externaldomain.net: NXDOMAIN
> 
> *comment* : strange it doesn't work against localhost.  Lets make sure
> that localhost lookups work at all :
> 
> -bash-4.2$ nslookup
>> google.com
> Server: 127.0.0.1
> Address:127.0.0.1#53
> 
> Non-authoritative answer:
> Name:   google.com
> Address: 216.58.216.142
> 
> *comment* : yup, I can resolve google.com when talking to localhost...
> 
> now lets try to talk to the forwarder configured in the global settings
> ---
>> server 10.21.0.14
> Default server: 10.21.0.14
> Address: 10.21.0.14#53
>> stash.externaldomain.net
> Server: 10.21.0.14
> Address:10.21.0.14#53
> 
> Non-authoritative answer:
> stash.externaldomain.net   canonical name = git1.externaldomain.net.
> Name:   git1.externaldomain.net
> Address: 10.20.10.30
> 
> more troubleshooting
> 
> I ran wireshark to see what the freeipa server was sending back to the
> client :
> 
> 3 0.00039310.178.0.99 10.178.21.2 DNS 163 
> Standard query response 0x12ca
> No such name CNAME git1.externaldomain.net
> 
> I've never seen a 'no such CNAME' response before.  Lets look at the
> contents of the packet:
> 
> 
> Frame 4: 163 bytes on wire (1304 bits), 163 bytes captured (1304 bits)
> Ethernet II, Src: Vmware_b7:09:c6 (00:50:56:b7:09:c6), Dst:
> HewlettP_3c:f9:48 (2c:59:e5:3c:f9:48)
> Internet Protocol Version 4, Src: 10.178.0.99 (10.178.0.99), Dst:
> 10.178.21.2 (10.178.21.2)
> User Datagram Protocol, Src Port: 53 (53), Dst Port: 57374 (57374)
> Domain Name System (response)
> [Request In: 1]
> [Time: 0.000414000 seconds]
> Transaction ID: 0x12ca
> Flags: 0x8183 Standard query response, No such name
> 1...    = Response: Message is a response
> .000 0...   = Opcode: Standard query (0)
>  .0..   = Authoritative: Server is not an authority
> for domain
>  ..0.   = Truncated: Message is not truncated
>  ...1   = Recursion desired: Do query recursively
>   1...  = Recursion available: Server can do recursive
> queries
>   .0..  = Z: reserved (0)
>   ..0.  = Answer authenticated: Answer/authority
> portion was not authenticated by the server
>   ...0  = Non-authenticated data: Unacceptable
>    0011 = Reply code: No such name (3)
> Questions: 1
> Answer RRs: 1
> Authority RRs: 1
> Additional RRs: 0
> Queries
> stash.externaldomain.net: type A, class IN
> Name: stash.externaldomain.net
> [Name Length: 21]
> [Label Count: 3]
> Type: A (Host Address) (1)
> Class: IN (0x0001)
> Answers
> stash.externaldomain.net: type CNAME, class IN, cname
> git1.externaldomain.net
> Name: stash.externaldomain.net
> Type: CNAME (Canonical NAME for an alias) (5)
> Class: IN (0x0001)
> Time to live: 22483
> Data length: 20
> CNAME: git1.externaldomain.net
> Authoritative nameservers
> externaldomain.net: type SOA, class IN, mname
> van-dns1.externaldomain.net
> Name: externaldomain.net
> Type: SOA (Start Of a zone of Authority) (6)
> Class: IN (0x0001)
> Time to live: 518
> Data length: 38
> Primary name server: van-dns1.externaldomain.net
> Responsible authority's mailbox: tech.externaldomain.net
> Serial Number: 2015092101
> Refresh Interval: 10800 (3 hours)
> Retry Interval: 900 (15 minutes)
> Expire limit: 604800 (7 days)
> Minimum TTL: 86400 (1 day)
> 
> 
>> We have a FreeIPA domain running IPA server 4.1.4 on CentOS 7.
>>
>> We have no per zone forwarding enabled, only a single global forwarder.
>> This seems to work fine, but then after a while (several weeks I think)
>> will randomly stop working.
>>
>> We had this issue several weeks ago on a different IPA domain (identical
>> setup) in our production network but it was ignored because a server
>> restart fixed it.
>>
>> This issue then re-surfaced in our development domain today (different
>> network, different physical hardware, same OS and IPA versions).

Re: [Freeipa-users] ssh and sudo password authentication not working with freeipa-client 3.3.4-0ubuntu3.1 on Ubuntu 14.04

2015-10-05 Thread Alexander Skwar

Hi

Hm, there's nothing at all in the /var/log/sssd/krb5_child.log when I try
to login with SSH and enter a password.

kinit doesn't work.

$ kinit -k
kinit: Permission denied while getting initial credentials

For this test, I was root and then did a "su - user" and then "kinit -k".
Also after the "kinit -k", nothing is in the krb5_child.log.

Regards,
Alexander


2015-10-02 17:59 GMT+02:00 Jakub Hrozek :

> On Fri, Oct 02, 2015 at 04:28:57PM +0200, Alexander Skwar wrote:
> > Hello
> >
> > How do I get password authentication to work with freeipa-client
> > 3.3.4-0ubuntu3.1 on Ubuntu 14.04 for ssh and sudo?
> >
> > Long version follows :)
> >
> > We've got an IPA server with the Red Hat Identity Management server
> > on RHEL 7.1 servers; FreeIPA v4.1.0 is being used there. I configured
> > users and groups there and would now like to login with SSH. When I
> > store a SSH key for the user account, I can login just fine, using
> > this SSH key. But I'd like/need to use passwords as well. And sudo
> > also doesn't work, when it's asking for passwords - I supposed,
> > it's the same root cause.
> >
> > Let's stick with SSH.
> >
> > Initially, I installed the FreeIPA client with this command line:
> >
> > ipa-client-install --force-join --mkhomedir --ssh-trust-dns \
> >   --enable-dns-updates --unattended \
> >   --principal=admin --password=correctone \
> >   --domain=customer.company.internal \
> >   --server=auth01.customer.company.internal
> >
> > I then try to do a SSH login with:
> >
> > ssh -l ewt@customer.company.internal 192.168.229.143
> > or:
> > ssh -l ewt 192.168.229.143
> >
> > Password authentication doesn't work.
> >
> > In the /var/log/syslog on the system where I try to login, I find this:
> >
> > 2015-10-02T15:33:38.771291+02:00 mgmt02 [sssd[krb5_child[14154]]]:
> > Key table entry not found
> >
> > After having turned up the debug level of the sssd with "sssd -i -f -d
> > 0x0770 --debug-timestamps=1", I find the following in the system log
> > files:
> >
> > 2015-10-02T15:40:48.756399+02:00 mgmt02 sshd[14194]:
> > pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0
> > tty=ssh ruser= rhost=212.71.117.1  user=ewt
> > 2015-10-02T15:40:48.775896+02:00 mgmt02 sshd[14194]:
> > pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0
> > tty=ssh ruser= rhost=212.71.117.1 user=ewt
> > 2015-10-02T15:40:48.775927+02:00 mgmt02 sshd[14194]:
> > pam_sss(sshd:auth): received for user ewt: 4 (System error)
> > 2015-10-02T15:40:50.988591+02:00 mgmt02 sshd[14194]: Failed
> > password for ewt from 212.71.117.1 port 58136 ssh2
> >
> > TBH, I don't quite understand it. Anyway, in
> > /var/log/sssd/sssd_customer.company.internal.log I noticed:
> >
> > (Fri Oct  2 15:46:26 2015) [sssd[be[customer.company.internal]]]
> > [read_pipe_handler] (0x0400): EOF received, client finished
> > (Fri Oct  2 15:46:26 2015) [sssd[be[customer.company.internal]]]
> > [parse_krb5_child_response] (0x0020): message too short.
> > (Fri Oct  2 15:46:26 2015) [sssd[be[customer.company.internal]]]
> > [krb5_auth_done] (0x0040): Could not parse child response [22]:
> > Invalid argument
> > (Fri Oct  2 15:46:26 2015) [sssd[be[customer.company.internal]]]
> > [ipa_auth_handler_done] (0x0040): krb5_auth_recv request failed.
> >
> > Well… What am I doing wrong or what might I have forgotten?
>
> We need to also see the krb5_child.log but please check if the keytab is
> correct (ie kinit -k works).
>
> --
> 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
>



-- 


Alexander
-- 
=>*Google+* => http://plus.skwar.me <==
=> *Chat* (Jabber/Google Talk) => a.sk...@gmail.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] Sudo default options

2015-10-05 Thread Pavel Březina


On 10/05/2015 10:58 AM, Andreas Calminder wrote:

Hi,
guessing this is a quite frequent question, but I can't find any solid
information about the topic.
I want to specify a set of default sudo options so I don't have to
specify these options for every other sudo rule I create.
There's supposed to be a magic "defaults" rule.
This old document
(https://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf) 
suggests
it's cn=defaults,ou=sudorules,dc=example,dc=com which doesn't exist in
my ipa 4.1 installation others suggest it's under
ou=sudoers,dc=example,dc=com when poking around in ldap it looks like it
could also be cn=sudorules,cn=sudo,dc=example,dc=com, but there is no
way to be sure. Also, might it be as simple as create a defaults rule in
the webui or cli with the default options set or is this a ldapmodify
action?


Hi,
just create a sudo rule named "defaults" through ipa cli or wui.

--
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] admin loses access?

2015-10-05 Thread Prasun Gera

I was facing similar issues, and ended up changing the username from admin
to something else since admin is a common name in brute force ssh attacks.
It was getting locked out in spite of using fail2ban. I guess fail2ban can
be tweaked to block the host before ipa blocks the admin account, but I
didn't bother doing that. Changing the username seemed easier.

On Mon, Oct 5, 2015 at 8:19 AM, Rob Crittenden  wrote:

> Janelle wrote:
> > On 10/5/15 7:39 AM, Rob Crittenden wrote:
> >> Torsten Harenberg wrote:
> >>> Hi Janelle,
> >>>
> >>> Am 04.10.2015 um 19:25 schrieb Janelle:
>  Just wondering if anyone knows why this happens from time to time on
>  servers:
> 
>  $ kinit admin
>  kinit: Clients credentials have been revoked while getting initial
>  credentials
> 
>  there are no failed logins to the admin account - not even any login
>  attempts, so it is not like someone is getting the account locked out.
>  Just curious if anyone else has seen in. With 16 masters, it occurs
>  randomly on some hosts, but eventually clears either on its own or
> with
>  a restart of IPA. However, I just restarted IPA on this server and
>  after
>  about 2-3 minutes it works again.
> 
> >>> I am seeing the same, see my mail "kinit admin not working anymore
> >>> (LOCKED_OUT: Clients credentials have been revoked)" from 03-SEPT.
> >>> Actually, wasn't it you who wanted to open a ticket?
> >>>
> >>> Have a nice evening,
> >>>
> >>>Torsten
> >>>
> >> When you see this run `ipa user-status admin` and `ipa pwpolicy-show
> >> --user=admin` and provide that so we can potentially see what is going
> >> on.
> >>
> >> rob
> >>
> > I am curious -- if you have 16 masters, but this only happens once in
> > awhile on 1 or 2 servers, how does the pwpolicy fit in? I am trying to
> > understand the thinking of where you are going?? I will for sure do this
> > the next time it happens, but I want to understand logic?
>
> Lockout is per-master because the failed auth count and successful login
> date is not replicated due to performance issues.
>
> The user-status command will collect the lockout attributes from each
> server, but it doesn't do the calculations, so the pwpolicy is needed as
> well in order to figure out whether on a given master the user is locked
> out.
>
> 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
>
-- 
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] separating authoritative servers from recursive servers

2015-10-05 Thread Brendan Kearney

i have two bind instances in somewhat of a multi-master server 
arrangement, where they share the same ldap backend via 
bind-dyndb-ldap.  currently, they are authoritative and recursive 
servers, and i want to change things up a bit.  i want to move the 
recursive function to a third device.  for this, i believe i need to set 
a forwarder for the two current servers.  i believe i would do this by 
adding the idnsForwarders object (with value) on the OU that is the 
idnsConfigObject.


i am looking for a sanity check, to ensure that i am not overlooking 
something important.  are there any steps i am missing?  i want the 
current two instances to be authoritative for all my forward and reverse 
zones, and use the forwarder for all recursion.  the forwarder instance 
is already running, and is setup to answer queries from only the two 
current instances.  i think i just need to point the current instances 
to the forwarder instance, and turn off recursion on them.


thanks in advance,

brendan

--
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] DNS forwarding configuration randomly breaks and stops working

2015-10-05 Thread nathan

>>> Looking at the log entries, it appears that there may have been a
>>> network
>>> connectivity 'blip' (maybe a switch or router was restarted) at some
>>> point
>>> and even after connectivity was restored, the global forwarding was
>>> failing because the "we can't contact our forwarder" status seemed to
>>> get
>>> stuck in memory.
>
> Most likely.
>
>>> [root@dc1 ~]# ipa dnsconfig-show
>>>   Global forwarders: 10.21.0.14
>>>   Allow PTR sync: TRUE
>
> This means that you are using the default forward policy which is 'first'.
> I.e. BIND daemon on the IPA server is trying to use the forwarder first
> and
> when it fails it fallbacks to asking server on the public Internet.
>
> I speculate that public servers know nothing about the name you were
> asking
> for and this negative answer got cached. This is default behavior in BIND
> and
> IPA did not change it.
>
> Workaround for network problems could be
> $ ipa dnsconfig-mod --forward-policy=only
> which will prevent BIND from falling back to public servers.
>
> Anyway, you should solve network connectivity problems, too :-)
>
> I hope this helps.
>
> --
> Petr^2 Spacek
>
> --
> 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
>

Ok, we managed to figure out what was happening here, but I still think
there is a bug somewhere in the FreeIPA DNS components that is
exacerbating the issue.

We have split DNS in our company.  We have a public copy of our DNS
records, which contain only A records.  We also have an internal copy of
our DNS records, which contains a bunch of CNAME records.

When we use nslookup to query the IPA server for stash.externaldomain.net
NSLOOKUP returns that stash.externaldomain.net is a CNAME and it returns
the associated A address.

When we query FreeIPA though a DNS client, FreeIPA returns that stash is a
cname and does not return the associated A address.  It seems like at that
point, FreeIPA decides that instead of sticking in 'forward' mode and
forwarding the request for the CNAME




-- 
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] DNS forwarding configuration randomly breaks and stops working

2015-10-05 Thread nathan

>>> Looking at the log entries, it appears that there may have been a
>>> network
>>> connectivity 'blip' (maybe a switch or router was restarted) at some
>>> point
>>> and even after connectivity was restored, the global forwarding was
>>> failing because the "we can't contact our forwarder" status seemed to
>>> get
>>> stuck in memory.
>
> Most likely.
>
>>> [root@dc1 ~]# ipa dnsconfig-show
>>>   Global forwarders: 10.21.0.14
>>>   Allow PTR sync: TRUE
>
> This means that you are using the default forward policy which is 'first'.
> I.e. BIND daemon on the IPA server is trying to use the forwarder first
> and
> when it fails it fallbacks to asking server on the public Internet.
>
> I speculate that public servers know nothing about the name you were
> asking
> for and this negative answer got cached. This is default behavior in BIND
> and
> IPA did not change it.
>
> Workaround for network problems could be
> $ ipa dnsconfig-mod --forward-policy=only
> which will prevent BIND from falling back to public servers.
>
> Anyway, you should solve network connectivity problems, too :-)
>
> I hope this helps.
>
> --
> Petr^2 Spacek
>
> --
> 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
>

Ok, we managed to figure out what was happening here, but I still think
there is a bug somewhere in the FreeIPA DNS components that is
exacerbating the issue.

We have split DNS in our company.  We have a public copy of our DNS
records, which contain only A records.  We also have an internal copy of
our DNS records, which contains a bunch of CNAME records.

When we use nslookup to query the IPA server for stash.externaldomain.net
NSLOOKUP returns that stash.externaldomain.net is a CNAME and it returns
both the CNAME and the associated A address.

When we query FreeIPA though a DNS client, FreeIPA returns that stash is a
CNAME and does not return the associated A address.  It seems like at that
point, FreeIPA decides that instead of sticking in 'forward' mode and
forwarding the request for the CNAME record to the forwarding server, it
decides instead to switch into recursive mode and begin the lookup by
querying root servers for externaldomain.net at which point since it is
going out to the general internet, it gets back answers from our public
facing DNS servers (remember we use split DNS).

The answer it gets is (quite rightly) that there is no such CNAME record
on the public DNS server.

So I have a couple questions about how the forward first policy is
supposed to work...

1.  In forward first mode, if the forward server returns a CNAME, is
FreeIPA supposed to ask the same forwarding server for the A record
associated with the CNAME, or is it supposed to then flip into recursive
mode and go to the root servers to find the CNAME?  I would expect #1, but
it seems like #2 is always happening no matter what.  I would only expect
it to attempt recursion if the initial query actually failed, not just
returned something other than an A record.

2. We did some more network packet capture, and noticed that in forward
first mode, the FreeIPA server, always sent out both a forward request to
the forwarding server, and an additional simultaneous request to the root
name servers (recursive mode).  It got back responses to both the
forwarded and recursive queries it had performed.  The recursive query
failed due to split DNS and the forwarded query succeeded due to it going
to an internal server which had the correct records.  Strangely enough...
the IPA server ignored the successful forwarded answer, and sent back the
'failed' answer it had gotten through recursion back to the requesting
client.  What is the behavior supposed to be in this situation and why is
the server always sending out the recursive request, even when it gets a
valid answer from the forwarded request?




-- 
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] admin loses access?

2015-10-05 Thread Rob Crittenden

Prasun Gera wrote:
> I was facing similar issues, and ended up changing the username from
> admin to something else since admin is a common name in brute force ssh
> attacks. It was getting locked out in spite of using fail2ban. I guess
> fail2ban can be tweaked to block the host before ipa blocks the admin
> account, but I didn't bother doing that. Changing the username seemed
> easier. 

Right, the power lies in the admins group. The only exception is in the
replica connection checker where the name 'admin' is hardcoded. There is
a ticket open to fix this. Otherwise AFAIK the name shouldn't matter.

rob

> 
> On Mon, Oct 5, 2015 at 8:19 AM, Rob Crittenden  > wrote:
> 
> Janelle wrote:
> > On 10/5/15 7:39 AM, Rob Crittenden wrote:
> >> Torsten Harenberg wrote:
> >>> Hi Janelle,
> >>>
> >>> Am 04.10.2015 um 19:25 schrieb Janelle:
>  Just wondering if anyone knows why this happens from time to
> time on
>  servers:
> 
>  $ kinit admin
>  kinit: Clients credentials have been revoked while getting initial
>  credentials
> 
>  there are no failed logins to the admin account - not even any
> login
>  attempts, so it is not like someone is getting the account
> locked out.
>  Just curious if anyone else has seen in. With 16 masters, it occurs
>  randomly on some hosts, but eventually clears either on its own
> or with
>  a restart of IPA. However, I just restarted IPA on this server and
>  after
>  about 2-3 minutes it works again.
> 
> >>> I am seeing the same, see my mail "kinit admin not working anymore
> >>> (LOCKED_OUT: Clients credentials have been revoked)" from 03-SEPT.
> >>> Actually, wasn't it you who wanted to open a ticket?
> >>>
> >>> Have a nice evening,
> >>>
> >>>Torsten
> >>>
> >> When you see this run `ipa user-status admin` and `ipa pwpolicy-show
> >> --user=admin` and provide that so we can potentially see what is
> going
> >> on.
> >>
> >> rob
> >>
> > I am curious -- if you have 16 masters, but this only happens once in
> > awhile on 1 or 2 servers, how does the pwpolicy fit in? I am trying to
> > understand the thinking of where you are going?? I will for sure
> do this
> > the next time it happens, but I want to understand logic?
> 
> Lockout is per-master because the failed auth count and successful login
> date is not replicated due to performance issues.
> 
> The user-status command will collect the lockout attributes from each
> server, but it doesn't do the calculations, so the pwpolicy is needed as
> well in order to figure out whether on a given master the user is locked
> out.
> 
> 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
> 
> 

-- 
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] Cannot connect to FreeIPA web UI anymore

2015-10-05 Thread Fujisan

I just noticed I can log in to the web UI with user admin and his password.

But when I try to configure firefox to use kerberos, I click on "Install
Kerberos Configuration Firefox Extension" button, a message appears saying
"Firefox prevented this site from asking you to install software on your
computer", so I click on the "Allow" button and then another message
appears "The add-on downloaded from this site could not be installed
because it appears to be corrupt.".

And the ipa commands are still not working.
$ ipa user-show admin
ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json': Unauthorized


On Mon, Oct 5, 2015 at 12:13 PM, Fujisan  wrote:

> I uninstalled the ipa server and reinstalled it. Then restored the backup.
> And then the following:
>
> $ keyctl list @s
> 3 keys in keyring:
> 437165764: --alswrv 0 65534 keyring: _uid.0
> 556579409: --alswrv 0 0 user:
> ipa_session_cookie:host/zaira2.opera@OPERA
> 286806445: ---lswrv 0 65534 keyring: _persistent.0
> $ keyctl purge 556579409
> purged 0 keys
> $ keyctl reap
> 0 keys reaped
> $ ipa user-show admin
> ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json':
> Unauthorized
> $ keyctl list @s
> 3 keys in keyring:
> 437165764: --alswrv 0 65534 keyring: _uid.0
> 556579409: --alswrv 0 0 user:
> ipa_session_cookie:host/zaira2.opera@OPERA
> 286806445: ---lswrv 0 65534 keyring: _persistent.0
>
> It doesn't seem to purge or to reap.
>
>
>
> On Mon, Oct 5, 2015 at 9:17 AM, Fujisan  wrote:
>
>> Good morning,
>> 
>> Any suggestion what I should do?
>>
>> I still have
>>
>> $ ipa user-show admin
>> ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json':
>> Unauthorized
>>
>>
>> Regards.
>>
>>
>> On Fri, Oct 2, 2015 at 5:04 PM, Fujisan  wrote:
>>
>>> I only have this:
>>>
>>> $ keyctl list @s
>>> 1 key in keyring:
>>> 641467419: --alswrv 0 65534 keyring: _uid.0
>>> $
>>>
>>>
>>>
>>> On Fri, Oct 2, 2015 at 5:01 PM, Alexander Bokovoy 
>>> wrote:
>>>
 On Fri, 02 Oct 2015, Fujisan wrote:

> I forgot to mention that
>
> $ ipa user-show admin
> ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json':
> Unauthorized
>
 This is most likely because of the cached session to your server.

 You can check if  keyctl list @s
 returns you something like
 [root@m1 ~]# keyctl list @s
 2 keys in keyring:
 496745412: --alswrv 0 65534 keyring: _uid.0
 215779962: --alswrv 0 0 user:
 ipa_session_cookie:ad...@example.com

 If so, then notice the key number (215779962) for the session cookie,
 and do:
  keyctl purge 215779962
  keyctl reap

 This should make a next 'ipa ...' command run to ask for new cookie.


> On Fri, Oct 2, 2015 at 4:44 PM, Fujisan  wrote:
>
> I still cannot login to the web UI.
>>
>> Here is what I did:
>>
>>1. mv /etc/krb5.keytab /etc/krb5.keytab.save
>>2. kinit admin
>>Password for admin@OPERA:
>>3. ipa-getkeytab -s zaira2.opera -p host/zaira2.opera@OPERA -k
>>/etc/krb5.keytab
>>4. systemctl restart sssd.service
>>5. mv /etc/httpd/conf/ipa.keytab /etc/httpd/conf/ipa.keytab.save
>>6. ipa-getkeytab -s zaira2.opera -p HTTP/zaira2.opera@OPERA -k
>>/etc/httpd/conf/ipa.keytab
>>7. systemctl restart httpd.service
>>
>>
>> The log says now:
>>
>> Oct 02 16:40:56 zaira2.opera krb5kdc[9065](info): AS_REQ (9 etypes
>> {18 17
>> 16 23 25 26 1 3 2}) 10.0.21.18: NEEDED_PREAUTH:
>> HTTP/zaira2.opera@OPERA
>> for krbtgt/OPERA@OPERA, Additional pre-authentication required
>>
>>
>>
>> On Fri, Oct 2, 2015 at 4:25 PM, Alexander Bokovoy <
>> aboko...@redhat.com>
>> wrote:
>>
>> On Fri, 02 Oct 2015, Fujisan wrote:
>>>
>>> Well, I think I messed up when trying to configure cockpit to use
 kerberos.

 What should I do to fix this?

 I have this on the ipa server:
 $ klist -k
 Keytab name: FILE:/etc/krb5.keytab
 KVNO Principal
 


 --
   2 host/zaira2.opera@OPERA
   2 host/zaira2.opera@OPERA
   2 host/zaira2.opera@OPERA
   2 host/zaira2.opera@OPERA
   1 nfs/zaira2.opera@OPERA
   1 nfs/zaira2.opera@OPERA
   1 nfs/zaira2.opera@OPERA
   1 nfs/zaira2.opera@OPERA
   3 HTTP/zaira2.opera@OPERA
   3 HTTP/zaira2.opera@OPERA
   3 HTTP/zaira2.opera@OPERA
   3 HTTP/zaira2.opera@OPERA

 You can start by:

>>> 0. backup every file mentioned below
>>> 1. Move /etc/krb5.keytab somewhere
>>> 2. kinit as admin
>>> 3. ipa-getkeytab -s

Re: [Freeipa-users] re-initialize replica

2015-10-05 Thread Martin Kosek

On 10/02/2015 06:00 PM, Andrew E. Bruno wrote:
> On Fri, Oct 02, 2015 at 09:56:47AM -0400, Andrew E. Bruno wrote:
>> What's the best way to re-initialize a replica? 
>>
>> Suppose one of your replicas goes south.. is there a command to tell
>> that replicate to re-initialize from the first master (instead of
>> removing/re-adding the replica from the topology)?
> 
> Found the command I was looking for:
>ipa-replica-manage re-initialize --from xxx
> 
> However, one of our replicates is down and can't seem to re-initialize
> it. Starting ipa fails (via systemctl restart ipa):
> 
> ipactl status
> Directory Service: RUNNING
> krb5kdc Service: STOPPED
> kadmin Service: STOPPED
> named Service: STOPPED
> ipa_memcached Service: STOPPED
> httpd Service: STOPPED
> pki-tomcatd Service: STOPPED
> ipa-otpd Service: STOPPED
> ipa: INFO: The ipactl command was successful
> 
> 
> Errors from the dirsrv show:
> 
> : GSSAPI Error: Unspecified GSS failure.  Minor code may provide more 
> information (No Kerberos credentials available)) errno 0 (Success)
> [02/Oct/2015:11:45:05 -0400] slapi_ldap_bind - Error: could not perform 
> interactive bind for id [] authentication mechanism [GSSAPI]: error -2 (Local 
> error)
> [02/Oct/2015:11:50:05 -0400] set_krb5_creds - Could not get initial 
> credentials for principal [ldap/server@realm] in keytab 
> [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for 
> requested realm)
> [02/Oct/2015:11:50:05 -0400] slapd_ldap_sasl_interactive_bind - Error: could 
> not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 (Local 
> error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  
> Minor code may provide more information (No Kerberos credentials available)) 
> errno 0 (Success)
> [02/Oct/2015:11:50:05 -0400] slapi_ldap_bind - Error: could not perform 
> interactive bind for id [] authentication mechanism [GSSAPI]: error -2 (Local 
> error)
> 
> 
> Attempting to re-initialize fails:
> 
> ipa-replica-manage re-initialize --from master
> Connection timed out.
> 
> 
> I verified time is in sync and DNS forward/reverse resolution is working.
> 
> Any pointers on what else to try?
> 
> Thanks!
> 
> --Andrew

Given that your Kerberos server instance is down, I would start investigating
Kerberos logs to see why.

-- 
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] Cannot connect to FreeIPA web UI anymore

2015-10-05 Thread Fujisan

It is actually on the ipa server that ipa commands are not working. On ipa
clients, I do not have errors.



On Mon, Oct 5, 2015 at 12:27 PM, Fujisan  wrote:

> I just noticed I can log in to the web UI with user admin and his password.
>
> But when I try to configure firefox to use kerberos, I click on "Install
> Kerberos Configuration Firefox Extension" button, a message appears saying
> "Firefox prevented this site from asking you to install software on your
> computer", so I click on the "Allow" button and then another message
> appears "The add-on downloaded from this site could not be installed
> because it appears to be corrupt.".
>
> And the ipa commands are still not working.
> $ ipa user-show admin
> ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json':
> Unauthorized
>
>
> On Mon, Oct 5, 2015 at 12:13 PM, Fujisan  wrote:
>
>> I uninstalled the ipa server and reinstalled it. Then restored the backup.
>> And then the following:
>>
>> $ keyctl list @s
>> 3 keys in keyring:
>> 437165764: --alswrv 0 65534 keyring: _uid.0
>> 556579409: --alswrv 0 0 user:
>> ipa_session_cookie:host/zaira2.opera@OPERA
>> 286806445: ---lswrv 0 65534 keyring: _persistent.0
>> $ keyctl purge 556579409
>> purged 0 keys
>> $ keyctl reap
>> 0 keys reaped
>> $ ipa user-show admin
>> ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json':
>> Unauthorized
>> $ keyctl list @s
>> 3 keys in keyring:
>> 437165764: --alswrv 0 65534 keyring: _uid.0
>> 556579409: --alswrv 0 0 user:
>> ipa_session_cookie:host/zaira2.opera@OPERA
>> 286806445: ---lswrv 0 65534 keyring: _persistent.0
>>
>> It doesn't seem to purge or to reap.
>>
>>
>>
>> On Mon, Oct 5, 2015 at 9:17 AM, Fujisan  wrote:
>>
>>> Good morning,
>>> 
>>> Any suggestion what I should do?
>>>
>>> I still have
>>>
>>> $ ipa user-show admin
>>> ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json':
>>> Unauthorized
>>>
>>>
>>> Regards.
>>>
>>>
>>> On Fri, Oct 2, 2015 at 5:04 PM, Fujisan  wrote:
>>>
 I only have this:

 $ keyctl list @s
 1 key in keyring:
 641467419: --alswrv 0 65534 keyring: _uid.0
 $



 On Fri, Oct 2, 2015 at 5:01 PM, Alexander Bokovoy 
 wrote:

> On Fri, 02 Oct 2015, Fujisan wrote:
>
>> I forgot to mention that
>>
>> $ ipa user-show admin
>> ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json':
>> Unauthorized
>>
> This is most likely because of the cached session to your server.
>
> You can check if  keyctl list @s
> returns you something like
> [root@m1 ~]# keyctl list @s
> 2 keys in keyring:
> 496745412: --alswrv 0 65534 keyring: _uid.0
> 215779962: --alswrv 0 0 user:
> ipa_session_cookie:ad...@example.com
>
> If so, then notice the key number (215779962) for the session cookie,
> and do:
>  keyctl purge 215779962
>  keyctl reap
>
> This should make a next 'ipa ...' command run to ask for new cookie.
>
>
>> On Fri, Oct 2, 2015 at 4:44 PM, Fujisan  wrote:
>>
>> I still cannot login to the web UI.
>>>
>>> Here is what I did:
>>>
>>>1. mv /etc/krb5.keytab /etc/krb5.keytab.save
>>>2. kinit admin
>>>Password for admin@OPERA:
>>>3. ipa-getkeytab -s zaira2.opera -p host/zaira2.opera@OPERA -k
>>>/etc/krb5.keytab
>>>4. systemctl restart sssd.service
>>>5. mv /etc/httpd/conf/ipa.keytab /etc/httpd/conf/ipa.keytab.save
>>>6. ipa-getkeytab -s zaira2.opera -p HTTP/zaira2.opera@OPERA -k
>>>/etc/httpd/conf/ipa.keytab
>>>7. systemctl restart httpd.service
>>>
>>>
>>> The log says now:
>>>
>>> Oct 02 16:40:56 zaira2.opera krb5kdc[9065](info): AS_REQ (9 etypes
>>> {18 17
>>> 16 23 25 26 1 3 2}) 10.0.21.18: NEEDED_PREAUTH:
>>> HTTP/zaira2.opera@OPERA
>>> for krbtgt/OPERA@OPERA, Additional pre-authentication required
>>>
>>>
>>>
>>> On Fri, Oct 2, 2015 at 4:25 PM, Alexander Bokovoy <
>>> aboko...@redhat.com>
>>> wrote:
>>>
>>> On Fri, 02 Oct 2015, Fujisan wrote:

 Well, I think I messed up when trying to configure cockpit to use
> kerberos.
>
> What should I do to fix this?
>
> I have this on the ipa server:
> $ klist -k
> Keytab name: FILE:/etc/krb5.keytab
> KVNO Principal
> 
>
>
> --
>   2 host/zaira2.opera@OPERA
>   2 host/zaira2.opera@OPERA
>   2 host/zaira2.opera@OPERA
>   2 host/zaira2.opera@OPERA
>   1 nfs/zaira2.opera@OPERA
>   1 nfs/zaira2.opera@OPERA
>   1 nfs/zaira2.opera@OPERA
>   1

Re: [Freeipa-users] ssh and sudo password authentication not working with freeipa-client 3.3.4-0ubuntu3.1 on Ubuntu 14.04

2015-10-05 Thread Sumit Bose

On Mon, Oct 05, 2015 at 09:00:13AM +0200, Alexander Skwar wrote:
> Hi
> 
> Hm, there's nothing at all in the /var/log/sssd/krb5_child.log when I try
> to login with SSH and enter a password.

Can you try to increase the debug_level to 0xFFF0?

> 
> kinit doesn't work.
> 
> $ kinit -k
> kinit: Permission denied while getting initial credentials
> 
> For this test, I was root and then did a "su - user" and then "kinit -k".
> Also after the "kinit -k", nothing is in the krb5_child.log.

The 'kinit -k' has to be done as root. It will only check if the client
can connect to the KDC at all and tries to get a TGT for the host.

It's expected that during this operation nothing is added to the SSSD
logs because the kinit utility work independent of SSSD.

bye,
Sumit

> 
> Regards,
> Alexander
> 
> 
> 2015-10-02 17:59 GMT+02:00 Jakub Hrozek :
> 
> > On Fri, Oct 02, 2015 at 04:28:57PM +0200, Alexander Skwar wrote:
> > > Hello
> > >
> > > How do I get password authentication to work with freeipa-client
> > > 3.3.4-0ubuntu3.1 on Ubuntu 14.04 for ssh and sudo?
> > >
> > > Long version follows :)
> > >
> > > We've got an IPA server with the Red Hat Identity Management server
> > > on RHEL 7.1 servers; FreeIPA v4.1.0 is being used there. I configured
> > > users and groups there and would now like to login with SSH. When I
> > > store a SSH key for the user account, I can login just fine, using
> > > this SSH key. But I'd like/need to use passwords as well. And sudo
> > > also doesn't work, when it's asking for passwords - I supposed,
> > > it's the same root cause.
> > >
> > > Let's stick with SSH.
> > >
> > > Initially, I installed the FreeIPA client with this command line:
> > >
> > > ipa-client-install --force-join --mkhomedir --ssh-trust-dns \
> > >   --enable-dns-updates --unattended \
> > >   --principal=admin --password=correctone \
> > >   --domain=customer.company.internal \
> > >   --server=auth01.customer.company.internal
> > >
> > > I then try to do a SSH login with:
> > >
> > > ssh -l ewt@customer.company.internal 192.168.229.143
> > > or:
> > > ssh -l ewt 192.168.229.143
> > >
> > > Password authentication doesn't work.
> > >
> > > In the /var/log/syslog on the system where I try to login, I find this:
> > >
> > > 2015-10-02T15:33:38.771291+02:00 mgmt02 [sssd[krb5_child[14154]]]:
> > > Key table entry not found
> > >
> > > After having turned up the debug level of the sssd with "sssd -i -f -d
> > > 0x0770 --debug-timestamps=1", I find the following in the system log
> > > files:
> > >
> > > 2015-10-02T15:40:48.756399+02:00 mgmt02 sshd[14194]:
> > > pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0
> > > tty=ssh ruser= rhost=212.71.117.1  user=ewt
> > > 2015-10-02T15:40:48.775896+02:00 mgmt02 sshd[14194]:
> > > pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0
> > > tty=ssh ruser= rhost=212.71.117.1 user=ewt
> > > 2015-10-02T15:40:48.775927+02:00 mgmt02 sshd[14194]:
> > > pam_sss(sshd:auth): received for user ewt: 4 (System error)
> > > 2015-10-02T15:40:50.988591+02:00 mgmt02 sshd[14194]: Failed
> > > password for ewt from 212.71.117.1 port 58136 ssh2
> > >
> > > TBH, I don't quite understand it. Anyway, in
> > > /var/log/sssd/sssd_customer.company.internal.log I noticed:
> > >
> > > (Fri Oct  2 15:46:26 2015) [sssd[be[customer.company.internal]]]
> > > [read_pipe_handler] (0x0400): EOF received, client finished
> > > (Fri Oct  2 15:46:26 2015) [sssd[be[customer.company.internal]]]
> > > [parse_krb5_child_response] (0x0020): message too short.
> > > (Fri Oct  2 15:46:26 2015) [sssd[be[customer.company.internal]]]
> > > [krb5_auth_done] (0x0040): Could not parse child response [22]:
> > > Invalid argument
> > > (Fri Oct  2 15:46:26 2015) [sssd[be[customer.company.internal]]]
> > > [ipa_auth_handler_done] (0x0040): krb5_auth_recv request failed.
> > >
> > > Well… What am I doing wrong or what might I have forgotten?
> >
> > We need to also see the krb5_child.log but please check if the keytab is
> > correct (ie kinit -k works).
> >
> > --
> > 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
> >
> 
> 
> 
> -- 
> 
> 
> Alexander
> -- 
> =>*Google+* => http://plus.skwar.me <==
> => *Chat* (Jabber/Google Talk) => a.sk...@gmail.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

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

2015-10-05 Thread Andreas Calminder


All right,
Thanks a million!

/andreas

On 10/05/2015 11:29 AM, Pavel Březina wrote:

On 10/05/2015 10:58 AM, Andreas Calminder wrote:

Hi,
guessing this is a quite frequent question, but I can't find any solid
information about the topic.
I want to specify a set of default sudo options so I don't have to
specify these options for every other sudo rule I create.
There's supposed to be a magic "defaults" rule.
This old document
(https://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf) 
suggests

it's cn=defaults,ou=sudorules,dc=example,dc=com which doesn't exist in
my ipa 4.1 installation others suggest it's under
ou=sudoers,dc=example,dc=com when poking around in ldap it looks like it
could also be cn=sudorules,cn=sudo,dc=example,dc=com, but there is no
way to be sure. Also, might it be as simple as create a defaults rule in
the webui or cli with the default options set or is this a ldapmodify
action?


Hi,
just create a sudo rule named "defaults" through ipa cli or wui.


--
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 3.3 performance issues with many hosts

2015-10-05 Thread Dominik Korittki




Am 01.10.2015 um 21:52 schrieb Rob Crittenden:

Dominik Korittki wrote:

Hello folks,

I am running two FreeIPA Servers with around 100 users and around 15.000
hosts, which are used by users to login via ssh. The FreeIPA servers
(which are Centos 7.0) ran good for a while, but as more and more hosts
got migrated to serve as FreeIPA hosts, it started to get slow and
unstable.

For example, its hard to maintain hostgroups, which have more than 1.000
hosts. The ipa host-* commands are getting slower as the hostgroup
grows. Is this normal?


You mean the ipa hostgroup-* commands? Whenever the entry is displayed
(show and add) it needs to dereference all members so yes, it is
understandable that it gets somewhat slower with more members. How slow
are we talking about?


We also experience random dirsrv segfaults. Here's a dmesg line from the
latest:

[690787.647261] traps: ns-slapd[5217] general protection ip:7f8d6b6d6bc1
sp:7f8d3aff2a88 error:0 in libc-2.17.so[7f8d6b65+1b6000]


You probably want to start here:
http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes


A stacktrace from the latest crash is attached to this email. After 
restarting the service, this is what I get in 
/var/log/dirsrv/slapd-INTERNAL/errors (hostname is ipa01.internal):


[05/Oct/2015:13:51:30 +0200] - slapd started.  Listening on All 
Interfaces port 389 for LDAP requests
[05/Oct/2015:13:51:30 +0200] - Listening on All Interfaces port 636 for 
LDAPS requests
[05/Oct/2015:13:51:30 +0200] - Listening on 
/var/run/slapd-INTERNAL.socket for LDAPI requests
[05/Oct/2015:13:51:30 +0200] slapd_ldap_sasl_interactive_bind - Error: 
could not perform interactive bind for id [] mech [GSSAPI]: LDAP error 
-2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified 
GSS failure.  Minor code may provide more information (No Kerberos 
credentials available)) errno 0 (Success)
[05/Oct/2015:13:51:30 +0200] slapi_ldap_bind - Error: could not perform 
interactive bind for id [] authentication mechanism [GSSAPI]: error -2 
(Local error)
[05/Oct/2015:13:51:30 +0200] NSMMReplicationPlugin - 
agmt="cn=meToipa02.internal" (ipa02:389): Replication bind with GSSAPI 
auth failed: LDAP error -2 (Local error) (SASL(-1): generic failure: 
GSSAPI Error: Unspecified GSS failure.  Minor code may provide more 
information (No Kerberos credentials available))
[05/Oct/2015:13:51:30 +0200] NSMMReplicationPlugin - changelog program - 
agmt="cn=masterAgreement1-ipa02.internal-pki-tomcat" (ipa02:389): CSN 
54bea4800060 not found, we aren't as up to date, or we purged
[05/Oct/2015:13:51:30 +0200] NSMMReplicationPlugin - 
agmt="cn=masterAgreement1-ipa02.internal-pki-tomcat" (ipa02:389): Data 
required to update replica has been purged. The replica must be 
reinitialized.
[05/Oct/2015:13:51:30 +0200] NSMMReplicationPlugin - 
agmt="cn=masterAgreement1-ipa02.internal-pki-tomcat" (ipa02:389): 
Incremental update failed and requires administrator action
[05/Oct/2015:13:51:33 +0200] NSMMReplicationPlugin - 
agmt="cn=meToipa02.internal" (ipa02:389): Replication bind with GSSAPI 
auth resumed



These lines are present since a replayed a ldif dump from ipa02 to 
ipa01, but i didn't think that it related to the segfault problem 
(therefore i said there are no related problems in the logfile).


But I am starting to believe that these errors could be in relation to 
each other.



Kind regards,
Dominik Korittki






Nothing in /var/log/dirsrv/slapd-INTERNAL/errors, which relates to the
problem.


Not sure about that anymore.


I'm thinking about migrating to latest CentOS 7 FreeIPA 4, but does that
solve my problems?

FreeIPA server version is 3.3.3-28.el7.centos
389-ds-base.x86_64 is 1.3.1.6-26.el7_0



Kind regards,
Dominik Korittki






GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-64.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /usr/sbin/ns-slapd...Reading symbols from 
/usr/lib/debug/usr/sbin/ns-slapd.debug...done.
done.
[New LWP 28096]
[New LWP 28100]
[New LWP 28074]
[New LWP 28109]
[New LWP 28098]
[New LWP 27931]
[New LWP 28079]
[New LWP 28073]
[New LWP 28103]
[New LWP 28077]
[New LWP 28076]
[New LWP 28101]
[New LWP 27930]
[New LWP 28071]
[New LWP 28084]
[New LWP 28075]
[New LWP 28102]
[New LWP 27928]
[New LWP 28121]
[New LWP 28086]
[New LWP 28099]
[New LWP 28092]
[New LWP 28094]
[New LWP 28104]
[New LWP 28091]
[New LWP 27929]
[New LWP 28106]
[New LWP 28088]
[New LWP 28081]
[New LWP 28082]
[New LWP 28090]
[New LWP 28095]
[New LWP 28083]
[New LWP 28085]
[New LWP 28108]
[New LWP 28089]
[New LWP 28093]
[New LWP 28078]
[New LWP

Re: [Freeipa-users] Cannot connect to FreeIPA web UI anymore

2015-10-05 Thread Fujisan

I uninstalled the ipa server and reinstalled it. Then restored the backup.
And then the following:

$ keyctl list @s
3 keys in keyring:
437165764: --alswrv 0 65534 keyring: _uid.0
556579409: --alswrv 0 0 user:
ipa_session_cookie:host/zaira2.opera@OPERA
286806445: ---lswrv 0 65534 keyring: _persistent.0
$ keyctl purge 556579409
purged 0 keys
$ keyctl reap
0 keys reaped
$ ipa user-show admin
ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json': Unauthorized
$ keyctl list @s
3 keys in keyring:
437165764: --alswrv 0 65534 keyring: _uid.0
556579409: --alswrv 0 0 user:
ipa_session_cookie:host/zaira2.opera@OPERA
286806445: ---lswrv 0 65534 keyring: _persistent.0

It doesn't seem to purge or to reap.



On Mon, Oct 5, 2015 at 9:17 AM, Fujisan  wrote:

> Good morning,
> 
> Any suggestion what I should do?
>
> I still have
>
> $ ipa user-show admin
> ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json':
> Unauthorized
>
>
> Regards.
>
>
> On Fri, Oct 2, 2015 at 5:04 PM, Fujisan  wrote:
>
>> I only have this:
>>
>> $ keyctl list @s
>> 1 key in keyring:
>> 641467419: --alswrv 0 65534 keyring: _uid.0
>> $
>>
>>
>>
>> On Fri, Oct 2, 2015 at 5:01 PM, Alexander Bokovoy 
>> wrote:
>>
>>> On Fri, 02 Oct 2015, Fujisan wrote:
>>>
 I forgot to mention that

 $ ipa user-show admin
 ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json':
 Unauthorized

>>> This is most likely because of the cached session to your server.
>>>
>>> You can check if  keyctl list @s
>>> returns you something like
>>> [root@m1 ~]# keyctl list @s
>>> 2 keys in keyring:
>>> 496745412: --alswrv 0 65534 keyring: _uid.0
>>> 215779962: --alswrv 0 0 user:
>>> ipa_session_cookie:ad...@example.com
>>>
>>> If so, then notice the key number (215779962) for the session cookie,
>>> and do:
>>>  keyctl purge 215779962
>>>  keyctl reap
>>>
>>> This should make a next 'ipa ...' command run to ask for new cookie.
>>>
>>>
 On Fri, Oct 2, 2015 at 4:44 PM, Fujisan  wrote:

 I still cannot login to the web UI.
>
> Here is what I did:
>
>1. mv /etc/krb5.keytab /etc/krb5.keytab.save
>2. kinit admin
>Password for admin@OPERA:
>3. ipa-getkeytab -s zaira2.opera -p host/zaira2.opera@OPERA -k
>/etc/krb5.keytab
>4. systemctl restart sssd.service
>5. mv /etc/httpd/conf/ipa.keytab /etc/httpd/conf/ipa.keytab.save
>6. ipa-getkeytab -s zaira2.opera -p HTTP/zaira2.opera@OPERA -k
>/etc/httpd/conf/ipa.keytab
>7. systemctl restart httpd.service
>
>
> The log says now:
>
> Oct 02 16:40:56 zaira2.opera krb5kdc[9065](info): AS_REQ (9 etypes {18
> 17
> 16 23 25 26 1 3 2}) 10.0.21.18: NEEDED_PREAUTH:
> HTTP/zaira2.opera@OPERA
> for krbtgt/OPERA@OPERA, Additional pre-authentication required
>
>
>
> On Fri, Oct 2, 2015 at 4:25 PM, Alexander Bokovoy  >
> wrote:
>
> On Fri, 02 Oct 2015, Fujisan wrote:
>>
>> Well, I think I messed up when trying to configure cockpit to use
>>> kerberos.
>>>
>>> What should I do to fix this?
>>>
>>> I have this on the ipa server:
>>> $ klist -k
>>> Keytab name: FILE:/etc/krb5.keytab
>>> KVNO Principal
>>> 
>>>
>>>
>>> --
>>>   2 host/zaira2.opera@OPERA
>>>   2 host/zaira2.opera@OPERA
>>>   2 host/zaira2.opera@OPERA
>>>   2 host/zaira2.opera@OPERA
>>>   1 nfs/zaira2.opera@OPERA
>>>   1 nfs/zaira2.opera@OPERA
>>>   1 nfs/zaira2.opera@OPERA
>>>   1 nfs/zaira2.opera@OPERA
>>>   3 HTTP/zaira2.opera@OPERA
>>>   3 HTTP/zaira2.opera@OPERA
>>>   3 HTTP/zaira2.opera@OPERA
>>>   3 HTTP/zaira2.opera@OPERA
>>>
>>> You can start by:
>>>
>> 0. backup every file mentioned below
>> 1. Move /etc/krb5.keytab somewhere
>> 2. kinit as admin
>> 3. ipa-getkeytab -s `hostname` -p host/`hostname` -k /etc/krb5.keytab
>> 4. restart SSSD
>> 5. Move /etc/httpd/conf/ipa.keytab somewhere
>> 6. ipa-getkeytab -s `hostname` -p HTTP/`hostname` -k
>> /etc/httpd/conf/ipa.keytab
>> 7. Restart httpd
>>
>> Every time you run 'ipa-getkeytab', Kerberos key for the service
>> specified by you is replaced on the server side so that keys in the
>> keytabs become unusable.
>>
>> I guess cockpit instructions were for something that was not supposed
>> to
>> run on IPA master. On IPA master there are already all needed services
>> (host/ and HTTP/) and their keytabs are in place.
>>
>>
>>
>> On Fri, Oct 2, 2015 at 3:45 PM, Alexander Bokovoy <
>>> aboko...@redhat.com>
>>> wrote:
>>>
>>> On Fri, 02 Oct 2015, Fujisan wrote:
>>>

Re: [Freeipa-users] FreeIPA 3.3 performance issues with many hosts

2015-10-05 Thread Tomas Babej

On 10/01/2015 05:06 PM, Dominik Korittki wrote:
> Hello folks,
> 
> I am running two FreeIPA Servers with around 100 users and around 15.000
> hosts, which are used by users to login via ssh. The FreeIPA servers
> (which are Centos 7.0) ran good for a while, but as more and more hosts
> got migrated to serve as FreeIPA hosts, it started to get slow and
> unstable.
> 
> For example, its hard to maintain hostgroups, which have more than 1.000
> hosts. The ipa host-* commands are getting slower as the hostgroup
> grows. Is this normal?
> We also experience random dirsrv segfaults. Here's a dmesg line from the
> latest:
> 
> [690787.647261] traps: ns-slapd[5217] general protection ip:7f8d6b6d6bc1
> sp:7f8d3aff2a88 error:0 in libc-2.17.so[7f8d6b65+1b6000]
> 
> Nothing in /var/log/dirsrv/slapd-INTERNAL/errors, which relates to the
> problem.
> I'm thinking about migrating to latest CentOS 7 FreeIPA 4, but does that
> solve my problems?
> 
> FreeIPA server version is 3.3.3-28.el7.centos
> 389-ds-base.x86_64 is 1.3.1.6-26.el7_0
> 
> 
> 
> Kind regards,
> Dominik Korittki
> 


Hi Dominik,

performance issues are a known problem, there has been some work to
improve the performance with respect to large groups:

11bd9d96f191066f7ba760549f00179c128a9787
efcd48ad01a39a67f131a2cea9d5477164fb

These improvements are in FreeIPA 4.2 only, however, which has not been
released for CentOS7 as of now. You may try to play with FreeIPA 4.2 on
Fedora, see https://copr.fedoraproject.org/coprs/mkosek/freeipa-4.2/.

HTH,
Tomas

-- 
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 and sudo password authentication not working with freeipa-client 3.3.4-0ubuntu3.1 on Ubuntu 14.04

2015-10-05 Thread Alexander Skwar

Hi

Hm, when I'm root, "kinit -k" works:

# kinit -k
#

Just not as a user. As a user, I get the "kinit: Permission denied while
getting initial credentials" error message.

Regards,
Alexander



2015-10-05 9:00 GMT+02:00 Alexander Skwar <
alexanders.mailinglists+nos...@gmail.com>:

> Hi
>
> Hm, there's nothing at all in the /var/log/sssd/krb5_child.log when I try
> to login with SSH and enter a password.
>
> kinit doesn't work.
>
> $ kinit -k
> kinit: Permission denied while getting initial credentials
>
> For this test, I was root and then did a "su - user" and then "kinit -k".
> Also after the "kinit -k", nothing is in the krb5_child.log.
>
> Regards,
> Alexander
>
>
> 2015-10-02 17:59 GMT+02:00 Jakub Hrozek :
>
>> On Fri, Oct 02, 2015 at 04:28:57PM +0200, Alexander Skwar wrote:
>> > Hello
>> >
>> > How do I get password authentication to work with freeipa-client
>> > 3.3.4-0ubuntu3.1 on Ubuntu 14.04 for ssh and sudo?
>> >
>> > Long version follows :)
>> >
>> > We've got an IPA server with the Red Hat Identity Management server
>> > on RHEL 7.1 servers; FreeIPA v4.1.0 is being used there. I configured
>> > users and groups there and would now like to login with SSH. When I
>> > store a SSH key for the user account, I can login just fine, using
>> > this SSH key. But I'd like/need to use passwords as well. And sudo
>> > also doesn't work, when it's asking for passwords - I supposed,
>> > it's the same root cause.
>> >
>> > Let's stick with SSH.
>> >
>> > Initially, I installed the FreeIPA client with this command line:
>> >
>> > ipa-client-install --force-join --mkhomedir --ssh-trust-dns \
>> >   --enable-dns-updates --unattended \
>> >   --principal=admin --password=correctone \
>> >   --domain=customer.company.internal \
>> >   --server=auth01.customer.company.internal
>> >
>> > I then try to do a SSH login with:
>> >
>> > ssh -l ewt@customer.company.internal 192.168.229.143
>> > or:
>> > ssh -l ewt 192.168.229.143
>> >
>> > Password authentication doesn't work.
>> >
>> > In the /var/log/syslog on the system where I try to login, I find this:
>> >
>> > 2015-10-02T15:33:38.771291+02:00 mgmt02 [sssd[krb5_child[14154]]]:
>> > Key table entry not found
>> >
>> > After having turned up the debug level of the sssd with "sssd -i -f -d
>> > 0x0770 --debug-timestamps=1", I find the following in the system log
>> > files:
>> >
>> > 2015-10-02T15:40:48.756399+02:00 mgmt02 sshd[14194]:
>> > pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0
>> > tty=ssh ruser= rhost=212.71.117.1  user=ewt
>> > 2015-10-02T15:40:48.775896+02:00 mgmt02 sshd[14194]:
>> > pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0
>> > tty=ssh ruser= rhost=212.71.117.1 user=ewt
>> > 2015-10-02T15:40:48.775927+02:00 mgmt02 sshd[14194]:
>> > pam_sss(sshd:auth): received for user ewt: 4 (System error)
>> > 2015-10-02T15:40:50.988591+02:00 mgmt02 sshd[14194]: Failed
>> > password for ewt from 212.71.117.1 port 58136 ssh2
>> >
>> > TBH, I don't quite understand it. Anyway, in
>> > /var/log/sssd/sssd_customer.company.internal.log I noticed:
>> >
>> > (Fri Oct  2 15:46:26 2015) [sssd[be[customer.company.internal]]]
>> > [read_pipe_handler] (0x0400): EOF received, client finished
>> > (Fri Oct  2 15:46:26 2015) [sssd[be[customer.company.internal]]]
>> > [parse_krb5_child_response] (0x0020): message too short.
>> > (Fri Oct  2 15:46:26 2015) [sssd[be[customer.company.internal]]]
>> > [krb5_auth_done] (0x0040): Could not parse child response [22]:
>> > Invalid argument
>> > (Fri Oct  2 15:46:26 2015) [sssd[be[customer.company.internal]]]
>> > [ipa_auth_handler_done] (0x0040): krb5_auth_recv request failed.
>> >
>> > Well… What am I doing wrong or what might I have forgotten?
>>
>> We need to also see the krb5_child.log but please check if the keytab is
>> correct (ie kinit -k works).
>>
>> --
>> 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
>>
>
>
>
> --
>
>
> Alexander
> --
> =>*Google+* => http://plus.skwar.me <==
> => *Chat* (Jabber/Google Talk) => a.sk...@gmail.com <==
>
>
>


-- 


Alexander
-- 
=>*Google+* => http://plus.skwar.me <==
=> *Chat* (Jabber/Google Talk) => a.sk...@gmail.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] SUDO does not always works on first try

2015-10-05 Thread Zoske, Fabian

Dear Jakub,

I found only the following entries in the /var/log/auth.log:

Oct  5 11:57:38 hl-srv10 sudo: pam_unix(sudo:auth): conversation failed
Oct  5 11:57:38 hl-srv10 sudo: pam_unix(sudo:auth): auth could not identify 
password for [f.zo...@de.eu.local]
Oct  5 11:57:38 hl-srv10 sudo: pam_sss(sudo:auth): authentication failure; 
logname=f.zo...@de.eu.local uid=1948403038 euid=0 tty=/dev/pts/1 
ruser=f.zo...@de.eu.local rhost= user=f.zo...@de.eu.local
Oct  5 11:57:38 hl-srv10 sudo: pam_sss(sudo:auth): received for user 
f.zo...@de.eu.local: 7 (Authentication failure)
Oct  5 11:57:38 hl-srv10 sudo: f.zo...@de.eu.local : user NOT authorized on 
host ; TTY=pts/1 ; PWD=/home/de.eu.local/f.zoske ; USER=root ; COMMAND=/bin/cat 
/etc/sssd/sssd.conf
Oct  5 11:57:42 hl-srv10 sudo: pam_unix(sudo:auth): authentication failure; 
logname=f.zo...@de.eu.local uid=1948403038 euid=0 tty=/dev/pts/1 
ruser=f.zo...@de.eu.local rhost=  user=f.zo...@de.eu.local
Oct  5 11:57:42 hl-srv10 sudo: pam_sss(sudo:auth): authentication success; 
logname=f.zo...@de.eu.local uid=1948403038 euid=0 tty=/dev/pts/1 
ruser=f.zo...@de.eu.local rhost= user=f.zo...@de.eu.local
Oct  5 11:57:43 hl-srv10 sudo: f.zo...@de.eu.local : user NOT authorized on 
host ; TTY=pts/1 ; PWD=/home/de.eu.local/f.zoske ; USER=root ; COMMAND=/bin/bash
Oct  5 11:57:46 hl-srv10 sudo: pam_unix(sudo:auth): authentication failure; 
logname=f.zo...@de.eu.local uid=1948403038 euid=0 tty=/dev/pts/1 
ruser=f.zo...@de.eu.local rhost=  user=f.zo...@de.eu.local
Oct  5 11:57:47 hl-srv10 sudo: pam_sss(sudo:auth): authentication success; 
logname=f.zo...@de.eu.local uid=1948403038 euid=0 tty=/dev/pts/1 
ruser=f.zo...@de.eu.local rhost= user=f.zo...@de.eu.local
Oct  5 11:57:47 hl-srv10 sudo: f.zo...@de.eu.local : TTY=pts/1 ; 
PWD=/home/de.eu.local/f.zoske ; USER=root ; COMMAND=/bin/bash
Oct  5 11:57:47 hl-srv10 sudo: pam_unix(sudo:session): session opened for user 
root by f.zo...@de.eu.local(uid=0)

In /var/log/sssd/ no entries were logged.

My sssd.conf:
[domain/ipa-lx.com]

cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = ipa-lx.com
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = hl-srv10.ipa-lx.com
chpass_provider = ipa
ipa_server = _srv_, dc01.ipa-lx.com
ldap_tls_cacert = /etc/ipa/ca.crt
ldap_sudo_use_host_filter = false

[sssd]
services = nss, pam, ssh, sudo
config_file_version = 2
default_domain_suffix = de.eu.local
domains = ei-ag.it

[nss]
override_shell = /bin/bash

[pam]

[sudo]

[autofs]

[ssh]

[pac]


Best regards,
Fabian
-- 
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] Cannot connect to FreeIPA web UI anymore

2015-10-05 Thread Fujisan

I was going to ask about the ipa command error on the ipa server and how to
fix it. But then I just tried again and it works.

$ ipa user-show admin
  User login: admin
  Last name: Administrator
  Home directory: /home/zaira/admin
  Login shell: /bin/bash
  UID: 1000
  GID: 1000
  Account disabled: False
  Password: True
  Member of groups: stagiaires, opera, ipausers, trust admins, admins,
oldstaff
  Kerberos keys available: True
  SSH public key fingerprint:
FA:76:85:EF:2A:D1:12:B9:A8:A4:F4:AE:45:B2:63:05 admin@ipasrv (ssh-dss)

Before trying again, I just ran a 'dnf update' and rebooted the server on
the new kernel (4.1.8-200.fc22.x86_64).

On Mon, Oct 5, 2015 at 4:07 PM, Petr Vobornik  wrote:

> On 10/05/2015 12:55 PM, Fujisan wrote:
>
>> It is actually on the ipa server that ipa commands are not working. On ipa
>> clients, I do not have errors.
>>
>>
>>
>> On Mon, Oct 5, 2015 at 12:27 PM, Fujisan  wrote:
>>
>> I just noticed I can log in to the web UI with user admin and his
>>> password.
>>>
>>> But when I try to configure firefox to use kerberos, I click on "Install
>>> Kerberos Configuration Firefox Extension" button, a message appears
>>> saying
>>> "Firefox prevented this site from asking you to install software on your
>>> computer", so I click on the "Allow" button and then another message
>>> appears "The add-on downloaded from this site could not be installed
>>> because it appears to be corrupt.".
>>>
>>
> Here you hit https://fedorahosted.org/freeipa/ticket/4906
>
> Fix(will be in 4.2.2 release) for this ticket changes the procedure for
> new versions of Firefox to a manual configuration. Basically the steps for
> Firefox which are described on page
> http://your-ipa.example.test/ipa/config/ssbrowser.html
>
>
>
>>> And the ipa commands are still not working.
>>> $ ipa user-show admin
>>> ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json':
>>> Unauthorized
>>>
>>>
>>> On Mon, Oct 5, 2015 at 12:13 PM, Fujisan  wrote:
>>>
>>> I uninstalled the ipa server and reinstalled it. Then restored the
 backup.
 And then the following:

 $ keyctl list @s
 3 keys in keyring:
 437165764: --alswrv 0 65534 keyring: _uid.0
 556579409: --alswrv 0 0 user:
 ipa_session_cookie:host/zaira2.opera@OPERA
 286806445: ---lswrv 0 65534 keyring: _persistent.0
 $ keyctl purge 556579409
 purged 0 keys
 $ keyctl reap
 0 keys reaped
 $ ipa user-show admin
 ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json':
 Unauthorized
 $ keyctl list @s
 3 keys in keyring:
 437165764: --alswrv 0 65534 keyring: _uid.0
 556579409: --alswrv 0 0 user:
 ipa_session_cookie:host/zaira2.opera@OPERA
 286806445: ---lswrv 0 65534 keyring: _persistent.0

 It doesn't seem to purge or to reap.



 On Mon, Oct 5, 2015 at 9:17 AM, Fujisan  wrote:

 Good morning,
> 
> Any suggestion what I should do?
>
> I still have
>
> $ ipa user-show admin
> ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json':
> Unauthorized
>
>
> Regards.
>
>
> On Fri, Oct 2, 2015 at 5:04 PM, Fujisan  wrote:
>
> I only have this:
>>
>> $ keyctl list @s
>> 1 key in keyring:
>> 641467419: --alswrv 0 65534 keyring: _uid.0
>> $
>>
>>
>>
>> On Fri, Oct 2, 2015 at 5:01 PM, Alexander Bokovoy <
>> aboko...@redhat.com>
>> wrote:
>>
>> On Fri, 02 Oct 2015, Fujisan wrote:
>>>
>>> I forgot to mention that

 $ ipa user-show admin
 ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json':
 Unauthorized

 This is most likely because of the cached session to your server.
>>>
>>> You can check if  keyctl list @s
>>> returns you something like
>>> [root@m1 ~]# keyctl list @s
>>> 2 keys in keyring:
>>> 496745412: --alswrv 0 65534 keyring: _uid.0
>>> 215779962: --alswrv 0 0 user:
>>> ipa_session_cookie:ad...@example.com
>>>
>>> If so, then notice the key number (215779962) for the session cookie,
>>> and do:
>>>   keyctl purge 215779962
>>>   keyctl reap
>>>
>>> This should make a next 'ipa ...' command run to ask for new cookie.
>>>
>>>
>>> On Fri, Oct 2, 2015 at 4:44 PM, Fujisan  wrote:

 I still cannot login to the web UI.

>
> Here is what I did:
>
> 1. mv /etc/krb5.keytab /etc/krb5.keytab.save
> 2. kinit admin
> Password for admin@OPERA:
> 3. ipa-getkeytab -s zaira2.opera -p host/zaira2.opera@OPERA -k
> /etc/krb5.keytab
> 4. systemctl restart sssd.service
> 5. mv /etc/httpd/conf/ipa.keytab
>

Re: [Freeipa-users] Cannot connect to FreeIPA web UI anymore

2015-10-05 Thread Petr Vobornik


On 10/05/2015 12:55 PM, Fujisan wrote:

It is actually on the ipa server that ipa commands are not working. On ipa
clients, I do not have errors.



On Mon, Oct 5, 2015 at 12:27 PM, Fujisan  wrote:


I just noticed I can log in to the web UI with user admin and his password.

But when I try to configure firefox to use kerberos, I click on "Install
Kerberos Configuration Firefox Extension" button, a message appears saying
"Firefox prevented this site from asking you to install software on your
computer", so I click on the "Allow" button and then another message
appears "The add-on downloaded from this site could not be installed
because it appears to be corrupt.".


Here you hit https://fedorahosted.org/freeipa/ticket/4906

Fix(will be in 4.2.2 release) for this ticket changes the procedure for 
new versions of Firefox to a manual configuration. Basically the steps 
for Firefox which are described on page 
http://your-ipa.example.test/ipa/config/ssbrowser.html




And the ipa commands are still not working.
$ ipa user-show admin
ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json':
Unauthorized


On Mon, Oct 5, 2015 at 12:13 PM, Fujisan  wrote:


I uninstalled the ipa server and reinstalled it. Then restored the backup.
And then the following:

$ keyctl list @s
3 keys in keyring:
437165764: --alswrv 0 65534 keyring: _uid.0
556579409: --alswrv 0 0 user:
ipa_session_cookie:host/zaira2.opera@OPERA
286806445: ---lswrv 0 65534 keyring: _persistent.0
$ keyctl purge 556579409
purged 0 keys
$ keyctl reap
0 keys reaped
$ ipa user-show admin
ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json':
Unauthorized
$ keyctl list @s
3 keys in keyring:
437165764: --alswrv 0 65534 keyring: _uid.0
556579409: --alswrv 0 0 user:
ipa_session_cookie:host/zaira2.opera@OPERA
286806445: ---lswrv 0 65534 keyring: _persistent.0

It doesn't seem to purge or to reap.



On Mon, Oct 5, 2015 at 9:17 AM, Fujisan  wrote:


Good morning,

Any suggestion what I should do?

I still have

$ ipa user-show admin
ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json':
Unauthorized


Regards.


On Fri, Oct 2, 2015 at 5:04 PM, Fujisan  wrote:


I only have this:

$ keyctl list @s
1 key in keyring:
641467419: --alswrv 0 65534 keyring: _uid.0
$



On Fri, Oct 2, 2015 at 5:01 PM, Alexander Bokovoy 
wrote:


On Fri, 02 Oct 2015, Fujisan wrote:


I forgot to mention that

$ ipa user-show admin
ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json':
Unauthorized


This is most likely because of the cached session to your server.

You can check if  keyctl list @s
returns you something like
[root@m1 ~]# keyctl list @s
2 keys in keyring:
496745412: --alswrv 0 65534 keyring: _uid.0
215779962: --alswrv 0 0 user:
ipa_session_cookie:ad...@example.com

If so, then notice the key number (215779962) for the session cookie,
and do:
  keyctl purge 215779962
  keyctl reap

This should make a next 'ipa ...' command run to ask for new cookie.



On Fri, Oct 2, 2015 at 4:44 PM, Fujisan  wrote:

I still cannot login to the web UI.


Here is what I did:

1. mv /etc/krb5.keytab /etc/krb5.keytab.save
2. kinit admin
Password for admin@OPERA:
3. ipa-getkeytab -s zaira2.opera -p host/zaira2.opera@OPERA -k
/etc/krb5.keytab
4. systemctl restart sssd.service
5. mv /etc/httpd/conf/ipa.keytab /etc/httpd/conf/ipa.keytab.save
6. ipa-getkeytab -s zaira2.opera -p HTTP/zaira2.opera@OPERA -k
/etc/httpd/conf/ipa.keytab
7. systemctl restart httpd.service


The log says now:

Oct 02 16:40:56 zaira2.opera krb5kdc[9065](info): AS_REQ (9 etypes
{18 17
16 23 25 26 1 3 2}) 10.0.21.18: NEEDED_PREAUTH:
HTTP/zaira2.opera@OPERA
for krbtgt/OPERA@OPERA, Additional pre-authentication required



On Fri, Oct 2, 2015 at 4:25 PM, Alexander Bokovoy <
aboko...@redhat.com>
wrote:

On Fri, 02 Oct 2015, Fujisan wrote:


Well, I think I messed up when trying to configure cockpit to use

kerberos.

What should I do to fix this?

I have this on the ipa server:
$ klist -k
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal



--
   2 host/zaira2.opera@OPERA
   2 host/zaira2.opera@OPERA
   2 host/zaira2.opera@OPERA
   2 host/zaira2.opera@OPERA
   1 nfs/zaira2.opera@OPERA
   1 nfs/zaira2.opera@OPERA
   1 nfs/zaira2.opera@OPERA
   1 nfs/zaira2.opera@OPERA
   3 HTTP/zaira2.opera@OPERA
   3 HTTP/zaira2.opera@OPERA
   3 HTTP/zaira2.opera@OPERA
   3 HTTP/zaira2.opera@OPERA

You can start by:


0. backup every file mentioned below
1. Move /etc/krb5.keytab somewhere
2. kinit as admin
3. ipa-getkeytab -s `hostname` -p host/`hostname` -k
/etc/krb5.keytab
4. restart SSSD
5. Move /etc/httpd/conf/ipa.keytab somewhere
6. ipa-getkeytab -s `hostname` -p HTTP/`hostname` -k
/etc/httpd/conf/ipa.keytab
7. Restart

Re: [Freeipa-users] admin loses access?

2015-10-05 Thread Rob Crittenden

Torsten Harenberg wrote:
> Hi Janelle,
> 
> Am 04.10.2015 um 19:25 schrieb Janelle:
>> Just wondering if anyone knows why this happens from time to time on
>> servers:
>>
>> $ kinit admin
>> kinit: Clients credentials have been revoked while getting initial
>> credentials
>>
>> there are no failed logins to the admin account - not even any login
>> attempts, so it is not like someone is getting the account locked out. 
>> Just curious if anyone else has seen in. With 16 masters, it occurs
>> randomly on some hosts, but eventually clears either on its own or with
>> a restart of IPA. However, I just restarted IPA on this server and after
>> about 2-3 minutes it works again.
>>
> 
> I am seeing the same, see my mail "kinit admin not working anymore
> (LOCKED_OUT: Clients credentials have been revoked)" from 03-SEPT.
> Actually, wasn't it you who wanted to open a ticket?
> 
> Have a nice evening,
> 
>   Torsten
> 

When you see this run `ipa user-status admin` and `ipa pwpolicy-show
--user=admin` and provide that so we can potentially see what is going on.

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] admin loses access?

2015-10-05 Thread Janelle


On 10/5/15 7:39 AM, Rob Crittenden wrote:

Torsten Harenberg wrote:

Hi Janelle,

Am 04.10.2015 um 19:25 schrieb Janelle:

Just wondering if anyone knows why this happens from time to time on
servers:

$ kinit admin
kinit: Clients credentials have been revoked while getting initial
credentials

there are no failed logins to the admin account - not even any login
attempts, so it is not like someone is getting the account locked out.
Just curious if anyone else has seen in. With 16 masters, it occurs
randomly on some hosts, but eventually clears either on its own or with
a restart of IPA. However, I just restarted IPA on this server and after
about 2-3 minutes it works again.


I am seeing the same, see my mail "kinit admin not working anymore
(LOCKED_OUT: Clients credentials have been revoked)" from 03-SEPT.
Actually, wasn't it you who wanted to open a ticket?

Have a nice evening,

   Torsten


When you see this run `ipa user-status admin` and `ipa pwpolicy-show
--user=admin` and provide that so we can potentially see what is going on.

rob

I am curious -- if you have 16 masters, but this only happens once in 
awhile on 1 or 2 servers, how does the pwpolicy fit in? I am trying to 
understand the thinking of where you are going?? I will for sure do this 
the next time it happens, but I want to understand logic?


thank you
~Janelle

--
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] admin loses access?

2015-10-05 Thread Rob Crittenden

Janelle wrote:
> On 10/5/15 7:39 AM, Rob Crittenden wrote:
>> Torsten Harenberg wrote:
>>> Hi Janelle,
>>>
>>> Am 04.10.2015 um 19:25 schrieb Janelle:
 Just wondering if anyone knows why this happens from time to time on
 servers:

 $ kinit admin
 kinit: Clients credentials have been revoked while getting initial
 credentials

 there are no failed logins to the admin account - not even any login
 attempts, so it is not like someone is getting the account locked out.
 Just curious if anyone else has seen in. With 16 masters, it occurs
 randomly on some hosts, but eventually clears either on its own or with
 a restart of IPA. However, I just restarted IPA on this server and
 after
 about 2-3 minutes it works again.

>>> I am seeing the same, see my mail "kinit admin not working anymore
>>> (LOCKED_OUT: Clients credentials have been revoked)" from 03-SEPT.
>>> Actually, wasn't it you who wanted to open a ticket?
>>>
>>> Have a nice evening,
>>>
>>>Torsten
>>>
>> When you see this run `ipa user-status admin` and `ipa pwpolicy-show
>> --user=admin` and provide that so we can potentially see what is going
>> on.
>>
>> rob
>>
> I am curious -- if you have 16 masters, but this only happens once in
> awhile on 1 or 2 servers, how does the pwpolicy fit in? I am trying to
> understand the thinking of where you are going?? I will for sure do this
> the next time it happens, but I want to understand logic?

Lockout is per-master because the failed auth count and successful login
date is not replicated due to performance issues.

The user-status command will collect the lockout attributes from each
server, but it doesn't do the calculations, so the pwpolicy is needed as
well in order to figure out whether on a given master the user is locked
out.

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

[Freeipa-users] More replication fun

2015-10-05 Thread Janelle


So here is a fun question -- how is this possible?

from ipa-replica-manage list-ruv

ipa002.example.com 389  6
ipa003.example.com 389  30   <-  Huh???
ipa003.example.com 389  33   <-
ipa004.example.com 389  24

~Janelle

--
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] More replication fun

2015-10-05 Thread Simo Sorce


On 05/10/15 11:11, Janelle wrote:

So here is a fun question -- how is this possible?

from ipa-replica-manage list-ruv

ipa002.example.com 389  6
ipa003.example.com 389  30   <-  Huh???
ipa003.example.com 389  33   <-
ipa004.example.com 389  24


ipa003 was reinstalled but the RUV was not properly cleaned

Simo.


--
Simo Sorce * Red Hat, Inc * New York

--
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] re-initialize replica

Re: [Freeipa-users] More replication fun

Re: [Freeipa-users] More replication fun

Re: [Freeipa-users] re-initialize replica

Re: [Freeipa-users] AD Cross Realm Trust + AIX

Re: [Freeipa-users] Cannot connect to FreeIPA web UI anymore

Re: [Freeipa-users] DNS forwarding configuration randomly breaks and stops working

Re: [Freeipa-users] ssh and sudo password authentication not working with freeipa-client 3.3.4-0ubuntu3.1 on Ubuntu 14.04

Re: [Freeipa-users] Sudo default options

Re: [Freeipa-users] admin loses access?

[Freeipa-users] separating authoritative servers from recursive servers

Re: [Freeipa-users] DNS forwarding configuration randomly breaks and stops working

Re: [Freeipa-users] DNS forwarding configuration randomly breaks and stops working

Re: [Freeipa-users] admin loses access?

Re: [Freeipa-users] Cannot connect to FreeIPA web UI anymore

Re: [Freeipa-users] re-initialize replica

Re: [Freeipa-users] Cannot connect to FreeIPA web UI anymore

Re: [Freeipa-users] ssh and sudo password authentication not working with freeipa-client 3.3.4-0ubuntu3.1 on Ubuntu 14.04

Re: [Freeipa-users] Sudo default options

Re: [Freeipa-users] FreeIPA 3.3 performance issues with many hosts

Re: [Freeipa-users] Cannot connect to FreeIPA web UI anymore

Re: [Freeipa-users] FreeIPA 3.3 performance issues with many hosts

Re: [Freeipa-users] ssh and sudo password authentication not working with freeipa-client 3.3.4-0ubuntu3.1 on Ubuntu 14.04

Re: [Freeipa-users] SUDO does not always works on first try

Re: [Freeipa-users] Cannot connect to FreeIPA web UI anymore

Re: [Freeipa-users] Cannot connect to FreeIPA web UI anymore

Re: [Freeipa-users] admin loses access?

Re: [Freeipa-users] admin loses access?

Re: [Freeipa-users] admin loses access?

[Freeipa-users] More replication fun

Re: [Freeipa-users] More replication fun

31 matches

Site Navigation

Mail list logo

Footer information