Re: [Freeipa-users] FreeIPA bind also-notify behavior.
On 1.9.2014 12:16, Dmitri Pal wrote:
On 09/01/2014 12:05 PM, Martin Kosek wrote:
On 09/01/2014 07:50 AM, Dmitri Pal wrote:
On 08/29/2014 09:32 PM, Matthew Sellers wrote:
Hi Everyone!
I am using FreeIPA 3.3.5 on Fedora 20 and attempting to configure FreeIPA to
send notifies to non-IPA slaves, but it seems broken on IPA ( notify packets
are never sent to to slaves ).
I have configured also-notify { nameserverip; }; in named.conf on my FreeIPA
test host in the options section and watched for notify traffic with tcpdump.
This document suggests that this is supported, and this is something I have
used in non-IPA bind servers with no issues.
https://fedoraproject.org/wiki/QA:Testcase_freeipav3_dns_zone_transfer
I wanted to ask the list before I file a bug with more details. Is anyone
using this bind feature on IPA with any success?
Thanks!
Matt
The DNS level change propagation is not supported between IPA replicas instead
it uses LDAP replication to propagate the changes.
If you want another non IPA DNS server to be a slave then you can do it. See
http://www.freeipa.org/page/V3/DNS_SOA_serial_auto-incrementation for more
information.
I thought that from F20, bind-dyndb-ldap was capable of native DNS operations
like AXFR/IXFR which can be used to actually deploy slave DNS servers. I wonder
if also-notify is something different. CCing Petr Spacek to advise.
AFAIU slave DNS servers not controlled by IPA yes, replicas as slaves - no.
Let me summarize:
- AXFR is supported (at least) by all versions RHEL 6.5 and newer versions
- IXFR is supported by bind-dyndb-ldap 4.0 and newer (Fedora 20+)
- DNS NOTIFY messages are always sent to servers listed in NS records
I.e. you have to add your non-IPA slave servers to NS records in particular
zone and then it should 'just work', no other configuration (like
'also-notify') is necessary.
Please let me know if it doesn't work for you.
--
Petr^2 Spacek
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Search Base issues
Martin Kosek wrote: On 09/03/2014 09:02 AM, Martin Kosek wrote: In the meantime, you can use the workaround that Rob sent, you would just need to delete it again when the fix is in, so that the permissions do not step on each other. Actually, wait a minute. I think Rob's ACI example may be too wide, it may expose any attribute in the compat tree, including a potential userPassword. The ACI was on his custom cn=canlogin subtree, not all of cn=compat. As I see, it seems that slapi-nis plugin do not fortunately expose that, but it is safer to just list the attributes that one wants to display (this is also what we did in FreeIPA 4.0, no global wildcard allowing ACIs any more). I added a respective permission via Web UI (one part of it cannot be added via CLI, see https://fedorahosted.org/freeipa/ticket/4522) and compat tree now works for me. See attached example. Resulting permission shown in CLI: # ipa permission-show TEMPORARY - Read compat tree Permission name: TEMPORARY - Read compat tree Granted rights: read, search, compare Effective attributes: cn, description, gecos, gidnumber, homedirectory, loginshell, memberuid, objectclass, uid, uidnumber Bind rule type: all Subtree: dc=mkosek-fedora20,dc=test ACI target DN: cn=compat,dc=mkosek-fedora20,dc=test It is much easier to manipulate than ACI added via ldapmodify. I see you filed a bug on the missing CLI option. That's why I did the ACI, because I couldn't demonstrate how to add this ACI on the CLI. I hadn't gotten around to doing that last night. rob HTH, Martin Martin On 09/02/2014 11:09 PM, Rob Crittenden wrote: Chris Whittle wrote: If I do this ldapsearch -LLL -H ldaps://DOMAIN:636 -x -D uid=mac_slave,cn=users,cn=accounts,dc=domain,dc=com -w 'nachopassword' -b uid=awesomeuser,cn=users,cn=accounts,dc=domain,dc=com It works fine AFAICT there currently isn't a permission for the compat tree. The admin user can do it via 'Admin can manage any entry and of course DM can do it because it can do anything. A temporary workaround would be to add an aci manually: dn: dc=example,dc=com changetype: modify add: aci aci: (targetattr = *)(target = ldap:///uid=*,cn=canlogin,cn=compat,dc=example,dc=com;)(version 3.0;acl Read canlogin compat tree;allow (compare,read,search) userdn = ldap:///all;;) This won't show up as a permission and will grant all authenticated users read access to the canlogin compat tree. I'm assuming here this contains entries keyed on uid. 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] Search Base issues
On 09/03/2014 03:08 PM, Rob Crittenden wrote: Martin Kosek wrote: On 09/03/2014 09:02 AM, Martin Kosek wrote: In the meantime, you can use the workaround that Rob sent, you would just need to delete it again when the fix is in, so that the permissions do not step on each other. Actually, wait a minute. I think Rob's ACI example may be too wide, it may expose any attribute in the compat tree, including a potential userPassword. The ACI was on his custom cn=canlogin subtree, not all of cn=compat. As I see, it seems that slapi-nis plugin do not fortunately expose that, but it is safer to just list the attributes that one wants to display (this is also what we did in FreeIPA 4.0, no global wildcard allowing ACIs any more). I added a respective permission via Web UI (one part of it cannot be added via CLI, see https://fedorahosted.org/freeipa/ticket/4522) and compat tree now works for me. See attached example. Resulting permission shown in CLI: # ipa permission-show TEMPORARY - Read compat tree Permission name: TEMPORARY - Read compat tree Granted rights: read, search, compare Effective attributes: cn, description, gecos, gidnumber, homedirectory, loginshell, memberuid, objectclass, uid, uidnumber Bind rule type: all Subtree: dc=mkosek-fedora20,dc=test ACI target DN: cn=compat,dc=mkosek-fedora20,dc=test It is much easier to manipulate than ACI added via ldapmodify. I see you filed a bug on the missing CLI option. That's why I did the ACI, because I couldn't demonstrate how to add this ACI on the CLI. I hadn't gotten around to doing that last night. rob Right. Surprisingly, the option was available in Web UI, thus the Web UI screenshot I attached to the thread :) But we have the CLI option fixed already, will be part of FreeIPA 4.0.2 which will be released very soon. 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
[Freeipa-users] replication - original master not replicating
Greetings, I'm running freeipa 3.0 with multimaster between 3 machines. The first system, the original installation machine and thus the keepers of the CA, etc, is not replicating with the other two. The other two are fine. Additionally, the original machine is no longer using the freeIPA running on it for authentication services. Examples: I created a new user on the first machine using ipa user-add and the other two systems didn't pick it up (even after an overnight wait). So I thought it was not created. I then tried to create the user again but on #2 machine on the web gui. It refused saying the private group of that user already existed. It did not error about the username. So I went to #1 and deleted the user. Back to #2 to create the user and #3 picked it up within a minute. But #1 picked it up this time. From #1, running id on any user in the system returns a No such user. But when I go to the gui on #1, I can find users. The #1 system has files sss in nsswitch for passwd, shadow, group, services, netgroup as do #2 and #3. When I setup #2, I ran the ipa-ca-install on the generated file from the #1 machine. So I think #2 now has the CA for my department. When I tried to setup #3 by using #1 as the master, it would not connect/complete back to #1. I replicated from #2 and it worked. It's been several months (10+ or so) since I set up the #1 machine and #2 was about 2 days after it. I don't know if #1 always didn't use freeIPA for authentication or not. #1 and #2 are CentOS 6.5. #3 is CentOS 7 and freeIPA 3.3. I was concerned that the version mismatch would be an issue but it seems to work well between #2 and #3. Clearly, if I add a user now, I use #2 or #3. I can get by with not messing around with #1 and it's just for master CA needs. Oh. I have all three in DNS and #1 and #2 are DNS servers. #3 is in a separate network segment and exists to provide auth services in the (likely) event a network link goes down between that location and the main stack. -- Jim Kinney Senior System Administrator Department of BioMedical Informatics Emory University jimkin...@emory.edu 404.712.0300 bmi.emory.edu -- 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] Search Base issues
That worked, but having issues get it to work with the OSX Directory Utility. I'm wondering if it's because when you go against the OU normally it's returning more info about the user versus what's being returned from the compat view I'm going to experiment with the attributes it's returning and see if that's it. I'm also wondering why FreeIPA doesn't support multiple OU's natively, this would be so much easier with multiple OUs (one for my non-users and one for my users) On Wed, Sep 3, 2014 at 9:10 AM, Martin Kosek mko...@redhat.com wrote: On 09/03/2014 03:08 PM, Rob Crittenden wrote: Martin Kosek wrote: On 09/03/2014 09:02 AM, Martin Kosek wrote: In the meantime, you can use the workaround that Rob sent, you would just need to delete it again when the fix is in, so that the permissions do not step on each other. Actually, wait a minute. I think Rob's ACI example may be too wide, it may expose any attribute in the compat tree, including a potential userPassword. The ACI was on his custom cn=canlogin subtree, not all of cn=compat. As I see, it seems that slapi-nis plugin do not fortunately expose that, but it is safer to just list the attributes that one wants to display (this is also what we did in FreeIPA 4.0, no global wildcard allowing ACIs any more). I added a respective permission via Web UI (one part of it cannot be added via CLI, see https://fedorahosted.org/freeipa/ticket/4522) and compat tree now works for me. See attached example. Resulting permission shown in CLI: # ipa permission-show TEMPORARY - Read compat tree Permission name: TEMPORARY - Read compat tree Granted rights: read, search, compare Effective attributes: cn, description, gecos, gidnumber, homedirectory, loginshell, memberuid, objectclass, uid, uidnumber Bind rule type: all Subtree: dc=mkosek-fedora20,dc=test ACI target DN: cn=compat,dc=mkosek-fedora20,dc=test It is much easier to manipulate than ACI added via ldapmodify. I see you filed a bug on the missing CLI option. That's why I did the ACI, because I couldn't demonstrate how to add this ACI on the CLI. I hadn't gotten around to doing that last night. rob Right. Surprisingly, the option was available in Web UI, thus the Web UI screenshot I attached to the thread :) But we have the CLI option fixed already, will be part of FreeIPA 4.0.2 which will be released very soon. 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] Password expiration dates are different when being resetted by the (primary) admin and a different admin
Great! Btw +1 for running on IPA 3.3.3, it has much more to offer than RHEL/CentOS 6.x one. Martin On 09/03/2014 06:08 PM, Zip Ly wrote: @Martin Ah that explains everything. We were using centos 6.5 + ipa 3.0.0 Now with a new test setup centos 7 + ipa 3.3.3, it works just as we wanted. Thank all for the help! On Tue, Sep 2, 2014 at 5:19 PM, Martin Kosek mko...@redhat.com wrote: On 09/02/2014 10:42 AM, Zip Ly wrote: @Martin The second admin is my service account. I use this account to communicate with our webapplication (it uses keytab and post/curl json to ipa). I can add users without a problem. But when it comes to changing password, the password is expired immediately. I have only one password policy and that's the 'global_policy'. The --maxlife you mentioned only affect this policy. If I use this service account to change the user password, the policy is ignored just as stated in the ipa wiki. Even if I set the --maxlife to 200, if the password is being resetted by this first admin, then the expire date is set to 90 days or expired immediately by the second admin/service account. That's why I want to know how to change this 90 days and also apply it for the service account. What version of FreeIPA do you use? Maybe you are hitting https://fedorahosted.org/freeipa/ticket/3968 that we fixed in FreeIPA 3.3.3. 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] Password expiration dates are different when being resetted by the (primary) admin and a different admin
@Martin Ah that explains everything. We were using centos 6.5 + ipa 3.0.0 Now with a new test setup centos 7 + ipa 3.3.3, it works just as we wanted. Thank all for the help! On Tue, Sep 2, 2014 at 5:19 PM, Martin Kosek mko...@redhat.com wrote: On 09/02/2014 10:42 AM, Zip Ly wrote: @Martin The second admin is my service account. I use this account to communicate with our webapplication (it uses keytab and post/curl json to ipa). I can add users without a problem. But when it comes to changing password, the password is expired immediately. I have only one password policy and that's the 'global_policy'. The --maxlife you mentioned only affect this policy. If I use this service account to change the user password, the policy is ignored just as stated in the ipa wiki. Even if I set the --maxlife to 200, if the password is being resetted by this first admin, then the expire date is set to 90 days or expired immediately by the second admin/service account. That's why I want to know how to change this 90 days and also apply it for the service account. What version of FreeIPA do you use? Maybe you are hitting https://fedorahosted.org/freeipa/ticket/3968 that we fixed in FreeIPA 3.3.3. 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
[Freeipa-users] ipa user-find finds user but ipa user-del fails
user-find sees a user but user-del cannot remove it. What can I do? Thanks. Regards, Ron [root@ipa]# ipa user-find --login phys210e -- 1 user matched -- User login: phys210e First name: Testing Last name: Phys210 Home directory: /home2/phys210e Login shell: /bin/bash Email address: phys2...@phas.ubc.ca UID: 15010 GID: 15010 Account disabled: False Password: True Kerberos keys available: False Number of entries returned 1 [root@ipa]# ipa user-del phys210e --continue --- Deleted user --- Failed to remove: phys210e [root@ipa]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.5 (Santiago) [root@ipa]# rpm -qa|grep ipa; rpm -qa|grep 389 ipa-pki-ca-theme-9.0.3-7.el6.noarch ipa-admintools-3.0.0-37.el6.i686 ipa-pki-common-theme-9.0.3-7.el6.noarch libipa_hbac-1.9.2-129.el6_5.4.i686 ipa-server-selinux-3.0.0-37.el6.i686 python-iniparse-0.3.1-2.1.el6.noarch libipa_hbac-python-1.9.2-129.el6_5.4.i686 ipa-server-3.0.0-37.el6.i686 ipa-python-3.0.0-37.el6.i686 ipa-client-3.0.0-37.el6.i686 389-ds-base-libs-1.2.11.15-33.el6_5.i686 389-ds-base-1.2.11.15-33.el6_5.i686 -- Ron Parachoniak Systems Manager, Department of Physics Astronomy University of British Columbia, Vancouver, B.C. V6T 1Z1 Phone: (604) 838-6437 0xA1D0F827.asc Description: application/pgp-keys -- 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 user-find finds user but ipa user-del fails
Can you check /var/log/dirsrv/slapd-YOUR-REALM/access, search for the DEL operation and see what was the error code that DS gave when it refused to delete the user? Martin On 09/03/2014 06:18 PM, Ron wrote: user-find sees a user but user-del cannot remove it. What can I do? Thanks. Regards, Ron [root@ipa]# ipa user-find --login phys210e -- 1 user matched -- User login: phys210e First name: Testing Last name: Phys210 Home directory: /home2/phys210e Login shell: /bin/bash Email address: phys2...@phas.ubc.ca UID: 15010 GID: 15010 Account disabled: False Password: True Kerberos keys available: False Number of entries returned 1 [root@ipa]# ipa user-del phys210e --continue --- Deleted user --- Failed to remove: phys210e [root@ipa]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.5 (Santiago) [root@ipa]# rpm -qa|grep ipa; rpm -qa|grep 389 ipa-pki-ca-theme-9.0.3-7.el6.noarch ipa-admintools-3.0.0-37.el6.i686 ipa-pki-common-theme-9.0.3-7.el6.noarch libipa_hbac-1.9.2-129.el6_5.4.i686 ipa-server-selinux-3.0.0-37.el6.i686 python-iniparse-0.3.1-2.1.el6.noarch libipa_hbac-python-1.9.2-129.el6_5.4.i686 ipa-server-3.0.0-37.el6.i686 ipa-python-3.0.0-37.el6.i686 ipa-client-3.0.0-37.el6.i686 389-ds-base-libs-1.2.11.15-33.el6_5.i686 389-ds-base-1.2.11.15-33.el6_5.i686 -- 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 user-find finds user but ipa user-del fails
Martin Kosek wrote: Can you check /var/log/dirsrv/slapd-YOUR-REALM/access, search for the DEL operation and see what was the error code that DS gave when it refused to delete the user? Were I to guess the issue is that this is a replication conflict entry. If you do: # ipa user-show --all --raw phys210e |grep dn: It will likely begin with nsuniqueid=hex, ... The reason it can be found and not deleted is we create the dn to be removed, we don't search for it. So the user uid=phys210e,cn=users,... etc doesn't exist but the user nsuniqueid=hex ... does. You'll need to use ldapmodify or ldapdelete to remove the entry though I'd check your other masters to see what the state of the user is there. rob Martin On 09/03/2014 06:18 PM, Ron wrote: user-find sees a user but user-del cannot remove it. What can I do? Thanks. Regards, Ron [root@ipa]# ipa user-find --login phys210e -- 1 user matched -- User login: phys210e First name: Testing Last name: Phys210 Home directory: /home2/phys210e Login shell: /bin/bash Email address: phys2...@phas.ubc.ca UID: 15010 GID: 15010 Account disabled: False Password: True Kerberos keys available: False Number of entries returned 1 [root@ipa]# ipa user-del phys210e --continue --- Deleted user --- Failed to remove: phys210e [root@ipa]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.5 (Santiago) [root@ipa]# rpm -qa|grep ipa; rpm -qa|grep 389 ipa-pki-ca-theme-9.0.3-7.el6.noarch ipa-admintools-3.0.0-37.el6.i686 ipa-pki-common-theme-9.0.3-7.el6.noarch libipa_hbac-1.9.2-129.el6_5.4.i686 ipa-server-selinux-3.0.0-37.el6.i686 python-iniparse-0.3.1-2.1.el6.noarch libipa_hbac-python-1.9.2-129.el6_5.4.i686 ipa-server-3.0.0-37.el6.i686 ipa-python-3.0.0-37.el6.i686 ipa-client-3.0.0-37.el6.i686 389-ds-base-libs-1.2.11.15-33.el6_5.i686 389-ds-base-1.2.11.15-33.el6_5.i686 -- 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] Search Base issues
Chris Whittle wrote: That worked, but having issues get it to work with the OSX Directory Utility. I'm wondering if it's because when you go against the OU normally it's returning more info about the user versus what's being returned from the compat view I'm going to experiment with the attributes it's returning and see if that's it. I'm also wondering why FreeIPA doesn't support multiple OU's natively, this would be so much easier with multiple OUs (one for my non-users and one for my users) Because they are so very often used really, really poorly, resulting in having to move entries around a lot with no real technical reason behind it. Think about the number of times an IT department gets renamed, oops, today they are called Global Support Services, oh no, didn't you hear, now they are ... Each one requiring an entire subtree move. Where the users exist in LDAP does not generally need to reflect the organizational structure. Your case is a bit different from most, where you want to host two completely separate kinds of users. rob On Wed, Sep 3, 2014 at 9:10 AM, Martin Kosek mko...@redhat.com mailto:mko...@redhat.com wrote: On 09/03/2014 03:08 PM, Rob Crittenden wrote: Martin Kosek wrote: On 09/03/2014 09:02 AM, Martin Kosek wrote: In the meantime, you can use the workaround that Rob sent, you would just need to delete it again when the fix is in, so that the permissions do not step on each other. Actually, wait a minute. I think Rob's ACI example may be too wide, it may expose any attribute in the compat tree, including a potential userPassword. The ACI was on his custom cn=canlogin subtree, not all of cn=compat. As I see, it seems that slapi-nis plugin do not fortunately expose that, but it is safer to just list the attributes that one wants to display (this is also what we did in FreeIPA 4.0, no global wildcard allowing ACIs any more). I added a respective permission via Web UI (one part of it cannot be added via CLI, see https://fedorahosted.org/freeipa/ticket/4522) and compat tree now works for me. See attached example. Resulting permission shown in CLI: # ipa permission-show TEMPORARY - Read compat tree Permission name: TEMPORARY - Read compat tree Granted rights: read, search, compare Effective attributes: cn, description, gecos, gidnumber, homedirectory, loginshell, memberuid, objectclass, uid, uidnumber Bind rule type: all Subtree: dc=mkosek-fedora20,dc=test ACI target DN: cn=compat,dc=mkosek-fedora20,dc=test It is much easier to manipulate than ACI added via ldapmodify. I see you filed a bug on the missing CLI option. That's why I did the ACI, because I couldn't demonstrate how to add this ACI on the CLI. I hadn't gotten around to doing that last night. rob Right. Surprisingly, the option was available in Web UI, thus the Web UI screenshot I attached to the thread :) But we have the CLI option fixed already, will be part of FreeIPA 4.0.2 which will be released very soon. 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] replication - original master not replicating
Jim Kinney wrote: Greetings, I'm running freeipa 3.0 with multimaster between 3 machines. The first system, the original installation machine and thus the keepers of the CA, etc, is not replicating with the other two. The other two are fine. Additionally, the original machine is no longer using the freeIPA running on it for authentication services. Examples: I created a new user on the first machine using ipa user-add and the other two systems didn't pick it up (even after an overnight wait). So I thought it was not created. I then tried to create the user again but on #2 machine on the web gui. It refused saying the private group of that user already existed. It did not error about the username. So I went to #1 and deleted the user. Back to #2 to create the user and #3 picked it up within a minute. But #1 picked it up this time. From #1, running id on any user in the system returns a No such user. But when I go to the gui on #1, I can find users. The #1 system has files sss in nsswitch for passwd, shadow, group, services, netgroup as do #2 and #3. When I setup #2, I ran the ipa-ca-install on the generated file from the #1 machine. So I think #2 now has the CA for my department. When I tried to setup #3 by using #1 as the master, it would not connect/complete back to #1. I replicated from #2 and it worked. It's been several months (10+ or so) since I set up the #1 machine and #2 was about 2 days after it. I don't know if #1 always didn't use freeIPA for authentication or not. #1 and #2 are CentOS 6.5. #3 is CentOS 7 and freeIPA 3.3. I was concerned that the version mismatch would be an issue but it seems to work well between #2 and #3. Clearly, if I add a user now, I use #2 or #3. I can get by with not messing around with #1 and it's just for master CA needs. Oh. I have all three in DNS and #1 and #2 are DNS servers. #3 is in a separate network segment and exists to provide auth services in the (likely) event a network link goes down between that location and the main stack. On each master I'd run: # ipa-replica-manage list -v `hostname` This will give you the replication status on each. 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] replication - original master not replicating
On Wed, 2014-09-03 at 13:48 -0400, Rob Crittenden wrote: Jim Kinney wrote: Greetings, I'm running freeipa 3.0 with multimaster between 3 machines. The first system, the original installation machine and thus the keepers of the CA, etc, is not replicating with the other two. The other two are fine. Additionally, the original machine is no longer using the freeIPA running on it for authentication services. Examples: I created a new user on the first machine using ipa user-add and the other two systems didn't pick it up (even after an overnight wait). So I thought it was not created. I then tried to create the user again but on #2 machine on the web gui. It refused saying the private group of that user already existed. It did not error about the username. So I went to #1 and deleted the user. Back to #2 to create the user and #3 picked it up within a minute. But #1 picked it up this time. From #1, running id on any user in the system returns a No such user. But when I go to the gui on #1, I can find users. The #1 system has files sss in nsswitch for passwd, shadow, group, services, netgroup as do #2 and #3. When I setup #2, I ran the ipa-ca-install on the generated file from the #1 machine. So I think #2 now has the CA for my department. When I tried to setup #3 by using #1 as the master, it would not connect/complete back to #1. I replicated from #2 and it worked. It's been several months (10+ or so) since I set up the #1 machine and #2 was about 2 days after it. I don't know if #1 always didn't use freeIPA for authentication or not. #1 and #2 are CentOS 6.5. #3 is CentOS 7 and freeIPA 3.3. I was concerned that the version mismatch would be an issue but it seems to work well between #2 and #3. Clearly, if I add a user now, I use #2 or #3. I can get by with not messing around with #1 and it's just for master CA needs. Oh. I have all three in DNS and #1 and #2 are DNS servers. #3 is in a separate network segment and exists to provide auth services in the (likely) event a network link goes down between that location and the main stack. On each master I'd run: # ipa-replica-manage list -v `hostname` This will give you the replication status on each. rob OK. Interesting results. #1 is vinz, #2 is prod01, #3 is beast : [root@vinz etc]# ipa-replica-manage list -v `hostname` beast.cci.emory.edu: replica last init status: None last init ended: None last update status: 32 - LDAP error: No such object last update ended: None prod01.cci.emory.edu: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2014-09-03 17:53:07+00:00 vinz.cci.emory.edu: replica last init status: None last init ended: None last update status: -1 Incremental update has failed and requires administrator actionLDAP error: Can't contact LDAP server last update ended: None [root@prod01 ~]# ipa-replica-manage list -v `hostname` beast.cci.emory.edu: replica last init status: 0 Total update succeeded last init ended: 2014-08-20 15:58:38+00:00 last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2014-09-03 17:54:20+00:00 vinz.cci.emory.edu: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2014-09-03 17:54:20+00:00 [root@beast ~]# ipa-replica-manage list -v `hostname` prod01.cci.emory.edu: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update started last update ended: None vinz.cci.emory.edu: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update started last update ended: None It looks like vinz is trying to replicate to itself. -- Jim Kinney Senior System Administrator Department of BioMedical Informatics Emory University jimkin...@emory.edu 404.712.0300 bmi.emory.edu -- 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] Search Base issues
Thanks Rob for the explanation! I think I have it working, I just have to test a machine and verify. On Wed, Sep 3, 2014 at 12:47 PM, Rob Crittenden rcrit...@redhat.com wrote: Chris Whittle wrote: That worked, but having issues get it to work with the OSX Directory Utility. I'm wondering if it's because when you go against the OU normally it's returning more info about the user versus what's being returned from the compat view I'm going to experiment with the attributes it's returning and see if that's it. I'm also wondering why FreeIPA doesn't support multiple OU's natively, this would be so much easier with multiple OUs (one for my non-users and one for my users) Because they are so very often used really, really poorly, resulting in having to move entries around a lot with no real technical reason behind it. Think about the number of times an IT department gets renamed, oops, today they are called Global Support Services, oh no, didn't you hear, now they are ... Each one requiring an entire subtree move. Where the users exist in LDAP does not generally need to reflect the organizational structure. Your case is a bit different from most, where you want to host two completely separate kinds of users. rob On Wed, Sep 3, 2014 at 9:10 AM, Martin Kosek mko...@redhat.com mailto:mko...@redhat.com wrote: On 09/03/2014 03:08 PM, Rob Crittenden wrote: Martin Kosek wrote: On 09/03/2014 09:02 AM, Martin Kosek wrote: In the meantime, you can use the workaround that Rob sent, you would just need to delete it again when the fix is in, so that the permissions do not step on each other. Actually, wait a minute. I think Rob's ACI example may be too wide, it may expose any attribute in the compat tree, including a potential userPassword. The ACI was on his custom cn=canlogin subtree, not all of cn=compat. As I see, it seems that slapi-nis plugin do not fortunately expose that, but it is safer to just list the attributes that one wants to display (this is also what we did in FreeIPA 4.0, no global wildcard allowing ACIs any more). I added a respective permission via Web UI (one part of it cannot be added via CLI, see https://fedorahosted.org/freeipa/ticket/4522) and compat tree now works for me. See attached example. Resulting permission shown in CLI: # ipa permission-show TEMPORARY - Read compat tree Permission name: TEMPORARY - Read compat tree Granted rights: read, search, compare Effective attributes: cn, description, gecos, gidnumber, homedirectory, loginshell, memberuid, objectclass, uid, uidnumber Bind rule type: all Subtree: dc=mkosek-fedora20,dc=test ACI target DN: cn=compat,dc=mkosek-fedora20,dc=test It is much easier to manipulate than ACI added via ldapmodify. I see you filed a bug on the missing CLI option. That's why I did the ACI, because I couldn't demonstrate how to add this ACI on the CLI. I hadn't gotten around to doing that last night. rob Right. Surprisingly, the option was available in Web UI, thus the Web UI screenshot I attached to the thread :) But we have the CLI option fixed already, will be part of FreeIPA 4.0.2 which will be released very soon. 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] ipa user-find finds user but ipa user-del fails
Here is what is in the /var/log/dirsrv/slapd-YOUR-REALM/access... logfile: conn=17342 fd=86 slot=86 connection from 142.103.xxx.xx to 142.103.xxx.xx conn=17342 op=0 BIND dn= method=sasl version=3 mech=GSSAPI conn=17342 op=0 RESULT err=14 tag=97 nentries=0 etime=1, SASL bind in progress conn=17342 op=1 BIND dn= method=sasl version=3 mech=GSSAPI conn=17342 op=1 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress conn=17342 op=2 BIND dn= method=sasl version=3 mech=GSSAPI conn=17342 op=2 RESULT err=0 tag=97 nentries=0 etime=0 dn=uid=admin,cn=users,cn=accounts,dc=pxxx,dc=abc,dc=ca conn=17342 op=3 SRCH base=cn=ipaconfig,cn=etc,dc=pxxx,dc=abc,dc=ca scope=0 filter=(objectClass=*) attrs=ALL conn=17342 op=3 RESULT err=0 tag=101 nentries=1 etime=0 conn=17342 op=4 SRCH base=cn=users,cn=accounts,dc=pxxx,dc=abc,dc=ca scope=1 filter=((objectClass=posixaccount)(memberOf=cn=admins,cn=groups,cn=accounts,dc=pxxx,dc=abc,dc=ca)) attrs=telephoneNumber sshpubkeyfp uid title loginShell uidNumber gidNumber sn homeDirectory mail givenName nsAccountLock conn=17342 op=4 RESULT err=0 tag=101 nentries=1 etime=0 conn=17342 op=5 SRCH base=uid=admin,cn=users,cn=accounts,dc=pxxx,dc=abc,dc=ca scope=0 filter=(userPassword=*) attrs=userPassword conn=17342 op=5 RESULT err=0 tag=101 nentries=1 etime=0 conn=17342 op=6 SRCH base=uid=admin,cn=users,cn=accounts,dc=pxxx,dc=abc,dc=ca scope=0 filter=(krbPrincipalKey=*) attrs=krbPrincipalKey conn=17342 op=6 RESULT err=0 tag=101 nentries=1 etime=0 conn=17342 op=7 SRCH base=uid=admin,cn=users,cn=accounts,dc=pxxx,dc=abc,dc=ca scope=0 filter=(objectClass=*) attrs=ipaSshPubKey conn=17342 op=7 RESULT err=0 tag=101 nentries=1 etime=0 conn=17342 op=8 DEL dn=uid=phys210e,cn=users,cn=accounts,dc=pxxx,dc=abc,dc=ca conn=17342 op=8 RESULT err=32 tag=107 nentries=0 etime=0 conn=17342 op=9 UNBIND conn=17342 op=9 fd=86 closed - U1 And here is the result of the user-show command: [root@ipa slapd-pxxx-abc-CA]# ipa user-find --login phys210e -- 1 user matched -- User login: phys210e First name: Testing Last name: Phys210 Home directory: /home2/phys210e Login shell: /bin/bash Email address: phys2...@pxxx.abc.ca UID: 15010 GID: 15010 Account disabled: False Password: True Kerberos keys available: False Number of entries returned 1 [root@ipa slapd-pxxx-abc-CA]# ipa user-show --all --raw phys210e ipa: ERROR: phys210e: user not found On 09/03/2014 10:43 AM, Rob Crittenden wrote: Martin Kosek wrote: Can you check /var/log/dirsrv/slapd-YOUR-REALM/access, search for the DEL operation and see what was the error code that DS gave when it refused to delete the user? Were I to guess the issue is that this is a replication conflict entry. If you do: # ipa user-show --all --raw phys210e |grep dn: It will likely begin with nsuniqueid=hex, ... The reason it can be found and not deleted is we create the dn to be removed, we don't search for it. So the user uid=phys210e,cn=users,... etc doesn't exist but the user nsuniqueid=hex ... does. You'll need to use ldapmodify or ldapdelete to remove the entry though I'd check your other masters to see what the state of the user is there. rob Martin On 09/03/2014 06:18 PM, Ron wrote: user-find sees a user but user-del cannot remove it. What can I do? Thanks. Regards, Ron [root@ipa]# ipa user-find --login phys210e -- 1 user matched -- User login: phys210e First name: Testing Last name: Phys210 Home directory: /home2/phys210e Login shell: /bin/bash Email address: phys2...@pxxx.abc.ca UID: 15010 GID: 15010 Account disabled: False Password: True Kerberos keys available: False Number of entries returned 1 [root@ipa]# ipa user-del phys210e --continue --- Deleted user --- Failed to remove: phys210e [root@ipa]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.5 (Santiago) [root@ipa]# rpm -qa|grep ipa; rpm -qa|grep 389 ipa-pki-ca-theme-9.0.3-7.el6.noarch ipa-admintools-3.0.0-37.el6.i686 ipa-pki-common-theme-9.0.3-7.el6.noarch libipa_hbac-1.9.2-129.el6_5.4.i686 ipa-server-selinux-3.0.0-37.el6.i686 python-iniparse-0.3.1-2.1.el6.noarch libipa_hbac-python-1.9.2-129.el6_5.4.i686 ipa-server-3.0.0-37.el6.i686 ipa-python-3.0.0-37.el6.i686 ipa-client-3.0.0-37.el6.i686 389-ds-base-libs-1.2.11.15-33.el6_5.i686 389-ds-base-1.2.11.15-33.el6_5.i686 -- Ron Parachoniak Systems Manager, Department of Physics Astronomy University of British Columbia, Vancouver, B.C. V6T 1Z1 Phone: (604) 838-6437 0xA1D0F827.asc Description: application/pgp-keys -- 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] Cert Renewal
Ott, Dennis wrote: I may need a little more direction here. The output from getcert list-cas does not contain the string 'ca_renewal'. What does this indicate? I don't have a 2 - 3 updated server handy so I'm going on best guesses from reading the code. It is probably ok. You really just need to be sure to have a CA that has a submit script of: dogtag-ipa-retrieve-agent-submit and one for dogtag-ipa-renew-agent What is the output from list-cas? The way that CA renewal works is this: - One CA, the first install by default, is marked as the CA renewal master. The only thing that distinguishes this master is the way the renewal scripts are configured. This CA does the actual renewal of the certificates and pushes the resulting public certs into a shared space in the IPA LDAP tree - The other CA's monitor this area, via those two dotag-ipa-* scripts, and fetch and install updated certificates when one is available. When a cert is in CA_WORKING state it means that an update should be available but isn't in the shared tree, so certmonger will try again in a few hours. Assuming that certmonger is configured properly then it should just be a matter of getting the right certs added to the LDAP tree. rob -Original Message- From: Rob Crittenden [mailto:rcrit...@redhat.com] Sent: Tuesday, August 26, 2014 3:53 PM To: Ott, Dennis; Freeipa-users@redhat.com Subject: Re: [Freeipa-users] Cert Renewal Ott, Dennis wrote: No services are currently running on the replica (and I am hesitant to start them) but, my recollection is that I did the replica server installation with the --setup-ca option. Also, there are /var/lib/dirsrv/slapd-PKI-IPA/ and /etc/pki-ca/ directories in place on the replica. ipa-getcert list shows all certs with a status of: CA_UNREACHABLE (but then, the service is down. The master also gave this status, even with the service running, until I followed the cert renewal procedure.) So, with the replica running a CA, should I follow the same procedure that I used on the master? Anything else to look out for? No, the procedure is slightly different on the replica. You need to start by ensuring that certmonger has a CA type for renewal: # getcert list-cas Look for ca_renewal Check the CA subsystem certs to see how they are configured. The CA should be dogtag-ipa-retrieve-agent-submit for auditSigningCert cert-pki-ca, ocspSigningCert cert-pki-ca and subsystemCert cert-pki-ca and a pre-save command of stop_pkicad and a post-save a restart_pkicad PKI-IPA The agent cert, ipaCert, should be using dogtag-ipa-retrieve-agent-submit, a blank pre-save command and a post-save command of restart_httpd. rob Thanks. Dennis -Original Message- From: Rob Crittenden [mailto:rcrit...@redhat.com] Sent: Monday, August 25, 2014 6:37 PM To: Ott, Dennis; freeipa-users@redhat.com Subject: Re: [Freeipa-users] Cert Renewal Ott, Dennis wrote: I have an IPA setup, one master, one replica; originally installed as v 2.x and later updated to v 3.0. For whatever reasons, the certs did not automatically renew and the services would no longer start. I updated the certs manually on the master using the procedure shown at: http://www.freeipa.org/page/IPA_2x_Certificate_Renewal The master is now functioning properly. At this point, the IPA service is still stopped on the replica. I hesitate to start it for concern it could interfere with the now-working master. What would be the recommended method for returning the replica to service? It depends on whether the replica. Does it also run a CA? If not then you can try restarting the certmonger service. This should cause it to fetch new certificates for the other IPA servers. ipa-getcert list will show you the status, wait until they are all MONITORING. Once that works then you can safely restart the world. Any changes on the master will be replicated out, and vice versa. 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 user-find finds user but ipa user-del fails
Ron wrote: And here is the result of the user-show command: [root@ipa slapd-pxxx-abc-CA]# ipa user-show --all --raw phys210e ipa: ERROR: phys210e: user not found Sorry, thinko on my part. Do ipa user-find --all --raw --login phys210e user-show is going to have the same issue as user-delete. rob On 09/03/2014 10:43 AM, Rob Crittenden wrote: Martin Kosek wrote: Can you check /var/log/dirsrv/slapd-YOUR-REALM/access, search for the DEL operation and see what was the error code that DS gave when it refused to delete the user? Were I to guess the issue is that this is a replication conflict entry. If you do: # ipa user-show --all --raw phys210e |grep dn: It will likely begin with nsuniqueid=hex, ... The reason it can be found and not deleted is we create the dn to be removed, we don't search for it. So the user uid=phys210e,cn=users,... etc doesn't exist but the user nsuniqueid=hex ... does. You'll need to use ldapmodify or ldapdelete to remove the entry though I'd check your other masters to see what the state of the user is there. rob Martin On 09/03/2014 06:18 PM, Ron wrote: user-find sees a user but user-del cannot remove it. What can I do? Thanks. Regards, Ron [root@ipa]# ipa user-find --login phys210e -- 1 user matched -- User login: phys210e First name: Testing Last name: Phys210 Home directory: /home2/phys210e Login shell: /bin/bash Email address: phys2...@pxxx.abc.ca UID: 15010 GID: 15010 Account disabled: False Password: True Kerberos keys available: False Number of entries returned 1 [root@ipa]# ipa user-del phys210e --continue --- Deleted user --- Failed to remove: phys210e [root@ipa]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.5 (Santiago) [root@ipa]# rpm -qa|grep ipa; rpm -qa|grep 389 ipa-pki-ca-theme-9.0.3-7.el6.noarch ipa-admintools-3.0.0-37.el6.i686 ipa-pki-common-theme-9.0.3-7.el6.noarch libipa_hbac-1.9.2-129.el6_5.4.i686 ipa-server-selinux-3.0.0-37.el6.i686 python-iniparse-0.3.1-2.1.el6.noarch libipa_hbac-python-1.9.2-129.el6_5.4.i686 ipa-server-3.0.0-37.el6.i686 ipa-python-3.0.0-37.el6.i686 ipa-client-3.0.0-37.el6.i686 389-ds-base-libs-1.2.11.15-33.el6_5.i686 389-ds-base-1.2.11.15-33.el6_5.i686 -- Ron Parachoniak Systems Manager, Department of Physics Astronomy University of British Columbia, Vancouver, B.C. V6T 1Z1 Phone: (604) 838-6437 -- 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 user-find finds user but ipa user-del fails
[root@ipa]# ipa user-find --all --raw --login phys210e | grep dn: dn: nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=,dc=abc,dc=ca On 09/03/2014 12:26 PM, Rob Crittenden wrote: Ron wrote: And here is the result of the user-show command: [root@ipa slapd-pxxx-abc-CA]# ipa user-show --all --raw phys210e ipa: ERROR: phys210e: user not found Sorry, thinko on my part. Do ipa user-find --all --raw --login phys210e user-show is going to have the same issue as user-delete. rob On 09/03/2014 10:43 AM, Rob Crittenden wrote: Martin Kosek wrote: Can you check /var/log/dirsrv/slapd-YOUR-REALM/access, search for the DEL operation and see what was the error code that DS gave when it refused to delete the user? Were I to guess the issue is that this is a replication conflict entry. If you do: # ipa user-show --all --raw phys210e |grep dn: It will likely begin with nsuniqueid=hex, ... The reason it can be found and not deleted is we create the dn to be removed, we don't search for it. So the user uid=phys210e,cn=users,... etc doesn't exist but the user nsuniqueid=hex ... does. You'll need to use ldapmodify or ldapdelete to remove the entry though I'd check your other masters to see what the state of the user is there. rob Martin On 09/03/2014 06:18 PM, Ron wrote: user-find sees a user but user-del cannot remove it. What can I do? Thanks. Regards, Ron [root@ipa]# ipa user-find --login phys210e -- 1 user matched -- User login: phys210e First name: Testing Last name: Phys210 Home directory: /home2/phys210e Login shell: /bin/bash Email address: phys2...@pxxx.abc.ca UID: 15010 GID: 15010 Account disabled: False Password: True Kerberos keys available: False Number of entries returned 1 [root@ipa]# ipa user-del phys210e --continue --- Deleted user --- Failed to remove: phys210e [root@ipa]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.5 (Santiago) [root@ipa]# rpm -qa|grep ipa; rpm -qa|grep 389 ipa-pki-ca-theme-9.0.3-7.el6.noarch ipa-admintools-3.0.0-37.el6.i686 ipa-pki-common-theme-9.0.3-7.el6.noarch libipa_hbac-1.9.2-129.el6_5.4.i686 ipa-server-selinux-3.0.0-37.el6.i686 python-iniparse-0.3.1-2.1.el6.noarch libipa_hbac-python-1.9.2-129.el6_5.4.i686 ipa-server-3.0.0-37.el6.i686 ipa-python-3.0.0-37.el6.i686 ipa-client-3.0.0-37.el6.i686 389-ds-base-libs-1.2.11.15-33.el6_5.i686 389-ds-base-1.2.11.15-33.el6_5.i686 -- Ron Parachoniak Systems Manager, Department of Physics Astronomy University of British Columbia, Vancouver, B.C. V6T 1Z1 Phone: (604) 838-6437 -- Ron Parachoniak Systems Manager, Department of Physics Astronomy University of British Columbia, Vancouver, B.C. V6T 1Z1 Phone: (604) 838-6437 0xA1D0F827.asc Description: application/pgp-keys -- 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] Search Base issues
Success here is my LDIF if anyone needs to do this with a MAC
dn: cn=Mac Users, cn=Schema Compatibility, cn=plugins, cn=config
objectClass: top
objectClass: extensibleObject
cn: Mac Users
schema-compat-search-base: cn=users,cn=accounts,dc=DOMAIN,dc=com
schema-compat-search-filter:
((objectClass=posixaccount)(memberOf=cn=canlogin,cn=groups,cn=accounts,dc
DOMAIN,dc=com))
schema-compat-container-group: cn=compat,dc=DOMAIN,dc=com
schema-compat-container-rdn: cn=canlogin
schema-compat-entry-rdn: cn=%{cn}
schema-compat-entry-attribute: objectclass=inetOrgPerson
schema-compat-entry-attribute: objectclass=posixAccount
schema-compat-entry-attribute: gecos=%{cn}
schema-compat-entry-attribute: cn=%{cn}
schema-compat-entry-attribute: uid=%{uid}
schema-compat-entry-attribute: uidNumber=%{uidNumber}
schema-compat-entry-attribute: gidNumber=%{gidNumber}
schema-compat-entry-attribute: loginShell=%{loginShell}
schema-compat-entry-attribute: homeDirectory=%{homeDirectory}
On Wed, Sep 3, 2014 at 1:04 PM, Chris Whittle cwhi...@gmail.com wrote:
Thanks Rob for the explanation!
I think I have it working, I just have to test a machine and verify.
On Wed, Sep 3, 2014 at 12:47 PM, Rob Crittenden rcrit...@redhat.com
wrote:
Chris Whittle wrote:
That worked, but having issues get it to work with the OSX Directory
Utility.
I'm wondering if it's because when you go against the OU normally it's
returning more info about the user versus what's being returned from the
compat view I'm going to experiment with the attributes it's returning
and see if that's it.
I'm also wondering why FreeIPA doesn't support multiple OU's natively,
this would be so much easier with multiple OUs (one for my non-users and
one for my users)
Because they are so very often used really, really poorly, resulting in
having to move entries around a lot with no real technical reason behind
it. Think about the number of times an IT department gets renamed, oops,
today they are called Global Support Services, oh no, didn't you hear,
now they are ... Each one requiring an entire subtree move. Where the
users exist in LDAP does not generally need to reflect the
organizational structure.
Your case is a bit different from most, where you want to host two
completely separate kinds of users.
rob
On Wed, Sep 3, 2014 at 9:10 AM, Martin Kosek mko...@redhat.com
mailto:mko...@redhat.com wrote:
On 09/03/2014 03:08 PM, Rob Crittenden wrote:
Martin Kosek wrote:
On 09/03/2014 09:02 AM, Martin Kosek wrote:
In the meantime, you can use the workaround that Rob sent, you
would just need
to delete it again when the fix is in, so that the permissions
do not step on
each other.
Actually, wait a minute. I think Rob's ACI example may be too
wide, it may
expose any attribute in the compat tree, including a potential
userPassword.
The ACI was on his custom cn=canlogin subtree, not all of
cn=compat.
As I see, it seems that slapi-nis plugin do not fortunately
expose that, but it
is safer to just list the attributes that one wants to display
(this is also
what we did in FreeIPA 4.0, no global wildcard allowing ACIs any
more).
I added a respective permission via Web UI (one part of it cannot
be added via
CLI, see https://fedorahosted.org/freeipa/ticket/4522) and
compat
tree now
works for me. See attached example.
Resulting permission shown in CLI:
# ipa permission-show TEMPORARY - Read compat tree
Permission name: TEMPORARY - Read compat tree
Granted rights: read, search, compare
Effective attributes: cn, description, gecos, gidnumber,
homedirectory,
loginshell, memberuid,
objectclass, uid, uidnumber
Bind rule type: all
Subtree: dc=mkosek-fedora20,dc=test
ACI target DN: cn=compat,dc=mkosek-fedora20,dc=test
It is much easier to manipulate than ACI added via ldapmodify.
I see you filed a bug on the missing CLI option. That's why I did
the
ACI, because I couldn't demonstrate how to add this ACI on the
CLI. I
hadn't gotten around to doing that last night.
rob
Right. Surprisingly, the option was available in Web UI, thus the
Web UI
screenshot I attached to the thread :) But we have the CLI option
fixed
already, will be part of FreeIPA 4.0.2 which will be released very
soon.
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] ipa user-find finds user but ipa user-del fails
By the way, all three replica servers show the same: [root@ipa]# ipa user-find --all --raw --login phys210e | grep dn: dn: nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=,dc=abc,dc=ca [root@ipa01]# ipa user-find --all --raw --login phys210e | grep dn: dn: nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=,dc=abc,dc=ca [root@ipa02]# ipa user-find --all --raw --login phys210e | grep dn: dn: nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=,dc=abc,dc=ca On 09/03/2014 12:26 PM, Rob Crittenden wrote: Ron wrote: And here is the result of the user-show command: [root@ipa slapd-pxxx-abc-CA]# ipa user-show --all --raw phys210e ipa: ERROR: phys210e: user not found Sorry, thinko on my part. Do ipa user-find --all --raw --login phys210e user-show is going to have the same issue as user-delete. rob On 09/03/2014 10:43 AM, Rob Crittenden wrote: Martin Kosek wrote: Can you check /var/log/dirsrv/slapd-YOUR-REALM/access, search for the DEL operation and see what was the error code that DS gave when it refused to delete the user? Were I to guess the issue is that this is a replication conflict entry. If you do: # ipa user-show --all --raw phys210e |grep dn: It will likely begin with nsuniqueid=hex, ... The reason it can be found and not deleted is we create the dn to be removed, we don't search for it. So the user uid=phys210e,cn=users,... etc doesn't exist but the user nsuniqueid=hex ... does. You'll need to use ldapmodify or ldapdelete to remove the entry though I'd check your other masters to see what the state of the user is there. rob Martin On 09/03/2014 06:18 PM, Ron wrote: user-find sees a user but user-del cannot remove it. What can I do? Thanks. Regards, Ron [root@ipa]# ipa user-find --login phys210e -- 1 user matched -- User login: phys210e First name: Testing Last name: Phys210 Home directory: /home2/phys210e Login shell: /bin/bash Email address: phys2...@pxxx.abc.ca UID: 15010 GID: 15010 Account disabled: False Password: True Kerberos keys available: False Number of entries returned 1 [root@ipa]# ipa user-del phys210e --continue --- Deleted user --- Failed to remove: phys210e [root@ipa]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.5 (Santiago) [root@ipa]# rpm -qa|grep ipa; rpm -qa|grep 389 ipa-pki-ca-theme-9.0.3-7.el6.noarch ipa-admintools-3.0.0-37.el6.i686 ipa-pki-common-theme-9.0.3-7.el6.noarch libipa_hbac-1.9.2-129.el6_5.4.i686 ipa-server-selinux-3.0.0-37.el6.i686 python-iniparse-0.3.1-2.1.el6.noarch libipa_hbac-python-1.9.2-129.el6_5.4.i686 ipa-server-3.0.0-37.el6.i686 ipa-python-3.0.0-37.el6.i686 ipa-client-3.0.0-37.el6.i686 389-ds-base-libs-1.2.11.15-33.el6_5.i686 389-ds-base-1.2.11.15-33.el6_5.i686 -- Ron Parachoniak Systems Manager, Department of Physics Astronomy University of British Columbia, Vancouver, B.C. V6T 1Z1 Phone: (604) 838-6437 -- Ron Parachoniak Systems Manager, Department of Physics Astronomy University of British Columbia, Vancouver, B.C. V6T 1Z1 Phone: (604) 838-6437 -- 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 user-find finds user but ipa user-del fails
On 09/03/2014 02:44 PM, Ron wrote: By the way, all three replica servers show the same: [root@ipa]# ipa user-find --all --raw --login phys210e | grep dn: dn: nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=,dc=abc,dc=ca [root@ipa01]# ipa user-find --all --raw --login phys210e | grep dn: dn: nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=,dc=abc,dc=ca [root@ipa02]# ipa user-find --all --raw --login phys210e | grep dn: dn: nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=,dc=abc,dc=ca These appear to be replication conflict entries. Not sure what happened. See https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html On 09/03/2014 12:26 PM, Rob Crittenden wrote: Ron wrote: And here is the result of the user-show command: [root@ipa slapd-pxxx-abc-CA]# ipa user-show --all --raw phys210e ipa: ERROR: phys210e: user not found Sorry, thinko on my part. Do ipa user-find --all --raw --login phys210e user-show is going to have the same issue as user-delete. rob On 09/03/2014 10:43 AM, Rob Crittenden wrote: Martin Kosek wrote: Can you check /var/log/dirsrv/slapd-YOUR-REALM/access, search for the DEL operation and see what was the error code that DS gave when it refused to delete the user? Were I to guess the issue is that this is a replication conflict entry. If you do: # ipa user-show --all --raw phys210e |grep dn: It will likely begin with nsuniqueid=hex, ... The reason it can be found and not deleted is we create the dn to be removed, we don't search for it. So the user uid=phys210e,cn=users,... etc doesn't exist but the user nsuniqueid=hex ... does. You'll need to use ldapmodify or ldapdelete to remove the entry though I'd check your other masters to see what the state of the user is there. rob Martin On 09/03/2014 06:18 PM, Ron wrote: user-find sees a user but user-del cannot remove it. What can I do? Thanks. Regards, Ron [root@ipa]# ipa user-find --login phys210e -- 1 user matched -- User login: phys210e First name: Testing Last name: Phys210 Home directory: /home2/phys210e Login shell: /bin/bash Email address: phys2...@pxxx.abc.ca UID: 15010 GID: 15010 Account disabled: False Password: True Kerberos keys available: False Number of entries returned 1 [root@ipa]# ipa user-del phys210e --continue --- Deleted user --- Failed to remove: phys210e [root@ipa]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.5 (Santiago) [root@ipa]# rpm -qa|grep ipa; rpm -qa|grep 389 ipa-pki-ca-theme-9.0.3-7.el6.noarch ipa-admintools-3.0.0-37.el6.i686 ipa-pki-common-theme-9.0.3-7.el6.noarch libipa_hbac-1.9.2-129.el6_5.4.i686 ipa-server-selinux-3.0.0-37.el6.i686 python-iniparse-0.3.1-2.1.el6.noarch libipa_hbac-python-1.9.2-129.el6_5.4.i686 ipa-server-3.0.0-37.el6.i686 ipa-python-3.0.0-37.el6.i686 ipa-client-3.0.0-37.el6.i686 389-ds-base-libs-1.2.11.15-33.el6_5.i686 389-ds-base-1.2.11.15-33.el6_5.i686 -- Ron Parachoniak Systems Manager, Department of Physics Astronomy University of British Columbia, Vancouver, B.C. V6T 1Z1 Phone: (604) 838-6437 -- 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] Cert Renewal
The output of getcert list-cas from the replica is below. It contains both the 'renew' and the 'retrieve' items. As previously stated, the services are not running on the replica. I have been nervous about starting them; not wanting to impact the functional master. But, it is sounding like starting them up is all I really need to do to fix things. Would I need to set the date back on both systems? Will the certs renew more-or-less immediately, or will there be some lag after starting up the replica ipa service? CA 'SelfSign': is-default: no ca-type: INTERNAL:SELF next-serial-number: 01 CA 'IPA': is-default: no ca-type: EXTERNAL helper-location: /usr/libexec/certmonger/ipa-submit CA 'certmaster': is-default: no ca-type: EXTERNAL helper-location: /usr/libexec/certmonger/certmaster-submit CA 'dogtag-ipa-renew-agent': is-default: no ca-type: EXTERNAL helper-location: /usr/libexec/certmonger/dogtag-ipa-renew-agent-submit CA 'dogtag-ipa-retrieve-agent-submit': is-default: no ca-type: EXTERNAL helper-location: /usr/libexec/certmonger/dogtag-ipa-retrieve-agent-submit -Original Message- From: Rob Crittenden [mailto:rcrit...@redhat.com] Sent: Wednesday, September 03, 2014 3:19 PM To: Ott, Dennis; Freeipa-users@redhat.com Subject: Re: [Freeipa-users] Cert Renewal Ott, Dennis wrote: I may need a little more direction here. The output from getcert list-cas does not contain the string 'ca_renewal'. What does this indicate? I don't have a 2 - 3 updated server handy so I'm going on best guesses from reading the code. It is probably ok. You really just need to be sure to have a CA that has a submit script of: dogtag-ipa-retrieve-agent-submit and one for dogtag-ipa-renew-agent What is the output from list-cas? The way that CA renewal works is this: - One CA, the first install by default, is marked as the CA renewal master. The only thing that distinguishes this master is the way the renewal scripts are configured. This CA does the actual renewal of the certificates and pushes the resulting public certs into a shared space in the IPA LDAP tree - The other CA's monitor this area, via those two dotag-ipa-* scripts, and fetch and install updated certificates when one is available. When a cert is in CA_WORKING state it means that an update should be available but isn't in the shared tree, so certmonger will try again in a few hours. Assuming that certmonger is configured properly then it should just be a matter of getting the right certs added to the LDAP tree. rob -Original Message- From: Rob Crittenden [mailto:rcrit...@redhat.com] Sent: Tuesday, August 26, 2014 3:53 PM To: Ott, Dennis; Freeipa-users@redhat.com Subject: Re: [Freeipa-users] Cert Renewal Ott, Dennis wrote: No services are currently running on the replica (and I am hesitant to start them) but, my recollection is that I did the replica server installation with the --setup-ca option. Also, there are /var/lib/dirsrv/slapd-PKI-IPA/ and /etc/pki-ca/ directories in place on the replica. ipa-getcert list shows all certs with a status of: CA_UNREACHABLE (but then, the service is down. The master also gave this status, even with the service running, until I followed the cert renewal procedure.) So, with the replica running a CA, should I follow the same procedure that I used on the master? Anything else to look out for? No, the procedure is slightly different on the replica. You need to start by ensuring that certmonger has a CA type for renewal: # getcert list-cas Look for ca_renewal Check the CA subsystem certs to see how they are configured. The CA should be dogtag-ipa-retrieve-agent-submit for auditSigningCert cert-pki-ca, ocspSigningCert cert-pki-ca and subsystemCert cert-pki-ca and a pre-save command of stop_pkicad and a post-save a restart_pkicad PKI-IPA The agent cert, ipaCert, should be using dogtag-ipa-retrieve-agent-submit, a blank pre-save command and a post-save command of restart_httpd. rob Thanks. Dennis -Original Message- From: Rob Crittenden [mailto:rcrit...@redhat.com] Sent: Monday, August 25, 2014 6:37 PM To: Ott, Dennis; freeipa-users@redhat.com Subject: Re: [Freeipa-users] Cert Renewal Ott, Dennis wrote: I have an IPA setup, one master, one replica; originally installed as v 2.x and later updated to v 3.0. For whatever reasons, the certs did not automatically renew and the services would no longer start. I updated the certs manually on the master using the procedure shown at: http://www.freeipa.org/page/IPA_2x_Certificate_Renewal The master is now functioning properly. At this point, the IPA service is still stopped on the replica. I hesitate to start it for concern it could interfere with the now-working master. What would be the recommended
Re: [Freeipa-users] ipa user-find finds user but ipa user-del fails
So in my case I would need to do the Renaming an Entry with a Multi-Valued Naming Attribute procedure on both IPA01 and IPA02? Would another way of doing this be to remove IPA01 (and later IPA02) as a replication-master and then re-add it? I ask this because I have about 70 of these entries. I think they are there because I was using a perl script (which used the perl ldap-add function) to create new user entries and for a while the script called this (ldap-add) on IPA then IPA02 immediately after. -Ron On 09/03/2014 02:24 PM, Rich Megginson wrote: On 09/03/2014 02:44 PM, Ron wrote: By the way, all three replica servers show the same: [root@ipa]# ipa user-find --all --raw --login phys210e | grep dn: dn: nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=,dc=abc,dc=ca [root@ipa01]# ipa user-find --all --raw --login phys210e | grep dn: dn: nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=,dc=abc,dc=ca [root@ipa02]# ipa user-find --all --raw --login phys210e | grep dn: dn: nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=,dc=abc,dc=ca These appear to be replication conflict entries. Not sure what happened. See https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html On 09/03/2014 12:26 PM, Rob Crittenden wrote: Ron wrote: And here is the result of the user-show command: [root@ipa slapd-pxxx-abc-CA]# ipa user-show --all --raw phys210e ipa: ERROR: phys210e: user not found Sorry, thinko on my part. Do ipa user-find --all --raw --login phys210e user-show is going to have the same issue as user-delete. rob On 09/03/2014 10:43 AM, Rob Crittenden wrote: Martin Kosek wrote: Can you check /var/log/dirsrv/slapd-YOUR-REALM/access, search for the DEL operation and see what was the error code that DS gave when it refused to delete the user? Were I to guess the issue is that this is a replication conflict entry. If you do: # ipa user-show --all --raw phys210e |grep dn: It will likely begin with nsuniqueid=hex, ... The reason it can be found and not deleted is we create the dn to be removed, we don't search for it. So the user uid=phys210e,cn=users,... etc doesn't exist but the user nsuniqueid=hex ... does. You'll need to use ldapmodify or ldapdelete to remove the entry though I'd check your other masters to see what the state of the user is there. rob Martin On 09/03/2014 06:18 PM, Ron wrote: user-find sees a user but user-del cannot remove it. What can I do? Thanks. Regards, Ron [root@ipa]# ipa user-find --login phys210e -- 1 user matched -- User login: phys210e First name: Testing Last name: Phys210 Home directory: /home2/phys210e Login shell: /bin/bash Email address: phys2...@pxxx.abc.ca UID: 15010 GID: 15010 Account disabled: False Password: True Kerberos keys available: False Number of entries returned 1 [root@ipa]# ipa user-del phys210e --continue --- Deleted user --- Failed to remove: phys210e [root@ipa]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.5 (Santiago) [root@ipa]# rpm -qa|grep ipa; rpm -qa|grep 389 ipa-pki-ca-theme-9.0.3-7.el6.noarch ipa-admintools-3.0.0-37.el6.i686 ipa-pki-common-theme-9.0.3-7.el6.noarch libipa_hbac-1.9.2-129.el6_5.4.i686 ipa-server-selinux-3.0.0-37.el6.i686 python-iniparse-0.3.1-2.1.el6.noarch libipa_hbac-python-1.9.2-129.el6_5.4.i686 ipa-server-3.0.0-37.el6.i686 ipa-python-3.0.0-37.el6.i686 ipa-client-3.0.0-37.el6.i686 389-ds-base-libs-1.2.11.15-33.el6_5.i686 389-ds-base-1.2.11.15-33.el6_5.i686 -- Ron Parachoniak Systems Manager, Department of Physics Astronomy University of British Columbia, Vancouver, B.C. V6T 1Z1 Phone: (604) 838-6437 -- Ron Parachoniak Systems Manager, Department of Physics Astronomy University of British Columbia, Vancouver, B.C. V6T 1Z1 Phone: (604) 838-6437 -- 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
