[Freeipa-users] migrating FreeIPA servers to new IP/network -- good idea or better to just rebuild fresh?

[Chris Dagdigian via FreeIPA-users]

I have a nice hard working cluster of 3 FreeIPA servers in an AWS 
account and VPC; all fully patched and updated as of yesterday.


However we have a fancy new "Shared Services" AWS account and central 
VPC all wired up via Transit Gateway to be reachable by all of our other 
accounts and environments and I need to start the process of moving the 
FreeIPA cluster into the new SharedServices environment. Moving FreeIPA 
into the new shared environment will extend our RBAC abilities 
automatically into any new AWS environment we build which would be 
really nice.


I've got an AWS AMI image of each of the FreeIPA systems taken last 
night; was thinking of just launching the AMI in the new AWS account and 
altering DNS to point to the new IP address it will receive. If I move 
one server at a time very slowly I was thinking that replication would 
catch up and things would be OK.


Is this sensible? Or am I better off building a fresh servers with new 
replication agreements and then slowly sun-setting the original cluster 
node members over time?


TL/DR: what is the risk of booting up a configured FreeIPA server with a 
new IP address? Thanks!


Regards
Chris






___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Freeipa-users] Re: question about the scope of FreeIPA LDAPS service - can it authenticate AD trust users or just local IPA users?

[Chris Dagdigian via FreeIPA-users]

Fantastic, thanks so much. Will test ASAP on my end. Thanks confirming 
that this is possible!


Chris





Louis Abel via FreeIPA-users 
November 5, 2020 at 2:56 PM
Yes, it is possible to do so. It will require you to turn on the 
compatibility tree and point to do that dn. More than likely you'll 
need to run `ipa-adtrust-install --enable-compat` on all IPA servers 
that are trust controllers/agents. Once you do so, you'll get a 
cn=compat,... you can use.


Users: cn=users,cn=compat,dc=ipa,dc=example,dc=com
Groups: cn=groups,cn=compat,dc=ipa,dc=example,dc=com

What will happen is all IPA users and groups typically show up 
immediately. But the AD users/groups will not until there is a query 
for them (eg ldapsearch or bind attempt), which should be sufficient. 
In my previous cases of using the compat tree, it was for Solaris, 
FreeBSD, and RHEL 5, and I didn't run into too many issues.


 
	Virus-free. www.avast.com 
 



<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>


___
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

Chris Dagdigian 
November 3, 2020 at 5:07 PM
Dumb question ...

For use cases (temporary/ephemeral/auto-scaling servers) where we 
can't do a full ipa-client-install on a managed node is it possible to 
use the LDAP service on FreeIPA to check a username and password for 
an AD-trust user?


I've been fooling around with making AWS Parallelcluster nodes LDAP 
clients of a FreeIPA environment and it actually works really well 
with users and groups that are local to FreeIPA; it's quite a nice 
solution actually and solves a consistency problem for some users and 
groups we need to persist as HPC grids are launched and destroyed.


Was wondering idly if the LDAP service extended to being able to 
authenticate a user that exists within an AD-trust. It does not seem 
to work out of the box but I was wondering if a change of the LDAP 
bind DN or other settings would allow this to work?


Wanted to ask if this was even possible before I spent more time 
working on my ldap configs!


Regards
Chris



___
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] question about the scope of FreeIPA LDAPS service - can it authenticate AD trust users or just local IPA users?

[Chris Dagdigian via FreeIPA-users]

Dumb question ...

For use cases (temporary/ephemeral/auto-scaling servers) where we can't 
do a full ipa-client-install on a managed node is it possible to use the 
LDAP service on FreeIPA to check a username and password for an AD-trust 
user?


I've been fooling around with making AWS Parallelcluster nodes LDAP 
clients of a FreeIPA environment and it actually works really well with 
users and groups that are local to FreeIPA; it's quite a nice solution 
actually and solves a consistency problem for some users and groups we 
need to persist as HPC grids are launched and destroyed.


Was wondering idly if the LDAP service extended to being able to 
authenticate a user that exists within an AD-trust. It does not seem to 
work out of the box but I was wondering if a change of the LDAP bind DN 
or other settings would allow this to work?


Wanted to ask if this was even possible before I spent more time working 
on my ldap configs!


Regards
Chris
___
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: How far I can take the use of short unqualified names/groups with an AD integrated FreeIPA setup?

[Chris Dagdigian via FreeIPA-users]

Thanks all, the suggestions were incredibly helpful and are working well!

That strikes wishlist item #1 off my list, now on to the next "wish" -- 
seeing if FreeIPA's LDAP service can be used to authenticate AD users 
for scenarios where we can't provide a full IPA client enrollment option.


Regards
Chris



Amos via FreeIPA-users 
October 30, 2020 at 3:21 PM
On Mon, Oct 26, 2020 at 8:04 PM Louis Abel via FreeIPA-users 
> wrote:




* Like in the comments, don't add that on the IPA server's
sssd.conf, only to the clients enrolled to the IPA domain.
* I cannot remember if it also drops the @domain for the groups as
well. You'll have to test this for yourself and see.


yes, it applies to groups as well.

When you do this, you *may* have to put the AD domain as the 
"default_realm" in /etc/krb5.conf.  If you do, just make sure that the 
"[domain_realm]" section has a line for that host to the IPA realm.  
At least that's what we've done, and things seem to work well for both 
the AD users and the hosts in the IPA realm.


Amos




___
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

Chris Dagdigian 
October 23, 2020 at 8:25 AM
Hi folks,

I've got a simple FreeIPA topology with a 1-way trust to a nice 
uncomplicated Active Directory environment. Unlike my other projects 
there is no complex AD forest or topology to navigate; just a single 
integrated domain.


Because of this we have short usernames working for login just fine; 
works great.  Instead of "ch...@domain.com" I can login as "chris"


However I was asked if it was possible to also use short  aka "not 
fully qualified" names when looking at local 'id', user and group info


Basically the question was if it was possible to use short names for 
everything including id views, getent output and group output


This is where my knowledge hits a wall -- I think this level of 
username and group handling is fed into NSS via IPA? If so is there a 
way to alter FreeIPA to use unqualified names -- presumably via 
altering or creating a new Trust View and applying it to the hosts?  
Not really sure if this is sensible or even advisable but I've been 
asked to research


Here is an example:


## Short login works fine! my AD username is "dagdig...@example.com" ...
$ ssh dagdigian@172.17.0.57 
Last login: Thu Oct 22 22:37:32 2020 from 10.10.210.63


## But user are asking about the OS view of usernames and groups:
## Is there a way to use non fully qualified names in these sorts of 
views, possibly via new Trust Views on the IPA server side?

## Is this even reasonable to consider doing?

[dagdig...@example.com@ansible-testhost-01 
 ~]$ id


uid=1087803012(dagdig...@example.com ) 
gid=1087803012(dagdig...@example.com ) 
groups=1087803012(dagdig...@example.com 
),69260(adm...@ipa.example.com 
),692600010(example_admins_po...@exaple.com 
),1087800513(domain 
us...@example.com 
),1087803220(consulta...@example.com 
)
[dagdig...@example.com@ansible-testhost-01 
 ~]$





Thanks!

Regards
Chris





___
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: Is it possible to use the FreeIPA LDAP interface to authenticate AD users?

[Chris Dagdigian via FreeIPA-users]

Replying to myself because I always post at odd hours when nobody is 
reading inbox, heh


Wondering if it is technically possible to use FreeIPA LDAP interface to 
resolve/authenticate AD-users.  Thanks!


Chris


Chris Dagdigian 
October 26, 2020 at 2:31 PM
My use case on AWS involves ephemeral or auto-scaling servers that do 
not live long enough to justify a formal IPA enroll/un-enroll process.


We have a great AD-integrated IPA system running at the moment and 
I've been able to configure a light test client that trusts the IPA CA 
certificate and will become an LDAPS client of the FreeIPA server


This works great for local IPA users but I'm trying to think this 
through and I'm not sure if I can use LDAP to authenticate an AD user? 
Is this even possible?


This is my working sssd.conf for a test client that just uses LDAP -- 
works great for resolving users and groups that are local IPA users 
but so far I can't resolve any of the AD resident users:


[domain/default]
autofs_provider = ldap
cache_credentials = True
ldap_search_base = cn=users,cn=accounts,dc=ipa,dc=example,dc=com
ldap_group_search_base = cn=groups,cn=accounts,dc=ipa,dc=example,dc=com
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
ldap_uri = ldap://ipa001.ipa.example.com/
ldap_id_use_start_tls = True
ldap_tls_cacertdir = /etc/pki/tls/
default_shell = /bin/bash
override_shell = /bin/bash


Is there any method using ldap_search_base or an override of the 
Default Trust View that would allow me to deploy a client that only 
talks LDAP to FreeIPA but is able to resolve and authenticate AD 
users?  I'm wondering if this is even possible or if I'm looking at a 
lost cause. Thanks!


Chris




___
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] Is it possible to use the FreeIPA LDAP interface to authenticate AD users?

[Chris Dagdigian via FreeIPA-users]

My use case on AWS involves ephemeral or auto-scaling servers that do 
not live long enough to justify a formal IPA enroll/un-enroll process.


We have a great AD-integrated IPA system running at the moment and I've 
been able to configure a light test client that trusts the IPA CA 
certificate and will become an LDAPS client of the FreeIPA server


This works great for local IPA users but I'm trying to think this 
through and I'm not sure if I can use LDAP to authenticate an AD user? 
Is this even possible?


This is my working sssd.conf for a test client that just uses LDAP -- 
works great for resolving users and groups that are local IPA users but 
so far I can't resolve any of the AD resident users:


[domain/default]
autofs_provider = ldap
cache_credentials = True
ldap_search_base = cn=users,cn=accounts,dc=ipa,dc=example,dc=com
ldap_group_search_base = cn=groups,cn=accounts,dc=ipa,dc=example,dc=com
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
ldap_uri = ldap://ipa001.ipa.example.com/
ldap_id_use_start_tls = True
ldap_tls_cacertdir = /etc/pki/tls/
default_shell = /bin/bash
override_shell = /bin/bash


Is there any method using ldap_search_base or an override of the Default 
Trust View that would allow me to deploy a client that only talks LDAP 
to FreeIPA but is able to resolve and authenticate AD users?  I'm 
wondering if this is even possible or if I'm looking at a lost cause. 
Thanks!


Chris


___
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] How far I can take the use of short unqualified names/groups with an AD integrated FreeIPA setup?

[Chris Dagdigian via FreeIPA-users]

Hi folks,

I've got a simple FreeIPA topology with a 1-way trust to a nice 
uncomplicated Active Directory environment. Unlike my other projects 
there is no complex AD forest or topology to navigate; just a single 
integrated domain.


Because of this we have short usernames working for login just fine; 
works great.  Instead of "ch...@domain.com" I can login as "chris"


However I was asked if it was possible to also use short  aka "not fully 
qualified" names when looking at local 'id', user and group info


Basically the question was if it was possible to use short names for 
everything including id views, getent output and group output


This is where my knowledge hits a wall -- I think this level of username 
and group handling is fed into NSS via IPA? If so is there a way to 
alter FreeIPA to use unqualified names -- presumably via altering or 
creating a new Trust View and applying it to the hosts?  Not really sure 
if this is sensible or even advisable but I've been asked to research


Here is an example:


## Short login works fine! my AD username is "dagdig...@example.com" ...
$ ssh dagdigian@172.17.0.57 
Last login: Thu Oct 22 22:37:32 2020 from 10.10.210.63


## But user are asking about the OS view of usernames and groups:
## Is there a way to use non fully qualified names in these sorts of 
views, possibly via new Trust Views on the IPA server side?

## Is this even reasonable to consider doing?

[dagdig...@example.com@ansible-testhost-01 
 ~]$ id


uid=1087803012(dagdig...@example.com ) 
gid=1087803012(dagdig...@example.com ) 
groups=1087803012(dagdig...@example.com 
),69260(adm...@ipa.example.com 
),692600010(example_admins_po...@exaple.com 
),1087800513(domain 
us...@example.com 
),1087803220(consulta...@example.com 
)
[dagdig...@example.com@ansible-testhost-01 
 ~]$





Thanks!

Regards
Chris



___
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: How to use the forms based login interface to give IPA admin access to selected federated users?

[Chris Dagdigian via FreeIPA-users]

I think you are right Alexander, the selinux was a false alarm. The 
scriptlet happened to complete exactly after I made the selinux changes 
after I got concerned it was stuck or hung on something; on my 3 other 
IPA systems I allowed the 'dnf module install idm:DL1/adtrust' command 
to run for as long as it liked; eventually both ran successfully to 
completion without me having to adjust things. I think the java process 
just took longer than I was expecting.


Can also confirm that I can login with my AD personae and see the admin 
webUI.


Regards
Chris



Alexander Bokovoy <mailto:aboko...@redhat.com>
October 12, 2020 at 3:48 PM
On ma, 12 loka 2020, Chris Dagdigian wrote:
Thanks Alexander (you've been helpful for *years* on this list, much 
appreciated ...)


Looks like my issue was being unfamiliar with the CentOS/RHEL 8Â 
"dnf" repo commands ...


For CentOS 8 the specific command was:

# dnf module install idm:DL1/adtrust

And for what it's worth installing the new plugin seems to hang 
forever if SELINUX is running and enabled; possibly because my order 
of installation did not set things up so the proper SELINUX policies 
could be set


Thescriptlet: 
ipa-healthcheck-0.4-4.module_el8.2.0+374+0d2d74a1.noarch hangs 
forever during the "dnf module install idm:DL1/adtrust" until you run 
these commands:


# ausearch -c 'java' --raw | audit2allow -M my-java
# semodule -X 300 -i my-java.pp

Out of paranoia I'm going to disable SELINUX while I test out 
allowing AD users to manage IPA just in case any other internal 
process or subsystem hits a SELINUX wall.


Can you please share the exact selinux issues as reported by ausearch?
It may well be inconsistency in CentOS 8.2 rebuilds, especially if you
are trying to use CentOS Stream.

If it is only hsperfdata_pkiuser AVC as below, then it shouldn't be a
big deal and it shouldn't cause any serious issue. This can be ignored
-- it is writing down profiling data that might be used by Java VM but
can live without it.



Regards
Chris


This was the sealert message:
> SELinux is preventing java from read access on the directory > 
hsperfdata_pkiuser.
> > *  Plugin catchall (100. confidence) suggests > 
**
> > If you believe that java should be allowed read access on the > 
hsperfdata_pkiuser directory by default.

> Then you should report this as a bug.
> You can generate a local policy module to allow this access.
> Do
> allow this access for now by executing:
> # ausearch -c 'java' --raw | audit2allow -M my-java
> # semodule -X 300 -i my-java.pp
> > > Additional Information:
> Source Context               
system_u:system_r:tomcat_t:s0
> Target Context               
unconfined_u:object_r:user_tmp_t:s0
> Target Objects                hsperfdata_pkiuser [ 
dir ]

> Source                        java
> Source Path                   java
> Port                         
> Host                         
ipa001.ipa.XXX.com

> Source RPM Packages
> Target RPM Packages
> Policy RPM                   
selinux-policy-3.14.3-41.el8_2.6.noarch

> Selinux Enabled               True
> Policy Type                   targeted
> Enforcing Mode                Enforcing
> Host Name                    ipa001.ipa.XXX.com
> Platform                      Linux 
ipa001.ipa.XXX.com
>                              
4.18.0-193.19.1.el8_2.x86_64 #1 SMP Mon > Sep 14
>                              14:37:00 
UTC 2020 x86_64 x86_64

> Alert Count                   22
> First Seen                    2020-09-25 
19:58:50 UTC
> Last Seen                     2020-10-12 
19:30:57 UTC
> Local ID                     
4bfba108-7f68-4ba5-b5dd-7c74575d31dc

> > Raw Audit Messages
> type=AVC msg=audit(1602531057.835:299): avc:  denied  { read } 
for > pid=4643 comm="java" name="hsperfdata_pkiuser" dev="nvme0n1p2" 
> ino=138422434 scontext=system_u:system_r:tomcat_t:s0 > 
tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=dir permissive=0






> Alexander Bokovoy <mailto:aboko...@redhat.com>
> October 12, 2020 at 3:23 PM
> On ma, 12 loka 2020, Chris Dagdigian via FreeIPA-users wrote:
> > Spoke too soon -- looks like FreeIPA 4.8.7 does not support the > 
> '--idoverrideusers' stuff shown on that URL:
> > > > Usage: ipa [global-options] group-add-member GROUP-NAME 
[options]
> > > > > > $ ipa group-add-member admins --idoverrideusers command>

> &g

[Freeipa-users] Re: How to use the forms based login interface to give IPA admin access to selected federated users?

[Chris Dagdigian via FreeIPA-users]

Thanks Alexander (you've been helpful for *years* on this list, much 
appreciated ...)


Looks like my issue was being unfamiliar with the CentOS/RHEL 8  "dnf" 
repo commands ...


For CentOS 8 the specific command was:

# dnf module install idm:DL1/adtrust

And for what it's worth installing the new plugin seems to hang forever 
if SELINUX is running and enabled; possibly because my order of 
installation did not set things up so the proper SELINUX policies could 
be set


Thescriptlet: ipa-healthcheck-0.4-4.module_el8.2.0+374+0d2d74a1.noarch  
hangs forever during the "dnf module install idm:DL1/adtrust" until you 
run these commands:


# ausearch -c 'java' --raw | audit2allow -M my-java
# semodule -X 300 -i my-java.pp

Out of paranoia I'm going to disable SELINUX while I test out allowing 
AD users to manage IPA just in case any other internal process or 
subsystem hits a SELINUX wall.


Regards
Chris


This was the sealert message:
SELinux is preventing java from read access on the directory 
hsperfdata_pkiuser.


*  Plugin catchall (100. confidence) suggests 
**


If you believe that java should be allowed read access on the 
hsperfdata_pkiuser directory by default.

Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'java' --raw | audit2allow -M my-java
# semodule -X 300 -i my-java.pp


Additional Information:
Source Context    system_u:system_r:tomcat_t:s0
Target Context    unconfined_u:object_r:user_tmp_t:s0
Target Objects    hsperfdata_pkiuser [ dir ]
Source    java
Source Path   java
Port  
Host  ipa001.ipa.XXX.com
Source RPM Packages
Target RPM Packages
Policy RPM    selinux-policy-3.14.3-41.el8_2.6.noarch
Selinux Enabled   True
Policy Type   targeted
Enforcing Mode    Enforcing
Host Name ipa001.ipa.XXX.com
Platform  Linux ipa001.ipa.XXX.com
  4.18.0-193.19.1.el8_2.x86_64 #1 SMP Mon 
Sep 14

  14:37:00 UTC 2020 x86_64 x86_64
Alert Count   22
First Seen    2020-09-25 19:58:50 UTC
Last Seen 2020-10-12 19:30:57 UTC
Local ID  4bfba108-7f68-4ba5-b5dd-7c74575d31dc

Raw Audit Messages
type=AVC msg=audit(1602531057.835:299): avc:  denied  { read } for 
pid=4643 comm="java" name="hsperfdata_pkiuser" dev="nvme0n1p2" 
ino=138422434 scontext=system_u:system_r:tomcat_t:s0 
tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=dir permissive=0







Alexander Bokovoy <mailto:aboko...@redhat.com>
October 12, 2020 at 3:23 PM
On ma, 12 loka 2020, Chris Dagdigian via FreeIPA-users wrote:
Spoke too soon -- looks like FreeIPA 4.8.7 does not support the 
'--idoverrideusers' stuff shown on that URL:


Usage: ipa [global-options] group-add-member GROUP-NAME [options]


$ ipa group-add-member admins --idoverrideusers 
Usage: ipa [global-options] group-add-member GROUP-NAME [options]

ipa: error: no such option: --idoverrideusers


Neither the group-add-member or the role-add-member seem to support 
the "--idoverrideuser" required to make this work.


Are the docs outdated or is my IPA version?


You need to be clear about your runtime environment.

FreeIPA 4.8.7+ is available in Fedora and RHEL 8.3 beta.

My understanding is that Ubuntu version does not support trust to Active
Directory due to linking issues with Heimdal in Ubuntu's version of
Samba.

In RHEL 8.2 the 'third-party' plugin that David talks about is installed
automatically when
 dnf module install idm:DL1/trust

is done.

Since that modifies server side API, a client side API cache needs to
expire or be cleaned. E.g.

  rm -rf ~/.cache/ipa/

needs to be done and then next run of 'ipa ...' CLI would re-acquire new
metadata for IPA API that should be able to show --idoverrideusers
command:

ipa group-add-member --help
Usage: ipa [global-options] group-add-member GROUP-NAME [options]

Add members to a group.
Options:
  -h, --help    show this help message and exit
  --external=STR    Members of a trusted domain in DOM\name or 
name@domain

    form
  --all Retrieve and print all attributes from the 
server.

    Affects command output.
  --raw Print entries as stored on the server. Only 
affects

    output format.
  --no-members  Suppress processing of membership attributes.
  --users=STR   users to add
  --groups=STR  groups to add
  --services=STR    services to add
  --idoverrideusers=STR
    User ID overrides to add




Thanks!

Chris


> David Sastre <mailto:d

[Freeipa-users] Re: How to use the forms based login interface to give IPA admin access to selected federated users?

[Chris Dagdigian via FreeIPA-users]

Spoke too soon -- looks like FreeIPA 4.8.7 does not support the 
'--idoverrideusers' stuff shown on that URL:


Usage: ipa [global-options] group-add-member GROUP-NAME [options]


$ ipa group-add-member admins --idoverrideusers 
Usage: ipa [global-options] group-add-member GROUP-NAME [options]

ipa: error: no such option: --idoverrideusers


Neither the group-add-member or the role-add-member seem to support the 
"--idoverrideuser" required to make this work.


Are the docs outdated or is my IPA version?

Thanks!

Chris



David Sastre 
October 12, 2020 at 2:10 PM
Does this help?

https://freeipa.readthedocs.io/en/latest/designs/adtrust/admin-ipa-as-trusted-user.html#usage

Chris Dagdigian 
October 12, 2020 at 1:59 PM
Hi folks,

I've got a three-node replicating FreeIPA cluster running in AWS with 
a one-way trust to an Active Directory domain.


Things work well with respect to user overrides and RBAC rules 
affecting client machines but I can't for the life of me figure out 
the order of operations for allowing a couple of external AD users to 
have admin access to the FreeIPA webUI itself.


There are 3 AD users I'd like to give WebUI admin access to.

So far I've tried the standard stuff I've used for non-IPA clients:

1) make group "corp_admins_external" populated with external 
"usern...@domain.com" identities
2) Make group "corp_admins_posix" populated with the 
corp_admins_external group

3) Added corp_admins_posix group to the admin group

Best I've been able to do so far is give myself login access to just 
the user self-service page and even then that failed until 
oddjob-mkhomedir() was running and enabled under authconfig


Is there a guide or a documentation set specific to granting admin 
access to the webUI for forms-based login users?


Thanks!

Chris




___
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: How to use the forms based login interface to give IPA admin access to selected federated users?

[Chris Dagdigian via FreeIPA-users]

Aha ! I was missing the Default Trust View work -- much appreciated!

Chris



David Sastre 
October 12, 2020 at 2:10 PM
Does this help?

https://freeipa.readthedocs.io/en/latest/designs/adtrust/admin-ipa-as-trusted-user.html#usage

Chris Dagdigian 
October 12, 2020 at 1:59 PM
Hi folks,

I've got a three-node replicating FreeIPA cluster running in AWS with 
a one-way trust to an Active Directory domain.


Things work well with respect to user overrides and RBAC rules 
affecting client machines but I can't for the life of me figure out 
the order of operations for allowing a couple of external AD users to 
have admin access to the FreeIPA webUI itself.


There are 3 AD users I'd like to give WebUI admin access to.

So far I've tried the standard stuff I've used for non-IPA clients:

1) make group "corp_admins_external" populated with external 
"usern...@domain.com" identities
2) Make group "corp_admins_posix" populated with the 
corp_admins_external group

3) Added corp_admins_posix group to the admin group

Best I've been able to do so far is give myself login access to just 
the user self-service page and even then that failed until 
oddjob-mkhomedir() was running and enabled under authconfig


Is there a guide or a documentation set specific to granting admin 
access to the webUI for forms-based login users?


Thanks!

Chris




___
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] How to use the forms based login interface to give IPA admin access to selected federated users?

[Chris Dagdigian via FreeIPA-users]

Hi folks,

I've got a three-node replicating FreeIPA cluster running in AWS with a 
one-way trust to an Active Directory domain.


Things work well with respect to user overrides and RBAC rules affecting 
client machines but I can't for the life of me figure out the order of 
operations for allowing a couple of external AD users to have admin 
access to the FreeIPA webUI itself.


There are 3 AD users I'd like to give WebUI admin access to.

So far I've tried the standard stuff I've used for non-IPA clients:

1) make group "corp_admins_external" populated with external 
"usern...@domain.com" identities
2) Make group "corp_admins_posix" populated with the 
corp_admins_external group

3) Added corp_admins_posix group to the admin group

Best I've been able to do so far is give myself login access to just the 
user self-service page and even then that failed until 
oddjob-mkhomedir() was running and enabled under authconfig


Is there a guide or a documentation set specific to granting admin 
access to the webUI for forms-based login users?


Thanks!

Chris

___
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] Anyone integrate FreeIPA 4.8.x with Okta LDAPS service recently?

[Chris Dagdigian via FreeIPA-users]

Hi folks,

Has anyone configured the LDAP service of Okta to push users into 
FreeIPA recently? Looking for tips/tricks more recent than this page 
https://www.freeipa.org/page/HowTo/Integrate_With_Okta which I think 
dates back to 2014.


I can get the Okta agent running on the FreeIPA host and talking to Okta 
but user provisioning fails with a DN parsing related error that makes 
me think that something is now different about (a) telling Okta what 
LDAP type/scheme is used on the other end or (b) setting up the 
attribute mapping.


This is my Okta ldap agent error when a user is pushed into FreeIPA -- I 
100% understand this is an Okta config and Okta agent config thing but 
am just wondering if anyone has been down this road recently. If not 
I'll try to write up my notes if I can get it working.



This is my error as of now. The RDN value is mapped to Okta 'uid' 
attribute which always resolves to an email address like DN. I'm going 
to blow everything away and restart fresh as I changed too many things 
while debugging the current config:


[ 2020-09-25 21:39:14.859 ] [ Thread-15 ] [ INFO  ] [LdapRestClient:478] 
- GET 
https://.okta.com/api/1/internal/app/agent/ldap_sun_one/0oa5o6gyetYbGjxtO357/agent/a535o686296OdyT6j357/nextAction?agentVersion=5.6.6
[ 2020-09-25 21:39:14.859 ] [ pool-2-thread-3 ] [ ERROR ] 
[UnboundIDLdapClient:531] - Error during ModifyRequest. ResultCode=34 
(invalid DN syntax) exception=
com.unboundid.ldap.sdk.LDAPException: Unable to parse string 
'd...@xxx.net' as a DN because it does not have an equal sign after RDN 
attribute 'd...@xxx.net'.

    at com.unboundid.ldap.sdk.DN.(DN.java:434)
    at com.unboundid.ldap.sdk.DN.(DN.java:300)
    at com.unboundid.ldap.sdk.DN.getParentString(DN.java:1055)
    at 
com.okta.ldap_agent.client.unboundid.UnboundIDLdapClient.moveEntry(UnboundIDLdapClient.java:902)
    at 
com.okta.ldap_agent.client.unboundid.UnboundIDLdapClient.modifyEntry(UnboundIDLdapClient.java:483)
    at 
com.okta.ldap_agent.connectors.ldap.LdapConnectorExecutorImpl.modifyEntry(LdapConnectorExecutorImpl.java:67)
    at 
com.okta.ldap_agent.adapters.LdapDirectoryAdapter.modifyEntry(LdapDirectoryAdapter.java:175)
    at 
com.okta.ldap_agent.handlers.WriteObjectActionHandler.performAction(WriteObjectActionHandler.java:43)
    at 
com.okta.ldap_agent.LdapAgent.lambda$dispatchAction$0(LdapAgent.java:253)
    at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)

    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
    at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)

    at java.lang.Thread.run(Thread.java:748)
[ 2020-09-25 21:39:14.860 ] [ pool-2-thread-3 ] [ ERROR ] 
[WriteObjectActionHandler:65] - Interchange error: 34, Unable to parse 
string 'd...@xxx.net' as a DN because it does not have an equal sign 
after RDN attribute 'd...@xxx.net'.





___
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: Deploying IPA on AWS

[Chris Dagdigian via FreeIPA-users]

Replies inline ...

And our setup  is strange as we could never get the global AD admins to make DNS
entries for us among other issues so we ended up choosing a totally new
TLD domain name to run IPA on and bind our servers against; this works
fine except we can't leverage kerberos based features because our realm
is different from our domain.

You can enrol IPA client through through Kerberos, this correct?

Yep! Our oddball IPA setup looks like this, due to a combination of 
senior IT leadership being frightened of the cloud and global active 
directory domain admins doing their usual global admin thing and 
refusing to even take meetings with mortals. So we had to self-support 
and only got a grudging 1-way trust set with the domain after escalating 
to very high levels. It works though.


   AD Domain (complex multi-child forest)  == company-x.com with child 
domains at  nafta.company-x.com, apac.company-x.com etc. etc.

   Our FreeIPA domain name is == company-x-ipa.com

So our REALM is COMPANY-X-IPA and that is where we bind our client 
machines to when enrolling but we set the local domain name and hostname 
to "company-x.com" when we enroll the host


This works well but from what I've been told we lose the ability to do 
things like kerberized authentication for filessytem mounts etc. -- 
since all we really needed was RBAC managed SSH login with a small 
smattering of custom sudo roles and a bunch of local SSH key storage it 
works fine for us.



I wish its this, but I dont think so.  If it was this, wouldn't doing
dig @192.168.30.8 neptune.external.example.com work at least?  The
host 192.168.30.8 being in the office?  How is your VPC?   Do you have
public and private and NAT between?  Or just a flat public?  I went
with the later as I assumed IPA don't like working over NAT.
Yeah most of this DNS is on-premise; again because of a corporate desire 
to use AD for DNS. We basically point all our nameservers at the on-prem 
domain controllers and don't use FreeIPA for DNS records really much at 
all (even the _SVR records that enable FreeIPA auto-discovery) -- but no 
network, DNS query or technical issues at all with DNS being outside of 
AWS -- works fine for us even DNS queries made on the IPA masters.   For 
rare cases where that did not work (HPC use cases)  we did the DNSMasq 
thing so we could inject custom reverse DNS responses while still 
delegating other queries back to the domain controllers.


Our VPC is direct connected back to the corporate WAN; no NAT on the 
private AWS subnets so it would be flat/private.  Lots of security 
controls and firewalls doing SSL intercept and decrypt at edges that 
blocked




Thanks again for the feedback.

Regards,
William


___
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: Deploying IPA on AWS

[Chris Dagdigian via FreeIPA-users]

I run a 4-node IPA cluster on AWS spanning a few global regions and tied 
into a particularly complex AD forest -- never had the DNS issues you 
mention but I've never had to talk to IPA on-prem either. And our setup 
is strange as we could never get the global AD admins to make DNS 
entries for us among other issues so we ended up choosing a totally new 
TLD domain name to run IPA on and bind our servers against; this works 
fine except we can't leverage kerberos based features because our realm 
is different from our domain.  All we needed was RBAC login using AD 
usernames and passwords though so our needs are met.


For DNS on AWS though ...

- You can override or alter DHCP level nameserver assignments at a 
VPC-level if you want to adjust DHCP option sets. This  is a big 
decision as it is VPC-wide in scope but works well to push out "global" 
DNS and nameserver preferences


- If VPC level changes are too much then it's pretty easy on an EC2 
instance to override or alter DNS resolution, nameservers and search 
order in ways that persist beyond reboot. Specific method depends OS you 
are using and if you want to this on the CLI via ansible or manual 
operations or if you want to do this at the cloud-init "just booting up" 
level


I did have a nasty DNS issue in the past with an old school client that 
believed all DNS should be served out of AD and that pre-creating 
reverse PTR records was "nonsense" and "not needed" which broke a ton of 
AWS HPC and EMR use cases and other projects where software does a 
reverse lookup on it's IP to learn more about its self.  In that setting 
we built our own custom DNS server based on DNSMasq -- DNSMasq is 
perfect because you can construct a totally bespoke DNS environment 
combining delegated nameservers, local name servers and you can even 
have DNSMasq read DNS entries from an /etc/hosts style file so you don't 
have to maintain a complex bind-format zone file



I don't know the exact scope of your situation but this seems like a 
case for overriding the DNS settings on the EC2 hosts running IPA to 
talk to your colo nameservers rather than the AWS designated ones that 
show up via your DHCP Option Set


Chris



William Muriithi via FreeIPA-users wrote on 5/27/20 10:30 AM:

Hello everyone

We want to move some of the systems for a co-location into AWS.  IPA
systems are some of  our candidate  servers.

I have attempted to get this working by setting up a replica server in
the cloud and attempting to setup replication - over VPN - and its not
working.  This is due to DNS issue on AWS being biased toward AWS DNS.
If I use nmap, it verify I can reach port 53 (TCP and UDP) on the
co-location from AWS, but if I do a dig against existing DNS, it
doesn't seem to resolve.

Have anyone gone through the exercise recently and managed to figure
how to work around this limitation?  Would be grateful if someone can
share how the worked around this problem.

Regards,
William
___
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] Can AD admins convert a 1-way trust to a 2-way trust without touching the freeIPA system?

[Chris Dagdigian via FreeIPA-users]

I just got CCd on an email chain concerning a conversion of 1-way AD 
trusts to 2-way trust for some realms and domains we use in one of the 
public cloud providers.


The AD team is finally responding to all the issues they caused us in 
the cloud by refusing a 2-way trust in the first place. It caused enough 
hassles on the pure Windows side of things that Senior Management got 
involved, heh.


I was the one who worked with the AD folk to set up the 1-way trust to 
our custom realm and it involved pre-shared secrets and joint 
coordinated actions.


But this time around the language in the email is sort of like "hey we 
are just giving you a heads up on a change that will be made live this 
weekend .."


So consider this a vague query along the lines of "Will this actually 
work?"  -- Can a 1-way trust be made into a 2-way trust with actions 
entirely performed on the AD side of things? The AD people have no 
access and no idea how FreeIPA works.


I was sort of thinking that I'd have to tear down the 1-way and set up a 
new 2-way trust but then I realized I've never done that before and I'm 
not sure how it works on the AD side of things.


Any tips on FreeIPA and 1-way to 2-way trust conversions would be 
appreciated, thanks!


Chris
___
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] Seeking URLs/docs/tips on handling UPN change in a complex already-trusted AD topology

[Chris Dagdigian via FreeIPA-users]

Hi folks,

Environment:   AWS-based FreeIPA cluster with it's own unique 
realm/domain that is bound to the AD domain of the real COMPANY.COM and 
a fairly complex forest


We have a functional FreeIPA system at the moment where AD users from 
COMPANY.COM can login


- via  @CHILD-DOMAIN.COMPANY.COM on older systems

- via @COMPANY.COM on newer systems with fresh SSSD 
(thank you AD search domains, heh!)



But we've gotten word from AD admins that they want to change the UPN 
from  to ".@company.com" and 
although I did not witness it supposedly when they made the change, all 
SSH logins to our FreeIPA managed systems broke.


I'm still not 100% convinced that things broke and we'll be testing more 
this week  --- but now I'm motivated to try to get ahead of any 
potential problems ...


Looking for documentation and URLS to read or general tips and advice 
regarding any impact or changes needed on FreeIPA when the UPN on Active 
Directory changes format.


In particular:

- What happens to existing IPA user groups of type "external" when we've 
listed those AD usernames via their 
@CHILD-DOMAIN.COMPANY.COM  and the UPN is now different? Do 
we have to go update/change/fix all of our external users?  If so, do 
those changes propagate into all of the other RBAC rules or are we 
looking at an entire rebuild/reset of our RBAC and user environment?


- Any FreeIPA changes or settings to look at or alter when UPN changes 
format?


I'm probably missing other major questions to ask so any other tips or 
advice would be appreciated.


Regards
Chris

___
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] How to extract the SSL key and certificate used by FreeIPA on it's HTTPS interface?

[Chris Dagdigian via FreeIPA-users]

Got a strange one for the list ...

I've got a lovely multi-region replicating FreeIPA cluster spanning a 
few AWS VPCs that is doing a fantastic job stitching together a complex 
Active Directory topology


Now, however I have a need to support clients in a different, less 
trusted VPC and the firewall people want to do a MiTM attack on the 
TLS/HTTPS streams so they can intercept, decrypt and monitor HTTPS 
traffic -- including apparently to and from the IPA nodes.


They want the SSL cert and key used by the HTTPS interface on the IPA 
systems so they can set up the intercept properly.


My main question -- how do I properly extract the key and certificate 
from FreeIPA?


From reading and poking around it looks like the certs I want are in 
/etc/httpd/alias but must be access by the 'certutil' utility which 
seems .. under documented  ... both in the IPA docs as well as from what 
I can tell online.


I'm sort of terrified of breaking my installation by screwing up 
certificate work.


Can anyone provide tips, URLs or a cheatsheet for pulling SSL 
certificates and keys out of FreeIPA? Particularly the cert and key that 
is used on the HTTPS TCP:443 interface?


Thanks!

Chris

___
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: can clients or servers be pinned to named Active Directory servers to bypass DNS auto-discovery?

[Chris Dagdigian via FreeIPA-users]

Thanks! Replies in line




Alexander Bokovoy wrote on 10/24/18 8:40 AM:

On ke, 24 loka 2018, Chris Dagdigian via FreeIPA-users wrote:
Is it possible to override the AD integration use of DNS queries to 
find AD controllers and replace the auto-discovery with a named list 
of domain controllers?

Where? In 'ipa trust-add' or in SSSD? The former has already a mechanism
by specifying a domain controller to contact.


Trust is already built and that took *months* to arrange with the 
mysterious AD admins who do not talk to mere mortals. Not going to mess 
with that! Looking to pin IDM interactions with named AD servers at the 
sssd.conf level I think


We've got a setup in an AWS VPC and we've found that out of the 100 
or so domain controllers in DNS that a few of them refuse to talk to 
us or answer ldaps:// queries. After a lot of nmap and DNS probe work 
we think we've discovered a number of "bad" controllers that may be 
responsible for random password check / login failures in the AWS 
environment


Can the latest sssd/free-ipa be configured to use a list of "known 
good" domain controllers?

SSSD can be pinned down to the specific site and also to specific domain
controllers in 1.16+. Some of the configurations are possible with
earlier versions too, see manual page for sssd-ipa(5), section "Trusted
domains configuration".


Thank you ! We will research/test this


Love this list and the resources on it!

Regards,
Chris


___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] can clients or servers be pinned to named Active Directory servers to bypass DNS auto-discovery?

[Chris Dagdigian via FreeIPA-users]

Is it possible to override the AD integration use of DNS queries to find 
AD controllers and replace the auto-discovery with a named list of 
domain controllers?


We've got a setup in an AWS VPC and we've found that out of the 100 or 
so domain controllers in DNS that a few of them refuse to talk to us or 
answer ldaps:// queries. After a lot of nmap and DNS probe work we think 
we've discovered a number of "bad" controllers that may be responsible 
for random password check / login failures in the AWS environment


Can the latest sssd/free-ipa be configured to use a list of "known good" 
domain controllers?


Thanks!

Chris
___
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://getfedora.org/code-of-conduct.html
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 admin account I use for trust setup is getting audited - what specific permissions does the AD user need to have for trust setup?

[Chris Dagdigian via FreeIPA-users]

Just replying to say 'thanks' to Alexander and the list in general. This 
was exactly what I needed. The tech answers and signal:noise ratio in 
this list is pretty fantastic.


-Chris



Alexander Bokovoy 
June 13, 2018 at 7:33 AM

What do you use this 'idmbind' account for?

If you are using it to establish trust to AD which is a one-time
operation, then by Microsoft's own requirements that account should be a
member of Enterprise Admin group in the AD forest _or_ a member of
Domain Admins group in the forest root domain for AD forest.

https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/active-directory-security-groups#bkmk-entadmins 

https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/active-directory-security-groups#bkmk-domainadmins 



See details at 
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc773178(v=ws.10) 




To create a forest trust, the administrator creating the trust must be a
member of the Domain Admins group (in the forest root domain) or the
Enterprise Admins group in Active Directory. Each trust is assigned a
password that the administrators in both forests must know. Members of
Enterprise Admins in both forests can create the trusts in both forests
at once and, in this scenario, a password that is cryptographically
random is automatically generated and written for both forests.

Members of the Incoming Forest Trust Builders group can create one-way,
incoming forest trusts. For example, members of this group residing in
Forest A can create a one-way, incoming forest trust from Forest B. This
one-way, incoming forest trust allows users in Forest A to access
resources located in Forest B. Members of this group are granted the
permission Create Inbound Forest Trust on the forest root domain. This
group has no default members.


As you can see, for one-way trust there is another group that could be
used but we never tested whether those permissions would be enough.




___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/HDDJE3W5DK5KVWYW5GKHG4KIBHPVMTHQ/

[Freeipa-users] AD admin account I use for trust setup is getting audited - what specific permissions does the AD user need to have for trust setup?

[Chris Dagdigian via FreeIPA-users]

Hi folks,

Tried to find this in the FreeIPA and RHEL IDM docs but could not find 
my answer with any specificity ...


I have a user account called "idmbind" inside an AD controller for a 
domain that we integrate with our linux fleet in AWS


Because this domain is non-essential and we had full control we got lazy 
and just made the "idmbind" account as privileged as possible -- it's 
currently part of the "Domain Admin" and "Enterprise Admin" groups


Now that crunch time is over we are auditing all our AD user accounts. 
I've been specifically asked:


"Does your idmbind user really need Enterprise Admin group membership?"

"Does your idmbind user really need Domain Admin group membership?"

Is there a concise answer somewhere on what permissions/roles the local 
AD user account needs to have when we use that username and password to 
set up 1-way and 2-way trusts with FreeIPA? The docs and screenshots 
show the words "domain administrator" but I'm wondering if the 
requirements are more specific.


I figure "Domain Admin yes, Enterprise Admin no" may be the proper 
answer but looking for a more authoritative voice, thanks!


Chris

___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/SPR72YHCMOQKZS62SKGDF7BVVS3NO72P/

[Freeipa-users] dumb question - how many AD trust setup interactions are needed for multi-node replicating IPA cluster

[Chris Dagdigian via FreeIPA-users]

Hi folks,

Multi-region AWS IPA user here. We've got an ancient and brittle IPA 
setup with broken replication and an inability to upgrade. Rather than 
fix I want to stand up a whole new set of IPA servers running the latest 
version so I can get replication working again as well as leverage all 
the great new features in IPA and SSSD subsystem.


However in my environment it's an incredibly complex process to set up a 
1-way trust with Active Directory.


The administrators work for a managed service provider and they are 
outside of the normal support loop so they rarely interact with peons 
and outsiders like myself. Just getting their attention is a procedural 
and political effort.  The first AD trust took more than 3 months to 
setup (!)



I need to start the process again for requesting a new AD trust 
arrangement for the new IPA servers I intend to build.


Realized that I had a really dumb question ...

If my goal is to have a 4-node replicating cluster (2x in us-east AWS 
region and 2x in eu-central-2 region) how many discrete AD trusts do I 
actually have to arrange with my remote AD administrators?


If I get a good 1-way trust working on a single IPA node in the cluster, 
will the replicating targets inherit this trust?


Do I need to set up the trust individually on each of the 4 planned IPA 
boxes?


Thanks!

_Chris

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] IPA 4.5 upgrade or clean install on CentOS/RHEL-7.4 has never worked for us (webUI fails) -- Latest guidance?

[Chris Dagdigian via FreeIPA-users]

Hi folks,

Stuck in a catch-22 where I can't update our existing 4.4.0 production 
servers nor can we stand up new working sandbox servers running IPA-4.5


In all cases (upgrade and new install) we end up with a WebUI that is 
not functional when deployed on RHEL 7.4 or CentOS 7.4


However I think now I have the actual error and there were hints from 
the mailing list archive about the culprit maybe being httpd and keytab 
related. Or at least it seems tightly tied to the security changes 
implemented between IPA 4.4 and 4.5 releases.



Here is the setup from a fresh install on RHEL 7.4

- CLI installation works perfectly
- AD trust setup works perfectly
- All CLI tools and commands seem to work just fine
- No errors in standard locations
- "ipactl status" reports no issues
- SELINUX is disabled
- Using Chrome browser for access and testing


However the WebUI is totally unusable. The front page just displays an 
error box that says:


HTTP Error 404
Cannot connect to the server, please check API accesibility 
(certificate, API, proxy, etc.)



Reading the lists archives this weekend I found the links that point to 
the security changes between 4.4 and 4.5 and I also found the helpful 
advice to set "debug=true" in /etc/ipa/server.conf



After setting the debug=true values now I see a new message in the httpd 
error logs:



[Sun Dec 10 03:13:08.976509 2017] [:error] [pid 7821] ipa: INFO: *** 
PROCESS START ***
[Mon Dec 11 11:55:07.102172 2017] [auth_gssapi:error] [pid 7824] [client 
172.29.XX.XX:57976] NO AUTH DATA Client did not send any authentication 
headers, referer: https://usaeilidmp010.XXX.org/ipa/ui/
[Mon Dec 11 11:55:07.298810 2017] [auth_gssapi:error] [pid 7824] [client 
172.29.XX.XX:57976] GSS ERROR In Negotiate Auth: 
gss_accept_sec_context() failed: [An unsupported mechanism was requested 
(Unknown error)], referer: https://usaeilidmp010.XXX.org/ipa/ui/

[root@usaeilidmp010 ec2-user]#


Those error messages have come up in past forum messages but the thread 
replies always led me into a maze of other URls or generic instructions 
to "regenerate the keytab for HTTPD server"



I'm pretty sure the above web error is exactly why the webUI is failing 
however I can't find clear or concise instructions on how to fix or 
debug further ...


Has anyone dealt with this already?  I may need an idiot's guide to 
resolving that particular gss error as I failed at doing so myself this 
weekend :)  I pretty much do not understand that error nor how to 
address it, heh.


Thanks!

-Chris



___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] freeIPA webUI failure after 4.5 upgrade on CentOS

[Chris Dagdigian via FreeIPA-users]

Did the "yum upgrade" followed by  "sudo ipa-server-upgrade" followed by 
a reboot on two different IPA servers


Now the webUI fails on both. The webUI error is:

Cannot connect to the server, please check API accesibility 
(certificate, API, proxy, etc.)


httpd error log says this:


[Fri Nov 17 14:08:38.914506 2017] [:error] [pid 2748] ipa: INFO: *** 
PROCESS START ***
[Fri Nov 17 14:08:39.002769 2017] [:error] [pid 2747] ipa: INFO: *** 
PROCESS START ***
[Fri Nov 17 14:11:42.214284 2017] [auth_gssapi:error] [pid 2749] [client 
172.29.128.180:54933] NO AUTH DATA Client did not send any 
authentication headers, referer: https://usaeilidmp002.xxx.org/ipa/ui/
[Fri Nov 17 14:11:42.304960 2017] [auth_gssapi:error] [pid 2749] [client 
172.29.128.180:54933] GSS ERROR In Negotiate Auth: 
gss_accept_sec_context() failed: [An unsupported mechanism was requested 
(Unknown error)], referer: https://usaeilidmp002.xxx.org/ipa/ui/

[root@usaeilidmp002 httpd]#


Browser is Chrome - same as I've always been using to access the admin UI

Any tips or guidance?  May have to restore from backup


Chris


___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] pointing SSSD/IPA at named AD domain controllers now with recent updates?

[Chris Dagdigian via FreeIPA-users]

The most fragile and user-angering aspect of our complex IPA setup in 
AWS is when user AD password checks mysteriously fail and deny login. 
All of the troubleshooting stuff works fine - user is recognized as 
valid, ipa hbactest all work fine but the user gets permission denied 
when logging in.


Right now my only fix is converting users over to SSH keybased logins 
with the IPA server holding the public key -- that works great. 
Restarting sssd a few times and waiting 10 minutes also usually resolves 
the issue.


We *suspect* the password check failure is because this large 
organization has 100+ domain controllers scattered in networks and 
datacenters all over the place and we think that maybe SSSD is DNS 
resolving via _SVR_ records a domain controller that is unreachable or 
unknown to our cloud nACLs and security controls -- or maybe a domain 
controller that just flat out refuses to talk to us.


I've seen on this list mentions of really cool AD integration 
improvements like being able to have more than one AD domain vs the 
existing "Default domain" that requires our users to login with fully 
qualified @.COMPANY.ORG  as well as mentions that 
future versions of SSSD would allow us to pin our communication to 
known/named AD controllers?  I think the basic advice from the IPA 
community was that this stuff was showing up in modern sssd releases and 
that we just had to wait a bit for the updated sssd code to show up in 
distro repos.


Did I understand things correctly? Are we at the point now with IPA and 
SSD upgrades where we could possibly pin our AD traffic to named 
controllers? And maybe also address the AD domain search issue as well?


Thanks!

Chris

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Got RBAC controls for individual AD users sorted; now to allow login based on AD group membership ?

[Chris Dagdigian via FreeIPA-users]

Hi folks,

Have an AWS footprint that thanks to FreeIPA can talk to a really 
complex remote AD forest with lots of transitive trusts and child 
domains. Would not be possible without FreeIPA in the mix.


So far we've only really been required to grant admin/sudo access and 
we've done that individually with role based user and hostgroups


I'm comfortable with bringing an AD user into the fold:

1. Make a non-posix group in FreeIPA to hold the AD usernames
2. Make a second group of type=POSIX that inherits members from the 
external non-posix group

3. Implement RBAC controls and rules via the posix group
4. magic!

Now I need to globally allow SSH and possibly other PAM service access 
based on pre-existing AD group membership


Looking for guidance or URLs on how to manage RBAC controls based on AD 
group rather than AD username.


Is it roughly the same (or exactly the same? )

- Make non-posix group that references the AD group in FreeIPA
- Make POSIX group in FreeIPA that inherits members of the non-posix group
- Implement RBAC rules?

Any tips or cheatsheets for allowing RBAC controls based on groups that 
exist in AD would be appreciated. thanks!


Chris

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Guidance on setting up locked down role for a local IPA user who can only do "ipa hbactest ... " command?

[Chris Dagdigian via FreeIPA-users]

Hi folks,

We have an absurdly complex multi-domain/multi-child AD forrest tied 
together on AWS via FreeIPA.


I'm spending a lot of time debugging login issues and the "ipa hbactest" 
command is fantastic at "proving" out if something should or should not 
work.


I currently "kinit admin" before running these commands but would like 
to be able to pass this 'power' on to other people, including project 
managers and other folks that I would not trust with direct IPA 
privileges that would let them accidentally do dangerous things :)


Has anyone set up an IPA user with read-only access or otherwise set up 
a locked down role so that a user can only run "ipa hbactest ..." type 
commands? Looking for sensible tips and guidance on spreading some IPA 
powers around to people that I would not normally want having higher 
level privileges.


Thanks!

Chris

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: { possibly offtopic } -- can sssd.conf alone be configured to copy the custom AD ID Ranges used by IPA server?

[Chris Dagdigian via FreeIPA-users]

Jakub Hrozek via FreeIPA-users wrote:

If not, have you considered pointing the clients towards the compat tree
and using a plain LDAP setup, if your vendor supports that?



Appreciate the replies to even a non-IPA usage question. This list has a 
tremendous signal:noise ratio.


The info above sounds promising but I don't quite understand it. Is 
there a chapter in the IDM Admin Guide you can point me to to read up on 
or some other reference I can check out? Thanks!


Chris


___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] { possibly offtopic } -- can sssd.conf alone be configured to copy the custom AD ID Ranges used by IPA server?

[Chris Dagdigian via FreeIPA-users]

Hi folks,


I have a set of servers that CANNOT become enrolled IDM clients due to a 
vendor refusing to support this type of config.


This server fleet is directly bound to an AD system via the standard 
non-IPA "realm join ..." type commands


Since I can't bring these servers "into the fold" so to speak at the 
very least I would love to offset at least one potential future problem 
by seeing if I can help them configure sssd.conf on their local machines 
to use the same AD SID-to-UID algorithm (complete with custom ID Range 
values that we have enabled on the IPA master) so that they at least get 
the same UID and GID values for their AD users as the same user would 
get if they logged into the much larger fleet of IDM-managed servers.


Hope I'm asking the question properly -- in a nutshell I'm wondering how 
to trick a standalone sssd.conf file so that it uses the same SID-to-UID 
algorithm that an IDM master would use. This would at least let me get 
consistent UID/GID values across my fleet of enrolled vs. non-enrolled 
IDM clients !  Tips or advice appreciated even if the response is "heck 
no; you can't do that .. "




Regards,
Chris

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] ipa 4.4.0-14 not honoring "ipa-client-install --force-join" command?

[Chris Dagdigian via FreeIPA-users]

Hi folks,

Fixing a topology and replication issue caused my IDM infrastructure to 
forget about roughly 30 enrolled client hosts.


Though this would be trivial to fix via an ansible playbook that runs 
the IPA client install command again with the "--force-join" argument.


Manpage and docs suggest this should work. Any tips or help appreciated!

Software:

ipa-common-4.4.0-14.el7.centos.7.noarch
ipa-client-common-4.4.0-14.el7.centos.7.noarch
ipa-client-4.4.0-14.el7.centos.7.x86_64


Error when I try to re-enroll the client:

[root@deawilldpp06 centos]#
[root@deawilldpp06 centos]# ipa-client-install --force-join --mkhomedir 
--unattended --password= --principal  --server 
deawilidmp001..org --domain W.org


IPA client is already configured on this system.
If you want to reinstall the IPA client, uninstall it first using 
'ipa-client-install --uninstall'.

[root@deawilldpp06 centos]#
[root@deawilldpp06 centos]#



___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Need a clue re: broken topology and broken replication in a simple 2-server setup

[Chris Dagdigian via FreeIPA-users]

Situation: Two servers housed in 2 different AWS regions are completely 
disconnected and totally out of sync. I can't fix replication at all so 
I'm looking for clues or tips ..


Backstory:
 - Complex Active Directory needs including transitive trusts across 
multiple child domains of the AD Forrest
 - This means that we've been constantly upgrading IPA and subsystems 
like sssd* given the speed at which AD integration is being improved/fixed
 - We've been doing "yum update" and "ipa-server-upgrade" commands all 
the way from ipa-3.x to current v4.4.0
 - Due to incremental upgrades over time we've been at "domain level 0" 
until very recently


Issues
 - Two servers work but they are islands to their own - no replication 
seems to be occurring

 - IPA connection-check scripts seem to all pass
 - IPA replication-manage "list" commands seem to work fine
 - forcing replication or forcing a complete reinit has zero effect
 - IPA topologysegment-find domain commands seem to show the proper 
segments
 - BUT -- the topology-verify command clearly shows broken topology and 
disconnected state


It was only recently that I discovered the broken topology status - had 
spent too much time in the weeds looking at debug output trying to 
figure out why replication was not working .


I'm wondering what the best next-step is to regaining a unified IPA 
view. From reading the admin guide I'm thinking that I need to bring up 
new IPA servers so that I have more "nodes" to play with when 
potentially connecting and fixing the topology segments -- seems easier 
to fix segments when you have more nodes to play with.


I'm not sure what to fix first -- is the broken topology segment the 
cause for broken replication or is something wrong in the replication 
internals that results in a disconnected topology?


Guidance appreciated. I'm appending some redacted command output below.

Regards,
Chris

###


# ipa-replica-manage list
us-idmp001.COMPANYidm.org: master
eu-idmp001.COMPANYidm.org: master


# ipa topologysegment-find domain
-
1 segment matched
-
  Segment name: us-idmp001.COMPANYidm.org-to-eu-idmp001.COMPANYidm.org
  Left node: us-idmp001.COMPANYidm.org
  Right node: eu-idmp001.COMPANYidm.org
  Connectivity: left-right

Number of entries returned 1



#ipa topologysegment-find domain
-
1 segment matched
-
  Segment name: eu-idmp001.COMPANYidm.org-to-us-idmp001.COMPANYidm.org
  Left node: eu-idmp001.COMPANYidm.org
  Right node: us-idmp001.COMPANYidm.org
  Connectivity: left-right

Number of entries returned 1

[root@eu-idmp001 centos]#


# ipa topologysuffix-verify domain

Replication topology of suffix "domain" contains errors.


Topology is disconnected

  Server eu-idmp001.COMPANYidm.org can't contact servers: 
us-idmp001.COMPANYidm.org

[root@us-idmp001 centos]#


# ipa topologysuffix-verify domain

Replication topology of suffix "domain" contains errors.


Topology is disconnected

  Server us-idmp001.COMPANYidm.org can't contact servers: 
eu-idmp001.COMPANYidm.org

[root@eu-idmp001 centos]#
[root@eu-idmp001 centos]#


#  /usr/sbin/ipa-replica-conncheck --replica eu-idmp001.COMPANYidm.org
Check connection from master to remote replica 'eu-idmp001.COMPANYidm.org':
   Directory Service: Unsecure port (389): OK
   Directory Service: Secure port (636): OK
   Kerberos KDC: TCP (88): OK
   Kerberos KDC: UDP (88): WARNING
   Kerberos Kpasswd: TCP (464): OK
   Kerberos Kpasswd: UDP (464): WARNING
   HTTP Server: Unsecure port (80): OK
   HTTP Server: Secure port (443): OK
The following UDP ports could not be verified as open: 88, 464
This can happen if they are already bound to an application
and ipa-replica-conncheck cannot attach own UDP responder.

Connection from master to replica is OK.


ipa-replica-conncheck --master us-idmp001.COMPANYidm.org
Check connection from replica to remote master 'us-idmp001.COMPANYidm.org':
   Directory Service: Unsecure port (389): OK
   Directory Service: Secure port (636): OK
   Kerberos KDC: TCP (88): OK
   Kerberos Kpasswd: TCP (464): OK
   HTTP Server: Unsecure port (80): OK
   HTTP Server: Secure port (443): OK

The following list of ports use UDP protocol and would need to be
checked manually:
   Kerberos KDC: UDP (88): SKIPPED
   Kerberos Kpasswd: UDP (464): SKIPPED

Connection from replica to master is OK.
Start listening on required ports for remote master check
Listeners are started. Use CTRL+C to terminate the listening part after 
the test.


Please run the following command on remote