[Freeipa-devel] [PATCH PoC] proper support of kerberos principal aliases

[Martin Babinsky]

Work-in-progress patchset for https://fedorahosted.org/freeipa/ticket/3864

I didn't even format the patches according to guidelines since I will 
certainly get many comments from Simo/Alexander and do a lot of 
reworking. But I hope I'm at least on a right track.


--
Martin^3 Babinsky
From 913bc484c1d00d62a5ab7f31546fec87cc1b8c43 Mon Sep 17 00:00:00 2001
From: Martin Babinsky 
Date: Tue, 8 Sep 2015 18:01:57 +0200
Subject: [PATCH 8/8] add case-insensitive matching rule to krbprincipalname
 index

Part of https://fedorahosted.org/freeipa/ticket/3864
---
 install/share/indices.ldif|  2 ++
 install/updates/20-indices.update | 10 ++
 2 files changed, 12 insertions(+)

diff --git a/install/share/indices.ldif b/install/share/indices.ldif
index 8c4913b569eb8be740090e1665349608be4ae932..081c15e48094f1df8cf6b8613730e6c56f9c16b9 100644
--- a/install/share/indices.ldif
+++ b/install/share/indices.ldif
@@ -6,6 +6,8 @@ cn:krbPrincipalName
 nsSystemIndex:false
 nsIndexType:eq
 nsIndexType:sub
+nsMatchingRule: caseIgnoreIA5Match
+nsMatchingRule: caseExactIA5Match
 
 dn: cn=ou,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
 changetype: add
diff --git a/install/updates/20-indices.update b/install/updates/20-indices.update
index 9c12e0cb804066feaa7e9e3f93a06018a8d43ddd..f39310a304d37614526a425e43751bc492fa7c67 100644
--- a/install/updates/20-indices.update
+++ b/install/updates/20-indices.update
@@ -231,3 +231,13 @@ default:ObjectClass: top
 default:ObjectClass: nsIndex
 only:nsIndexType: eq
 only:nsIndexType: pres
+
+dn: cn=krbPrincipalName,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
+default:cn: krbPrincipalName
+default:ObjectClass: top
+default:ObjectClass: nsIndex
+default:nsSystemIndex: false
+only: nsMatchingRule: caseIgnoreIA5Match
+only: nsMatchingRule: caseExactIA5Match
+only:nsIndexType: eq
+only:nsIndexType: sub
-- 
2.4.3

From 9a838dba6713d1b5eef73fd6c9dee210f1c86458 Mon Sep 17 00:00:00 2001
From: Martin Babinsky 
Date: Tue, 8 Sep 2015 17:52:40 +0200
Subject: [PATCH 7/8] always set krbcanonicalname attribute on new principals
 created using IPA API

Part of https://fedorahosted.org/freeipa/ticket/3864
---
 ipalib/plugins/baseuser.py |  3 ++-
 ipalib/plugins/host.py |  4 +++-
 ipalib/plugins/service.py  | 16 
 3 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/ipalib/plugins/baseuser.py b/ipalib/plugins/baseuser.py
index ed7c1a9d360a89ce0640dd63e748596993bb8b6c..ed880441b0f2bb768f957a7a31590b6b4d58cfc1 100644
--- a/ipalib/plugins/baseuser.py
+++ b/ipalib/plugins/baseuser.py
@@ -29,7 +29,7 @@ from ipalib import Flag, Int, Password, Str, Bool, StrEnum, DateTime, Bytes
 from ipalib.plugable import Registry
 from ipalib.plugins.baseldap import DN, LDAPObject, \
 LDAPCreate, LDAPUpdate, LDAPSearch, LDAPDelete, LDAPRetrieve
-from ipalib.plugins.service import validate_certificate
+from ipalib.plugins.service import validate_certificate, set_krbcanonicalname
 from ipalib.plugins import baseldap
 from ipalib.request import context
 from ipalib import _, ngettext
@@ -483,6 +483,7 @@ class baseuser_add(LDAPCreate):
 """
 def pre_common_callback(self, ldap, dn, entry_attrs, **options):
 assert isinstance(dn, DN)
+set_krbcanonicalname(entry_attrs)
 self.obj.convert_usercertificate_pre(entry_attrs)
 
 def post_common_callback(self, ldap, dn, entry_attrs, **options):
diff --git a/ipalib/plugins/host.py b/ipalib/plugins/host.py
index 532ff66607911cfd8e1a3407b0f361641bb7992b..bf363017d4c42c058c9bc9f1dd1997d75591e3fb 100644
--- a/ipalib/plugins/host.py
+++ b/ipalib/plugins/host.py
@@ -33,7 +33,8 @@ from ipalib.plugins.baseldap import (LDAPQuery, LDAPObject, LDAPCreate,
 from ipalib.plugins.service import (split_principal, validate_certificate,
 set_certificate_attrs, ticket_flags_params, update_krbticketflags,
 set_kerberos_attrs, rename_ipaallowedtoperform_from_ldap,
-rename_ipaallowedtoperform_to_ldap, revoke_certs)
+rename_ipaallowedtoperform_to_ldap, revoke_certs,
+set_krbcanonicalname)
 from ipalib.plugins.dns import (dns_container_exists, _record_types,
 add_records_for_host_validation, add_records_for_host,
 get_reverse_zone)
@@ -633,6 +634,7 @@ class host_add(LDAPCreate):
 entry_attrs['objectclass'].append('krbprincipalaux')
 if 'krbprincipal' not in entry_attrs['objectclass']:
 entry_attrs['objectclass'].append('krbprincipal')
+set_krbcanonicalname(entry_attrs)
 else:
 if 'krbprincipalaux' in entry_attrs['objectclass']:
 entry_attrs['objectclass'].remove('krbprincipalaux')
diff --git a/ipalib/plugins/service.py b/ipalib/plugins/service.py
index 0e188dad4a215a6882cf2a458e0bd1de80f4c58a..74e0f0dc716534b7fd2eb476cff1d1e0f3ba0f1d 100644
--- a/ipalib/plugins/service.py
+++ b/ipalib/plugins/service.py
@@ -361,6 +361,19 @@ def 

Re: [Freeipa-devel] [PATCH] 916 vault: add vault container commands

[Jan Cholasta]

On 8.9.2015 23:06, Petr Vobornik wrote:

On 09/03/2015 03:18 PM, Jan Cholasta wrote:

On 2.9.2015 07:26, Endi Sukma Dewata wrote:

On 9/1/2015 10:22 AM, Simo Sorce wrote:

On Tue, 2015-09-01 at 17:15 +0200, Petr Vobornik wrote:

On 09/01/2015 04:39 PM, Jan Cholasta wrote:

On 1.9.2015 16:26, Jan Cholasta wrote:

On 26.8.2015 13:22, Petr Vobornik wrote:

On 08/25/2015 08:04 PM, Petr Vobornik wrote:

adds commands:
* vaultcontainer-show [--service |--user  ]
* vaultcontainer-add-owner
   [--service |--user  ]
   [--users ]  [--groups ] [--services
]
* vaultcontainer-remove-owner
   [--service |--user  ]
   [--users ]  [--groups ] [--services
]

https://fedorahosted.org/freeipa/ticket/5250

Use cases:
1. When user/service is deleted, associated vault container looses
owner. There was no API command to set the owner.
2. Change owner of container by admin to manage access.

Show command was added to show current owners.

Find command was not added, should it be?




There is also a design for vault container ownership handling
created by
Endi - it's for future Vault 2.0.

http://www.freeipa.org/page/V4/Password_Vault_2.0#Adding_container_owner




This patch has a different API than the proposed - different way of
specifying the container. The design page uses path e.g.
/users/foobar.
This patch uses the same way as vaults e.g. --user=foobar. This
means
that the implementation in this patch cannot manage ownership of
parent
vault containers e.g. cn=users,cn=vaults,cn=kra,$SUFFIX.

Do we want to go with this approach in 4.2?

Attaching also new path which removes setting of owner which
doesn't
exist so that integrity is OK and that it is consistent with
removing of
user.

Updated patch attached - output fix.


We had a long discussion about this with Petr and we think the best
approach is as follows:

* Add new "Vault administrators" privilege. Vault
administrators will
have unrestricted access to vaults and vault containers, including
the
power to add/remove owners of vaults and vault containers.

* Remove the ability of vault owners to add/remove other vault
owners. If vault owner needs to be changed, vault administrator
has to
do it. Note that vault owners will still have the ability to
add/remove
vault members.

* When adding new vault container, set owner to the current
user. If
vault container owner needs to be changed, vault administrator has
to do
it.

* Allow adding vaults and vault containers only if the owner is
set
to the current user.

* Introduce commands to modify vault container owner and to
delete
vault container, so the administrator has a choice between assigning
ownership or deleting an unowned container.


Also:

* Control access to vault data using an ipaProtectedOperation
ACI.
Users which have read access to "ipaProtectedOperation;accessKRA"
on a
vault can retrieve data from the vault and users which have write
access
to "ipaProtectedOperation;accessKRA" on a vault can archive data in
the
vault.

Honza



+1

CCing Simo and Endi to check the proposal.

And Scott (related to #5216, #5215)


Sounds reasonable to me.
I can see that allowing owners to hand over vaults w/o admin
intervention may have some appeal in some use cases, but I also see it
can bring downsides with it, so all in all I think I agree with the
above points.

Simo.



Not a total objection, but if many people in unrelated groups are using
vaults, and they are sharing the vaults only with members of each group,
having to ask a Vault Administrator for each ownership change sounds a
bit cumbersome. Since the Vault Adminstrator will have access to all
vaults in all groups, only a small number of people can be trusted to
hold that role. If there are many ownership changes the Vault
Administrator will have to handle all those requests, and the vault
users may have to wait until the change is completed.

If owners are allowed to add others as owners, the vaults will be pretty
much maintenance free to the admin.


Owners can still manage members, which is IMO good enough for sharing a
vault with other users.



Regardless, please update the wiki page to describe the new behavior
when it's implemented:
http://www.freeipa.org/page/V4/Password_Vault_1.1


Sure.

I have updated and rebased Petr's patch 916.

Patch 488 obsoletes Petr's patch 918.

Patch for vault data access control is not included, because I was not
able to make GER work correctly with "ipaProtectedOperation;accessKRA".



I found 1 major issue(#3), one easy fix(#2), optional(#1) and a question
(#4).

1. `ipa vaultcontainer-del` doesn't show user/service name. IMHO not a
blocker.

[pvoborni@vm-063 ~]$ ipa vaultcontainer-del --user=fbar
--
Deleted vault container ""
--


Fixed.




2. Invalid description of vaultcontainer-show
   "Display information about a vault."


Fixed.



3. Something which needs to be fixed:

Setting password for first vault without a vault container 

Re: [Freeipa-devel] IPA 3.0 migrated to 4.1 users break winsync agreement when deleted in active directory

[Martin Basti]

On 09/09/2015 10:50 AM, Andreas Calminder wrote:
Forgot to write that deleting users in active directory not migrated 
with the migrate-ds command works fine, it's only migrated users 
present in the ad that breaks the winsync agreement on deletion.


On 09/09/2015 10:35 AM, Andreas Calminder wrote:

Hi,
I've asked in #freeipa on freenode but to no avail, figured I'll ask 
here as well, since I think I've actually hit a bug or (quite) 
possibly I've done something moronic configuration/migration -wise.


I've got an existing FreeIPA 3.0.0 environment running with a fully 
functioning winsync agreement and passsync service with the windows 
environments active directory, I'm trying to migrate the 3.0.0 
environments users into a freshly installed 4.1 (rhel7) environment, 
after migration I setup a winsync agreement and make it 
bi-directional  (one-way sync from windows) everything seems to be 
working alright until I delete a migrated user from the Active 
Directory, after the winsync picks up on the change it'll break and 
suggests a re-initialize. After the re-initialization the agreement 
seems to be fine, however the deleted user are still present in the 
ipa 4.1 environment and cannot be deleted. The webgui and ipa cli 
says: ipauser1: user not found. ipa user-find ipauser1 finds the user 
and it's visible in the ui.


Anyone had the same problem or anything similar or any pointers on 
where to start looking?


Regards,
Andreas





Hello, this might be a replication conflict.

Can you list that user via ldapsearch to check if this is replication 
conflict?


https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH 0058, 0064] dns: do not add (forward)zone if it is already resolvable.

[Petr Spacek]

On 8.9.2015 16:30, David Kupka wrote:
> On 28/08/15 13:36, Martin Basti wrote:
>>
>>
>> On 08/28/2015 10:03 AM, Petr Spacek wrote:
>>> On 27.8.2015 14:22, David Kupka wrote:
 @@ -2101,11 +2101,25 @@ class DNSZoneBase(LDAPObject):
   class DNSZoneBase_add(LDAPCreate):
 +takes_options = LDAPCreate.takes_options + (
 +Flag('force',
 + label=_('Force'),
 + doc=_('Force DNS zone creation.')
 +),
 +Flag('skip_overlap_check',
 + doc=_('Force DNS zone creation even if it will overlap
 with '
 +   'existing zone.')
 +),
 +)
 +
   has_output_params = LDAPCreate.has_output_params +
 dnszone_output_params
   def pre_callback(self, ldap, dn, entry_attrs, attrs_list,
 *keys, **options):
   assert isinstance(dn, DN)
 +if options['force']:
 +options['skip_overlap_check'] = True
 +
   try:
   entry = ldap.get_entry(dn)
   except errors.NotFound:
 @@ -2120,6 +2134,12 @@ class DNSZoneBase_add(LDAPCreate):
   entry_attrs['idnszoneactive'] = 'TRUE'
 +if not options['skip_overlap_check']:
 +try:
 +check_zone_overlap(keys[-1])
 +except RuntimeError as e:
 +raise errors.InvocationError(e.message)
 +
   return dn
 @@ -2673,9 +2693,9 @@ class dnszone_add(DNSZoneBase_add):
   __doc__ = _('Create new DNS zone (SOA record).')
   takes_options = DNSZoneBase_add.takes_options + (
 -Flag('force',
 - label=_('Force'),
 - doc=_('Force DNS zone creation even if nameserver is
 not resolvable.'),
 +Flag('skip_nameserver_check',
 + doc=_('Force DNS zone creation even if nameserver is not '
 +   'resolvable.')
   ),
   # Deprecated
 @@ -2699,6 +2719,9 @@ class dnszone_add(DNSZoneBase_add):
   def pre_callback(self, ldap, dn, entry_attrs, attrs_list,
 *keys, **options):
   assert isinstance(dn, DN)
 +if options['force']:
 +options['skip_nameserver_check'] = True
>>> Why is it in DNSZoneBase_add.pre_callback?
>>>
>>> Shouldn't the equation force = (skip_nameserver_check +
>>> skip_nameserver_check)
>>> be handled in parameter parsing & validation? (Again, I do not know
>>> the IPA
>>> framework :-))
>>>
 +
   dn = super(dnszone_add, self).pre_callback(
   ldap, dn, entry_attrs, attrs_list, *keys, **options)
 @@ -2713,7 +2736,7 @@ class dnszone_add(DNSZoneBase_add):
   error=_("Nameserver for reverse zone cannot be
 a relative DNS name"))
   # verify if user specified server is resolvable
 -if not options['force']:
 +if not options['skip_nameserver_check']:
   check_ns_rec_resolvable(keys[0],
 entry_attrs['idnssoamname'])
   # show warning about --name-server option
   context.show_warning_nameserver_option = True
 diff --git a/ipapython/ipautil.py b/ipapython/ipautil.py
 index
 d959bb369d946217acd080e78483cc9013dda4c7..18f477d4fb6620090b7073689c8df51b65a8307a

 100644
 --- a/ipapython/ipautil.py
 +++ b/ipapython/ipautil.py
 @@ -924,6 +924,20 @@ def host_exists(host):
   else:
   return True
 +def check_zone_overlap(zone):
 +if resolver.zone_for_name(zone) == zone:
 +try:
 +ns = [ans.to_text() for ans in resolver.query(zone, 'NS')]
 +except DNSException as e:
 +root_logger.debug("Failed to resolve nameserver(s) for
 domain"
 +" {0}: {1}".format(zone, e))
 +ns = []
 +
 +msg = u"DNS zone {0} already exists".format(zone)
>>> Nitpick: I would say "already exists in DNS" to make it absolutely
>>> clear. Just
>>> 'already exists' might be confusing because ipa dnszone-show will say
>>> that the
>>> zone does not exist ...
>>>
 +if ns:
 +msg += u" and is handled by server(s): {0}".format(',
 '.join(ns))
 +raise RuntimeError(msg)
 +
   def get_ipa_basedn(conn):
   """
   Get base DN of IPA suffix in given LDAP server.
>> 0064
>> NACK
>>
>> ipa-replica-install should have the --skip-overlap-check too, because
>> any replica can be the first DNS server.
> 
> Thanks for the catch, added.
> 
>>
>> 0064+0058
>> Can be the options --allow-zone-overlap and --skip-overlap-check merged
>> into an one name, to have just one name for same thing?
>>
> 
> Each option has bit different behavior:
> The '--skip-overlap-check' option in API call prevent the check to be
> performed and thus no error or warning 

Re: [Freeipa-devel] [PATCH 0311] tests: fix vault tests

[Martin Babinsky]

On 09/08/2015 05:45 PM, Martin Basti wrote:

Attached patch fixes vault tests.



Tests work for me, ACK.

--
Martin^3 Babinsky

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH 0311] tests: fix vault tests

[Martin Basti]

On 09/09/2015 02:21 PM, Martin Babinsky wrote:

On 09/08/2015 05:45 PM, Martin Basti wrote:

Attached patch fixes vault tests.



Tests work for me, ACK.


pushed to

master:
* 9ffe7f49987bf788449a2007a33f0a3d83ea4553 FIX vault tests
ipa-4-2:
* 72ba3777ca8c58dbbb912a19f81fd2bb2983b8d6 FIX vault tests

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH PoC] proper support of kerberos principal aliases

[Simo Sorce]

On Wed, 2015-09-09 at 10:52 +0200, Martin Babinsky wrote:
>  if (found) {
> +/* replace the incoming principal with the value got
> from LDAP
> + * search. This is needed so that correctly case
> principal is
> + * returned in the case when canonicalization is
> switched on
> + * and no krbcanonicalname attribute is present in
> the entry.
> + */
> +free(*principal);
> +*principal = strdup(vals[i]->bv_val);
> +if (!(*principal)) {
> +return KRB5_KDB_INTERNAL_ERROR;
> +}
>  break;


This unconditionally replaces the principal even when canonicalization
is not requested. Shouldn't this replace be conditional on
KRB5_KDB_FLAGS_ALIAS_OK being set ?

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH PoC] proper support of kerberos principal aliases

[Simo Sorce]

On Wed, 2015-09-09 at 10:52 +0200, Martin Babinsky wrote:
> Work-in-progress patchset for https://fedorahosted.org/freeipa/ticket/3864
> 
> I didn't even format the patches according to guidelines since I will 
> certainly get many comments from Simo/Alexander and do a lot of 
> reworking. But I hope I'm at least on a right track.

The direction looks good, keep in mind you have to change also 
install/share/modrdn-krbprinc.ldif (and related update file) to add a
'cn=Kerberos Canonical Name' rule.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] IPA 3.0 migrated to 4.1 users break winsync agreement when deleted in active directory

[Rich Megginson]

On 09/09/2015 03:39 AM, Martin Basti wrote:



On 09/09/2015 10:50 AM, Andreas Calminder wrote:
Forgot to write that deleting users in active directory not migrated 
with the migrate-ds command works fine, it's only migrated users 
present in the ad that breaks the winsync agreement on deletion.


On 09/09/2015 10:35 AM, Andreas Calminder wrote:

Hi,
I've asked in #freeipa on freenode but to no avail, figured I'll ask 
here as well, since I think I've actually hit a bug or (quite) 
possibly I've done something moronic configuration/migration -wise.


I've got an existing FreeIPA 3.0.0 environment running with a fully 
functioning winsync agreement and passsync service with the windows 
environments active directory, I'm trying to migrate the 3.0.0 
environments users into a freshly installed 4.1 (rhel7) environment, 
after migration I setup a winsync agreement and make it 
bi-directional  (one-way sync from windows) everything seems to be 
working alright until I delete a migrated user from the Active 
Directory, after the winsync picks up on the change it'll break and 
suggests a re-initialize. After the re-initialization the agreement 
seems to be fine, however the deleted user are still present in the 
ipa 4.1 environment and cannot be deleted. The webgui and ipa cli 
says: ipauser1: user not found. ipa user-find ipauser1 finds the 
user and it's visible in the ui.


Anyone had the same problem or anything similar or any pointers on 
where to start looking?


Regards,
Andreas





Hello, this might be a replication conflict.

Can you list that user via ldapsearch to check if this is replication 
conflict?


https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html 



Use the latest docs, just in case they are more accurate: 
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH PoC] proper support of kerberos principal aliases

[Simo Sorce]

On Wed, 2015-09-09 at 16:21 +0200, David Kupka wrote:
> On 09/09/15 15:59, Simo Sorce wrote:
> > On Wed, 2015-09-09 at 10:52 +0200, Martin Babinsky wrote:
> >>   if (found) {
> >> +/* replace the incoming principal with the value got
> >> from LDAP
> >> + * search. This is needed so that correctly case
> >> principal is
> >> + * returned in the case when canonicalization is
> >> switched on
> >> + * and no krbcanonicalname attribute is present in
> >> the entry.
> >> + */
> >> +free(*principal);
> >> +*principal = strdup(vals[i]->bv_val);
> >> +if (!(*principal)) {
> >> +return KRB5_KDB_INTERNAL_ERROR;
> >> +}
> >>   break;
> >
> >
> > This unconditionally replaces the principal even when canonicalization
> > is not requested. Shouldn't this replace be conditional on
> > KRB5_KDB_FLAGS_ALIAS_OK being set ?
> >
> > Simo.
> >
> 
> It's not obvious from first look but it actually depends on the 
> KRB5_KDB_FLAGS_ALIAS_OK.
> When KRB5_KDB_FLAGS_ALIAS_OK is true the 'found' variable is the result 
> of case-insensitive comparison.
> When it's false 'found' variable is the result of case-sensitive comparison.
> In case of case-sensitive match we're replacing the principal with the 
> exactly same value though effectively not changing it.
> 

Yeah I saw that, but you just said it, it is not obvious.

You should just move this chunk of code, as is, 2 blocks above where the
insensitive comparison is done.

This will make it clear that it is done only for canonicalization and
following changes won't break stuff. It will also avoid unnecessry free
and replace with the same value when canonicalization is not used.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH PoC] proper support of kerberos principal aliases

[David Kupka]

On 09/09/15 15:59, Simo Sorce wrote:

On Wed, 2015-09-09 at 10:52 +0200, Martin Babinsky wrote:

  if (found) {
+/* replace the incoming principal with the value got
from LDAP
+ * search. This is needed so that correctly case
principal is
+ * returned in the case when canonicalization is
switched on
+ * and no krbcanonicalname attribute is present in
the entry.
+ */
+free(*principal);
+*principal = strdup(vals[i]->bv_val);
+if (!(*principal)) {
+return KRB5_KDB_INTERNAL_ERROR;
+}
  break;



This unconditionally replaces the principal even when canonicalization
is not requested. Shouldn't this replace be conditional on
KRB5_KDB_FLAGS_ALIAS_OK being set ?

Simo.



It's not obvious from first look but it actually depends on the 
KRB5_KDB_FLAGS_ALIAS_OK.
When KRB5_KDB_FLAGS_ALIAS_OK is true the 'found' variable is the result 
of case-insensitive comparison.

When it's false 'found' variable is the result of case-sensitive comparison.
In case of case-sensitive match we're replacing the principal with the 
exactly same value though effectively not changing it.


--
David Kupka

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] IPA 3.0 migrated to 4.1 users break winsync agreement when deleted in active directory

[Andreas Calminder]

Hi,
thanks for your reply, I'm able to list the user with ldapsearch and I 
can't find any conflict entries described in the article. The 4.1 
environment is only 1 server connected to active directory. Forgot to 
reply to the list before, doh!


I've noticed a difference between users in 3.0 and 4.1 though, migrated 
users in the 4.1 does not have an entry in " 
cn=groups,cn=accounts,dc=sub,dc=domain,dc=tld" while users in 3.0 have this.

Example:

FreeIPA 4.1 environment:
# ldapsearch -xLLL -D "cn=directory manager" -W 
-b"cn=batman,cn=groups,cn=accounts,dc=sub,dc=domain,dc=tld"

Enter LDAP Password:
No such object (32) Matched DN: 
cn=groups,cn=accounts,dc=sub,dc=domain,dc=tld


FreeIPA 3.0 environment:
# ldapsearch -xLLL -D "cn=directory manager" -W -b 
"cn=batman,cn=groups,cn=accounts,dc=sub,dc=domain,dc=tld"

Enter LDAP Password:
dn: cn=batman,cn=groups,cn=accounts,dc=dev,dc=sub,dc=domain,dc=tld
objectClass: posixgroup
objectClass: ipaobject
objectClass: mepManagedEntry
objectClass: top
cn: batman
gidNumber: 1486600065
description: User private group for batman
mepManagedBy: uid=batman,cn=users,cn=accounts,dc=sub,dc=domain,dc=tld
ipaUniqueID: 139f6140-5074-11e5-a09d-005056914c0c

/andreas

On 09/09/2015 04:29 PM, Rich Megginson wrote:

On 09/09/2015 03:39 AM, Martin Basti wrote:



On 09/09/2015 10:50 AM, Andreas Calminder wrote:
Forgot to write that deleting users in active directory not migrated 
with the migrate-ds command works fine, it's only migrated users 
present in the ad that breaks the winsync agreement on deletion.


On 09/09/2015 10:35 AM, Andreas Calminder wrote:

Hi,
I've asked in #freeipa on freenode but to no avail, figured I'll 
ask here as well, since I think I've actually hit a bug or (quite) 
possibly I've done something moronic configuration/migration -wise.


I've got an existing FreeIPA 3.0.0 environment running with a fully 
functioning winsync agreement and passsync service with the windows 
environments active directory, I'm trying to migrate the 3.0.0 
environments users into a freshly installed 4.1 (rhel7) 
environment, after migration I setup a winsync agreement and make 
it bi-directional  (one-way sync from windows) everything seems to 
be working alright until I delete a migrated user from the Active 
Directory, after the winsync picks up on the change it'll break and 
suggests a re-initialize. After the re-initialization the agreement 
seems to be fine, however the deleted user are still present in the 
ipa 4.1 environment and cannot be deleted. The webgui and ipa cli 
says: ipauser1: user not found. ipa user-find ipauser1 finds the 
user and it's visible in the ui.


Anyone had the same problem or anything similar or any pointers on 
where to start looking?


Regards,
Andreas





Hello, this might be a replication conflict.

Can you list that user via ldapsearch to check if this is replication 
conflict?


https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html 



Use the latest docs, just in case they are more accurate: 
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html





-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] IPA 3.0 migrated to 4.1 users break winsync agreement when deleted in active directory

[Andreas Calminder]

Yes, kind of. I wanted a new environment with a proper certificate authority 
setup with only the old users and groups from the IPA 3.0 environment. The old 
environment use a self signed ca, I thought it would be easier to just migrate 
my users and groups.

On 9 Sep 2015 4:49 pm, Rob Crittenden  wrote:
Andreas Calminder wrote:
> Hi,
> thanks for your reply, I'm able to list the user with ldapsearch and I
> can't find any conflict entries described in the article. The 4.1
> environment is only 1 server connected to active directory. Forgot to
> reply to the list before, doh!
>
> I've noticed a difference between users in 3.0 and 4.1 though, migrated
> users in the 4.1 does not have an entry in "
> cn=groups,cn=accounts,dc=sub,dc=domain,dc=tld" while users in 3.0 have this.
> Example:
>
> FreeIPA 4.1 environment:
> # ldapsearch -xLLL -D "cn=directory manager" -W
> -b"cn=batman,cn=groups,cn=accounts,dc=sub,dc=domain,dc=tld"
> Enter LDAP Password:
> No such object (32) Matched DN:
> cn=groups,cn=accounts,dc=sub,dc=domain,dc=tld
>
> FreeIPA 3.0 environment:
> # ldapsearch -xLLL -D "cn=directory manager" -W -b
> "cn=batman,cn=groups,cn=accounts,dc=sub,dc=domain,dc=tld"
> Enter LDAP Password:
> dn: cn=batman,cn=groups,cn=accounts,dc=dev,dc=sub,dc=domain,dc=tld
> objectClass: posixgroup
> objectClass: ipaobject
> objectClass: mepManagedEntry
> objectClass: top
> cn: batman
> gidNumber: 1486600065
> description: User private group for batman
> mepManagedBy: uid=batman,cn=users,cn=accounts,dc=sub,dc=domain,dc=tld
> ipaUniqueID: 139f6140-5074-11e5-a09d-005056914c0c

Migrated users don't get user-private groups created.

Is there a reason you migrated from 3.0 to 4.1 rather than just adding a
4.1 master to the existing pool?

rob

>
> /andreas
>
> On 09/09/2015 04:29 PM, Rich Megginson wrote:
>> On 09/09/2015 03:39 AM, Martin Basti wrote:
>>>
>>>
>>> On 09/09/2015 10:50 AM, Andreas Calminder wrote:
 Forgot to write that deleting users in active directory not migrated
 with the migrate-ds command works fine, it's only migrated users
 present in the ad that breaks the winsync agreement on deletion.

 On 09/09/2015 10:35 AM, Andreas Calminder wrote:
> Hi,
> I've asked in #freeipa on freenode but to no avail, figured I'll
> ask here as well, since I think I've actually hit a bug or (quite)
> possibly I've done something moronic configuration/migration -wise.
>
> I've got an existing FreeIPA 3.0.0 environment running with a fully
> functioning winsync agreement and passsync service with the windows
> environments active directory, I'm trying to migrate the 3.0.0
> environments users into a freshly installed 4.1 (rhel7)
> environment, after migration I setup a winsync agreement and make
> it bi-directional  (one-way sync from windows) everything seems to
> be working alright until I delete a migrated user from the Active
> Directory, after the winsync picks up on the change it'll break and
> suggests a re-initialize. After the re-initialization the agreement
> seems to be fine, however the deleted user are still present in the
> ipa 4.1 environment and cannot be deleted. The webgui and ipa cli
> says: ipauser1: user not found. ipa user-find ipauser1 finds the
> user and it's visible in the ui.
>
> Anyone had the same problem or anything similar or any pointers on
> where to start looking?
>
> Regards,
> Andreas
>

>>>
>>> Hello, this might be a replication conflict.
>>>
>>> Can you list that user via ldapsearch to check if this is replication
>>> conflict?
>>>
>>> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html
>>>
>>>
>> Use the latest docs, just in case they are more accurate:
>> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html
>>
>>
>
>
>

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] IPA 3.0 migrated to 4.1 users break winsync agreement when deleted in active directory

[Rob Crittenden]

Andreas Calminder wrote:
> Hi,
> thanks for your reply, I'm able to list the user with ldapsearch and I
> can't find any conflict entries described in the article. The 4.1
> environment is only 1 server connected to active directory. Forgot to
> reply to the list before, doh!
> 
> I've noticed a difference between users in 3.0 and 4.1 though, migrated
> users in the 4.1 does not have an entry in "
> cn=groups,cn=accounts,dc=sub,dc=domain,dc=tld" while users in 3.0 have this.
> Example:
> 
> FreeIPA 4.1 environment:
> # ldapsearch -xLLL -D "cn=directory manager" -W
> -b"cn=batman,cn=groups,cn=accounts,dc=sub,dc=domain,dc=tld"
> Enter LDAP Password:
> No such object (32) Matched DN:
> cn=groups,cn=accounts,dc=sub,dc=domain,dc=tld
> 
> FreeIPA 3.0 environment:
> # ldapsearch -xLLL -D "cn=directory manager" -W -b
> "cn=batman,cn=groups,cn=accounts,dc=sub,dc=domain,dc=tld"
> Enter LDAP Password:
> dn: cn=batman,cn=groups,cn=accounts,dc=dev,dc=sub,dc=domain,dc=tld
> objectClass: posixgroup
> objectClass: ipaobject
> objectClass: mepManagedEntry
> objectClass: top
> cn: batman
> gidNumber: 1486600065
> description: User private group for batman
> mepManagedBy: uid=batman,cn=users,cn=accounts,dc=sub,dc=domain,dc=tld
> ipaUniqueID: 139f6140-5074-11e5-a09d-005056914c0c

Migrated users don't get user-private groups created.

Is there a reason you migrated from 3.0 to 4.1 rather than just adding a
4.1 master to the existing pool?

rob

> 
> /andreas
> 
> On 09/09/2015 04:29 PM, Rich Megginson wrote:
>> On 09/09/2015 03:39 AM, Martin Basti wrote:
>>>
>>>
>>> On 09/09/2015 10:50 AM, Andreas Calminder wrote:
 Forgot to write that deleting users in active directory not migrated
 with the migrate-ds command works fine, it's only migrated users
 present in the ad that breaks the winsync agreement on deletion.

 On 09/09/2015 10:35 AM, Andreas Calminder wrote:
> Hi,
> I've asked in #freeipa on freenode but to no avail, figured I'll
> ask here as well, since I think I've actually hit a bug or (quite)
> possibly I've done something moronic configuration/migration -wise.
>
> I've got an existing FreeIPA 3.0.0 environment running with a fully
> functioning winsync agreement and passsync service with the windows
> environments active directory, I'm trying to migrate the 3.0.0
> environments users into a freshly installed 4.1 (rhel7)
> environment, after migration I setup a winsync agreement and make
> it bi-directional  (one-way sync from windows) everything seems to
> be working alright until I delete a migrated user from the Active
> Directory, after the winsync picks up on the change it'll break and
> suggests a re-initialize. After the re-initialization the agreement
> seems to be fine, however the deleted user are still present in the
> ipa 4.1 environment and cannot be deleted. The webgui and ipa cli
> says: ipauser1: user not found. ipa user-find ipauser1 finds the
> user and it's visible in the ui.
>
> Anyone had the same problem or anything similar or any pointers on
> where to start looking?
>
> Regards,
> Andreas
>

>>>
>>> Hello, this might be a replication conflict.
>>>
>>> Can you list that user via ldapsearch to check if this is replication
>>> conflict?
>>>
>>> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html
>>>
>>>
>> Use the latest docs, just in case they are more accurate:
>> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html
>>
>>
> 
> 
> 

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCHSET] Replica promotion patches

[Simo Sorce]

On Wed, 2015-08-26 at 17:27 -0400, Simo Sorce wrote:
> This patchset implements https://fedorahosted.org/freeipa/ticket/2888
> and introduces a number of required  changes and dependencies to achieve
> this goal.
> This work requires the custodia project to securely transfer keys
> between ipa servers.
> 
> This work is not 100% complete, it still misses the ability to install
> kra instances and the ability to install a CA (via ipa-ca-install) with
> externally signed certs.
> 
> However it is massive enough that warrants review and pushing, the resat
> of the changes can be applied later as this work should not disrupt the
> classic install methods.
> 
> In order to build my previous patches (530-533) are needed as well as a
> number of updated components.
> 
> I used the following coprs for testing:
> simo/jwcrypto
> simo/custodia
> abbra/sssd-kkdcproxy (for sssd 1.13.1)
> lkrispen/389-ds-current (for 389 > 1.3.4.4)
> vakwetu/dogtag_10.2.7_test_builds (for dogtag 10.2.7)
> mkosek/freeipa-4.2-fedora-22 (misc)
> fedora/updates-testing (python-gssapi 1.1.2)
> 
> Ludwig's copr is necessary to have a functional DNA plugin in replicas,
> eventually his patches should be committed in 389-ds-base 1.3.4.4 when
> it will be released.
> 
> We are aware of a dogtag bug https://fedorahosted.org/pki/ticket/1580
> that may cause installation issues in some case (re-install of a
> replica).
> 
> The domain must be raised to level 1 in order to use replica promotion.
> 
> In order to promote a replica the server must be first joined as a
> regular client to the domain.
> 
> This is the flow I usually use for testing:
> 
> # ipa-client-install
> # kinit admin
> # ipa-replica-install --promote --setup-ca
>  etc...>
> 
> These patches are also available in this git tree rebnase on current
> master:
> https://fedorapeople.org/cgit/simo/public_git/freeipa.git/log/?h=custodia-review

FYI: I rebased this branch on top of master and applied minor changes to
one of the DNS patches. I also added the missing support to install KRA.

DS 1.3.4.4 is also in Fedora updates testing, so ludwig's copr is not
needed anymore.

Dogtag's ticket is not fixed yet so running both --setup-ca and
--setup-kra at the same time will still yield an error and install will
fail.

Please let me know if there are any major issues with this patchset, I'd
like to push it to master and attack the remaining issues as add ons
(install with external certs not supported yet for example)

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH] 916 vault: add vault container commands

[Petr Vobornik]

On 09/09/2015 10:52 AM, Jan Cholasta wrote:

On 8.9.2015 23:06, Petr Vobornik wrote:

On 09/03/2015 03:18 PM, Jan Cholasta wrote:

On 2.9.2015 07:26, Endi Sukma Dewata wrote:

On 9/1/2015 10:22 AM, Simo Sorce wrote:

On Tue, 2015-09-01 at 17:15 +0200, Petr Vobornik wrote:

On 09/01/2015 04:39 PM, Jan Cholasta wrote:

On 1.9.2015 16:26, Jan Cholasta wrote:

On 26.8.2015 13:22, Petr Vobornik wrote:

On 08/25/2015 08:04 PM, Petr Vobornik wrote:

adds commands:
* vaultcontainer-show [--service |--user  ]
* vaultcontainer-add-owner
   [--service |--user  ]
   [--users ]  [--groups ] [--services
]
* vaultcontainer-remove-owner
   [--service |--user  ]
   [--users ]  [--groups ] [--services
]

https://fedorahosted.org/freeipa/ticket/5250

Use cases:
1. When user/service is deleted, associated vault container
looses
owner. There was no API command to set the owner.
2. Change owner of container by admin to manage access.

Show command was added to show current owners.

Find command was not added, should it be?




There is also a design for vault container ownership handling
created by
Endi - it's for future Vault 2.0.

http://www.freeipa.org/page/V4/Password_Vault_2.0#Adding_container_owner





This patch has a different API than the proposed - different
way of
specifying the container. The design page uses path e.g.
/users/foobar.
This patch uses the same way as vaults e.g. --user=foobar. This
means
that the implementation in this patch cannot manage ownership of
parent
vault containers e.g. cn=users,cn=vaults,cn=kra,$SUFFIX.

Do we want to go with this approach in 4.2?

Attaching also new path which removes setting of owner which
doesn't
exist so that integrity is OK and that it is consistent with
removing of
user.

Updated patch attached - output fix.


We had a long discussion about this with Petr and we think the best
approach is as follows:

* Add new "Vault administrators" privilege. Vault
administrators will
have unrestricted access to vaults and vault containers, including
the
power to add/remove owners of vaults and vault containers.

* Remove the ability of vault owners to add/remove other vault
owners. If vault owner needs to be changed, vault administrator
has to
do it. Note that vault owners will still have the ability to
add/remove
vault members.

* When adding new vault container, set owner to the current
user. If
vault container owner needs to be changed, vault administrator has
to do
it.

* Allow adding vaults and vault containers only if the owner is
set
to the current user.

* Introduce commands to modify vault container owner and to
delete
vault container, so the administrator has a choice between
assigning
ownership or deleting an unowned container.


Also:

* Control access to vault data using an ipaProtectedOperation
ACI.
Users which have read access to "ipaProtectedOperation;accessKRA"
on a
vault can retrieve data from the vault and users which have write
access
to "ipaProtectedOperation;accessKRA" on a vault can archive data in
the
vault.

Honza



+1

CCing Simo and Endi to check the proposal.

And Scott (related to #5216, #5215)


Sounds reasonable to me.
I can see that allowing owners to hand over vaults w/o admin
intervention may have some appeal in some use cases, but I also see it
can bring downsides with it, so all in all I think I agree with the
above points.

Simo.



Not a total objection, but if many people in unrelated groups are using
vaults, and they are sharing the vaults only with members of each
group,
having to ask a Vault Administrator for each ownership change sounds a
bit cumbersome. Since the Vault Adminstrator will have access to all
vaults in all groups, only a small number of people can be trusted to
hold that role. If there are many ownership changes the Vault
Administrator will have to handle all those requests, and the vault
users may have to wait until the change is completed.

If owners are allowed to add others as owners, the vaults will be
pretty
much maintenance free to the admin.


Owners can still manage members, which is IMO good enough for sharing a
vault with other users.



Regardless, please update the wiki page to describe the new behavior
when it's implemented:
http://www.freeipa.org/page/V4/Password_Vault_1.1


Sure.

I have updated and rebased Petr's patch 916.

Patch 488 obsoletes Petr's patch 918.

Patch for vault data access control is not included, because I was not
able to make GER work correctly with "ipaProtectedOperation;accessKRA".



I found 1 major issue(#3), one easy fix(#2), optional(#1) and a question
(#4).

1. `ipa vaultcontainer-del` doesn't show user/service name. IMHO not a
blocker.

[pvoborni@vm-063 ~]$ ipa vaultcontainer-del --user=fbar
--
Deleted vault container ""
--


Fixed.




2. Invalid description of vaultcontainer-show
   "Display information about a vault."


Fixed



3. Something which needs to be fixed:

Setting password for 

Re: [Freeipa-devel] IPA 3.0 migrated to 4.1 users break winsync agreement when deleted in active directory

[Andreas Calminder]

Hi,
I just wanted to post the solution for this, I've reported this to Redhat and a 
bug has been filed (https://bugzilla.redhat.com/1261536). The problem was that 
migrate-ds copied the attribute mepManagedEntry on migration, the suggested 
workaround, running migrate-ds with --user-ignore-attribute=mepManagedEntry 
--user-ignore-objectclass=mepOriginEntry worked like a charm (Thanks Rob!), 
deleting users in active directory doesn't break the winsync agreement and I'm 
able to delete migrated users directly in ipa. As mentioned in the bug 
comments, migrate-ds isn't really for ipa to ipa migration. However, it kind of 
worked...

/andreas

From: freeipa-devel-boun...@redhat.com 
[mailto:freeipa-devel-boun...@redhat.com] On Behalf Of Andreas Calminder
Sent: den 9 september 2015 17:16
To: freeipa-devel@redhat.com
Subject: Re: [Freeipa-devel] IPA 3.0 migrated to 4.1 users break winsync 
agreement when deleted in active directory

Yes, kind of. I wanted a new environment with a proper certificate authority 
setup with only the old users and groups from the IPA 3.0 environment. The old 
environment use a self signed ca, I thought it would be easier to just migrate 
my users and groups.
On 9 Sep 2015 4:49 pm, Rob Crittenden  wrote:
Andreas Calminder wrote:
> Hi,
> thanks for your reply, I'm able to list the user with ldapsearch and I
> can't find any conflict entries described in the article. The 4.1
> environment is only 1 server connected to active directory. Forgot to
> reply to the list before, doh!
> 
> I've noticed a difference between users in 3.0 and 4.1 though, migrated
> users in the 4.1 does not have an entry in "
> cn=groups,cn=accounts,dc=sub,dc=domain,dc=tld" while users in 3.0 have this.
> Example:
> 
> FreeIPA 4.1 environment:
> # ldapsearch -xLLL -D "cn=directory manager" -W
> -b"cn=batman,cn=groups,cn=accounts,dc=sub,dc=domain,dc=tld"
> Enter LDAP Password:
> No such object (32) Matched DN:
> cn=groups,cn=accounts,dc=sub,dc=domain,dc=tld
> 
> FreeIPA 3.0 environment:
> # ldapsearch -xLLL -D "cn=directory manager" -W -b
> "cn=batman,cn=groups,cn=accounts,dc=sub,dc=domain,dc=tld"
> Enter LDAP Password:
> dn: cn=batman,cn=groups,cn=accounts,dc=dev,dc=sub,dc=domain,dc=tld
> objectClass: posixgroup
> objectClass: ipaobject
> objectClass: mepManagedEntry
> objectClass: top
> cn: batman
> gidNumber: 1486600065
> description: User private group for batman
> mepManagedBy: uid=batman,cn=users,cn=accounts,dc=sub,dc=domain,dc=tld
> ipaUniqueID: 139f6140-5074-11e5-a09d-005056914c0c

Migrated users don't get user-private groups created.

Is there a reason you migrated from 3.0 to 4.1 rather than just adding a
4.1 master to the existing pool?

rob

> 
> /andreas
> 
> On 09/09/2015 04:29 PM, Rich Megginson wrote:
>> On 09/09/2015 03:39 AM, Martin Basti wrote:
>>>
>>>
>>> On 09/09/2015 10:50 AM, Andreas Calminder wrote:
 Forgot to write that deleting users in active directory not migrated
 with the migrate-ds command works fine, it's only migrated users
 present in the ad that breaks the winsync agreement on deletion.

 On 09/09/2015 10:35 AM, Andreas Calminder wrote:
> Hi,
> I've asked in #freeipa on freenode but to no avail, figured I'll
> ask here as well, since I think I've actually hit a bug or (quite)
> possibly I've done something moronic configuration/migration -wise.
>
> I've got an existing FreeIPA 3.0.0 environment running with a fully
> functioning winsync agreement and passsync service with the windows
> environments active directory, I'm trying to migrate the 3.0.0
> environments users into a freshly installed 4.1 (rhel7)
> environment, after migration I setup a winsync agreement and make
> it bi-directional  (one-way sync from windows) everything seems to
> be working alright until I delete a migrated user from the Active
> Directory, after the winsync picks up on the change it'll break and
> suggests a re-initialize. After the re-initialization the agreement
> seems to be fine, however the deleted user are still present in the
> ipa 4.1 environment and cannot be deleted. The webgui and ipa cli
> says: ipauser1: user not found. ipa user-find ipauser1 finds the
> user and it's visible in the ui.
>
> Anyone had the same problem or anything similar or any pointers on
> where to start looking?
>
> Regards,
> Andreas
>

>>>
>>> Hello, this might be a replication conflict.
>>>
>>> Can you list that user via ldapsearch to check if this is replication
>>> conflict?
>>>
>>> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html
>>>
>>>
>> Use the latest docs, just in case they are more accurate:
>>