Re: [Freeipa-users] Search Base issues

[Martin Kosek]

Ok, it indeed looks like we missed this tree when doing Permission V2
refactoring (ticket https://fedorahosted.org/freeipa/ticket/4521). This is
something we will need to fix in upcoming FreeIPA 4.0.2, so please stay tuned.

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.

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
> 
>>
>> **Mac_Slave is my automation user.
>>
>>
>>
>>
>> On Tue, Sep 2, 2014 at 3:40 PM, Chris Whittle > > wrote:
>>
>> For testing I'm using
>>
>> ldapsearch -LLL -H ldaps://DOMAIN636 -x -D "cn=directory manager" -w
>> 'nachopassword' -b "cn=canlogin,cn=compat,dc=domain,dc=com"
>>
>> If I do it with directory manager it works fine, if I use my
>> automation user (just a generic user with no extra permissions) it
>> returns nothing, no error, just empty space
>>
>> if I add -v (verbose) i get 
>>
>> ldap_initialize( ldaps://domain.com:636/??base
>>  )
>>
>> filter: (objectclass=*)
>>
>> requesting: All userApplication attributes
>>
>>
>> Thanks everyone!
>>
>>
>> On Tue, Sep 2, 2014 at 3:31 PM, Rob Crittenden > > wrote:
>>
>> Chris Whittle wrote:
>> > hmmm...
>> > Is there not a permission or role in freeIPA that I could give
>> a group
>> > or role just to see everything in
>> > my CN "cn=canlogin,cn=compat,dc=DOMAIN,dc=com"
>>
>> Can you provide more details on what you're doing, and how you are
>> binding? Can you search the cn=users,cn=compat,dc=DOMAIN,dc=com
>> tree?
>>
>> AFAICT you should be able to read cn=compat as long as you bind
>> as a user.
>>
>> rob
>>
>> >
>> >
>> >
>> > On Tue, Sep 2, 2014 at 3:06 PM, Dmitri Pal > 
>> > >> wrote:
>> >
>> > On 09/02/2014 09:34 PM, Chris Whittle wrote:
>> >> Ok Dmitri, I got it added using what you sent and the
>> following links
>> >>   
>>  
>> https://git.fedorahosted.org/cgit/slapi-nis.git/tree/doc/sch-getting-started.txt
>> >> and
>> >>   
>>  
>> https://www.redhat.com/archives/freeipa-users/2009-August/msg00013.html
>> >>
>> >> I think i'm 90% there with the caveat that I can't seem
>> to see
>> >> what permissions I need to give a user to view my NIS "view".
>> >>  Right now Directory Manager can see it but that is it.
>> >>
>> >> Any ideas?
>> >>
>> > You got me :-)
>> > I would defer to specialist in this area to solve this
>> problem.
>> >
>> >
>> >>
>> >>
>> >> On Tue, Sep 2, 2014 at 9:00 AM, Chris Whittle
>> mailto:cwhi...@gmail.com>
>> >> >> wrote:
>> >>
>> >> Thanks Dimitri, before I get too far this rabbit hole
>> (cause
>> >> it looks a little scary) let me make sure I get it.
>> >>
>> >> So using Slap-NIS I should be able to create a view into
>> >> FreeIPA that would show only a subset of user based on
>> >> something like a group or an attribute?
>> >>
>> >> Then using the built in MAC Directory Utility (or any
>> LDAP
>> >> client) I should be able to use that Slap-NIS view as a
>> >> searchbase and it would return just people I wanted. 
>> This
>> >> could be used keep anyone outside that view from
>> logging in?
>> >>
>> >> I'm sorry for the noob questions but there isn't a
>> lot of good
>> 

Re: [Freeipa-users] FreeIPA bind also-notify behavior.

[Petr Spacek]

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

[Rob Crittenden]

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

[Martin Kosek]

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

[Jim Kinney]

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

[Chris Whittle]

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  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

[Martin Kosek]

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  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

[Zip Ly]

@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  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

[Ron]

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

[Martin Kosek]

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

[Rob Crittenden]

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=, ...

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= ... 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

[Rob Crittenden]

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  > 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

[Rob Crittenden]

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

[Jim Kinney]

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

[Chris Whittle]

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  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  > > 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

[Rob Crittenden]

Jim Kinney wrote:
> 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.

Yeah. You can see the actual agreements by binding as cn=Directory
Manager and searching in cn=mapping tree, cn=config. We'd had to see the
agreement to really know what's going on, but it shouldn't affect
sending data to the other masters.

So it looks like vinz is communicating ok with prod01 so the data should
be getting shared ok, esp since prod01 and beast have agreements.

I'd start by checking on the replication agreement between vinz and
beast. The error 32 is a bit odd in itself. The 389-ds error log may
contain more information.

rob

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/free

Re: [Freeipa-users] ipa user-find finds user but ipa user-del fails

[Ron]

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=, ...
>
> 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= ... 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 Freei

Re: [Freeipa-users] Cert Renewal

[Rob Crittenden]

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

[Rob Crittenden]

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=, ...
>>
>> 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= ... 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

[Ron]

[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=, ...
>>>
>>> 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= ... 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

[Chris Whittle]

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  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 
> 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 > > > 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
>> >
>> >
>>
>>
>
-

Re: [Freeipa-users] ipa user-find finds user but ipa user-del fails

[Ron]

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=, ...
>>>
>>> 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= ... 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

[Rich Megginson]

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=, ...

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= ... 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

[Ott, Dennis]

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 

Re: [Freeipa-users] ipa user-find finds user but ipa user-del fails

[Ron]

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=, ...
>
> 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= ... 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

[Rich Megginson]

On 09/03/2014 05:50 PM, Ron wrote:

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?


Yes.



Would another way of doing this be to remove IPA01 (and later IPA02) as
a replication-master and then re-add it?


How would that solve the problem?  Wouldn't you still have 
nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e on IPA03?



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.


That would do it - adding the same entry to two or more servers before 
replication can occur.




-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=, ...

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= ... 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