Re: [Freeipa-users] getcert, multiple alternative names (SANs), and wildcard certificates

2017-04-03 Thread Fraser Tweedale 
On Mon, Apr 03, 2017 at 04:17:13PM -0700, Wim Lewis wrote:

> I'm trying to provision a client with a wildcard certificate[1]. I
> followed the procedure outlined in [2], but I'm not receiving the
> certificate I expect. The certificate's subject DN contains a
> wildcard string, but the SAN does not. Since the SAN, not the
> subject name, is the relevant part of the certificate [3], this
> isn't the right certificate.
> 
> What I want is a certificate with two SAN entries, a dNSName for
> "blah.example.com" and another dNSName for "*.blah.example.com".
> But if I request the additional SAN (by passing "-D
> 'blah.example.com' -D '*.blah.example.com'" to getcert) then the
> request fails:
> 
> status: CA_UNREACHABLE
>   ca-error: Server at https://ipa.example.com/ipa/xml failed
>   request, will retry: 4001 (RPC failed at server.  The
>   service principal for subject alt name *.blah.example.com in
>   certificate request does not exist).
> 
> How do I tell FreeIPA that it is OK for it to issue a cert with an
> additional SAN to my host principal?
> 

The only way is to create a profile that hard-codes the desired SAN
data, then use that profile.

The observed behaviour is because FreeIPA's CSR processing checks
that all SAN values present in the CSR actually correspond to the
indicated subject principal(s).  In your case, there is no principal
that has a wildcard in its name, so the cert request gets rejected.

We are not planning to change FreeIPA to support wildcard dnsNames
in SAN.  More commentary below.

> 
> [1] Why am I using a wildcard certificate despite it being easy to
> issue certs from FreeIPA? I'm using it with sandstorm.io, which
> creates a randomly named subdomain for essentially every session.
> This is a reasonable use of wildcard certificates, as I understand
> it, since all of the domains are served from the same process and
> no other domain can match the cert's wildcard - sandstorm owns the
> dns hierarchy under its root.
>
Is your instance publicly hosted?  Perhaps the sandstorm.io
developers could support ACME/Let's Encrypt so that certs can be
automatically acquired for each domain...

> [2] https://www.freeipa.org/page/Howto/Wildcard_certificates
 
> [3] See RFC6125 [B.2], based on RFC 2818, which describes what
> part of the certificate the browser should look at to see if the
> certificate matches the expected hostname. In short, as far as
> HTTPS is concerned, if there are DNS SANs, then the subject field
> of the server's certificate (and its CN) is irrelevant.
>
This is correct.

But see also ยง7.2 which states that wildcard certs are deprecated :)
https://tools.ietf.org/html/rfc6125#section-7.2

Thanks,
Fraser

-- 
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] Upgrade from IPA 4.2

2017-04-03 Thread Lachlan Musicman 
On 4 April 2017 at 04:28, Andrey Ptashnik  wrote:

> Hello,
>
> We have Centos 7.2 and IPA 4.2 version.
> I remember that in previous versions in order to upgrade to the latest one
> I had to run IPA upgrade scripts that would separately upgrade LDAP
> database. Is that the same procedure if I need to upgrade from version 4.2?
>
>

Andrey,

That wasn't my experience. We just did a yum update and it all seemed to
work.

Given it's role, I presume you have or can set up a test env you can try it
on?

cheers
L.

--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper
-- 
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] subdomain errors

2017-04-03 Thread Lachlan Musicman 
On 4 April 2017 at 01:35, Alexander Bokovoy  wrote:

> On ma, 03 huhti 2017, Orion Poplawski wrote:
>
>> On 04/03/2017 09:03 AM, Orion Poplawski wrote:
>>
>>> On 04/03/2017 02:08 AM, Jakub Hrozek wrote:
>>>
 On Fri, Mar 31, 2017 at 05:08:13PM -0600, Orion Poplawski wrote:

>>>
>>> I'm seeing:
>>
>> [03/Apr/2017:09:07:34.269247507 -0600] sidgen_task_thread - [file
>> ipa_sidgen_task.c, line 194]: Sidgen task starts ...
>> [03/Apr/2017:09:07:34.273308903 -0600] find_sid_for_ldap_entry - [file
>> ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [24613] into an
>> unused
>> SID.
>> [03/Apr/2017:09:07:34.274521892 -0600] do_work - [file
>> ipa_sidgen_task.c, line
>> 154]: Cannot add SID to existing entry.
>> [03/Apr/2017:09:07:34.277196405 -0600] sidgen_task_thread - [file
>> ipa_sidgen_task.c, line 199]: Sidgen task finished [32].
>>
> Look at this list's archives, I've been giving recipes how to fix this
> in February.
>
> My IPA ranges are:
>>
>> # ipa idrange-find
>> 
>> 2 ranges matched
>> 
>>  Range name: AD.NWRA.COM_id_range
>>  First Posix ID of the range: 2
>>  Number of IDs in the range: 2
>>  First RID of the corresponding RID range: 0
>>  Domain SID of the trusted domain: S-1-5-21-89655523-1570529619-2
>> 103694531
>>  Range type: Active Directory domain range
>>
>>  Range name: NWRA.COM_id_range
>>  First Posix ID of the range: 8000
>>  Number of IDs in the range: 2000
>>  First RID of the corresponding RID range: 1000
>>  First RID of the secondary RID range: 1
>>  Range type: local domain range
>> 
>> Number of entries returned 2
>> 
>>
>> So I've been creating these local posix IPA groups for HBAC access (as
>> well as
>> file storage) with the same gid as that assigned to the AD user.  Perhaps
>> that
>> is a problem?
>>
> Yes, that is a problem. But HBAC group is not a problem because HBAC
> group is not a POSIX IPA group at all, it is even stored in a different
> subtree than user groups.
>
>
Can you expand on this please? In what way is this a problem?

We also have local posix IPA groups with the same gid as that assigned to
the AD user (for historical reasons to do with samba shares on networked
disks).

We don't use those groups for HBAC though, we use AD group membership
through external groups for HBAC. (I use the term "we use HBAC" loosely -
it's still in testing :) )

cheers
L.
-- 
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] libsemanage updates fail due to AD user with space

2017-04-03 Thread Lachlan Musicman 
On 3 April 2017 at 19:11, Jakub Hrozek  wrote:

> On Mon, Apr 03, 2017 at 11:00:21AM +1000, Lachlan Musicman wrote:
> >
> > With SSSD/IPA in use, in a one way trust to AD, and AD users have spaces
> in
> > their names, libsemanage fails to update:
> >
> > eg from recent monthly upgrade cycle:
> >
> > Updating   :
> > selinux-policy-targeted-3.13.1-102.el7_3.16.noarch
> > 3/14
> > libsemanage.parse_assert_ch: expected character ':', but found 'f'
> > (/etc/selinux/targeted/tmp/seusers.local: 5):
> > lastname firstn...@domain.com:unconfined_u:s0-s0:c0.c1023 (No such file
> or
> > directory).
> > libsemanage.seuser_parse: could not parse seuser record (No such file or
> > directory).
> > libsemanage.dbase_file_cache: could not cache file database (No such file
> > or directory).
> > libsemanage.semanage_base_merge_components: could not merge local
> > modifications into policy (No such file or directory).
> >
>
> Hi,
> according to my quick testing this is solved with this PR:
> https://github.com/SSSD/sssd/pull/189
> (Please note that we haven't ran all regression tests on this PR so I
> can't in fact tell if it's correct or not. The code does look OK,
> though).
>
> I was also able to work around the issue by setting:
> override_space = _
> in sssd.conf
>


Thanks Jakub. The problem with the override_space = _ is that we also have
users with _ in their names. I understand that this could be any character,
but we decided that - given what we know about our AD - any character could
also be in a user name.

Looking forward to seeing the patch in upcoming releases.

Cheers
L.


--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper
-- 
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] getcert, multiple alternative names (SANs), and wildcard certificates

2017-04-03 Thread Wim Lewis 
I'm trying to provision a client with a wildcard certificate[1]. I followed the 
procedure outlined in [2], but I'm not receiving the certificate I expect. The 
certificate's subject DN contains a wildcard string, but the SAN does not. 
Since the SAN, not the subject name, is the relevant part of the certificate 
[3], this isn't the right certificate.

What I want is a certificate with two SAN entries, a dNSName for 
"blah.example.com" and another dNSName for "*.blah.example.com". But if I 
request the additional SAN (by passing "-D 'blah.example.com' -D 
'*.blah.example.com'" to getcert) then the request fails:

status: CA_UNREACHABLE
ca-error: Server at https://ipa.example.com/ipa/xml failed request, 
will retry: 4001 (RPC failed at server.  The service principal for subject alt 
name *.blah.example.com in certificate request does not exist).

How do I tell FreeIPA that it is OK for it to issue a cert with an additional 
SAN to my host principal?


[1] Why am I using a wildcard certificate despite it being easy to issue certs 
from FreeIPA? I'm using it with sandstorm.io, which creates a randomly named 
subdomain for essentially every session. This is a reasonable use of wildcard 
certificates, as I understand it, since all of the domains are served from the 
same process and no other domain can match the cert's wildcard - sandstorm owns 
the dns hierarchy under its root.

[2] https://www.freeipa.org/page/Howto/Wildcard_certificates

[3] See RFC6125 [B.2], based on RFC 2818, which describes what part of the 
certificate the browser should look at to see if the certificate matches the 
expected hostname. In short, as far as HTTPS is concerned, if there are DNS 
SANs, then the subject field of the server's certificate (and its CN) is 
irrelevant.



-- 
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] Upgrade from IPA 4.2

2017-04-03 Thread Andrey Ptashnik 
Hello,

We have Centos 7.2 and IPA 4.2 version.
I remember that in previous versions in order to upgrade to the latest one I 
had to run IPA upgrade scripts that would separately upgrade LDAP database. Is 
that the same procedure if I need to upgrade from version 4.2?

Regards,

Andrey

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

2017-04-03 Thread Alexander Bokovoy 

On ma, 03 huhti 2017, Jakub Hrozek wrote:

On Mon, Apr 03, 2017 at 06:32:49PM +0300, Alexander Bokovoy wrote:

On ma, 03 huhti 2017, Orion Poplawski wrote:
> On 04/03/2017 02:10 AM, Alexander Bokovoy wrote:
> > On ma, 03 huhti 2017, Jakub Hrozek wrote:
> > > On Fri, Mar 31, 2017 at 04:07:16PM -0600, Orion Poplawski wrote:
> > > > I'm seeing messages like this:
> > > >
> > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]]
> > > > [ipa_add_ad_memberships_get_next] (0x0020): There are unresolved 
external
> > > > group memberships even after all groups have been looked up on the LDAP
> > > > server.
> > > >
> > > > and wondering it is anything to worry about.
> > > >
> > > >
> > > > Some context:
> > > >
> > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] 
[sysdb_cache_search_groups]
> > > > (0x2000): Search groups with filter:
> > > > 
(&(objectclass=group)(originalDN=ipaUniqueID=12d2026e-a5cd-11e5-a14e-00163e2d6456,cn=hbac,dc=nwra,dc=com))
> > > >
> > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] 
[sysdb_cache_search_groups]
> > > > (0x2000): No such entry
> > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] 
[sysdb_cache_search_groups]
> > > > (0x2000): Search groups with filter:
> > > > 
(&(objectclass=group)(originalDN=cn=nwra,cn=groups,cn=accounts,dc=nwra,dc=com))
> > > >
> > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [merge_msg_ts_attrs] 
(0x2000):
> > > > No such DN in the timestamp cache:
> > > > name=n...@nwra.com,cn=groups,cn=nwra.com,cn=sysdb
> > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] 
[sysdb_merge_res_ts_attrs]
> > > > (0x2000): TS cache doesn't contain this DN, skipping
> > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] 
[sdap_get_groups_next_base]
> > > > (0x0400): Searching for groups with base [cn=accounts,dc=nwra,dc=com]
> > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_print_server] 
(0x2000):
> > > > Searching 10.10.41.4:389
> > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] 
[sdap_get_generic_ext_step]
> > > > (0x0400): calling ldap_search_ext with
> > > > 
[(&(cn=12d2026e-a5cd-11e5-a14e-00163e2d6456)(|(objectClass=ipaUserGroup)(objectClass=posixGroup))(cn=*)(&(gidNumber=*)(!(gidNumber=0][cn=accounts,dc=nwra,dc=com].
> > > >
> > >
> > > I think this might be the reason why SSSD reports unresolved
> > > memberships. It'trying to resolve the group using the cn attribute, ut
> > > the object's RDN attribute seems to be ipaUniqueID. So I don't think
> > > this is harmful, just confusing.
> > >
> > > Can you please check what the object is on the IPA side with this
> > > ipaUniqueID?
> > It is HBAC group -- see above in the log:
> > 
(&(objectclass=group)(originalDN=ipaUniqueID=12d2026e-a5cd-11e5-a14e-00163e2d6456,cn=hbac,dc=nwra,dc=com))
>
> This is our "allow employees access" HBAC group.  So it applies to our "nwra"
> host group as well as a couple individual machines, and to our "nwra" IPA 
group.
It is HBAC group, not a normal POSIX user group, so SSSD shouldn't even
look at it for a POSIX user membership.


Right, I'll try to reproduce at least the error message locally to try
if we can suppress it (by skipping the HBAC group). At the very least
the error message is confusing for admins.

It may also be related to the issue of not setting proper base for
searches in case of IPA provider for some times of searches.
--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ipa_add_ad_memberships_get_next errors

2017-04-03 Thread Jakub Hrozek 
On Mon, Apr 03, 2017 at 06:32:49PM +0300, Alexander Bokovoy wrote:
> On ma, 03 huhti 2017, Orion Poplawski wrote:
> > On 04/03/2017 02:10 AM, Alexander Bokovoy wrote:
> > > On ma, 03 huhti 2017, Jakub Hrozek wrote:
> > > > On Fri, Mar 31, 2017 at 04:07:16PM -0600, Orion Poplawski wrote:
> > > > > I'm seeing messages like this:
> > > > > 
> > > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]]
> > > > > [ipa_add_ad_memberships_get_next] (0x0020): There are unresolved 
> > > > > external
> > > > > group memberships even after all groups have been looked up on the 
> > > > > LDAP
> > > > > server.
> > > > > 
> > > > > and wondering it is anything to worry about.
> > > > > 
> > > > > 
> > > > > Some context:
> > > > > 
> > > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] 
> > > > > [sysdb_cache_search_groups]
> > > > > (0x2000): Search groups with filter:
> > > > > (&(objectclass=group)(originalDN=ipaUniqueID=12d2026e-a5cd-11e5-a14e-00163e2d6456,cn=hbac,dc=nwra,dc=com))
> > > > > 
> > > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] 
> > > > > [sysdb_cache_search_groups]
> > > > > (0x2000): No such entry
> > > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] 
> > > > > [sysdb_cache_search_groups]
> > > > > (0x2000): Search groups with filter:
> > > > > (&(objectclass=group)(originalDN=cn=nwra,cn=groups,cn=accounts,dc=nwra,dc=com))
> > > > > 
> > > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [merge_msg_ts_attrs] 
> > > > > (0x2000):
> > > > > No such DN in the timestamp cache:
> > > > > name=n...@nwra.com,cn=groups,cn=nwra.com,cn=sysdb
> > > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] 
> > > > > [sysdb_merge_res_ts_attrs]
> > > > > (0x2000): TS cache doesn't contain this DN, skipping
> > > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] 
> > > > > [sdap_get_groups_next_base]
> > > > > (0x0400): Searching for groups with base [cn=accounts,dc=nwra,dc=com]
> > > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_print_server] 
> > > > > (0x2000):
> > > > > Searching 10.10.41.4:389
> > > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] 
> > > > > [sdap_get_generic_ext_step]
> > > > > (0x0400): calling ldap_search_ext with
> > > > > [(&(cn=12d2026e-a5cd-11e5-a14e-00163e2d6456)(|(objectClass=ipaUserGroup)(objectClass=posixGroup))(cn=*)(&(gidNumber=*)(!(gidNumber=0][cn=accounts,dc=nwra,dc=com].
> > > > > 
> > > > 
> > > > I think this might be the reason why SSSD reports unresolved
> > > > memberships. It'trying to resolve the group using the cn attribute, ut
> > > > the object's RDN attribute seems to be ipaUniqueID. So I don't think
> > > > this is harmful, just confusing.
> > > > 
> > > > Can you please check what the object is on the IPA side with this
> > > > ipaUniqueID?
> > > It is HBAC group -- see above in the log:
> > > (&(objectclass=group)(originalDN=ipaUniqueID=12d2026e-a5cd-11e5-a14e-00163e2d6456,cn=hbac,dc=nwra,dc=com))
> > 
> > This is our "allow employees access" HBAC group.  So it applies to our 
> > "nwra"
> > host group as well as a couple individual machines, and to our "nwra" IPA 
> > group.
> It is HBAC group, not a normal POSIX user group, so SSSD shouldn't even
> look at it for a POSIX user membership.

Right, I'll try to reproduce at least the error message locally to try
if we can suppress it (by skipping the HBAC group). At the very least
the error message is confusing for admins.

-- 
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] subdomain errors

2017-04-03 Thread Alexander Bokovoy 

On ma, 03 huhti 2017, Orion Poplawski wrote:

On 04/03/2017 09:03 AM, Orion Poplawski wrote:

On 04/03/2017 02:08 AM, Jakub Hrozek wrote:

On Fri, Mar 31, 2017 at 05:08:13PM -0600, Orion Poplawski wrote:

I seem to be having some issues with users/groups that may be leading to
errors in the subdomain status.  Can anyone parse this for me?

(Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_cache_entry_attr]
(0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object (32)]
(Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_entry_attr]
(0x0080): Cannot set ts attrs for
name=u...@ad.nwra.com,cn=users,cn=ad.nwra.com,cn=sysdb


This can be ignored, it's just a minor performance annoyance we track
upstream.


Figured something like that, but thanks.


(Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_cache_entry_attr]
(0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object (32)]
(Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_entry_attr]
(0x0080): Cannot set ts attrs for
name=u...@ad.nwra.com,cn=users,cn=ad.nwra.com,cn=sysdb
(Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]]
[ipa_initgr_get_overrides_step] (0x0040): The group
name=u...@nwra.com,cn=groups,cn=nwra.com,cn=sysdb has no UUID attribute
objectSIDString, error!


But this seems strange. Before you sanitized (presumably?) the logs, did
the DN name=u...@nwra.com,cn=groups,cn=nwra.com,cn=sysdb correspond to
an IPA object?


Yes, it's an IPA group used for HBAC access.


Did you run the sidgen task when setting up trusts or did you make sure
all replicas are either trust controllers or trust agents? Does the
entry on the IPA LDAP side have ipaNTSecurityIdentifier attribute?


I suspect the sidgen task has not been run, as I'm not really sure what that
is.  I have belatedly installed and run ipa-adtrust-install on all of our IPA
servers, though a couple ran without that for a while.  It does not look like
that group has an ipaNTSecurityIdentifier atribute.


I'm seeing:

[03/Apr/2017:09:07:34.269247507 -0600] sidgen_task_thread - [file
ipa_sidgen_task.c, line 194]: Sidgen task starts ...
[03/Apr/2017:09:07:34.273308903 -0600] find_sid_for_ldap_entry - [file
ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [24613] into an unused
SID.
[03/Apr/2017:09:07:34.274521892 -0600] do_work - [file ipa_sidgen_task.c, line
154]: Cannot add SID to existing entry.
[03/Apr/2017:09:07:34.277196405 -0600] sidgen_task_thread - [file
ipa_sidgen_task.c, line 199]: Sidgen task finished [32].

Look at this list's archives, I've been giving recipes how to fix this
in February.


My IPA ranges are:

# ipa idrange-find

2 ranges matched

 Range name: AD.NWRA.COM_id_range
 First Posix ID of the range: 2
 Number of IDs in the range: 2
 First RID of the corresponding RID range: 0
 Domain SID of the trusted domain: S-1-5-21-89655523-1570529619-2103694531
 Range type: Active Directory domain range

 Range name: NWRA.COM_id_range
 First Posix ID of the range: 8000
 Number of IDs in the range: 2000
 First RID of the corresponding RID range: 1000
 First RID of the secondary RID range: 1
 Range type: local domain range

Number of entries returned 2


So I've been creating these local posix IPA groups for HBAC access (as well as
file storage) with the same gid as that assigned to the AD user.  Perhaps that
is a problem?

Yes, that is a problem. But HBAC group is not a problem because HBAC
group is not a POSIX IPA group at all, it is even stored in a different
subtree than user groups.

--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ipa_add_ad_memberships_get_next errors

2017-04-03 Thread Alexander Bokovoy 

On ma, 03 huhti 2017, Orion Poplawski wrote:

On 04/03/2017 02:10 AM, Alexander Bokovoy wrote:

On ma, 03 huhti 2017, Jakub Hrozek wrote:

On Fri, Mar 31, 2017 at 04:07:16PM -0600, Orion Poplawski wrote:

I'm seeing messages like this:

(Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]]
[ipa_add_ad_memberships_get_next] (0x0020): There are unresolved external
group memberships even after all groups have been looked up on the LDAP
server.

and wondering it is anything to worry about.


Some context:

(Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_cache_search_groups]
(0x2000): Search groups with filter:
(&(objectclass=group)(originalDN=ipaUniqueID=12d2026e-a5cd-11e5-a14e-00163e2d6456,cn=hbac,dc=nwra,dc=com))

(Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_cache_search_groups]
(0x2000): No such entry
(Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_cache_search_groups]
(0x2000): Search groups with filter:
(&(objectclass=group)(originalDN=cn=nwra,cn=groups,cn=accounts,dc=nwra,dc=com))

(Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [merge_msg_ts_attrs] (0x2000):
No such DN in the timestamp cache:
name=n...@nwra.com,cn=groups,cn=nwra.com,cn=sysdb
(Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_merge_res_ts_attrs]
(0x2000): TS cache doesn't contain this DN, skipping
(Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_groups_next_base]
(0x0400): Searching for groups with base [cn=accounts,dc=nwra,dc=com]
(Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_print_server] (0x2000):
Searching 10.10.41.4:389
(Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step]
(0x0400): calling ldap_search_ext with
[(&(cn=12d2026e-a5cd-11e5-a14e-00163e2d6456)(|(objectClass=ipaUserGroup)(objectClass=posixGroup))(cn=*)(&(gidNumber=*)(!(gidNumber=0][cn=accounts,dc=nwra,dc=com].



I think this might be the reason why SSSD reports unresolved
memberships. It'trying to resolve the group using the cn attribute, ut
the object's RDN attribute seems to be ipaUniqueID. So I don't think
this is harmful, just confusing.

Can you please check what the object is on the IPA side with this
ipaUniqueID?

It is HBAC group -- see above in the log:
(&(objectclass=group)(originalDN=ipaUniqueID=12d2026e-a5cd-11e5-a14e-00163e2d6456,cn=hbac,dc=nwra,dc=com))


This is our "allow employees access" HBAC group.  So it applies to our "nwra"
host group as well as a couple individual machines, and to our "nwra" IPA group.

It is HBAC group, not a normal POSIX user group, so SSSD shouldn't even
look at it for a POSIX user membership.


--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] subdomain errors

2017-04-03 Thread Orion Poplawski 
On 04/03/2017 09:03 AM, Orion Poplawski wrote:
> On 04/03/2017 02:08 AM, Jakub Hrozek wrote:
>> On Fri, Mar 31, 2017 at 05:08:13PM -0600, Orion Poplawski wrote:
>>> I seem to be having some issues with users/groups that may be leading to
>>> errors in the subdomain status.  Can anyone parse this for me?
>>>
>>> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_cache_entry_attr]
>>> (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object 
>>> (32)]
>>> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_entry_attr]
>>> (0x0080): Cannot set ts attrs for
>>> name=u...@ad.nwra.com,cn=users,cn=ad.nwra.com,cn=sysdb
>>
>> This can be ignored, it's just a minor performance annoyance we track
>> upstream.
> 
> Figured something like that, but thanks.
> 
>>> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_cache_entry_attr]
>>> (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object 
>>> (32)]
>>> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_entry_attr]
>>> (0x0080): Cannot set ts attrs for
>>> name=u...@ad.nwra.com,cn=users,cn=ad.nwra.com,cn=sysdb
>>> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]]
>>> [ipa_initgr_get_overrides_step] (0x0040): The group
>>> name=u...@nwra.com,cn=groups,cn=nwra.com,cn=sysdb has no UUID attribute
>>> objectSIDString, error!
>>
>> But this seems strange. Before you sanitized (presumably?) the logs, did
>> the DN name=u...@nwra.com,cn=groups,cn=nwra.com,cn=sysdb correspond to
>> an IPA object?
> 
> Yes, it's an IPA group used for HBAC access.
> 
>> Did you run the sidgen task when setting up trusts or did you make sure
>> all replicas are either trust controllers or trust agents? Does the
>> entry on the IPA LDAP side have ipaNTSecurityIdentifier attribute?
> 
> I suspect the sidgen task has not been run, as I'm not really sure what that
> is.  I have belatedly installed and run ipa-adtrust-install on all of our IPA
> servers, though a couple ran without that for a while.  It does not look like
> that group has an ipaNTSecurityIdentifier atribute.

I'm seeing:

[03/Apr/2017:09:07:34.269247507 -0600] sidgen_task_thread - [file
ipa_sidgen_task.c, line 194]: Sidgen task starts ...
[03/Apr/2017:09:07:34.273308903 -0600] find_sid_for_ldap_entry - [file
ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [24613] into an unused
SID.
[03/Apr/2017:09:07:34.274521892 -0600] do_work - [file ipa_sidgen_task.c, line
154]: Cannot add SID to existing entry.
[03/Apr/2017:09:07:34.277196405 -0600] sidgen_task_thread - [file
ipa_sidgen_task.c, line 199]: Sidgen task finished [32].

My IPA ranges are:

# ipa idrange-find

2 ranges matched

  Range name: AD.NWRA.COM_id_range
  First Posix ID of the range: 2
  Number of IDs in the range: 2
  First RID of the corresponding RID range: 0
  Domain SID of the trusted domain: S-1-5-21-89655523-1570529619-2103694531
  Range type: Active Directory domain range

  Range name: NWRA.COM_id_range
  First Posix ID of the range: 8000
  Number of IDs in the range: 2000
  First RID of the corresponding RID range: 1000
  First RID of the secondary RID range: 1
  Range type: local domain range

Number of entries returned 2


So I've been creating these local posix IPA groups for HBAC access (as well as
file storage) with the same gid as that assigned to the AD user.  Perhaps that
is a problem?


-- 
Orion Poplawski
Technical Manager  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] subdomain errors

2017-04-03 Thread Orion Poplawski 
On 04/03/2017 02:08 AM, Jakub Hrozek wrote:
> On Fri, Mar 31, 2017 at 05:08:13PM -0600, Orion Poplawski wrote:
>> I seem to be having some issues with users/groups that may be leading to
>> errors in the subdomain status.  Can anyone parse this for me?
>>
>> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_cache_entry_attr]
>> (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object 
>> (32)]
>> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_entry_attr]
>> (0x0080): Cannot set ts attrs for
>> name=u...@ad.nwra.com,cn=users,cn=ad.nwra.com,cn=sysdb
> 
> This can be ignored, it's just a minor performance annoyance we track
> upstream.

Figured something like that, but thanks.

>> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_cache_entry_attr]
>> (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object 
>> (32)]
>> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_entry_attr]
>> (0x0080): Cannot set ts attrs for
>> name=u...@ad.nwra.com,cn=users,cn=ad.nwra.com,cn=sysdb
>> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]]
>> [ipa_initgr_get_overrides_step] (0x0040): The group
>> name=u...@nwra.com,cn=groups,cn=nwra.com,cn=sysdb has no UUID attribute
>> objectSIDString, error!
> 
> But this seems strange. Before you sanitized (presumably?) the logs, did
> the DN name=u...@nwra.com,cn=groups,cn=nwra.com,cn=sysdb correspond to
> an IPA object?

Yes, it's an IPA group used for HBAC access.

> Did you run the sidgen task when setting up trusts or did you make sure
> all replicas are either trust controllers or trust agents? Does the
> entry on the IPA LDAP side have ipaNTSecurityIdentifier attribute?

I suspect the sidgen task has not been run, as I'm not really sure what that
is.  I have belatedly installed and run ipa-adtrust-install on all of our IPA
servers, though a couple ran without that for a while.  It does not look like
that group has an ipaNTSecurityIdentifier atribute.

>> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]]
>> [ipa_id_get_groups_overrides_done] (0x0040): IPA resolve user groups 
>> overrides
>> failed [22].
>> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_srv_ad_acct_lookup_done]
>> (0x0040): ipa_get_*_acct request failed: [22]: Invalid argument.
>> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_subdomain_account_done]
>> (0x0040): ipa_get_*_acct request failed: [22]: Invalid argument.
>> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [dp_reply_std_set] (0x0080):
>> DP Error is OK on failed request?
>> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_cache_entry_attr]
>> (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object 
>> (32)]
>> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_entry_attr]
>> (0x0080): Cannot set ts attrs for
>> name=u...@ad.nwra.com,cn=users,cn=ad.nwra.com,cn=sysdb
>> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]]
>> [ipa_initgr_get_overrides_step] (0x0040): The group
>> name=u...@nwra.com,cn=groups,cn=nwra.com,cn=sysdb has no UUID attribute
>> objectSIDString, error!
>> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]]
>> [ipa_id_get_groups_overrides_done] (0x0040): IPA resolve user groups 
>> overrides
>> failed [22].
>> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_srv_ad_acct_lookup_done]
>> (0x0040): ipa_get_*_acct request failed: [22]: Invalid argument.
>> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_subdomain_account_done]
>> (0x0040): ipa_get_*_acct request failed: [22]: Invalid argument.
>> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [dp_reply_std_set] (0x0080):
>> DP Error is OK on failed request?
>> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]]
>> [sdap_ad_tokengroups_get_posix_members] (0x0080): Domain not found for SID
>> S-1-5-32-545
>> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_cache_entry_attr]
>> (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object 
>> (32)]
>> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_entry_attr]
>> (0x0080): Cannot set ts attrs for
>> name=u...@ad.nwra.com,cn=users,cn=ad.nwra.com,cn=sysdb
>> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]]
>> [ipa_add_ad_memberships_get_next] (0x0020): There are unresolved external
>> group memberships even after all groups have been looked up on the LDAP 
>> server.
>> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]]
>> [ipa_id_get_account_info_orig_done] (0x0080): Object not found, ending 
>> request
>> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_srv_ad_acct_lookup_done]
>> (0x0080): Sudomain lookup failed, will try to reset sudomain..
>> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [be_fo_reset_svc] (0x0080):
>> Cannot retrieve service [ad.nwra.com]
>> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_srv_ad_acct_lookup_done]
>> (0x0040): ipa_get_*_acct request failed: [1432158270]: Subdomain is inactive.
>> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]]

Re: [Freeipa-users] ipa_add_ad_memberships_get_next errors

2017-04-03 Thread Orion Poplawski 
On 04/03/2017 02:10 AM, Alexander Bokovoy wrote:
> On ma, 03 huhti 2017, Jakub Hrozek wrote:
>> On Fri, Mar 31, 2017 at 04:07:16PM -0600, Orion Poplawski wrote:
>>> I'm seeing messages like this:
>>>
>>> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]]
>>> [ipa_add_ad_memberships_get_next] (0x0020): There are unresolved external
>>> group memberships even after all groups have been looked up on the LDAP
>>> server.
>>>
>>> and wondering it is anything to worry about.
>>>
>>>
>>> Some context:
>>>
>>> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_cache_search_groups]
>>> (0x2000): Search groups with filter:
>>> (&(objectclass=group)(originalDN=ipaUniqueID=12d2026e-a5cd-11e5-a14e-00163e2d6456,cn=hbac,dc=nwra,dc=com))
>>>
>>> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_cache_search_groups]
>>> (0x2000): No such entry
>>> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_cache_search_groups]
>>> (0x2000): Search groups with filter:
>>> (&(objectclass=group)(originalDN=cn=nwra,cn=groups,cn=accounts,dc=nwra,dc=com))
>>>
>>> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [merge_msg_ts_attrs] 
>>> (0x2000):
>>> No such DN in the timestamp cache:
>>> name=n...@nwra.com,cn=groups,cn=nwra.com,cn=sysdb
>>> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_merge_res_ts_attrs]
>>> (0x2000): TS cache doesn't contain this DN, skipping
>>> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_groups_next_base]
>>> (0x0400): Searching for groups with base [cn=accounts,dc=nwra,dc=com]
>>> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_print_server] 
>>> (0x2000):
>>> Searching 10.10.41.4:389
>>> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step]
>>> (0x0400): calling ldap_search_ext with
>>> [(&(cn=12d2026e-a5cd-11e5-a14e-00163e2d6456)(|(objectClass=ipaUserGroup)(objectClass=posixGroup))(cn=*)(&(gidNumber=*)(!(gidNumber=0][cn=accounts,dc=nwra,dc=com].
>>>
>>
>> I think this might be the reason why SSSD reports unresolved
>> memberships. It'trying to resolve the group using the cn attribute, ut
>> the object's RDN attribute seems to be ipaUniqueID. So I don't think
>> this is harmful, just confusing.
>>
>> Can you please check what the object is on the IPA side with this
>> ipaUniqueID?
> It is HBAC group -- see above in the log:
> (&(objectclass=group)(originalDN=ipaUniqueID=12d2026e-a5cd-11e5-a14e-00163e2d6456,cn=hbac,dc=nwra,dc=com))

This is our "allow employees access" HBAC group.  So it applies to our "nwra"
host group as well as a couple individual machines, and to our "nwra" IPA group.

# 12d2026e-a5cd-11e5-a14e-00163e2d6456, hbac, nwra.com
dn: ipaUniqueID=12d2026e-a5cd-11e5-a14e-00163e2d6456,cn=hbac,dc=nwra,dc=com
description: Allow NWRA-Users
serviceCategory: all
memberHost: cn=nwra,cn=hostgroups,cn=accounts,dc=nwra,dc=com
memberHost: fqdn=ipaclient1.cora.nwra.com,cn=computers,cn=accounts,dc=nwra,dc=
 com
memberHost: fqdn=quetzal.cora.nwra.com,cn=computers,cn=accounts,dc=nwra,dc=com
memberUser: cn=nwra,cn=groups,cn=accounts,dc=nwra,dc=com
objectClass: ipaassociation
objectClass: ipahbacrule
accessRuleType: allow
ipaEnabledFlag: TRUE
cn: allow_nwra
ipaUniqueID: 12d2026e-a5cd-11e5-a14e-00163e2d6456

The group search for that item fails presumably because it's not a group
(doesn't have objectclass=group).

The nwra group contains the nwra_users_external group:

# ipa group-show nwra
  Group name: nwra
  Description: ad.nwra.com NWRA-Users
  GID: 1001
  Member groups: nwra_users_external
  Member of HBAC rule: allow_nwra

# ipa group-show nwra_users_external
  Group name: nwra_users_external
  Description: ad.nwra.com NWRA-Users external map
  External member: nwra-us...@ad.nwra.com
  Member of groups: nwra
  Indirect Member of HBAC rule: allow_nwra


-- 
Orion Poplawski
Technical Manager  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] libsemanage updates fail due to AD user with space

2017-04-03 Thread Jakub Hrozek 
On Mon, Apr 03, 2017 at 11:00:21AM +1000, Lachlan Musicman wrote:
> Hola,
> 
> I've reported this issue before (with a different symptom iirc), but
> thought I should mention again, as I have no idea how to competently report
> it to selinux.
> 
> With SSSD/IPA in use, in a one way trust to AD, and AD users have spaces in
> their names, libsemanage fails to update:
> 
> eg from recent monthly upgrade cycle:
> 
> Updating   :
> selinux-policy-targeted-3.13.1-102.el7_3.16.noarch
> 3/14
> libsemanage.parse_assert_ch: expected character ':', but found 'f'
> (/etc/selinux/targeted/tmp/seusers.local: 5):
> lastname firstn...@domain.com:unconfined_u:s0-s0:c0.c1023 (No such file or
> directory).
> libsemanage.seuser_parse: could not parse seuser record (No such file or
> directory).
> libsemanage.dbase_file_cache: could not cache file database (No such file
> or directory).
> libsemanage.semanage_base_merge_components: could not merge local
> modifications into policy (No such file or directory).
> 

Hi,
according to my quick testing this is solved with this PR:
https://github.com/SSSD/sssd/pull/189
(Please note that we haven't ran all regression tests on this PR so I
can't in fact tell if it's correct or not. The code does look OK,
though).

I was also able to work around the issue by setting:
override_space = _
in sssd.conf

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

2017-04-03 Thread Alexander Bokovoy 

On ma, 03 huhti 2017, Jakub Hrozek wrote:

On Fri, Mar 31, 2017 at 04:07:16PM -0600, Orion Poplawski wrote:

I'm seeing messages like this:

(Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]]
[ipa_add_ad_memberships_get_next] (0x0020): There are unresolved external
group memberships even after all groups have been looked up on the LDAP server.

and wondering it is anything to worry about.


Some context:

(Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_cache_search_groups]
(0x2000): Search groups with filter:
(&(objectclass=group)(originalDN=ipaUniqueID=12d2026e-a5cd-11e5-a14e-00163e2d6456,cn=hbac,dc=nwra,dc=com))
(Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_cache_search_groups]
(0x2000): No such entry
(Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_cache_search_groups]
(0x2000): Search groups with filter:
(&(objectclass=group)(originalDN=cn=nwra,cn=groups,cn=accounts,dc=nwra,dc=com))
(Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [merge_msg_ts_attrs] (0x2000):
No such DN in the timestamp cache:
name=n...@nwra.com,cn=groups,cn=nwra.com,cn=sysdb
(Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_merge_res_ts_attrs]
(0x2000): TS cache doesn't contain this DN, skipping
(Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_groups_next_base]
(0x0400): Searching for groups with base [cn=accounts,dc=nwra,dc=com]
(Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_print_server] (0x2000):
Searching 10.10.41.4:389
(Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step]
(0x0400): calling ldap_search_ext with
[(&(cn=12d2026e-a5cd-11e5-a14e-00163e2d6456)(|(objectClass=ipaUserGroup)(objectClass=posixGroup))(cn=*)(&(gidNumber=*)(!(gidNumber=0][cn=accounts,dc=nwra,dc=com].


I think this might be the reason why SSSD reports unresolved
memberships. It'trying to resolve the group using the cn attribute, ut
the object's RDN attribute seems to be ipaUniqueID. So I don't think
this is harmful, just confusing.

Can you please check what the object is on the IPA side with this
ipaUniqueID?

It is HBAC group -- see above in the log:
(&(objectclass=group)(originalDN=ipaUniqueID=12d2026e-a5cd-11e5-a14e-00163e2d6456,cn=hbac,dc=nwra,dc=com))


--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] subdomain errors

2017-04-03 Thread Jakub Hrozek 
On Fri, Mar 31, 2017 at 05:08:13PM -0600, Orion Poplawski wrote:
> I seem to be having some issues with users/groups that may be leading to
> errors in the subdomain status.  Can anyone parse this for me?
> 
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_cache_entry_attr]
> (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object 
> (32)]
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_entry_attr]
> (0x0080): Cannot set ts attrs for
> name=u...@ad.nwra.com,cn=users,cn=ad.nwra.com,cn=sysdb

This can be ignored, it's just a minor performance annoyance we track
upstream.

> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_cache_entry_attr]
> (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object 
> (32)]
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_entry_attr]
> (0x0080): Cannot set ts attrs for
> name=u...@ad.nwra.com,cn=users,cn=ad.nwra.com,cn=sysdb
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]]
> [ipa_initgr_get_overrides_step] (0x0040): The group
> name=u...@nwra.com,cn=groups,cn=nwra.com,cn=sysdb has no UUID attribute
> objectSIDString, error!

But this seems strange. Before you sanitized (presumably?) the logs, did
the DN name=u...@nwra.com,cn=groups,cn=nwra.com,cn=sysdb correspond to
an IPA object?

Did you run the sidgen task when setting up trusts or did you make sure
all replicas are either trust controllers or trust agents? Does the
entry on the IPA LDAP side have ipaNTSecurityIdentifier attribute?

> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]]
> [ipa_id_get_groups_overrides_done] (0x0040): IPA resolve user groups overrides
> failed [22].
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_srv_ad_acct_lookup_done]
> (0x0040): ipa_get_*_acct request failed: [22]: Invalid argument.
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_subdomain_account_done]
> (0x0040): ipa_get_*_acct request failed: [22]: Invalid argument.
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [dp_reply_std_set] (0x0080):
> DP Error is OK on failed request?
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_cache_entry_attr]
> (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object 
> (32)]
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_entry_attr]
> (0x0080): Cannot set ts attrs for
> name=u...@ad.nwra.com,cn=users,cn=ad.nwra.com,cn=sysdb
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]]
> [ipa_initgr_get_overrides_step] (0x0040): The group
> name=u...@nwra.com,cn=groups,cn=nwra.com,cn=sysdb has no UUID attribute
> objectSIDString, error!
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]]
> [ipa_id_get_groups_overrides_done] (0x0040): IPA resolve user groups overrides
> failed [22].
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_srv_ad_acct_lookup_done]
> (0x0040): ipa_get_*_acct request failed: [22]: Invalid argument.
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_subdomain_account_done]
> (0x0040): ipa_get_*_acct request failed: [22]: Invalid argument.
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [dp_reply_std_set] (0x0080):
> DP Error is OK on failed request?
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]]
> [sdap_ad_tokengroups_get_posix_members] (0x0080): Domain not found for SID
> S-1-5-32-545
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_cache_entry_attr]
> (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object 
> (32)]
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_entry_attr]
> (0x0080): Cannot set ts attrs for
> name=u...@ad.nwra.com,cn=users,cn=ad.nwra.com,cn=sysdb
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]]
> [ipa_add_ad_memberships_get_next] (0x0020): There are unresolved external
> group memberships even after all groups have been looked up on the LDAP 
> server.
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]]
> [ipa_id_get_account_info_orig_done] (0x0080): Object not found, ending request
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_srv_ad_acct_lookup_done]
> (0x0080): Sudomain lookup failed, will try to reset sudomain..
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [be_fo_reset_svc] (0x0080):
> Cannot retrieve service [ad.nwra.com]
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_srv_ad_acct_lookup_done]
> (0x0040): ipa_get_*_acct request failed: [1432158270]: Subdomain is inactive.
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_subdomain_account_done]
> (0x0040): ipa_get_*_acct request failed: [1432158270]: Subdomain is inactive.
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [dp_reply_std_set] (0x0080):
> DP Error is OK on failed request?
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]]
> [ipa_id_get_account_info_orig_done] (0x0080): Object not found, ending request
> (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_srv_ad_acct_lookup_done]
> (0x0080): Sudomain lookup failed, will try to reset sudomain..
> (Fri Mar 31 16:54:26 2017)

Re: [Freeipa-users] ipa_add_ad_memberships_get_next errors

2017-04-03 Thread Jakub Hrozek 
On Fri, Mar 31, 2017 at 04:07:16PM -0600, Orion Poplawski wrote:
> I'm seeing messages like this:
> 
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]]
> [ipa_add_ad_memberships_get_next] (0x0020): There are unresolved external
> group memberships even after all groups have been looked up on the LDAP 
> server.
> 
> and wondering it is anything to worry about.
> 
> 
> Some context:
> 
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_cache_search_groups]
> (0x2000): Search groups with filter:
> (&(objectclass=group)(originalDN=ipaUniqueID=12d2026e-a5cd-11e5-a14e-00163e2d6456,cn=hbac,dc=nwra,dc=com))
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_cache_search_groups]
> (0x2000): No such entry
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_cache_search_groups]
> (0x2000): Search groups with filter:
> (&(objectclass=group)(originalDN=cn=nwra,cn=groups,cn=accounts,dc=nwra,dc=com))
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [merge_msg_ts_attrs] (0x2000):
> No such DN in the timestamp cache:
> name=n...@nwra.com,cn=groups,cn=nwra.com,cn=sysdb
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_merge_res_ts_attrs]
> (0x2000): TS cache doesn't contain this DN, skipping
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_groups_next_base]
> (0x0400): Searching for groups with base [cn=accounts,dc=nwra,dc=com]
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_print_server] (0x2000):
> Searching 10.10.41.4:389
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step]
> (0x0400): calling ldap_search_ext with
> [(&(cn=12d2026e-a5cd-11e5-a14e-00163e2d6456)(|(objectClass=ipaUserGroup)(objectClass=posixGroup))(cn=*)(&(gidNumber=*)(!(gidNumber=0][cn=accounts,dc=nwra,dc=com].

I think this might be the reason why SSSD reports unresolved
memberships. It'trying to resolve the group using the cn attribute, ut
the object's RDN attribute seems to be ipaUniqueID. So I don't think
this is harmful, just confusing.

Can you please check what the object is on the IPA side with this
ipaUniqueID?

Could you describe the hierarchy so I can set up and reproduce something
similar locally?

> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step]
> (0x1000): Requesting attrs: [objectClass]
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step]
> (0x1000): Requesting attrs: [posixGroup]
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step]
> (0x1000): Requesting attrs: [cn]
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step]
> (0x1000): Requesting attrs: [userPassword]
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step]
> (0x1000): Requesting attrs: [gidNumber]
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step]
> (0x1000): Requesting attrs: [member]
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step]
> (0x1000): Requesting attrs: [ipaUniqueID]
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step]
> (0x1000): Requesting attrs: [ipaNTSecurityIdentifier]
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step]
> (0x1000): Requesting attrs: [modifyTimestamp]
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step]
> (0x1000): Requesting attrs: [entryUSN]
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step]
> (0x1000): Requesting attrs: [ipaExternalMember]
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step]
> (0x2000): ldap_search_ext called, msgid = 17
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_op_add] (0x2000): New
> operation 17 timeout 6
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_process_result]
> (0x2000): Trace: sh[0x7fc2ae9e9d90], connected[1], ops[0x7fc2aea403c0],
> ldap[0x7fc2ae9b60b0]
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_process_result]
> (0x2000): Trace: end of ldap_result list
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_process_result]
> (0x2000): Trace: sh[0x7fc2ae9e9d90], connected[1], ops[0x7fc2aea403c0],
> ldap[0x7fc2ae9b60b0]
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_op_finished]
> (0x0400): Search result: Success(0), no errmsg set
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_op_destructor] (0x2000):
> Operation 17 finished
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_groups_process]
> (0x0400): Search for groups, returned 0 results.
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_cache_search_groups]
> (0x2000): Search groups with filter:
> (&(objectclass=group)(originalDN=ipaUniqueID=12d2026e-a5cd-11e5-a14e-00163e2d6456,cn=hbac,dc=nwra,dc=com))
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_cache_search_groups]
> (0x2000): No such entry
> (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]]
> [ipa_add_ad_memberships_get_next] (0x0020): There are