Re: [Freeipa-users] Search Base issues
Ok, thanks. Good to see it is working for you.
I see you actually do authorization decision based on Schema Compatibility
plugin :) Note that an alternate, preferred way of doing authorization in
FreeIPA though is HBAC where you would configure which group of users can login
to which machines.
But this is only being enforced when SSSD is on the client machine, so it may
not be working for all your machines.
Martin
On 09/03/2014 10:45 PM, Chris Whittle wrote:
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
Re: [Freeipa-users] ipa user-find finds user but ipa user-del fails
Ah, ok. As Rob advised, you will need to delete it via ldapdelete CLI or via any LDAP GUI application of choice. BTW, this is upstream ticket tracking better means to resolve replication conflicts: https://fedorahosted.org/freeipa/ticket/1025 Martin On 09/03/2014 10: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 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
[Freeipa-users] Filters in bind-dyndb-ldap
Hello, I am trying to use bind-dyndb-ldap to connect my BIND to an LDAP server for zones. I have a tiny question regarding this and both the project website and the kind people on #freeipa IRC directed me to this list. I hope someone is here who can answer my question. Sorry for intruding if I'm not asking in the correct place. For technical reasons we need to be able to filter zones in LDAP according to some flags, e.g. 'enabled'. Other services usually provide a config option to include LDAP search filters in every query, like ldap_search_filter = (enabled=1) Unfortunately, I can't find anything like this in the README file of bind-dyndb-ldap. Does anybody know of a way to pass a search filter to LDAP? Thanks in advance, Sebastian -- Sebastian Leitz Mail: sebastian.le...@etes.de ETES GmbH Fon : +49 (7 11) 48 90 83 - 14 Gablenberger Hauptstrasse 32 Fax : +49 (7 11) 48 90 83 - 50 D-70186 Stuttgart Web : http://www.etes.de/ Registergericht: Amtsgericht Stuttgart HRB 721182 Geschäftsführender Gesellschafter: Markus Espenhain Sitz der Gesellschaft: Stuttgart USt.-Id.Nr.: DE814767446 -- 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] Filters in bind-dyndb-ldap
Look at nsaccountlock if it's TRUE then they are disabled. On Thu, Sep 4, 2014 at 7:20 AM, Sebastian Leitz sebastian.le...@etes.de wrote: Hello, I am trying to use bind-dyndb-ldap to connect my BIND to an LDAP server for zones. I have a tiny question regarding this and both the project website and the kind people on #freeipa IRC directed me to this list. I hope someone is here who can answer my question. Sorry for intruding if I'm not asking in the correct place. For technical reasons we need to be able to filter zones in LDAP according to some flags, e.g. 'enabled'. Other services usually provide a config option to include LDAP search filters in every query, like ldap_search_filter = (enabled=1) Unfortunately, I can't find anything like this in the README file of bind-dyndb-ldap. Does anybody know of a way to pass a search filter to LDAP? Thanks in advance, Sebastian -- Sebastian Leitz Mail: sebastian.le...@etes.de ETES GmbH Fon : +49 (7 11) 48 90 83 - 14 Gablenberger Hauptstrasse 32 Fax : +49 (7 11) 48 90 83 - 50 D-70186 Stuttgart Web : http://www.etes.de/ Registergericht: Amtsgericht Stuttgart HRB 721182 Geschäftsführender Gesellschafter: Markus Espenhain Sitz der Gesellschaft: Stuttgart USt.-Id.Nr.: DE814767446 -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Filters in bind-dyndb-ldap
Actually, FreeIPAbind-dynd-ldap use idnszoneactive attribute (TRUE/FALSE) to define which zones are active and which are not. On 09/04/2014 02:23 PM, Chris Whittle wrote: Look at nsaccountlock if it's TRUE then they are disabled. On Thu, Sep 4, 2014 at 7:20 AM, Sebastian Leitz sebastian.le...@etes.de wrote: Hello, I am trying to use bind-dyndb-ldap to connect my BIND to an LDAP server for zones. I have a tiny question regarding this and both the project website and the kind people on #freeipa IRC directed me to this list. I hope someone is here who can answer my question. Sorry for intruding if I'm not asking in the correct place. For technical reasons we need to be able to filter zones in LDAP according to some flags, e.g. 'enabled'. Other services usually provide a config option to include LDAP search filters in every query, like ldap_search_filter = (enabled=1) Unfortunately, I can't find anything like this in the README file of bind-dyndb-ldap. Does anybody know of a way to pass a search filter to LDAP? Thanks in advance, Sebastian -- Sebastian Leitz Mail: sebastian.le...@etes.de ETES GmbH Fon : +49 (7 11) 48 90 83 - 14 Gablenberger Hauptstrasse 32 Fax : +49 (7 11) 48 90 83 - 50 D-70186 Stuttgart Web : http://www.etes.de/ Registergericht: Amtsgericht Stuttgart HRB 721182 Geschäftsführender Gesellschafter: Markus Espenhain Sitz der Gesellschaft: Stuttgart USt.-Id.Nr.: DE814767446 -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Filters in bind-dyndb-ldap
On 4.9.2014 14:28, Martin Kosek wrote: Actually, FreeIPAbind-dynd-ldap use idnszoneactive attribute (TRUE/FALSE) to define which zones are active and which are not. Martin is right, I will add couple more details about this: idnszoneactive attribute should work in bind-dyndb-ldap 4.0. Versions = 4.0 do not support it yet. This defficiency is tracked in https://fedorahosted.org/bind-dyndb-ldap/ticket/127 You have couple options as a workaround: 1) Use older version of bind-dyndb-ldap :-) 2) Use LDAP transformation on server side so the server doesn't return objects from sub-tree with idnszoneactive attribute = FALSE. 3) Try some ACI magic on server side so it will not return objects from given sub-tree if idnszoneactive = FALSE. (This seems to be easiest option to me.) Have a nice day! Petr^2 Spacek On 09/04/2014 02:23 PM, Chris Whittle wrote: Look at nsaccountlock if it's TRUE then they are disabled. On Thu, Sep 4, 2014 at 7:20 AM, Sebastian Leitz sebastian.le...@etes.de wrote: Hello, I am trying to use bind-dyndb-ldap to connect my BIND to an LDAP server for zones. I have a tiny question regarding this and both the project website and the kind people on #freeipa IRC directed me to this list. I hope someone is here who can answer my question. Sorry for intruding if I'm not asking in the correct place. For technical reasons we need to be able to filter zones in LDAP according to some flags, e.g. 'enabled'. Other services usually provide a config option to include LDAP search filters in every query, like ldap_search_filter = (enabled=1) Unfortunately, I can't find anything like this in the README file of bind-dyndb-ldap. Does anybody know of a way to pass a search filter to LDAP? Thanks in advance, Sebastian -- 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] Filters in bind-dyndb-ldap
Thanks, Martin and Petr, for your comments and the workaround. As we're internally still on an old version of bind-dyndb-ldap I can actually use the LDAP attribute to achieve what I desire. Yeah! As for the future, I opended https://bugzilla.redhat.com/show_bug.cgi?id=1138317, if anybody is interested to upvote :-) -Ursprüngliche Nachricht- Von:Petr Spacek pspa...@redhat.com Gesendet: Don 4 September 2014 15:23 An: freeipa-users@redhat.com Betreff: Re: [Freeipa-users] Filters in bind-dyndb-ldap On 4.9.2014 14:28, Martin Kosek wrote: Actually, FreeIPAbind-dynd-ldap use idnszoneactive attribute (TRUE/FALSE) to define which zones are active and which are not. Martin is right, I will add couple more details about this: idnszoneactive attribute should work in bind-dyndb-ldap 4.0. Versions = 4.0 do not support it yet. This defficiency is tracked in https://fedorahosted.org/bind-dyndb-ldap/ticket/127 You have couple options as a workaround: 1) Use older version of bind-dyndb-ldap :-) 2) Use LDAP transformation on server side so the server doesn't return objects from sub-tree with idnszoneactive attribute = FALSE. 3) Try some ACI magic on server side so it will not return objects from given sub-tree if idnszoneactive = FALSE. (This seems to be easiest option to me.) Have a nice day! Petr^2 Spacek On 09/04/2014 02:23 PM, Chris Whittle wrote: Look at nsaccountlock if it's TRUE then they are disabled. On Thu, Sep 4, 2014 at 7:20 AM, Sebastian Leitz sebastian.le...@etes.de wrote: Hello, I am trying to use bind-dyndb-ldap to connect my BIND to an LDAP server for zones. I have a tiny question regarding this and both the project website and the kind people on #freeipa IRC directed me to this list. I hope someone is here who can answer my question. Sorry for intruding if I'm not asking in the correct place. For technical reasons we need to be able to filter zones in LDAP according to some flags, e.g. 'enabled'. Other services usually provide a config option to include LDAP search filters in every query, like ldap_search_filter = (enabled=1) Unfortunately, I can't find anything like this in the README file of bind-dyndb-ldap. Does anybody know of a way to pass a search filter to LDAP? Thanks in advance, Sebastian -- 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 -- Sebastian Leitz Mail: sebastian.le...@etes.de ETES GmbH Fon : +49 (7 11) 48 90 83 - 14 Gablenberger Hauptstrasse 32 Fax : +49 (7 11) 48 90 83 - 50 D-70186 Stuttgart Web : http://www.etes.de/ Registergericht: Amtsgericht Stuttgart HRB 721182 Geschäftsführender Gesellschafter: Markus Espenhain Sitz der Gesellschaft: Stuttgart USt.-Id.Nr.: DE814767446 -- 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 stopped working
Hello list, We’re running FreeIPA with a master and 3 replicas. The replication stopped working and currently we’re adding resources only to the master. This is the environment we have: m1: OS: CentOS release 6.5 FreeIPA: 3.0.0-37 CA: pki-ca-9.0.3 # ipa-replica-manage list -v `hostname` m2.example.com: replica last init status: None last init ended: None last update status: 49 - LDAP error: Invalid credentials last update ended: None m3.example.com: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2014-09-04 14:28:44+00:00 m4.example.com: replica last init status: None last init ended: None last update status: -2 - LDAP error: Local error last update ended: None m2: OS: CentOS release 6.5 FreeIPA: 3.0.0-37 # ipa-replica-manage list -v `hostname` m1.example.com: 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: 2014-09-03 22:53:21+00:00 m3: OS: CentOS release 6.5 FreeIPA: 3.0.0-37 # ipa-replica-manage list -v `hostname` m1.example.com: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2014-09-04 14:31:51+00:00 m4: OS: CentOS release 6.5 FreeIPA: 3.3.3-28 # ipa-replica-manage list -v `hostname` m1.example.com: replica last init status: None last init ended: None last update status: 49 Unable to acquire replicaLDAP error: Invalid credentials last update ended: None Note that although m3 reports “Incremental update succeeded”, users created on m1 are not replicated to m3, and users created on m3 are not replicated back to m1. We’ve tried different things including re-initializing m2. Can somebody point me in the right direction to get replication going again? Thanks in advance! Guillermo -- 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 stopped working
I should add that we already tried everything at https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html On Thu, Sep 4, 2014 at 11:11 AM, Guillermo Fuentes guillermo.fuen...@modernizingmedicine.com wrote: Hello list, We’re running FreeIPA with a master and 3 replicas. The replication stopped working and currently we’re adding resources only to the master. This is the environment we have: m1: OS: CentOS release 6.5 FreeIPA: 3.0.0-37 CA: pki-ca-9.0.3 # ipa-replica-manage list -v `hostname` m2.example.com: replica last init status: None last init ended: None last update status: 49 - LDAP error: Invalid credentials last update ended: None m3.example.com: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2014-09-04 14:28:44+00:00 m4.example.com: replica last init status: None last init ended: None last update status: -2 - LDAP error: Local error last update ended: None m2: OS: CentOS release 6.5 FreeIPA: 3.0.0-37 # ipa-replica-manage list -v `hostname` m1.example.com: 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: 2014-09-03 22:53:21+00:00 m3: OS: CentOS release 6.5 FreeIPA: 3.0.0-37 # ipa-replica-manage list -v `hostname` m1.example.com: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2014-09-04 14:31:51+00:00 m4: OS: CentOS release 6.5 FreeIPA: 3.3.3-28 # ipa-replica-manage list -v `hostname` m1.example.com: replica last init status: None last init ended: None last update status: 49 Unable to acquire replicaLDAP error: Invalid credentials last update ended: None Note that although m3 reports “Incremental update succeeded”, users created on m1 are not replicated to m3, and users created on m3 are not replicated back to m1. We’ve tried different things including re-initializing m2. Can somebody point me in the right direction to get replication going again? Thanks in advance! Guillermo -- 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 -- Cheers, Fredy Sanchez IT Manager @ Modernizing Medicine 561-880-2998 x237 fredy.sanc...@modmed.com Need IT support? Visit https://mmit.zendesk.com - - -- 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
So I tried to delete an entry on IPA01 without success: [root@ipa01 ~]# ldapdelete -D uid=admin,cn=users,cn=accounts,dc=,dc=abc,dc=ca -W -x cn=userxyz+nsuniqueid=62c9c682-32ce11e4-8c13b928-a98b9061,cn=groups,cn=accounts,dc=,dc=abc,dc=ca Enter LDAP Password: ldap_delete: Server is unwilling to perform (53) additional info: Deleting a managed entry is not allowed. It needs to be manually unlinked first Same problem if I try to use ldapmodify: [root@ipa01 ~]# ldapmodify -D uid=admin,cn=users,cn=accounts,dc=,dc=abc,dc=ca -W -x Enter LDAP Password: dn: cn=userxyz+nsuniqueid=62c9c682-32ce11e4-8c13b928-a98b9061,cn=groups,cn=accounts,dc=,dc=abc,dc=ca changetype: modrdn newrdn: uid=19000 deleteoldrdn: 0 modifying rdn of entry cn=userxyz+nsuniqueid=62c9c682-32ce11e4-8c13b928-a98b9061,cn=groups,cn=accounts,dc=,dc=abc,dc=ca ldap_rename: Server is unwilling to perform (53) additional info: Renaming a managed entry is not allowed. It needs to be manually unlinked first. (19000 is just an unused uid) Would this be because of the private group associated with the user? How do I unlink the entry? Would I use the following? ipa group-detach userxyz Thanks again for all your help! -Ron On 09/04/2014 02:48 AM, Martin Kosek wrote: Ah, ok. As Rob advised, you will need to delete it via ldapdelete CLI or via any LDAP GUI application of choice. BTW, this is upstream ticket tracking better means to resolve replication conflicts: https://fedorahosted.org/freeipa/ticket/1025 Martin On 09/03/2014 10: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 -- 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 stopped working
sudo ipa-replica-conncheck --replica for all replicas comes back with ... The following UDP ports could not be verified as open: 88, 464 This can happen if they are already bound to an application and ipa-replica-conncheck cannot attach own UDP responder. Connection from master to replica is OK. ipa-replica-manage -v list $REPLICA fails w/ Failed to get data from 'REPLICA': Invalid credentials SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context The common error is: nsds5replicaLastUpdateStatus: -2 - LDAP error: Local error On Thu, Sep 4, 2014 at 11:21 AM, Fredy Sanchez fredy.sanc...@modmed.com wrote: I should add that we already tried everything at https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html On Thu, Sep 4, 2014 at 11:11 AM, Guillermo Fuentes guillermo.fuen...@modernizingmedicine.com wrote: Hello list, We’re running FreeIPA with a master and 3 replicas. The replication stopped working and currently we’re adding resources only to the master. This is the environment we have: m1: OS: CentOS release 6.5 FreeIPA: 3.0.0-37 CA: pki-ca-9.0.3 # ipa-replica-manage list -v `hostname` m2.example.com: replica last init status: None last init ended: None last update status: 49 - LDAP error: Invalid credentials last update ended: None m3.example.com: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2014-09-04 14:28:44+00:00 m4.example.com: replica last init status: None last init ended: None last update status: -2 - LDAP error: Local error last update ended: None m2: OS: CentOS release 6.5 FreeIPA: 3.0.0-37 # ipa-replica-manage list -v `hostname` m1.example.com: 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: 2014-09-03 22:53:21+00:00 m3: OS: CentOS release 6.5 FreeIPA: 3.0.0-37 # ipa-replica-manage list -v `hostname` m1.example.com: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2014-09-04 14:31:51+00:00 m4: OS: CentOS release 6.5 FreeIPA: 3.3.3-28 # ipa-replica-manage list -v `hostname` m1.example.com: replica last init status: None last init ended: None last update status: 49 Unable to acquire replicaLDAP error: Invalid credentials last update ended: None Note that although m3 reports “Incremental update succeeded”, users created on m1 are not replicated to m3, and users created on m3 are not replicated back to m1. We’ve tried different things including re-initializing m2. Can somebody point me in the right direction to get replication going again? Thanks in advance! Guillermo -- 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 -- Cheers, Fredy Sanchez IT Manager @ Modernizing Medicine 561-880-2998 x237 fredy.sanc...@modmed.com Need IT support? Visit https://mmit.zendesk.com - - -- Cheers, Fredy Sanchez IT Manager @ Modernizing Medicine 561-880-2998 x237 fredy.sanc...@modmed.com Need IT support? Visit https://mmit.zendesk.com - - -- 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/04/2014 02:31 PM, Ron wrote: So I tried to delete an entry on IPA01 without success: [root@ipa01 ~]# ldapdelete -D uid=admin,cn=users,cn=accounts,dc=,dc=abc,dc=ca -W -x cn=userxyz+nsuniqueid=62c9c682-32ce11e4-8c13b928-a98b9061,cn=groups,cn=accounts,dc=,dc=abc,dc=ca Enter LDAP Password: ldap_delete: Server is unwilling to perform (53) additional info: Deleting a managed entry is not allowed. It needs to be manually unlinked first Same problem if I try to use ldapmodify: [root@ipa01 ~]# ldapmodify -D uid=admin,cn=users,cn=accounts,dc=,dc=abc,dc=ca -W -x Enter LDAP Password: dn: cn=userxyz+nsuniqueid=62c9c682-32ce11e4-8c13b928-a98b9061,cn=groups,cn=accounts,dc=,dc=abc,dc=ca changetype: modrdn newrdn: uid=19000 deleteoldrdn: 0 modifying rdn of entry cn=userxyz+nsuniqueid=62c9c682-32ce11e4-8c13b928-a98b9061,cn=groups,cn=accounts,dc=,dc=abc,dc=ca ldap_rename: Server is unwilling to perform (53) additional info: Renaming a managed entry is not allowed. It needs to be manually unlinked first. (19000 is just an unused uid) Would this be because of the private group associated with the user? How do I unlink the entry? Would I use the following? ipa group-detach userxyz Yes, see https://fedorahosted.org/freeipa/ticket/75 Thanks again for all your help! -Ron On 09/04/2014 02:48 AM, Martin Kosek wrote: Ah, ok. As Rob advised, you will need to delete it via ldapdelete CLI or via any LDAP GUI application of choice. BTW, this is upstream ticket tracking better means to resolve replication conflicts: https://fedorahosted.org/freeipa/ticket/1025 Martin On 09/03/2014 10: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 -- 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] Using 389-console with FreeIPA 3
I realize this question has been brought forth previously, but I am unable to find a clear answer. I have a 389-ds environment that is serving as an authentication back end for a python application. The plan was to use this as a kind of SSO for other future applications and we have MANY users/groups/OUs and different policies involved already. Since it's not really feasible to re-create everything, and it will not integrate directly with FreeIPA I would like to be able to import my subtree to the 389-ds instance within my new FreeIPA install and manage that subtree separately from all my hosts and POSIX users. The short question, how can I manage to get the admin console working with the 389-ds that is included in FreeIPA? I'd really like to use FreeIPA for all my host based authentication, but it becomes a non-option if we have to run multiple directory clusters. -- 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
