Re: [Freeipa-users] IPA web ui always giving Your session has expired. Please re-login.
HI thanks sure this is the only place i can ask questions :) but i don't know from where i am getting that basic authentication window like .htaccess based. i think when i tried from chome only i got this window On Mon, Mar 9, 2015 at 2:21 PM, Martin Kosek mko...@redhat.com wrote: Ok, thanks for information. I would still love to know the real root cause, but we will now find it now I assume. Of this issue re-appears, let us know :-) Thanks, Martin On 03/09/2015 09:10 AM, Ben .T.George wrote: Hi Martin, thanks for your replay. yesterday i did lot of this to fix this issue. the issue has been solved by kdestroy and re-initiate the ticket. after that restarted ipa service, it got worked Regards, ben On Mon, Mar 9, 2015 at 10:57 AM, Martin Kosek mko...@redhat.com wrote: Thanks for all the data. So it looks like your browser properly forward the session cookie, but it is not recognized on the server even though it was stored before. Especially these lines are strange: [Sun Mar 08 13:16:29.909637 2015] [:error] [pid 3004] ipa: DEBUG: store session: session_id=4803e184cecb42f2e326391dbb09443d start_timestamp=2015-03-08T13:15:12 access_timestamp=2015-03-08T13:16:29 expiration_timestamp=2015-03-08T13:36:29 ... [Sun Mar 08 13:16:29.921519 2015] [:error] [pid 3003] ipa: DEBUG: found session cookie_id = 4803e184cecb42f2e326391dbb09443d [Sun Mar 08 13:16:29.921731 2015] [:error] [pid 3003] ipa: DEBUG: no session data in cache with id=4803e184cecb42f2e326391dbb09443d, generating empty session data We know that ipa_memcached is running. Can you please also check if there are no SELinux errors in /var/log/audit/audit.log preveting Apache from looking up the session data? Thanks, Martin On 03/08/2015 11:44 AM, Ben .T.George wrote: i was inspecting the page and got below response. http://s21.postimg.org/itv5hf0h3/asdasd.jpg http://s3.postimg.org/f6knomt1f/Capture.jpg please anyone help me to solve this issue. i just want to create one local user in IPA On Sun, Mar 8, 2015 at 1:17 PM, Ben .T.George bentech4...@gmail.com wrote: I enabled debugging mode on default.conf and this is what i am getting on error_log [Sun Mar 08 13:16:18.204363 2015] [auth_kerb:error] [pid 3065] [client 172.16.107.250:60088] gss_accept_sec_context() failed: An unsupported mechanism was requested (, Unknown error), referer: https://kwtpocpbis01.solaris.local/ipa/ui/ [Sun Mar 08 13:16:29.849339 2015] [:error] [pid 3004] ipa: DEBUG: WSGI wsgi_dispatch.__call__: [Sun Mar 08 13:16:29.849458 2015] [:error] [pid 3004] ipa: DEBUG: WSGI login_password.__call__: [Sun Mar 08 13:16:29.849683 2015] [:error] [pid 3004] ipa: DEBUG: Obtaining armor ccache: principal=HTTP/kwtpocpbis01.solaris.local@SOLARIS.LOCAL keytab=/etc/httpd/conf/ipa.keytab ccache=/var/run/ipa_memcached/krbcc_A_admin [Sun Mar 08 13:16:29.849830 2015] [:error] [pid 3004] ipa: DEBUG: Starting external process [Sun Mar 08 13:16:29.849923 2015] [:error] [pid 3004] ipa: DEBUG: args='/usr/bin/kinit' '-kt' '/etc/httpd/conf/ipa.keytab' 'HTTP/kwtpocpbis01.solaris.local@SOLARIS.LOCAL' [Sun Mar 08 13:16:29.868747 2015] [:error] [pid 3004] ipa: DEBUG: Process finished, return code=0 [Sun Mar 08 13:16:29.868858 2015] [:error] [pid 3004] ipa: DEBUG: stdout= [Sun Mar 08 13:16:29.868955 2015] [:error] [pid 3004] ipa: DEBUG: stderr= [Sun Mar 08 13:16:29.869120 2015] [:error] [pid 3004] ipa: DEBUG: Starting external process [Sun Mar 08 13:16:29.869204 2015] [:error] [pid 3004] ipa: DEBUG: args='/usr/bin/kinit' 'admin@SOLARIS.LOCAL' '-T' '/var/run/ipa_memcached/krbcc_A_admin' [Sun Mar 08 13:16:29.902181 2015] [:error] [pid 3004] ipa: DEBUG: Process finished, return code=0 [Sun Mar 08 13:16:29.902269 2015] [:error] [pid 3004] ipa: DEBUG: stdout=Password for admin@SOLARIS.LOCAL: [Sun Mar 08 13:16:29.902278 2015] [:error] [pid 3004] [Sun Mar 08 13:16:29.902328 2015] [:error] [pid 3004] ipa: DEBUG: stderr= [Sun Mar 08 13:16:29.902427 2015] [:error] [pid 3004] ipa: DEBUG: kinit: principal=admin@SOLARIS.LOCAL returncode=0, stderr= [Sun Mar 08 13:16:29.902483 2015] [:error] [pid 3004] ipa: DEBUG: Cleanup the armor ccache [Sun Mar 08 13:16:29.902560 2015] [:error] [pid 3004] ipa: DEBUG: Starting external process [Sun Mar 08 13:16:29.902621 2015] [:error] [pid 3004] ipa: DEBUG: args='/usr/bin/kdestroy' '-A' '-c' '/var/run/ipa_memcached/krbcc_A_admin' [Sun Mar 08 13:16:29.908045 2015] [:error] [pid 3004] ipa: DEBUG: Process finished, return code=0 [Sun Mar 08 13:16:29.908121 2015] [:error] [pid 3004] ipa: DEBUG: stdout= [Sun Mar 08 13:16:29.908173 2015] [:error] [pid 3004] ipa: DEBUG: stderr= [Sun Mar 08 13:16:29.908348 2015] [:error] [pid 3004] ipa: DEBUG: found session cookie_id = 4803e184cecb42f2e326391dbb09443d [Sun Mar 08 13:16:29.908647 2015] [:error]
Re: [Freeipa-users] IPA web ui always giving Your session has expired. Please re-login.
Ok, thanks for information. I would still love to know the real root cause, but we will now find it now I assume. Of this issue re-appears, let us know :-) Thanks, Martin On 03/09/2015 09:10 AM, Ben .T.George wrote: Hi Martin, thanks for your replay. yesterday i did lot of this to fix this issue. the issue has been solved by kdestroy and re-initiate the ticket. after that restarted ipa service, it got worked Regards, ben On Mon, Mar 9, 2015 at 10:57 AM, Martin Kosek mko...@redhat.com wrote: Thanks for all the data. So it looks like your browser properly forward the session cookie, but it is not recognized on the server even though it was stored before. Especially these lines are strange: [Sun Mar 08 13:16:29.909637 2015] [:error] [pid 3004] ipa: DEBUG: store session: session_id=4803e184cecb42f2e326391dbb09443d start_timestamp=2015-03-08T13:15:12 access_timestamp=2015-03-08T13:16:29 expiration_timestamp=2015-03-08T13:36:29 ... [Sun Mar 08 13:16:29.921519 2015] [:error] [pid 3003] ipa: DEBUG: found session cookie_id = 4803e184cecb42f2e326391dbb09443d [Sun Mar 08 13:16:29.921731 2015] [:error] [pid 3003] ipa: DEBUG: no session data in cache with id=4803e184cecb42f2e326391dbb09443d, generating empty session data We know that ipa_memcached is running. Can you please also check if there are no SELinux errors in /var/log/audit/audit.log preveting Apache from looking up the session data? Thanks, Martin On 03/08/2015 11:44 AM, Ben .T.George wrote: i was inspecting the page and got below response. http://s21.postimg.org/itv5hf0h3/asdasd.jpg http://s3.postimg.org/f6knomt1f/Capture.jpg please anyone help me to solve this issue. i just want to create one local user in IPA On Sun, Mar 8, 2015 at 1:17 PM, Ben .T.George bentech4...@gmail.com wrote: I enabled debugging mode on default.conf and this is what i am getting on error_log [Sun Mar 08 13:16:18.204363 2015] [auth_kerb:error] [pid 3065] [client 172.16.107.250:60088] gss_accept_sec_context() failed: An unsupported mechanism was requested (, Unknown error), referer: https://kwtpocpbis01.solaris.local/ipa/ui/ [Sun Mar 08 13:16:29.849339 2015] [:error] [pid 3004] ipa: DEBUG: WSGI wsgi_dispatch.__call__: [Sun Mar 08 13:16:29.849458 2015] [:error] [pid 3004] ipa: DEBUG: WSGI login_password.__call__: [Sun Mar 08 13:16:29.849683 2015] [:error] [pid 3004] ipa: DEBUG: Obtaining armor ccache: principal=HTTP/kwtpocpbis01.solaris.local@SOLARIS.LOCAL keytab=/etc/httpd/conf/ipa.keytab ccache=/var/run/ipa_memcached/krbcc_A_admin [Sun Mar 08 13:16:29.849830 2015] [:error] [pid 3004] ipa: DEBUG: Starting external process [Sun Mar 08 13:16:29.849923 2015] [:error] [pid 3004] ipa: DEBUG: args='/usr/bin/kinit' '-kt' '/etc/httpd/conf/ipa.keytab' 'HTTP/kwtpocpbis01.solaris.local@SOLARIS.LOCAL' [Sun Mar 08 13:16:29.868747 2015] [:error] [pid 3004] ipa: DEBUG: Process finished, return code=0 [Sun Mar 08 13:16:29.868858 2015] [:error] [pid 3004] ipa: DEBUG: stdout= [Sun Mar 08 13:16:29.868955 2015] [:error] [pid 3004] ipa: DEBUG: stderr= [Sun Mar 08 13:16:29.869120 2015] [:error] [pid 3004] ipa: DEBUG: Starting external process [Sun Mar 08 13:16:29.869204 2015] [:error] [pid 3004] ipa: DEBUG: args='/usr/bin/kinit' 'admin@SOLARIS.LOCAL' '-T' '/var/run/ipa_memcached/krbcc_A_admin' [Sun Mar 08 13:16:29.902181 2015] [:error] [pid 3004] ipa: DEBUG: Process finished, return code=0 [Sun Mar 08 13:16:29.902269 2015] [:error] [pid 3004] ipa: DEBUG: stdout=Password for admin@SOLARIS.LOCAL: [Sun Mar 08 13:16:29.902278 2015] [:error] [pid 3004] [Sun Mar 08 13:16:29.902328 2015] [:error] [pid 3004] ipa: DEBUG: stderr= [Sun Mar 08 13:16:29.902427 2015] [:error] [pid 3004] ipa: DEBUG: kinit: principal=admin@SOLARIS.LOCAL returncode=0, stderr= [Sun Mar 08 13:16:29.902483 2015] [:error] [pid 3004] ipa: DEBUG: Cleanup the armor ccache [Sun Mar 08 13:16:29.902560 2015] [:error] [pid 3004] ipa: DEBUG: Starting external process [Sun Mar 08 13:16:29.902621 2015] [:error] [pid 3004] ipa: DEBUG: args='/usr/bin/kdestroy' '-A' '-c' '/var/run/ipa_memcached/krbcc_A_admin' [Sun Mar 08 13:16:29.908045 2015] [:error] [pid 3004] ipa: DEBUG: Process finished, return code=0 [Sun Mar 08 13:16:29.908121 2015] [:error] [pid 3004] ipa: DEBUG: stdout= [Sun Mar 08 13:16:29.908173 2015] [:error] [pid 3004] ipa: DEBUG: stderr= [Sun Mar 08 13:16:29.908348 2015] [:error] [pid 3004] ipa: DEBUG: found session cookie_id = 4803e184cecb42f2e326391dbb09443d [Sun Mar 08 13:16:29.908647 2015] [:error] [pid 3004] ipa: DEBUG: found session data in cache with id=4803e184cecb42f2e326391dbb09443d [Sun Mar 08 13:16:29.908728 2015] [:error] [pid 3004] ipa: DEBUG: finalize_kerberos_acquisition: login_password ccache_name=FILE:/var/run/ipa_memcached/krbcc_3004 session_id=4803e184cecb42f2e326391dbb09443d [Sun Mar 08 13:16:29.908824 2015] [:error] [pid 3004] ipa: DEBUG: reading ccache data from file
[Freeipa-users] Filter/Block/Limit Interaction with Multiple Domain Controllers
Hi List I have AD trusts configured and working between an IPA server and a master primary domain controller (dc-1) in a forest in one data center. This allows me to connect with SSH to linux servers in the same data-center, authenticating with my AD credentials. I'm trying to test a scenario where I have an IPA server set up in another data center, and trust is established with an AD domain controller (dc-2) in that data-center. This domain controller takes dc-1 as it's authoritative source. Ideally, the IPA server will interact with the domain controller nearest to it (i.e dc-2), however, from tcpdump, I note the following: - IPA server communicates with dc-2 first - dc-2 returns a list of domain controllers in all the datacenters, including dc-1 the IPA server then begins querying ldap and kerberos ports on dc-1, the domain controller furthest from it. - Authentication on clients fail My question is: Is it possible to get IPA to query and interact only with the domain controller it initially established trust with? Thanks in advance, Traiano -- 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] Errors while adding DNS Zone
I'm getting some errors on a DNS Zone that I'm attempting to create. My systems reside within a sub-domain of example.com. (xyz.example.com) Of course example.com is the internet address, but I want to host the internal example.com so we're able to point to internal intranets and so on. So to the good stuff Regardless of what flags I give, what NS records I change, the NS never actually set. I know it's something silly that I'm overlooking but would really love other eyes. I go to create the zone on server2. [root@server2 html]# ipa dnszone-add example.com Zone name: example.com. Active zone: TRUE Authoritative nameserver: server2.xyz.example.com. Administrator e-mail address: hostmaster SOA serial: 1425924224 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 BIND update policy: grant xyz.example.com krb5-self * A; grant xyz.example.com krb5-self * ; grant xyz.example.com krb5-self * SSHFP; Dynamic update: FALSE Allow query: any; Allow transfer: none; [root@server2 html]# rndc reload server reload successful Logs on server1 show this Mar 09 18:03:48 server1.xyz.example.com named-pkcs11[23279]: zone example.com/IN: NS 'server2.xyz.example.com' has no address records (A or ) Mar 09 18:03:48 server1.xyz.example.com named-pkcs11[23279]: zone example.com/IN: NS 'server1.xyz.example.com' has no address records (A or ) Mar 09 18:03:48 server1.xyz.example.com named-pkcs11[23279]: zone example.com/IN: not loaded due to errors. Mar 09 18:03:48 server1.xyz.example.com named-pkcs11[23279]: update_zone (syncrepl) failed for 'idnsname=example.com.,cn=dns,dc=xyz,dc=example,dc=com'. Zones can be outdated, run `rndc reload`: bad zone Mar 09 18:03:48 server1.xyz.example.com named-pkcs11[23279]: zone example.com/IN: NS 'server2.xyz.example.com' has no address records (A or ) Mar 09 18:03:48 server1.xyz.example.com named-pkcs11[23279]: zone example.com/IN: NS 'server1.xyz.example.com' has no address records (A or ) Mar 09 18:03:48 server1.xyz.example.com named-pkcs11[23279]: zone example.com/IN: not loaded due to errors. Mar 09 18:03:48 server1.xyz.example.com named-pkcs11[23279]: update_zone (syncrepl) failed for 'idnsname=example.com.,cn=dns,dc=xyz,dc=example,dc=com'. Zones can be outdated, run `rndc reload`: bad zone Mar 09 18:03:51 server1.xyz.example.com named-pkcs11[23279]: zone example.com/IN: NS 'server2.xyz.example.com' has no address records (A or ) Mar 09 18:03:51 server1.xyz.example.com named-pkcs11[23279]: zone example.com/IN: NS 'server1.xyz.example.com' has no address records (A or ) Mar 09 18:03:51 server1.xyz.example.com named-pkcs11[23279]: zone example.com/IN: not loaded due to errors. Mar 09 18:03:51 server1.xyz.example.com named-pkcs11[23279]: zone example.com/IN: unable to reload invalid zone; reload triggered by change in 'idnsname=_kerberos,idnsname=example.com.,cn=dns,dc=xyz,dc=example,dc=com':bad zone Mar 09 18:03:51 server1.xyz.example.com named-pkcs11[23279]: zone example.com/IN: NS 'server2.xyz.example.com' has no address records (A or ) Mar 09 18:03:51 server1.xyz.example.com named-pkcs11[23279]: zone example.com/IN: NS 'server1.xyz.example.com' has no address records (A or ) Mar 09 18:03:51 server1.xyz.example.com named-pkcs11[23279]: zone example.com/IN: not loaded due to errors. Mar 09 18:03:51 server1.xyz.example.com named-pkcs11[23279]: update_zone (syncrepl) failed for 'idnsname=example.com.,cn=dns,dc=xyz,dc=example,dc=com'. Zones can be outdated, run `rndc reload`: bad zone -- 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] Filter/Block/Limit Interaction with Multiple Domain Controllers
On Mon, 09 Mar 2015, Traiano Welcome wrote: Hi List I have AD trusts configured and working between an IPA server and a master primary domain controller (dc-1) in a forest in one data center. This allows me to connect with SSH to linux servers in the same data-center, authenticating with my AD credentials. I'm trying to test a scenario where I have an IPA server set up in another data center, and trust is established with an AD domain controller (dc-2) in that data-center. This domain controller takes dc-1 as it's authoritative source. Ideally, the IPA server will interact with the domain controller nearest to it (i.e dc-2), however, from tcpdump, I note the following: - IPA server communicates with dc-2 first - dc-2 returns a list of domain controllers in all the datacenters, including dc-1 the IPA server then begins querying ldap and kerberos ports on dc-1, the domain controller furthest from it. - Authentication on clients fail My question is: Is it possible to get IPA to query and interact only with the domain controller it initially established trust with? Let's first separate multiple issues. 1. Terminology Cross-forest trust is established between domain controllers in forest root domains. In case of IPA we need that access only once, when trust is created. You don't need to establish trust again with dc-2 once you have established it with dc-1. When trust is established, AD DCs will look up IPA masters via SRV records in DNS (_ldap._tcp.ipa-domain). We don't provide site-specific SRV records as IPA does not handle sites in this area yet. However, this is not your problem. 2. User and group lookups are done by SSSD against global catalog service (_gc._tcp.ad-domain) and AD DS (_ldap._tcp.ad-domain), along with Kerberos KDC (AD DCs). These DCs are found via SRV records in DNS and SSSD since 1.9.5 uses site-specific SRV records for AD domain controllers lookups in case of IPA-AD trust. You are interested in (2) being site-aware. However, you didn't say what is your distribution and software versions so it is quite hard to give any recommendation. -- / 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] Error establishing trust with AD domain
Ok - I'll answer my own question. I needed to establish the trust with the forest-root domain (domain.com), not the child domain. I have verified using 'ipa trustdomain-find' that I can see the child domain (ad.domain.com) now. Sorry for the noise! Thanks, Josh From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Baird, Josh Sent: Monday, March 09, 2015 5:06 PM To: freeipa-users@redhat.com Subject: [Freeipa-users] Error establishing trust with AD domain Hi, I have successfully established a trust in my lab environment running IPA 4.1 (RHEL7.1) and a Windows 2008 R2 domain with Windows 2003 domain/forest functional levels. I'm now trying to establish a trust with my production AD domain (same functional level). The only difference is that my production domain (ad.domain.lan) is a child-domain of a forest named domain.lan. There is no forest in my lab envrionment. I'm getting the following error when running 'ipa trust-add': # ipa trust-add --type ad ad.domain.lan --range-type=ipa-ad-trust --admin jbadmin --password Active Directory domain administrator's password: ipa: ERROR: Domain 'ad.domain.lan' is not a root domain for forest 'domain.lan' Any ideas? Thanks, Josh -- 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] Filter/Block/Limit Interaction with Multiple Domain Controllers
On 03/09/2015 02:29 PM, Traiano Welcome wrote: Hi Alexander Thanks for the response: On Mon, Mar 9, 2015 at 8:04 PM, Alexander Bokovoy aboko...@redhat.com wrote: On Mon, 09 Mar 2015, Traiano Welcome wrote: Hi List I have AD trusts configured and working between an IPA server and a master primary domain controller (dc-1) in a forest in one data center. This allows me to connect with SSH to linux servers in the same data-center, authenticating with my AD credentials. I'm trying to test a scenario where I have an IPA server set up in another data center, and trust is established with an AD domain controller (dc-2) in that data-center. This domain controller takes dc-1 as it's authoritative source. Ideally, the IPA server will interact with the domain controller nearest to it (i.e dc-2), however, from tcpdump, I note the following: - IPA server communicates with dc-2 first - dc-2 returns a list of domain controllers in all the datacenters, including dc-1 the IPA server then begins querying ldap and kerberos ports on dc-1, the domain controller furthest from it. - Authentication on clients fail My question is: Is it possible to get IPA to query and interact only with the domain controller it initially established trust with? Let's first separate multiple issues. 1. Terminology Cross-forest trust is established between domain controllers in forest root domains. In case of IPA we need that access only once, when trust is created. You don't need to establish trust again with dc-2 once you have established it with dc-1. When trust is established, AD DCs will look up IPA masters via SRV records in DNS (_ldap._tcp.ipa-domain). We don't provide site-specific SRV records as IPA does not handle sites in this area yet. Thanks for the clarification. However, this is not your problem. 2. User and group lookups are done by SSSD against global catalog service (_gc._tcp.ad-domain) and AD DS (_ldap._tcp.ad-domain), along with Kerberos KDC (AD DCs). These DCs are found via SRV records in DNS and SSSD since 1.9.5 uses site-specific SRV records for AD domain controllers lookups in case of IPA-AD trust. You are interested in (2) being site-aware. However, you didn't say what is your distribution and software versions so it is quite hard to give any recommendation. My objective is basically distribution of IPA servers across multiple data centers linked by a WAN: - There is a central 'head office' with an AD domain-controller, this is the primary source of identity for the domain. - A number of other data-centers each have their own local AD domain controller linked to the head-office domain controller - The datacenters are in different timezones. - An IPA server in each data-center with trust established with the local domain controller - Each IPA server is configured with it's own realm, but provides access to the global AD domain via AD Trusts The idea was to prevent IPA authentication related traffic going across the WAN (latency, different time-zones etc) to a central ad domain controller at head office. So this setup seemed reasonable. I'm using IPA v3.3 distributed with the CentOS 7 DVD. For reference, the working setup was based on this howto: http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Description ... which works fine if the IPA server has a trust relationship directly with the primary domain controller at head office (which it is collocated with). I can live without site-awareness per se if I can achieve IPA centralised authentication across datacenters in different timezones, with AD as the primary source of identity. An alternative setup that I've considered testing: - IPA server at the head office with trust established to the primary AD DC. - A replica of the primary in each DC (different timezones), on the same realm However, I doubt replicas can work across timezones, and with high WAN latencies. As Alexander said the trust on the fores level. There is no pairing between IPA replicas and AD DCs to a specific data center. What you need to concentrate is making sure that SSSD on a client picks AD in the local data center and IPA in the same data center (for the additional lookup operations). I do not know whether one can explicitly set this in sssd.conf. This is something to ask SSSD list. The alternative would be to make DNS return the right server. For AD DC the AD DNS will be returning the server to authenticate against and there should be a way to configure AD DNS this way. I do not think it is possible to force specific DNS entry out of IPA - it does not support sites yet. But may be there is a way to override it on SSSD. In case of other (legacy Linux or other platforms) clients that talk to IPA you can configure them with the explicit fail over list. They do not talk to AD directly. You might also consider configuring SSSD on the IPA server to use AD in the same location as a primary server. HTH --
[Freeipa-users] Error establishing trust with AD domain
Hi, I have successfully established a trust in my lab environment running IPA 4.1 (RHEL7.1) and a Windows 2008 R2 domain with Windows 2003 domain/forest functional levels. I'm now trying to establish a trust with my production AD domain (same functional level). The only difference is that my production domain (ad.domain.lan) is a child-domain of a forest named domain.lan. There is no forest in my lab envrionment. I'm getting the following error when running 'ipa trust-add': # ipa trust-add --type ad ad.domain.lan --range-type=ipa-ad-trust --admin jbadmin --password Active Directory domain administrator's password: ipa: ERROR: Domain 'ad.domain.lan' is not a root domain for forest 'domain.lan' Any ideas? Thanks, Josh -- 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] Error in replication while inserting a RHEL7.1 server into a RHEL6.6 IPA setup.
On 03/09/2015 03:35 PM, Steven Jones wrote:
Any idea what is going on here please?
==
[root@vuwunicoipam004 mailto:root@vuwunicoipam004 ipa-certs]#
ipa-replica-install --setup-dns --forwarder=10.100.32.31 -U
replica-info-vuwunicoipam004.ods.vuw.ac.nz.gpg --skip-conncheck
Checking forwarders, please wait ...
WARNING: DNS forwarder 10.100.32.31 does not return DNSSEC signatures in answers
Please fix forwarder configuration to enable DNSSEC support.
(For BIND 9 add directive dnssec-enable yes; to options {})
WARNING: DNSSEC validation will be disabled
I don't know if this is a problem, so I will leave it to our DNS gurus
to answer.
Directory Manager (existing master) password:
Adding [10.100.32.50 vuwunicoipam004.ods.vuw.ac.nz] to your /etc/hosts file
Using reverse zone(s) 32.100.10.in-addr.arpa.
Configuring NTP daemon (ntpd)
[1/4]: stopping ntpd
[2/4]: writing configuration
[3/4]: configuring ntpd to start on boot
[4/4]: starting ntpd
Done configuring NTP daemon (ntpd).
Configuring directory server (dirsrv): Estimated time 1 minute
[1/35]: creating directory server user
[2/35]: creating directory server instance
[3/35]: adding default schema
[4/35]: enabling memberof plugin
[5/35]: enabling winsync plugin
[6/35]: configuring replication version plugin
[7/35]: enabling IPA enrollment plugin
[8/35]: enabling ldapi
[9/35]: configuring uniqueness plugin
[10/35]: configuring uuid plugin
[11/35]: configuring modrdn plugin
[12/35]: configuring DNS plugin
[13/35]: enabling entryUSN plugin
[14/35]: configuring lockout plugin
[15/35]: creating indices
[16/35]: enabling referential integrity plugin
[17/35]: configuring ssl for ds instance
[18/35]: configuring certmap.conf
[19/35]: configure autobind for root
[20/35]: configure new location for managed entries
[21/35]: configure dirsrv ccache
[22/35]: enable SASL mapping fallback
[23/35]: restarting directory server
[24/35]: setting up initial replication
Starting replication, please wait until this has completed.
Update in progress, 128 seconds elapsed
[vuwunicoipam002.ods.vuw.ac.nz] reports: Update failed! Status: [10 Total
update abortedLDAP error: Referral]
If the client got back a referral, it means the replica was being
re-initialized at this time. Sounds like either the client is not
checking to see if the initialization is complete, or the server is
reporting back erroneously that initialization is complete.
[error] RuntimeError: Failed to start replication
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.
Failed to start replication
[root@vuwunicoipam004 mailto:root@vuwunicoipam004 ipa-certs]#
No firewalls are active and the network is a simple vyos virtual router.
=
[root@vuwunicoipam002 mailto:root@vuwunicoipam002 etc]# iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
[root@vuwunicoipam002 mailto:root@vuwunicoipam002 etc]#
=
=
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
[root@vuwunicoipam004 mailto:root@vuwunicoipam004 ipa-certs]#
=
regards
Steven
--
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] Error in replication while inserting a RHEL7.1 server into a RHEL6.6 IPA setup.
Any idea what is going on here please?
==
[root@vuwunicoipam004mailto:root@vuwunicoipam004 ipa-certs]#
ipa-replica-install --setup-dns --forwarder=10.100.32.31 -U
replica-info-vuwunicoipam004.ods.vuw.ac.nz.gpg --skip-conncheck
Checking forwarders, please wait ...
WARNING: DNS forwarder 10.100.32.31 does not return DNSSEC signatures in answers
Please fix forwarder configuration to enable DNSSEC support.
(For BIND 9 add directive dnssec-enable yes; to options {})
WARNING: DNSSEC validation will be disabled
Directory Manager (existing master) password:
Adding [10.100.32.50 vuwunicoipam004.ods.vuw.ac.nz] to your /etc/hosts file
Using reverse zone(s) 32.100.10.in-addr.arpa.
Configuring NTP daemon (ntpd)
[1/4]: stopping ntpd
[2/4]: writing configuration
[3/4]: configuring ntpd to start on boot
[4/4]: starting ntpd
Done configuring NTP daemon (ntpd).
Configuring directory server (dirsrv): Estimated time 1 minute
[1/35]: creating directory server user
[2/35]: creating directory server instance
[3/35]: adding default schema
[4/35]: enabling memberof plugin
[5/35]: enabling winsync plugin
[6/35]: configuring replication version plugin
[7/35]: enabling IPA enrollment plugin
[8/35]: enabling ldapi
[9/35]: configuring uniqueness plugin
[10/35]: configuring uuid plugin
[11/35]: configuring modrdn plugin
[12/35]: configuring DNS plugin
[13/35]: enabling entryUSN plugin
[14/35]: configuring lockout plugin
[15/35]: creating indices
[16/35]: enabling referential integrity plugin
[17/35]: configuring ssl for ds instance
[18/35]: configuring certmap.conf
[19/35]: configure autobind for root
[20/35]: configure new location for managed entries
[21/35]: configure dirsrv ccache
[22/35]: enable SASL mapping fallback
[23/35]: restarting directory server
[24/35]: setting up initial replication
Starting replication, please wait until this has completed.
Update in progress, 128 seconds elapsed
[vuwunicoipam002.ods.vuw.ac.nz] reports: Update failed! Status: [10 Total
update abortedLDAP error: Referral]
[error] RuntimeError: Failed to start replication
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.
Failed to start replication
[root@vuwunicoipam004mailto:root@vuwunicoipam004 ipa-certs]#
No firewalls are active and the network is a simple vyos virtual router.
=
[root@vuwunicoipam002mailto:root@vuwunicoipam002 etc]# iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
[root@vuwunicoipam002mailto:root@vuwunicoipam002 etc]#
=
=
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
[root@vuwunicoipam004mailto:root@vuwunicoipam004 ipa-certs]#
=
regards
Steven
--
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] Filter/Block/Limit Interaction with Multiple Domain Controllers
On Mon, 09 Mar 2015, Traiano Welcome wrote: Hi Alexander Thanks for the response: On Mon, Mar 9, 2015 at 8:04 PM, Alexander Bokovoy aboko...@redhat.com wrote: On Mon, 09 Mar 2015, Traiano Welcome wrote: Hi List I have AD trusts configured and working between an IPA server and a master primary domain controller (dc-1) in a forest in one data center. This allows me to connect with SSH to linux servers in the same data-center, authenticating with my AD credentials. I'm trying to test a scenario where I have an IPA server set up in another data center, and trust is established with an AD domain controller (dc-2) in that data-center. This domain controller takes dc-1 as it's authoritative source. Ideally, the IPA server will interact with the domain controller nearest to it (i.e dc-2), however, from tcpdump, I note the following: - IPA server communicates with dc-2 first - dc-2 returns a list of domain controllers in all the datacenters, including dc-1 the IPA server then begins querying ldap and kerberos ports on dc-1, the domain controller furthest from it. - Authentication on clients fail My question is: Is it possible to get IPA to query and interact only with the domain controller it initially established trust with? Let's first separate multiple issues. 1. Terminology Cross-forest trust is established between domain controllers in forest root domains. In case of IPA we need that access only once, when trust is created. You don't need to establish trust again with dc-2 once you have established it with dc-1. When trust is established, AD DCs will look up IPA masters via SRV records in DNS (_ldap._tcp.ipa-domain). We don't provide site-specific SRV records as IPA does not handle sites in this area yet. Thanks for the clarification. However, this is not your problem. 2. User and group lookups are done by SSSD against global catalog service (_gc._tcp.ad-domain) and AD DS (_ldap._tcp.ad-domain), along with Kerberos KDC (AD DCs). These DCs are found via SRV records in DNS and SSSD since 1.9.5 uses site-specific SRV records for AD domain controllers lookups in case of IPA-AD trust. You are interested in (2) being site-aware. However, you didn't say what is your distribution and software versions so it is quite hard to give any recommendation. My objective is basically distribution of IPA servers across multiple data centers linked by a WAN: - There is a central 'head office' with an AD domain-controller, this is the primary source of identity for the domain. - A number of other data-centers each have their own local AD domain controller linked to the head-office domain controller - The datacenters are in different timezones. - An IPA server in each data-center with trust established with the local domain controller - Each IPA server is configured with it's own realm, but provides access to the global AD domain via AD Trusts The idea was to prevent IPA authentication related traffic going across the WAN (latency, different time-zones etc) to a central ad domain controller at head office. So this setup seemed reasonable. Do you have sites defined in AD? If so, can you enable debug_level=10 in /etc/sssd/sssd.conf on IPA master in the other datacenter and attempt to login as AD user. We'll see in SSSD logs how it discovers what AD DC to talk to. Add following to /etc/sssd/sssd.conf: [domain/..] .. debug_level = 10 [nss] debug_level = 10 and restart sssd. I'm using IPA v3.3 distributed with the CentOS 7 DVD. For reference, the working setup was based on this howto: http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Description ... which works fine if the IPA server has a trust relationship directly with the primary domain controller at head office (which it is collocated with). I can live without site-awareness per se if I can achieve IPA centralised authentication across datacenters in different timezones, with AD as the primary source of identity. An alternative setup that I've considered testing: - IPA server at the head office with trust established to the primary AD DC. - A replica of the primary in each DC (different timezones), on the same realm Currently each master has to be prepared with ipa-adtrust-install if any of IPA clients connected to this master need to be accessible to AD users. -- / 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] Trying to migrate, can't set hashed passwords
On Mon, 09 Mar 2015, Ben Slusky wrote: Greetings FreeIPA users, I'm setting up FreeIPA service in our production environment to replace several different authentication methods for various systems. I'm trying to migrate the first wave of users now My plan was to copy their passwords from an old LDAP directory (one of the aforementioned several authentication methods) and then send them to the migration page to finish the job. Even in migration mode, you can only set pre-hashed passwords when creating the records, not when modifying them. bslu...@ipa1.aws:~$ head techteam-passwords.ldif dn: uid=user1001,cn=users,cn=accounts,dc=smartling,dc=int changeType: modify replace: userPassword userPassword:: e1NTSE[...] - dn: uid=user1002,cn=users,cn=accounts,dc=smartling,dc=int changeType: modify replace: userPassword userPassword:: e1NIQX[...] Unfortunately it isn't working: bslu...@ipa1.aws:~$ ldapmodify -x -D cn=directory\ manager -W -f techteam-passwords.ldif Enter LDAP Password: modifying entry uid=user1001,cn=users,cn=accounts,dc=smartling,dc=int ldap_modify: Operations error (1) I found some possible causes of this error, and fixed them: bslu...@ipa1.aws:~$ ipa config-show |grep migration Enable migration mode: TRUE bslu...@ipa1.aws:~$ ldapsearch -x -D cn=directory\ manager -W -b cn=config |grep allow-hashed Enter LDAP Password: nsslapd-allow-hashed-passwords: on Still no soap. Any suggestions? Works as designed. We only allow unhashed passwords in migration mode when entry is added, not modified. -- / 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] Filter/Block/Limit Interaction with Multiple Domain Controllers
On Mon, Mar 09, 2015 at 02:58:14PM -0400, Dmitri Pal wrote: On 03/09/2015 02:29 PM, Traiano Welcome wrote: Hi Alexander Thanks for the response: On Mon, Mar 9, 2015 at 8:04 PM, Alexander Bokovoy aboko...@redhat.com wrote: On Mon, 09 Mar 2015, Traiano Welcome wrote: Hi List I have AD trusts configured and working between an IPA server and a master primary domain controller (dc-1) in a forest in one data center. This allows me to connect with SSH to linux servers in the same data-center, authenticating with my AD credentials. I'm trying to test a scenario where I have an IPA server set up in another data center, and trust is established with an AD domain controller (dc-2) in that data-center. This domain controller takes dc-1 as it's authoritative source. Ideally, the IPA server will interact with the domain controller nearest to it (i.e dc-2), however, from tcpdump, I note the following: - IPA server communicates with dc-2 first - dc-2 returns a list of domain controllers in all the datacenters, including dc-1 the IPA server then begins querying ldap and kerberos ports on dc-1, the domain controller furthest from it. - Authentication on clients fail My question is: Is it possible to get IPA to query and interact only with the domain controller it initially established trust with? Let's first separate multiple issues. 1. Terminology Cross-forest trust is established between domain controllers in forest root domains. In case of IPA we need that access only once, when trust is created. You don't need to establish trust again with dc-2 once you have established it with dc-1. When trust is established, AD DCs will look up IPA masters via SRV records in DNS (_ldap._tcp.ipa-domain). We don't provide site-specific SRV records as IPA does not handle sites in this area yet. Thanks for the clarification. However, this is not your problem. 2. User and group lookups are done by SSSD against global catalog service (_gc._tcp.ad-domain) and AD DS (_ldap._tcp.ad-domain), along with Kerberos KDC (AD DCs). These DCs are found via SRV records in DNS and SSSD since 1.9.5 uses site-specific SRV records for AD domain controllers lookups in case of IPA-AD trust. You are interested in (2) being site-aware. However, you didn't say what is your distribution and software versions so it is quite hard to give any recommendation. My objective is basically distribution of IPA servers across multiple data centers linked by a WAN: - There is a central 'head office' with an AD domain-controller, this is the primary source of identity for the domain. - A number of other data-centers each have their own local AD domain controller linked to the head-office domain controller - The datacenters are in different timezones. - An IPA server in each data-center with trust established with the local domain controller - Each IPA server is configured with it's own realm, but provides access to the global AD domain via AD Trusts The idea was to prevent IPA authentication related traffic going across the WAN (latency, different time-zones etc) to a central ad domain controller at head office. So this setup seemed reasonable. I'm using IPA v3.3 distributed with the CentOS 7 DVD. For reference, the working setup was based on this howto: http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Description ... which works fine if the IPA server has a trust relationship directly with the primary domain controller at head office (which it is collocated with). I can live without site-awareness per se if I can achieve IPA centralised authentication across datacenters in different timezones, with AD as the primary source of identity. An alternative setup that I've considered testing: - IPA server at the head office with trust established to the primary AD DC. - A replica of the primary in each DC (different timezones), on the same realm However, I doubt replicas can work across timezones, and with high WAN latencies. As Alexander said the trust on the fores level. There is no pairing between IPA replicas and AD DCs to a specific data center. What you need to concentrate is making sure that SSSD on a client picks AD in the local data center and IPA in the same data center (for the additional lookup operations). I do not know whether one can explicitly set this in sssd.conf. This is something to ask SSSD list. The alternative would be to make DNS return the right server. You can set the site and the DNS domain for the direct integration, but not for the server mode. The server mode is designed to operate with mostly defaults -- the reason not being that much that we don't want to support configuration, but the current failover code can't handle two totally separate domains in a single back end. This is a known pain point me and Pavel Brezina were talking about for a long time.
Re: [Freeipa-users] Error in replication while inserting a RHEL7.1 server into a RHEL6.6 IPA setup.
On 03/09/2015 05:35 PM, Steven Jones wrote:
Any idea what is going on here please?
==
[root@vuwunicoipam004 mailto:root@vuwunicoipam004 ipa-certs]#
ipa-replica-install --setup-dns --forwarder=10.100.32.31 -U
replica-info-vuwunicoipam004.ods.vuw.ac.nz.gpg --skip-conncheck
Why are you skipping a connection check?
The check will find issues like this ahead of time.
I suspect there is something wrong with either DNS entries for LDAP
server records or LDAP or Kerberos port is not open between new replica
and master.
At least I would try with connection check on and see if it gives some
hints.
Checking forwarders, please wait ...
WARNING: DNS forwarder 10.100.32.31 does not return DNSSEC signatures in answers
Please fix forwarder configuration to enable DNSSEC support.
(For BIND 9 add directive dnssec-enable yes; to options {})
WARNING: DNSSEC validation will be disabled
Directory Manager (existing master) password:
Adding [10.100.32.50 vuwunicoipam004.ods.vuw.ac.nz] to your /etc/hosts file
Using reverse zone(s) 32.100.10.in-addr.arpa.
Configuring NTP daemon (ntpd)
[1/4]: stopping ntpd
[2/4]: writing configuration
[3/4]: configuring ntpd to start on boot
[4/4]: starting ntpd
Done configuring NTP daemon (ntpd).
Configuring directory server (dirsrv): Estimated time 1 minute
[1/35]: creating directory server user
[2/35]: creating directory server instance
[3/35]: adding default schema
[4/35]: enabling memberof plugin
[5/35]: enabling winsync plugin
[6/35]: configuring replication version plugin
[7/35]: enabling IPA enrollment plugin
[8/35]: enabling ldapi
[9/35]: configuring uniqueness plugin
[10/35]: configuring uuid plugin
[11/35]: configuring modrdn plugin
[12/35]: configuring DNS plugin
[13/35]: enabling entryUSN plugin
[14/35]: configuring lockout plugin
[15/35]: creating indices
[16/35]: enabling referential integrity plugin
[17/35]: configuring ssl for ds instance
[18/35]: configuring certmap.conf
[19/35]: configure autobind for root
[20/35]: configure new location for managed entries
[21/35]: configure dirsrv ccache
[22/35]: enable SASL mapping fallback
[23/35]: restarting directory server
[24/35]: setting up initial replication
Starting replication, please wait until this has completed.
Update in progress, 128 seconds elapsed
[vuwunicoipam002.ods.vuw.ac.nz] reports: Update failed! Status: [10 Total
update abortedLDAP error: Referral]
[error] RuntimeError: Failed to start replication
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.
Failed to start replication
[root@vuwunicoipam004 mailto:root@vuwunicoipam004 ipa-certs]#
No firewalls are active and the network is a simple vyos virtual router.
=
[root@vuwunicoipam002 mailto:root@vuwunicoipam002 etc]# iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
[root@vuwunicoipam002 mailto:root@vuwunicoipam002 etc]#
=
=
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
[root@vuwunicoipam004 mailto:root@vuwunicoipam004 ipa-certs]#
=
regards
Steven
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Adding FreeIPA as a vsphere identity source
I've update the ACI's but am still getting the same error as before. I am
guessing this is probably related to the same issue in the other concurrent
vsphere 5.5 email thread that is going. I'll just keep my eye on that to see
the resolution.
On 3/6/2015 at 3:45 PM, Martin Kosek mko...@redhat.com wrote:
On 03/06/2015 08:35 AM, Alexander Bokovoy wrote:
On Fri, 06 Mar 2015, Martin Kosek wrote:
On 03/06/2015 02:24 AM, re...@hushmail.com wrote:
Just to confirm I should restart the server after i've run the
ldapmodify?
Right. It would be safer thing to do, if you modified the Schema
Compatibility config. At least to make sure it re-creates the
entries from
scratch.
Also I've used ldap modify to remove the 'uniqueMember' object
class from
the compat schema and added the 'sn=%{sn}' attribute and I
still am having
no luck. I get the same 'identity source may be malfunctioning
error' from
vpshere.
The key here is to see the Directory Server access log, to see
what kind of
LDAP searches is vSphere doing and then seeing the actual
entries in FreeIPA
with ldapsearch (or any GUI, I use Apache Directory Studio).
With this
knowledge, you should just need to update either the Schema
Compatibility
plugin configuration or vSphere configuration.
Note also that in 4.1 we have ACIs that only give access to
certain
attributes within compat tree and not all of them. Adding a new
attribute requires to add an ACI to allow serving it.
If this is an issue, you'd see the difference when accessing as
cn=Directory Manager or as any other authenticated bind.
Very good point Alexander! I unfortunately did my tests either as
admin or DM.
I updated the HOWTO with the new step that fixed it for me.
http://www.freeipa.org/page/HowTo/vsphere5_integration#Permission_U
pdate
So reesb, after the update above, you should get it working.
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] Filter/Block/Limit Interaction with Multiple Domain Controllers
On 03/09/2015 03:40 PM, Jakub Hrozek wrote: On Mon, Mar 09, 2015 at 02:58:14PM -0400, Dmitri Pal wrote: On 03/09/2015 02:29 PM, Traiano Welcome wrote: Hi Alexander Thanks for the response: On Mon, Mar 9, 2015 at 8:04 PM, Alexander Bokovoy aboko...@redhat.com wrote: On Mon, 09 Mar 2015, Traiano Welcome wrote: Hi List I have AD trusts configured and working between an IPA server and a master primary domain controller (dc-1) in a forest in one data center. This allows me to connect with SSH to linux servers in the same data-center, authenticating with my AD credentials. I'm trying to test a scenario where I have an IPA server set up in another data center, and trust is established with an AD domain controller (dc-2) in that data-center. This domain controller takes dc-1 as it's authoritative source. Ideally, the IPA server will interact with the domain controller nearest to it (i.e dc-2), however, from tcpdump, I note the following: - IPA server communicates with dc-2 first - dc-2 returns a list of domain controllers in all the datacenters, including dc-1 the IPA server then begins querying ldap and kerberos ports on dc-1, the domain controller furthest from it. - Authentication on clients fail My question is: Is it possible to get IPA to query and interact only with the domain controller it initially established trust with? Let's first separate multiple issues. 1. Terminology Cross-forest trust is established between domain controllers in forest root domains. In case of IPA we need that access only once, when trust is created. You don't need to establish trust again with dc-2 once you have established it with dc-1. When trust is established, AD DCs will look up IPA masters via SRV records in DNS (_ldap._tcp.ipa-domain). We don't provide site-specific SRV records as IPA does not handle sites in this area yet. Thanks for the clarification. However, this is not your problem. 2. User and group lookups are done by SSSD against global catalog service (_gc._tcp.ad-domain) and AD DS (_ldap._tcp.ad-domain), along with Kerberos KDC (AD DCs). These DCs are found via SRV records in DNS and SSSD since 1.9.5 uses site-specific SRV records for AD domain controllers lookups in case of IPA-AD trust. You are interested in (2) being site-aware. However, you didn't say what is your distribution and software versions so it is quite hard to give any recommendation. My objective is basically distribution of IPA servers across multiple data centers linked by a WAN: - There is a central 'head office' with an AD domain-controller, this is the primary source of identity for the domain. - A number of other data-centers each have their own local AD domain controller linked to the head-office domain controller - The datacenters are in different timezones. - An IPA server in each data-center with trust established with the local domain controller - Each IPA server is configured with it's own realm, but provides access to the global AD domain via AD Trusts The idea was to prevent IPA authentication related traffic going across the WAN (latency, different time-zones etc) to a central ad domain controller at head office. So this setup seemed reasonable. I'm using IPA v3.3 distributed with the CentOS 7 DVD. For reference, the working setup was based on this howto: http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Description ... which works fine if the IPA server has a trust relationship directly with the primary domain controller at head office (which it is collocated with). I can live without site-awareness per se if I can achieve IPA centralised authentication across datacenters in different timezones, with AD as the primary source of identity. An alternative setup that I've considered testing: - IPA server at the head office with trust established to the primary AD DC. - A replica of the primary in each DC (different timezones), on the same realm However, I doubt replicas can work across timezones, and with high WAN latencies. As Alexander said the trust on the fores level. There is no pairing between IPA replicas and AD DCs to a specific data center. What you need to concentrate is making sure that SSSD on a client picks AD in the local data center and IPA in the same data center (for the additional lookup operations). I do not know whether one can explicitly set this in sssd.conf. This is something to ask SSSD list. The alternative would be to make DNS return the right server. You can set the site and the DNS domain for the direct integration, but not for the server mode. The server mode is designed to operate with mostly defaults -- the reason not being that much that we don't want to support configuration, but the current failover code can't handle two totally separate domains in a single back end. This is a known pain point me and Pavel Brezina were talking about for a long time. So far there hasn't been a driver that would justify
Re: [Freeipa-users] Error in replication while inserting a RHEL7.1 server into a RHEL6.6 IPA setup.
It usually fails, hence I skip it.
Since I have no firewall either side and I know I have a simple network since I
built there is nothing possible blocking in-between.
I will double check the DNS zone file.
I had to rename the server to ipam004 as the replica attempt sulked if i
re-used an old hostname, ipam001.
regards
Steven
From: freeipa-users-boun...@redhat.com freeipa-users-boun...@redhat.com on
behalf of Dmitri Pal d...@redhat.com
Sent: Tuesday, 10 March 2015 1:22 p.m.
To: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Error in replication while inserting a RHEL7.1
server into a RHEL6.6 IPA setup.
On 03/09/2015 05:35 PM, Steven Jones wrote:
Any idea what is going on here please?
==
[root@vuwunicoipam004mailto:root@vuwunicoipam004 ipa-certs]#
ipa-replica-install --setup-dns --forwarder=10.100.32.31 -U
replica-info-vuwunicoipam004.ods.vuw.ac.nz.gpg --skip-conncheck
Why are you skipping a connection check?
The check will find issues like this ahead of time.
I suspect there is something wrong with either DNS entries for LDAP server
records or LDAP or Kerberos port is not open between new replica and master.
At least I would try with connection check on and see if it gives some hints.
Checking forwarders, please wait ...
WARNING: DNS forwarder 10.100.32.31 does not return DNSSEC signatures in answers
Please fix forwarder configuration to enable DNSSEC support.
(For BIND 9 add directive dnssec-enable yes; to options {})
WARNING: DNSSEC validation will be disabled
Directory Manager (existing master) password:
Adding [10.100.32.50 vuwunicoipam004.ods.vuw.ac.nz] to your /etc/hosts file
Using reverse zone(s) 32.100.10.in-addr.arpa.
Configuring NTP daemon (ntpd)
[1/4]: stopping ntpd
[2/4]: writing configuration
[3/4]: configuring ntpd to start on boot
[4/4]: starting ntpd
Done configuring NTP daemon (ntpd).
Configuring directory server (dirsrv): Estimated time 1 minute
[1/35]: creating directory server user
[2/35]: creating directory server instance
[3/35]: adding default schema
[4/35]: enabling memberof plugin
[5/35]: enabling winsync plugin
[6/35]: configuring replication version plugin
[7/35]: enabling IPA enrollment plugin
[8/35]: enabling ldapi
[9/35]: configuring uniqueness plugin
[10/35]: configuring uuid plugin
[11/35]: configuring modrdn plugin
[12/35]: configuring DNS plugin
[13/35]: enabling entryUSN plugin
[14/35]: configuring lockout plugin
[15/35]: creating indices
[16/35]: enabling referential integrity plugin
[17/35]: configuring ssl for ds instance
[18/35]: configuring certmap.conf
[19/35]: configure autobind for root
[20/35]: configure new location for managed entries
[21/35]: configure dirsrv ccache
[22/35]: enable SASL mapping fallback
[23/35]: restarting directory server
[24/35]: setting up initial replication
Starting replication, please wait until this has completed.
Update in progress, 128 seconds elapsed
[vuwunicoipam002.ods.vuw.ac.nz] reports: Update failed! Status: [10 Total
update abortedLDAP error: Referral]
[error] RuntimeError: Failed to start replication
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.
Failed to start replication
[root@vuwunicoipam004mailto:root@vuwunicoipam004 ipa-certs]#
No firewalls are active and the network is a simple vyos virtual router.
=
[root@vuwunicoipam002mailto:root@vuwunicoipam002 etc]# iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
[root@vuwunicoipam002mailto:root@vuwunicoipam002 etc]#
=
=
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
[root@vuwunicoipam004mailto:root@vuwunicoipam004 ipa-certs]#
=
regards
Steven
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Error in replication while inserting a RHEL7.1 server into a RHEL6.6 IPA setup.
==
2015-03-09T21:15:31Z DEBUG flushing ldap://vuwunicoipam002.ods.vuw.ac.nz:389
from SchemaCache
2015-03-09T21:15:31Z DEBUG retrieving schema for SchemaCache
url=ldap://vuwunicoipam002.ods.vuw.ac.nz:389
conn=ldap.ldapobject.SimpleLDAPObject instance at 0x4226cb0
2015-03-09T21:15:31Z DEBUG flushing ldaps://vuwunicoipam004.ods.vuw.ac.nz:636
from SchemaCache
2015-03-09T21:15:31Z DEBUG retrieving schema for SchemaCache
url=ldaps://vuwunicoipam004.ods.vuw.ac.nz:636
conn=ldap.ldapobject.SimpleLDAPObject instance at 0x3d3d368
2015-03-09T21:17:42Z DEBUG Traceback (most recent call last):
File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line
382, in start_creation
run_step(full_msg, method)
File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line
372, in run_step
method()
File /usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py, line
368, in __setup_replica
r_bindpw=self.dm_password)
File /usr/lib/python2.7/site-packages/ipaserver/install/replication.py,
line 969, in setup_replication
raise RuntimeError(Failed to start replication)
RuntimeError: Failed to start replication
2015-03-09T21:17:42Z DEBUG [error] RuntimeError: Failed to start replication
2015-03-09T21:17:42Z DEBUG File
/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py, line 646,
in run_script
return_value = main_function()
File /sbin/ipa-replica-install, line 700, in main
ds = install_replica_ds(config)
File /sbin/ipa-replica-install, line 195, in install_replica_ds
ca_file=config.dir + /ca.crt,
File /usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py, line
355, in create_replica
self.start_creation(runtime=60)
File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line
382, in start_creation
run_step(full_msg, method)
File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line
372, in run_step
method()
File /usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py, line
368, in __setup_replica
r_bindpw=self.dm_password)
File /usr/lib/python2.7/site-packages/ipaserver/install/replication.py,
line 969, in setup_replication
raise RuntimeError(Failed to start replication)
2015-03-09T21:17:42Z DEBUG The ipa-replica-install command failed, exception:
RuntimeError: Failed to start replication
==
replica log.
?
regards
Steven
From: freeipa-users-boun...@redhat.com freeipa-users-boun...@redhat.com on
behalf of Rich Megginson rmegg...@redhat.com
Sent: Tuesday, 10 March 2015 11:02 a.m.
To: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Error in replication while inserting a RHEL7.1
server into a RHEL6.6 IPA setup.
On 03/09/2015 03:35 PM, Steven Jones wrote:
Any idea what is going on here please?
==
[root@vuwunicoipam004mailto:root@vuwunicoipam004 ipa-certs]#
ipa-replica-install --setup-dns --forwarder=10.100.32.31 -U
replica-info-vuwunicoipam004.ods.vuw.ac.nz.gpg --skip-conncheck
Checking forwarders, please wait ...
WARNING: DNS forwarder 10.100.32.31 does not return DNSSEC signatures in answers
Please fix forwarder configuration to enable DNSSEC support.
(For BIND 9 add directive dnssec-enable yes; to options {})
WARNING: DNSSEC validation will be disabled
I don't know if this is a problem, so I will leave it to our DNS gurus to
answer.
Directory Manager (existing master) password:
Adding [10.100.32.50 vuwunicoipam004.ods.vuw.ac.nz] to your /etc/hosts file
Using reverse zone(s) 32.100.10.in-addr.arpa.
Configuring NTP daemon (ntpd)
[1/4]: stopping ntpd
[2/4]: writing configuration
[3/4]: configuring ntpd to start on boot
[4/4]: starting ntpd
Done configuring NTP daemon (ntpd).
Configuring directory server (dirsrv): Estimated time 1 minute
[1/35]: creating directory server user
[2/35]: creating directory server instance
[3/35]: adding default schema
[4/35]: enabling memberof plugin
[5/35]: enabling winsync plugin
[6/35]: configuring replication version plugin
[7/35]: enabling IPA enrollment plugin
[8/35]: enabling ldapi
[9/35]: configuring uniqueness plugin
[10/35]: configuring uuid plugin
[11/35]: configuring modrdn plugin
[12/35]: configuring DNS plugin
[13/35]: enabling entryUSN plugin
[14/35]: configuring lockout plugin
[15/35]: creating indices
[16/35]: enabling referential integrity plugin
[17/35]: configuring ssl for ds instance
[18/35]: configuring certmap.conf
[19/35]: configure autobind for root
[20/35]: configure new location for managed entries
[21/35]: configure dirsrv ccache
[22/35]: enable SASL mapping fallback
[23/35]: restarting directory server
[24/35]: setting up initial replication
Starting replication, please wait until this has completed.
Update in progress, 128 seconds elapsed
[vuwunicoipam002.ods.vuw.ac.nz] reports: Update failed! Status: [10 Total
update abortedLDAP error: Referral]
If the
Re: [Freeipa-users] Error in replication while inserting a RHEL7.1 server into a RHEL6.6 IPA setup.
=
Check connection from replica to remote master 'vuwunicoipam002.ods.vuw.ac.nz':
Directory Service: Unsecure port (389): OK
Directory Service: Secure port (636): OK
Kerberos KDC: TCP (88): OK
Kerberos Kpasswd: TCP (464): OK
HTTP Server: Unsecure port (80): OK
HTTP Server: Secure port (443): OK
The following list of ports use UDP protocol and would need to be
checked manually:
Kerberos KDC: UDP (88): SKIPPED
Kerberos Kpasswd: UDP (464): SKIPPED
Connection from replica to master is OK.
Start listening on required ports for remote master check
Get credentials to log in to remote master
ad...@ods.vuw.ac.nzmailto:ad...@ods.vuw.ac.nz password:
Check SSH connection to remote master
Execute check on remote master
Check connection from master to remote replica 'vuwunicoipam004.ods.vuw.ac.nz':
Directory Service: Unsecure port (389): OK
Directory Service: Secure port (636): OK
Kerberos KDC: TCP (88): OK
Kerberos KDC: UDP (88): OK
Kerberos Kpasswd: TCP (464): OK
Kerberos Kpasswd: UDP (464): OK
HTTP Server: Unsecure port (80): OK
HTTP Server: Secure port (443): OK
Connection from master to replica is OK.
ipa : DEBUGProcess finished, return code=0
Connection check OK
==
regards
Steven
From: freeipa-users-boun...@redhat.com freeipa-users-boun...@redhat.com on
behalf of Steven Jones steven.jo...@vuw.ac.nz
Sent: Tuesday, 10 March 2015 1:36 p.m.
To: freeipa-users@redhat.com; d...@redhat.com
Subject: Re: [Freeipa-users] Error in replication while inserting a RHEL7.1
server into a RHEL6.6 IPA setup.
It usually fails, hence I skip it.
Since I have no firewall either side and I know I have a simple network since I
built there is nothing possible blocking in-between.
I will double check the DNS zone file.
I had to rename the server to ipam004 as the replica attempt sulked if i
re-used an old hostname, ipam001.
regards
Steven
From: freeipa-users-boun...@redhat.com freeipa-users-boun...@redhat.com on
behalf of Dmitri Pal d...@redhat.com
Sent: Tuesday, 10 March 2015 1:22 p.m.
To: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Error in replication while inserting a RHEL7.1
server into a RHEL6.6 IPA setup.
On 03/09/2015 05:35 PM, Steven Jones wrote:
Any idea what is going on here please?
==
[root@vuwunicoipam004mailto:root@vuwunicoipam004 ipa-certs]#
ipa-replica-install --setup-dns --forwarder=10.100.32.31 -U
replica-info-vuwunicoipam004.ods.vuw.ac.nz.gpg --skip-conncheck
Why are you skipping a connection check?
The check will find issues like this ahead of time.
I suspect there is something wrong with either DNS entries for LDAP server
records or LDAP or Kerberos port is not open between new replica and master.
At least I would try with connection check on and see if it gives some hints.
Checking forwarders, please wait ...
WARNING: DNS forwarder 10.100.32.31 does not return DNSSEC signatures in answers
Please fix forwarder configuration to enable DNSSEC support.
(For BIND 9 add directive dnssec-enable yes; to options {})
WARNING: DNSSEC validation will be disabled
Directory Manager (existing master) password:
Adding [10.100.32.50 vuwunicoipam004.ods.vuw.ac.nz] to your /etc/hosts file
Using reverse zone(s) 32.100.10.in-addr.arpa.
Configuring NTP daemon (ntpd)
[1/4]: stopping ntpd
[2/4]: writing configuration
[3/4]: configuring ntpd to start on boot
[4/4]: starting ntpd
Done configuring NTP daemon (ntpd).
Configuring directory server (dirsrv): Estimated time 1 minute
[1/35]: creating directory server user
[2/35]: creating directory server instance
[3/35]: adding default schema
[4/35]: enabling memberof plugin
[5/35]: enabling winsync plugin
[6/35]: configuring replication version plugin
[7/35]: enabling IPA enrollment plugin
[8/35]: enabling ldapi
[9/35]: configuring uniqueness plugin
[10/35]: configuring uuid plugin
[11/35]: configuring modrdn plugin
[12/35]: configuring DNS plugin
[13/35]: enabling entryUSN plugin
[14/35]: configuring lockout plugin
[15/35]: creating indices
[16/35]: enabling referential integrity plugin
[17/35]: configuring ssl for ds instance
[18/35]: configuring certmap.conf
[19/35]: configure autobind for root
[20/35]: configure new location for managed entries
[21/35]: configure dirsrv ccache
[22/35]: enable SASL mapping fallback
[23/35]: restarting directory server
[24/35]: setting up initial replication
Starting replication, please wait until this has completed.
Update in progress, 128 seconds elapsed
[vuwunicoipam002.ods.vuw.ac.nz] reports: Update failed! Status: [10 Total
update abortedLDAP error: Referral]
[error] RuntimeError: Failed to start replication
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.
Failed to start replication
[root@vuwunicoipam004mailto:root@vuwunicoipam004 ipa-certs]#
Re: [Freeipa-users] IPA web ui always giving Your session has expired. Please re-login.
Thanks for all the data. So it looks like your browser properly forward the session cookie, but it is not recognized on the server even though it was stored before. Especially these lines are strange: [Sun Mar 08 13:16:29.909637 2015] [:error] [pid 3004] ipa: DEBUG: store session: session_id=4803e184cecb42f2e326391dbb09443d start_timestamp=2015-03-08T13:15:12 access_timestamp=2015-03-08T13:16:29 expiration_timestamp=2015-03-08T13:36:29 ... [Sun Mar 08 13:16:29.921519 2015] [:error] [pid 3003] ipa: DEBUG: found session cookie_id = 4803e184cecb42f2e326391dbb09443d [Sun Mar 08 13:16:29.921731 2015] [:error] [pid 3003] ipa: DEBUG: no session data in cache with id=4803e184cecb42f2e326391dbb09443d, generating empty session data We know that ipa_memcached is running. Can you please also check if there are no SELinux errors in /var/log/audit/audit.log preveting Apache from looking up the session data? Thanks, Martin On 03/08/2015 11:44 AM, Ben .T.George wrote: i was inspecting the page and got below response. http://s21.postimg.org/itv5hf0h3/asdasd.jpg http://s3.postimg.org/f6knomt1f/Capture.jpg please anyone help me to solve this issue. i just want to create one local user in IPA On Sun, Mar 8, 2015 at 1:17 PM, Ben .T.George bentech4...@gmail.com wrote: I enabled debugging mode on default.conf and this is what i am getting on error_log [Sun Mar 08 13:16:18.204363 2015] [auth_kerb:error] [pid 3065] [client 172.16.107.250:60088] gss_accept_sec_context() failed: An unsupported mechanism was requested (, Unknown error), referer: https://kwtpocpbis01.solaris.local/ipa/ui/ [Sun Mar 08 13:16:29.849339 2015] [:error] [pid 3004] ipa: DEBUG: WSGI wsgi_dispatch.__call__: [Sun Mar 08 13:16:29.849458 2015] [:error] [pid 3004] ipa: DEBUG: WSGI login_password.__call__: [Sun Mar 08 13:16:29.849683 2015] [:error] [pid 3004] ipa: DEBUG: Obtaining armor ccache: principal=HTTP/kwtpocpbis01.solaris.local@SOLARIS.LOCAL keytab=/etc/httpd/conf/ipa.keytab ccache=/var/run/ipa_memcached/krbcc_A_admin [Sun Mar 08 13:16:29.849830 2015] [:error] [pid 3004] ipa: DEBUG: Starting external process [Sun Mar 08 13:16:29.849923 2015] [:error] [pid 3004] ipa: DEBUG: args='/usr/bin/kinit' '-kt' '/etc/httpd/conf/ipa.keytab' 'HTTP/kwtpocpbis01.solaris.local@SOLARIS.LOCAL' [Sun Mar 08 13:16:29.868747 2015] [:error] [pid 3004] ipa: DEBUG: Process finished, return code=0 [Sun Mar 08 13:16:29.868858 2015] [:error] [pid 3004] ipa: DEBUG: stdout= [Sun Mar 08 13:16:29.868955 2015] [:error] [pid 3004] ipa: DEBUG: stderr= [Sun Mar 08 13:16:29.869120 2015] [:error] [pid 3004] ipa: DEBUG: Starting external process [Sun Mar 08 13:16:29.869204 2015] [:error] [pid 3004] ipa: DEBUG: args='/usr/bin/kinit' 'admin@SOLARIS.LOCAL' '-T' '/var/run/ipa_memcached/krbcc_A_admin' [Sun Mar 08 13:16:29.902181 2015] [:error] [pid 3004] ipa: DEBUG: Process finished, return code=0 [Sun Mar 08 13:16:29.902269 2015] [:error] [pid 3004] ipa: DEBUG: stdout=Password for admin@SOLARIS.LOCAL: [Sun Mar 08 13:16:29.902278 2015] [:error] [pid 3004] [Sun Mar 08 13:16:29.902328 2015] [:error] [pid 3004] ipa: DEBUG: stderr= [Sun Mar 08 13:16:29.902427 2015] [:error] [pid 3004] ipa: DEBUG: kinit: principal=admin@SOLARIS.LOCAL returncode=0, stderr= [Sun Mar 08 13:16:29.902483 2015] [:error] [pid 3004] ipa: DEBUG: Cleanup the armor ccache [Sun Mar 08 13:16:29.902560 2015] [:error] [pid 3004] ipa: DEBUG: Starting external process [Sun Mar 08 13:16:29.902621 2015] [:error] [pid 3004] ipa: DEBUG: args='/usr/bin/kdestroy' '-A' '-c' '/var/run/ipa_memcached/krbcc_A_admin' [Sun Mar 08 13:16:29.908045 2015] [:error] [pid 3004] ipa: DEBUG: Process finished, return code=0 [Sun Mar 08 13:16:29.908121 2015] [:error] [pid 3004] ipa: DEBUG: stdout= [Sun Mar 08 13:16:29.908173 2015] [:error] [pid 3004] ipa: DEBUG: stderr= [Sun Mar 08 13:16:29.908348 2015] [:error] [pid 3004] ipa: DEBUG: found session cookie_id = 4803e184cecb42f2e326391dbb09443d [Sun Mar 08 13:16:29.908647 2015] [:error] [pid 3004] ipa: DEBUG: found session data in cache with id=4803e184cecb42f2e326391dbb09443d [Sun Mar 08 13:16:29.908728 2015] [:error] [pid 3004] ipa: DEBUG: finalize_kerberos_acquisition: login_password ccache_name=FILE:/var/run/ipa_memcached/krbcc_3004 session_id=4803e184cecb42f2e326391dbb09443d [Sun Mar 08 13:16:29.908824 2015] [:error] [pid 3004] ipa: DEBUG: reading ccache data from file /var/run/ipa_memcached/krbcc_3004 [Sun Mar 08 13:16:29.909319 2015] [:error] [pid 3004] ipa: DEBUG: get_credential_times: principal=krbtgt/SOLARIS.LOCAL@SOLARIS.LOCAL, authtime=03/08/15 13:16:29, starttime=03/08/15 13:16:29, endtime=03/09/15 13:16:29, renew_till=01/01/70 03:00:00 [Sun Mar 08 13:16:29.909415 2015] [:error] [pid 3004] ipa: DEBUG: KRB5_CCache FILE:/var/run/ipa_memcached/krbcc_3004 endtime=1425896189 (03/09/15 13:16:29) [Sun Mar 08 13:16:29.909538 2015] [:error] [pid 3004] ipa: DEBUG: set_session_expiration_time:
Re: [Freeipa-users] IPA web ui always giving Your session has expired. Please re-login.
Hi Martin, thanks for your replay. yesterday i did lot of this to fix this issue. the issue has been solved by kdestroy and re-initiate the ticket. after that restarted ipa service, it got worked Regards, ben On Mon, Mar 9, 2015 at 10:57 AM, Martin Kosek mko...@redhat.com wrote: Thanks for all the data. So it looks like your browser properly forward the session cookie, but it is not recognized on the server even though it was stored before. Especially these lines are strange: [Sun Mar 08 13:16:29.909637 2015] [:error] [pid 3004] ipa: DEBUG: store session: session_id=4803e184cecb42f2e326391dbb09443d start_timestamp=2015-03-08T13:15:12 access_timestamp=2015-03-08T13:16:29 expiration_timestamp=2015-03-08T13:36:29 ... [Sun Mar 08 13:16:29.921519 2015] [:error] [pid 3003] ipa: DEBUG: found session cookie_id = 4803e184cecb42f2e326391dbb09443d [Sun Mar 08 13:16:29.921731 2015] [:error] [pid 3003] ipa: DEBUG: no session data in cache with id=4803e184cecb42f2e326391dbb09443d, generating empty session data We know that ipa_memcached is running. Can you please also check if there are no SELinux errors in /var/log/audit/audit.log preveting Apache from looking up the session data? Thanks, Martin On 03/08/2015 11:44 AM, Ben .T.George wrote: i was inspecting the page and got below response. http://s21.postimg.org/itv5hf0h3/asdasd.jpg http://s3.postimg.org/f6knomt1f/Capture.jpg please anyone help me to solve this issue. i just want to create one local user in IPA On Sun, Mar 8, 2015 at 1:17 PM, Ben .T.George bentech4...@gmail.com wrote: I enabled debugging mode on default.conf and this is what i am getting on error_log [Sun Mar 08 13:16:18.204363 2015] [auth_kerb:error] [pid 3065] [client 172.16.107.250:60088] gss_accept_sec_context() failed: An unsupported mechanism was requested (, Unknown error), referer: https://kwtpocpbis01.solaris.local/ipa/ui/ [Sun Mar 08 13:16:29.849339 2015] [:error] [pid 3004] ipa: DEBUG: WSGI wsgi_dispatch.__call__: [Sun Mar 08 13:16:29.849458 2015] [:error] [pid 3004] ipa: DEBUG: WSGI login_password.__call__: [Sun Mar 08 13:16:29.849683 2015] [:error] [pid 3004] ipa: DEBUG: Obtaining armor ccache: principal=HTTP/kwtpocpbis01.solaris.local@SOLARIS.LOCAL keytab=/etc/httpd/conf/ipa.keytab ccache=/var/run/ipa_memcached/krbcc_A_admin [Sun Mar 08 13:16:29.849830 2015] [:error] [pid 3004] ipa: DEBUG: Starting external process [Sun Mar 08 13:16:29.849923 2015] [:error] [pid 3004] ipa: DEBUG: args='/usr/bin/kinit' '-kt' '/etc/httpd/conf/ipa.keytab' 'HTTP/kwtpocpbis01.solaris.local@SOLARIS.LOCAL' [Sun Mar 08 13:16:29.868747 2015] [:error] [pid 3004] ipa: DEBUG: Process finished, return code=0 [Sun Mar 08 13:16:29.868858 2015] [:error] [pid 3004] ipa: DEBUG: stdout= [Sun Mar 08 13:16:29.868955 2015] [:error] [pid 3004] ipa: DEBUG: stderr= [Sun Mar 08 13:16:29.869120 2015] [:error] [pid 3004] ipa: DEBUG: Starting external process [Sun Mar 08 13:16:29.869204 2015] [:error] [pid 3004] ipa: DEBUG: args='/usr/bin/kinit' 'admin@SOLARIS.LOCAL' '-T' '/var/run/ipa_memcached/krbcc_A_admin' [Sun Mar 08 13:16:29.902181 2015] [:error] [pid 3004] ipa: DEBUG: Process finished, return code=0 [Sun Mar 08 13:16:29.902269 2015] [:error] [pid 3004] ipa: DEBUG: stdout=Password for admin@SOLARIS.LOCAL: [Sun Mar 08 13:16:29.902278 2015] [:error] [pid 3004] [Sun Mar 08 13:16:29.902328 2015] [:error] [pid 3004] ipa: DEBUG: stderr= [Sun Mar 08 13:16:29.902427 2015] [:error] [pid 3004] ipa: DEBUG: kinit: principal=admin@SOLARIS.LOCAL returncode=0, stderr= [Sun Mar 08 13:16:29.902483 2015] [:error] [pid 3004] ipa: DEBUG: Cleanup the armor ccache [Sun Mar 08 13:16:29.902560 2015] [:error] [pid 3004] ipa: DEBUG: Starting external process [Sun Mar 08 13:16:29.902621 2015] [:error] [pid 3004] ipa: DEBUG: args='/usr/bin/kdestroy' '-A' '-c' '/var/run/ipa_memcached/krbcc_A_admin' [Sun Mar 08 13:16:29.908045 2015] [:error] [pid 3004] ipa: DEBUG: Process finished, return code=0 [Sun Mar 08 13:16:29.908121 2015] [:error] [pid 3004] ipa: DEBUG: stdout= [Sun Mar 08 13:16:29.908173 2015] [:error] [pid 3004] ipa: DEBUG: stderr= [Sun Mar 08 13:16:29.908348 2015] [:error] [pid 3004] ipa: DEBUG: found session cookie_id = 4803e184cecb42f2e326391dbb09443d [Sun Mar 08 13:16:29.908647 2015] [:error] [pid 3004] ipa: DEBUG: found session data in cache with id=4803e184cecb42f2e326391dbb09443d [Sun Mar 08 13:16:29.908728 2015] [:error] [pid 3004] ipa: DEBUG: finalize_kerberos_acquisition: login_password ccache_name=FILE:/var/run/ipa_memcached/krbcc_3004 session_id=4803e184cecb42f2e326391dbb09443d [Sun Mar 08 13:16:29.908824 2015] [:error] [pid 3004] ipa: DEBUG: reading ccache data from file /var/run/ipa_memcached/krbcc_3004 [Sun Mar 08 13:16:29.909319 2015] [:error] [pid 3004] ipa: DEBUG: get_credential_times: principal=krbtgt/SOLARIS.LOCAL@SOLARIS.LOCAL,
