Re: [Freeipa-users] ipactl services running, but auth not working

[Aaron Collins]

It sounds like your IPA service is hanging.  The fastest way to check is do an 
ldap search against that host to see if it replies.  If it doesn’t look under 
/var/log/dirvsrv/sapd-$INSTANCE-NAME/error to see if you have an error.  I’ve 
seen this with the out of fd error, or if you server is in a dead lock.

[ignature_882888092]

Aaron Collins |  Senior DevOps Engineer
3990 Freedom Circle, Santa Clara, CA 95054
808.203.8756 mobile  |  acoll...@chegg.com
www.chegg.com  |  t @chegg  |  f 
chegg

We put students first. Chegg is proud to have helped students & their families 
save over $1 billion.

From:  on behalf of pgb205 
Reply-To: pgb205 
Date: Friday, February 3, 2017 at 12:11 PM
To: "Sullivan, Daniel [CRI]" 
Cc: Freeipa-users 
Subject: Re: [Freeipa-users] ipactl services running, but auth not working

there are reports from multiple clients being unable to authenticate.
ipactl status shows all services as running.
The problem is fixed when I 'ipactl restart'.


From: "Sullivan, Daniel [CRI]" 
To: pgb205 
Cc: Freeipa-users 
Sent: Friday, February 3, 2017 2:47 PM
Subject: Re: [Freeipa-users] ipactl services running, but auth not working

What exactly are you seeing to determine that the server is actually failing?  
Is it not possible that sssd (the client) is timing out?  Will 389ds service an 
LDAP request, i.e. can you run

ldapsearch -D "cn=Directory Manager" -w  -s base -b "cn=config" 
"(objectclass=*)”

What exactly are you trying to do?  Just password authentication to an sssd 
client?  Are you operating in a trusted AD environment?

Dan

On Feb 3, 2017, at 11:26 AM, pgb205 
mailto:pgb...@yahoo.com>>>
 wrote:

My problem is with the server itself seemingly not providing services even 
though it claims to do so. would be curious to know what to look at on freeipa 
server or how to inrease logging


From: "Sullivan, Daniel [CRI]" 
mailto:dsulliv...@bsd.uchicago.edu>>>
To: pgb205 
mailto:pgb...@yahoo.com>>>
Cc: Freeipa-users 
mailto:freeipa-users@redhat.com>>>
Sent: Thursday, February 2, 2017 5:16 PM
Subject: Re: [Freeipa-users] ipactl services running, but auth not working

Have you looked at the sssd logs yet?

Dan

On Feb 2, 2017, at 4:13 PM, pgb205 
mailto:pgb...@yahoo.com>>  for more 
info on the project




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

Re: [Freeipa-users] IPA replica issue

[Giorgio Biacchi]

On 02/06/2017 05:14 PM, Giorgio Biacchi wrote:

On 02/06/2017 04:54 PM, Rob Crittenden wrote:

Giorgio Biacchi wrote:

Hi list,
I have this message in the logs:

Feb  6 16:43:10 dc01 ns-slapd: [06/Feb/2017:16:43:10.157801305 +0100]
NSMMReplicationPlugin -
agmt="cn=masterAgreement1-dc02.myorg.local-pki-tomcat" (dc02:389): Data
required to update replica has been purged from the changelog. The
replica must be reinitialized.

But ipa-replica-manage re-initialize --from dc02.myorg.local does not
fix the problem. Even moving away the changelog directory didn't help..

I'm running ipa-server-4.4.0-14.el7.centos.4.x86_64 and
389-ds-base-1.3.5.10-15.el7_3.x86_64, and setup is:

#ipa-replica-manage list
Directory Manager password:

dc01.myorg.local: master
dc02.myorg.local: master

Can someone please tell me which is the correct sequence of actions to
fix this issue?


The error appears to be the CA replicated data (ref to tomcat in the
agreement) so you need to use ipa-csreplica-manage instead of
ipa-replica-manage.

rob



Hi Rob,
even ipa-csreplica-manage re-initialize --from dc02.myorg.local seems not to
solve the issue, here's the logs after the command you suggested:

Feb  6 17:12:06 dc01 ns-slapd: [06/Feb/2017:17:12:06.432485541 +0100]
NSMMReplicationPlugin - changelog program - agmt="cn=meTodc02.myorg.local"
(idc02:389): CSN 58989367000c0004 not found, we aren't as up to date, or we
purged
Feb  6 17:12:06 dc01 ns-slapd: [06/Feb/2017:17:12:06.436444629 +0100]
NSMMReplicationPlugin - agmt="cn=meTodc02.myorg.local" (dc02:389): Data required
to update replica has been purged from the changelog. The replica must be
reinitialized.

Thanks for your kind attention


Hello again,
after a couple of re-initialization (ipa-csreplica-manage and 
ipa-replica-manage) and after systemctl restart ipa now the previuos error is 
gone and the replica is working in both directions.


Now I have a new error:

Feb  6 18:02:12 dc01 [sssd[ldap_child[10109]]]: Failed to initialize credentials 
using keytab [MEMORY:/etc/krb5.keytab]: Decrypt integrity check failed. Unable 
to create GSSAPI-encrypted LDAP connection.

Feb  6 18:02:12 dc01 [sssd[ldap_child[10109]]]: Decrypt integrity check failed

There's a way to fix this??

Thanks
--
gb

PGP Key: http://pgp.mit.edu/
Primary key fingerprint: C510 0765 943E EBED A4F2 69D3 16CC DC90 B9CB 0F34

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

Re: [Freeipa-users] IPA replica issue

[Giorgio Biacchi]

On 02/06/2017 04:54 PM, Rob Crittenden wrote:

Giorgio Biacchi wrote:

Hi list,
I have this message in the logs:

Feb  6 16:43:10 dc01 ns-slapd: [06/Feb/2017:16:43:10.157801305 +0100]
NSMMReplicationPlugin -
agmt="cn=masterAgreement1-dc02.myorg.local-pki-tomcat" (dc02:389): Data
required to update replica has been purged from the changelog. The
replica must be reinitialized.

But ipa-replica-manage re-initialize --from dc02.myorg.local does not
fix the problem. Even moving away the changelog directory didn't help..

I'm running ipa-server-4.4.0-14.el7.centos.4.x86_64 and
389-ds-base-1.3.5.10-15.el7_3.x86_64, and setup is:

#ipa-replica-manage list
Directory Manager password:

dc01.myorg.local: master
dc02.myorg.local: master

Can someone please tell me which is the correct sequence of actions to
fix this issue?


The error appears to be the CA replicated data (ref to tomcat in the
agreement) so you need to use ipa-csreplica-manage instead of
ipa-replica-manage.

rob



Hi Rob,
even ipa-csreplica-manage re-initialize --from dc02.myorg.local seems not to 
solve the issue, here's the logs after the command you suggested:


Feb  6 17:12:06 dc01 ns-slapd: [06/Feb/2017:17:12:06.432485541 +0100] 
NSMMReplicationPlugin - changelog program - agmt="cn=meTodc02.myorg.local" 
(idc02:389): CSN 58989367000c0004 not found, we aren't as up to date, or we 
purged
Feb  6 17:12:06 dc01 ns-slapd: [06/Feb/2017:17:12:06.436444629 +0100] 
NSMMReplicationPlugin - agmt="cn=meTodc02.myorg.local" (dc02:389): Data required 
to update replica has been purged from the changelog. The replica must be 
reinitialized.


Thanks for your kind attention
--
gb

PGP Key: http://pgp.mit.edu/
Primary key fingerprint: C510 0765 943E EBED A4F2 69D3 16CC DC90 B9CB 0F34

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

Re: [Freeipa-users] IPA replica issue

[Rob Crittenden]

Giorgio Biacchi wrote:
> Hi list,
> I have this message in the logs:
> 
> Feb  6 16:43:10 dc01 ns-slapd: [06/Feb/2017:16:43:10.157801305 +0100]
> NSMMReplicationPlugin -
> agmt="cn=masterAgreement1-dc02.myorg.local-pki-tomcat" (dc02:389): Data
> required to update replica has been purged from the changelog. The
> replica must be reinitialized.
> 
> But ipa-replica-manage re-initialize --from dc02.myorg.local does not
> fix the problem. Even moving away the changelog directory didn't help..
> 
> I'm running ipa-server-4.4.0-14.el7.centos.4.x86_64 and
> 389-ds-base-1.3.5.10-15.el7_3.x86_64, and setup is:
> 
> #ipa-replica-manage list
> Directory Manager password:
> 
> dc01.myorg.local: master
> dc02.myorg.local: master
> 
> Can someone please tell me which is the correct sequence of actions to
> fix this issue?

The error appears to be the CA replicated data (ref to tomcat in the
agreement) so you need to use ipa-csreplica-manage instead of
ipa-replica-manage.

rob

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

[Freeipa-users] IPA replica issue

[Giorgio Biacchi]

Hi list,
I have this message in the logs:

Feb  6 16:43:10 dc01 ns-slapd: [06/Feb/2017:16:43:10.157801305 +0100] 
NSMMReplicationPlugin - agmt="cn=masterAgreement1-dc02.myorg.local-pki-tomcat" 
(dc02:389): Data required to update replica has been purged from the changelog. 
The replica must be reinitialized.


But ipa-replica-manage re-initialize --from dc02.myorg.local does not fix the 
problem. Even moving away the changelog directory didn't help..


I'm running ipa-server-4.4.0-14.el7.centos.4.x86_64 and 
389-ds-base-1.3.5.10-15.el7_3.x86_64, and setup is:


#ipa-replica-manage list
Directory Manager password:

dc01.myorg.local: master
dc02.myorg.local: master

Can someone please tell me which is the correct sequence of actions to fix this 
issue?


Thanks
--
gb

PGP Key: http://pgp.mit.edu/
Primary key fingerprint: C510 0765 943E EBED A4F2 69D3 16CC DC90 B9CB 0F34

--
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] Wrong principal in request in NFS mount

[Rob Crittenden]

Matthew Carter wrote:
> So I have two test machines that I set up because of this same problem
> on my secure offline network. One of the test machines is a server that
> has FreeIPA and NFS running on it, the other test machine is a client
> that mounts two NFS shares from the server using krb5i sec.
> 
> Upon initial install, everything works as it is supposed to. The domain
> users can log in just fine, the mount mounts perfectly.

It sounds to me like /etc/krb5.keytab isn't being cleaned up properly on
uninstall.

What I'd suggest is to re-fetch the service principal, perhaps several
times, to bump the KVNO to be sure you have the right one. Then restart
the NFS services and see if that helps. Conceivably you'd need to do
something similar on the client if that too has a mix of principals from
the old and new masters.

Getting some logging from the previous uninstall would be useful. IIRC
there is a separate uninstall log for the client.

rob


> If I remove the client from the domain using:
> 
> ipa-client-automount --uninstall
> 
> ipa-client-install --uninstall
> 
> 
> And then on the server:
> 
> ipa-client-automount --uninstall
> 
> ipa-server-install --uninstall
> 
> then delete the ca.crt, run sss -E (to clear the sssd caches), rm
> /tmp/krb5*
> 
> 
> and then reinstall the server:
> 
> ipa-server-install
> 
> service sshd restart
> 
> kinit admin
> 
> ipa service-add nfs/server.dar.lan
> 
> ipa-getkeytab -s server.dar.lan -p host/server.dar.lan -k
> /etc/krb5.keytab
> 
> ipa-getkeytab -s server.dar.lan -p nfs/server.dar.lan -k
> /etc/krb5.keytab
> 
> ipa-client-automount
> 
> 
> and reinstall on the client:
> 
> ipa-client-install
> 
> ipa-client-automount
> 
> 
> I believe I now have the same setup as I had before.
> 
> I can kinit and get a ticket:
> 
> Ticket cache: FILE:/tmp/krb5cc_61520_TinxaO
> Default principal: ad...@dar.lan
> 
> Valid starting ExpiresService principal
> 02/03/17 12:54:02  02/04/17 12:53:59  krbtgt/dar@dar.lan
> 
> My domain users can log in to their desktops.
> 
> But I can't mount the shares.
> 
> I get:
> 
> mount.nfs4: timeout set for Fri Feb  3 12:58:36 2017
> mount.nfs4: trying text-based options
> 'sec=krb5i,proto=tcp,port=2049,rsize=8192,wsize=8192,timeo=14,intr,addr=137.67.205.1,clientaddr=137.67.205.11'
> mount.nfs4: mount(2): Permission denied
> mount.nfs4: access denied by server while mounting
> server:/NFS_SHARE/USERS
> mount.nfs4: timeout set for Fri Feb  3 12:58:36 2017
> mount.nfs4: trying text-based options
> 'sec=krb5i,proto=tcp,port=2049,rsize=8192,wsize=8192,timeo=14,intr,addr=137.67.205.1,clientaddr=137.67.205.11'
> mount.nfs4: mount(2): Permission denied
> mount.nfs4: access denied by server while mounting
> server:/NFS_SHARE/admin
> 
> 
> Originally I chased permissions, but when I started looking at
> /var/log/messages on the server, I noticed that rpcgssd was complaining 
> about a wrong principal.
> 
> On the server I executed kadmin.local and then listprincs
> 
> K/m...@dar.lan
> krbtgt/dar@dar.lan
> kadmin/server.dar@dar.lan
> kadmin/ad...@dar.lan
> kadmin/chang...@dar.lan
> ldap/server.dar@dar.lan
> host/server.dar@dar.lan
> HTTP/server.dar@dar.lan
> nfs/server.dar@dar.lan
> s_shar...@dar.lan
> host/as1.dar@dar.lan
> 
> and then a getprinc on nfs/server.dar@dar.lan:
> 
> Principal: nfs/server.dar@dar.lan
> Expiration date: [never]
> Last password change: Thu Feb 02 15:31:24 EST 2017
> Password expiration date: [none]
> Maximum ticket life: 1 day 00:00:00
> Maximum renewable life: 7 days 00:00:00
> Last modified: Thu Feb 02 15:31:24 EST 2017
> (nfs/server.dar@dar.lan)
> Last successful authentication: Thu Feb 02 16:52:16 EST 2017
> Last failed authentication: Fri Feb 03 12:09:14 EST 2017
> Failed password attempts: 1
> Number of keys: 4
> Key: vno 3, aes256-cts-hmac-sha1-96, no salt
> Key: vno 3, aes128-cts-hmac-sha1-96, no salt
> Key: vno 3, des3-cbc-sha1, no salt
> Key: vno 3, arcfour-hmac, no salt
> MKey: vno 1
> Attributes: REQUIRES_PRE_AUTH
> Policy: [none]
> 
> looking at my keytab, klist -ke /etc/krb5.keytab
> 
>12  host/server.dar@dar.lan
>21   nfs/server.dar@dar.lan
>33  host/server.dar@dar.lan
>43  host/server.dar@dar.lan
>53  host/server.dar@dar.lan
>63  host/server.dar@dar.lan
>72   nfs/server.dar@dar.lan
>82   nfs/server.dar@dar.lan
>92   nfs/server.dar@dar.lan
>   102   nfs/server.dar@dar.lan
> 
> I saw I had two extra older kt's so I used kadmin.local to remove them
> with modp

[Freeipa-users] Ubuntu client 2FA not working

[Tommy Nikjoo]

Hi,

I'm having some issues with 2FA PAM config's on Ubuntu clients. 
Currently, I'm guessing that the PAM module doesn't know how to talk to
the 2FA protocol.  Is anyone able to give an in site into how to get
this working correctly?

Thanks

**

//



On 14/12/16 22:48, Fraser Tweedale wrote:
> On Wed, Dec 14, 2016 at 05:35:35PM +, Tommy Nikjoo wrote:
>> Hi,
>>
>> I'm trying to install FreeIPA on CentOS 7 using the yum package, but I
>> keep getting an error when it tries to restart DogTag
>>
>>   [26/31]: restarting certificate server
>> ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to restart
>> the Dogtag instance.See the installation log for details.
>>   [27/31]: migrating certificate profiles to LDAP
>>   [error] NetworkError: cannot connect to
>> 'https://ldap2.armourcomms.com:8443/ca/rest/account/login': ''
>> ipa.ipapython.install.cli.install_tool(Server): ERRORcannot connect
>> to 'https://ldap2.armourcomms.com:8443/ca/rest/account/login': ''
>> ipa.ipapython.install.cli.install_tool(Server): ERRORThe
>> ipa-server-install command failed. See /var/log/ipaserver-install.log
>> for more information
>>
>>
>> The log shows the following error
>>
>> 2016-12-14T16:53:05Z DEBUG NSSConnection init ldap.example.com
>> 2016-12-14T16:53:05Z DEBUG Connecting: x.x.x.x:0
>> 2016-12-14T16:53:05Z DEBUG approved_usage = SSL Server intended_usage =
>> SSL Server
>> 2016-12-14T16:53:05Z DEBUG cert valid True for
>> "CN=ldap.example.com,O=EXAMPLE.COM"
>> 2016-12-14T16:53:05Z DEBUG handshake complete, peer = x.x.x.x:8443
>> 2016-12-14T16:53:05Z DEBUG Protocol: TLS1.2
>> 2016-12-14T16:53:05Z DEBUG Cipher: TLS_RSA_WITH_AES_256_CBC_SHA
>> 2016-12-14T16:53:05Z DEBUG response status 200
>> 2016-12-14T16:53:05Z DEBUG response headers {'content-length': '205',
>> 'set-cookie': 'JSESSIONID=9B6C767CDBED07088646235E68E831E0; Path=/ca/;
>> Secure; HttpOnly', 'expires': 'Thu, 01 Jan 1970 00:00:00 UTC', 'server':
>> 'Apache-Coyote/1.1', 'cache-control': 'private', 'date': 'Wed, 14 Dec
>> 2016 16:53:05 GMT', 'content-type': 'application/xml'}
>> 2016-12-14T16:53:05Z DEBUG response body '> encoding="UTF-8" standalone="yes"?>> id="ipara">iparaCertificate Manager
>> AgentsRegistration Manager Agents'
>> 2016-12-14T16:53:05Z DEBUG request POST
>> https://ldap.example.com:8443/ca/rest/profiles/raw
>> 2016-12-14T16:53:05Z DEBUG request body
>> 'profileId=IECUserRoles\nclassId=caEnrollImpl\ndesc=Enroll user
>> certificates with IECUserRoles extension via IPA-RA agent
>> authentication.\nvisible=false\nenable=true\nenableBy=admin\nauth.instance_id=raCertAuth\nname=IPA-RA
>> Agent-Authenticated Server Certificate
>> Enrollment\ninput.list=i1,i2\ninput.i1.class_id=certReqInputImpl\ninput.i2.class_id=submitterInfoInputImpl\noutput.list=o1\noutput.o1.class_id=certOutputImpl\npolicyset.list=serverCertSet\npolicyset.serverCertSet.list=1,2,3,4,5,6,7,8,9,10,11,12\npolicyset.serverCertSet.1.constraint.class_id=subjectNameConstraintImpl\npolicyset.serverCertSet.1.constraint.name=Subject
>> Name
>> Constraint\npolicyset.serverCertSet.1.constraint.params.pattern=CN=[^,]+,.+\npolicyset.serverCertSet.1.constraint.params.accept=true\npolicyset.serverCertSet.1.default.class_id=subjectNameDefaultImpl\npolicyset.serverCertSet.1.default.name=Subject
>> Name
>> Default\npolicyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$,
>> O=EXAMPLE.COM\npolicyset.serverCertSet.2.constraint.class_id=validityConstraintImpl\npolicyset.serverCertSet.2.constraint.name=Validity
>> Constraint\npolicyset.serverCertSet.2.constraint.params.range=740\npolicyset.serverCertSet.2.constraint.params.notBeforeCheck=false\npolicyset.serverCertSet.2.constraint.params.notAfterCheck=false\npolicyset.serverCertSet.2.default.class_id=validityDefaultImpl\npolicyset.serverCertSet.2.default.name=Validity
>> Default\npolicyset.serverCertSet.2.default.params.range=731\npolicyset.serverCertSet.2.default.params.startTime=0\npolicyset.serverCertSet.3.constraint.class_id=keyConstraintImpl\npolicyset.serverCertSet.3.constraint.name=Key
>> Constraint\npolicyset.serverCertSet.3.constraint.params.keyType=RSA\npolicyset.serverCertSet.3.constraint.params.keyParameters=1024,2048,3072,4096\npolicyset.serverCertSet.3.default.class_id=userKeyDefaultImpl\npolicyset.serverCertSet.3.default.name=Key
>> Default\npolicyset.serverCertSet.4.constraint.class_id=noConstraintImpl\npolicyset.serverCertSet.4.constraint.name=No
>> Constraint\npolicyset.serverCertSet.4.default.class_id=authorityKeyIdentifierExtDefaultImpl\npolicyset.serverCertSet.4.default.name=Authority
>> Key Identifier
>> Default\npolicyset.serverCertSet.5.constraint.class_id=noConstraintImpl\npolicyset.serverCertSet.5.constraint.name=No
>> Constraint\npolicyset.serverCertSet.5.default.class_id=authInfoAccessExtDefaultImpl\npolicyset.serverCertSet.5.default.name=AIA
>> Extension
>> Default\npolicyset.serverCertSet.5.default.params.authInfoAccessADEnable_0=true\npolicyset.serverCertSet.5.default

Re: [Freeipa-users] Needs help understand this timeout issue

[Sullivan, Daniel [CRI]]

Have you looked at the ignore_group_members option?  Maybe this is the problem 
you are seeing?

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

==snip==

ignore_group_members
Normally the most data-intensive operation is downloading the groups including 
their members. Usually, we are interested in what groups a user is a member of 
(id aduser@ad_domain) as the initial step rather than what members do specific 
groups include (getent group adgroup@ad_domain). Setting the 
ignore_group_members option to True makes all groups appear as empty, thus 
downloading only information about the group objects themselves and not their 
members, providing a significant performance boost. Please note that id 
aduser@ad_domain would still return all the correct groups!
==snip==


Dan

On Feb 6, 2017, at 1:59 AM, Troels Hansen  wrote:

Hi

I'm aware of the anatomy of how the lookup is done, but I would suppose a valid 
cache on the IPA server would result in the cache from the IPA server being 
used?

I have been debugging this issue some more, and can confirm is the client have 
its sssd cache invalidated by "sss_cache -E" and the IPA server have a valid 
cache, when the client asks for the user, the IPA server still asks the AD for 
the entire group info?

I can see, that even though the cache is refreshed the attribute 
initgrExpireTimestamp (in the ldb cache) isn't updated.
I have been unable to find out exactly what this controls?

lastUpdate and dataExpireTimestamp is updated to the time stamp of when the 
refresh ran.


- On Feb 1, 2017, at 2:27 PM, Sullivan, Daniel [CRI] 
dsulliv...@bsd.uchicago.edu wrote:

Have you checked to see if the user is expired in the cache, or if it is
impacted by entry_cache_nowait_percentage (ref sssd.conf). The default entry
timeout is only 90 minutes and entry_cache_nowait_percentage default is 50.

ldbsearch -H  /var/lib/sss/db/timestamps_xxx.xxx.uchicago.edu.ldb >
~/timestamps.txt
ldbsearch -H  /var/lib/sss/db/cache_xxx.xxx.uchicago.edu.ldb > ~/cache.txt

Might be able to provide more info.

Again, I’d really familiarize yourself with the anatomy of an sssd lookup, if
you get to know the diagram and steps 1-7 here it will be a big help to your
question(s).
https://jhrozek.wordpress.com/2015/03/11/anatomy-of-sssd-user-lookup/

Dan


On Feb 1, 2017, at 4:32 AM, Troels Hansen  wrote:

>From looking af at TCP dump, I can see that if a client requests a AD user from
IPA, IPA does a full user lookup in AD, even though the IPA server have the
user in local cache?

It looks like a single group generates a LOT of traffic to AD like:
client -> IPA
IPA -> client
IPA -> AD
AD -> IPA
IPA -> AD
IPA -> Second AD
Second AD -> IPA
IPA -> Second AD
IPA -> AD
AD -> IPA
IPA -> AD
IPA -> client
client -> IPA
IPA -> Client

Something similar continues for every group the user has.

Soo, I guess the question that I haven't been able to find documented anywhere.
Isn't the SSSD group cache on the IPA servers supposed to be used then a sssd
client requests a user?



- On Feb 1, 2017, at 9:53 AM, Troels Hansen t...@casalogic.dk wrote:

Hmm, suspect its happening on the server.. thous I haven't been able to
pinpoint a log entry that confirms my suspecting.

I have pinpointed the timeout to happen after 58 seconds after completely
removing the SSSD cache and restaring SSSD, which leads me to think my issue is
related to ldap_enumaration_search_timeout which defaults to 60.

rm -fr /var/lib/sss/{mc,db}/* && systemctl restart sssd && time id shja

However, I'm unable to crank it up on the server as it seems to be adjusted Down
to 60 Again?

Wed Feb  1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_get_options] (0x0400): Option
ldap_enumeration_search_timeout has value 120
(Wed Feb  1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_copy_options_ex] (0x0400):
Option ldap_enumeration_search_timeout has value 60
(Wed Feb  1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_copy_options_ex] (0x0400):
Option ldap_enumeration_search_timeout has value 60

LDAP seems speedy enough, not timeouts while querying it manually while a client
is doing a user lookup.

- On Jan 30, 2017, at 6:06 PM, Sullivan, Daniel [CRI]
dsulliv...@bsd.uchicago.edu wrote:


If the timeout is occurring on the server, I would start by increasing one or
both of these values:

ldap_opt_timeout
ldap_search_timeout

If that doesn’t work I’d take look to see if the 389 server is under high load
when you are performing this operation.  The easiest way I have found to do
this is to just execute an LDAP query directly against the IPA server when you
are performing an id lookup, for example:

ldapsearch -D "cn=Directory Manager" -w  -s base -b "cn=config"
"(objectclass=*)”

If the LDAP server is not responsive you probably need to increase the number of
worker threads for 389ds.  Also, you might want to disable referrals, check out
the man pages for this;

ldap_referrals = false

Also, FWIW, if you crank up de

Re: [Freeipa-users] client in many IPA domains

[David Kupka]

On Fri, Feb 03, 2017 at 02:04:55PM -0200, Raul Dias wrote:
> Hello,
> 
> Can ipa-client (e.g., anotebook) be in more than one realm? e.g. depending
> on the network where it is connected.
> 
> -rsd
> 

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

Hello! 

It depends what are you expectation about features that will be available on 
such client.

If you just want to be able to obtain Kerberos ticket for a user on the client 
it will work even without FreeIPA (assuming DNS records for Kerberos are in 
place).

Enrolling the client to two FreeIPA domains is theoretically doable but:
a) would require some experimentation and manual tinkering,
b) may bring security issues (e.g. sharing the same Kerberos key with both 
domains),
c) will likely result in weird behavior,
d) is definitelly not supported nor encouraged.

-- 
David Kupka


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

Re: [Freeipa-users] IPA replica setup for version 4.4

[Martin Basti]

On 04.02.2017 10:21, deepak dimri wrote:
I am trying to install ipa replica but getting below error when 
running ipa-replica-install


i am following below link for ipa 4.4:

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



Run connection check to master
ipa.ipapython.install.cli.install_tool(Replica): ERROR  Connection 
check failed!

Please fix your network settings according to error messages above


What could be reason for this error?

Thanks,
Deepak





Hello,

this can be caused by firewall IMO. Could you provide 
ipareplica-install.log ?


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] VERSION: 4.4.0, IPA Replica DOES NOT Work

[Alexander Bokovoy]

On la, 04 helmi 2017, deepak dimri wrote:

I am wondering Does IPA Replica as standalone without IPA Master being up
works for you guys? Mine and my collogue IPA setup in our own Dev
environment with VERSION: 4.2 works perfectly fine. but now when we are
moving to staging env we are getting IPA version VERSION: 4.4.0,
API_VERSION: 2.213 installed through yum in centos 7 and replica now DOES
NOT WORK as standalone unit.

We either keep getting GATEWAY_TIMEOUT Error on the browser or its taking
hell lot of time to fetch user and host objects from Replica DS. The moment
we bring up our IPA Server up replica also starts working fine.

I am not sure but unfortunately there is no helpful reply i am getting on
this issue and wondering if any one else is having TIMEOUT issue with
replica with version 4.4?

I have a hard time understanding what exactly you are trying to do and
what 'standalone IPA replica without IPA master' means.

Could you please show a sequence of operations you tried to perform?

--
/ 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] Needs help understand this timeout issue

[Troels Hansen]

Hi

I'm aware of the anatomy of how the lookup is done, but I would suppose a valid 
cache on the IPA server would result in the cache from the IPA server being 
used?

I have been debugging this issue some more, and can confirm is the client have 
its sssd cache invalidated by "sss_cache -E" and the IPA server have a valid 
cache, when the client asks for the user, the IPA server still asks the AD for 
the entire group info?

I can see, that even though the cache is refreshed the attribute 
initgrExpireTimestamp (in the ldb cache) isn't updated.
I have been unable to find out exactly what this controls?

lastUpdate and dataExpireTimestamp is updated to the time stamp of when the 
refresh ran.


- On Feb 1, 2017, at 2:27 PM, Sullivan, Daniel [CRI] 
dsulliv...@bsd.uchicago.edu wrote:

> Have you checked to see if the user is expired in the cache, or if it is
> impacted by entry_cache_nowait_percentage (ref sssd.conf). The default entry
> timeout is only 90 minutes and entry_cache_nowait_percentage default is 50.
> 
> ldbsearch -H  /var/lib/sss/db/timestamps_xxx.xxx.uchicago.edu.ldb >
> ~/timestamps.txt
> ldbsearch -H  /var/lib/sss/db/cache_xxx.xxx.uchicago.edu.ldb > ~/cache.txt
> 
> Might be able to provide more info.
> 
> Again, I’d really familiarize yourself with the anatomy of an sssd lookup, if
> you get to know the diagram and steps 1-7 here it will be a big help to your
> question(s).
> https://jhrozek.wordpress.com/2015/03/11/anatomy-of-sssd-user-lookup/
> 
> Dan
> 
> 
>> On Feb 1, 2017, at 4:32 AM, Troels Hansen  wrote:
>> 
>>> From looking af at TCP dump, I can see that if a client requests a AD user 
>>> from
>>> IPA, IPA does a full user lookup in AD, even though the IPA server have the
>>> user in local cache?
>> 
>> It looks like a single group generates a LOT of traffic to AD like:
>> client -> IPA
>> IPA -> client
>> IPA -> AD
>> AD -> IPA
>> IPA -> AD
>> IPA -> Second AD
>> Second AD -> IPA
>> IPA -> Second AD
>> IPA -> AD
>> AD -> IPA
>> IPA -> AD
>> IPA -> client
>> client -> IPA
>> IPA -> Client
>> 
>> Something similar continues for every group the user has.
>> 
>> Soo, I guess the question that I haven't been able to find documented 
>> anywhere.
>> Isn't the SSSD group cache on the IPA servers supposed to be used then a sssd
>> client requests a user?
>> 
>> 
>> 
>> - On Feb 1, 2017, at 9:53 AM, Troels Hansen t...@casalogic.dk wrote:
>> 
>>> Hmm, suspect its happening on the server.. thous I haven't been able to
>>> pinpoint a log entry that confirms my suspecting.
>>> 
>>> I have pinpointed the timeout to happen after 58 seconds after completely
>>> removing the SSSD cache and restaring SSSD, which leads me to think my 
>>> issue is
>>> related to ldap_enumaration_search_timeout which defaults to 60.
>>> 
>>> rm -fr /var/lib/sss/{mc,db}/* && systemctl restart sssd && time id shja
>>> 
>>> However, I'm unable to crank it up on the server as it seems to be adjusted 
>>> Down
>>> to 60 Again?
>>> 
>>> Wed Feb  1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_get_options] (0x0400): 
>>> Option
>>> ldap_enumeration_search_timeout has value 120
>>> (Wed Feb  1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_copy_options_ex] 
>>> (0x0400):
>>> Option ldap_enumeration_search_timeout has value 60
>>> (Wed Feb  1 09:40:56 2017) [sssd[be[lx.dr.dk]]] [dp_copy_options_ex] 
>>> (0x0400):
>>> Option ldap_enumeration_search_timeout has value 60
>>> 
>>> LDAP seems speedy enough, not timeouts while querying it manually while a 
>>> client
>>> is doing a user lookup.
>>> 
>>> - On Jan 30, 2017, at 6:06 PM, Sullivan, Daniel [CRI]
>>> dsulliv...@bsd.uchicago.edu wrote:
>>> 
 
 If the timeout is occurring on the server, I would start by increasing one 
 or
 both of these values:
 
 ldap_opt_timeout
 ldap_search_timeout
 
 If that doesn’t work I’d take look to see if the 389 server is under high 
 load
 when you are performing this operation.  The easiest way I have found to do
 this is to just execute an LDAP query directly against the IPA server when 
 you
 are performing an id lookup, for example:
 
 ldapsearch -D "cn=Directory Manager" -w  -s base -b "cn=config"
 "(objectclass=*)”
 
 If the LDAP server is not responsive you probably need to increase the 
 number of
 worker threads for 389ds.  Also, you might want to disable referrals, 
 check out
 the man pages for this;
 
 ldap_referrals = false
 
 Also, FWIW, if you crank up debug logging on the sssd client, you should 
 be able
 to see the amount of seconds of timeout assigned to the operation, and 
 witness
 the fact that the operation is actually timing out by inspecting the logs
 themselves.  The logs can get a little verbose but the data is there.
 
>>> 
>>> --
>>> Manage your subscription for the Freeipa-users mailing list:
>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>> Go to http://freeipa.org for