Re: [Freeipa-users] Free ipa Configurations

[Martin Kosek]

On 11/12/2014 04:09 AM, Rolf Nufable wrote:
> I have another question, well I've achieved the state where I can't log in to 
> my admin account in the server side, it happens because I'm changing the time 
> of the server machine. 
> 
> but the time is really wrong. and I disabled NTP and the server has no access 
> to the internet. 
> 
> these are my network configurations. 
> 
> peerdns = no 
> ipaddr  = 192.168.1.1
> netmask = 255.255.255.0
> dns1 = 192.168.1.1
> onboot = yes 
> 
> as you can see I've made the server also the dns1, (is this correct though ? 
> i really don't know ) 
> 
> feel free to correct my network config 
> 
> And another problem is that I need to sync my freeipa server time to the 
> right time zone? if thats the case then I do need internet connection for my 
> Freeipa server , so that it could access ntp servers right?  ( or am I wrong? 
> ) 

Yes, internet connection helps. Theoretically you could just set up the time
manually on your FreeIPA server and then let your clients synchronize their
time with it as NTP is running there, but that may be cumbersome.

> 
> still this is a great breakthrough for my work 
> 
> Now what to do? 

FreeIPA server and the KDC do not care about the time zone, it works with UTC
time anyway, AFAIK. You just simply need to have the time synchronized on all
your servers and clients or Kerberos protocol will not work.

> ps. Martin attached is the krb5kdc.log after I changed the time of the 
> server.  Httpd error log didnt changed at all after I tried to access the web 
> UI and tried to log in.. 

I saw no error there...

> 
> 
> TIA 
> 
> 
> 
> On Tuesday, November 11, 2014 7:10 PM, Petr Vobornik  
> wrote:
>  
> 
> 
> On 11.11.2014 11:11, Jakub Hrozek wrote:
>> On Tue, Nov 11, 2014 at 02:07:57AM -0800, Rolf Nufable wrote:
>>> well I'm trying to setup sudo in my client machine, also I want to access 
>>> the server web browser In the client machine ( is it possible though ? )
>>>
>>> well I'm having this error in the client side when using the command su - ( 
>>> user )
>>>
>>> su - u...@example.com
>>>
>>> su : u...@example.com does not exist.
>>
>> Are you sure ipa-client-install did run successfully on that machine?
>>
>> Can you unenroll and enroll the client back so that we start from an
>> sssd.conf that is created by the tooling?
>>
>> As Martin said, you don't need those sudo-related config options with
>> recent SSSD releases, they wouldn't work in the sudo section anyway.
> 
> Does:
> 
> $ id u...@example.com
> 
> return you the user info?
> 
> if not and ipa-client-install was run successfully before, check 
> nsswitch.conf if it has sssd configured (sss next to various providers).
> 
> if not run:
> $ authconfig --enablesssd --update
> 
> if it doesn't help, try to run:
> $ authconfig --disablesssd --update
> $ authconfig --enablesssd --update
> 
> if it helps, please tell me. I'm curious if you suffer from one issue I 
> experienced.
> 
> 
> 
>>
>>>
>>>
>>>
>>> On Tuesday, November 11, 2014 5:56 PM, Martin Kosek  
>>> wrote:
>>>
>>>
>>>
>>> It is still really hard to give advise as I do not know what's actually 
>>> wrong.
>>> So are you trying to set up a sudo on your client or are you trying to log 
>>> in
>>> with your client browser to FreeIPA server? These are 2 orthogonal actions.
>>>
>>> Who gives the "Can't I connect to the ipa server" error? As I said earlier, 
>>> I
>>> cannot help you without described procedure you are trying to do, logs and
>>> exact error messages.
>>>
>>> Martin
>>>
>>>
>>> On 11/11/2014 09:32 AM, Rolf Nufable wrote:
 never mind the problem on the server side, somehow it got fixed , I really 
 don't know how though

 so in the client side , It is successful when installing free ipa client 
 and the
>>>   server discovery is fine, my freipa Client is 4.1.0 and my server is 
>>> 4.0.3 (although somewhere I've read that version incompatibility would not 
>>> be an issue since if either one is of a lower version, the only features 
>>> that would be used is the one that the lower version can do )

 So I really don't know why Can't I connect to the ipa server.

 Iptables works fine.
 /etc/resolv.conf is file as well

 sssd/sssd.conf ( added these lines )
 [sudo]
 sudo_provider = ldap
 ldap_uri = ldap://myipaserver.example.com
 ldap_sudo_search_base = ou=sudoers,dc=example,dc=com
 ldap_sasl_mech = GSSAPI
 ldap_sasl_authid = host/myipaserver.example.com
 ldap_sasl_realm = EXAMPLE.COM
 krb_server = myipaserver.example.com


 and /etc/nsswitch.conf
 (added this line )

 sudoers : files sss ldap

 is there something missing ?



 On Tuesday, November 11, 2014 3:45 PM, Rolf Nufable 
  wrote:



 oh sorry I forgot that on the clients side " 
 network.negotiate-auth.trusted-uris " they have the same domain as of the 
 server side I've configured it as well as in 

Re: [Freeipa-users] strange error deleting replica?

[Martin Kosek]

Adding freeipa-users list back. Would the ipa.strace log below then tell which
name resolution fail?

On 11/11/2014 05:36 PM, Janelle wrote:
> On all the systems, besides being in DNS (external server) they are all in 
> /etc/hosts, so not sure why that would error.
> But indeed they all resolve in DNS as well.
> 
> Hmm..
> ~J
>> Martin Kosek 
>> November 11, 2014 at 3:01 AM
>>
>> This is usually DNS resolution error, though the command should not crash 
>> this 
>> way.
>>
>> Does follow resolution work?
>>
>> $ host `hostname`
>> $ host kermit.xyzzy.com
>>
>> Alternatively, if you are not sure which DNS resolution fails, we could look 
>> at
>> strace output:
>>
>> $ strace -o ipa.strace ipa-replica-manage del kermit.xyzzy.com --force
>>
>> That would create a log caled ipa.strace with all system calls of
>> ipa-replica-manage del command and we would see which DNS resolution failed.
>>
>> Martin
> 

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

Re: [Freeipa-users] how to overcome same serial number in cert issue on different master servers?

[Les Stott]

> -Original Message-
> From: Rob Crittenden [mailto:rcrit...@redhat.com]
> Sent: Wednesday, 12 November 2014 6:33 AM
> To: Fraser Tweedale; Les Stott
> Cc: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] how to overcome same serial number in cert
> issue on different master servers?
> 
> Fraser Tweedale wrote:
> > On Tue, Nov 11, 2014 at 04:17:37AM +, Les Stott wrote:
> >>> -Original Message-
> >>> From: Fraser Tweedale [mailto:ftwee...@redhat.com]
> >>> Sent: Tuesday, 11 November 2014 1:59 PM
> >>> To: Les Stott
> >>> Cc: freeipa-users@redhat.com
> >>> Subject: Re: [Freeipa-users] how to overcome same serial number in
> >>> cert issue on different master servers?
> >>>
> >>> On Tue, Nov 11, 2014 at 02:11:55AM +, Les Stott wrote:
> > -Original Message-
> > From: Fraser Tweedale [mailto:ftwee...@redhat.com]
> > Sent: Tuesday, 11 November 2014 12:51 PM
> > To: Les Stott
> > Cc: freeipa-users@redhat.com
> > Subject: Re: [Freeipa-users] how to overcome same serial number in
> > cert issue on different master servers?
> >
> > On Tue, Nov 11, 2014 at 01:40:50AM +, Les Stott wrote:
> >> Hi,
> >>
> >> I have a standard rhel6 deployment for FreeIPA in two
> environments.
> >>
> >> One environment is in our Production Data Center, The Other in
> >> our DR
> > Data Center.
> >>
> >> Both environments are setup with the same domain
> (mydomain.com)
> >> for
> > FreeIPA. This is to support dr/failover etc.
> >>
> >> In each environment, there is a master. In Prod its
> >> serverA.mydomain.com,
> > In DR its serverB.mydomain.com.
> >>
> >> The master in each environment gets a generated certificate by
> >> IPA. This
> > certificate shows a Serial Number of "0A"
> >>
> >> My problem is that because the certificates have the same
> >> Organization,
> > OU and Serial Number, I can only browse to one of them (using
> Firefox).
> >>
> >> If I browse to https://serverA.mydomain.com/ipa/ui/ and accept
> >> the
> > certificate it works fine.
> >> If I then try to browse to https://serverB.mydomain.com/ipa/ui/
> >> it comes
> > up with the following error:
> >>
> >> "Your certificate contains the same serial number as another
> >> certificate
> > issued by the certificate authority. Please get a new certificate
> > containing a unique serial number. (Error code:
> >>> sec_error_reused_issuer_and_serial)"
> >>
> >> If I remove the stored browser certificate for serverA, then
> >> browse to
> > serverB, and accept the certificate, it works, but then the "same
> > serial number" error pops up for browsing serverA.
> >>
> >> Note: both environments were built separately and are not linked
> >> in
> > anyway (no replication between prod/dr).
> >>
> >> Is there a way to generate unique serial numbers for the masters?
> >>
> >> Thanks in advance,
> >>
> >> Les
> >>
> >>
> >>
> > Hi Les,
> >
> > Ideally, you should prevent this situation by using different
> > common names
> > (CN) for your CAs and server certifications across the different
> > environments.  If this is not possible, you can configure the
> > Dogtag CA to use random serial numbers:
> >
> >
> >>>
> http://dogtagpki.org/wiki/Random_Certificate_Serial_Numbers#How_to_U
> > se_Random_Certificate_Serial_Numbers
> >
> > This does not guarantee that you will not get serial number
> > collisions, but reduces the likelihood.
> >
> 
>  Thanks for the quick reply.
> 
>  In this case the common name is different between both
> environments.
>  In prod the master was serverA, in DR the master was serverB. It
>  just happened that way. So having a different CommonName doesn't
> help.
> 
> >>> Do the CA certificates bear the same commonName?  This is probably
> >>> what Firefox uses to determine if there are serial number collisions.
> >>>
> >>
> >> It appears so.
> >>
> >> The certificate for the CA on the master serverA shows:
> >>
> >> Issued To
> >> Common Name (CN) serverA.mydomain.com Organization (O)
> mydomain.com
> >> Organizational Unit (OU)  Serial Number 0A
> >> Issued By:
> >> Common Name (CN) Certificate Authority Organization (O)
> mydomain.com
> >> Organizational Unit (OU) 
> >>
> >> The certificate for the CA on the master serverB shows:
> >>
> >> Issued To
> >> Common Name (CN) serverB.mydomain.com Organization (O)
> mydomain.com
> >> Organizational Unit (OU)  Serial Number 0A
> >> Issued By:
> >> Common Name (CN) Certificate Authority Organization (O)
> mydomain.com
> >> Organizational Unit (OU) 
> >>
> >>
> >> Shouldn't the Common Name of the CA be different? Or is it the same in
> order to make CA replication easier?
> >>
> > Both environments were probably set up with the same CN for the CA
> > 

Re: [Freeipa-users] Centos IPA Client fails after upgrade to 6.6

[Michael Lasevich]

Sending you logs directly. Thanks.

-M

On 11/11/14, 5:33 AM, Jakub Hrozek wrote:
> On Mon, Nov 10, 2014 at 09:29:04AM -0800, Michael Lasevich wrote:
>> I can certainly try, it would need to be compatible with CentOS 6.6 though.
>>
>> -M
> Thank you very much, can you try these packages?
>
> Please note they wouldn't fix your problem, but will hopefully shed some
> more light on what's going on:
> https://jhrozek.fedorapeople.org/sssd-test-builds/krb5-ccache-debugging/
>
>>> So according to the logs, the create_ccache() function failed.
>> Unfortunately,
>> we don't do very good job at logging the failures there..
>>> Michael, are you able to run a custom package with extra debugging? It
>> would help us pinpoint which line actually is failing.
>>> Thanks a lot for providing the logs!

-- 
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] strange DS errors trying to tune...

[Alexander Bokovoy]

On Tue, 11 Nov 2014, Janelle wrote:
In this case it is the exact password and it worked in the first line 
but not in the second.


Now to make things even more strange -- I have 8 replicas -- and 3 of 
them show this problem, the others do not -- WOW..

cn=config subtree is not replicated in FreeIPA, thus if you have
different passwords for Directory Manager (they are stored in
cn=config), this must be a problem local to a replica, not a replication
issue.

Perhaps some script or a person changed the directory manager's
password?

For the record, the password is stored in nsslapd-rootpw attribute of
cn=config:

dn: cn=config
nsslapd-rootdn: cn=Directory Manager
nsslapd-rootpw: {SSHA}some-hash-value

You can check the content of /etc/dirsrv/slapd-INSTANCE/dse.ldif
directly. Do not change the file while directory server is running as
your changes will be overridden.

--
/ Alexander Bokovoy

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

Re: [Freeipa-users] strange DS errors trying to tune...

[Rich Megginson]

On 11/11/2014 12:33 PM, Janelle wrote:
In this case it is the exact password and it worked in the first line 
but not in the second.


Now to make things even more strange -- I have 8 replicas -- and 3 of 
them show this problem, the others do not -- WOW..


My brain is going to explode today. :-)


Yeah, sorry, I have no idea.  Please let us know if you figure it out.



~J


Rich Megginson 
November 11, 2014 at 10:39 AM
On 11/11/2014 11:30 AM, Janelle wrote:

Hi all..

I continue to come up with strange and unusual problems. Here is a 
new one - use the dbmon.sh script and trying to tune the dbcache...


This is on a replica BTW

First -- THIS WORKS:

INCR=60 BINDDN="cn=directory manager" BINDPW="asecret" VERBOSE=2 
dbmon.sh


and I see all the info I need, BUT - now I want to tune it and get: 
(HOW CAN THIS BE?!?!)


# ldapmodify -x -D "cn=directory manager" -w asecret < dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config
> changetype: modify
> replace: nsslapd-cachememsize
> nsslapd-cachememsize: 8589934592
> EOF
ldap_bind: Invalid credentials (49)


Is asecret the literal password?  If not, does it contain spaces or 
other shell metacharacters that need to be quoted or escaped?




Thanks
~J





Janelle 
November 11, 2014 at 10:30 AM
Hi all..

I continue to come up with strange and unusual problems. Here is a 
new one - use the dbmon.sh script and trying to tune the dbcache...


This is on a replica BTW

First -- THIS WORKS:

INCR=60 BINDDN="cn=directory manager" BINDPW="asecret" VERBOSE=2 dbmon.sh

and I see all the info I need, BUT - now I want to tune it and get: 
(HOW CAN THIS BE?!?!)


# ldapmodify -x -D "cn=directory manager" -w asecret < dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config
> changetype: modify
> replace: nsslapd-cachememsize
> nsslapd-cachememsize: 8589934592
> EOF
ldap_bind: Invalid credentials (49)

Thanks
~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] strange DS errors trying to tune...

[Janelle]

In this case it is the exact password and it worked in the first line 
but not in the second.


Now to make things even more strange -- I have 8 replicas -- and 3 of 
them show this problem, the others do not -- WOW..


My brain is going to explode today. :-)

~J


Rich Megginson 
November 11, 2014 at 10:39 AM
On 11/11/2014 11:30 AM, Janelle wrote:

Hi all..

I continue to come up with strange and unusual problems. Here is a 
new one - use the dbmon.sh script and trying to tune the dbcache...


This is on a replica BTW

First -- THIS WORKS:

INCR=60 BINDDN="cn=directory manager" BINDPW="asecret"  VERBOSE=2 
dbmon.sh


and I see all the info I need, BUT - now I want to tune it and get: 
(HOW CAN THIS BE?!?!)


# ldapmodify -x -D "cn=directory manager" -w asecret < dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config
> changetype: modify
> replace: nsslapd-cachememsize
> nsslapd-cachememsize: 8589934592
> EOF
ldap_bind: Invalid credentials (49)


Is asecret the literal password?  If not, does it contain spaces or 
other shell metacharacters that need to be quoted or escaped?




Thanks
~J





Janelle 
November 11, 2014 at 10:30 AM
Hi all..

I continue to come up with strange and unusual problems. Here is a new 
one - use the dbmon.sh script and trying to tune the dbcache...


This is on a replica BTW

First -- THIS WORKS:

INCR=60 BINDDN="cn=directory manager" BINDPW="asecret"  VERBOSE=2 dbmon.sh

and I see all the info I need, BUT - now I want to tune it and get: 
(HOW CAN THIS BE?!?!)


# ldapmodify -x -D "cn=directory manager" -w asecret < dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config
> changetype: modify
> replace: nsslapd-cachememsize
> nsslapd-cachememsize: 8589934592
> EOF
ldap_bind: Invalid credentials (49)

Thanks
~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] how to overcome same serial number in cert issue on different master servers?

[Rob Crittenden]

Fraser Tweedale wrote:
> On Tue, Nov 11, 2014 at 04:17:37AM +, Les Stott wrote:
>>> -Original Message-
>>> From: Fraser Tweedale [mailto:ftwee...@redhat.com]
>>> Sent: Tuesday, 11 November 2014 1:59 PM
>>> To: Les Stott
>>> Cc: freeipa-users@redhat.com
>>> Subject: Re: [Freeipa-users] how to overcome same serial number in cert
>>> issue on different master servers?
>>>
>>> On Tue, Nov 11, 2014 at 02:11:55AM +, Les Stott wrote:
> -Original Message-
> From: Fraser Tweedale [mailto:ftwee...@redhat.com]
> Sent: Tuesday, 11 November 2014 12:51 PM
> To: Les Stott
> Cc: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] how to overcome same serial number in
> cert issue on different master servers?
>
> On Tue, Nov 11, 2014 at 01:40:50AM +, Les Stott wrote:
>> Hi,
>>
>> I have a standard rhel6 deployment for FreeIPA in two environments.
>>
>> One environment is in our Production Data Center, The Other in our
>> DR
> Data Center.
>>
>> Both environments are setup with the same domain (mydomain.com)
>> for
> FreeIPA. This is to support dr/failover etc.
>>
>> In each environment, there is a master. In Prod its
>> serverA.mydomain.com,
> In DR its serverB.mydomain.com.
>>
>> The master in each environment gets a generated certificate by
>> IPA. This
> certificate shows a Serial Number of "0A"
>>
>> My problem is that because the certificates have the same
>> Organization,
> OU and Serial Number, I can only browse to one of them (using Firefox).
>>
>> If I browse to https://serverA.mydomain.com/ipa/ui/ and accept the
> certificate it works fine.
>> If I then try to browse to https://serverB.mydomain.com/ipa/ui/ it
>> comes
> up with the following error:
>>
>> "Your certificate contains the same serial number as another
>> certificate
> issued by the certificate authority. Please get a new certificate
> containing a unique serial number. (Error code:
>>> sec_error_reused_issuer_and_serial)"
>>
>> If I remove the stored browser certificate for serverA, then
>> browse to
> serverB, and accept the certificate, it works, but then the "same
> serial number" error pops up for browsing serverA.
>>
>> Note: both environments were built separately and are not linked
>> in
> anyway (no replication between prod/dr).
>>
>> Is there a way to generate unique serial numbers for the masters?
>>
>> Thanks in advance,
>>
>> Les
>>
>>
>>
> Hi Les,
>
> Ideally, you should prevent this situation by using different common
> names
> (CN) for your CAs and server certifications across the different
> environments.  If this is not possible, you can configure the Dogtag
> CA to use random serial numbers:
>
>
>>> http://dogtagpki.org/wiki/Random_Certificate_Serial_Numbers#How_to_U
> se_Random_Certificate_Serial_Numbers
>
> This does not guarantee that you will not get serial number
> collisions, but reduces the likelihood.
>

 Thanks for the quick reply.

 In this case the common name is different between both environments.
 In prod the master was serverA, in DR the master was serverB. It just
 happened that way. So having a different CommonName doesn't help.

>>> Do the CA certificates bear the same commonName?  This is probably what
>>> Firefox uses to determine if there are serial number collisions.
>>>
>>
>> It appears so.
>>
>> The certificate for the CA on the master serverA shows:
>>
>> Issued To
>> Common Name (CN) serverA.mydomain.com
>> Organization (O) mydomain.com
>> Organizational Unit (OU) 
>> Serial Number 0A
>> Issued By:
>> Common Name (CN) Certificate Authority
>> Organization (O) mydomain.com
>> Organizational Unit (OU) 
>>
>> The certificate for the CA on the master serverB shows:
>>
>> Issued To
>> Common Name (CN) serverB.mydomain.com
>> Organization (O) mydomain.com
>> Organizational Unit (OU) 
>> Serial Number 0A
>> Issued By:
>> Common Name (CN) Certificate Authority
>> Organization (O) mydomain.com
>> Organizational Unit (OU) 
>>
>>
>> Shouldn't the Common Name of the CA be different? Or is it the same in order 
>> to make CA replication easier?
>>
> Both environments were probably set up with the same CN for the CA
> (perhaps a default name).  I don't think this has anything to do
> with replication.
> 
>> Is there a way to re-issue certificates for the masters so they get unique 
>> serial numbers (without making the systems blow up)?
>>
> You can manually renew a certificate using Certmonger:
> 
> http://www.freeipa.org/page/Certmonger#Manually_renew_a_certificate
> 
> You should enable random serial numbers before doing this.

The problem here isn't the server certs, it's the CA certs. He has two
CA's with the same subjects and serial numbers claiming to be th

Re: [Freeipa-users] how to overcome same serial number in cert issue on different master servers?

[Simo Sorce]

On Tue, 11 Nov 2014 14:19:02 -0500
Simo Sorce  wrote:

> On Tue, 11 Nov 2014 04:17:37 +
> Les Stott  wrote:
> 
> > > -Original Message-
> > > From: Fraser Tweedale [mailto:ftwee...@redhat.com]
> > > Sent: Tuesday, 11 November 2014 1:59 PM
> > > To: Les Stott
> > > Cc: freeipa-users@redhat.com
> > > Subject: Re: [Freeipa-users] how to overcome same serial number in
> > > cert issue on different master servers?
> > > 
> > > On Tue, Nov 11, 2014 at 02:11:55AM +, Les Stott wrote:
> > > > > -Original Message-
> > > > > From: Fraser Tweedale [mailto:ftwee...@redhat.com]
> > > > > Sent: Tuesday, 11 November 2014 12:51 PM
> > > > > To: Les Stott
> > > > > Cc: freeipa-users@redhat.com
> > > > > Subject: Re: [Freeipa-users] how to overcome same serial
> > > > > number in cert issue on different master servers?
> > > > >
> > > > > On Tue, Nov 11, 2014 at 01:40:50AM +, Les Stott wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I have a standard rhel6 deployment for FreeIPA in two
> > > > > > environments.
> > > > > >
> > > > > > One environment is in our Production Data Center, The Other
> > > > > > in our DR
> > > > > Data Center.
> > > > > >
> > > > > > Both environments are setup with the same domain
> > > > > > (mydomain.com) for
> > > > > FreeIPA. This is to support dr/failover etc.
> > > > > >
> > > > > > In each environment, there is a master. In Prod its
> > > > > > serverA.mydomain.com,
> > > > > In DR its serverB.mydomain.com.
> > > > > >
> > > > > > The master in each environment gets a generated certificate
> > > > > > by IPA. This
> > > > > certificate shows a Serial Number of "0A"
> > > > > >
> > > > > > My problem is that because the certificates have the same
> > > > > > Organization,
> > > > > OU and Serial Number, I can only browse to one of them (using
> > > > > Firefox).
> > > > > >
> > > > > > If I browse to https://serverA.mydomain.com/ipa/ui/ and
> > > > > > accept the
> > > > > certificate it works fine.
> > > > > > If I then try to browse to
> > > > > > https://serverB.mydomain.com/ipa/ui/ it comes
> > > > > up with the following error:
> > > > > >
> > > > > > "Your certificate contains the same serial number as another
> > > > > > certificate
> > > > > issued by the certificate authority. Please get a new
> > > > > certificate containing a unique serial number. (Error code:
> > > sec_error_reused_issuer_and_serial)"
> > > > > >
> > > > > > If I remove the stored browser certificate for serverA, then
> > > > > > browse to
> > > > > serverB, and accept the certificate, it works, but then the
> > > > > "same serial number" error pops up for browsing serverA.
> > > > > >
> > > > > > Note: both environments were built separately and are not
> > > > > > linked in
> > > > > anyway (no replication between prod/dr).
> > > > > >
> > > > > > Is there a way to generate unique serial numbers for the
> > > > > > masters?
> > > > > >
> > > > > > Thanks in advance,
> > > > > >
> > > > > > Les
> > > > > >
> > > > > >
> > > > > >
> > > > > Hi Les,
> > > > >
> > > > > Ideally, you should prevent this situation by using different
> > > > > common names
> > > > > (CN) for your CAs and server certifications across the
> > > > > different environments.  If this is not possible, you can
> > > > > configure the Dogtag CA to use random serial numbers:
> > > > >
> > > > >
> > > http://dogtagpki.org/wiki/Random_Certificate_Serial_Numbers#How_to_U
> > > > > se_Random_Certificate_Serial_Numbers
> > > > >
> > > > > This does not guarantee that you will not get serial number
> > > > > collisions, but reduces the likelihood.
> > > > >
> > > >
> > > > Thanks for the quick reply.
> > > >
> > > > In this case the common name is different between both
> > > > environments. In prod the master was serverA, in DR the master
> > > > was serverB. It just happened that way. So having a different
> > > > CommonName doesn't help.
> > > >
> > > Do the CA certificates bear the same commonName?  This is probably
> > > what Firefox uses to determine if there are serial number
> > > collisions.
> > > 
> > 
> > It appears so.
> > 
> > The certificate for the CA on the master serverA shows:
> > 
> > Issued To
> > Common Name (CN) serverA.mydomain.com
> > Organization (O) mydomain.com
> > Organizational Unit (OU) 
> > Serial Number 0A
> > Issued By:
> > Common Name (CN) Certificate Authority
> > Organization (O) mydomain.com
> > Organizational Unit (OU) 
> > 
> > The certificate for the CA on the master serverB shows:
> > 
> > Issued To
> > Common Name (CN) serverB.mydomain.com
> > Organization (O) mydomain.com
> > Organizational Unit (OU) 
> > Serial Number 0A
> > Issued By:
> > Common Name (CN) Certificate Authority
> > Organization (O) mydomain.com
> > Organizational Unit (OU) 
> > 
> > 
> > Shouldn't the Common Name of the CA be different? Or is it the same
> > in order to make CA replication easier?
> > 
> > Is there a way to re-issue certificates for the masters so they get
> > unique serial numbers (without maki

Re: [Freeipa-users] how to overcome same serial number in cert issue on different master servers?

[Simo Sorce]

On Tue, 11 Nov 2014 04:17:37 +
Les Stott  wrote:

> > -Original Message-
> > From: Fraser Tweedale [mailto:ftwee...@redhat.com]
> > Sent: Tuesday, 11 November 2014 1:59 PM
> > To: Les Stott
> > Cc: freeipa-users@redhat.com
> > Subject: Re: [Freeipa-users] how to overcome same serial number in
> > cert issue on different master servers?
> > 
> > On Tue, Nov 11, 2014 at 02:11:55AM +, Les Stott wrote:
> > > > -Original Message-
> > > > From: Fraser Tweedale [mailto:ftwee...@redhat.com]
> > > > Sent: Tuesday, 11 November 2014 12:51 PM
> > > > To: Les Stott
> > > > Cc: freeipa-users@redhat.com
> > > > Subject: Re: [Freeipa-users] how to overcome same serial number
> > > > in cert issue on different master servers?
> > > >
> > > > On Tue, Nov 11, 2014 at 01:40:50AM +, Les Stott wrote:
> > > > > Hi,
> > > > >
> > > > > I have a standard rhel6 deployment for FreeIPA in two
> > > > > environments.
> > > > >
> > > > > One environment is in our Production Data Center, The Other
> > > > > in our DR
> > > > Data Center.
> > > > >
> > > > > Both environments are setup with the same domain
> > > > > (mydomain.com) for
> > > > FreeIPA. This is to support dr/failover etc.
> > > > >
> > > > > In each environment, there is a master. In Prod its
> > > > > serverA.mydomain.com,
> > > > In DR its serverB.mydomain.com.
> > > > >
> > > > > The master in each environment gets a generated certificate by
> > > > > IPA. This
> > > > certificate shows a Serial Number of "0A"
> > > > >
> > > > > My problem is that because the certificates have the same
> > > > > Organization,
> > > > OU and Serial Number, I can only browse to one of them (using
> > > > Firefox).
> > > > >
> > > > > If I browse to https://serverA.mydomain.com/ipa/ui/ and
> > > > > accept the
> > > > certificate it works fine.
> > > > > If I then try to browse to
> > > > > https://serverB.mydomain.com/ipa/ui/ it comes
> > > > up with the following error:
> > > > >
> > > > > "Your certificate contains the same serial number as another
> > > > > certificate
> > > > issued by the certificate authority. Please get a new
> > > > certificate containing a unique serial number. (Error code:
> > sec_error_reused_issuer_and_serial)"
> > > > >
> > > > > If I remove the stored browser certificate for serverA, then
> > > > > browse to
> > > > serverB, and accept the certificate, it works, but then the
> > > > "same serial number" error pops up for browsing serverA.
> > > > >
> > > > > Note: both environments were built separately and are not
> > > > > linked in
> > > > anyway (no replication between prod/dr).
> > > > >
> > > > > Is there a way to generate unique serial numbers for the
> > > > > masters?
> > > > >
> > > > > Thanks in advance,
> > > > >
> > > > > Les
> > > > >
> > > > >
> > > > >
> > > > Hi Les,
> > > >
> > > > Ideally, you should prevent this situation by using different
> > > > common names
> > > > (CN) for your CAs and server certifications across the different
> > > > environments.  If this is not possible, you can configure the
> > > > Dogtag CA to use random serial numbers:
> > > >
> > > >
> > http://dogtagpki.org/wiki/Random_Certificate_Serial_Numbers#How_to_U
> > > > se_Random_Certificate_Serial_Numbers
> > > >
> > > > This does not guarantee that you will not get serial number
> > > > collisions, but reduces the likelihood.
> > > >
> > >
> > > Thanks for the quick reply.
> > >
> > > In this case the common name is different between both
> > > environments. In prod the master was serverA, in DR the master
> > > was serverB. It just happened that way. So having a different
> > > CommonName doesn't help.
> > >
> > Do the CA certificates bear the same commonName?  This is probably
> > what Firefox uses to determine if there are serial number
> > collisions.
> > 
> 
> It appears so.
> 
> The certificate for the CA on the master serverA shows:
> 
> Issued To
> Common Name (CN) serverA.mydomain.com
> Organization (O) mydomain.com
> Organizational Unit (OU) 
> Serial Number 0A
> Issued By:
> Common Name (CN) Certificate Authority
> Organization (O) mydomain.com
> Organizational Unit (OU) 
> 
> The certificate for the CA on the master serverB shows:
> 
> Issued To
> Common Name (CN) serverB.mydomain.com
> Organization (O) mydomain.com
> Organizational Unit (OU) 
> Serial Number 0A
> Issued By:
> Common Name (CN) Certificate Authority
> Organization (O) mydomain.com
> Organizational Unit (OU) 
> 
> 
> Shouldn't the Common Name of the CA be different? Or is it the same
> in order to make CA replication easier?
> 
> Is there a way to re-issue certificates for the masters so they get
> unique serial numbers (without making the systems blow up)?

It is strongly advised not to use the same domain/realm name for 2
different IPA installations, there are a ton of weird and extremely
hard to debug errors that will come your way if you do so.
*especially* if you have clients that access both environments.

A better scheme would be to use mydfomain.com 

Re: [Freeipa-users] strange DS errors trying to tune...

[Rich Megginson]

On 11/11/2014 11:30 AM, Janelle wrote:

Hi all..

I continue to come up with strange and unusual problems. Here is a new 
one - use the dbmon.sh script and trying to tune the dbcache...


This is on a replica BTW

First -- THIS WORKS:

INCR=60 BINDDN="cn=directory manager" BINDPW="asecret"  VERBOSE=2 dbmon.sh

and I see all the info I need, BUT - now I want to tune it and get: 
(HOW CAN THIS BE?!?!)


# ldapmodify -x -D "cn=directory manager" -w asecret < dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config
> changetype: modify
> replace: nsslapd-cachememsize
> nsslapd-cachememsize: 8589934592
> EOF
ldap_bind: Invalid credentials (49)


Is asecret the literal password?  If not, does it contain spaces or 
other shell metacharacters that need to be quoted or escaped?




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

[Freeipa-users] strange DS errors trying to tune...

[Janelle]

Hi all..

I continue to come up with strange and unusual problems. Here is a new 
one - use the dbmon.sh script and trying to tune the dbcache...


This is on a replica BTW

First -- THIS WORKS:

INCR=60 BINDDN="cn=directory manager" BINDPW="asecret"  VERBOSE=2 dbmon.sh

and I see all the info I need, BUT - now I want to tune it and get: (HOW 
CAN THIS BE?!?!)


# ldapmodify -x -D "cn=directory manager" -w asecret < dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config
> changetype: modify
> replace: nsslapd-cachememsize
> nsslapd-cachememsize: 8589934592
> EOF
ldap_bind: Invalid credentials (49)

Thanks
~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] certmonger question

[Nalin Dahyabhai]

On Tue, Nov 11, 2014 at 11:13:12AM -0500, Nalin Dahyabhai wrote:
> Since you mention that this seems to be specific to 32-bit boxes, I
> think I need to switch to that one to try to sort out what's happening
> here, since I'm on a 64-bit box.

Okay, found it, and as 64-bit cleanliness sometimes is, it's a one-line
change.  The nightlies should have it starting with anything claiming to
be 0.76.7 or later.  If you can open this in bugzilla, it'll probably
look less weird to parts of management than if I did it.

Thanks,

Nalin

-- 
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 unresponsive - Causes DOS situations

[Rich Megginson]

On 11/11/2014 10:37 AM, Martin Basti wrote:

On 11/11/14 15:58, Rich Megginson wrote:

On 11/11/2014 06:20 AM, Ludwig Krispenz wrote:


On 11/11/2014 02:14 PM, Martin Basti wrote:

Ludiwg (CCed) this seems like old (fixed?) DS bug.
hmm, it says limit is 2097152, so it already has the new setting, 
but the error message says the packet is 800MB*

*


*Right.  That usually means the server was expecting an encrypted 
SASL buffer from the client, but instead the client thinks SASL 
encryption negotiation failed and just sent a plain LDAP buffer.  
What version of 389-ds-base are you using?  rpm -q 389-ds-base


https://fedorahosted.org/389/ticket/47416

So, DO NOT increase your sasl io buffer size - it will not fix the 
problem, and it will leave you open to DoS attacks.

*


He is using

CentOS release 6.5 (Final)
389-ds-base.x86_64   1.2.11.15-34.el6_5



Ignore the "SASL encrypted packet length exceeds maximum allowed limit" 
error.  All it means is the client has some error and is canceling the 
connection.


The bugzilla associated with *47416 is targeted for RHEL 7.1.  The 
problem is that we were never able to figure out what error the client 
was getting that caused the client to stop establishing the *SASL 
encryption, and the original customer who reported the problem dropped 
the case - everything just started working, no further errors.  Note 
that 47416 doesn't really fix the problem or address the root cause - 
the root cause is some error on the client side that causes it to stop 
doing encrypted SASL I/O and send an LDAP unbind request.


Let's get back to the actual problem - what is the actual problem? The 
ldap server is hanging or unresponsive?  If so, then see 
http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-hangs. Let's 
get some dirsrv stack traces during the period of time when it appears 
to be unresponsive.





*
*

**


On 11/11/14 13:13, Walter van Lille wrote:
I've just cleaned out a ton of slapd_poll timed out messages from 
the output and changed the names to protect the innocent, :-)

Here is the output as requested:


*[05/Nov/2014:11:44:05 +0200] - SASL encrypted packet length 
exceeds maximum allowed limit (length=805565, limit=2097152).  
Change the nsslapd-maxsasliosize attribute in cn=config to 
increase limit.*

*
*
*[10/Nov/2014:14:45:19 +0200] - slapd_poll(115) timed out*
*[10/Nov/2014:14:45:19 +0200] sasl_io_enable - Cannot enable SASL 
security on connection in CLOSING state*
*[10/Nov/2014:14:45:19 +0200] - Error: could not add/remove IO 
layers from connection*
*[11/Nov/2014:11:48:09 +0200] - slapd shutting down - signaling 
operation threads*
*[11/Nov/2014:11:48:09 +0200] - slapd shutting down - waiting for 
30 threads to terminate*
*[11/Nov/2014:13:14:12 +0200] - slapd shutting down - closing down 
internal subsystems and plugins*
*[11/Nov/2014:13:14:12 +0200] - Waiting for 4 database threads to 
stop*

*[11/Nov/2014:13:14:13 +0200] - All database threads now stopped*
*[11/Nov/2014:13:14:13 +0200] - slapd stopped.*
*[11/Nov/2014:13:26:35 +0200] - 389-Directory/1.2.11.15 
 B2014.219.179 starting up*
*[11/Nov/2014:13:26:35 +0200] schema-compat-plugin - warning: no 
entries set up under cn=computers, cn=compat,dc=sample,dc=example*
*[11/Nov/2014:13:26:36 +0200] - Skipping CoS Definition 
cn=Password Policy,cn=accounts,dc=sample,dc=example--no CoS 
Templates found, which should be added before the CoS Definition.*
*[11/Nov/2014:13:26:36 +0200] - Skipping CoS Definition 
cn=Password Policy,cn=accounts,dc=sample,dc=example--no CoS 
Templates found, which should be added before the CoS Definition.*
*[11/Nov/2014:13:26:36 +0200] - slapd started. Listening on All 
Interfaces port 389 for LDAP requests*
*[11/Nov/2014:13:26:36 +0200] - Listening on All Interfaces port 
636 for LDAPS requests*
*[11/Nov/2014:13:26:36 +0200] - Listening on 
/var/run/slapd-SAMPLE-EXAMPLE.socket for LDAPI requests*

*[11/Nov/2014:13:57:08 +0200] - slapd_poll(78) timed out*
*
*
*
*
*
*


On Tue, Nov 11, 2014 at 1:19 PM, Martin Basti > wrote:


IMHO It's DS bug, can you share DS error log?
pspacek CCed to examine named logs.

Martin^2


On 11/11/14 12:13, Walter van Lille wrote:

Hi Martin, thanks for the reply.
My version: bind-dyndb-ldap-2.3-5.el6.x86_64
The server doesn't have journalctl installed but I have the
outputs from the messages and named.run files that I included
here:

Messages:

*Nov 11 12:30:13 freeipa named[1481]: error (network
unreachable) resolving
'example.example.com.10.123.123.123/A/IN': 2001:500:2f::f#53*
*Nov 11 12:30:23 freeipa named[1481]: LDAP query timed out.
Try to adjust "timeout" parameter*
*Nov 11 12:30:23 freeipa named[1481]: LDAP query timed out.
Try to adjust "timeout" parameter*
*Nov 11 12:30:33 freeipa named[1481]: LDAP query timed out.
Try to adjust "timeout" parameter*
*Nov 11 12:30:33 freeipa named[1481]: LDAP query timed out

Re: [Freeipa-users] FreeIPA unresponsive - Causes DOS situations

[Martin Basti]

On 11/11/14 15:58, Rich Megginson wrote:

On 11/11/2014 06:20 AM, Ludwig Krispenz wrote:


On 11/11/2014 02:14 PM, Martin Basti wrote:

Ludiwg (CCed) this seems like old (fixed?) DS bug.
hmm, it says limit is 2097152, so it already has the new setting, but 
the error message says the packet is 800MB*

*


*Right.  That usually means the server was expecting an encrypted SASL 
buffer from the client, but instead the client thinks SASL encryption 
negotiation failed and just sent a plain LDAP buffer.  What version of 
389-ds-base are you using?  rpm -q 389-ds-base


https://fedorahosted.org/389/ticket/47416

So, DO NOT increase your sasl io buffer size - it will not fix the 
problem, and it will leave you open to DoS attacks.

*


He is using

CentOS release 6.5 (Final)
389-ds-base.x86_64   1.2.11.15-34.el6_5


*
*

**


On 11/11/14 13:13, Walter van Lille wrote:
I've just cleaned out a ton of slapd_poll timed out messages from 
the output and changed the names to protect the innocent, :-)

Here is the output as requested:


*[05/Nov/2014:11:44:05 +0200] - SASL encrypted packet length 
exceeds maximum allowed limit (length=805565, limit=2097152).  
Change the nsslapd-maxsasliosize attribute in cn=config to increase 
limit.*

*
*
*[10/Nov/2014:14:45:19 +0200] - slapd_poll(115) timed out*
*[10/Nov/2014:14:45:19 +0200] sasl_io_enable - Cannot enable SASL 
security on connection in CLOSING state*
*[10/Nov/2014:14:45:19 +0200] - Error: could not add/remove IO 
layers from connection*
*[11/Nov/2014:11:48:09 +0200] - slapd shutting down - signaling 
operation threads*
*[11/Nov/2014:11:48:09 +0200] - slapd shutting down - waiting for 
30 threads to terminate*
*[11/Nov/2014:13:14:12 +0200] - slapd shutting down - closing down 
internal subsystems and plugins*

*[11/Nov/2014:13:14:12 +0200] - Waiting for 4 database threads to stop*
*[11/Nov/2014:13:14:13 +0200] - All database threads now stopped*
*[11/Nov/2014:13:14:13 +0200] - slapd stopped.*
*[11/Nov/2014:13:26:35 +0200] - 389-Directory/1.2.11.15 
 B2014.219.179 starting up*
*[11/Nov/2014:13:26:35 +0200] schema-compat-plugin - warning: no 
entries set up under cn=computers, cn=compat,dc=sample,dc=example*
*[11/Nov/2014:13:26:36 +0200] - Skipping CoS Definition cn=Password 
Policy,cn=accounts,dc=sample,dc=example--no CoS Templates found, 
which should be added before the CoS Definition.*
*[11/Nov/2014:13:26:36 +0200] - Skipping CoS Definition cn=Password 
Policy,cn=accounts,dc=sample,dc=example--no CoS Templates found, 
which should be added before the CoS Definition.*
*[11/Nov/2014:13:26:36 +0200] - slapd started. Listening on All 
Interfaces port 389 for LDAP requests*
*[11/Nov/2014:13:26:36 +0200] - Listening on All Interfaces port 
636 for LDAPS requests*
*[11/Nov/2014:13:26:36 +0200] - Listening on 
/var/run/slapd-SAMPLE-EXAMPLE.socket for LDAPI requests*

*[11/Nov/2014:13:57:08 +0200] - slapd_poll(78) timed out*
*
*
*
*
*
*


On Tue, Nov 11, 2014 at 1:19 PM, Martin Basti > wrote:


IMHO It's DS bug, can you share DS error log?
pspacek CCed to examine named logs.

Martin^2


On 11/11/14 12:13, Walter van Lille wrote:

Hi Martin, thanks for the reply.
My version: bind-dyndb-ldap-2.3-5.el6.x86_64
The server doesn't have journalctl installed but I have the
outputs from the messages and named.run files that I included
here:

Messages:

*Nov 11 12:30:13 freeipa named[1481]: error (network
unreachable) resolving
'example.example.com.10.123.123.123/A/IN': 2001:500:2f::f#53*
*Nov 11 12:30:23 freeipa named[1481]: LDAP query timed out.
Try to adjust "timeout" parameter*
*Nov 11 12:30:23 freeipa named[1481]: LDAP query timed out.
Try to adjust "timeout" parameter*
*Nov 11 12:30:33 freeipa named[1481]: LDAP query timed out.
Try to adjust "timeout" parameter*
*Nov 11 12:30:33 freeipa named[1481]: LDAP query timed out.
Try to adjust "timeout" parameter*

Named.run:

*client 10.123.123.123#42639: transfer of
'example.example/IN': AXFR-style IXFR started*
*client 10.123.123.123#42639: transfer of
''example.example/IN': AXFR-style IXFR ended*
*client 10.123.123.123#46912: transfer of
'10.123.123.123.in-addr.arpa/IN': AXFR-style IXFR started*
*client 10.123.123.123#46912: transfer of
'10.123.123.123.in-addr.arpa/IN': AXFR-style IXFR ended*
*LDAP query timed out. Try to adjust "timeout" parameter*
*LDAP query timed out. Try to adjust "timeout" parameter*
*LDAP query timed out. Try to adjust "timeout" parameter*

I just replaced the IPs and the actual names with something
more generic.

Regards,

Walter

On Thu, Nov 6, 2014 at 5:00 PM, Martin Basti
mailto:mba...@redhat.com>> wrote:

On 06/11/14 14:58, Walter van Lille wrote:

Hi,

I need some assistance please.
I've taken over an IPA server to manage a few months ago,
and it was working fine unt

Re: [Freeipa-users] Installed OpenSSH server does not support dynamically loading authorized user keys - no key login support

[Vaclav Adamec]

openssh-6.1p1-5.el6.1.x86_64
libssh2-1.4.2-1.el6.x86_64
openssh-clients-6.1p1-5.el6.1.x86_64
openssh-server-6.1p1-5.el6.1.x86_64


it's up2date centos66 with 6.1 openssh, but same issue is for 6.7. I'll
check rpmspec if there is no issue with dynamically loading authorized user
keys, I'm not aware about any disabled functionality. Also I'll try fresh
CentOS 6.6 with default 5.3 openssh.

Vasek


On Tue, Nov 11, 2014 at 3:44 PM, Rob Crittenden  wrote:

> Vaclav Adamec wrote:
> > Here it is:
> >
> > 2014-11-11T11:45:33Z DEBUG stderr=
> > 2014-11-11T11:45:33Z DEBUG Backing up system configuration file
> > '/etc/ssh/ssh_config'
> > 2014-11-11T11:45:33Z DEBUG Saving Index File to
> > '/var/lib/ipa-client/sysrestore/sysrestore.index'
> > 2014-11-11T11:45:33Z INFO Configured /etc/ssh/ssh_config
> > 2014-11-11T11:45:33Z DEBUG Backing up system configuration file
> > '/etc/ssh/sshd_config'
> > 2014-11-11T11:45:33Z DEBUG Saving Index File to
> > '/var/lib/ipa-client/sysrestore/sysrestore.index'
> > 2014-11-11T11:45:33Z DEBUG args=sshd -t -f /dev/null -o
> > AuthorizedKeysCommand=
> > 2014-11-11T11:45:33Z DEBUG stdout=
> > 2014-11-11T11:45:33Z DEBUG stderr=command-line line 0:
> > AuthorizedKeysCommand must be an absolute path
> >
> > 2014-11-11T11:45:33Z DEBUG args=sshd -t -f /dev/null -o PubKeyAgent=
> > 2014-11-11T11:45:33Z DEBUG stdout=
> > 2014-11-11T11:45:33Z DEBUG stderr=command-line: line 0: Bad
> > configuration option: PubKeyAgent
> >
> > 2014-11-11T11:45:33Z WARNING Installed OpenSSH server does not support
> > dynamically loading authorized user keys. Public key authentication of
> > IPA users will not be available.
> > 2014-11-11T11:45:33Z INFO Configured /etc/ssh/sshd_config
> > 2014-11-11T11:45:33Z DEBUG args=/sbin/service sshd status
> > 2014-11-11T11:45:33Z DEBUG stdout=openssh-daemon (pid  24698) is
> running...
>
> Seems to be different behavior from sshd. What version do you have
> installed?
>
> On my RHEL-6.x box I see:
>
> 2014-11-11T14:40:00Z DEBUG args=sshd -t -f /dev/null -o
> AuthorizedKeysCommand=
> 2014-11-11T14:40:00Z DEBUG stdout=
> 2014-11-11T14:40:00Z DEBUG stderr=
> 2014-11-11T14:40:00Z INFO Configured /etc/ssh/sshd_config
>
> rob
>
> >
> >
> > On Tue, Nov 11, 2014 at 3:15 PM, Rob Crittenden  > > wrote:
> >
> > Vaclav Adamec wrote:
> > > Hi,
> > >  I'm getting "Installed OpenSSH server does not support dynamically
> > > loading authorized user keys. Public key authentication of IPA
> users
> > > will not be available" during ipa client install on CentOS 6.6
> > >
> > > Packages openssh-server-6.1p1-5.el6.1.x86_64 and
> > > ipa-client-3.0.0-42.el6.centos.x86_64
> > >
> > > Manual setup of  "AuthorizedKeysCommand
> > /usr/bin/sss_ssh_authorizedkeys"
> > > in /etc/ssh/sshd_config is ok.
> > >
> > > Any reason for that ?
> > >
> >
> > I'd check the client install log for more details,
> > /var/log/ipaclient-install.log
> >
> > A number of different permutations are tried and the log should have
> > more details on which ones failed (and hopefully why).
> >
> > rob
> >
> >
> >
> >
> > --
> > -- May the fox be with you ...
> >/\
> >   (~(
> >) ) /\_/\
> >   (_=---_(@ @)
> > (  \   /
> > /|/\|\  V
> > " " " "
> >
> >
> >
> >
>
>


-- 
-- May the fox be with you ...
   /\
  (~(
   ) ) /\_/\
  (_=---_(@ @)
(  \   /
/|/\|\  V
" " " "
-- 
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] certmonger question

[Nalin Dahyabhai]

On Tue, Nov 11, 2014 at 08:48:18AM +0100, Natxo Asenjo wrote:
> 2014-11-11 08:34:33 [11677] Certificate "Local Signing Authority"
> valid for 31473668s.
> 2014-11-11 08:34:33 [11677] Running result is 1481416576.
> 2014-11-11 08:34:33 [11677] Final result is 1481416576.

Okay, that's weird.  The result being tallied here is the earliest of
the not-valid-after times for the CA's certificate, but on my
development box, those numbers are coming back scaled up by a factor of
a million.  That suggests that the logic that determines how long to
wait before trying to fetch new data is somehow arriving at a much lower
value than it should, which would explain why it immediately polls for a
new local signer certificate.

Since you mention that this seems to be specific to 32-bit boxes, I
think I need to switch to that one to try to sort out what's happening
here, since I'm on a 64-bit box.

[snip]

> # CACert, ipa, etc, domain.tld
> dn: cn=CACert,cn=ipa,cn=etc,dc=domain,dc=tld
> cACertificate;binary:: TUlJRG5EQ0NBb1NnQXdJQkFnSUJBVEFOQmdrcWhraUc5dzBCQVFzRkF
>  EQTdNUmt3RndZRFZRUUtFeEJWVGtsWUxrbFNTVk5hVDFKSExrNU1NUjR3SEFZRFZRUURFeFZEWlhK
>  MGFXWnBZMkYwWlNCQmRYUm9iM0pwZEhrd0hoY05NVEl4TVRBM01qRXlOREUxV2hjTk1qQXhNVEEzT
>  WpFeU5ERTFXakE3TVJrd0Z3WURWUVFLRXhCVlRrbFlMa2xTU1ZOYVQxSkhMazVNTVI0d0hBWURWUV
>  FERXhWRFpYSjBhV1pwWTJGMFpTQkJkWFJvYjNKcGRIa3dnZ0VpTUEwR0NTcUdTSWIzRFFFQkFRVUF
>  BNElCRHdBd2dnRUtBb0lCQVFDeTJXVnk3UWtIaXVFTlcvemtNZUQ0SUxvcU9ydXVZS3ZiMitycWV1
>  STlpdyt6QkJ0NTY5WFN4cmdjeWVUcTBHNjNSamJYZ3JBem90NEVoWWc2TW9lcERWQ24wQm51clVmZ
>  2JDZjVSMEVib2lnamJvaDVNR25QeWxIZWZMUkdBUk5VQ3djVEdBNHVSOVpRTC9yRVVxV2t0bVpqYW
>  5ZRXZPUDhVQmV1cTVXUDVlbWFYOFUwM1N6TUErY1FUOXcvengwZUFPWWdaVzV5eDNhQTVRNEZ1OHF
>  XcU1HR0FPQTZ5RFFXcW1JcGd4aUZISFJhN2hRSzRBamVIZ3ZhQ29sYVU5NzlMaDVqQXYvWHdyWXRv
>  azFHK1VWRXA0NUlOcGZ4cjVkTGUwM29nblBGUFowL3h3YkJxdHQvMnFuNnJrNEw0dWtINFA5ZzRSd
>  zBvN1UxeUpWeC9TT0pBZ01CQUFHamdhb3dnYWN3SHdZRFZSMGpCQmd3Rm9BVW81ZmtpaTY0eno3cU
>  0vSzhrOVlqM3FtRU5tZ3dEd1lEVlIwVEFRSC9CQVV3QXdFQi96QU9CZ05WSFE4QkFmOEVCQU1DQWN
>  Zd0hRWURWUjBPQkJZRUZLT1g1SW91dU04KzZqUHl2SlBXSTk2cGhEWm9NRVFHQ0NzR0FRVUZCd0VC
>  QkRnd05qQTBCZ2dyQmdFRkJRY3dBWVlvYUhSMGNEb3ZMMnRrWXpBeExuVnVhWGd1YVhKcGMzcHZjb
>  WN1Ym13Nk9EQXZZMkV2YjJOemNEQU5CZ2txaGtpRzl3MEJBUXNGQUFPQ0FRRUFKMjhnZG96ZC9wdE
>  9NNVBUS0t3eVYrb3RPL3drM3lFcnNseHBOVWhSWmdTTlV3VCt0NnRmRi9qK2pKUlY1c1grankwOWM
>  5RG8rcDNIeTlnUm5JVkpPTkRTY3ZNVjluRGM3NUM2SkdYVStGZE5KSitEYnBlcC9Sc1FqSHJaK3Vu
>  d0l5QVdvT3BCb2w4c0d6TjV0WGJlby9NNm1HRnhhQlRIMUdLdGd2NENLYnpRQW90dk1hR3h6S2pTY
>  0hSc0dhZXJOU0NacC85MHlSSnlwQzNNT29zVUZjRmw0Q29ZSEI0MlhEVHpqdnpaUWNhRk5jZ1lYT2
>  NpdWp3d1lITnpzU3FZY0lLRlNXdVd2TisrN2c0eXhRTWx1OFFXME1zL1BudG1UbU8yY0RkTkkxdHV
>  qVnlCS2U1OTl5NE8vRXMvTUJHdER0VkE4NUFMa3NKT1UyN2JqdHZiQmc9PQ==
> 
> # search result
> search: 4
> result: 0 Success

Yup.  If you trim the whitespace and run that through 'base64 -d',
you'll see base64-encoded data.  If you run _that_ through 'base64 -d',
you'll get the certificate, which confirms that it was double-encoded,
as I think Martin noted.

[snip]

> So there is something wrong but how come I only see this in this
> client after upgrading it to centos 6.6?

Not specifically.  Caching the root certificate (for the "IPA" and
"local" signers, anyway), is new functionality that was added for other
users.

HTH,

Nalin

-- 
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] certmonger question

[Natxo Asenjo]

hi,

This seems to happen only in 32bits vm's. At least in my limited
testing, 2 out 2 32bits hosts running 6.5 after upgrading have this
problem. A amd64 host is ok.

$ rpm -qa | grep certmonger
certmonger-0.75.13-1.el6.x86_64

$ rpm -qa | grep certmonger
certmonger-0.75.13-1.el6.i686


--
Groeten,
natxo

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

Re: [Freeipa-users] certmonger question

[Martin Kosek]

On 11/11/2014 02:47 PM, Natxo Asenjo wrote:
> hi,
> 
> On Tue, Nov 11, 2014 at 2:13 PM, Martin Kosek  wrote:
> 
>> I meant IPA server running on RHEL/CentOS 6.5 or older... This is the one 
>> that
>> can regenerate CAcert entry without double encoding.
> 
> ok.
> 
> So I removed the cacert object and ran
> 
> ipa-ldap-updater --upgrade --ldapi
> 
> (it does not know the --quiet switch in this version). And now in he
> apache directory studio I see the value of the attribue is X509v3:
> CN=Certificate Authority, O=DOMAIN.TLD

Ah, looks good.

> So that's fixed. But certmonger on the client still gives me the same errror
> 
> Could I send you the full log of certmonger privately (1.1M)?

Sure. Though Nalin (CCed) would be better candidate as he is knowledgeable
about certmonger internals.

Martin

-- 
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 unresponsive - Causes DOS situations

[Rich Megginson]

On 11/11/2014 06:20 AM, Ludwig Krispenz wrote:


On 11/11/2014 02:14 PM, Martin Basti wrote:

Ludiwg (CCed) this seems like old (fixed?) DS bug.
hmm, it says limit is 2097152, so it already has the new setting, but 
the error message says the packet is 800MB*

*


*Right.  That usually means the server was expecting an encrypted SASL 
buffer from the client, but instead the client thinks SASL encryption 
negotiation failed and just sent a plain LDAP buffer. What version of 
389-ds-base are you using?  rpm -q 389-ds-base


https://fedorahosted.org/389/ticket/47416

So, DO NOT increase your sasl io buffer size - it will not fix the 
problem, and it will leave you open to DoS attacks.


*

**


On 11/11/14 13:13, Walter van Lille wrote:
I've just cleaned out a ton of slapd_poll timed out messages from 
the output and changed the names to protect the innocent, :-)

Here is the output as requested:


*[05/Nov/2014:11:44:05 +0200] - SASL encrypted packet length exceeds 
maximum allowed limit (length=805565, limit=2097152).  Change the 
nsslapd-maxsasliosize attribute in cn=config to increase limit.*

*
*
*[10/Nov/2014:14:45:19 +0200] - slapd_poll(115) timed out*
*[10/Nov/2014:14:45:19 +0200] sasl_io_enable - Cannot enable SASL 
security on connection in CLOSING state*
*[10/Nov/2014:14:45:19 +0200] - Error: could not add/remove IO 
layers from connection*
*[11/Nov/2014:11:48:09 +0200] - slapd shutting down - signaling 
operation threads*
*[11/Nov/2014:11:48:09 +0200] - slapd shutting down - waiting for 30 
threads to terminate*
*[11/Nov/2014:13:14:12 +0200] - slapd shutting down - closing down 
internal subsystems and plugins*

*[11/Nov/2014:13:14:12 +0200] - Waiting for 4 database threads to stop*
*[11/Nov/2014:13:14:13 +0200] - All database threads now stopped*
*[11/Nov/2014:13:14:13 +0200] - slapd stopped.*
*[11/Nov/2014:13:26:35 +0200] - 389-Directory/1.2.11.15 
 B2014.219.179 starting up*
*[11/Nov/2014:13:26:35 +0200] schema-compat-plugin - warning: no 
entries set up under cn=computers, cn=compat,dc=sample,dc=example*
*[11/Nov/2014:13:26:36 +0200] - Skipping CoS Definition cn=Password 
Policy,cn=accounts,dc=sample,dc=example--no CoS Templates found, 
which should be added before the CoS Definition.*
*[11/Nov/2014:13:26:36 +0200] - Skipping CoS Definition cn=Password 
Policy,cn=accounts,dc=sample,dc=example--no CoS Templates found, 
which should be added before the CoS Definition.*
*[11/Nov/2014:13:26:36 +0200] - slapd started. Listening on All 
Interfaces port 389 for LDAP requests*
*[11/Nov/2014:13:26:36 +0200] - Listening on All Interfaces port 636 
for LDAPS requests*
*[11/Nov/2014:13:26:36 +0200] - Listening on 
/var/run/slapd-SAMPLE-EXAMPLE.socket for LDAPI requests*

*[11/Nov/2014:13:57:08 +0200] - slapd_poll(78) timed out*
*
*
*
*
*
*


On Tue, Nov 11, 2014 at 1:19 PM, Martin Basti > wrote:


IMHO It's DS bug, can you share DS error log?
pspacek CCed to examine named logs.

Martin^2


On 11/11/14 12:13, Walter van Lille wrote:

Hi Martin, thanks for the reply.
My version: bind-dyndb-ldap-2.3-5.el6.x86_64
The server doesn't have journalctl installed but I have the
outputs from the messages and named.run files that I included here:

Messages:

*Nov 11 12:30:13 freeipa named[1481]: error (network
unreachable) resolving
'example.example.com.10.123.123.123/A/IN': 2001:500:2f::f#53*
*Nov 11 12:30:23 freeipa named[1481]: LDAP query timed out. Try
to adjust "timeout" parameter*
*Nov 11 12:30:23 freeipa named[1481]: LDAP query timed out. Try
to adjust "timeout" parameter*
*Nov 11 12:30:33 freeipa named[1481]: LDAP query timed out. Try
to adjust "timeout" parameter*
*Nov 11 12:30:33 freeipa named[1481]: LDAP query timed out. Try
to adjust "timeout" parameter*

Named.run:

*client 10.123.123.123#42639: transfer of 'example.example/IN':
AXFR-style IXFR started*
*client 10.123.123.123#42639: transfer of
''example.example/IN': AXFR-style IXFR ended*
*client 10.123.123.123#46912: transfer of
'10.123.123.123.in-addr.arpa/IN': AXFR-style IXFR started*
*client 10.123.123.123#46912: transfer of
'10.123.123.123.in-addr.arpa/IN': AXFR-style IXFR ended*
*LDAP query timed out. Try to adjust "timeout" parameter*
*LDAP query timed out. Try to adjust "timeout" parameter*
*LDAP query timed out. Try to adjust "timeout" parameter*

I just replaced the IPs and the actual names with something
more generic.

Regards,

Walter

On Thu, Nov 6, 2014 at 5:00 PM, Martin Basti mailto:mba...@redhat.com>> wrote:

On 06/11/14 14:58, Walter van Lille wrote:

Hi,

I need some assistance please.
I've taken over an IPA server to manage a few months ago,
and it was working fine until recently when it started
acting up seemingly off its own accord.
When I do an ipactl status it basically gives an output

Re: [Freeipa-users] Installed OpenSSH server does not support dynamically loading authorized user keys - no key login support

[Rob Crittenden]

Vaclav Adamec wrote:
> Here it is:
> 
> 2014-11-11T11:45:33Z DEBUG stderr=
> 2014-11-11T11:45:33Z DEBUG Backing up system configuration file
> '/etc/ssh/ssh_config'
> 2014-11-11T11:45:33Z DEBUG Saving Index File to
> '/var/lib/ipa-client/sysrestore/sysrestore.index'
> 2014-11-11T11:45:33Z INFO Configured /etc/ssh/ssh_config
> 2014-11-11T11:45:33Z DEBUG Backing up system configuration file
> '/etc/ssh/sshd_config'
> 2014-11-11T11:45:33Z DEBUG Saving Index File to
> '/var/lib/ipa-client/sysrestore/sysrestore.index'
> 2014-11-11T11:45:33Z DEBUG args=sshd -t -f /dev/null -o
> AuthorizedKeysCommand=
> 2014-11-11T11:45:33Z DEBUG stdout=
> 2014-11-11T11:45:33Z DEBUG stderr=command-line line 0:
> AuthorizedKeysCommand must be an absolute path
> 
> 2014-11-11T11:45:33Z DEBUG args=sshd -t -f /dev/null -o PubKeyAgent=
> 2014-11-11T11:45:33Z DEBUG stdout=
> 2014-11-11T11:45:33Z DEBUG stderr=command-line: line 0: Bad
> configuration option: PubKeyAgent
> 
> 2014-11-11T11:45:33Z WARNING Installed OpenSSH server does not support
> dynamically loading authorized user keys. Public key authentication of
> IPA users will not be available.
> 2014-11-11T11:45:33Z INFO Configured /etc/ssh/sshd_config
> 2014-11-11T11:45:33Z DEBUG args=/sbin/service sshd status
> 2014-11-11T11:45:33Z DEBUG stdout=openssh-daemon (pid  24698) is running...

Seems to be different behavior from sshd. What version do you have
installed?

On my RHEL-6.x box I see:

2014-11-11T14:40:00Z DEBUG args=sshd -t -f /dev/null -o
AuthorizedKeysCommand=
2014-11-11T14:40:00Z DEBUG stdout=
2014-11-11T14:40:00Z DEBUG stderr=
2014-11-11T14:40:00Z INFO Configured /etc/ssh/sshd_config

rob

> 
> 
> On Tue, Nov 11, 2014 at 3:15 PM, Rob Crittenden  > wrote:
> 
> Vaclav Adamec wrote:
> > Hi,
> >  I'm getting "Installed OpenSSH server does not support dynamically
> > loading authorized user keys. Public key authentication of IPA users
> > will not be available" during ipa client install on CentOS 6.6
> >
> > Packages openssh-server-6.1p1-5.el6.1.x86_64 and
> > ipa-client-3.0.0-42.el6.centos.x86_64
> >
> > Manual setup of  "AuthorizedKeysCommand
> /usr/bin/sss_ssh_authorizedkeys"
> > in /etc/ssh/sshd_config is ok.
> >
> > Any reason for that ?
> >
> 
> I'd check the client install log for more details,
> /var/log/ipaclient-install.log
> 
> A number of different permutations are tried and the log should have
> more details on which ones failed (and hopefully why).
> 
> rob
> 
> 
> 
> 
> -- 
> -- May the fox be with you ...
>/\
>   (~(
>) ) /\_/\
>   (_=---_(@ @)
> (  \   / 
> /|/\|\  V
> " " " "
> 
> 
> 
> 

-- 
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] Installed OpenSSH server does not support dynamically loading authorized user keys - no key login support

[Vaclav Adamec]

Here it is:

2014-11-11T11:45:33Z DEBUG stderr=
2014-11-11T11:45:33Z DEBUG Backing up system configuration file
'/etc/ssh/ssh_config'
2014-11-11T11:45:33Z DEBUG Saving Index File to
'/var/lib/ipa-client/sysrestore/sysrestore.index'
2014-11-11T11:45:33Z INFO Configured /etc/ssh/ssh_config
2014-11-11T11:45:33Z DEBUG Backing up system configuration file
'/etc/ssh/sshd_config'
2014-11-11T11:45:33Z DEBUG Saving Index File to
'/var/lib/ipa-client/sysrestore/sysrestore.index'
2014-11-11T11:45:33Z DEBUG args=sshd -t -f /dev/null -o
AuthorizedKeysCommand=
2014-11-11T11:45:33Z DEBUG stdout=
2014-11-11T11:45:33Z DEBUG stderr=command-line line 0:
AuthorizedKeysCommand must be an absolute path

2014-11-11T11:45:33Z DEBUG args=sshd -t -f /dev/null -o PubKeyAgent=
2014-11-11T11:45:33Z DEBUG stdout=
2014-11-11T11:45:33Z DEBUG stderr=command-line: line 0: Bad configuration
option: PubKeyAgent

2014-11-11T11:45:33Z WARNING Installed OpenSSH server does not support
dynamically loading authorized user keys. Public key authentication of IPA
users will not be available.
2014-11-11T11:45:33Z INFO Configured /etc/ssh/sshd_config
2014-11-11T11:45:33Z DEBUG args=/sbin/service sshd status
2014-11-11T11:45:33Z DEBUG stdout=openssh-daemon (pid  24698) is running...


On Tue, Nov 11, 2014 at 3:15 PM, Rob Crittenden  wrote:

> Vaclav Adamec wrote:
> > Hi,
> >  I'm getting "Installed OpenSSH server does not support dynamically
> > loading authorized user keys. Public key authentication of IPA users
> > will not be available" during ipa client install on CentOS 6.6
> >
> > Packages openssh-server-6.1p1-5.el6.1.x86_64 and
> > ipa-client-3.0.0-42.el6.centos.x86_64
> >
> > Manual setup of  "AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys"
> > in /etc/ssh/sshd_config is ok.
> >
> > Any reason for that ?
> >
>
> I'd check the client install log for more details,
> /var/log/ipaclient-install.log
>
> A number of different permutations are tried and the log should have
> more details on which ones failed (and hopefully why).
>
> rob
>



-- 
-- May the fox be with you ...
   /\
  (~(
   ) ) /\_/\
  (_=---_(@ @)
(  \   /
/|/\|\  V
" " " "
-- 
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] Installed OpenSSH server does not support dynamically loading authorized user keys - no key login support

[Rob Crittenden]

Vaclav Adamec wrote:
> Hi,
>  I'm getting "Installed OpenSSH server does not support dynamically
> loading authorized user keys. Public key authentication of IPA users
> will not be available" during ipa client install on CentOS 6.6
> 
> Packages openssh-server-6.1p1-5.el6.1.x86_64 and
> ipa-client-3.0.0-42.el6.centos.x86_64
> 
> Manual setup of  "AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys"
> in /etc/ssh/sshd_config is ok.
> 
> Any reason for that ?
>

I'd check the client install log for more details,
/var/log/ipaclient-install.log

A number of different permutations are tried and the log should have
more details on which ones failed (and hopefully why).

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] Adjust settings for processes

[Rob Crittenden]

Alexander Bokovoy wrote:
> On Tue, 11 Nov 2014, Roman Naumenko wrote:
>> Alexander Bokovoy wrote on 11-11-14 6:52:
>>> On Tue, 11 Nov 2014, Roman Naumenko wrote:
 I'd like to adjust process settings on freeipa server to fit it
 better into virtual instance.
 Is it possible to change settings of java, ns-slapd and apache
 processes somewhere in config files and what those files are?
>>> http://pkgs.fedoraproject.org/cgit/httpd.git/tree/httpd.service
>>> ---
>>> # For example, to pass additional options (for instance, -D
>>> definitions) to the
>>> # httpd binary at startup, you need to create a file named
>>> # "/etc/systemd/system/httpd.service" containing:
>>> #.include /lib/systemd/system/httpd.service
>>> #[Service]
>>> #Environment=OPTIONS=-DMY_DEFINE
>> Isn't it for startup options only?
> You've asked about settings for the processes, that's how it is done in
> systemd environment. Check systemd.resource-control(5) and
> systemd.exec(5) for details of what can be changed.
> 
>>
>> I need to set some of these, they are usually in httpd.conf
>>
>> 
>>  StartServers   12
>>  MinSpareServers12
>>  MaxSpareServers12
>>  MaxClients 12
>>  MaxRequestsPerChild  300
>> 
> This is Apache-specific config and as such should go into
> /etc/httpd/conf.d/, any file with .conf suffix there is automatically
> included by httpd during startup thanks to the following in
> /etc/httpd/conf/httpd.conf:
> 
> # Load config files in the "/etc/httpd/conf.d" directory, if any.
> IncludeOptional conf.d/*.conf
> 

It depends on the version of your distro.

In recent Fedora a lot of configuration has been split out into separate
files. This particular configuration can be found in
/etc/httpd/conf.d/prefork.conf.

For older releases, on RHEL-6 for example, it is still defined in
/etc/httpd/conf/httpd.conf.

As for 389-ds, there is no magic-bullet tuning. It is very
environment-specific and heavily based on the size of your data. This
should help, https://github.com/richm/scripts/wiki/dbmon.sh

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] certmonger question

[Natxo Asenjo]

hi,

On Tue, Nov 11, 2014 at 2:13 PM, Martin Kosek  wrote:

> I meant IPA server running on RHEL/CentOS 6.5 or older... This is the one that
> can regenerate CAcert entry without double encoding.

ok.

So I removed the cacert object and ran

ipa-ldap-updater --upgrade --ldapi

(it does not know the --quiet switch in this version). And now in he
apache directory studio I see the value of the attribue is X509v3:
CN=Certificate Authority, O=DOMAIN.TLD

So that's fixed. But certmonger on the client still gives me the same errror

Could I send you the full log of certmonger privately (1.1M)?

Thanks.
--
Groeten,
natxo

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

Re: [Freeipa-users] Centos IPA Client fails after upgrade to 6.6

[Jakub Hrozek]

On Mon, Nov 10, 2014 at 09:29:04AM -0800, Michael Lasevich wrote:
> I can certainly try, it would need to be compatible with CentOS 6.6 though.
> 
> -M

Thank you very much, can you try these packages?

Please note they wouldn't fix your problem, but will hopefully shed some
more light on what's going on:
https://jhrozek.fedorapeople.org/sssd-test-builds/krb5-ccache-debugging/

> 
> > So according to the logs, the create_ccache() function failed.
> Unfortunately,
> we don't do very good job at logging the failures there..
> >
> >Michael, are you able to run a custom package with extra debugging? It
> would help us pinpoint which line actually is failing.
> >
> >Thanks a lot for providing the logs!

-- 
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 unresponsive - Causes DOS situations

[Ludwig Krispenz]

On 11/11/2014 02:14 PM, Martin Basti wrote:

Ludiwg (CCed) this seems like old (fixed?) DS bug.
hmm, it says limit is 2097152, so it already has the new setting, but 
the error message says the packet is 800MB*

*


On 11/11/14 13:13, Walter van Lille wrote:
I've just cleaned out a ton of slapd_poll timed out messages from the 
output and changed the names to protect the innocent, :-)

Here is the output as requested:


*[05/Nov/2014:11:44:05 +0200] - SASL encrypted packet length exceeds 
maximum allowed limit (length=805565, limit=2097152).  Change the 
nsslapd-maxsasliosize attribute in cn=config to increase limit.*

*
*
*[10/Nov/2014:14:45:19 +0200] - slapd_poll(115) timed out*
*[10/Nov/2014:14:45:19 +0200] sasl_io_enable - Cannot enable SASL 
security on connection in CLOSING state*
*[10/Nov/2014:14:45:19 +0200] - Error: could not add/remove IO layers 
from connection*
*[11/Nov/2014:11:48:09 +0200] - slapd shutting down - signaling 
operation threads*
*[11/Nov/2014:11:48:09 +0200] - slapd shutting down - waiting for 30 
threads to terminate*
*[11/Nov/2014:13:14:12 +0200] - slapd shutting down - closing down 
internal subsystems and plugins*

*[11/Nov/2014:13:14:12 +0200] - Waiting for 4 database threads to stop*
*[11/Nov/2014:13:14:13 +0200] - All database threads now stopped*
*[11/Nov/2014:13:14:13 +0200] - slapd stopped.*
*[11/Nov/2014:13:26:35 +0200] - 389-Directory/1.2.11.15 
 B2014.219.179 starting up*
*[11/Nov/2014:13:26:35 +0200] schema-compat-plugin - warning: no 
entries set up under cn=computers, cn=compat,dc=sample,dc=example*
*[11/Nov/2014:13:26:36 +0200] - Skipping CoS Definition cn=Password 
Policy,cn=accounts,dc=sample,dc=example--no CoS Templates found, 
which should be added before the CoS Definition.*
*[11/Nov/2014:13:26:36 +0200] - Skipping CoS Definition cn=Password 
Policy,cn=accounts,dc=sample,dc=example--no CoS Templates found, 
which should be added before the CoS Definition.*
*[11/Nov/2014:13:26:36 +0200] - slapd started. Listening on All 
Interfaces port 389 for LDAP requests*
*[11/Nov/2014:13:26:36 +0200] - Listening on All Interfaces port 636 
for LDAPS requests*
*[11/Nov/2014:13:26:36 +0200] - Listening on 
/var/run/slapd-SAMPLE-EXAMPLE.socket for LDAPI requests*

*[11/Nov/2014:13:57:08 +0200] - slapd_poll(78) timed out*
*
*
*
*
*
*


On Tue, Nov 11, 2014 at 1:19 PM, Martin Basti > wrote:


IMHO It's DS bug, can you share DS error log?
pspacek CCed to examine named logs.

Martin^2


On 11/11/14 12:13, Walter van Lille wrote:

Hi Martin, thanks for the reply.
My version: bind-dyndb-ldap-2.3-5.el6.x86_64
The server doesn't have journalctl installed but I have the
outputs from the messages and named.run files that I included here:

Messages:

*Nov 11 12:30:13 freeipa named[1481]: error (network
unreachable) resolving
'example.example.com.10.123.123.123/A/IN': 2001:500:2f::f#53*
*Nov 11 12:30:23 freeipa named[1481]: LDAP query timed out. Try
to adjust "timeout" parameter*
*Nov 11 12:30:23 freeipa named[1481]: LDAP query timed out. Try
to adjust "timeout" parameter*
*Nov 11 12:30:33 freeipa named[1481]: LDAP query timed out. Try
to adjust "timeout" parameter*
*Nov 11 12:30:33 freeipa named[1481]: LDAP query timed out. Try
to adjust "timeout" parameter*

Named.run:

*client 10.123.123.123#42639: transfer of 'example.example/IN':
AXFR-style IXFR started*
*client 10.123.123.123#42639: transfer of ''example.example/IN':
AXFR-style IXFR ended*
*client 10.123.123.123#46912: transfer of
'10.123.123.123.in-addr.arpa/IN': AXFR-style IXFR started*
*client 10.123.123.123#46912: transfer of
'10.123.123.123.in-addr.arpa/IN': AXFR-style IXFR ended*
*LDAP query timed out. Try to adjust "timeout" parameter*
*LDAP query timed out. Try to adjust "timeout" parameter*
*LDAP query timed out. Try to adjust "timeout" parameter*

I just replaced the IPs and the actual names with something more
generic.

Regards,

Walter

On Thu, Nov 6, 2014 at 5:00 PM, Martin Basti mailto:mba...@redhat.com>> wrote:

On 06/11/14 14:58, Walter van Lille wrote:

Hi,

I need some assistance please.
I've taken over an IPA server to manage a few months ago,
and it was working fine until recently when it started
acting up seemingly off its own accord.
When I do an ipactl status it basically gives an output as
shown below:


*Directory Service: RUNNING
*
*
*
*Loong
pause... (To the tune of 7 minutes sometimes)*
*
*
*KDC Service: RUNNING*
*KPASSWD Service: RUNNING*
*DNS Service: RUNNING*
*MEMCACHE Service: RUNNING*
*HTTP Service: RUNNING*
*CA Service: RUNNING*
*ADTRUST Service: RUNNING*
*EXTID Service:

Re: [Freeipa-users] FreeIPA unresponsive - Causes DOS situations

[Martin Kosek]

On 11/11/2014 01:29 PM, Petr Spacek wrote:
> On 11.11.2014 13:13, Walter van Lille wrote:
>> SASL encrypted packet length exceeds
>> maximum allowed limit
> 
> Martin, do you remember where is the appropriate knob?
> 

Do you mean nsslapd-sasl-max-buffer-size setting in cn=config? This is a
related ticket

https://fedorahosted.org/389/ticket/47457

This is the public, RHEL-7.1 variant of it:
https://bugzilla.redhat.com/show_bug.cgi?id=1044193

Martin

-- 
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 unresponsive - Causes DOS situations

[Martin Basti]

Ludiwg (CCed) this seems like old (fixed?) DS bug.

On 11/11/14 13:13, Walter van Lille wrote:
I've just cleaned out a ton of slapd_poll timed out messages from the 
output and changed the names to protect the innocent, :-)

Here is the output as requested:


*[05/Nov/2014:11:44:05 +0200] - SASL encrypted packet length exceeds 
maximum allowed limit (length=805634565, limit=2097152).  Change the 
nsslapd-maxsasliosize attribute in cn=config to increase limit.*

*
*
*[10/Nov/2014:14:45:19 +0200] - slapd_poll(115) timed out*
*[10/Nov/2014:14:45:19 +0200] sasl_io_enable - Cannot enable SASL 
security on connection in CLOSING state*
*[10/Nov/2014:14:45:19 +0200] - Error: could not add/remove IO layers 
from connection*
*[11/Nov/2014:11:48:09 +0200] - slapd shutting down - signaling 
operation threads*
*[11/Nov/2014:11:48:09 +0200] - slapd shutting down - waiting for 30 
threads to terminate*
*[11/Nov/2014:13:14:12 +0200] - slapd shutting down - closing down 
internal subsystems and plugins*

*[11/Nov/2014:13:14:12 +0200] - Waiting for 4 database threads to stop*
*[11/Nov/2014:13:14:13 +0200] - All database threads now stopped*
*[11/Nov/2014:13:14:13 +0200] - slapd stopped.*
*[11/Nov/2014:13:26:35 +0200] - 389-Directory/1.2.11.15 
 B2014.219.179 starting up*
*[11/Nov/2014:13:26:35 +0200] schema-compat-plugin - warning: no 
entries set up under cn=computers, cn=compat,dc=sample,dc=example*
*[11/Nov/2014:13:26:36 +0200] - Skipping CoS Definition cn=Password 
Policy,cn=accounts,dc=sample,dc=example--no CoS Templates found, which 
should be added before the CoS Definition.*
*[11/Nov/2014:13:26:36 +0200] - Skipping CoS Definition cn=Password 
Policy,cn=accounts,dc=sample,dc=example--no CoS Templates found, which 
should be added before the CoS Definition.*
*[11/Nov/2014:13:26:36 +0200] - slapd started. Listening on All 
Interfaces port 389 for LDAP requests*
*[11/Nov/2014:13:26:36 +0200] - Listening on All Interfaces port 636 
for LDAPS requests*
*[11/Nov/2014:13:26:36 +0200] - Listening on 
/var/run/slapd-SAMPLE-EXAMPLE.socket for LDAPI requests*

*[11/Nov/2014:13:57:08 +0200] - slapd_poll(78) timed out*
*
*
*
*
*
*


On Tue, Nov 11, 2014 at 1:19 PM, Martin Basti > wrote:


IMHO It's DS bug, can you share DS error log?
pspacek CCed to examine named logs.

Martin^2


On 11/11/14 12:13, Walter van Lille wrote:

Hi Martin, thanks for the reply.
My version: bind-dyndb-ldap-2.3-5.el6.x86_64
The server doesn't have journalctl installed but I have the
outputs from the messages and named.run files that I included here:

Messages:

*Nov 11 12:30:13 freeipa named[1481]: error (network unreachable)
resolving 'example.example.com.10.123.123.123/A/IN':
2001:500:2f::f#53*
*Nov 11 12:30:23 freeipa named[1481]: LDAP query timed out. Try
to adjust "timeout" parameter*
*Nov 11 12:30:23 freeipa named[1481]: LDAP query timed out. Try
to adjust "timeout" parameter*
*Nov 11 12:30:33 freeipa named[1481]: LDAP query timed out. Try
to adjust "timeout" parameter*
*Nov 11 12:30:33 freeipa named[1481]: LDAP query timed out. Try
to adjust "timeout" parameter*

Named.run:

*client 10.123.123.123#42639: transfer of 'example.example/IN':
AXFR-style IXFR started*
*client 10.123.123.123#42639: transfer of ''example.example/IN':
AXFR-style IXFR ended*
*client 10.123.123.123#46912: transfer of
'10.123.123.123.in-addr.arpa/IN': AXFR-style IXFR started*
*client 10.123.123.123#46912: transfer of
'10.123.123.123.in-addr.arpa/IN': AXFR-style IXFR ended*
*LDAP query timed out. Try to adjust "timeout" parameter*
*LDAP query timed out. Try to adjust "timeout" parameter*
*LDAP query timed out. Try to adjust "timeout" parameter*

I just replaced the IPs and the actual names with something more
generic.

Regards,

Walter

On Thu, Nov 6, 2014 at 5:00 PM, Martin Basti mailto:mba...@redhat.com>> wrote:

On 06/11/14 14:58, Walter van Lille wrote:

Hi,

I need some assistance please.
I've taken over an IPA server to manage a few months ago,
and it was working fine until recently when it started
acting up seemingly off its own accord.
When I do an ipactl status it basically gives an output as
shown below:


*Directory Service: RUNNING
*
*
*
*Loong
pause... (To the tune of 7 minutes sometimes)*
*
*
*KDC Service: RUNNING*
*KPASSWD Service: RUNNING*
*DNS Service: RUNNING*
*MEMCACHE Service: RUNNING*
*HTTP Service: RUNNING*
*CA Service: RUNNING*
*ADTRUST Service: RUNNING*
*EXTID Service: RUNNING*

Running top showed that ns-slapd was munching almost all my
resources, but I got that fixed by upping the cache.
Unfortunately 

Re: [Freeipa-users] certmonger question

[Martin Kosek]

On 11/11/2014 01:28 PM, Natxo Asenjo wrote:
> hi Nali,
> On Tue, Nov 11, 2014 at 12:57 PM, Martin Kosek  wrote:
> 
>> So if the lurking double encoded certificate is in LDAP, and thus Apache DS
>> shows is invalid (it shows as OK in my RHEL-7.0 server), maybe the easiest 
>> way
>> to fix it would be to:
>>
>> - Open your Apache DS
>> - Back up cn=CAcert,cn=ipa,cn=etc,dc=example,dc=com
>> - Delete the cn=CAcert,cn=ipa,cn=etc,dc=example,dc=com entry
>> - Run
>>   # ipa-ldap-updater --upgrade --ldapi --quiet
>>   on your 6.5+ server and the certificate entry should get regenerated 
>> (tested
>> with 7.0).
> 
> when you write 6.5+ server you mean in the kdc/CA server, right? Just
> checking :-)
> 
> Thanks!
> 
> --
> Groeten,
> natxo
> 

I meant IPA server running on RHEL/CentOS 6.5 or older... This is the one that
can regenerate CAcert entry without double encoding.

Martin

-- 
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] Adjust settings for processes

[Alexander Bokovoy]

On Tue, 11 Nov 2014, Roman Naumenko wrote:

Alexander Bokovoy wrote on 11-11-14 6:52:

On Tue, 11 Nov 2014, Roman Naumenko wrote:
I'd like to adjust process settings on freeipa server to fit it 
better into virtual instance.
Is it possible to change settings of java, ns-slapd and apache 
processes somewhere in config files and what those files are?

http://pkgs.fedoraproject.org/cgit/httpd.git/tree/httpd.service
---
# For example, to pass additional options (for instance, -D 
definitions) to the

# httpd binary at startup, you need to create a file named
# "/etc/systemd/system/httpd.service" containing:
#.include /lib/systemd/system/httpd.service
#[Service]
#Environment=OPTIONS=-DMY_DEFINE

Isn't it for startup options only?

You've asked about settings for the processes, that's how it is done in
systemd environment. Check systemd.resource-control(5) and
systemd.exec(5) for details of what can be changed.



I need to set some of these, they are usually in httpd.conf


 StartServers   12
 MinSpareServers12
 MaxSpareServers12
 MaxClients 12
 MaxRequestsPerChild  300


This is Apache-specific config and as such should go into
/etc/httpd/conf.d/, any file with .conf suffix there is automatically
included by httpd during startup thanks to the following in
/etc/httpd/conf/httpd.conf:

# Load config files in the "/etc/httpd/conf.d" directory, if any.
IncludeOptional conf.d/*.conf

--
/ Alexander Bokovoy

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

Re: [Freeipa-users] Adjust settings for processes

[Roman Naumenko]

Alexander Bokovoy wrote on 11-11-14 6:52:

On Tue, 11 Nov 2014, Roman Naumenko wrote:
I'd like to adjust process settings on freeipa server to fit it 
better into virtual instance.
Is it possible to change settings of java, ns-slapd and apache 
processes somewhere in config files and what those files are?

http://pkgs.fedoraproject.org/cgit/httpd.git/tree/httpd.service
---
# For example, to pass additional options (for instance, -D 
definitions) to the

# httpd binary at startup, you need to create a file named
# "/etc/systemd/system/httpd.service" containing:
#.include /lib/systemd/system/httpd.service
#[Service]
#Environment=OPTIONS=-DMY_DEFINE

Isn't it for startup options only?

I need to set some of these, they are usually in httpd.conf


  StartServers   12
  MinSpareServers12
  MaxSpareServers12
  MaxClients 12
  MaxRequestsPerChild  300


--Roman

--
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 unresponsive - Causes DOS situations

[Petr Spacek]

On 11.11.2014 13:13, Walter van Lille wrote:
> SASL encrypted packet length exceeds
> maximum allowed limit

Martin, do you remember where is the appropriate knob?

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

Re: [Freeipa-users] certmonger question

[Natxo Asenjo]

hi Nali,
On Tue, Nov 11, 2014 at 12:57 PM, Martin Kosek  wrote:

> So if the lurking double encoded certificate is in LDAP, and thus Apache DS
> shows is invalid (it shows as OK in my RHEL-7.0 server), maybe the easiest way
> to fix it would be to:
>
> - Open your Apache DS
> - Back up cn=CAcert,cn=ipa,cn=etc,dc=example,dc=com
> - Delete the cn=CAcert,cn=ipa,cn=etc,dc=example,dc=com entry
> - Run
>   # ipa-ldap-updater --upgrade --ldapi --quiet
>   on your 6.5+ server and the certificate entry should get regenerated (tested
> with 7.0).

when you write 6.5+ server you mean in the kdc/CA server, right? Just
checking :-)

Thanks!

--
Groeten,
natxo

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

Re: [Freeipa-users] FreeIPA unresponsive - Causes DOS situations

[Walter van Lille]

I've just cleaned out a ton of slapd_poll timed out messages from the
output and changed the names to protect the innocent, :-)
Here is the output as requested:


*[05/Nov/2014:11:44:05 +0200] - SASL encrypted packet length exceeds
maximum allowed limit (length=805634565, limit=2097152).  Change the
nsslapd-maxsasliosize attribute in cn=config to increase limit.*

*[10/Nov/2014:14:45:19 +0200] - slapd_poll(115) timed out*
*[10/Nov/2014:14:45:19 +0200] sasl_io_enable - Cannot enable SASL security
on connection in CLOSING state*
*[10/Nov/2014:14:45:19 +0200] - Error: could not add/remove IO layers from
connection*
*[11/Nov/2014:11:48:09 +0200] - slapd shutting down - signaling operation
threads*
*[11/Nov/2014:11:48:09 +0200] - slapd shutting down - waiting for 30
threads to terminate*
*[11/Nov/2014:13:14:12 +0200] - slapd shutting down - closing down internal
subsystems and plugins*
*[11/Nov/2014:13:14:12 +0200] - Waiting for 4 database threads to stop*
*[11/Nov/2014:13:14:13 +0200] - All database threads now stopped*
*[11/Nov/2014:13:14:13 +0200] - slapd stopped.*
*[11/Nov/2014:13:26:35 +0200] - 389-Directory/1.2.11.15 
B2014.219.179 starting up*
*[11/Nov/2014:13:26:35 +0200] schema-compat-plugin - warning: no entries
set up under cn=computers, cn=compat,dc=sample,dc=example*
*[11/Nov/2014:13:26:36 +0200] - Skipping CoS Definition cn=Password
Policy,cn=accounts,dc=sample,dc=example--no CoS Templates found, which
should be added before the CoS Definition.*
*[11/Nov/2014:13:26:36 +0200] - Skipping CoS Definition cn=Password
Policy,cn=accounts,dc=sample,dc=example--no CoS Templates found, which
should be added before the CoS Definition.*
*[11/Nov/2014:13:26:36 +0200] - slapd started.  Listening on All Interfaces
port 389 for LDAP requests*
*[11/Nov/2014:13:26:36 +0200] - Listening on All Interfaces port 636 for
LDAPS requests*
*[11/Nov/2014:13:26:36 +0200] - Listening on
/var/run/slapd-SAMPLE-EXAMPLE.socket for LDAPI requests*
*[11/Nov/2014:13:57:08 +0200] - slapd_poll(78) timed out*





On Tue, Nov 11, 2014 at 1:19 PM, Martin Basti  wrote:

>  IMHO It's DS bug, can you share DS error log?
> pspacek CCed to examine named logs.
>
> Martin^2
>
>
> On 11/11/14 12:13, Walter van Lille wrote:
>
> Hi Martin, thanks for the reply.
> My version: bind-dyndb-ldap-2.3-5.el6.x86_64
> The server doesn't have journalctl installed but I have the outputs from
> the messages and named.run files that I included here:
>
>  Messages:
>
>  *Nov 11 12:30:13 freeipa named[1481]: error (network unreachable)
> resolving 'example.example.com.10.123.123.123/A/IN': 2001:500:2f::f#53*
> *Nov 11 12:30:23 freeipa named[1481]: LDAP query timed out. Try to adjust
> "timeout" parameter*
> *Nov 11 12:30:23 freeipa named[1481]: LDAP query timed out. Try to adjust
> "timeout" parameter*
> *Nov 11 12:30:33 freeipa named[1481]: LDAP query timed out. Try to adjust
> "timeout" parameter*
> *Nov 11 12:30:33 freeipa named[1481]: LDAP query timed out. Try to adjust
> "timeout" parameter*
>
>  Named.run:
>
>  *client 10.123.123.123#42639: transfer of 'example.example/IN':
> AXFR-style IXFR started*
> *client 10.123.123.123#42639: transfer of ''example.example/IN':
> AXFR-style IXFR ended*
> *client 10.123.123.123#46912: transfer of
> '10.123.123.123.in-addr.arpa/IN': AXFR-style IXFR started*
> *client 10.123.123.123#46912: transfer of
> '10.123.123.123.in-addr.arpa/IN': AXFR-style IXFR ended*
> *LDAP query timed out. Try to adjust "timeout" parameter*
> *LDAP query timed out. Try to adjust "timeout" parameter*
> *LDAP query timed out. Try to adjust "timeout" parameter*
>
>  I just replaced the IPs and the actual names with something more generic.
>
>  Regards,
>
>  Walter
>
> On Thu, Nov 6, 2014 at 5:00 PM, Martin Basti  wrote:
>
>>   On 06/11/14 14:58, Walter van Lille wrote:
>>
>> Hi,
>>
>>  I need some assistance please.
>> I've taken over an IPA server to manage a few months ago, and it was
>> working fine until recently when it started acting up seemingly off its own
>> accord.
>> When I do an ipactl status it basically gives an output as shown below:
>>
>>
>>
>> *Directory Service: RUNNING *
>>
>>  *Loong pause... (To the
>> tune of 7 minutes sometimes)*
>>
>>  *KDC Service: RUNNING*
>> *KPASSWD Service: RUNNING*
>> *DNS Service: RUNNING*
>> *MEMCACHE Service: RUNNING*
>> *HTTP Service: RUNNING*
>> *CA Service: RUNNING*
>> *ADTRUST Service: RUNNING*
>> *EXTID Service: RUNNING*
>>
>>  Running top showed that ns-slapd was munching almost all my resources,
>> but I got that fixed by upping the cache. Unfortunately this did not
>> correct the issue and it still reacts in the same fashion, although the
>> resources have been freed up now.
>> I've noticed that when I run dig on either the local server or a remote
>> machine that the query basically just times out as shown here:
>>
>>   *dig freeipa.myexample.sample*
>>
>>  *; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>>
>> freeipa

Re: [Freeipa-users] certmonger question

[Martin Kosek]

On 11/11/2014 08:48 AM, Natxo Asenjo wrote:
> Hi Nalin,
> 
> On Mon, Nov 10, 2014 at 5:19 PM, Nalin Dahyabhai  wrote:
>> On Mon, Nov 10, 2014 at 04:17:49PM +0100, Natxo Asenjo wrote:
>>> How can I debug this?
>>
>> First thing would be to run the daemon with additional logging - I
>> usually use '-d3' to watch what's going on while the daemon's running
>> various tasks.
> 
> wow, yes. Now you can debug ;-)
> 
> I got this sequential message until the certmonger daemon died (unly
> posting a small portion):
> 
> 2014-11-11 08:34:28 [8610] Will revisit CA5('local').certs on traffic from 
> 1020.
> 2014-11-11 08:34:28 [8610] CA5('local').certs moved to state 'NEED_TO_REFRESH'
> 2014-11-11 08:34:28 [8610] Will revisit CA5('local').certs in
> 1481416576 seconds.
> 2014-11-11 08:34:28 [8610] CA5('local').certs moved to state 'REFRESHING'
> 2014-11-11 08:34:28 [8610] Will revisit CA5('local').certs on traffic from 
> 1022.
> 2014-11-11 08:34:28 [8610] Will revisit CA5('local').certs on traffic from 
> 1022.
> 2014-11-11 08:34:28 [8610] CA5('local').certs data is unchanged
> 2014-11-11 08:34:28 [8610] CA5('local').certs moved to state 'NEED_TO_ANALYZE'
> 2014-11-11 08:34:28 [8610] Will revisit CA5('local').certs now.
> 2014-11-11 08:34:28 [8610] CA5('local').certs moved to state 'ANALYZING'
> 2014-11-11 08:34:28 [8610] Will revisit CA5('local').certs on traffic from 
> 1021.
> 2014-11-11 08:34:28 [11672] Certificate "Local Signing Authority"
> valid for 31473673s.
> 2014-11-11 08:34:28 [11672] Running result is 1481416576.
> 2014-11-11 08:34:28 [11672] Final result is 1481416576.
> 2014-11-11 08:34:28 [8610] Will revisit CA5('local').certs on traffic from 
> 1021.
> 2014-11-11 08:34:28 [8610] CA5('local').certs moved to state 'NEED_TO_REFRESH'
> 2014-11-11 08:34:28 [8610] Will revisit CA5('local').certs in
> 1481416576 seconds.
> 2014-11-11 08:34:28 [8610] CA5('local').certs moved to state 'REFRESHING'
> 2014-11-11 08:34:28 [8610] Will revisit CA5('local').certs soon.
> 2014-11-11 08:34:33 [8610] CA5('local').certs data is unchanged
> 2014-11-11 08:34:33 [8610] CA5('local').certs moved to state 'NEED_TO_ANALYZE'
> 2014-11-11 08:34:33 [8610] Will revisit CA5('local').certs now.
> 2014-11-11 08:34:33 [8610] CA5('local').certs moved to state 'ANALYZING'
> 2014-11-11 08:34:33 [8610] Will revisit CA5('local').certs on traffic from 
> 1022.
> 2014-11-11 08:34:33 [11677] Certificate "Local Signing Authority"
> valid for 31473668s.
> 2014-11-11 08:34:33 [11677] Running result is 1481416576.
> 2014-11-11 08:34:33 [11677] Final result is 1481416576.
> 2014-11-11 08:34:33 [8610] Will revisit CA5('local').certs on traffic from 
> 1022.
> 2014-11-11 08:34:33 [8610] CA5('local').certs moved to state 'NEED_TO_REFRESH'
> 2014-11-11 08:34:33 [8610] Will revisit CA5('local').certs in
> 1481416576 seconds.
> 2014-11-11 08:34:33 [8610] CA5('local').certs moved to state 'REFRESHING'
> 2014-11-11 08:34:33 [8610] Will revisit CA5('local').certs soon.
> 2014-11-11 08:34:38 [8610] CA5('local').certs data is unchanged
> 2014-11-11 08:34:38 [8610] CA5('local').certs moved to state 'NEED_TO_ANALYZE'
> 2014-11-11 08:34:38 [8610] Will revisit CA5('local').certs now.
> Killed
> 
>> The data logged with the Decoding Error looks like a certificate that's
>> been base64-encoded, and then base64-encoded again, which is very odd,
>> since that error message is logged in cases where it fails to parse a
>> root certificate that it has just retrieved from the CA, and that data
>> shouldn't have been mangled like that.
>>
>> Can you check the contents of the "caCertificate" attribute in the
>> "cn=cacert,cn=ipa,cn=etc" entry under the IPA base DN in the directory
>> server, and perhaps provide them?  They can be retrieved using a command
>> like:
>>ldapsearch -b cn=cacert,cn=ipa,cn=etc,$SUFFIX -s base -Y GSSAPI 
>> caCertificate
>>
>> The attribute values are supposed to be certificates in binary form,
>> which ldapsearch will likely base64-encode for display -- ldapsearch
>> will indicate that it's doing this by separating the attribute name from
>> the value using two colons ('::') instead of the usual one (':') in its
>> output, in accordance with ldif(5).
> 
> using the apache directory studio I see in the attr
> cacertificate;binary: invalid certificate (1240 bytes).
> 
> Using your command I get:
> 
> $ ldapsearch -b cn=cacert,cn=ipa,cn=etc,dc=domain,dc=tld -Y GSSAPI
> caCertificate -h kdc01.domain.tld
> SASL/GSSAPI authentication started
> SASL username: user.ad...@domain.tld
> SASL SSF: 56
> SASL data security layer installed.
> # extended LDIF
> #
> # LDAPv3
> # base  with scope subtree
> # filter: (objectclass=*)
> # requesting: caCertificate
> #
> 
> # CACert, ipa, etc, domain.tld
> dn: cn=CACert,cn=ipa,cn=etc,dc=domain,dc=tld
> cACertificate;binary:: TUlJRG5EQ0NBb1NnQXdJQkFnSUJBVEFOQmdrcWhraUc5dzBCQVFzRkF
>  EQTdNUmt3RndZRFZRUUtFeEJWVGtsWUxrbFNTVk5hVDFKSExrNU1NUjR3SEFZRFZRUURFeFZEWlhK
>  MGFXWnBZMkYwWlNCQmRYUm9iM0pwZEhrd0hoY05NVEl4TVRBM0

[Freeipa-users] Installed OpenSSH server does not support dynamically loading authorized user keys - no key login support

[Vaclav Adamec]

Hi,
 I'm getting "Installed OpenSSH server does not support dynamically loading
authorized user keys. Public key authentication of IPA users will not be
available" during ipa client install on CentOS 6.6

Packages openssh-server-6.1p1-5.el6.1.x86_64 and
ipa-client-3.0.0-42.el6.centos.x86_64

Manual setup of  "AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys" in
/etc/ssh/sshd_config is ok.

Any reason for that ?

Thanks

Vasek
-- 
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] Adjust settings for processes

[Alexander Bokovoy]

On Tue, 11 Nov 2014, Roman Naumenko wrote:
I'd like to adjust process settings on freeipa server to fit it better 
into virtual instance.
Is it possible to change settings of java, ns-slapd and apache 
processes somewhere in config files and what those files are?

http://pkgs.fedoraproject.org/cgit/httpd.git/tree/httpd.service
---
# For example, to pass additional options (for instance, -D definitions) to the
# httpd binary at startup, you need to create a file named
# "/etc/systemd/system/httpd.service" containing:
#   .include /lib/systemd/system/httpd.service
#   [Service]
#   Environment=OPTIONS=-DMY_DEFINE

---

--
/ Alexander Bokovoy

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

Re: [Freeipa-users] DNS and $GENERATE Directive

[Petr Spacek]

On 10.11.2014 09:25, Martin Kosek wrote:
> On 11/08/2014 12:16 AM, Andrew Powell wrote:
>> Is there a way to add a Bind $GENERATE directive line to FreeIPA to
>> automatically name DHCP-assigned ranges?
>>
>> In a file-based Bind installation, I can have the following line in the 
>> forward
>> example.com zone file:
>>
>> $generate 80-250/1 wd${0,3,d}.example.com. A 192.168.0.$
>>
>> (which adds records wd080.example.com thru wd250.example.com)
>>
>> And for the reverse zone (0.168.192.in-addr.arpa) I can have the following 
>> line:
>>
>> $generate 80-250/1 $ PTR wd${0,3,d}.example.com.
>>
>> I can do without naming the DHCP-assigned ranges, but it seems like the 
>> proper
>> thing to do.
>>
> 
> Interesting question. I do not think bind-dyndb-ldap supports the $GENERATE
> directive. I am not even sure how to extend LDAP DNS tree to support it as it
> has a very specific syntax. You would need to add a new LDAP space accepting
> strings that would be then passed to BIND... I will let Petr to assess if this
> is possible or not.
We would have to re-implement the $GENERATE logic ourselves (and find a way
how to store it in LDAP).

It would complicate dynamic updates a lot so I would rather avoid implementing
this in bind-dyndb-ldap.

> For now, the best approach would be to either add all these records to LDAP or
> to have it in a BIND zone file and synchronize between all FreeIPA DNS 
> servers.

I would recommend to simply use ipa dnsrecord-add command in a for cycle to
add all the records.

ipa dnsrecord-generate command could generate set of LDAP objects too and it
would not require any changes in bind-dyndb-ldap... But I'm not sure if there
is a real benefit. IMHO it would be better to implement
https://fedorahosted.org/freeipa/ticket/4706
Seed managed DNS domain from existing domain

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

[Freeipa-users] Adjust settings for processes

[Roman Naumenko]

I'd like to adjust process settings on freeipa server to fit it better 
into virtual instance.
Is it possible to change settings of java, ns-slapd and apache processes 
somewhere in config files and what those files are?


For example: ServerLimit, StartServers and things like that typically 
set for apache mpm, but I couldn't find relevant options in /etc/httpd


apachectl status
httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled)
   Active: active (running) since Sun 2014-10-26 16:19:24 UTC; 1 weeks 
5 days ago

 Main PID: 1546 (httpd)
   Status: "Total requests: 0; Current requests/sec: 0; Current 
traffic:   0 B/sec"

   CGroup: /system.slice/httpd.service
   |- 1546 /usr/sbin/httpd -DFOREGROUND
   |- 1547 /usr/libexec/nss_pcache 98307 off /etc/httpd/alias
   |-17436 /usr/sbin/httpd -DFOREGROUND
   |-17437 /usr/sbin/httpd -DFOREGROUND
   |-17438 /usr/sbin/httpd -DFOREGROUND
   |-17439 /usr/sbin/httpd -DFOREGROUND
   |-17440 /usr/sbin/httpd -DFOREGROUND
   |-17441 /usr/sbin/httpd -DFOREGROUND
   |-17442 /usr/sbin/httpd -DFOREGROUND
   |-18416 /usr/sbin/httpd -DFOREGROUND
   `-22003 /usr/sbin/httpd -DFOREGROUND

Nov 06 13:23:03 ipa httpd[17436]: GSSAPI client step 1
Nov 06 13:23:03 ipa httpd[17436]: GSSAPI client step 2
Nov 06 13:23:03 ipa httpd[17437]: GSSAPI client step 1
Nov 06 13:23:03 ipa httpd[17437]: GSSAPI client step 1
Nov 06 13:23:03 ipa httpd[17437]: GSSAPI client step 1
Nov 06 13:23:03 ipa httpd[17437]: GSSAPI client step 2
Nov 06 13:23:04 ipa httpd[17436]: GSSAPI client step 1
Nov 06 13:23:04 ipa httpd[17436]: GSSAPI client step 1
Nov 06 13:23:04 ipa httpd[17436]: GSSAPI client step 1
Nov 06 13:23:04 ipa httpd[17436]: GSSAPI client step 2

--Roman
-- 
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 unresponsive - Causes DOS situations

[Martin Basti]

IMHO It's DS bug, can you share DS error log?
pspacek CCed to examine named logs.

Martin^2

On 11/11/14 12:13, Walter van Lille wrote:

Hi Martin, thanks for the reply.
My version: bind-dyndb-ldap-2.3-5.el6.x86_64
The server doesn't have journalctl installed but I have the outputs 
from the messages and named.run files that I included here:


Messages:

*Nov 11 12:30:13 freeipa named[1481]: error (network unreachable) 
resolving 'example.example.com.10.123.123.123/A/IN': 2001:500:2f::f#53*
*Nov 11 12:30:23 freeipa named[1481]: LDAP query timed out. Try to 
adjust "timeout" parameter*
*Nov 11 12:30:23 freeipa named[1481]: LDAP query timed out. Try to 
adjust "timeout" parameter*
*Nov 11 12:30:33 freeipa named[1481]: LDAP query timed out. Try to 
adjust "timeout" parameter*
*Nov 11 12:30:33 freeipa named[1481]: LDAP query timed out. Try to 
adjust "timeout" parameter*


Named.run:

*client 10.123.123.123#42639: transfer of 'example.example/IN': 
AXFR-style IXFR started*
*client 10.123.123.123#42639: transfer of ''example.example/IN': 
AXFR-style IXFR ended*
*client 10.123.123.123#46912: transfer of 
'10.123.123.123.in-addr.arpa/IN': AXFR-style IXFR started*
*client 10.123.123.123#46912: transfer of 
'10.123.123.123.in-addr.arpa/IN': AXFR-style IXFR ended*

*LDAP query timed out. Try to adjust "timeout" parameter*
*LDAP query timed out. Try to adjust "timeout" parameter*
*LDAP query timed out. Try to adjust "timeout" parameter*

I just replaced the IPs and the actual names with something more generic.

Regards,

Walter

On Thu, Nov 6, 2014 at 5:00 PM, Martin Basti > wrote:


On 06/11/14 14:58, Walter van Lille wrote:

Hi,

I need some assistance please.
I've taken over an IPA server to manage a few months ago, and it
was working fine until recently when it started acting up
seemingly off its own accord.
When I do an ipactl status it basically gives an output as shown
below:


*Directory Service: RUNNING
*
*
*
*Loong pause...
(To the tune of 7 minutes sometimes)*
*
*
*KDC Service: RUNNING*
*KPASSWD Service: RUNNING*
*DNS Service: RUNNING*
*MEMCACHE Service: RUNNING*
*HTTP Service: RUNNING*
*CA Service: RUNNING*
*ADTRUST Service: RUNNING*
*EXTID Service: RUNNING*

Running top showed that ns-slapd was munching almost all my
resources, but I got that fixed by upping the cache.
Unfortunately this did not correct the issue and it still reacts
in the same fashion, although the resources have been freed up now.
I've noticed that when I run dig on either the local server or a
remote machine that the query basically just times out as shown here:

*dig freeipa.myexample.sample*
*
*
*; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>>
freeipa.myexample.sample*
*;; global options: +cmd*
*;; connection timed out; no servers could be reached*

When the KDC service fails to start, then name lookups seem OK,
but authentication fails. otherwise it's dead in the water.

This also happens:

*sudo ipactl status*
*Directory Service: RUNNING*
*Unknown error when retrieving list of services from LDAP:*
*
*
My software setup is as follows:

*CentOS release 6.5 (Final)
*
*389-ds-base.x86_64   1.2.11.15-34.el6_5
*
*bind.x86_64  32:9.8.2-0.23.rc1.el6_5.1
*
*bind-dyndb-ldap.x86_64*
*bind-libs.x86_64 32:9.8.2-0.23.rc1.el6_5.1*
*bind-utils.x86_64  32:9.8.2-0.23.rc1.el6_5.1*
*rpcbind.x86_64   0.2.0-11.el6  
@anaconda-CentOS-201311291202.x86_64/6.5*

*samba4-winbind.x86_64*
*krb5-server.x86_64   1.10.3-15.el6_5.1
*
*
*
*Linux 2.6.32-431.29.2.el6.x86_64 #1 SMP Tue Sep 9 21:36:05 UTC
2014 x86_64 x86_64 x86_64 GNU/Linux
*

It's not a permanent situation as it sometimes runs 100% for a
while, but 80% of the time it is unusable. If anybody can assist
me, please be so kind.

Regards,

Walter


Hello please which version of bind-dyndb-ldap do you use?
I had similar issue with bind-dyndb-ldap, but it was development
version, I'm not sure if this is your case.
When named was failing, dirserv was really slow.

Can you send journalctl -b -u named log when dig doesn't work??

-- 
Martin Basti






--
Martin Basti

-- 
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] Free ipa Configurations

[Petr Vobornik]

On 11.11.2014 11:11, Jakub Hrozek wrote:

On Tue, Nov 11, 2014 at 02:07:57AM -0800, Rolf Nufable wrote:

well I'm trying to setup sudo in my client machine, also I want to access the 
server web browser In the client machine ( is it possible though ? )

well I'm having this error in the client side when using the command su - ( 
user )

su - u...@example.com

su : u...@example.com does not exist.


Are you sure ipa-client-install did run successfully on that machine?

Can you unenroll and enroll the client back so that we start from an
sssd.conf that is created by the tooling?

As Martin said, you don't need those sudo-related config options with
recent SSSD releases, they wouldn't work in the sudo section anyway.


Does:

$ id u...@example.com

return you the user info?

if not and ipa-client-install was run successfully before, check 
nsswitch.conf if it has sssd configured (sss next to various providers).


if not run:
$ authconfig --enablesssd --update

if it doesn't help, try to run:
$ authconfig --disablesssd --update
$ authconfig --enablesssd --update

if it helps, please tell me. I'm curious if you suffer from one issue I 
experienced.









On Tuesday, November 11, 2014 5:56 PM, Martin Kosek  wrote:



It is still really hard to give advise as I do not know what's actually wrong.
So are you trying to set up a sudo on your client or are you trying to log in
with your client browser to FreeIPA server? These are 2 orthogonal actions.

Who gives the "Can't I connect to the ipa server" error? As I said earlier, I
cannot help you without described procedure you are trying to do, logs and
exact error messages.

Martin


On 11/11/2014 09:32 AM, Rolf Nufable wrote:

never mind the problem on the server side, somehow it got fixed , I really 
don't know how though

so in the client side , It is successful when installing free ipa client and the

  server discovery is fine, my freipa Client is 4.1.0 and my server is 4.0.3 
(although somewhere I've read that version incompatibility would not be an 
issue since if either one is of a lower version, the only features that would 
be used is the one that the lower version can do )


So I really don't know why Can't I connect to the ipa server.

Iptables works fine.
/etc/resolv.conf is file as well

sssd/sssd.conf ( added these lines )
[sudo]
sudo_provider = ldap
ldap_uri = ldap://myipaserver.example.com
ldap_sudo_search_base = ou=sudoers,dc=example,dc=com
ldap_sasl_mech = GSSAPI
ldap_sasl_authid = host/myipaserver.example.com
ldap_sasl_realm = EXAMPLE.COM
krb_server = myipaserver.example.com


and /etc/nsswitch.conf
(added this line )

sudoers : files sss ldap

is there something missing ?



On Tuesday, November 11, 2014 3:45 PM, Rolf Nufable  
wrote:



oh sorry I forgot that on the clients side " network.negotiate-auth.trusted-uris 
" they have the same domain as of the server side I've configured it as well as in 
the client side because recent guides for deploying IPA says that you must go to 
about:config either

  you are on the server or client side, or at least thats what I remember.


Wait a sec I'm trying to achieve the state again where the server side wont let 
me log in using the admin credentials , just so i could show you the logs




On Tuesday, November 11, 2014 3:28 PM, Martin Kosek  wrote:



On 11/11/2014 08:07 AM, Rolf Nufable wrote:

well I dont know how or what command to use to display the logs, could you 
teach me how?


There should be HOWTO articles on how to do that. Jakub may have better
sources, but I see for

  example:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/SSSD-Troubleshooting.html


, but yes the network.negotiate-auth.trusted-uris has the same domain name 
which is example.com this is on the server side only


network.negotiate-auth.trusted-uris must be set in the *client* Firefox machine.


while on the client side, even

  though the network.negotiate-auth.trusted-uris is configured correctly, the 
web UI can't be accessed so its a really weird scenario. but the registration 
of the ipa client to the server says its successful.

FreeIPA 4.0+ Web UI should allow you to login at least with your user+password,
if SSO login fails. Does at least this part work? Because if not, there is some
error on the server side. It would be interesting to check if there are no
errors on the server in following logs:
- /var/log/httpd/error_log
- /var/log/krb5kdc.log





TIA


On Tuesday, November 11, 2014 2:56 PM, Martin Kosek  wrote:



On 11/11/2014 06:37 AM, Rolf Nufable

  wrote:

or could you guys direct me or guide me on how to deploy this ipa server? I've 
been successful deploying ipa version 3.3.5 before but this 4.0 and above 
series is really giving me a headache


Hm, that is worrying. FreeIPA 4.0+ should definitely not be more difficult to
deploy, on the

  contrary, it should be much cooler than 3.3.



On Tuesday, November 11, 2014 1:24 PM, Rolf Nufable  
wrote:



well 

Re: [Freeipa-users] strange error deleting replica?

[Martin Kosek]

On 11/10/2014 06:58 PM, Janelle wrote:
> Hi --
> 
> Has anyone seen this before?
> 
> # ipa-replica-manage del kermit.xyzzy.com --force
> unexpected error: [Errno -2] Name or service not known
> 
> ?? Very confused as to What service or name is not known?
> 
> This is 4.0.5 running on CentOS  7.
> 
> ~J

This is usually DNS resolution error, though the command should not crash this 
way.

Does follow resolution work?

$ host `hostname`
$ host kermit.xyzzy.com

Alternatively, if you are not sure which DNS resolution fails, we could look at
strace output:

$ strace -o ipa.strace ipa-replica-manage del kermit.xyzzy.com --force

That would create a log caled ipa.strace with all system calls of
ipa-replica-manage del command and we would see which DNS resolution failed.

Martin

-- 
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] Free ipa Configurations

[Jakub Hrozek]

On Tue, Nov 11, 2014 at 02:07:57AM -0800, Rolf Nufable wrote:
> well I'm trying to setup sudo in my client machine, also I want to access the 
> server web browser In the client machine ( is it possible though ? ) 
> 
> well I'm having this error in the client side when using the command su - ( 
> user ) 
> 
> su - u...@example.com
> 
> su : u...@example.com does not exist. 

Are you sure ipa-client-install did run successfully on that machine? 

Can you unenroll and enroll the client back so that we start from an
sssd.conf that is created by the tooling?

As Martin said, you don't need those sudo-related config options with
recent SSSD releases, they wouldn't work in the sudo section anyway.

> 
> 
> 
> On Tuesday, November 11, 2014 5:56 PM, Martin Kosek  wrote:
>  
> 
> 
> It is still really hard to give advise as I do not know what's actually wrong.
> So are you trying to set up a sudo on your client or are you trying to log in
> with your client browser to FreeIPA server? These are 2 orthogonal actions.
> 
> Who gives the "Can't I connect to the ipa server" error? As I said earlier, I
> cannot help you without described procedure you are trying to do, logs and
> exact error messages.
> 
> Martin
> 
> 
> On 11/11/2014 09:32 AM, Rolf Nufable wrote:
> > never mind the problem on the server side, somehow it got fixed , I really 
> > don't know how though
> > 
> > so in the client side , It is successful when installing free ipa client 
> > and the
>  server discovery is fine, my freipa Client is 4.1.0 and my server is 4.0.3 
> (although somewhere I've read that version incompatibility would not be an 
> issue since if either one is of a lower version, the only features that would 
> be used is the one that the lower version can do ) 
> > 
> > So I really don't know why Can't I connect to the ipa server. 
> > 
> > Iptables works fine.
> > /etc/resolv.conf is file as well 
> > 
> > sssd/sssd.conf ( added these lines ) 
> > [sudo]
> > sudo_provider = ldap
> > ldap_uri = ldap://myipaserver.example.com
> > ldap_sudo_search_base = ou=sudoers,dc=example,dc=com
> > ldap_sasl_mech = GSSAPI
> > ldap_sasl_authid = host/myipaserver.example.com
> > ldap_sasl_realm = EXAMPLE.COM
> > krb_server = myipaserver.example.com
> > 
> > 
> > and /etc/nsswitch.conf
> > (added this line ) 
> > 
> > sudoers : files sss ldap
> > 
> > is there something missing ? 
> > 
> > 
> > 
> > On Tuesday, November 11, 2014 3:45 PM, Rolf Nufable 
> >  wrote:
> >  
> > 
> > 
> > oh sorry I forgot that on the clients side " 
> > network.negotiate-auth.trusted-uris " they have the same domain as of the 
> > server side I've configured it as well as in the client side because recent 
> > guides for deploying IPA says that you must go to about:config either
>  you are on the server or client side, or at least thats what I remember. 
> > 
> > Wait a sec I'm trying to achieve the state again where the server side wont 
> > let me log in using the admin credentials , just so i could show you the 
> > logs 
> > 
> > 
> > 
> > 
> > On Tuesday, November 11, 2014 3:28 PM, Martin Kosek  
> > wrote:
> >  
> > 
> > 
> > On 11/11/2014 08:07 AM, Rolf Nufable wrote:
> >> well I dont know how or what command to use to display the logs, could you 
> >> teach me how?
> > 
> > There should be HOWTO articles on how to do that. Jakub may have better
> > sources, but I see for
>  example:
> > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/SSSD-Troubleshooting.html
> > 
> >> , but yes the network.negotiate-auth.trusted-uris has the same domain name 
> >> which is example.com this is on the server side only
> > 
> > network.negotiate-auth.trusted-uris must be set in the *client* Firefox 
> > machine.
> > 
> >> while on the client side, even
> >  though the network.negotiate-auth.trusted-uris is configured correctly, 
> > the web UI can't be accessed so its a really weird scenario. but the 
> > registration of the ipa client to the server says its successful. 
> > 
> > FreeIPA 4.0+ Web UI should allow you to login at least with your 
> > user+password,
> > if SSO login fails. Does at least this part work? Because if not, there is 
> > some
> > error on the server side. It would be interesting to check if there are no
> > errors on the server in following logs:
> > - /var/log/httpd/error_log
> > - /var/log/krb5kdc.log
> > 
> > 
> > 
> >>
> >> TIA 
> >>
> >>
> >> On Tuesday, November 11, 2014 2:56 PM, Martin Kosek  
> >> wrote:
> >>  
> >>
> >>
> >> On 11/11/2014 06:37 AM, Rolf Nufable
>  wrote:
> >>> or could you guys direct me or guide me on how to deploy this ipa server? 
> >>> I've been successful deploying ipa version 3.3.5 before but this 4.0 and 
> >>> above series is really giving me a headache 
> >>
> >> Hm, that is worrying. FreeIPA 4.0+ should definitely not be more difficult 
> >> to
> >> deploy, on the
> >  contrary, it should be much cooler than 3.3.
> >>
> >>> On Tuesday, November 11, 2014 1:24 PM, Rolf Nufable 

Re: [Freeipa-users] Free ipa Configurations

[Jakub Hrozek]

On Tue, Nov 11, 2014 at 07:56:14AM +0100, Martin Kosek wrote:
> On 11/11/2014 06:37 AM, Rolf Nufable wrote:
> > or could you guys direct me or guide me on how to deploy this ipa server? 
> > I've been successful deploying ipa version 3.3.5 before but this 4.0 and 
> > above series is really giving me a headache 
> 
> Hm, that is worrying. FreeIPA 4.0+ should definitely not be more difficult to
> deploy, on the contrary, it should be much cooler than 3.3.
> 
> > On Tuesday, November 11, 2014 1:24 PM, Rolf Nufable 
> >  wrote:
> >  
> > 
> > 
> > well I'll try them now, my sssd config only consists of these lines added 
> > to the sudo area 
> > 
> > sudo_provider = ldap
> > ldap_uri = ldap://myipaserver.example.com
> > ldap_sudo_search_base = ou=sudoers,dc=example,dc=com
> > ldap_sasl_mech = GSSAPI
> > ldap_sasl_authid = host/myipaserver.example.com
> > ldap_sasl_realm = EXAMPLE.COM
> > krb_server = myipaserver.example.com
> 
> BWT, with FreeIPA 4.0+ / RHEL-6.6+ / recent Fedoras you can use "ipa" sudo
> provider. Actually, FreeIPA 4.0+ clients do that for you.

Right, in addition, the above should have been added to the domain
section, not the sudo section with older clients..

> 
> More info here:
> https://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf
> https://fedorahosted.org/freeipa/ticket/3358
> 
> > plus another question why is it that when I invoke the kinit admin command 
> > for the kerberos I couldnt access the web UI and keeps asking me to 
> > configure my web browser ( firefox) though I've already configured it many 
> > times.. 
> 
> Are you sure that network.negotiate-auth.trusted-uris in about:config
> correctly? Are you saying that your Firefox works with FreeIPA 3.3 server but
> not with FreeIPA 4.0+? What is the domain of the FreeIPA 4.0+ server and what
> is the setting of network.negotiate-auth.trusted-uris?
> 
> In any case, it is still hard to advise as I still did not see any related
> logs, error messages or actual real errors preventing you from enrolling 
> FreeIPA.
> 
> Thanks,
> Martin
> 
> > 
> > 
> > TIA 
> > 
> > 
> > 
> > On Monday, November 10, 2014 8:41 PM, Jakub Hrozek  
> > wrote:
> >  
> > 
> > 
> > On Mon, Nov 10, 2014 at 12:56:00PM +0100, Martin Kosek wrote:
> > 
> >> On 11/10/2014 02:05 AM, Rolf
> >  Nufable wrote:
> >>> Hello 
> >>>
> >>> I have tons of questions on why free ipa wont't work on my network , I've 
> >>> been using fedora 20 as the os for the server and client free ipa .
> >>>
> >>> I deployed freeipa 4.0.3 at the server side and freeipa 4.1.0 for the 
> >>> client side using 2 VM's at first it was okay, got it connected and used 
> >>> ldap to pass sudo for the client side, but when I finally deployed it in 
> >>> our real network consisting of an esxi server and one work station having 
> >>> the same versions of free ipa for server and client, the error that I'm 
> >>> getting is that " the user does not exist " when I invoked the " su - ( 
> >>> user ) " command, so My question is how can I solve this problem?? I've 
> >>> been at it for 3 weeks now ..
> >>
> >> I assume this is on Fedora 20, running from the mkosek/freeipa Copr repo. I
> >> assume this is a problem in SSSD client part, if the user cannot be found.
> >> CCing Lukas and Jakub to advise.
> > 
> > Sorry, I skipped this thread b/c the subject didn't look like it was
> > SSSD-related.
> > 
> > I think we need to examine SSSD logs...
> > 
> 

-- 
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] Free ipa Configurations

[Rolf Nufable]

well I'm trying to setup sudo in my client machine, also I want to access the 
server web browser In the client machine ( is it possible though ? ) 

well I'm having this error in the client side when using the command su - ( 
user ) 

su - u...@example.com

su : u...@example.com does not exist. 



On Tuesday, November 11, 2014 5:56 PM, Martin Kosek  wrote:
 


It is still really hard to give advise as I do not know what's actually wrong.
So are you trying to set up a sudo on your client or are you trying to log in
with your client browser to FreeIPA server? These are 2 orthogonal actions.

Who gives the "Can't I connect to the ipa server" error? As I said earlier, I
cannot help you without described procedure you are trying to do, logs and
exact error messages.

Martin


On 11/11/2014 09:32 AM, Rolf Nufable wrote:
> never mind the problem on the server side, somehow it got fixed , I really 
> don't know how though
> 
> so in the client side , It is successful when installing free ipa client and 
> the
 server discovery is fine, my freipa Client is 4.1.0 and my server is 4.0.3 
(although somewhere I've read that version incompatibility would not be an 
issue since if either one is of a lower version, the only features that would 
be used is the one that the lower version can do ) 
> 
> So I really don't know why Can't I connect to the ipa server. 
> 
> Iptables works fine.
> /etc/resolv.conf is file as well 
> 
> sssd/sssd.conf ( added these lines ) 
> [sudo]
> sudo_provider = ldap
> ldap_uri = ldap://myipaserver.example.com
> ldap_sudo_search_base = ou=sudoers,dc=example,dc=com
> ldap_sasl_mech = GSSAPI
> ldap_sasl_authid = host/myipaserver.example.com
> ldap_sasl_realm = EXAMPLE.COM
> krb_server = myipaserver.example.com
> 
> 
> and /etc/nsswitch.conf
> (added this line ) 
> 
> sudoers : files sss ldap
> 
> is there something missing ? 
> 
> 
> 
> On Tuesday, November 11, 2014 3:45 PM, Rolf Nufable 
>  wrote:
>  
> 
> 
> oh sorry I forgot that on the clients side " 
> network.negotiate-auth.trusted-uris " they have the same domain as of the 
> server side I've configured it as well as in the client side because recent 
> guides for deploying IPA says that you must go to about:config either
 you are on the server or client side, or at least thats what I remember. 
> 
> Wait a sec I'm trying to achieve the state again where the server side wont 
> let me log in using the admin credentials , just so i could show you the logs 
> 
> 
> 
> 
> On Tuesday, November 11, 2014 3:28 PM, Martin Kosek  wrote:
>  
> 
> 
> On 11/11/2014 08:07 AM, Rolf Nufable wrote:
>> well I dont know how or what command to use to display the logs, could you 
>> teach me how?
> 
> There should be HOWTO articles on how to do that. Jakub may have better
> sources, but I see for
 example:
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/SSSD-Troubleshooting.html
> 
>> , but yes the network.negotiate-auth.trusted-uris has the same domain name 
>> which is example.com this is on the server side only
> 
> network.negotiate-auth.trusted-uris must be set in the *client* Firefox 
> machine.
> 
>> while on the client side, even
>  though the network.negotiate-auth.trusted-uris is configured correctly, the 
> web UI can't be accessed so its a really weird scenario. but the registration 
> of the ipa client to the server says its successful. 
> 
> FreeIPA 4.0+ Web UI should allow you to login at least with your 
> user+password,
> if SSO login fails. Does at least this part work? Because if not, there is 
> some
> error on the server side. It would be interesting to check if there are no
> errors on the server in following logs:
> - /var/log/httpd/error_log
> - /var/log/krb5kdc.log
> 
> 
> 
>>
>> TIA 
>>
>>
>> On Tuesday, November 11, 2014 2:56 PM, Martin Kosek  
>> wrote:
>>  
>>
>>
>> On 11/11/2014 06:37 AM, Rolf Nufable
 wrote:
>>> or could you guys direct me or guide me on how to deploy this ipa server? 
>>> I've been successful deploying ipa version 3.3.5 before but this 4.0 and 
>>> above series is really giving me a headache 
>>
>> Hm, that is worrying. FreeIPA 4.0+ should definitely not be more difficult to
>> deploy, on the
>  contrary, it should be much cooler than 3.3.
>>
>>> On Tuesday, November 11, 2014 1:24 PM, Rolf Nufable 
>>>  wrote:
>>>  
>>>
>>>
>>> well I'll try them now, my sssd config only consists of these lines added 
>>> to the sudo area 
>>>
>>> sudo_provider = ldap
>>> ldap_uri = ldap://myipaserver.example.com
>>> ldap_sudo_search_base = ou=sudoers,dc=example,dc=com
>>> ldap_sasl_mech =
>  GSSAPI
>>> ldap_sasl_authid = host/myipaserver.example.com
>>> ldap_sasl_realm = EXAMPLE.COM
>>> krb_server = myipaserver.example.com
>>
>> BWT, with FreeIPA 4.0+ / RHEL-6.6+ / recent Fedoras you can use "ipa" sudo
>> provider. Actually, FreeIPA 4.0+ clients do that for you.
>>
>> More info here:
>> https://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf
>> https://fedora

Re: [Freeipa-users] Free ipa Configurations

[Martin Kosek]

It is still really hard to give advise as I do not know what's actually wrong.
So are you trying to set up a sudo on your client or are you trying to log in
with your client browser to FreeIPA server? These are 2 orthogonal actions.

Who gives the "Can't I connect to the ipa server" error? As I said earlier, I
cannot help you without described procedure you are trying to do, logs and
exact error messages.

Martin

On 11/11/2014 09:32 AM, Rolf Nufable wrote:
> never mind the problem on the server side, somehow it got fixed , I really 
> don't know how though
> 
> so in the client side , It is successful when installing free ipa client and 
> the server discovery is fine, my freipa Client is 4.1.0 and my server is 
> 4.0.3 (although somewhere I've read that version incompatibility would not be 
> an issue since if either one is of a lower version, the only features that 
> would be used is the one that the lower version can do ) 
> 
> So I really don't know why Can't I connect to the ipa server. 
> 
> Iptables works fine.
> /etc/resolv.conf is file as well 
> 
> sssd/sssd.conf ( added these lines ) 
> [sudo]
> sudo_provider = ldap
> ldap_uri = ldap://myipaserver.example.com
> ldap_sudo_search_base = ou=sudoers,dc=example,dc=com
> ldap_sasl_mech = GSSAPI
> ldap_sasl_authid = host/myipaserver.example.com
> ldap_sasl_realm = EXAMPLE.COM
> krb_server = myipaserver.example.com
> 
> 
> and /etc/nsswitch.conf
> (added this line ) 
> 
> sudoers : files sss ldap
> 
> is there something missing ? 
> 
> 
> 
> On Tuesday, November 11, 2014 3:45 PM, Rolf Nufable 
>  wrote:
>  
> 
> 
> oh sorry I forgot that on the clients side " 
> network.negotiate-auth.trusted-uris " they have the same domain as of the 
> server side I've configured it as well as in the client side because recent 
> guides for deploying IPA says that you must go to about:config either you are 
> on the server or client side, or at least thats what I remember. 
> 
> Wait a sec I'm trying to achieve the state again where the server side wont 
> let me log in using the admin credentials , just so i could show you the logs 
> 
> 
> 
> 
> On Tuesday, November 11, 2014 3:28 PM, Martin Kosek  wrote:
>  
> 
> 
> On 11/11/2014 08:07 AM, Rolf Nufable wrote:
>> well I dont know how or what command to use to display the logs, could you 
>> teach me how?
> 
> There should be HOWTO articles on how to do that. Jakub may have better
> sources, but I see for example:
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/SSSD-Troubleshooting.html
> 
>> , but yes the network.negotiate-auth.trusted-uris has the same domain name 
>> which is example.com this is on the server side only
> 
> network.negotiate-auth.trusted-uris must be set in the *client* Firefox 
> machine.
> 
>> while on the client side, even
>  though the network.negotiate-auth.trusted-uris is configured correctly, the 
> web UI can't be accessed so its a really weird scenario. but the registration 
> of the ipa client to the server says its successful. 
> 
> FreeIPA 4.0+ Web UI should allow you to login at least with your 
> user+password,
> if SSO login fails. Does at least this part work? Because if not, there is 
> some
> error on the server side. It would be interesting to check if there are no
> errors on the server in following logs:
> - /var/log/httpd/error_log
> - /var/log/krb5kdc.log
> 
> 
> 
>>
>> TIA 
>>
>>
>> On Tuesday, November 11, 2014 2:56 PM, Martin Kosek  
>> wrote:
>>  
>>
>>
>> On 11/11/2014 06:37 AM, Rolf Nufable wrote:
>>> or could you guys direct me or guide me on how to deploy this ipa server? 
>>> I've been successful deploying ipa version 3.3.5 before but this 4.0 and 
>>> above series is really giving me a headache 
>>
>> Hm, that is worrying. FreeIPA 4.0+ should definitely not be more difficult to
>> deploy, on the
>  contrary, it should be much cooler than 3.3.
>>
>>> On Tuesday, November 11, 2014 1:24 PM, Rolf Nufable 
>>>  wrote:
>>>  
>>>
>>>
>>> well I'll try them now, my sssd config only consists of these lines added 
>>> to the sudo area 
>>>
>>> sudo_provider = ldap
>>> ldap_uri = ldap://myipaserver.example.com
>>> ldap_sudo_search_base = ou=sudoers,dc=example,dc=com
>>> ldap_sasl_mech =
>  GSSAPI
>>> ldap_sasl_authid = host/myipaserver.example.com
>>> ldap_sasl_realm = EXAMPLE.COM
>>> krb_server = myipaserver.example.com
>>
>> BWT, with FreeIPA 4.0+ / RHEL-6.6+ / recent Fedoras you can use "ipa" sudo
>> provider. Actually, FreeIPA 4.0+ clients do that for you.
>>
>> More info here:
>> https://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf
>> https://fedorahosted.org/freeipa/ticket/3358
>>
>>> plus another question why is it that when I invoke the kinit admin command 
>>> for the kerberos I couldnt access the web UI and keeps asking me to 
>>> configure my web browser ( firefox) though I've already configured it many 
>>> times.. 
>>
>> Are you sure that network.negotiate-auth.trusted-uris in about:config
>> co

Re: [Freeipa-users] Free ipa Configurations

[Rolf Nufable]

never mind the problem on the server side, somehow it got fixed , I really 
don't know how though

so in the client side , It is successful when installing free ipa client and 
the server discovery is fine, my freipa Client is 4.1.0 and my server is 4.0.3 
(although somewhere I've read that version incompatibility would not be an 
issue since if either one is of a lower version, the only features that would 
be used is the one that the lower version can do ) 

So I really don't know why Can't I connect to the ipa server. 

Iptables works fine.
/etc/resolv.conf is file as well 

sssd/sssd.conf ( added these lines ) 
[sudo]
sudo_provider = ldap
ldap_uri = ldap://myipaserver.example.com
ldap_sudo_search_base = ou=sudoers,dc=example,dc=com
ldap_sasl_mech = GSSAPI
ldap_sasl_authid = host/myipaserver.example.com
ldap_sasl_realm = EXAMPLE.COM
krb_server = myipaserver.example.com


and /etc/nsswitch.conf
(added this line ) 

sudoers : files sss ldap

is there something missing ? 



On Tuesday, November 11, 2014 3:45 PM, Rolf Nufable  
wrote:
 


oh sorry I forgot that on the clients side " 
network.negotiate-auth.trusted-uris " they have the same domain as of the 
server side I've configured it as well as in the client side because recent 
guides for deploying IPA says that you must go to about:config either you are 
on the server or client side, or at least thats what I remember. 

Wait a sec I'm trying to achieve the state again where the server side wont let 
me log in using the admin credentials , just so i could show you the logs 




On Tuesday, November 11, 2014 3:28 PM, Martin Kosek  wrote:
 


On 11/11/2014 08:07 AM, Rolf Nufable wrote:
> well I dont know how or what command to use to display the logs, could you 
> teach me how?

There should be HOWTO articles on how to do that. Jakub may have better
sources, but I see for example:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/SSSD-Troubleshooting.html

> , but yes the network.negotiate-auth.trusted-uris has the same domain name 
> which is example.com this is on the server side only

network.negotiate-auth.trusted-uris must be set in the *client* Firefox machine.

> while on the client side, even
 though the network.negotiate-auth.trusted-uris is configured correctly, the 
web UI can't be accessed so its a really weird scenario. but the registration 
of the ipa client to the server says its successful. 

FreeIPA 4.0+ Web UI should allow you to login at least with your user+password,
if SSO login fails. Does at least this part work? Because if not, there is some
error on the server side. It would be interesting to check if there are no
errors on the server in following logs:
- /var/log/httpd/error_log
- /var/log/krb5kdc.log



> 
> TIA 
> 
> 
> On Tuesday, November 11, 2014 2:56 PM, Martin Kosek  wrote:
>  
> 
> 
> On 11/11/2014 06:37 AM, Rolf Nufable wrote:
>> or could you guys direct me or guide me on how to deploy this ipa server? 
>> I've been successful deploying ipa version 3.3.5 before but this 4.0 and 
>> above series is really giving me a headache 
> 
> Hm, that is worrying. FreeIPA 4.0+ should definitely not be more difficult to
> deploy, on the
 contrary, it should be much cooler than 3.3.
> 
>> On Tuesday, November 11, 2014 1:24 PM, Rolf Nufable 
>>  wrote:
>>  
>>
>>
>> well I'll try them now, my sssd config only consists of these lines added to 
>> the sudo area 
>>
>> sudo_provider = ldap
>> ldap_uri = ldap://myipaserver.example.com
>> ldap_sudo_search_base = ou=sudoers,dc=example,dc=com
>> ldap_sasl_mech =
 GSSAPI
>> ldap_sasl_authid = host/myipaserver.example.com
>> ldap_sasl_realm = EXAMPLE.COM
>> krb_server = myipaserver.example.com
> 
> BWT, with FreeIPA 4.0+ / RHEL-6.6+ / recent Fedoras you can use "ipa" sudo
> provider. Actually, FreeIPA 4.0+ clients do that for you.
> 
> More info here:
> https://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf
> https://fedorahosted.org/freeipa/ticket/3358
> 
>> plus another question why is it that when I invoke the kinit admin command 
>> for the kerberos I couldnt access the web UI and keeps asking me to 
>> configure my web browser ( firefox) though I've already configured it many 
>> times.. 
> 
> Are you sure that network.negotiate-auth.trusted-uris in about:config
> correctly? Are you saying that your Firefox works with FreeIPA 3.3 server but
> not with FreeIPA 4.0+? What is the domain of the FreeIPA 4.0+ server and what
> is the setting of network.negotiate-auth.trusted-uris?
> 
> In any case, it is still hard to
 advise as I still did not see any related
> logs, error messages or actual real errors preventing you from enrolling 
> FreeIPA.
> 
> Thanks,
> Martin
> 
> 
>>
>>
>> TIA 
>>
>>
>>
>> On Monday, November 10, 2014 8:41 PM, Jakub Hrozek  
>> wrote:
>>  
>>
>>
>> On Mon, Nov 10, 2014 at 12:56:00PM +0100, Martin Kosek wrote:
>>
>>> On 11/10/2014 02:05 AM, Rolf
>>  Nufable wrote:
 Hello 

 I have tons of questio

Re: [Freeipa-users] Possible trust issues

[Sumit Bose]

On Tue, Nov 11, 2014 at 07:52:22AM +0200, Alexander Bokovoy wrote:
> On Mon, 10 Nov 2014, William Muriithi wrote:
> >less /var/log/sssd/sssd_example.loc.log
> >
> >(Mon Nov 10 15:58:21 2014) [sssd[be[example.loc]]] [fo_set_port_status] 
> >(0x0100): Marking port 389 of server 'ipa3-yyz-int.example.loc' as 'working'
> >(Mon Nov 10 15:58:21 2014) [sssd[be[example.loc]]] 
> >[set_server_common_status] (0x0100): Marking server 
> >'ipa3-yyz-int.example.loc' as 'working'
> >(Mon Nov 10 16:01:44 2014) [sssd[be[example.loc]]] [be_get_account_info] 
> >(0x0100): Got request for [4097][1][name=wmuriithi]
> >(Mon Nov 10 16:01:44 2014) [sssd[be[example.loc]]] [ipa_s2n_get_user_done] 
> >(0x0040): s2n exop request failed.
> >(Mon Nov 10 16:01:44 2014) [sssd[be[example.loc]]] [acctinfo_callback] 
> >(0x0100): Request processed. Returned 3,1432158221,Account info lookup failed
> >(Mon Nov 10 16:01:57 2014) [sssd[be[example.loc]]] [be_get_account_info] 
> >(0x0100): Got request for [4097][1][name=wmuriithi]
> >(Mon Nov 10 16:01:57 2014) [sssd[be[example.loc]]] [ipa_s2n_get_user_done] 
> >(0x0040): s2n exop request failed.
> >(Mon Nov 10 16:01:57 2014) [sssd[be[example.loc]]] [acctinfo_callback] 
> >(0x0100): Request processed. Returned 3,1432158221,Account info lookup failed
> >(Mon Nov 10 16:01:57 2014) [sssd[be[example.loc]]] [be_get_account_info] 
> >(0x0100): Got request for [4097][1][name=wmuriithi]
> >(Mon Nov 10 16:01:57 2014) [sssd[be[example.loc]]] [ipa_s2n_get_user_done] 
> >(0x0040): s2n exop request failed.
> >(Mon Nov 10 16:01:57 2014) [sssd[be[example.loc]]] [acctinfo_callback] 
> >(0x0100): Request processed. Returned 3,1432158221,Account info lookup failed
> >(Mon Nov 10 16:01:57 2014) [sssd[be[example.loc]]] [be_get_account_info] 
> >(0x0100): Got request for [4097][1][name=wmuriithi]
> >(Mon Nov 10 16:01:57 2014) [sssd[be[example.loc]]] [ipa_s2n_get_user_done] 
> >(0x0040): s2n exop request failed.
> >
> >Does this mean I have to recreate the trust relationship?  I didn't get
> >any error when I set up the trust last week and uncertain recreating
> >the trust would help.  Would highly appreciate any pointers on what
> >would be best way forward.
> 's2n exop request failed' above tells that communication to IPA master
> didn't succeed in looking up AD users and groups. You need to enable
> debug in sssd on IPA master and provide logs from there.

Can you resolve the user on the IPA master? Does ssh work in the IPA
master?

bye,
Sumit

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

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