Re: [Freeipa-users] Stuck getting sudo working with Ubuntu client
Thanks again, Lukas! I was wondering if the overlaps of names was a problem, so I redid parts of my IPA setup to rename them - thanks for pointing out the ticket! Also, your suggestion to use ldap_group_object_class = ipaUserGroup worked - which saves me the trouble of tracking that down in six months when my IPA domain grows and the performance issues associated with enumerate begin to manifest. Many thanks - you are extraordinarily helpful. My colleagues and I are quite grateful for all your advice! Thanks again, Andrew On Mon, Apr 20, 2015 at 1:29 AM, Lukas Slebodnik lsleb...@redhat.com wrote: On (19/04/15 12:51), Andrew Sacamano wrote: Thanks again Lukas, These turned out to be very helpful debugging suggestions, and were the critical part of getting the problem solved - the pointer to ldb-tools was extremely helpful in identifying where the issue was happening! With them, I was able to see the right sudo rules were being cached, and that the change from sudo working to sudo not working happened not because of the host, but because of the user, and in particular, the user being a listed explicitly, or only as part of a group. The user's groups were being listed in the user's entry in the cache, but not when running the id command. Some quick googling, and I discovered that in Ubuntu 14.04, the sssd option enumerate defaults to false, which meant that the group memberships were not taking effect, which meant that sudo rules based on membership in a group weren't working. Setting enumerate to true got everything working. If you have a problem with id might be caused by https://fedorahosted.org/sssd/ticket/2471 You can fix the bug with ammending configuration. put ldap_group_object_class = ipaUserGroup into domain section of sssd.conf It should work even with disabled enumeration. 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] understanding RUVs?
Hello, When I was working with OpenLDAP, and AD - and did not deal with RUVs the way I am with 389-ds and IPA. I am trying to understand what is normal for values. If I am looking at this (and seem to have no replication problems): ipa-replica-manage list-ruv ipa001.example.com:389: 13 ipa002.example.com:389: 12 ipa003.example.com:389: 11 ipa004.example.com:389: 10 ipa005.example.com:389: 7 ipa006.example.com:389: 6 ipa007.example.com:389: 5 ipa008.example.com:389: 3 ipa009.example.com:389: 16 ipa00a.example.com:389: 17 ipa00b.example.com:389: 15 ipa00c.example.com:389: 14 ipa00d.example.com:389: 9 ipa00e.example.com:389: 8 ipa00f.example.com:389: 4 I guess I was wondering, should I be seeing all the same values or should they all be unique based on being replicated and the order they were added? Or is it telling me something else? Sorry, I guess I am still trying to wrap my head around replication metadata. Thank you ~J -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] HBAC and SUDO rules for legacy clients
On 04/20/2015 12:08 PM, Srdjan Dutina wrote: Sorry for misunderstanding. I understand HBAC rules will not work for Centos 5. I just wanted to make sure disabling allow all rule and adding new HBAC rules won't interfere with AD users logging on Centos 5. To clarify: CentOS 5 needs to point to compat tree for AD users to authenticate. You need to use LDAP SSSD back end for that not IPA SSSD back end (idenity_provider setting in sssd.conf). Once you use LDAP back end you need to use some other access control configuration not HBAC as HBAC comes when you use IPA SSSD back end only. You can use ldap filter or simple acces provider or something other option that is support in SSSD 1.5 against LDAP. Does this make sense? On Mon, Apr 20, 2015 at 5:03 PM Alexander Bokovoy aboko...@redhat.com mailto:aboko...@redhat.com wrote: On Mon, 20 Apr 2015, Srdjan Dutina wrote: Just found in http://www.freeipa.org/images/0/0d/FreeIPA33-legacy-clients.pdf the next sentence: If you have HBAC's allow_all rule disabled, you will need to allow system-auth service on the FreeIPA master, so that authentication of the AD users can be performed. Is this true for FreeIPA 4.1.0 also and how could I do this? Either you are reading it wrong or I don't get where you want to apply HBAC rules because this is for IPA masters, not legacy clients per se. Yes, you nede to create HBAC service named 'system-auth' and grant access to it to AD users on IPA masters, but all it will allow you is to authenticate AD users via compat tree. If your RHEL5 SSSD clients attempt to run own HBAC rule checks, AD users cannot be checked by those rules. -- / Alexander Bokovoy -- 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
[Freeipa-users] ipa: ERROR: non-public: TypeError -- ipa trust-add crash
Hi This is for freeipa-server-4.1.4-1.el7.centos.x86_64 When Running: ipa trust-add --type=ad ad.domain.com --admin ad_user --password ipa: ERROR: an internal error has occurred Some more info at : /var/log/httpd/error_log num_setup=2, max_setup=0, param_total=0, this_param=0, max_param=0, data_total=116, this_data=116, max_data=4280, param_offset=84, param_pad=2, param_disp=0, data_offset=84, data_pad=0, data_disp=0 smb_signing_md5: sequence number 14 smb_signing_sign_pdu: sent SMB signature of [] FD A6 9F 6B 2F 72 8D 4F ...k/r.O smb_signing_md5: sequence number 15 smb_signing_check_pdu: seq 15: got good SMB signature of [] B3 5C 71 C9 1F E4 21 35 .q...!5 rpc reply data: [] 00 00 02 00 08 00 00 00 32 00 34 00 04 00 02 00 2.4. [0010] 32 00 34 00 08 00 02 00 00 00 00 00 03 00 00 00 2.4. [0020] 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [0030] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [0040] 00 00 00 00 1A 00 00 00 00 00 00 00 19 00 00 00 [00C0] 6D 00 00 00 00 00 00 00 m... [Mon Apr 20 22:59:48.849462 2015] [:error] [pid 32475] ipa: ERROR: non-public: TypeError: default/librpc/gen_ndr/py_lsa.c:9436: Expected type 'security.dom_sid' for 'py_dom_sid' of type 'NoneType' [Mon Apr 20 22:59:48.849484 2015] [:error] [pid 32475] Traceback (most recent call last): [Mon Apr 20 22:59:48.849486 2015] [:error] [pid 32475] File /usr/lib/python2.7/site-packages/ipaserver/rpcserver.py, line 349, in wsgi_execute [Mon Apr 20 22:59:48.849489 2015] [:error] [pid 32475] result = self.Command[name](*args, **options) [Mon Apr 20 22:59:48.849491 2015] [:error] [pid 32475] File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 439, in __call__ [Mon Apr 20 22:59:48.849492 2015] [:error] [pid 32475] ret = self.run(*args, **options) [Mon Apr 20 22:59:48.849494 2015] [:error] [pid 32475] File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 754, in run [Mon Apr 20 22:59:48.849496 2015] [:error] [pid 32475] return self.execute(*args, **options) [Mon Apr 20 22:59:48.849498 2015] [:error] [pid 32475] File /usr/lib/python2.7/site-packages/ipalib/plugins/trust.py, line 474, in execute [Mon Apr 20 22:59:48.849500 2015] [:error] [pid 32475] result = self.execute_ad(full_join, *keys, **options) [Mon Apr 20 22:59:48.849502 2015] [:error] [pid 32475] File /usr/lib/python2.7/site-packages/ipalib/plugins/trust.py, line 709, in execute_ad [Mon Apr 20 22:59:48.849504 2015] [:error] [pid 32475] self.realm_passwd [Mon Apr 20 22:59:48.849506 2015] [:error] [pid 32475] File /usr/lib/python2.7/site-packages/ipaserver/dcerpc.py, line 1222, in join_ad_full_credentials [Mon Apr 20 22:59:48.849507 2015] [:error] [pid 32475] self.remote_domain.establish_trust(self.local_domain, trustdom_pass) [Mon Apr 20 22:59:48.849509 2015] [:error] [pid 32475] File /usr/lib/python2.7/site-packages/ipaserver/dcerpc.py, line 963, in establish_trust [Mon Apr 20 22:59:48.849511 2015] [:error] [pid 32475] self._pipe.DeleteTrustedDomain(self._policy_handle, res.info_ex.sid) [Mon Apr 20 22:59:48.849513 2015] [:error] [pid 32475] TypeError: default/librpc/gen_ndr/py_lsa.c:9436: Expected type 'security.dom_sid' for 'py_dom_sid' of type 'NoneType' [Mon Apr 20 22:59:48.849782 2015] [:error] [pid 32475] ipa: INFO: [jsonserver_kerb] ad...@ldap.domain.com: trust_add(u'ad.domain.com', trust_type=u'ad', realm_admin=u'ad_user', realm_passwd=u'', all=False, raw=False, version=u'2.114'): TypeError Have you seen any of this before? Thanks! -- 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] web interface for FREEIPA runtime error
Sometimes when I access the web URL where FreeIPA is installed for general administration ,I encounter this error below. Runtime error Web UI got in unrecoverable state during metadata phase I can only restore access after I have restarted the server ,is there a service I can restart or something that can prevent it from happening -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] ipa: ERROR: non-public: TypeError -- ipa trust-add crash
On Tue, 21 Apr 2015, g.fer.or...@unicyber.co.uk wrote: Hi This is for freeipa-server-4.1.4-1.el7.centos.x86_64 When Running: ipa trust-add --type=ad ad.domain.com --admin ad_user --password ipa: ERROR: an internal error has occurred Some more info at : /var/log/httpd/error_log num_setup=2, max_setup=0, param_total=0, this_param=0, max_param=0, data_total=116, this_data=116, max_data=4280, param_offset=84, param_pad=2, param_disp=0, data_offset=84, data_pad=0, data_disp=0 smb_signing_md5: sequence number 14 smb_signing_sign_pdu: sent SMB signature of [] FD A6 9F 6B 2F 72 8D 4F ...k/r.O smb_signing_md5: sequence number 15 smb_signing_check_pdu: seq 15: got good SMB signature of [] B3 5C 71 C9 1F E4 21 35 .q...!5 rpc reply data: [] 00 00 02 00 08 00 00 00 32 00 34 00 04 00 02 00 2.4. [0010] 32 00 34 00 08 00 02 00 00 00 00 00 03 00 00 00 2.4. [0020] 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [0030] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [0040] 00 00 00 00 1A 00 00 00 00 00 00 00 19 00 00 00 [00C0] 6D 00 00 00 00 00 00 00 m... [Mon Apr 20 22:59:48.849462 2015] [:error] [pid 32475] ipa: ERROR: non-public: TypeError: default/librpc/gen_ndr/py_lsa.c:9436: Expected type 'security.dom_sid' for 'py_dom_sid' of type 'NoneType' [Mon Apr 20 22:59:48.849484 2015] [:error] [pid 32475] Traceback (most recent call last): [Mon Apr 20 22:59:48.849486 2015] [:error] [pid 32475] File /usr/lib/python2.7/site-packages/ipaserver/rpcserver.py, line 349, in wsgi_execute [Mon Apr 20 22:59:48.849489 2015] [:error] [pid 32475] result = self.Command[name](*args, **options) [Mon Apr 20 22:59:48.849491 2015] [:error] [pid 32475] File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 439, in __call__ [Mon Apr 20 22:59:48.849492 2015] [:error] [pid 32475] ret = self.run(*args, **options) [Mon Apr 20 22:59:48.849494 2015] [:error] [pid 32475] File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 754, in run [Mon Apr 20 22:59:48.849496 2015] [:error] [pid 32475] return self.execute(*args, **options) [Mon Apr 20 22:59:48.849498 2015] [:error] [pid 32475] File /usr/lib/python2.7/site-packages/ipalib/plugins/trust.py, line 474, in execute [Mon Apr 20 22:59:48.849500 2015] [:error] [pid 32475] result = self.execute_ad(full_join, *keys, **options) [Mon Apr 20 22:59:48.849502 2015] [:error] [pid 32475] File /usr/lib/python2.7/site-packages/ipalib/plugins/trust.py, line 709, in execute_ad [Mon Apr 20 22:59:48.849504 2015] [:error] [pid 32475] self.realm_passwd [Mon Apr 20 22:59:48.849506 2015] [:error] [pid 32475] File /usr/lib/python2.7/site-packages/ipaserver/dcerpc.py, line 1222, in join_ad_full_credentials [Mon Apr 20 22:59:48.849507 2015] [:error] [pid 32475] self.remote_domain.establish_trust(self.local_domain, trustdom_pass) [Mon Apr 20 22:59:48.849509 2015] [:error] [pid 32475] File /usr/lib/python2.7/site-packages/ipaserver/dcerpc.py, line 963, in establish_trust [Mon Apr 20 22:59:48.849511 2015] [:error] [pid 32475] self._pipe.DeleteTrustedDomain(self._policy_handle, res.info_ex.sid) [Mon Apr 20 22:59:48.849513 2015] [:error] [pid 32475] TypeError: default/librpc/gen_ndr/py_lsa.c:9436: Expected type 'security.dom_sid' for 'py_dom_sid' of type 'NoneType' [Mon Apr 20 22:59:48.849782 2015] [:error] [pid 32475] ipa: INFO: [jsonserver_kerb] ad...@ldap.domain.com: trust_add(u'ad.domain.com', trust_type=u'ad', realm_admin=u'ad_user', realm_passwd=u'', all=False, raw=False, version=u'2.114'): TypeError Have you seen any of this before? No. Can you file a bug or ticket and attach full httpd's error_log there? -- / 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] Found new problem after 3.3 - 4.1 update
Thank You, I'm stupid enough to forgot about debug mode. Here the problem: Insufficient access: Insufficient 'write' privilege to the 'krbLastPwdChange' attribute of entry 'fqdn=sib-rhel07.unix.ad.com,cn=computers,cn=accounts,dc=unix,dc=ad,dc=com'. This host is not new, it was removed from domain to test the privileges... WBR, Alexander Frolushkin -Original Message- From: Rob Crittenden [mailto:rcrit...@redhat.com] Sent: Monday, April 20, 2015 8:41 PM To: Alexander Frolushkin (SIB); freeipa-users@redhat.com; 'David Kupka' Subject: Re: [Freeipa-users] Found new problem after 3.3 - 4.1 update Alexander Frolushkin wrote: Very strange. If this user acts as a member of admins group - it can enroll host. If not - it can't. Only difference this group brings in permissions - a number of replication agreement permissions... admins can do nearly anything so that's not surprising. For host enrollment these permissions are quite broad IMHO, particularly the replication bits. Run ipa-client-install with the debug flag and you should get more information out of ipa-join. /var/log/ipaclient-install.log will log all fo this so you shouldn't need to try capturing stdout. At the same time see if /var/log/httpd/error_log on the IPA master provides any information on why the request was rejected, or at least which operation failed. At a glance these permissions look sufficient, and then some. rob Информация в этом сообщении предназначена исключительно для конкретных лиц, которым она адресована. В сообщении может содержаться конфиденциальная информация, которая не может быть раскрыта или использована кем-либо, кроме адресатов. Если вы не адресат этого сообщения, то использование, переадресация, копирование или распространение содержания сообщения или его части незаконно и запрещено. Если Вы получили это сообщение ошибочно, пожалуйста, незамедлительно сообщите отправителю об этом и удалите со всем содержимым само сообщение и любые возможные его копии и приложения. The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this communication in error please notify us immediately by responding to this email and then delete the e-mail and all attachments and any copies thereof. (c)20mf50 -- 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] Found new problem after 3.3 - 4.1 update
Alexander Frolushkin wrote: Thank You, I'm stupid enough to forgot about debug mode. Here the problem: Insufficient access: Insufficient 'write' privilege to the 'krbLastPwdChange' attribute of entry 'fqdn=sib-rhel07.unix.ad.com,cn=computers,cn=accounts,dc=unix,dc=ad,dc=com'. This host is not new, it was removed from domain to test the privileges... Try adding 'Manage host keytab' to your privilege. I'd use the privilege 'Host Enrollment' as a model of the minimum of what you need. This covers only the enrollment bit. Add creating hosts and others as needed. rob WBR, Alexander Frolushkin -Original Message- From: Rob Crittenden [mailto:rcrit...@redhat.com] Sent: Monday, April 20, 2015 8:41 PM To: Alexander Frolushkin (SIB); freeipa-users@redhat.com; 'David Kupka' Subject: Re: [Freeipa-users] Found new problem after 3.3 - 4.1 update Alexander Frolushkin wrote: Very strange. If this user acts as a member of admins group - it can enroll host. If not - it can't. Only difference this group brings in permissions - a number of replication agreement permissions... admins can do nearly anything so that's not surprising. For host enrollment these permissions are quite broad IMHO, particularly the replication bits. Run ipa-client-install with the debug flag and you should get more information out of ipa-join. /var/log/ipaclient-install.log will log all fo this so you shouldn't need to try capturing stdout. At the same time see if /var/log/httpd/error_log on the IPA master provides any information on why the request was rejected, or at least which operation failed. At a glance these permissions look sufficient, and then some. rob Информация в этом сообщении предназначена исключительно для конкретных лиц, которым она адресована. В сообщении может содержаться конфиденциальная информация, которая не может быть раскрыта или использована кем-либо, кроме адресатов. Если вы не адресат этого сообщения, то использование, переадресация, копирование или распространение содержания сообщения или его части незаконно и запрещено. Если Вы получили это сообщение ошибочно, пожалуйста, незамедлительно сообщите отправителю об этом и удалите со всем содержимым само сообщен�! �е и л� �бые возможные его копии и приложения. The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this communication in error please notify us immediately by responding to this email and then delete the e-mail and all attachments and any copies thereof. (c)20mf50 -- 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] web interface for FREEIPA runtime error
Chamambo Martin wrote: Sometimes when I access the web URL where FreeIPA is installed for general administration ,I encounter this error below. Runtime error Web UI got in unrecoverable state during metadata phase I can only restore access after I have restarted the server ,is there a service I can restart or something that can prevent it from happening I'd check /var/log/httpd/error_log for more information when you see this problem. It may have more details. 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] ipa-replica-prepare failing
Hi, Let me know how I can assist. In the meantime could I setup a replica using a different certificate? Self signed or anything like that? Regards, D 2015-04-17 15:27 GMT+02:00 Jan Cholasta jchol...@redhat.com: Hi, I don't have any new information. I'm trying to reproduce the problem but had no luck so far. Honza Dne 17.4.2015 v 15:23 David Dejaeghere napsal(a): Hi, Any more things I can try out? How do we proceed? Kind Regards, D 2015-04-15 11:48 GMT+02:00 David Dejaeghere david.dejaegh...@gmail.com mailto:david.dejaegh...@gmail.com: Hi Honza, That gave me the exact same output. Any ideas? Regards, D 2015-04-15 7:33 GMT+02:00 Jan Cholasta jchol...@redhat.com mailto:jchol...@redhat.com: Hi, Dne 14.4.2015 v 19:47 Rob Crittenden napsal(a): David Dejaeghere wrote: Hi Rob, So you want to output of the command using pk12 with server cert and key? or with the ca chain in there too? Oddly enough it is failing in exactly the same place. Those GoDaddy CA certs are still being loaded from somewhere, I'm not sure where, and I suspect that is the source of the problem. They are in the default CA certificate bundle (in the ca-certificate package). I guess NSS loads it automatically. I'm going to forward the log to a colleague who has worked on this code more recently than I have. Maybe he will have an idea. Could you try if the following works? # mv /usr/share/pki/ca-trust-__source/ca-bundle.trust.crt /root/ca-bundle.trust.crt # update-ca-trust # ipa-replica-prepare ... # mv /root/ca-bundle.trust.crt /usr/share/pki/ca-trust-__source/ca-bundle.trust.crt # update-ca-trust rob Honza -- Jan Cholasta -- Jan Cholasta -- 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] Found new problem after 3.3 - 4.1 update
Very strange. If this user acts as a member of admins group - it can enroll host. If not - it can't. Only difference this group brings in permissions - a number of replication agreement permissions... -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Alexander Frolushkin Sent: Monday, April 20, 2015 5:06 PM To: 'David Kupka'; freeipa-users@redhat.com Subject: Re: [Freeipa-users] Found new problem after 3.3 - 4.1 update Hello! This thread seams to solve similar issue: https://www.redhat.com/archives/freeipa-users/2013-January/msg00153.html Thank You, but... On 3.3 I used this thread to make it work. But on 4.1: User, able to enroll: memberofindirect: cn=System: Read Replication Agreements,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=System: Modify Hosts,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=Modify DNA Range,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=Add Configuration Sub-Entries,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=Modify PassSync Managers Configuration,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=Read LDBM Database Configuration,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=Read PassSync Managers Configuration,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=Remove Replication Agreements,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=Modify Replication Agreements,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=Read DNA Range,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=Replication Administrators,cn=privileges,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=System: Add Hosts,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=System: Manage Host Enrollment Password,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=System: Manage Host Certificates,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=Add Replication Agreements,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=System: Enroll a Host,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=Host Enrollment,cn=privileges,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=System: Add krbPrincipalName to a Host,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru User, not able to enroll: memberofindirect: cn=Read PassSync Managers Configuration,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=System: Modify Hosts,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=Modify DNA Range,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=Add Configuration Sub-Entries,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=Read LDBM Database Configuration,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=Read DNA Range,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=System: Add Hosts,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=System: Manage Host Enrollment Password,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=System: Manage Host Certificates,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: ipaUniqueID=05b0d3f4-d2e1-11e4-b40b-00505698162f,cn=sudorules,cn=sudo,dc=unix,dc=megafon,dc=ru memberofindirect: cn=System: Enroll a Host,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=Host Enrollment,cn=privileges,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=System: Add krbPrincipalName to a Host,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru I used to try made it looks as close as possible in terms of permissions (replication agreement not looks like a required permission). But - first one works (enroll a new host to IPA), second one - not. -- David Kupka Информация в этом сообщении предназначена исключительно для конкретных лиц, которым она адресована. В сообщении может содержаться конфиденциальная информация, которая не может быть раскрыта или использована кем-либо, кроме адресатов. Если вы не адресат этого сообщения, то использование, переадресация, копирование или распространение содержания сообщения или его части незаконно и запрещено. Если Вы получили это сообщение ошибочно, пожалуйста, незамедлительно сообщите отправителю об этом и удалите со всем содержимым само сообщение и любые возможные его копии и приложения. The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the
[Freeipa-users] Found new problem after 3.3 - 4.1 update
Hello! We found our host enrollment role does not work after ipa server update. Now user having this role get this error: Joining realm failed: No permission to join this host to the IPA domain. Maybe now we need to add some addition permissions to this role, can someone to point out which permissions is required to add new host to domain? WBR, Alexander Frolushkin Cell +79232508764 Work +79232507764 ?? ? ? ? ? ??? ?? ???, ??? ??? ??. ? ? ? ??? ??, ??? ?? ? ??? ???-, ? ?. ?? ?? ??? ? ?, ?? ?, ?, ??? ??? ??? ?? ? ??? ??? ? ? ? ?. ?? ??? ? , ??, ??? ??? ?? ? ??? ?? ?? ? ? ? ? ??? ? ? ??. The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this communication in error please notify us immediately by responding to this email and then delete the e-mail and all attachments and any copies thereof. (c)20mf50 -- 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] Stuck getting sudo working with Ubuntu client
On (19/04/15 12:51), Andrew Sacamano wrote: Thanks again Lukas, These turned out to be very helpful debugging suggestions, and were the critical part of getting the problem solved - the pointer to ldb-tools was extremely helpful in identifying where the issue was happening! With them, I was able to see the right sudo rules were being cached, and that the change from sudo working to sudo not working happened not because of the host, but because of the user, and in particular, the user being a listed explicitly, or only as part of a group. The user's groups were being listed in the user's entry in the cache, but not when running the id command. Some quick googling, and I discovered that in Ubuntu 14.04, the sssd option enumerate defaults to false, which meant that the group memberships were not taking effect, which meant that sudo rules based on membership in a group weren't working. Setting enumerate to true got everything working. If you have a problem with id might be caused by https://fedorahosted.org/sssd/ticket/2471 You can fix the bug with ammending configuration. put ldap_group_object_class = ipaUserGroup into domain section of sssd.conf It should work even with disabled enumeration. 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] Found new problem after 3.3 - 4.1 update
On 04/20/2015 12:00 PM, Alexander Frolushkin wrote: Hello! We found our host enrollment role does not work after ipa server update. Now user having this role get this error: Joining realm failed: No permission to join this host to the IPA domain. Maybe now we need to add some addition permissions to this role, can someone to point out which permissions is required to add new host to domain? WBR, Alexander Frolushkin Cell +79232508764 Work +79232507764 ?? ? ? ? ? ??? ?? ???, ??? ??? ??. ? ? ? ??? ??, ??? ?? ? ??? ???-, ? ?. ?? ?? ??? ? ?, ?? ?, ?, ??? ??? ??? ?? ? ??? ??? ? ? ? ?. ?? ??? ? , ??, ??? ??? ?? ? ??? ?? ?? ? ? ? ? ??? ? ? ??. The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this communication in error please notify us immediately by responding to this email and then delete the e-mail and all attachments and any copies thereof. (c)20mf50 Hello! This thread seams to solve similar issue: https://www.redhat.com/archives/freeipa-users/2013-January/msg00153.html -- David Kupka -- 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] Found new problem after 3.3 - 4.1 update
Hello! This thread seams to solve similar issue: https://www.redhat.com/archives/freeipa-users/2013-January/msg00153.html Thank You, but... On 3.3 I used this thread to make it work. But on 4.1: User, able to enroll: memberofindirect: cn=System: Read Replication Agreements,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=System: Modify Hosts,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=Modify DNA Range,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=Add Configuration Sub-Entries,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=Modify PassSync Managers Configuration,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=Read LDBM Database Configuration,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=Read PassSync Managers Configuration,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=Remove Replication Agreements,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=Modify Replication Agreements,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=Read DNA Range,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=Replication Administrators,cn=privileges,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=System: Add Hosts,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=System: Manage Host Enrollment Password,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=System: Manage Host Certificates,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=Add Replication Agreements,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=System: Enroll a Host,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=Host Enrollment,cn=privileges,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=System: Add krbPrincipalName to a Host,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru User, not able to enroll: memberofindirect: cn=Read PassSync Managers Configuration,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=System: Modify Hosts,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=Modify DNA Range,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=Add Configuration Sub-Entries,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=Read LDBM Database Configuration,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=Read DNA Range,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=System: Add Hosts,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=System: Manage Host Enrollment Password,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=System: Manage Host Certificates,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: ipaUniqueID=05b0d3f4-d2e1-11e4-b40b-00505698162f,cn=sudorules,cn=sudo,dc=unix,dc=megafon,dc=ru memberofindirect: cn=System: Enroll a Host,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=Host Enrollment,cn=privileges,cn=pbac,dc=unix,dc=megafon,dc=ru memberofindirect: cn=System: Add krbPrincipalName to a Host,cn=permissions,cn=pbac,dc=unix,dc=megafon,dc=ru I used to try made it looks as close as possible in terms of permissions (replication agreement not looks like a required permission). But - first one works (enroll a new host to IPA), second one - not. -- David Kupka Информация в этом сообщении предназначена исключительно для конкретных лиц, которым она адресована. В сообщении может содержаться конфиденциальная информация, которая не может быть раскрыта или использована кем-либо, кроме адресатов. Если вы не адресат этого сообщения, то использование, переадресация, копирование или распространение содержания сообщения или его части незаконно и запрещено. Если Вы получили это сообщение ошибочно, пожалуйста, незамедлительно сообщите отправителю об этом и удалите со всем содержимым само сообщение и любые возможные его копии и приложения. The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this communication in error please notify us immediately by responding to this email and then delete the e-mail and all attachments and any copies thereof. (c)20mf50 -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go
Re: [Freeipa-users] Slow user logon with IPA
2015-04-15 15:08 GMT+02:00 Lukas Slebodnik lsleb...@redhat.com: On (15/04/15 08:53), Jakub Hrozek wrote: I pushed the selinux performance patches upstream yesterday. They will make their way to 7.2, 6.7 and I guess Lukas might also cherry-pick them for Fedora. Packages for fedora 21,22 are built. You just need to wait utill they are available in updates testing or you can download packages from koji. https://admin.fedoraproject.org/updates/sssd-1.12.4-4.fc22 https://admin.fedoraproject.org/updates/sssd-1.12.4-3.fc21 Please test and provide karma. Karma provided. For my setup I'm finally back to the 3-4 seconds login time for a user with only a handful of groups. Thanks! -- john -- 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] HBAC and SUDO rules for legacy clients
On Mon, 20 Apr 2015, Srdjan Dutina wrote: Thank for quick answer! If I disable HBAC rule, I can still login to Centos 5 client using IPA user, but not using AD user. Is there a workaround? I need allow_all disabled because of newer IPA clients. There is no workaround so far. -- / 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] HBAC and SUDO rules for legacy clients
Thank for quick answer! If I disable HBAC rule, I can still login to Centos 5 client using IPA user, but not using AD user. Is there a workaround? I need allow_all disabled because of newer IPA clients. On Mon, Apr 20, 2015 at 4:30 PM Alexander Bokovoy aboko...@redhat.com wrote: On Mon, 20 Apr 2015, Srdjan Dutina wrote: Hi, Testing FreeIPA 4.1.0 (Centos 7 (1503)) with AD 2012 R2 trust. For Centos 5.11 Client (SSSD 1.5.1), will HBAC and SUDO rules function? If yes, does this apply AD users also? SSSD 1.5.1 does not have SUDO support. HBAC support in 1.5.1 will mot likely not work with compat tree that is required for legacy clients to support AD users. I don't think this was even tested. -- / 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
[Freeipa-users] HBAC and SUDO rules for legacy clients
Hi, Testing FreeIPA 4.1.0 (Centos 7 (1503)) with AD 2012 R2 trust. For Centos 5.11 Client (SSSD 1.5.1), will HBAC and SUDO rules function? If yes, does this apply AD users also? 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] HBAC and SUDO rules for legacy clients
On Mon, 20 Apr 2015, Srdjan Dutina wrote: Hi, Testing FreeIPA 4.1.0 (Centos 7 (1503)) with AD 2012 R2 trust. For Centos 5.11 Client (SSSD 1.5.1), will HBAC and SUDO rules function? If yes, does this apply AD users also? SSSD 1.5.1 does not have SUDO support. HBAC support in 1.5.1 will mot likely not work with compat tree that is required for legacy clients to support AD users. I don't think this was even tested. -- / 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] Found new problem after 3.3 - 4.1 update
Alexander Frolushkin wrote: Very strange. If this user acts as a member of admins group - it can enroll host. If not - it can't. Only difference this group brings in permissions - a number of replication agreement permissions... admins can do nearly anything so that's not surprising. For host enrollment these permissions are quite broad IMHO, particularly the replication bits. Run ipa-client-install with the debug flag and you should get more information out of ipa-join. /var/log/ipaclient-install.log will log all fo this so you shouldn't need to try capturing stdout. At the same time see if /var/log/httpd/error_log on the IPA master provides any information on why the request was rejected, or at least which operation failed. At a glance these permissions look sufficient, and then some. 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] HBAC and SUDO rules for legacy clients
Just found in http://www.freeipa.org/images/0/0d/FreeIPA33-legacy-clients.pdf the next sentence: If you have HBAC's allow_all rule disabled, you will need to allow system-auth service on the FreeIPA master, so that authentication of the AD users can be performed. Is this true for FreeIPA 4.1.0 also and how could I do this? On Mon, Apr 20, 2015 at 4:51 PM Alexander Bokovoy aboko...@redhat.com wrote: On Mon, 20 Apr 2015, Srdjan Dutina wrote: Thank for quick answer! If I disable HBAC rule, I can still login to Centos 5 client using IPA user, but not using AD user. Is there a workaround? I need allow_all disabled because of newer IPA clients. There is no workaround so far. -- / 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] HBAC and SUDO rules for legacy clients
On Mon, 20 Apr 2015, Srdjan Dutina wrote: Just found in http://www.freeipa.org/images/0/0d/FreeIPA33-legacy-clients.pdf the next sentence: If you have HBAC's allow_all rule disabled, you will need to allow system-auth service on the FreeIPA master, so that authentication of the AD users can be performed. Is this true for FreeIPA 4.1.0 also and how could I do this? Either you are reading it wrong or I don't get where you want to apply HBAC rules because this is for IPA masters, not legacy clients per se. Yes, you nede to create HBAC service named 'system-auth' and grant access to it to AD users on IPA masters, but all it will allow you is to authenticate AD users via compat tree. If your RHEL5 SSSD clients attempt to run own HBAC rule checks, AD users cannot be checked by those rules. -- / 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] HBAC and SUDO rules for legacy clients
Sorry for misunderstanding. I understand HBAC rules will not work for Centos 5. I just wanted to make sure disabling allow all rule and adding new HBAC rules won't interfere with AD users logging on Centos 5. On Mon, Apr 20, 2015 at 5:03 PM Alexander Bokovoy aboko...@redhat.com wrote: On Mon, 20 Apr 2015, Srdjan Dutina wrote: Just found in http://www.freeipa.org/images/0/0d/FreeIPA33-legacy-clients.pdf the next sentence: If you have HBAC's allow_all rule disabled, you will need to allow system-auth service on the FreeIPA master, so that authentication of the AD users can be performed. Is this true for FreeIPA 4.1.0 also and how could I do this? Either you are reading it wrong or I don't get where you want to apply HBAC rules because this is for IPA masters, not legacy clients per se. Yes, you nede to create HBAC service named 'system-auth' and grant access to it to AD users on IPA masters, but all it will allow you is to authenticate AD users via compat tree. If your RHEL5 SSSD clients attempt to run own HBAC rule checks, AD users cannot be checked by those rules. -- / 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
