Re: [Freeipa-users] replication again :-(
On 05/21/2015 06:09 PM, Janelle wrote:
On 5/21/15 8:12 AM, Ludwig Krispenz wrote:
On 05/21/2015 03:59 PM, Janelle wrote:
On 5/21/15 6:46 AM, Ludwig Krispenz wrote:
On 05/21/2015 03:28 PM, Janelle wrote:
I think I found the problem.
There was a lone replica running in another DC. It was installed
as a replica some time ago with all the others. Think of this --
the original config had 5 servers, one of them was this server.
Then the other 4 servers were RE-BUILT from scratch, so all the
replication agreements were changed AND - this is the important
part - the 5th server was never added back in. BUT - the 5th
server was left running and never told it that it was not a member
anymore. It still thought it had a replication agreement with
original server 1, but server 1 knew otherwise.
Now, although the first 4 servers were rebuilt, the same domain,
realm, AND passwords were used.
I am guessing that somehow, this 5th server keeps trying to
interject its info into the ring of 4 servers, kind of forcing its
way in. Somehow, because the original credentials still work (but
certs are all different) is leaving the first 4 servers with a
can't decode issue.
There should be some security checks so this can't happen. It
should also be easy to replicate.
Now I have to go re-initialize all the servers from a good server,
so everyone is happy again. The problem server has been shutdown
completely. (and yes, there were actually 3 of them in my scenario
- I just used 1 to simplify my example - but that explains the 3
CSNs that just kept appearing)
What concerns me most about this - were the servers outside of the
good ring somehow able to inject data into replication which
might have been causing bad data??? This is bad if it is true.
it depends a bit on what you mean by rebuilt from scratch.
A replication session needs to meet three conditions to be able to
send data:
- the supplier side needs to be able to authenticate and the
authenticated users has to be in the list of binddns of the replica
- the data generation of supplier and consumer side need to be the
same (they all have to have the same common origin)
- the supplier needs to have the changes (CSNs) to be able to
position in its changelog to send updates
now if you have 5 servers, forget about one of them and do not
change the credentials in the others and do not reinitialize the
database by an ldif import to generate a new database generation,
the fifth server will still be able to connect and eventually send
updates - how should the other servers know that this one is no
longer a good one
~Janelle
The only problem left now - is no matter what, this last entry will
NOT go away and now I have 2 stuck cleanruvs that will not abort
either.
unable to decode {replica 24} 554d53d30018
554d54a400020018
CLEANALLRUV tasks
RID 24 None
No abort CLEANALLRUV tasks running
=
ldapmodify -D cn=directory manager -W -a
dn: cn=abort 24, cn=abort cleanallruv, cn=tasks, cn=config
objectclass: extensibleObject
replica-base-dn: dc=example,dc=com
cn: abort 24
replica-id: 24
replica-certify-all: no
adding new entry cn=abort 24, cn=abort cleanallruv, cn=tasks,
cn=config
ldap_add: No such object (32)
in your dse.ldif do you see something like:
nsds5ReplicaCleanRUV: 300::no
in the replica object ?
This is where the task lives as long as it couldn't reach all servers
for which a replication agreement exists.
If abort task doesn't work, you could try to stop the server, remove
these lines from the dse.ldif, start the server again
Sadly, nothing even close to that anywhere. And now, after trying to
remove another replica which had been showing as a duplicate, although
authentication is continuing to work, I am afraid to try and do
anything else to replication, for fear of bringing all of production
down.
I did not notice this at first - but yesterday when I shared my RUVs
-- there was something I missed:
dc1-ipa1.example.com 389 10
dc1-ipa2.example.com 389 25
dc1-ipa2.example.com 389 9
dc1-ipa3.example.com 389 8
dc1-ipa4.example.com 389 4
ipa2 appears twice with RUV 9 and 25 - with no explanation.
Frustrated.
~Janelle
Hi Janelle,
Yes I mentioned that duplicate yesterday. That means the node
dc1-ipa2.example.com is a master and use to be known with RID 9 and now
is known as RID 25 (or the opposite)
Did you reinstall that node ? The purpose of CleanAllRuv is to clear the
old value from the RUV.
Editing dc1-ipa2.example.com dse.ldif you can confirm the current value
and choose which one need to be cleared.
When you have duplicated RID you may see logs with
'attrlist_replace:... in the error logs
Thanks
thierry
--
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] User Can't Authenticate
On (21/05/15 18:56), Dmitri Pal wrote: On 05/21/2015 05:54 PM, John Williams wrote: I've got a freeIPA client where a user account cannot authenticate. The log entry for IPA looks like: audit/audit.log.4:type=USER_AUTH msg=audit(1425316592.375:38090): user pid=16485 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=PAM:authentication acct=aswanda exe=/usr/sbin/sshd hostname=172.31.0.162 addr=172.31.0.162 terminal=ssh res=failed' When I try to sudo to the user account, I get the following error: [root@myhost ~]# sudo su - testuser su: user testuser does not exist However, all that works for my account. Please help. Thanks in advance. What do you use on the client? SSSD? What is the OS version? What SSSD logs show? For sssd related issues see https://fedorahosted.org/sssd/wiki/Troubleshooting Firstly, ensure you can get user information (getent passwd user) Secondly, troubleshoot authentication and access control. LS -- 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] [[Test-Announce] Fedora 22 Final status is Go, release on May 26, 2015]
Hi Alexander Great news, does this also mean that user created in freeipa are self created/synchronized in the windows ad ? Regtards 2015-05-22 15:00 GMT-04:00 Alexander Bokovoy aboko...@redhat.com: Hi, As per attached message, Fedora 22 final release will come to life next week. If you are planning to use FreeIPA in Fedora 22 or upgrade your FreeIPA deployment to Fedora 22, make sure updates-testing repository is enabled. Several last moment bug fixes related to FreeIPA were not rolled into the final Fedora 22 image and they are waiting in updats-testing for the gates to be open after release. One particular area is support for cross-forest trusts with Active Directory --- Samba in Fedora 22 got upgraded to 4.2.1 version which caused some changes in underlying libraries FreeIPA uses for supporting the cross-forest trust. The fixes are awaiting you after install in the updats-testing. Happy Fedora 22 use! -- / Alexander Bokovoy -- Mensaje reenviado -- From: Jaroslav Reznik jrez...@redhat.com To: devel-annou...@lists.fedoraproject.org, test-announce test-annou...@lists.fedoraproject.org, Fedora Logistics List logist...@lists.fedoraproject.org Cc: Date: Fri, 22 May 2015 14:46:39 -0400 (EDT) Subject: [Test-Announce] Fedora 22 Final status is Go, release on May 26, 2015 At the Fedora 22 Final Go/No-Go Meeting #2 that just occurred, it was agreed to Go with the Fedora 22 Final by Fedora QA, Release Engineering and Development. Fedora 22 Final will be publicly available on Tuesday, May 26, 2015. Meeting details can be seen here: Minutes: http://bit.ly/1Bh2pH1 Log: http://bit.ly/1HzMI5g Thank you everyone for a great job, sleepless nights validating TCs, RCs, fixing bugs, composing stuf and everything else needed for smooth releases. Amazing last three years wrangling releases for me! Jaroslav ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] [[Test-Announce] Fedora 22 Final status is Go, release on May 26, 2015]
Carlos Raúl Laguna wrote: Just for clarification, If i create a user in Windows 2008R2 it propagates to Freeipa 4.1 because freeIPA trust the AD domain, in this scenario where AD equally trust the freeIPA domain (Fedora 22), a user created in freeIPA should not propagate as well to AD ? Regards Users are not copied, you can reference an AD user from IPA. So you can log into an IPA-managed machine using your AD credentials. This does not add the AD user to IPA. Right now you can't reference IPA users in AD resources, in any version of IPA. So no logging into Windows using your IPA credentials (yet). rob 2015-05-22 16:39 GMT-04:00 Alexander Bokovoy aboko...@redhat.com mailto:aboko...@redhat.com: On Fri, 22 May 2015, Carlos Raúl Laguna wrote: Hi Alexander Great news, does this also mean that user created in freeipa are self created/synchronized in the windows ad ? Regtards With cross-forest trust we don't synchronize anything to AD. Think about it as if FreeIPA was a separate AD forest, two AD forests don't synchronize anything to each other, they _refer_ to each other's domain controllers for operations that require authentication or other changes. -- / 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] [[Test-Announce] Fedora 22 Final status is Go, release on May 26, 2015]
Just for clarification, If i create a user in Windows 2008R2 it propagates to Freeipa 4.1 because freeIPA trust the AD domain, in this scenario where AD equally trust the freeIPA domain (Fedora 22), a user created in freeIPA should not propagate as well to AD ? Regards 2015-05-22 16:39 GMT-04:00 Alexander Bokovoy aboko...@redhat.com: On Fri, 22 May 2015, Carlos Raúl Laguna wrote: Hi Alexander Great news, does this also mean that user created in freeipa are self created/synchronized in the windows ad ? Regtards With cross-forest trust we don't synchronize anything to AD. Think about it as if FreeIPA was a separate AD forest, two AD forests don't synchronize anything to each other, they _refer_ to each other's domain controllers for operations that require authentication or other changes. -- / 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] ubuntu dns discovery
On Fri, May 22, 2015 at 3:14 PM, Martin Basti mba...@redhat.com wrote:
On 22/05/15 18:05, Johnny Tan wrote:
Our servers run CentOS-6.6 and ipa-server-3.0.0-42.el6.centos.x86_64
Our CentOS clients (also 6.6) join the domain seamlessly.
Our Ubuntu 14.04 LTS clients, however, don't seem to be able to
auto-discover domain, realm, or IPA servers:
```
dpkg -l | grep freeipa
ii freeipa-client 3.3.4-0ubuntu3.1
amd64FreeIPA centralized identity framework -- client
/usr/sbin/ipa-client-install --mkhomedir --no-ntp --no-sudo --unattended
--hostname testing-ubuntu001.pp --principal admin --password xx --debug
/usr/sbin/ipa-client-install was invoked with options: {'domain': None,
'force': False, 'krb5_offline_passwords': True, 'primary': False,
'realm_name': None, 'force_ntpd': False, 'create_sshfp': True, 'conf_sshd':
True, 'conf_ntp': False, 'on_master': False, 'ntp_server': None,
'ca_cert_file': None, 'principal': 'admin', 'keytab': None, 'hostname':
'testing-ubuntu001.pp', 'no_ac': False, 'unattended': True, 'sssd': True,
'trust_sshfp': False, 'dns_updates': False, 'mkhomedir': True, 'conf_ssh':
True, 'force_join': False, 'server': None, 'prompt_password': False,
'permit': False, 'debug': True, 'preserve_sssd': False, 'uninstall': False}
missing options might be asked for interactively later
Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index'
Loading StateFile from '/var/lib/ipa-client/sysrestore/sysrestore.state'
[IPA Discovery]
Starting IPA discovery with domain=None, servers=None,
hostname=testing-ubuntu001.pp
Start searching for LDAP SRV record in pp (domain of the hostname) and
its sub-domains
Search DNS for SRV record of _ldap._tcp.pp
DNS record not found: EmptyLabel
Start searching for LDAP SRV record in .pp (search domain from
/etc/resolv.conf) and its sub-domains
Search DNS for SRV record of _ldap._tcp..pp
DNS record not found: EmptyLabel
Already searched pp; skipping
No LDAP server found
No LDAP server found
Unable to discover domain, not provided on command line
Installation failed. Rolling back changes.
IPA client is not configured on this system.
```
Yet on the same client:
```
root@testing-ubuntu001:~# dig srv _ldap._tcp.pp +short
0 100 389 production-ipa003.pp.
0 100 389 production-ipa001.pp.
0 100 389 production-ipa002.pp.
```
Why can't ipa-client-install discover those SRV records?
johnny
Hello,
this is weird, DNS record not found: EmptyLabel, this error returns
python-dns when empty label is used in domain name.
And here is empty label - _ldap._tcp..pp (two dots).
But that doubled dot is not on line above and the error is the same,
interesting.
Aha! It seems our configuration management system is populating `search` in
/etc/resolv.conf with .pp rather than pp. If I manually change that, it
now works! Thank you.
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] [[Test-Announce] Fedora 22 Final status is Go, release on May 26, 2015]
On Fri, 22 May 2015, Carlos Raúl Laguna wrote: Hi Alexander Great news, does this also mean that user created in freeipa are self created/synchronized in the windows ad ? Regtards With cross-forest trust we don't synchronize anything to AD. Think about it as if FreeIPA was a separate AD forest, two AD forests don't synchronize anything to each other, they _refer_ to each other's domain controllers for operations that require authentication or other changes. -- / 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] Certificate operation cannot be completed: Unable to communicate with CMS (Not Found)
Dear Rob, The result is from ipa master server. Regards Sanju Abraham From: Rob Crittenden rcrit...@redhat.com To: Sanju A sanj...@tcs.com Cc: freeipa-users@redhat.com Date: 21-05-2015 19:03 Subject:Re: [Freeipa-users] Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) Sanju A wrote: Dear Rob, Please find the result of getcert list. Request ID '20140430124456': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=ipa.tcs-mobility.com,O=EXAMPLE.COM expires: 2016-04-30 12:44:55 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes You need to run getcert list on the IPA master running the CA that can't be contacted, not the host you're trying to delete. rob Regards Sanju Abraham From: Rob Crittenden rcrit...@redhat.com To: Sanju A sanj...@tcs.com, freeipa-users@redhat.com Date: 20-05-2015 19:04 Subject: Re: [Freeipa-users] Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) Sanju A wrote: Hi, I am getting the following error while removing a host. --- Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) --- This usually means that the CA is not serving requestss. It may be up and running but that doesn't mean the webapp is working. This is often due to expired CA subsystem certificates. Run getcert list to check. rob =-=-= Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] FreeIPA groups not shown on client
On Fri, May 22, 2015 at 09:37:04AM +0200, Nikola Kržalić wrote: I have a ubuntu system running IPA client. I am able to log in via ssh using IPA users, but I do not get any group memberships or sudo rules. Same configuration works on a different system (running CentOS). sssd domain log output shows that the groups are retrieved from server successfully: (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] (0x1000): Added group [admins] for user [nkrzalic] (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] (0x1000): Added group [ipausers] for user [nkrzalic] (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] (0x1000): Added group [editors] for user [nkrzalic] (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] (0x1000): Added group [trust admins] for user [nkrzalic] (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] (0x1000): Added group [devops_team] for user [nkrzalic] (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] (0x1000): Added group [dev_team] for user [nkrzalic] (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] (0x1000): Added group [sys_team] for user [nkrzalic] Is anything else in the logs? What server version are you running? I guess you might be hitting the derefernce bug that appeared after IPA tightened its ACIs; https://fedorahosted.org/sssd/ticket/2421 -- 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] Certificate operation cannot be completed: Unable to communicate with CMS (Not Found)
Dear Rob, Please find the entire result. - Number of certificates and requests being tracked: 8. Request ID '20140430124246': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB',pin='288949439135' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=MYDOMAINNAME.COM subject: CN=CA Audit,O=MYDOMAINNAME.COM expires: 2016-04-19 12:42:02 UTC key usage: digitalSignature,nonRepudiation pre-save command: post-save command: track: yes auto-renew: yes Request ID '20140430124247': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB',pin='288949439135' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=MYDOMAINNAME.COM subject: CN=OCSP Subsystem,O=MYDOMAINNAME.COM expires: 2016-04-19 12:42:01 UTC key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign eku: id-kp-OCSPSigning pre-save command: post-save command: track: yes auto-renew: yes Request ID '20140430124248': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB',pin='288949439135' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=MYDOMAINNAME.COM subject: CN=CA Subsystem,O=MYDOMAINNAME.COM expires: 2016-04-19 12:42:01 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '20140430124249': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=MYDOMAINNAME.COM subject: CN=IPA RA,O=MYDOMAINNAME.COM expires: 2016-04-19 12:42:45 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '20140430124250': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB',pin='288949439135' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=MYDOMAINNAME.COM subject: CN=ipa.mydomainname.com,O=MYDOMAINNAME.COM expires: 2016-04-19 12:42:01 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '20140430124308': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-TCS-MOBILITY-COM',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-TCS-MOBILITY-COM/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-TCS-MOBILITY-COM',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=MYDOMAINNAME.COM subject: CN=ipa.mydomainname.com,O=MYDOMAINNAME.COM expires: 2016-04-30 12:43:07 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '20140430124352': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA/pwdfile.txt'
Re: [Freeipa-users] Certificate operation cannot be completed: Unable to communicate with CMS (Not Found)
Sanju A wrote: Dear Rob, Please find the entire result. Ok, the good news is that renewal already took place and it looks like everything is a-ok certificate-wise. First, make sure the CA is up: # ipactl status If the CA is down, start it with service pki-cad start. If the CA is up, the next thing to check are the trust flags: # certutil -L -d /var/lib/pki-ca/alias The auditSigningCert should be u,u,Pu If it isn't, fix it with: # certutil -M -t u,u,Pu -d /var/lib/pki-ca/alias -n 'auditSigningCert cert-pki-ca' You'll need to restart the CA after changing the trust: # service pki-cad restart If the trust is ok and the CA was already up we'd need to see your CA logs to try to determine what is going on. rob -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] FreeIPA groups not shown on client
On (22/05/15 09:37), Nikola Kržalić wrote: I have a ubuntu system running IPA client. I am able to log in via ssh using IPA users, but I do not get any group memberships or sudo rules. Same configuration works on a different system (running CentOS). sssd domain log output shows that the groups are retrieved from server successfully: (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] (0x1000): Added group [admins] for user [nkrzalic] (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] (0x1000): Added group [ipausers] for user [nkrzalic] (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] (0x1000): Added group [editors] for user [nkrzalic] (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] (0x1000): Added group [trust admins] for user [nkrzalic] (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] (0x1000): Added group [devops_team] for user [nkrzalic] (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] (0x1000): Added group [dev_team] for user [nkrzalic] (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] (0x1000): Added group [sys_team] for user [nkrzalic] However, these groups are not shown on the user upon login: nkrzalic@ircsrv1:~$ id uid=281200051(nkrzalic) gid=281200051(nkrzalic) groups=281200051(nkrzalic) I tried cleaning sssd cache but that didn't help. sssd conf is as follows: [sssd] services = nss, pam, ssh, sudo config_file_version = 2 nsswitch.conf seems to be correct as well: # /etc/nsswitch.conf passwd: compat sss group: compat sss shadow: compat hosts: files dns networks: files protocols: db files services: db files ethers: db files rpc:db files netgroup: nis sss sudoers:files sss Interestingly after I do getent group devops_team this group shows up: nkrzalic@ircsrv1:~$ id uid=281200051(nkrzalic) gid=281200051(nkrzalic) groups=281200051(nkrzalic),28121(devops_team) Missing groups on ubuntu (sssd-1.11) can be caused by bug https://fedorahosted.org/sssd/ticket/2471. This bug is fixed on CentOS. Workaround is to amend configuration of domain section. ldap_group_object_class = ipaUserGroup If it does not help then please follow instruction from wiki https://fedorahosted.org/sssd/wiki/Troubleshooting LS -- 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] Antwort: FreeIPA groups not shown on client
On (22/05/15 18:28), Christoph Kaminski wrote: freeipa-users-boun...@redhat.com schrieb am 22.05.2015 09:37:04: Von: Nikola Kržalić nik...@krzalic.com An: freeipa-users@redhat.com Datum: 22.05.2015 15:05 Betreff: [Freeipa-users] FreeIPA groups not shown on client Gesendet von: freeipa-users-boun...@redhat.com I have a ubuntu system running IPA client. I am able to log in via ssh using IPA users, but I do not get any group memberships or sudo rules. Same configuration works on a different system (running CentOS). sssd domain log output shows that the groups are retrieved from server successfully: (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] (0x1000): Added group [admins] for user [nkrzalic] (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] (0x1000): Added group [ipausers] for user [nkrzalic] (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] (0x1000): Added group [editors] for user [nkrzalic] (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] (0x1000): Added group [trust admins] for user [nkrzalic] (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] (0x1000): Added group [devops_team] for user [nkrzalic] (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] (0x1000): Added group [dev_team] for user [nkrzalic] (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] (0x1000): Added group [sys_team] for user [nkrzalic] However, these groups are not shown on the user upon login: nkrzalic@ircsrv1:~$ id uid=281200051(nkrzalic) gid=281200051(nkrzalic) groups=281200051(nkrzalic) I tried cleaning sssd cache but that didn't help. sssd conf is as follows: [sssd] services = nss, pam, ssh, sudo config_file_version = 2 nsswitch.conf seems to be correct as well: # /etc/nsswitch.conf passwd: compat sss group: compat sss shadow: compat hosts: files dns networks: files protocols: db files services: db files ethers: db files rpc:db files netgroup: nis sss sudoers:files sss Interestingly after I do getent group devops_team this group shows up: nkrzalic@ircsrv1:~$ id uid=281200051(nkrzalic) gid=281200051(nkrzalic) groups=281200051(nkrzalic),28121(devops_team) nkrzalic@ircsrv1:~$ Any ideas? try to kill the cache with: (stop sssd) rm -rf /var/lib/sss/db/* (start sssd) we has had the same problems often here and only really kill the cache has fixed it (sss_cache -A hasnt help) I'm sorry it is not a solution. If you still have a problem and you are able to reproduce it then please file a bug with log files. LS -- 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] ubuntu dns discovery
Our servers run CentOS-6.6 and ipa-server-3.0.0-42.el6.centos.x86_64
Our CentOS clients (also 6.6) join the domain seamlessly.
Our Ubuntu 14.04 LTS clients, however, don't seem to be able to
auto-discover domain, realm, or IPA servers:
```
dpkg -l | grep freeipa
ii freeipa-client 3.3.4-0ubuntu3.1
amd64FreeIPA centralized identity framework -- client
/usr/sbin/ipa-client-install --mkhomedir --no-ntp --no-sudo --unattended
--hostname testing-ubuntu001.pp --principal admin --password xx --debug
/usr/sbin/ipa-client-install was invoked with options: {'domain': None,
'force': False, 'krb5_offline_passwords': True, 'primary': False,
'realm_name': None, 'force_ntpd': False, 'create_sshfp': True, 'conf_sshd':
True, 'conf_ntp': False, 'on_master': False, 'ntp_server': None,
'ca_cert_file': None, 'principal': 'admin', 'keytab': None, 'hostname':
'testing-ubuntu001.pp', 'no_ac': False, 'unattended': True, 'sssd': True,
'trust_sshfp': False, 'dns_updates': False, 'mkhomedir': True, 'conf_ssh':
True, 'force_join': False, 'server': None, 'prompt_password': False,
'permit': False, 'debug': True, 'preserve_sssd': False, 'uninstall': False}
missing options might be asked for interactively later
Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index'
Loading StateFile from '/var/lib/ipa-client/sysrestore/sysrestore.state'
[IPA Discovery]
Starting IPA discovery with domain=None, servers=None,
hostname=testing-ubuntu001.pp
Start searching for LDAP SRV record in pp (domain of the hostname) and
its sub-domains
Search DNS for SRV record of _ldap._tcp.pp
DNS record not found: EmptyLabel
Start searching for LDAP SRV record in .pp (search domain from
/etc/resolv.conf) and its sub-domains
Search DNS for SRV record of _ldap._tcp..pp
DNS record not found: EmptyLabel
Already searched pp; skipping
No LDAP server found
No LDAP server found
Unable to discover domain, not provided on command line
Installation failed. Rolling back changes.
IPA client is not configured on this system.
```
Yet on the same client:
```
root@testing-ubuntu001:~# dig srv _ldap._tcp.pp +short
0 100 389 production-ipa003.pp.
0 100 389 production-ipa001.pp.
0 100 389 production-ipa002.pp.
```
Why can't ipa-client-install discover those SRV records?
johnny
--
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] Antwort: FreeIPA groups not shown on client
freeipa-users-boun...@redhat.com schrieb am 22.05.2015 09:37:04: Von: Nikola Kržalić nik...@krzalic.com An: freeipa-users@redhat.com Datum: 22.05.2015 15:05 Betreff: [Freeipa-users] FreeIPA groups not shown on client Gesendet von: freeipa-users-boun...@redhat.com I have a ubuntu system running IPA client. I am able to log in via ssh using IPA users, but I do not get any group memberships or sudo rules. Same configuration works on a different system (running CentOS). sssd domain log output shows that the groups are retrieved from server successfully: (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] (0x1000): Added group [admins] for user [nkrzalic] (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] (0x1000): Added group [ipausers] for user [nkrzalic] (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] (0x1000): Added group [editors] for user [nkrzalic] (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] (0x1000): Added group [trust admins] for user [nkrzalic] (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] (0x1000): Added group [devops_team] for user [nkrzalic] (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] (0x1000): Added group [dev_team] for user [nkrzalic] (Fri May 22 07:04:37 2015) [sssd[be[ipa.*]]] [hbac_eval_user_element] (0x1000): Added group [sys_team] for user [nkrzalic] However, these groups are not shown on the user upon login: nkrzalic@ircsrv1:~$ id uid=281200051(nkrzalic) gid=281200051(nkrzalic) groups=281200051(nkrzalic) I tried cleaning sssd cache but that didn't help. sssd conf is as follows: [sssd] services = nss, pam, ssh, sudo config_file_version = 2 nsswitch.conf seems to be correct as well: # /etc/nsswitch.conf passwd: compat sss group: compat sss shadow: compat hosts: files dns networks: files protocols: db files services: db files ethers: db files rpc:db files netgroup: nis sss sudoers:files sss Interestingly after I do getent group devops_team this group shows up: nkrzalic@ircsrv1:~$ id uid=281200051(nkrzalic) gid=281200051(nkrzalic) groups=281200051(nkrzalic),28121(devops_team) nkrzalic@ircsrv1:~$ Any ideas? try to kill the cache with: (stop sssd) rm -rf /var/lib/sss/db/* (start sssd) we has had the same problems often here and only really kill the cache has fixed it (sss_cache -A hasnt help) Greetz Christoph Kaminski -- 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] [[Test-Announce] Fedora 22 Final status is Go, release on May 26, 2015]
Hi, As per attached message, Fedora 22 final release will come to life next week. If you are planning to use FreeIPA in Fedora 22 or upgrade your FreeIPA deployment to Fedora 22, make sure updates-testing repository is enabled. Several last moment bug fixes related to FreeIPA were not rolled into the final Fedora 22 image and they are waiting in updats-testing for the gates to be open after release. One particular area is support for cross-forest trusts with Active Directory --- Samba in Fedora 22 got upgraded to 4.2.1 version which caused some changes in underlying libraries FreeIPA uses for supporting the cross-forest trust. The fixes are awaiting you after install in the updats-testing. Happy Fedora 22 use! -- / Alexander Bokovoy ---BeginMessage--- At the Fedora 22 Final Go/No-Go Meeting #2 that just occurred, it was agreed to Go with the Fedora 22 Final by Fedora QA, Release Engineering and Development. Fedora 22 Final will be publicly available on Tuesday, May 26, 2015. Meeting details can be seen here: Minutes: http://bit.ly/1Bh2pH1 Log: http://bit.ly/1HzMI5g Thank you everyone for a great job, sleepless nights validating TCs, RCs, fixing bugs, composing stuf and everything else needed for smooth releases. Amazing last three years wrangling releases for me! Jaroslav ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct---End Message--- -- 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] ubuntu dns discovery
On 22/05/15 18:05, Johnny Tan wrote:
Our servers run CentOS-6.6 and ipa-server-3.0.0-42.el6.centos.x86_64
Our CentOS clients (also 6.6) join the domain seamlessly.
Our Ubuntu 14.04 LTS clients, however, don't seem to be able to
auto-discover domain, realm, or IPA servers:
```
dpkg -l | grep freeipa
ii freeipa-client 3.3.4-0ubuntu3.1
amd64FreeIPA centralized identity framework -- client
/usr/sbin/ipa-client-install --mkhomedir --no-ntp --no-sudo
--unattended --hostname testing-ubuntu001.pp --principal admin
--password xx --debug
/usr/sbin/ipa-client-install was invoked with options: {'domain':
None, 'force': False, 'krb5_offline_passwords': True, 'primary':
False, 'realm_name': None, 'force_ntpd': False, 'create_sshfp': True,
'conf_sshd': True, 'conf_ntp': False, 'on_master': False,
'ntp_server': None, 'ca_cert_file': None, 'principal': 'admin',
'keytab': None, 'hostname': 'testing-ubuntu001.pp', 'no_ac': False,
'unattended': True, 'sssd': True, 'trust_sshfp': False, 'dns_updates':
False, 'mkhomedir': True, 'conf_ssh': True, 'force_join': False,
'server': None, 'prompt_password': False, 'permit': False, 'debug':
True, 'preserve_sssd': False, 'uninstall': False}
missing options might be asked for interactively later
Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index'
Loading StateFile from '/var/lib/ipa-client/sysrestore/sysrestore.state'
[IPA Discovery]
Starting IPA discovery with domain=None, servers=None,
hostname=testing-ubuntu001.pp
Start searching for LDAP SRV record in pp (domain of the hostname)
and its sub-domains
Search DNS for SRV record of _ldap._tcp.pp
DNS record not found: EmptyLabel
Start searching for LDAP SRV record in .pp (search domain from
/etc/resolv.conf) and its sub-domains
Search DNS for SRV record of _ldap._tcp..pp
DNS record not found: EmptyLabel
Already searched pp; skipping
No LDAP server found
No LDAP server found
Unable to discover domain, not provided on command line
Installation failed. Rolling back changes.
IPA client is not configured on this system.
```
Yet on the same client:
```
root@testing-ubuntu001:~# dig srv _ldap._tcp.pp +short
0 100 389 production-ipa003.pp.
0 100 389 production-ipa001.pp.
0 100 389 production-ipa002.pp.
```
Why can't ipa-client-install discover those SRV records?
johnny
Hello,
this is weird, DNS record not found: EmptyLabel, this error returns
python-dns when empty label is used in domain name.
And here is empty label - _ldap._tcp..pp (two dots).
But that doubled dot is not on line above and the error is the same,
interesting.
--
Martin Basti
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Certificate operation cannot be completed: Unable to communicate with CMS (Not Found)
Hi Rob And thanks for the new instructions. However, right out of the gate: $ ipa-csreplica-manage set-renewal-master Usage: ipa-csreplica-manage [options] ipa-csreplica-manage: error: must provide a command [force-sync | disconnect | list | del | connect | re-initialize] Are there any RHEL6 specific instructions I can follow to the promised land? On Wed, May 20, 2015 at 8:30 PM, Rob Crittenden rcrit...@redhat.com wrote: Sina Owolabi wrote: Hi Rob This is the only CA master. The one I cloned it from was decommissioned, reinstalled and then made to be a replica of this server. Looks like I'm really stuck. How do I export the data out so I can reinstall from scratch, if possible? There are a lot of rules and configuration data I'd really like to keep. So in this case you have no master managing the renewal. Take a look at http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master#Procedure_in_FreeIPA_.3C_4.0 starting at the step Reconfigure a CA as the new master Since at least one certificate has expired you'll need to go back in time to get this working. Be sure to restart IPA after going back to ensure that the CA is up. You'll eventually want to do the CRL changes as well. rob On Wed, May 20, 2015, 2:32 PM Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com wrote: Sina Owolabi wrote: Another key difference I noticed is that the problematic certs have CA:IPA in them, while the working certs have CA: dogtag-ipa-retrieve-agent-submit. Ok, the full output is really helpful. First an explanation of CA subsystem renewal. CA clones are just that, exact clones of each other, which means they use the same subsystem certificates for OCSP, audit, etc. This also means that at renewal time they need to be renewed on only one master and then somehow shared with the ohter clones. The initially-installed CA is designated as the renewal master by default. It configures certmonger to renew the CA subsytem certificates and put the new public cert into a shared area in IPA that will be replicated to the other masters. The non-renewal masters are configured with a special CA, dogtag-ipa-retrieve-agent-submit, that looks in this shared area for an updated certificate and when available, it installs it. So the issue is that it isn't seeing this updated certificate, hence CA_WORKING. The CA_UNREACHABLE are due to the fact that the IPA RA agent certificate that IPA uses to talk to the CA expired on 04/29. So the steps you need to take are: 1. Check your other CA masters and see if they have been renewed properly (getcert list will tell you, look for expiration in 2017). 2. If they have, see if the data was pushed to LDAP $ kinit admin $ ldapsearch -Y GSSAPI -b cn=ca_renewal,cn=ipa,cn=etc,dc=example,dc=com See if there are certificate entries there. Check on multiple masters to see if there is a replication issue. If the certs are there you can try restarting certmonger to kickstart the request. 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
