[Freeipa-users] bind-dyndb-ldap, AXFR and DS records

[Ben Roberts]

Hi all,

This is a question more about bind-dyndb-ldap rather than freeipa, but I
understand it's written/maintained by the freeipa project and so this might
be the most appropriate place to ask. I have setup bind-dyndb-ldap to read
some zones from openldap, with multiple nameservers acting as masters and
one nameserver running as a slave via the usual notify/transfer mechanism.
I'm not seeing any DS records transfer across to the slave nameserver, nor
when I manually query the primaries with an AFXR request. This includes
both the apex DS records, automatically generated by bind-dyndb-ldap, but
more importantly the glue dSRecord objects for a delegated subdomain.

I note that the dSRecord entries are present in
/var/named/dyndb-ldap/$view/master/$zone/raw but not present in
/var/named/dyndb-ldap/$view/master/$zone/signed.

Example (domain name and ip addresses obfuscated, but all other fields are
unmodified):
$ dig +noall +answer DS subdomain.example.local @127.0.01
subdomain.example.local.   600 IN  DS  38589 7 1
6C410EF5A47631FBA2C3BC295A90363EA86A1846
subdomain.example.local.   600 IN  DS  38589 7 2
23E22A49BBF2AD0E3F4668CB4C0DB52EE60ACA4308C1DE002A47AD7B 99734334

$ dig +noall +answer AXFR subdomain.example.local @127.0.0.1 | head -n 1
subdomain.example.local.   600 IN  SOA ns1.example.local.
hostmaster.example.local. 2016050416 43200 3600 1209600 3600

$ dig +noall +answer AXFR subdomain.example.local @127.0.0.1 | grep '\bDS\b'
$

This behaviour doesn't seem right to me. I would expect the DS records to
be transferred to the slaves as normal so that any glue records are
correctly present on all nameservers. I can't see any references in the
bind-dyndb-ldap wiki/readme or code comments that would explain DS records
being treated specially, but please do correct me if I'm wrong.

Regards,
Ben Roberts
-- 
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] Where is SID stored after ipa-adtrust-install?

[Armaan Esfahani]

It worked! Thanks so much for your help.


On 2/8/17, 12:20 PM, "Alexander Bokovoy"  wrote:

On ke, 08 helmi 2017, Armaan Esfahani wrote:
>I have found the following.
>
>[08/Feb/2017:11:14:38 -0500] sidgen_task_thread - [file ipa_sidgen_task.c, 
line 194]: Sidgen task starts ...
>[08/Feb/2017:11:14:38 -0500] find_sid_for_ldap_entry - [file 
ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [755400050] into an 
unused SID.
>[08/Feb/2017:11:14:38 -0500] do_work - [file ipa_sidgen_task.c, line 154]: 
Cannot add SID to existing entry.
>[08/Feb/2017:11:14:38 -0500] sidgen_task_thread - [file ipa_sidgen_task.c, 
line 199]: Sidgen task finished [32].
>
>I assume this is the second possibility you brought up, the ID ranges I
>have setup do not allow mapping of UID/GID to SID

Yes. Check existing ID ranges to see if you have one that covers POSIX ID
755400050. If there is none, you need to create another ID range that
covers those users.

This typically comes from cases where POSIX IDs were assigned manually
or from already existing source via migration. At this point FreeIPA
would not have an ID range that covers these pre-allocated IDs.

So you need to define several variables here:

 - base ID of the range
 - range size -- enough to cover those existing users and groups that
   are outside of IPA ID range
 - RID bases -- since we are building SIDs for the same domain, the RID
   base and secondary RID base should not be overlapping with existing
   IPA ID range

For example, if you have 100 users starting around 75540 and your
default IPA ID range has 20 entries (default range size), then
mapping RID base above that one would be enough.

ipa idrange-add MY.DOM.AIN-extra_id_range --base-id=75540 
--range-size=100 \
  --rid-base=50 
--secondary-rid-base=500100 \
  --type=ipa-local

Adding this range would be enough -- there will not be any allocation of
POSIX IDs in the range but sidgen plugin will be able to use the range
to drive SID allocation.


>
>On 2/8/17, 11:10 AM, "Alexander Bokovoy"  wrote:
>
>On ke, 08 helmi 2017, Armaan Esfahani wrote:
>>I’ve been having issues with some of my IPA seemingly not getting 
SID’s
>>after the install, even after running with the –add-sids modifier. I
>>was wondering where the SID values are located so that I can take a
>>look at what’s happening/
>In the user object itself, ipaNTSecurityIdentifier attribute.
>
>If you have SIDs not generated, there are two potential issues that
>cause it:
> - sidgen plugin configuration looking at wrong basedn
> - ID ranges you have do not allow to map UID/GID to SID
>
>If you ran ipa-adtrust-install --add-sids and it generated nothing, 
look
>at /var/log/dirsrv/slapd-INSTANCE/errors log file. There should be at
>least two lines:
>
>[01/Feb/2017:14:28:24.189906631 +0100] sidgen_task_thread - [file 
ipa_sidgen_task.c, line 194]: Sidgen task starts ...
>[01/Feb/2017:14:28:24.192039515 +0100] sidgen_task_thread - [file 
ipa_sidgen_task.c, line 199]: Sidgen task finished [0].
>
>If there are any errors causing issues with SID generation, they will 
be
>in between these two lines.
>
>
>--
>/ 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

-- 
/ 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] Where is SID stored after ipa-adtrust-install?

[Alexander Bokovoy]

On ke, 08 helmi 2017, Armaan Esfahani wrote:

I have found the following.

[08/Feb/2017:11:14:38 -0500] sidgen_task_thread - [file ipa_sidgen_task.c, line 
194]: Sidgen task starts ...
[08/Feb/2017:11:14:38 -0500] find_sid_for_ldap_entry - [file 
ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [755400050] into an 
unused SID.
[08/Feb/2017:11:14:38 -0500] do_work - [file ipa_sidgen_task.c, line 154]: 
Cannot add SID to existing entry.
[08/Feb/2017:11:14:38 -0500] sidgen_task_thread - [file ipa_sidgen_task.c, line 
199]: Sidgen task finished [32].

I assume this is the second possibility you brought up, the ID ranges I
have setup do not allow mapping of UID/GID to SID


Yes. Check existing ID ranges to see if you have one that covers POSIX ID
755400050. If there is none, you need to create another ID range that
covers those users.

This typically comes from cases where POSIX IDs were assigned manually
or from already existing source via migration. At this point FreeIPA
would not have an ID range that covers these pre-allocated IDs.

So you need to define several variables here:

- base ID of the range
- range size -- enough to cover those existing users and groups that
  are outside of IPA ID range
- RID bases -- since we are building SIDs for the same domain, the RID
  base and secondary RID base should not be overlapping with existing
  IPA ID range

For example, if you have 100 users starting around 75540 and your
default IPA ID range has 20 entries (default range size), then
mapping RID base above that one would be enough.

ipa idrange-add MY.DOM.AIN-extra_id_range --base-id=75540 --range-size=100 \
 --rid-base=50 
--secondary-rid-base=500100 \
  --type=ipa-local

Adding this range would be enough -- there will not be any allocation of
POSIX IDs in the range but sidgen plugin will be able to use the range
to drive SID allocation.




On 2/8/17, 11:10 AM, "Alexander Bokovoy"  wrote:

   On ke, 08 helmi 2017, Armaan Esfahani wrote:
   >I’ve been having issues with some of my IPA seemingly not getting SID’s
   >after the install, even after running with the –add-sids modifier. I
   >was wondering where the SID values are located so that I can take a
   >look at what’s happening/
   In the user object itself, ipaNTSecurityIdentifier attribute.

   If you have SIDs not generated, there are two potential issues that
   cause it:
- sidgen plugin configuration looking at wrong basedn
- ID ranges you have do not allow to map UID/GID to SID

   If you ran ipa-adtrust-install --add-sids and it generated nothing, look
   at /var/log/dirsrv/slapd-INSTANCE/errors log file. There should be at
   least two lines:

   [01/Feb/2017:14:28:24.189906631 +0100] sidgen_task_thread - [file 
ipa_sidgen_task.c, line 194]: Sidgen task starts ...
   [01/Feb/2017:14:28:24.192039515 +0100] sidgen_task_thread - [file 
ipa_sidgen_task.c, line 199]: Sidgen task finished [0].

   If there are any errors causing issues with SID generation, they will be
   in between these two lines.


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


--
/ 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] Where is SID stored after ipa-adtrust-install?

[Armaan Esfahani]

Hey Jeff, that is also happening here, however only with users created after 
the ipa-adtrust-install. For example, the admin user fails to ever be 
authenticated despite numerous password resets, yet if I were to create a new 
account and reset it’s password it works fine.

 

 

From: Jeff Goddard 
Date: Wednesday, February 8, 2017 at 11:21 AM
To: Alexander Bokovoy 
Cc: Armaan Esfahani , 

Subject: Re: [Freeipa-users] Where is SID stored after ipa-adtrust-install?

 

I had this same issue and the value was only added after a password change.

Jeff

 

 

On Wed, Feb 8, 2017 at 11:10 AM, Alexander Bokovoy  wrote:

On ke, 08 helmi 2017, Armaan Esfahani wrote:

I’ve been having issues with some of my IPA seemingly not getting SID’s
after the install, even after running with the –add-sids modifier. I
was wondering where the SID values are located so that I can take a
look at what’s happening/

In the user object itself, ipaNTSecurityIdentifier attribute.

If you have SIDs not generated, there are two potential issues that
cause it:
- sidgen plugin configuration looking at wrong basedn
- ID ranges you have do not allow to map UID/GID to SID

If you ran ipa-adtrust-install --add-sids and it generated nothing, look
at /var/log/dirsrv/slapd-INSTANCE/errors log file. There should be at
least two lines:

[01/Feb/2017:14:28:24.189906631 +0100] sidgen_task_thread - [file 
ipa_sidgen_task.c, line 194]: Sidgen task starts ...
[01/Feb/2017:14:28:24.192039515 +0100] sidgen_task_thread - [file 
ipa_sidgen_task.c, line 199]: Sidgen task finished [0].

If there are any errors causing issues with SID generation, they will be
in between these two lines.


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




-- 
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] Where is SID stored after ipa-adtrust-install?

[Jeff Goddard]

I had this same issue and the value was only added after a password change.

Jeff



On Wed, Feb 8, 2017 at 11:10 AM, Alexander Bokovoy 
wrote:

> On ke, 08 helmi 2017, Armaan Esfahani wrote:
>
>> I’ve been having issues with some of my IPA seemingly not getting SID’s
>> after the install, even after running with the –add-sids modifier. I
>> was wondering where the SID values are located so that I can take a
>> look at what’s happening/
>>
> In the user object itself, ipaNTSecurityIdentifier attribute.
>
> If you have SIDs not generated, there are two potential issues that
> cause it:
> - sidgen plugin configuration looking at wrong basedn
> - ID ranges you have do not allow to map UID/GID to SID
>
> If you ran ipa-adtrust-install --add-sids and it generated nothing, look
> at /var/log/dirsrv/slapd-INSTANCE/errors log file. There should be at
> least two lines:
>
> [01/Feb/2017:14:28:24.189906631 +0100] sidgen_task_thread - [file
> ipa_sidgen_task.c, line 194]: Sidgen task starts ...
> [01/Feb/2017:14:28:24.192039515 +0100] sidgen_task_thread - [file
> ipa_sidgen_task.c, line 199]: Sidgen task finished [0].
>
> If there are any errors causing issues with SID generation, they will be
> in between these two lines.
>
>
> --
> / 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
-- 
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] Where is SID stored after ipa-adtrust-install?

[Armaan Esfahani]

I have found the following.

[08/Feb/2017:11:14:38 -0500] sidgen_task_thread - [file ipa_sidgen_task.c, line 
194]: Sidgen task starts ...
[08/Feb/2017:11:14:38 -0500] find_sid_for_ldap_entry - [file 
ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [755400050] into an 
unused SID.
[08/Feb/2017:11:14:38 -0500] do_work - [file ipa_sidgen_task.c, line 154]: 
Cannot add SID to existing entry.
[08/Feb/2017:11:14:38 -0500] sidgen_task_thread - [file ipa_sidgen_task.c, line 
199]: Sidgen task finished [32].

I assume this is the second possibility you brought up, the ID ranges I have 
setup do not allow mapping of UID/GID to SID

On 2/8/17, 11:10 AM, "Alexander Bokovoy"  wrote:

On ke, 08 helmi 2017, Armaan Esfahani wrote:
>I’ve been having issues with some of my IPA seemingly not getting SID’s
>after the install, even after running with the –add-sids modifier. I
>was wondering where the SID values are located so that I can take a
>look at what’s happening/
In the user object itself, ipaNTSecurityIdentifier attribute.

If you have SIDs not generated, there are two potential issues that
cause it:
 - sidgen plugin configuration looking at wrong basedn
 - ID ranges you have do not allow to map UID/GID to SID

If you ran ipa-adtrust-install --add-sids and it generated nothing, look
at /var/log/dirsrv/slapd-INSTANCE/errors log file. There should be at
least two lines:

[01/Feb/2017:14:28:24.189906631 +0100] sidgen_task_thread - [file 
ipa_sidgen_task.c, line 194]: Sidgen task starts ...
[01/Feb/2017:14:28:24.192039515 +0100] sidgen_task_thread - [file 
ipa_sidgen_task.c, line 199]: Sidgen task finished [0].

If there are any errors causing issues with SID generation, they will be
in between these two lines.


-- 
/ 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] Where is SID stored after ipa-adtrust-install?

[Alexander Bokovoy]

On ke, 08 helmi 2017, Armaan Esfahani wrote:

I’ve been having issues with some of my IPA seemingly not getting SID’s
after the install, even after running with the –add-sids modifier. I
was wondering where the SID values are located so that I can take a
look at what’s happening/

In the user object itself, ipaNTSecurityIdentifier attribute.

If you have SIDs not generated, there are two potential issues that
cause it:
- sidgen plugin configuration looking at wrong basedn
- ID ranges you have do not allow to map UID/GID to SID

If you ran ipa-adtrust-install --add-sids and it generated nothing, look
at /var/log/dirsrv/slapd-INSTANCE/errors log file. There should be at
least two lines:

[01/Feb/2017:14:28:24.189906631 +0100] sidgen_task_thread - [file 
ipa_sidgen_task.c, line 194]: Sidgen task starts ...
[01/Feb/2017:14:28:24.192039515 +0100] sidgen_task_thread - [file 
ipa_sidgen_task.c, line 199]: Sidgen task finished [0].

If there are any errors causing issues with SID generation, they will be
in between these two lines.


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

[Freeipa-users] Where is SID stored after ipa-adtrust-install?

[Armaan Esfahani]

I’ve been having issues with some of my IPA seemingly not getting SID’s after 
the install, even after running with the –add-sids modifier. I was wondering 
where the SID values are located so that I can take a look at what’s happening/

 

-- 

Armaan Esfahani
Advanced Open Systems
m:(470) 377-2115
a:2440 Sandy Plains Rd. Marietta GA, 30062
 Bldg 4 Ste D
e:armaan.esfah...@advancedopen.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] sudo rules are not active immediatly

[Nathanaël Blanchet]

Le 08/02/2017 à 13:00, Pavel Březina a écrit :

On 02/08/2017 11:59 AM, Nathanaël Blanchet wrote:

Hello,
on latest IPA, when adding a command to a rule or a sudo option for
example, the change is not active on the user session.
For example, after removing !authenticate option, I still can execute
sudo commands without password.
I tried to logout and relogin, but nothing changes, but on a new vm
where never logeed in before it wroks.
Is there a cache or somting to do so as to commands to be immediatly
available?



Hi,
sudo rules are cache on the client and refresh happens periodically. 
We have several update mechanisms that deals with finding new rules, 
deleting non-existent ones and updating expired but it cannot be 
performed on desired at the moment. We have a ticket for that [1]. 
Please see 'man sssd-sudo' to get better understanding how it works.


it's said that sssd-sudo has been created to be near of the local 
sudoers functionnment. So I suppose the three described mechanisms are 
intended to converge to a near realtime rule change.
It's true that waiting for an undefinied time, rules become available... 
but is there an estimated time of availibility? Is it rather 15min or 
one hour (I suppose beyond is not usable)
It is possible to expired cached rules with sss_cache. This won't find 
you newly added rules but it will fetch updated rules and removed 
deleted ones.


[1] https://fedorahosted.org/sssd/ticket/2884




--
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] Needs help understand this timeout issue

[Troels Hansen]

Cache is verified valid by looking at the cache files /var/lib/sss/db/ ldb 
files.

Also, if I lookup the user on the IPA server I get a fast response.

Looking up the user on a client which have a valid cache return the user within 
a few ms or secs.
Invalidating the cache on the client with sss_cache results in the user being 
fetched from the IPA server. This takes about 15-20 seconds.
This is acceptable.
If I do a tcpdump of ldap traffic while this happens I only see traffic between 
sssd client and ipa server.

Then I remove the cache files and restarts sssd on the client, simulating a 
newly joined client or a client that have cleaned up its ldb cache 
(ldap_purge_cache_timeout=0 only set on the server).
At this point the IPA server still have a valid cache.

Looking up the user while tcpdumping on IPA server I can see what looks like 
IPA fetches the entire information from AD.
This is ~730 groups, mostly nested groups for this user.

This takes 5-7 minutes


The LDAP responds quickly, no CPU load, and I can do manual LDAP lookups then 
the user is fetched, so nothing that points to a busy LDAP.

It doesn't matter if I do a lookup of the user or he logs in. Its the same 
behavior.

Currently its very limited load, but this is going to scale up later on. 


- On Feb 8, 2017, at 2:12 PM, Sullivan, Daniel [CRI] 
dsulliv...@bsd.uchicago.edu wrote:

> Are you actually logging in or or just doing a lookup on a user?  I remember
> reading somewhere that groups are always re-evaluated at the point of login,
> regardless of what is in the cache.  I am not sure if this is accurate or the
> implications of whether or not it is on the client, server or both, but this
> could be what is happening.
> 
> Also, how are verifying that the group in the cache on the server is valid?  
> If
> you do a lookup a user on the server after the mapped memory cache expires
> (i.e. if you restart sssd), do you see a log entry that a valid cache entry 
> has
> been found and that entry is being returned (from memory it is in the nsss
> logs)?  It might help you to focus on the sysdb cache by setting a very low
> timeout value for the in memory mapped cache and or negative cache timeouts.
> Based on my experiencif a valid cache entry in the sysdb *NOT* found, a log
> entry is not returned (just a lookup is performed), which for an untrained eye
> makes it difficult to assess when timeouts are occurring in the sysdb cache.
> 
> Also, five minutes is a ridiculously long time to have to wait, have you
> inspected the performance of your 389 server?  Is your environment large or
> under large load?  Based on experience and another thread from this list, I
> have seen the 389ds threads get tied up due to extop operations because AD
> lookups via SSSD eventually will be blocked sssd under high load.
> 
> I had to significantly scale 389ds worker threads and processor cores to
> accommodate large numbers of concurrent AD lookups, this improved the
> performance of our environment and solved many issues.
> 
> Dan
> 
>> On Feb 8, 2017, at 1:27 AM, Troels Hansen  wrote:
>> 
>> No, ignore_group_members option is already set.
>> Tried setting and removing it on the client but didn't make a huge different.
>> 
>> Is a client have an completely empty cache, newly joined, empty 
>> /var/lig/sssd/db
>> and mc cache or something, the IPA server ALWAYS asks the AD for group info,
>> despite having a valid cache.
>> 
>> This leads to a delay of up to, or even more 5 minutes before a user can 
>> login.
>> Being denied access at first, but logging again later with success.
>> 
>> If the client have a cache thats only expired its able to pull the account 
>> info
>> from the cache on the IPA, without the IPA having to contact the AD.
>> 
>> 
>> - On Feb 6, 2017, at 2:24 PM, Sullivan, Daniel [CRI]
>> dsulliv...@bsd.uchicago.edu wrote:
>> 
>>> Have you looked at the ignore_group_members option?  Maybe this is the 
>>> problem
>>> you are seeing?
>>> 
>>> https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-ipa-ad-trust-deployments/
>>> 
>>> ==snip==
>>> 
>>> ignore_group_members
>>> Normally the most data-intensive operation is downloading the groups 
>>> including
>>> their members. Usually, we are interested in what groups a user is a member 
>>> of
>>> (id aduser@ad_domain) as the initial step rather than what members do 
>>> specific
>>> groups include (getent group adgroup@ad_domain). Setting the
>>> ignore_group_members option to True makes all groups appear as empty, thus
>>> downloading only information about the group objects themselves and not 
>>> their
>>> members, providing a significant performance boost. Please note that id
>>> aduser@ad_domain would still return all the correct groups!
>>> ==snip==
>>> 
>>> 
>>> Dan
>>> 
>>> On Feb 6, 2017, at 1:59 AM, Troels Hansen  wrote:
>>> 
>>> Hi
>>> 
>>> I'm aware of the anatomy of how the lookup is done, but I would 

Re: [Freeipa-users] Needs help understand this timeout issue

[Sullivan, Daniel [CRI]]

Are you actually logging in or or just doing a lookup on a user?  I remember 
reading somewhere that groups are always re-evaluated at the point of login, 
regardless of what is in the cache.  I am not sure if this is accurate or the 
implications of whether or not it is on the client, server or both, but this 
could be what is happening.

Also, how are verifying that the group in the cache on the server is valid?  If 
you do a lookup a user on the server after the mapped memory cache expires 
(i.e. if you restart sssd), do you see a log entry that a valid cache entry has 
been found and that entry is being returned (from memory it is in the nsss 
logs)?  It might help you to focus on the sysdb cache by setting a very low 
timeout value for the in memory mapped cache and or negative cache timeouts. 
Based on my experiencif a valid cache entry in the sysdb *NOT* found, a log 
entry is not returned (just a lookup is performed), which for an untrained eye 
makes it difficult to assess when timeouts are occurring in the sysdb cache. 

Also, five minutes is a ridiculously long time to have to wait, have you 
inspected the performance of your 389 server?  Is your environment large or 
under large load?  Based on experience and another thread from this list, I 
have seen the 389ds threads get tied up due to extop operations because AD 
lookups via SSSD eventually will be blocked sssd under high load.  

I had to significantly scale 389ds worker threads and processor cores to 
accommodate large numbers of concurrent AD lookups, this improved the 
performance of our environment and solved many issues.

Dan

> On Feb 8, 2017, at 1:27 AM, Troels Hansen  wrote:
> 
> No, ignore_group_members option is already set.
> Tried setting and removing it on the client but didn't make a huge different.
> 
> Is a client have an completely empty cache, newly joined, empty 
> /var/lig/sssd/db and mc cache or something, the IPA server ALWAYS asks the AD 
> for group info, despite having a valid cache.
> 
> This leads to a delay of up to, or even more 5 minutes before a user can 
> login. Being denied access at first, but logging again later with success.
> 
> If the client have a cache thats only expired its able to pull the account 
> info from the cache on the IPA, without the IPA having to contact the AD.
> 
> 
> - On Feb 6, 2017, at 2:24 PM, Sullivan, Daniel [CRI] 
> dsulliv...@bsd.uchicago.edu wrote:
> 
>> Have you looked at the ignore_group_members option?  Maybe this is the 
>> problem
>> you are seeing?
>> 
>> https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-ipa-ad-trust-deployments/
>> 
>> ==snip==
>> 
>> ignore_group_members
>> Normally the most data-intensive operation is downloading the groups 
>> including
>> their members. Usually, we are interested in what groups a user is a member 
>> of
>> (id aduser@ad_domain) as the initial step rather than what members do 
>> specific
>> groups include (getent group adgroup@ad_domain). Setting the
>> ignore_group_members option to True makes all groups appear as empty, thus
>> downloading only information about the group objects themselves and not their
>> members, providing a significant performance boost. Please note that id
>> aduser@ad_domain would still return all the correct groups!
>> ==snip==
>> 
>> 
>> Dan
>> 
>> On Feb 6, 2017, at 1:59 AM, Troels Hansen  wrote:
>> 
>> Hi
>> 
>> I'm aware of the anatomy of how the lookup is done, but I would suppose a 
>> valid
>> cache on the IPA server would result in the cache from the IPA server being
>> used?
>> 
>> I have been debugging this issue some more, and can confirm is the client 
>> have
>> its sssd cache invalidated by "sss_cache -E" and the IPA server have a valid
>> cache, when the client asks for the user, the IPA server still asks the AD 
>> for
>> the entire group info?
>> 
>> I can see, that even though the cache is refreshed the attribute
>> initgrExpireTimestamp (in the ldb cache) isn't updated.
>> I have been unable to find out exactly what this controls?
>> 
>> lastUpdate and dataExpireTimestamp is updated to the time stamp of when the
>> refresh ran.
>> 
>> 
>> - On Feb 1, 2017, at 2:27 PM, Sullivan, Daniel [CRI]
>> dsulliv...@bsd.uchicago.edu wrote:
>> 
>> Have you checked to see if the user is expired in the cache, or if it is
>> impacted by entry_cache_nowait_percentage (ref sssd.conf). The default entry
>> timeout is only 90 minutes and entry_cache_nowait_percentage default is 50.
>> 
>> ldbsearch -H  /var/lib/sss/db/timestamps_xxx.xxx.uchicago.edu.ldb >
>> ~/timestamps.txt
>> ldbsearch -H  /var/lib/sss/db/cache_xxx.xxx.uchicago.edu.ldb > ~/cache.txt
>> 
>> Might be able to provide more info.
>> 
>> Again, I’d really familiarize yourself with the anatomy of an sssd lookup, if
>> you get to know the diagram and steps 1-7 here it will be a big help to your
>> question(s).
>> 

Re: [Freeipa-users] ipa- client rhel 6.9 support for UPN different then domain name

[Sumit Bose]

On Wed, Feb 08, 2017 at 12:44:07PM +0100, Troels Hansen wrote:
> Hi, 
> 
> Have you tried setting ldap_user_principal to something nonexisting? For 
> example:
> 
> ldap_user_principal = nosuchattr
> 
> and inherit this to the AD domain with:
> 
> subdomain_inherit = ldap_user_principal
> 
> Both in the domain section of sssd.

Enterprise principals are supported by IPA since RHEL 7.3, so this
work-around for older versions should not be needed anymore.

> 
> - On Feb 8, 2017, at 12:17 PM, Jan Karásek jan.kara...@elostech.cz wrote:
> 
> > Hi, thank you for help.
> > 
> > I am running RHEL 7.3 on IPA serveres and with RHEL 7.3 clients it works 
> > really
> > nice.
> > Trouble is on RHEL 6 machines. I have tried to add 
> > krb5_use_enterprise_principal
> > = true into domain section of sssd.conf on RHEL 6 IPA clients but problem 
> > still
> > persists. Is there anything else that should be set ?  I have restarted sssd
> > service, both on servers and client, empty sssd_cache and so on but I am 
> > still
> > unable resolve users(on RHEL 6) with short UPN - id and getent passwd 
> > return no
> > such user...We still have more servers on RHEL 6 then on RHEL 7.

SSSD logs from a RHEL 6 client which includes a failing user lookup are
needed to see why it is still failing, see
https://fedorahosted.org/sssd/wiki/Troubleshooting for details.

bye,
Sumit

> > 
> > Thanks,
> > Jan
> > 
> > 
> >> Hi,
> >> 
> >> I just looked into RHEL 6.9 beta repos and I can see there is
> >> sssd-client-1.13.3-53.el6.x86_64 version. I would like to know if with 
> >> rhel 6.9
> >> will come support for using different UPN then domain name. I am talking 
> >> about
> >> AD trust scenario where user in AD domain sits in 
> >> u...@subdomain.example.com
> >> but has a UPN set to u...@example.com. It has been solved in RHEL 7.3 I 
> >> guess
> >> with sssd 1.14. Is ipa-client in RHEL 6.9 able to handle this situation or 
> >> is
> >> there any known workaround ?
> > 
> > This is basically a server side feature. You need an IPA server version
> > which is delivered with RHEL-7.3. SSSD 1.14 in 7.3 can automatically
> > detect if the server supports this or not. This autodetection was not
> > backported to 6.9 but if your servers support it you can set
> > 'krb5_use_enterprise_principal = true' (see man sssd-krb5 for details)
> > on the IPA clients with older SSSD versions.
> > 
> > HTH
> > 
> > bye,
> > Sumit
> > 
> >> 
> >> Thanks,
> >> Jan
> >> 
> > 
> > 
> > --
> > 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
> 
> -- 
> Med venlig hilsen 
> 
> Troels Hansen 
> 
> Systemkonsulent 
> 
> Casalogic A/S 
> 
> 
> T (+45) 70 20 10 63 
> 
> M (+45) 22 43 71 57 
> 
> Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og 
> meget mere.
> 
> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

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

Re: [Freeipa-users] sudo rules are not active immediatly

[Pavel Březina]

On 02/08/2017 11:59 AM, Nathanaël Blanchet wrote:

Hello,
on latest IPA, when adding a command to a rule or a sudo option for
example, the change is not active on the user session.
For example, after removing !authenticate option, I still can execute
sudo commands without password.
I tried to logout and relogin, but nothing changes, but on a new vm
where never logeed in before it wroks.
Is there a cache or somting to do so as to commands to be immediatly
available?



Hi,
sudo rules are cache on the client and refresh happens periodically. We 
have several update mechanisms that deals with finding new rules, 
deleting non-existent ones and updating expired but it cannot be 
performed on desired at the moment. We have a ticket for that [1]. 
Please see 'man sssd-sudo' to get better understanding how it works.


It is possible to expired cached rules with sss_cache. This won't find 
you newly added rules but it will fetch updated rules and removed 
deleted ones.


[1] https://fedorahosted.org/sssd/ticket/2884

--
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- client rhel 6.9 support for UPN different then domain name

[Troels Hansen]

Hi, 

Have you tried setting ldap_user_principal to something nonexisting? For 
example:

ldap_user_principal = nosuchattr

and inherit this to the AD domain with:

subdomain_inherit = ldap_user_principal

Both in the domain section of sssd.

- On Feb 8, 2017, at 12:17 PM, Jan Karásek jan.kara...@elostech.cz wrote:

> Hi, thank you for help.
> 
> I am running RHEL 7.3 on IPA serveres and with RHEL 7.3 clients it works 
> really
> nice.
> Trouble is on RHEL 6 machines. I have tried to add 
> krb5_use_enterprise_principal
> = true into domain section of sssd.conf on RHEL 6 IPA clients but problem 
> still
> persists. Is there anything else that should be set ?  I have restarted sssd
> service, both on servers and client, empty sssd_cache and so on but I am still
> unable resolve users(on RHEL 6) with short UPN - id and getent passwd return 
> no
> such user...We still have more servers on RHEL 6 then on RHEL 7.
> 
> Thanks,
> Jan
> 
> 
>> Hi,
>> 
>> I just looked into RHEL 6.9 beta repos and I can see there is
>> sssd-client-1.13.3-53.el6.x86_64 version. I would like to know if with rhel 
>> 6.9
>> will come support for using different UPN then domain name. I am talking 
>> about
>> AD trust scenario where user in AD domain sits in u...@subdomain.example.com
>> but has a UPN set to u...@example.com. It has been solved in RHEL 7.3 I guess
>> with sssd 1.14. Is ipa-client in RHEL 6.9 able to handle this situation or is
>> there any known workaround ?
> 
> This is basically a server side feature. You need an IPA server version
> which is delivered with RHEL-7.3. SSSD 1.14 in 7.3 can automatically
> detect if the server supports this or not. This autodetection was not
> backported to 6.9 but if your servers support it you can set
> 'krb5_use_enterprise_principal = true' (see man sssd-krb5 for details)
> on the IPA clients with older SSSD versions.
> 
> HTH
> 
> bye,
> Sumit
> 
>> 
>> Thanks,
>> Jan
>> 
> 
> 
> --
> 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

-- 
Med venlig hilsen 

Troels Hansen 

Systemkonsulent 

Casalogic A/S 


T (+45) 70 20 10 63 

M (+45) 22 43 71 57 

Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og 
meget mere.

-- 
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- client rhel 6.9 support for UPN different then domain name

[Jan Karásek]

Hi, thank you for help. 

I am running RHEL 7.3 on IPA serveres and with RHEL 7.3 clients it works really 
nice. 
Trouble is on RHEL 6 machines. I have tried to add 
krb5_use_enterprise_principal = true into domain section of sssd.conf on RHEL 6 
IPA clients but problem still persists. Is there anything else that should be 
set ?  I have restarted sssd service, both on servers and client, empty 
sssd_cache and so on but I am still unable resolve users(on RHEL 6) with short 
UPN - id and getent passwd return no such user...We still have more servers on 
RHEL 6 then on RHEL 7.

Thanks,
Jan


> Hi,
> 
> I just looked into RHEL 6.9 beta repos and I can see there is 
> sssd-client-1.13.3-53.el6.x86_64 version. I would like to know if with rhel 
> 6.9 will come support for using different UPN then domain name. I am talking 
> about AD trust scenario where user in AD domain sits in 
> u...@subdomain.example.com but has a UPN set to u...@example.com. It has been 
> solved in RHEL 7.3 I guess with sssd 1.14. Is ipa-client in RHEL 6.9 able to 
> handle this situation or is there any known workaround ?

This is basically a server side feature. You need an IPA server version
which is delivered with RHEL-7.3. SSSD 1.14 in 7.3 can automatically
detect if the server supports this or not. This autodetection was not
backported to 6.9 but if your servers support it you can set
'krb5_use_enterprise_principal = true' (see man sssd-krb5 for details)
on the IPA clients with older SSSD versions. 

HTH

bye,
Sumit

> 
> Thanks,
> Jan 
> 


-- 
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] sudo rules are not active immediatly

[Nathanaël Blanchet]

Hello,
on latest IPA, when adding a command to a rule or a sudo option for 
example, the change is not active on the user session.
For example, after removing !authenticate option, I still can execute 
sudo commands without password.
I tried to logout and relogin, but nothing changes, but on a new vm 
where never logeed in before it wroks.
Is there a cache or somting to do so as to commands to be immediatly 
available?


--
Nathanaël Blanchet

Supervision réseau
Pôle Infrastrutures Informatiques
227 avenue Professeur-Jean-Louis-Viala
34193 MONTPELLIER CEDEX 5   
Tél. 33 (0)4 67 54 84 55
Fax  33 (0)4 67 54 84 14
blanc...@abes.fr


--
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] Where in the login process is KRB5CCNAME being set

[Jakub Hrozek]

On Wed, Feb 08, 2017 at 09:59:52AM +0100, Kees Bakker wrote:
> Hi,
> 
> This is a follow-up on the problem I had with
>   klist: Invalid UID in persistent keyring name while getting default ccache
> (See "How to enable krb5_child log" earlier this month.)
> 
> The situation is that we have local users with the same name that exist in 
> IPA,
> but the UIDs are different. We have this on several systems, and it is because
> we are in the process of setting up a FreeIPA server.
> 
> Now (so far), on one system the environment variable KRB5CCNAME is set during
> login. (Login via display manager or console, does not matter. If logged via 
> SSH
> then the variable is not set.)
> 
> My question: where / how is that variable being set? I'd like to understand 
> why
> this one system is different from the rest.

The variable is set by pam_sss.so during the authentication phase.

I suspect the difference might be in the PAM stack -- maybe on the
systems where KRB5CCNAME is not set, the PAM stack is configured using
pam_localuser.so so that if the username exists in /etc/passwd, only
pam_unix.so is tried?

> 
> Other details: Ubuntu 16.04 (server and clients).
> 
> BTW. The klist / kinit problem can easily be solved by unsetting that 
> environment
> variable.
> -- 
> Kees
> 
> 
> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

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

[Freeipa-users] Where in the login process is KRB5CCNAME being set

[Kees Bakker]

Hi,

This is a follow-up on the problem I had with
  klist: Invalid UID in persistent keyring name while getting default ccache
(See "How to enable krb5_child log" earlier this month.)

The situation is that we have local users with the same name that exist in IPA,
but the UIDs are different. We have this on several systems, and it is because
we are in the process of setting up a FreeIPA server.

Now (so far), on one system the environment variable KRB5CCNAME is set during
login. (Login via display manager or console, does not matter. If logged via SSH
then the variable is not set.)

My question: where / how is that variable being set? I'd like to understand why
this one system is different from the rest.

Other details: Ubuntu 16.04 (server and clients).

BTW. The klist / kinit problem can easily be solved by unsetting that 
environment
variable.
-- 
Kees


-- 
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] Smart Card login into an Active Directory User

[Sumit Bose]

On Fri, Feb 03, 2017 at 12:59:26PM -0800, spammewo...@cox.net wrote:
> 
>  Sumit Bose  wrote: 
> > On Fri, Feb 03, 2017 at 09:33:13AM +0100, Sumit Bose wrote:
> > On Thu, Feb 02, 2017 at 11:03:28AM -0800, spammewo...@cox.net wrote:
> > > I am running an IPA server (4.4.0) on RHEL 7.3 which is integrated with a 
> > > Windows Active Directory server.   I am trying to configure the IPA 
> > > server to allow the Active Directory Users to log into Gnome with a CAC 
> > > smart card.  I’m having a hard time finding any instructions on how to do 
> > > this.  The problem I’m having is the Common Name from the smart card is 
> > > not getting associated with the Active Directory account.  I added the 
> > > certificate from the smart card to the IPA server by creating a User ID 
> > > override for the AD user account.  I made sure to not use authconfig to 
> > > configure smart cards and I added ifp to the services line in the 
> > > sssd.conf file.
> > > 
> > > I have the following packages installed:
> > > ipa-admintools.noarch   4.4.0-14.el7_3.4  
> > >   
> > > ipa-client.x86_64   4.4.0-14.el7_3.4  
> > >   
> > > ipa-client-common.noarch   4.4.0-14.el7_3.4   
> > > 
> > > ipa-common.noarch   4.4.0-14.el7_3.4  
> > > 
> > > ipa-python-compat.noarch   4.4.0-14.el7_3.4   
> > >   
> > > ipa-server.x86_64   4.4.0-14.el7_3.4  
> > >   
> > > ipa-server-common.noarch   4.4.0-14.el7_3.4   
> > >   
> > > ipa-server-dns.noarch  4.4.0-14.el7_3.4
> > > ipa-server-trust-ad.x86_64  4.4.0-14.el7_3.4
> > > 
> > > I can log in with AD user accounts that are configured with UserName and 
> > > Passswords, so I know that the integration is working.   When I try to 
> > > log into GDM with my smart card,  I don’t get prompted for a PIN number.  
> > > It only asks for the password from the AD account.   
> > 
> > Please have a look at the steps described in
> > https://bugzilla.redhat.com/show_bug.cgi?id=1300420#c9 . Please let me
> > know if you run into issues.
> 
> Please also check if you followed the steps in
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/smart-cards.html
> 
> HTH
> 
> bye,
> Sumit
> 
> -- 
> Hello Sumit,
> I followed the instructions in comment #9.I modified the 
> /etc/pam.d/smartcard-auth file and the two files that are under 
> /etc/dconf/db/distro.d/.   But it still doesn't work.   GDM will prompt me 
> for a password not the PIN when I plug in the smart card.Do I need to run 
> "authconfig --enablesmartcard --smartcardmodule=no_module --update" before I 
> change the files ?Should I remove pam_pkcs11 too ?I have been able to 
> get AD smart card login working using standard authconfig, pam_pkcs11, and 
> the cn_map.I just don't want to use the cn_map file and have to list all 
> of my user's "Common Names" in this file.

With the steps you described running authconfig is not needed and might
even do more harm than good. I think it would be best check the SSSD
logs next.

Please add 'debug_level = 9' at least to the [pam] section of sssd.conf
and restart SSSD (see https://fedorahosted.org/sssd/wiki/Troubleshooting
for details). Now try to authenticate again. The relevant log files are
/var/log/sssd/sssd_pam.log and /var/log/sssd/p11_child.log. The latter
e.g. should show if there are any issues validation the certificate.

Feel free to send the logs file to me directly if you do not want to
share them on a public list.

HTH

bye,
Sumit

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

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

Re: [Freeipa-users] Ubuntu client 2FA not working

[Sumit Bose]

On Mon, Feb 06, 2017 at 01:56:06PM +, Tommy Nikjoo wrote:
> Hi,
> 
> I'm having some issues with 2FA PAM config's on Ubuntu clients. 
> Currently, I'm guessing that the PAM module doesn't know how to talk to
> the 2FA protocol.  Is anyone able to give an in site into how to get
> this working correctly?

In general you have to make sure the pam_sss is the pam modules which
does the conversation with the user and not e.g. pam_unix because
pam_unix will only ask for a password.

E.g. on Fedora/RHEL a general auth part of the PAM configuration might
look like:

authrequired  pam_env.so
auth[default=1 success=ok] pam_localuser.so
auth[success=done ignore=ignore default=die] pam_unix.so nullok 
try_first_pass
authrequisite pam_succeed_if.so uid >= 1000 quiet_success
authsufficientpam_sss.so forward_pass
authrequired  pam_deny.so

The pam_localuser module checks if the user trying to log in is a local
user, i.e. listed in /etc/passwd, and if it is a local user (success=ok)
the next module pam_unix is called. For non-local user the next module
is skipped (default=1) and after the uid check pam_sss is call which now
can prompt the user according to the authentication methods available
for the user on the IPA server.

HTH

bye,
Sumit

> 
> Thanks
> 
> **
> 
>   //
> 
> 
> 
> On 14/12/16 22:48, Fraser Tweedale wrote:
> > On Wed, Dec 14, 2016 at 05:35:35PM +, Tommy Nikjoo wrote:
> >> Hi,
> >>
> >> I'm trying to install FreeIPA on CentOS 7 using the yum package, but I
> >> keep getting an error when it tries to restart DogTag
> >>
> >>   [26/31]: restarting certificate server
> >> ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to restart
> >> the Dogtag instance.See the installation log for details.
> >>   [27/31]: migrating certificate profiles to LDAP
> >>   [error] NetworkError: cannot connect to
> >> 'https://ldap2.armourcomms.com:8443/ca/rest/account/login': ''
> >> ipa.ipapython.install.cli.install_tool(Server): ERRORcannot connect
> >> to 'https://ldap2.armourcomms.com:8443/ca/rest/account/login': ''
> >> ipa.ipapython.install.cli.install_tool(Server): ERRORThe
> >> ipa-server-install command failed. See /var/log/ipaserver-install.log
> >> for more information
> >>
> >>
> >> The log shows the following error
> >>
> >> 2016-12-14T16:53:05Z DEBUG NSSConnection init ldap.example.com
> >> 2016-12-14T16:53:05Z DEBUG Connecting: x.x.x.x:0
> >> 2016-12-14T16:53:05Z DEBUG approved_usage = SSL Server intended_usage =
> >> SSL Server
> >> 2016-12-14T16:53:05Z DEBUG cert valid True for
> >> "CN=ldap.example.com,O=EXAMPLE.COM"
> >> 2016-12-14T16:53:05Z DEBUG handshake complete, peer = x.x.x.x:8443
> >> 2016-12-14T16:53:05Z DEBUG Protocol: TLS1.2
> >> 2016-12-14T16:53:05Z DEBUG Cipher: TLS_RSA_WITH_AES_256_CBC_SHA
> >> 2016-12-14T16:53:05Z DEBUG response status 200
> >> 2016-12-14T16:53:05Z DEBUG response headers {'content-length': '205',
> >> 'set-cookie': 'JSESSIONID=9B6C767CDBED07088646235E68E831E0; Path=/ca/;
> >> Secure; HttpOnly', 'expires': 'Thu, 01 Jan 1970 00:00:00 UTC', 'server':
> >> 'Apache-Coyote/1.1', 'cache-control': 'private', 'date': 'Wed, 14 Dec
> >> 2016 16:53:05 GMT', 'content-type': 'application/xml'}
> >> 2016-12-14T16:53:05Z DEBUG response body ' >> encoding="UTF-8" standalone="yes"?> >> id="ipara">iparaCertificate Manager
> >> AgentsRegistration Manager Agents'
> >> 2016-12-14T16:53:05Z DEBUG request POST
> >> https://ldap.example.com:8443/ca/rest/profiles/raw
> >> 2016-12-14T16:53:05Z DEBUG request body
> >> 'profileId=IECUserRoles\nclassId=caEnrollImpl\ndesc=Enroll user
> >> certificates with IECUserRoles extension via IPA-RA agent
> >> authentication.\nvisible=false\nenable=true\nenableBy=admin\nauth.instance_id=raCertAuth\nname=IPA-RA
> >> Agent-Authenticated Server Certificate
> >> Enrollment\ninput.list=i1,i2\ninput.i1.class_id=certReqInputImpl\ninput.i2.class_id=submitterInfoInputImpl\noutput.list=o1\noutput.o1.class_id=certOutputImpl\npolicyset.list=serverCertSet\npolicyset.serverCertSet.list=1,2,3,4,5,6,7,8,9,10,11,12\npolicyset.serverCertSet.1.constraint.class_id=subjectNameConstraintImpl\npolicyset.serverCertSet.1.constraint.name=Subject
> >> Name
> >> Constraint\npolicyset.serverCertSet.1.constraint.params.pattern=CN=[^,]+,.+\npolicyset.serverCertSet.1.constraint.params.accept=true\npolicyset.serverCertSet.1.default.class_id=subjectNameDefaultImpl\npolicyset.serverCertSet.1.default.name=Subject
> >> Name
> >> Default\npolicyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$,
> >> O=EXAMPLE.COM\npolicyset.serverCertSet.2.constraint.class_id=validityConstraintImpl\npolicyset.serverCertSet.2.constraint.name=Validity
> >>