[Freeipa-users] Re: AD trust nested AD groups

[Alexander Bokovoy via FreeIPA-users]

On ke, 22 huhti 2020, Natxo Asenjo via FreeIPA-users wrote:

hi,

On Wed, Apr 22, 2020 at 7:26 PM Natxo Asenjo  wrote:



In order to use AD nested groups, do we need to add an external IDM group
for every nested group?

specifically, our AD people have global groups (account groups, they say)

with the user accounts, and the domain local groups (resource groups, they
call them) have these global groups as members.

So, in order to grant the people on the domain local groups which have no
direct user members, should we create both external groups in Idm? Both the
global group and the domain local group?


Domain local groups are not visible through the forest trust, so they cannot
be used in FreeIPA for access control means.

Global groups can be used if they are security groups and not just
distribution groups.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: CSR in PRINTABLESTRING enc when docs says UTF8STRING is default

[Fraser Tweedale via FreeIPA-users]

On Mon, Apr 13, 2020 at 08:50:38AM +0300, Alexander Bokovoy via FreeIPA-users 
wrote:
> On su, 12 huhti 2020, Fredrik Arneving via FreeIPA-users wrote:
> > Hi Alexander,
> > 
> > Thank you for explaining this to me.
> > Next question:
> > 
> > Given that my "oranizationName" is given on the command line as an
> > argument to the --ca-subject and --subject-base flags, can you help me
> > figure out if it is possible to give these arguments in some way that
> > the nss library would intrepret as non-printable and hence set the "vt"
> > value as "SEC_ASN1_UTF8_STRING?
> 
> NSS accepts #-hex-encoded values, so if you are able to encode your
> O=... value in advance, express it in hex and specify with
> 
> O=#aabbccddeeff1122334455...
> 
> But I am not sure FreeIPA will accept that at all, not tried that
> myself.
> 

Based on some quick checks, FreeIPA will accept DNs written like
this, but it does not preserve the hex-literal syntax when turning
them back into string.

>>> from ipapython.dn import DN
>>> str(DN("O=#58592050"))
>>> 'O=XY P'
>>>

And I don't think this behaviour is even correct, because it's
directly interpreting the hex data as UTF-8, but it should treat it
as BER ASN.1; see https://tools.ietf.org/html/rfc4514#section-2.4

Cheers,
Fraser

> > Any hints on how to avoid rebuilding my existing PKI infrastructure would 
> > be nice.
> You can create an intermediate manual CA that actually will handle IPA
> CA signing request in the form it is provided.
> 
> -- 
> / Alexander Bokovoy
> Sr. Principal Software Engineer
> Security / Identity Management Engineering
> Red Hat Limited, Finland
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: AD trust nested AD groups

[Natxo Asenjo via FreeIPA-users]

hi,

On Wed, Apr 22, 2020 at 7:26 PM Natxo Asenjo  wrote:

>
> In order to use AD nested groups, do we need to add an external IDM group
> for every nested group?
>
> specifically, our AD people have global groups (account groups, they say)
with the user accounts, and the domain local groups (resource groups, they
call them) have these global groups as members.

So, in order to grant the people on the domain local groups which have no
direct user members, should we create both external groups in Idm? Both the
global group and the domain local group?
--
Groeten,
natxo
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] AD trust nested AD groups

[Natxo Asenjo via FreeIPA-users]

hi,

we have a working one way trust between an AD forest and a RHEL 7 forest.

In order to use AD nested groups, do we need to add an external IDM group
for every nested group?


--
Groeten,
natxo
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Replication issue with CSN generator

[thierry bordaz via FreeIPA-users]

Hi Morgan,

Sure. The most immediate and safest action is to do

|dn: cn=config changetype: modify replace: nsslapd-ignore-time-skew 
nsslapd-ignore-time-skew: on |


On all servers in the topology (no need to restart). Then monitor if 
replication is catching up.
Okay NTP issues is likely the RC of your time skew but there is not easy 
way to prove it if any.


best regards
theirry



On 4/22/20 3:16 PM, Morgan Marodin via FreeIPA-users wrote:

Hi.

I don't have access to RedHat portal :(
There are similar articles in a public forum?

Anyway ... could I stop ipa-server, change the value of 
/nsslapd-ignore-time-skew/ into 
//etc/dirsrv/slapd-IPA-MYDOMAIN-COM/dse.ldif/ and start again the server?

Or is more complicated to change the configuration?

VMs are local, but the cluster where the 1st server is running is 
affected by NTP problems ...
For this reason I want to remove the First Master and install another 
replica in the new cluster.


Thanks, bye.
Morgan

Il giorno mer 22 apr 2020 alle ore 11:33 thierry bordaz via 
FreeIPA-users > ha scritto:


Hi,

CSN generator time skew is a pending issue still under investigation.

At the moment the way your csn generator is messed up looks not
fatal. You can allow replication to continue with the setting of
nsslapd-ignore-time-skew on all servers.
(https://access.redhat.com/solutions/1162703)

If it does not allow replication to continue there is a recovery
procedure but I would recommend to first try ignore-time-skew
(https://access.redhat.com/solutions/3543811)

NTP tuning or specific VMs are suspected to contribute to time
skew. What type of VMs are you using (local or cloud (AWS)) ?

best regards
thierry

On 4/21/20 5:42 PM, Morgan Marodin via FreeIPA-users wrote:

Hi.

Into my environment I have two IPA server, replicating each other.
They are both 7.6 OS systems, ipa-server RPM version is
4.6.4-10.0.1.el7_6.2.x86_64.

The first server installed was srv01 (many years ago), then I
installed the replica into srv02 (like a year later the 1st node).
When I had a single server I did also a trust with my corporate
Active Directory.
VMs are running in 2 different hypervisor clusters.

Now the replication doesn't works. Into log files I have this error:
/[16/Apr/2020:12:25:36.856632697 +0200] - ERR -
csngen_adjust_time - Adjustment limit exceeded; value - 23221226,
limit - 86400
[16/Apr/2020:12:25:36.857909222 +0200] - ERR -
NSMMReplicationPlugin - repl5_inc_run -
agmt="cn=meTosrv01.ipa.mydomain.com
" (srv01:389): Fatal error -
too much time skew between replicas!
[16/Apr/2020:12:25:36.862233147 +0200] - ERR -
NSMMReplicationPlugin - repl5_inc_run -
agmt="cn=meTosrv01.ipa.mydomain.com
" (srv01:389): Incremental
update failed and requires administrator action/

I tried to force the replica, but the limit exceeded problem
doesn't allow the sync.
I know that the problem is that CSN generator has become grossly
skewed.
Using the external script readNsState.py I found that there was
as offset time for about a month, so ... I waited for a month and
then the issue disappeared.
But now the offset is about 9 months ... I can't wait so much time :)

/[root@srv01 scripts]# ./readNsState.py
/etc/dirsrv/slapd-IPA-MYDOMAIN-COM/dse.ldif
nsState is BACCN/xfAHbiBAAABCgNdQ==
Little Endian
For replica
cn=replica,cn=dc\3Dipa\2Cdc\3Dmydomain\2Cdc\3Dcom,cn=mapping
tree,cn=con
  fmtstr=[H6x3QH6x]
  size=40
  len of nsstate is 40
  CSN generator state:
    Replica ID    : 4
    Sampled Time  : 1610364802
    Gen as csn    : 5ffc3782299650004
*Time as str   : Mon Jan 11 12:33:22 2021*
    Local Offset  : 320118
    Remote Offset : 10244
    Seq. num      : 29965
    System time   : Tue Apr 21 15:03:45 2020
    Diff in sec.  : -22890577
    Day:sec diff  : -265:5423

nsState is YAADLZheXSgTAA==
Little Endian
For replica cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config
  fmtstr=[H6x3QH6x]
  size=40
  len of nsstate is 40
  CSN generator state:
    Replica ID    : 96
    Sampled Time  : 1587031299
    Gen as csn    : 5e982d0300190096
    Time as str   : Thu Apr 16 12:01:39 2020
    Local Offset  : 0
    Remote Offset : 10333
    Seq. num      : 19
    System time   : Tue Apr 21 15:03:45 2020
    Diff in sec.  : 442926
    Day:sec diff  : 5:10926

[root@srv02 scripts]# ./readNsState.py
/etc/dirsrv/slapd-IPA-MYDOMAIN-COM/dse.ldif
nsState is AwBU7p5esVNiAQ==
Little Endian
For replica
cn=replica,cn=dc\3Dipa\2Cdc\

[Freeipa-users] Re: Replication issue with CSN generator

[Morgan Marodin via FreeIPA-users]

Hi.

I don't have access to RedHat portal :(
There are similar articles in a public forum?

Anyway ... could I stop ipa-server, change the value of
*nsslapd-ignore-time-skew* into
*/etc/dirsrv/slapd-IPA-MYDOMAIN-COM/dse.ldif* and start again the server?
Or is more complicated to change the configuration?

VMs are local, but the cluster where the 1st server is running is affected
by NTP problems ...
For this reason I want to remove the First Master and install another
replica in the new cluster.

Thanks, bye.
Morgan

Il giorno mer 22 apr 2020 alle ore 11:33 thierry bordaz via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> ha scritto:

> Hi,
>
> CSN generator time skew is a pending issue still under investigation.
>
> At the moment the way your csn generator is messed up looks not fatal. You
> can allow replication to continue with the setting of
> nsslapd-ignore-time-skew on all servers. (
> https://access.redhat.com/solutions/1162703)
>
> If it does not allow replication to continue there is a recovery procedure
> but I would recommend to first try ignore-time-skew (
> https://access.redhat.com/solutions/3543811)
>
> NTP tuning or specific VMs are suspected to contribute to time skew. What
> type of VMs are you using (local or cloud (AWS)) ?
>
> best regards
> thierry
>
> On 4/21/20 5:42 PM, Morgan Marodin via FreeIPA-users wrote:
>
> Hi.
>
> Into my environment I have two IPA server, replicating each other.
> They are both 7.6 OS systems, ipa-server RPM version is
> 4.6.4-10.0.1.el7_6.2.x86_64.
>
> The first server installed was srv01 (many years ago), then I installed
> the replica into srv02 (like a year later the 1st node).
> When I had a single server I did also a trust with my corporate Active
> Directory.
> VMs are running in 2 different hypervisor clusters.
>
> Now the replication doesn't works. Into log files I have this error:
>
>
> *[16/Apr/2020:12:25:36.856632697 +0200] - ERR - csngen_adjust_time -
> Adjustment limit exceeded; value - 23221226, limit - 86400
> [16/Apr/2020:12:25:36.857909222 +0200] - ERR - NSMMReplicationPlugin -
> repl5_inc_run - agmt="cn=meTosrv01.ipa.mydomain.com
> " (srv01:389): Fatal error - too much
> time skew between replicas! [16/Apr/2020:12:25:36.862233147 +0200] - ERR -
> NSMMReplicationPlugin - repl5_inc_run - agmt="cn=meTosrv01.ipa.mydomain.com
> " (srv01:389): Incremental update failed
> and requires administrator action*
>
> I tried to force the replica, but the limit exceeded problem doesn't allow
> the sync.
> I know that the problem is that CSN generator has become grossly skewed.
> Using the external script readNsState.py I found that there was as offset
> time for about a month, so ... I waited for a month and then the issue
> disappeared.
> But now the offset is about 9 months ... I can't wait so much time :)
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *[root@srv01 scripts]# ./readNsState.py
> /etc/dirsrv/slapd-IPA-MYDOMAIN-COM/dse.ldif nsState is
> BACCN/xfAHbiBAAABCgNdQ== Little Endian For
> replica cn=replica,cn=dc\3Dipa\2Cdc\3Dmydomain\2Cdc\3Dcom,cn=mapping
> tree,cn=con   fmtstr=[H6x3QH6x]   size=40   len of nsstate is 40   CSN
> generator state: Replica ID: 4 Sampled Time  : 1610364802
> Gen as csn: 5ffc3782299650004 Time as str   : Mon Jan 11
> 12:33:22 2021 Local Offset  : 320118 Remote Offset : 10244 Seq.
> num  : 29965 System time   : Tue Apr 21 15:03:45 2020 Diff in
> sec.  : -22890577 Day:sec diff  : -265:5423 nsState is
> YAADLZheXSgTAA== Little Endian For
> replica cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config
> fmtstr=[H6x3QH6x]   size=40   len of nsstate is 40   CSN generator state:
>   Replica ID: 96 Sampled Time  : 1587031299 Gen as csn:
> 5e982d0300190096 Time as str   : Thu Apr 16 12:01:39 2020 Local
> Offset  : 0 Remote Offset : 10333 Seq. num  : 19 System
> time   : Tue Apr 21 15:03:45 2020 Diff in sec.  : 442926 Day:sec
> diff  : 5:10926 [root@srv02 scripts]# ./readNsState.py
> /etc/dirsrv/slapd-IPA-MYDOMAIN-COM/dse.ldif nsState is
> AwBU7p5esVNiAQ== Little Endian For
> replica cn=replica,cn=dc\3Dipa\2Cdc\3Dmydomain\2Cdc\3Dcom,cn=mapping
> tree,cn=con   fmtstr=[H6x3QH6x]   size=40   len of nsstate is 40   CSN
> generator state: Replica ID: 3 Sampled Time  : 1587474004
> Gen as csn: 5e9eee540003 Time as str   : Tue Apr 21
> 15:00:04 2020 Local Offset  : 0 Remote Offset : 23221169 Seq.
> num  : 0 System time   : Tue Apr 21 15:02:38 2020 Diff in sec.
>  : 154 Day:sec diff  : 0:154 nsState is
> YQAuLZheAEUB7SYSAA== Little Endian For
> replica cn=replica,c

[Freeipa-users] Re: Ansible tasks for certprofiles and ca-acls

[Rafael Jeffman via FreeIPA-users]

Hi Philipp,

You might not want to use wildcard certificates (
https://tools.ietf.org/html/rfc6125#section-7.2).

I don't know of any module that can directly manage certprofiles and
ca-acls using Ansible and FreeIPA. It is not the best solution, but you
might use `command` and follow the Howto/Wildcard Certificates.

Rafael

On Tue, Apr 21, 2020 at 7:03 PM pleusmann--- via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:

> Hi,
>
> I'd like to issue wildcard-certificates following this guide:
> https://www.freeipa.org/page/Howto/Wildcard_certificates
> Is there any way to manage certprofiles and ca-acls using ansible?
>
> Cheers,
>  Philipp
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
>


-- 
Rafael Guterres Jeffman
Senior Software Engineer
FreeIPA - Red Hat
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Replication issue with CSN generator

[thierry bordaz via FreeIPA-users]

Hi,

CSN generator time skew is a pending issue still under investigation.

At the moment the way your csn generator is messed up looks not fatal. 
You can allow replication to continue with the setting of 
nsslapd-ignore-time-skew on all servers. 
(https://access.redhat.com/solutions/1162703)


If it does not allow replication to continue there is a recovery 
procedure but I would recommend to first try ignore-time-skew 
(https://access.redhat.com/solutions/3543811)


NTP tuning or specific VMs are suspected to contribute to time skew. 
What type of VMs are you using (local or cloud (AWS)) ?


best regards
thierry

On 4/21/20 5:42 PM, Morgan Marodin via FreeIPA-users wrote:

Hi.

Into my environment I have two IPA server, replicating each other.
They are both 7.6 OS systems, ipa-server RPM version is 
4.6.4-10.0.1.el7_6.2.x86_64.


The first server installed was srv01 (many years ago), then I 
installed the replica into srv02 (like a year later the 1st node).
When I had a single server I did also a trust with my corporate Active 
Directory.

VMs are running in 2 different hypervisor clusters.

Now the replication doesn't works. Into log files I have this error:
/[16/Apr/2020:12:25:36.856632697 +0200] - ERR - csngen_adjust_time - 
Adjustment limit exceeded; value - 23221226, limit - 86400
[16/Apr/2020:12:25:36.857909222 +0200] - ERR - NSMMReplicationPlugin - 
repl5_inc_run - agmt="cn=meTosrv01.ipa.mydomain.com 
" (srv01:389): Fatal error - too 
much time skew between replicas!
[16/Apr/2020:12:25:36.862233147 +0200] - ERR - NSMMReplicationPlugin - 
repl5_inc_run - agmt="cn=meTosrv01.ipa.mydomain.com 
" (srv01:389): Incremental update 
failed and requires administrator action/


I tried to force the replica, but the limit exceeded problem doesn't 
allow the sync.

I know that the problem is that CSN generator has become grossly skewed.
Using the external script readNsState.py I found that there was as 
offset time for about a month, so ... I waited for a month and then 
the issue disappeared.

But now the offset is about 9 months ... I can't wait so much time :)

/[root@srv01 scripts]# ./readNsState.py 
/etc/dirsrv/slapd-IPA-MYDOMAIN-COM/dse.ldif

nsState is BACCN/xfAHbiBAAABCgNdQ==
Little Endian
For replica 
cn=replica,cn=dc\3Dipa\2Cdc\3Dmydomain\2Cdc\3Dcom,cn=mapping tree,cn=con

  fmtstr=[H6x3QH6x]
  size=40
  len of nsstate is 40
  CSN generator state:
    Replica ID    : 4
    Sampled Time  : 1610364802
    Gen as csn    : 5ffc3782299650004
*Time as str   : Mon Jan 11 12:33:22 2021*
    Local Offset  : 320118
    Remote Offset : 10244
    Seq. num      : 29965
    System time   : Tue Apr 21 15:03:45 2020
    Diff in sec.  : -22890577
    Day:sec diff  : -265:5423

nsState is YAADLZheXSgTAA==
Little Endian
For replica cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config
  fmtstr=[H6x3QH6x]
  size=40
  len of nsstate is 40
  CSN generator state:
    Replica ID    : 96
    Sampled Time  : 1587031299
    Gen as csn    : 5e982d0300190096
    Time as str   : Thu Apr 16 12:01:39 2020
    Local Offset  : 0
    Remote Offset : 10333
    Seq. num      : 19
    System time   : Tue Apr 21 15:03:45 2020
    Diff in sec.  : 442926
    Day:sec diff  : 5:10926

[root@srv02 scripts]# ./readNsState.py 
/etc/dirsrv/slapd-IPA-MYDOMAIN-COM/dse.ldif

nsState is AwBU7p5esVNiAQ==
Little Endian
For replica 
cn=replica,cn=dc\3Dipa\2Cdc\3Dmydomain\2Cdc\3Dcom,cn=mapping tree,cn=con

  fmtstr=[H6x3QH6x]
  size=40
  len of nsstate is 40
  CSN generator state:
    Replica ID    : 3
    Sampled Time  : 1587474004
    Gen as csn    : 5e9eee540003
    Time as str   : Tue Apr 21 15:00:04 2020
    Local Offset  : 0
    Remote Offset : 23221169
    Seq. num      : 0
    System time   : Tue Apr 21 15:02:38 2020
    Diff in sec.  : 154
    Day:sec diff  : 0:154

nsState is YQAuLZheAEUB7SYSAA==
Little Endian
For replica cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config
  fmtstr=[H6x3QH6x]
  size=40
  len of nsstate is 40
  CSN generator state:
    Replica ID    : 97
    Sampled Time  : 1587031342
    Gen as csn    : 5e982d2e00180097
    Time as str   : Thu Apr 16 12:02:22 2020
    Local Offset  : 325
    Remote Offset : 9965
    Seq. num      : 18
    System time   : Tue Apr 21 15:02:38 2020
    Diff in sec.  : 442816
    Day:sec diff  : 5:10816/

As you can see in the 1st node the Time as str is Jan 11 of 2021.
With timedatectl command I see that both VMs use the same Time zone 
and the clock is correct.


I found this old article to fix my issue:
/https://www.redhat.com/archives/freeipa-users/2014-February/msg7.html/

But ... I had the same issue in the past, always in the 1st server. 
So, in my mind I don't want to try to use that fix.
I have a new hypervisor cluster, so I would prefer to reinstall the