[Freeipa-users] Re: Upgrading from EL7.9 to EL8

2022-06-15 Thread Angus Clarke via FreeIPA-users
Thanks Rob
Angus

From: Rob Crittenden 
Sent: 15 June 2022 14:15
To: FreeIPA users list 
Cc: Angus Clarke 
Subject: Re: [Freeipa-users] Upgrading from EL7.9 to EL8

Angus Clarke via FreeIPA-users wrote:
> Hello
>
> I am planning the upgrade of one of our FreeIPA deployments from EL7.9
>
> Previously, we have been quite good at upgrading through OS point
> upgrades (7.3, 7.4, 7.5 etc) as this was the advice through that series
> of FreeIPA software.
>
> Upgrading our FreeIPAs from EL7.9 today will see me introduce an EL8
> FreeIPA which will receive the freeipa software from the Appstream
> repository. At time of writing, that process will see me introducing a
> replica running ipa-server 4.9.8 to my existing FreeIPA nodes running
> ipa-server 4.6.8
>
> Should I be concerned about more minor updates and find some way of
> upgrading through different ipa-server (and dependencies) releases from
> Appstream or do you think I should just run the procedure as described
> above?

Major version upgrades via adding a new machine is the recommended and
documented route. It includes retiring existing, older servers, so have
a plan for that.

Running mixed versions is likely fine in most cases but we don't
recommend doing it for very long and encourage a relatively fast
migration (weeks not months). Be sure to watch the replication topology
and maintain the service mix (e.g. at least 2 CAs), and at have one CA
designated as the renewal master, CRL master, etc. It's all in the docs.

rob

___
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] Upgrading from EL7.9 to EL8

2022-06-15 Thread Angus Clarke via FreeIPA-users
Hello

I am planning the upgrade of one of our FreeIPA deployments from EL7.9

Previously, we have been quite good at upgrading through OS point upgrades 
(7.3, 7.4, 7.5 etc) as this was the advice through that series of FreeIPA 
software.

Upgrading our FreeIPAs from EL7.9 today will see me introduce an EL8 FreeIPA 
which will receive the freeipa software from the Appstream repository. At time 
of writing, that process will see me introducing a replica running ipa-server 
4.9.8 to my existing FreeIPA nodes running ipa-server 4.6.8

Should I be concerned about more minor updates and find some way of upgrading 
through different ipa-server (and dependencies) releases from Appstream or do 
you think I should just run the procedure as described above?

Thanks
Angus
___
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: hostgroup automember rules

2022-05-27 Thread Angus Clarke via FreeIPA-users
Alexander's other suggestion was quite straight forward too, sharing the 
process for the archive.

To allow customers to enroll hosts themselves and have automembership operate 
on the "locality" attribute:


  1.  Create A/ records in the local DNS for the host you intend to add 
(blah.int.ajc)
  2.
  3.  Create automembership rule based on "l" attribute (locality)

  1.  An IPA user is needed with these privileges:
  2.  Host Administrators
  3.  Host Enrollment

  1.  On an already enrolled host:
  2.  [angusc@enrolled ~] $ kinit
  3.  [angusc@enrolled ~] $ ipa host-add blah.int.ajc --locality="worcester"
  4.
  5.  At this point the automembership rule has been honoured

  1.  Enroll the client with ipa-client-install
  2.  [angusc@blah ~] $ ipa-client-install --mkhomedir --no-ntp --no-nisdomain 
--domain=int.ajc --server=infra1.int.ajc


Thanks for the pointers

Regards
Angus



From: Angus Clarke 
Sent: 26 May 2022 09:11
To: Rob Crittenden ; FreeIPA users list 
; Alexander Bokovoy 
Subject: Re: [Freeipa-users] Re: hostgroup automember rules

Super that worked a treat thanks, however I see that the host can run the 
automember rebuild on any other host which might not be desirable.

I'll have a loot at Alexander's previous suggestion too with regards to 
creating a host entry with particular attributes set prior to running the 
ipa-client-install command.

Thanks again
Angus

From: Rob Crittenden 
Sent: 25 May 2022 20:24
To: FreeIPA users list ; Alexander 
Bokovoy 
Cc: Angus Clarke 
Subject: Re: [Freeipa-users] Re: hostgroup automember rules

This is controlled by the permission 'Add Automember Rebuild Membership
Task'. There is a related privilege, 'Automember Task Administrator'.

To limit what you're allowing to the minimum I'd create a new role like
'Hosts can rebuild automember' and add your host(s) to it.

rob

Angus Clarke via FreeIPA-users wrote:
> Hi Alexander
>
>> There are two ways of setting these fields:
>>
>>   - prior to enrollment, by pre-creating a host and setting the
>> attributes at that time.
>>
>>   - after the enrollment, right from the host using host keytab
>
> I started looking at the latter as it seems a simpler route, the host
> principal seems to lack the write to rebuild automembership for itself -
> is this something I can change?
>
> [root@blah ~]# kinit -k
> [root@blah ~]# ipa automember-rebuild --hosts=`hostname`
> ipa: ERROR: Insufficient access: Insufficient 'add' privilege to add the
> entry 'cn=automember rebuild membership,cn=tasks,cn=config'.
>
> Thanks a lot
> Angus
>
>
>
> 
> *From:* Alexander Bokovoy 
> *Sent:* 20 May 2022 13:39
> *To:* FreeIPA users list 
> *Cc:* Angus Clarke 
> *Subject:* Re: [Freeipa-users] hostgroup automember rules
>
> Hi Angus,
>
> On pe, 20 touko 2022, Angus Clarke via FreeIPA-users wrote:
>>Hello
>>
>>FreeIPA 4.6.8
>>
>>We are very happy with hostgroup automember rules based on servername
>>attribute however one of our internal customers uses a generic
>>servername template for all of their servers regardless of its
>>function.
>>
>>So I'm wondering what other attributes I might use for hostgroup
>>automember - perhaps some of the attributes can be configured by the
>>ipa-client-install (the host's "description" field perhaps) although I
>>don't see such mention in the man page ... Presumably they could use a
>>different enrollment user ("enrolledby") for each of their hostgroup
>>functions (not ideal.)
>>
>>There are various attribute fields in the WebUI but I don't find much
>>documentation for them. What is the "|" field - perhaps I can exploit
>>this somehow?
>
> Few years ago a customer of mine asked a similar question. Here is what
> I answered:
>
> --
> You can use nsHardwarePlatform attribute (part of nsHost objectclass).
> It is exposed as '--platform' in IPA CLI for 'ipa host-*' commands.
>
> Originally it was supposed to be filled by the IPA client join process
> to 'uname -m' value. ipa-join tools still sends it to the server but the
> value is ignored completely by the join process. As the result,
> nsHardwarePlatform attribute is never set on the host object.
>
> I don't see any code in IPA itself that would rely on the content of
> nsHardwarePlatform attribute. We have web UI tests upstream that modify
> the field to test that you can modify it but that's all.
>
> Alternatively, one can use userClass attribute (--class in IPA CLI for
> host-* commands). This one is 

[Freeipa-users] Re: hostgroup automember rules

2022-05-26 Thread Angus Clarke via FreeIPA-users
Super that worked a treat thanks, however I see that the host can run the 
automember rebuild on any other host which might not be desirable.

I'll have a loot at Alexander's previous suggestion too with regards to 
creating a host entry with particular attributes set prior to running the 
ipa-client-install command.

Thanks again
Angus

From: Rob Crittenden 
Sent: 25 May 2022 20:24
To: FreeIPA users list ; Alexander 
Bokovoy 
Cc: Angus Clarke 
Subject: Re: [Freeipa-users] Re: hostgroup automember rules

This is controlled by the permission 'Add Automember Rebuild Membership
Task'. There is a related privilege, 'Automember Task Administrator'.

To limit what you're allowing to the minimum I'd create a new role like
'Hosts can rebuild automember' and add your host(s) to it.

rob

Angus Clarke via FreeIPA-users wrote:
> Hi Alexander
>
>> There are two ways of setting these fields:
>>
>>   - prior to enrollment, by pre-creating a host and setting the
>> attributes at that time.
>>
>>   - after the enrollment, right from the host using host keytab
>
> I started looking at the latter as it seems a simpler route, the host
> principal seems to lack the write to rebuild automembership for itself -
> is this something I can change?
>
> [root@blah ~]# kinit -k
> [root@blah ~]# ipa automember-rebuild --hosts=`hostname`
> ipa: ERROR: Insufficient access: Insufficient 'add' privilege to add the
> entry 'cn=automember rebuild membership,cn=tasks,cn=config'.
>
> Thanks a lot
> Angus
>
>
>
> 
> *From:* Alexander Bokovoy 
> *Sent:* 20 May 2022 13:39
> *To:* FreeIPA users list 
> *Cc:* Angus Clarke 
> *Subject:* Re: [Freeipa-users] hostgroup automember rules
>
> Hi Angus,
>
> On pe, 20 touko 2022, Angus Clarke via FreeIPA-users wrote:
>>Hello
>>
>>FreeIPA 4.6.8
>>
>>We are very happy with hostgroup automember rules based on servername
>>attribute however one of our internal customers uses a generic
>>servername template for all of their servers regardless of its
>>function.
>>
>>So I'm wondering what other attributes I might use for hostgroup
>>automember - perhaps some of the attributes can be configured by the
>>ipa-client-install (the host's "description" field perhaps) although I
>>don't see such mention in the man page ... Presumably they could use a
>>different enrollment user ("enrolledby") for each of their hostgroup
>>functions (not ideal.)
>>
>>There are various attribute fields in the WebUI but I don't find much
>>documentation for them. What is the "|" field - perhaps I can exploit
>>this somehow?
>
> Few years ago a customer of mine asked a similar question. Here is what
> I answered:
>
> --
> You can use nsHardwarePlatform attribute (part of nsHost objectclass).
> It is exposed as '--platform' in IPA CLI for 'ipa host-*' commands.
>
> Originally it was supposed to be filled by the IPA client join process
> to 'uname -m' value. ipa-join tools still sends it to the server but the
> value is ignored completely by the join process. As the result,
> nsHardwarePlatform attribute is never set on the host object.
>
> I don't see any code in IPA itself that would rely on the content of
> nsHardwarePlatform attribute. We have web UI tests upstream that modify
> the field to test that you can modify it but that's all.
>
> Alternatively, one can use userClass attribute (--class in IPA CLI for
> host-* commands). This one is also not utilized and is left specifically
> for the customers to define its semantics.
>
> Another alternative is nsHostLocation attribute (--location in IPA CLI
> for host-*
> commands). Again, the semantics is totally left for customers to define.
>
> --
>
> There are two ways of setting these fields:
>
>   - prior to enrollment, by pre-creating a host and setting the
> attributes at that time.
>
>   - after the enrollment, right from the host using host keytab
>
> The former can be done by a designated user/service account and can be
> tuned with custom permissions to allow such modification. The latter
> relies on the fact that the host principal has some write rights
> already:
>
> # kinit -k
>
> # ipa host-show `hostname` --rights --all
>dn: fqdn=dc.ipa.test,cn=computers,cn=accounts,dc=ipa,dc=test
>Host name: dc.ipa.test
>Principal name: host/dc.ipa.t...@ipa.test
>Principal alias: host/dc.ipa.t...@ipa.test
>SSH public key: [skip]
>

[Freeipa-users] Re: hostgroup automember rules

2022-05-25 Thread Angus Clarke via FreeIPA-users
Hi Alexander

> There are two ways of setting these fields:
>
>   - prior to enrollment, by pre-creating a host and setting the
> attributes at that time.
>
>   - after the enrollment, right from the host using host keytab

I started looking at the latter as it seems a simpler route, the host principal 
seems to lack the write to rebuild automembership for itself - is this 
something I can change?

[root@blah ~]# kinit -k
[root@blah ~]# ipa automember-rebuild --hosts=`hostname`
ipa: ERROR: Insufficient access: Insufficient 'add' privilege to add the entry 
'cn=automember rebuild membership,cn=tasks,cn=config'.

Thanks a lot
Angus




From: Alexander Bokovoy 
Sent: 20 May 2022 13:39
To: FreeIPA users list 
Cc: Angus Clarke 
Subject: Re: [Freeipa-users] hostgroup automember rules

Hi Angus,

On pe, 20 touko 2022, Angus Clarke via FreeIPA-users wrote:
>Hello
>
>FreeIPA 4.6.8
>
>We are very happy with hostgroup automember rules based on servername
>attribute however one of our internal customers uses a generic
>servername template for all of their servers regardless of its
>function.
>
>So I'm wondering what other attributes I might use for hostgroup
>automember - perhaps some of the attributes can be configured by the
>ipa-client-install (the host's "description" field perhaps) although I
>don't see such mention in the man page ... Presumably they could use a
>different enrollment user ("enrolledby") for each of their hostgroup
>functions (not ideal.)
>
>There are various attribute fields in the WebUI but I don't find much
>documentation for them. What is the "|" field - perhaps I can exploit
>this somehow?

Few years ago a customer of mine asked a similar question. Here is what
I answered:

--
You can use nsHardwarePlatform attribute (part of nsHost objectclass).
It is exposed as '--platform' in IPA CLI for 'ipa host-*' commands.

Originally it was supposed to be filled by the IPA client join process
to 'uname -m' value. ipa-join tools still sends it to the server but the
value is ignored completely by the join process. As the result,
nsHardwarePlatform attribute is never set on the host object.

I don't see any code in IPA itself that would rely on the content of
nsHardwarePlatform attribute. We have web UI tests upstream that modify
the field to test that you can modify it but that's all.

Alternatively, one can use userClass attribute (--class in IPA CLI for
host-* commands). This one is also not utilized and is left specifically
for the customers to define its semantics.

Another alternative is nsHostLocation attribute (--location in IPA CLI for 
host-*
commands). Again, the semantics is totally left for customers to define.

--

There are two ways of setting these fields:

  - prior to enrollment, by pre-creating a host and setting the
attributes at that time.

  - after the enrollment, right from the host using host keytab

The former can be done by a designated user/service account and can be
tuned with custom permissions to allow such modification. The latter
relies on the fact that the host principal has some write rights
already:

# kinit -k

# ipa host-show `hostname` --rights --all
   dn: fqdn=dc.ipa.test,cn=computers,cn=accounts,dc=ipa,dc=test
   Host name: dc.ipa.test
   Principal name: host/dc.ipa.t...@ipa.test
   Principal alias: host/dc.ipa.t...@ipa.test
   SSH public key: [skip]
   SSH public key fingerprint: [skip]
   Requires pre-authentication: True
   Trusted for delegation: False
   Trusted to authenticate as user: False
   Password: False
   Member of host-groups: ipaservers
   Keytab: True
   Managed by: dc.ipa.test
   Managing: dc.ipa.test
   attributelevelrights: {'aci': '', 'cn': 'rscwo', 'description': 'rscwo', 
'enrolledby': 'rsc', 'fqdn': 'rsc', 'ipaassignedidview': 'rsc', 
'ipaclientversion': 'rsc', 'ipakrbauthzdata': 'rsc', 'ipasshpubkey': 'rscwo', 
'ipauniqueid': 'rsc', 'krballowedtodelegateto': '', 
'krbauthindmaxrenewableage': '', 'krbauthindmaxticketlife': '', 
'krbcanonicalname': 'rsc', 'krbextradata': '', 'krblastadminunlock': '', 
'krblastfailedauth': '', 'krblastpwdchange': 'rscwo', 'krblastsuccessfulauth': 
'', 'krbloginfailedcount': '', 'krbmaxrenewableage': '', 'krbmaxticketlife': 
'', 'krbobjectreferences': '', 'krbpasswordexpiration': 'rsc', 
'krbprincipalaliases': 'rsc', 'krbprincipalauthind': 'rsc', 
'krbprincipalexpiration': 'rsc', 'krbprincipalkey': 'swo', 'krbprincipalname': 
'rsc', 'krbprincipaltype': '', 'krbpwdhistory': '', 'krbpwdpolicyreference': 
'', 'krbticketflags': '', 'krbticketpolicyreference': '', 'krbupenabled': '', 
'l': 'rscwo', 'managedby': 'rsc', 'memberof': 'rsc', 'nsaccountlock': '', 
'nshardwareplatform': 'rscwo', 'nshostlocation': 'rscwo', 'nsosversion'

[Freeipa-users] Re: hostgroup automember rules

2022-05-23 Thread Angus Clarke via FreeIPA-users
Thanks a lot Alexander.

From: Alexander Bokovoy 
Sent: 20 May 2022 13:39
To: FreeIPA users list 
Cc: Angus Clarke 
Subject: Re: [Freeipa-users] hostgroup automember rules

Hi Angus,

On pe, 20 touko 2022, Angus Clarke via FreeIPA-users wrote:
>Hello
>
>FreeIPA 4.6.8
>
>We are very happy with hostgroup automember rules based on servername
>attribute however one of our internal customers uses a generic
>servername template for all of their servers regardless of its
>function.
>
>So I'm wondering what other attributes I might use for hostgroup
>automember - perhaps some of the attributes can be configured by the
>ipa-client-install (the host's "description" field perhaps) although I
>don't see such mention in the man page ... Presumably they could use a
>different enrollment user ("enrolledby") for each of their hostgroup
>functions (not ideal.)
>
>There are various attribute fields in the WebUI but I don't find much
>documentation for them. What is the "|" field - perhaps I can exploit
>this somehow?

Few years ago a customer of mine asked a similar question. Here is what
I answered:

--
You can use nsHardwarePlatform attribute (part of nsHost objectclass).
It is exposed as '--platform' in IPA CLI for 'ipa host-*' commands.

Originally it was supposed to be filled by the IPA client join process
to 'uname -m' value. ipa-join tools still sends it to the server but the
value is ignored completely by the join process. As the result,
nsHardwarePlatform attribute is never set on the host object.

I don't see any code in IPA itself that would rely on the content of
nsHardwarePlatform attribute. We have web UI tests upstream that modify
the field to test that you can modify it but that's all.

Alternatively, one can use userClass attribute (--class in IPA CLI for
host-* commands). This one is also not utilized and is left specifically
for the customers to define its semantics.

Another alternative is nsHostLocation attribute (--location in IPA CLI for 
host-*
commands). Again, the semantics is totally left for customers to define.

--

There are two ways of setting these fields:

  - prior to enrollment, by pre-creating a host and setting the
attributes at that time.

  - after the enrollment, right from the host using host keytab

The former can be done by a designated user/service account and can be
tuned with custom permissions to allow such modification. The latter
relies on the fact that the host principal has some write rights
already:

# kinit -k

# ipa host-show `hostname` --rights --all
   dn: fqdn=dc.ipa.test,cn=computers,cn=accounts,dc=ipa,dc=test
   Host name: dc.ipa.test
   Principal name: host/dc.ipa.t...@ipa.test
   Principal alias: host/dc.ipa.t...@ipa.test
   SSH public key: [skip]
   SSH public key fingerprint: [skip]
   Requires pre-authentication: True
   Trusted for delegation: False
   Trusted to authenticate as user: False
   Password: False
   Member of host-groups: ipaservers
   Keytab: True
   Managed by: dc.ipa.test
   Managing: dc.ipa.test
   attributelevelrights: {'aci': '', 'cn': 'rscwo', 'description': 'rscwo', 
'enrolledby': 'rsc', 'fqdn': 'rsc', 'ipaassignedidview': 'rsc', 
'ipaclientversion': 'rsc', 'ipakrbauthzdata': 'rsc', 'ipasshpubkey': 'rscwo', 
'ipauniqueid': 'rsc', 'krballowedtodelegateto': '', 
'krbauthindmaxrenewableage': '', 'krbauthindmaxticketlife': '', 
'krbcanonicalname': 'rsc', 'krbextradata': '', 'krblastadminunlock': '', 
'krblastfailedauth': '', 'krblastpwdchange': 'rscwo', 'krblastsuccessfulauth': 
'', 'krbloginfailedcount': '', 'krbmaxrenewableage': '', 'krbmaxticketlife': 
'', 'krbobjectreferences': '', 'krbpasswordexpiration': 'rsc', 
'krbprincipalaliases': 'rsc', 'krbprincipalauthind': 'rsc', 
'krbprincipalexpiration': 'rsc', 'krbprincipalkey': 'swo', 'krbprincipalname': 
'rsc', 'krbprincipaltype': '', 'krbpwdhistory': '', 'krbpwdpolicyreference': 
'', 'krbticketflags': '', 'krbticketpolicyreference': '', 'krbupenabled': '', 
'l': 'rscwo', 'managedby': 'rsc', 'memberof': 'rsc', 'nsaccountlock': '', 
'nshardwareplatform': 'rscwo', 'nshostlocation': 'rscwo', 'nsosversion': 
'rscwo', 'objectclass': 'rsc', 'serverhostname': 'rsc', 'usercertificate': 
'rscwo', 'userclass': 'rsc', 'userpassword': 'swo'}
   cn: dc.ipa.test
   ipauniqueid: b179f1ea-c4b8-11ec-9e86-52540083ff9d
   krblastpwdchange: 20220425165647Z
   objectclass: top, ipaobject, nshost, ipahost, ipaservice, pkiuser, 
krbprincipalaux, krbprincipal, krbticketpolicyaux, ipasshhost, 
ipaSshGroupOfPubKeys
   serverhostname: dc

So, the host/dc.ipa.t...@ipa.test principal can write to:

   - nsHardwarePlatform
   - nsHostLocation
   - nsOSVersion
   - l (locality)
   - description

but it cannot write to 'userClass' attribute.

A handy mapping between 

[Freeipa-users] Re: hostgroup automember rules

2022-05-23 Thread Angus Clarke via FreeIPA-users
Thanks a lot Flo.

From: Florence Blanc-Renaud 
Sent: 20 May 2022 13:12
To: FreeIPA users list 
Cc: Angus Clarke 
Subject: Re: [Freeipa-users] hostgroup automember rules

Hi,

On Fri, May 20, 2022 at 11:48 AM Angus Clarke via FreeIPA-users 
mailto:freeipa-users@lists.fedorahosted.org>>
 wrote:
Hello

FreeIPA 4.6.8

We are very happy with hostgroup automember rules based on servername attribute 
however one of our internal customers uses a generic servername template for 
all of their servers regardless of its function.

So I'm wondering what other attributes I might use for hostgroup automember - 
perhaps some of the attributes can be configured by the ipa-client-install (the 
host's "description" field perhaps) although I don't see such mention in the 
man page ... Presumably they could use a different enrollment user 
("enrolledby") for each of their hostgroup functions (not ideal.)

There are various attribute fields in the WebUI but I don't find much 
documentation for them. What is the "|" field - perhaps I can exploit this 
somehow?

The automember group functionality is described in this chapter: Automating 
group membership using IdM 
CLI<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Fdocumentation%2Fen-us%2Fred_hat_enterprise_linux%2F8%2Fhtml%2Fmanaging_idm_users_groups_hosts_and_access_control_rules%2Fautomating-group-membership-using-idm-cli_managing-users-groups-hosts%23doc-wrapper=05%7C01%7C%7Cb6d74a98ce3c4a191ed808da3a51b223%7C84df9e7fe9f640afb435%7C1%7C0%7C637886419797093673%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=zntaNdlnuy4BoZggjoR6DUyxUIVnvgb8Sn0kUA2AStE%3D=0>.
You can define a new hostgroup with an automember rule based on any attribute 
defined in the schema. Just be aware that the conditions are defined using 
Perl-compatible regular expressions (PCRE) format.
The 'l' attribute is an alias for 'locality' or 'localityname' and can contain 
any string. For any attribute you can find its description in the LDAP schema.

The host entries have multiple object classes. For instance if you run
ipa host-show server.ipa.test --all --raw
you can see all its objectclasses:
  objectClass: top
  objectClass: ipaobject
  objectClass: nshost
  objectClass: ipahost
  objectClass: ipaservice
  objectClass: pkiuser
  objectClass: krbprincipalaux
  objectClass: krbprincipal
  objectClass: krbticketpolicyaux
  objectClass: ipasshhost
  objectClass: ipaSshGroupOfPubKeys

Each object class defines the mandatory/optional attributes that the entry can 
contain. For instance in order to find the attributes for the nshost 
objectclass:
ldapsearch -LLL -o ldif-wrap=no -b cn=schema -s base objectclasses | grep -i 
nshost
objectclasses: ( nsHost-oid NAME 'nsHost' DESC 'Netscape defined objectclass' 
SUP top STRUCTURAL MUST cn MAY ( serverHostName $ description $ l $ 
nsHostLocation $ nsHardwarePlatform $ nsOsVersion ) X-ORIGIN 'Netscape' )

The nshost objectclass allows the presence of serverhostname, description, l 
etc...
Now to find what description can contain:
ldapsearch -LLL -o ldif-wrap=no -b cn=schema -s base attributetypes | grep -i 
description
attributetypes: ( 2.5.4.13 NAME 'description'  EQUALITY caseIgnoreMatch SUBSTR 
caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'RFC 
4519' )

The SYNTAX part defines the type of data (the RFC 
4517<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc4517%23section-3.3.6=05%7C01%7C%7Cb6d74a98ce3c4a191ed808da3a51b223%7C84df9e7fe9f640afb435%7C1%7C0%7C637886419797093673%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=vGaicO1JVQIr5rueD8%2FcndBgf8lvUyblmnz8Nba2qCU%3D=0>
 defines 1.3.6.1.4.1.1466.115.121.1.15 as a DirectoryString).
With this knowledge, you can pick an attribute where you want to store 
information that can be used to group the hosts together, and create the 
matching rule using this attribute.

If you are curious about LDAP schema in general, you can read the RFC 
4519<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfc%2Frfc4519.txt=05%7C01%7C%7Cb6d74a98ce3c4a191ed808da3a51b223%7C84df9e7fe9f640afb435%7C1%7C0%7C637886419797093673%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=6JOgDQgg1b6n209BSheguhWB7r5WXYgAUaAxNMlfRTk%3D=0>.
HTH,
flo



Any advice gladly received.

Thanks a lot
Angus
___
FreeIPA-users mailing list -- 
freeipa-users@lists.fedorahosted.org<mailto:freeipa-users@lists.fedorahosted.org>
To unsubscribe send an email to 
freeipa-users-le...@lists.fedorahosted.org<mailto:freeipa-users-le...@lists.fedorahosted.org>
Fedora Code of Cond

[Freeipa-users] hostgroup automember rules

2022-05-20 Thread Angus Clarke via FreeIPA-users
Hello

FreeIPA 4.6.8

We are very happy with hostgroup automember rules based on servername attribute 
however one of our internal customers uses a generic servername template for 
all of their servers regardless of its function.

So I'm wondering what other attributes I might use for hostgroup automember - 
perhaps some of the attributes can be configured by the ipa-client-install (the 
host's "description" field perhaps) although I don't see such mention in the 
man page ... Presumably they could use a different enrollment user 
("enrolledby") for each of their hostgroup functions (not ideal.)

There are various attribute fields in the WebUI but I don't find much 
documentation for them. What is the "|" field - perhaps I can exploit this 
somehow?

Any advice gladly received.

Thanks a lot
Angus
___
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: EL8 ipa upgrade / Single Level Domain

2022-05-04 Thread Angus Clarke via FreeIPA-users
Thank you for the direction

Regards
Angus



From: Alexander Bokovoy 
Sent: 04 May 2022 09:58
To: FreeIPA users list 
Cc: Florence Blanc-Renaud ; Angus Clarke 
Subject: Re: [Freeipa-users] Re: EL8 ipa upgrade / Single Level Domain

On ke, 04 touko 2022, Angus Clarke via FreeIPA-users wrote:
>Thanks Flo,
>
>Are there any options available to me to continue using my existing
>FreeIPA deployment with EL8 clients and indeed to upgrade the FreeIPA
>infra to 4.7+ which I believe is only available to EL8 - manipulate the
>current single level domain/realm perhaps?
>
>Or am I faced with replacing the whole deployment with a fresh FreeIPA
>install using a permitted domain/realm?

The latter is the case, unfortunately. Manipulating domain/realm would
not be easy because Kerberos realm details are everywhere. Your LDAP
database suffix embeds it as well, as dc=single-label, that one is hard
to change. Kerberos realm is baked into all principals.

>
>I suppose the latter involves a large amount of work in
>exporting/importing users/groups/hbac/automember/sudo/
>configurations and then having to re-register all of our existing
>clients (we have many) to the new infra.

It might be possible to migrate, kind of. I haven't tried that myself.

If you'd export LDAP data and modify LDAP suffix (dc=single-label ->
dc=new,dc=domain), modify all principals to use new realm, and all other
objects to use new domain, then do a data-only backup from the new
install, replace LDIF file in it with the modified version, re-import
that backup, then manually re-generate keytabs using LDAPI URI in
ipa-getkeytab (as root on IPA master this will allow you to be a
cn=Directory Manager), then it might work. I am not detailing the
process because a) I have not tried that, b) it is easy to break. But I
think it could be possible at least theoretically:

  - your Kerberos master key would stay the same as part of the import so
you would be able to decrypt old Kerberos keys for old principals

  - your user Kerberos principals use random salt, so they should not
depend on the realm value

  - keytab files have to be rebuilt because they do have the Kerberos
principal name recorded in them, so they'd be issued into 'old' realm

All the users/groups/HBAC/sudo rules metadata is the same, it only
differs by the DN which is now ending in a different suffix which could
be fixed with LDIF replacement.

Restoring backup from the data would force wiping the 'new' deployment
content. You need this because you certainly want to keep old ID ranges,
DNA ranges, SIDs and other per-deployment settings.

Again, this is a theory. I haven't tried that myself.

>
>Thanks
>Angus
>
>From: Florence Blanc-Renaud via FreeIPA-users 
>
>Sent: 03 May 2022 13:37
>To: FreeIPA users list 
>Cc: Angus Clarke ; Florence Blanc-Renaud 
>Subject: [Freeipa-users] Re: EL8 ipa upgrade / Single Level Domain
>
>Hi,
>
>
>On Tue, May 3, 2022 at 11:59 AM Angus Clarke via FreeIPA-users 
>mailto:freeipa-users@lists.fedorahosted.org>>
> wrote:
>Hello
>
>We installed our IPA servers back in EL7.2 days and deployed with a single 
>level domain and matching (uppercased) realm. Through various upgrades we are 
>now at EL7.9 and are aware that the ipa-client-install command has become 
>finickity about single level domains however thus far we have been able to 
>continue joining EL7 clients.
>
>I've setup my test environment similarly and have been unsuccessful in trying 
>to upgrade (join new and replace old) these EL7 Freeipa servers to EL8, the 
>ipa-client-install on EL8 skips the single level domain so I'm a bit stuck.
>
>Is there a way around this in EL8?
>
>As you saw, the installation of single-label domain is forbidden since 
>ipa-4.6.5-1.el7, but the upgrade from older versions is still allowed.
>Regarding the client, the installation in a single-label IPA domain is 
>possible only with IPA 4.6.x clients (see 
>https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.redhat.com%2Fshow_bug.cgi%3Fid%3D1745108data=05%7C01%7C%7C9f9643c899514ea1e4e808da2da3eae9%7C84df9e7fe9f640afb435%7C1%7C0%7C637872479282454342%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=JBG6U9ZR7vwsXmUtdSxPl%2B7KjZHcWJPA%2FPyoCJdP4dk%3Dreserved=0<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.redhat.com%2Fshow_bug.cgi%3Fid%3D1745108data=05%7C01%7C%7C9f9643c899514ea1e4e808da2da3eae9%7C84df9e7fe9f640afb435%7C1%7C0%7C637872479282454342%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=JBG6U9ZR7vwsXmUtdSxPl%2B7KjZHcWJPA%2FPyoCJdP4dk%3Dreserved=0>).
> It was a deliberate choice to allow

[Freeipa-users] Re: EL8 ipa upgrade / Single Level Domain

2022-05-04 Thread Angus Clarke via FreeIPA-users
Thanks Flo,

Are there any options available to me to continue using my existing FreeIPA 
deployment with EL8 clients and indeed to upgrade the FreeIPA infra to 4.7+ 
which I believe is only available to EL8 - manipulate the current single level 
domain/realm perhaps?

Or am I faced with replacing the whole deployment with a fresh FreeIPA install 
using a permitted domain/realm?

I suppose the latter involves a large amount of work in exporting/importing 
users/groups/hbac/automember/sudo/ configurations and then having to 
re-register all of our existing clients (we have many) to the new infra.

Thanks
Angus

From: Florence Blanc-Renaud via FreeIPA-users 

Sent: 03 May 2022 13:37
To: FreeIPA users list 
Cc: Angus Clarke ; Florence Blanc-Renaud 
Subject: [Freeipa-users] Re: EL8 ipa upgrade / Single Level Domain

Hi,


On Tue, May 3, 2022 at 11:59 AM Angus Clarke via FreeIPA-users 
mailto:freeipa-users@lists.fedorahosted.org>>
 wrote:
Hello

We installed our IPA servers back in EL7.2 days and deployed with a single 
level domain and matching (uppercased) realm. Through various upgrades we are 
now at EL7.9 and are aware that the ipa-client-install command has become 
finickity about single level domains however thus far we have been able to 
continue joining EL7 clients.

I've setup my test environment similarly and have been unsuccessful in trying 
to upgrade (join new and replace old) these EL7 Freeipa servers to EL8, the 
ipa-client-install on EL8 skips the single level domain so I'm a bit stuck.

Is there a way around this in EL8?

As you saw, the installation of single-label domain is forbidden since 
ipa-4.6.5-1.el7, but the upgrade from older versions is still allowed.
Regarding the client, the installation in a single-label IPA domain is possible 
only with IPA 4.6.x clients (see 
https://bugzilla.redhat.com/show_bug.cgi?id=1745108<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.redhat.com%2Fshow_bug.cgi%3Fid%3D1745108=05%7C01%7C%7C1d2a85ff65f343d25ba508da2d179d8a%7C84df9e7fe9f640afb435%7C1%7C0%7C637871876703235499%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=lhH0GJxGEYvwRHIqQAkOhKMOIbAge7MebrNaAy%2Bd%2BqI%3D=0>).
 It was a deliberate choice to allow RHEL7 clients but stop supporting this 
type of deployment with RHEL8+. So no workaround with RHEL8...

Hope this clarifies,
flo

EL7 ipa server (ipatest1):
ipa-server-4.6.8-5.0.1.el7_9.10.x86_64

EL8 (ipatest2):
ipa-server-4.9.6-12.0.1.module+el8.5.0+20642+b228f286.x86_64


[root@ipatest2 ~]# ipa-replica-install --setup-ca --ip-address 192.168.180.141 
--password=Password1234 --principal=admin --setup-dns 
--forwarder=192.168.180.100
Configuring client side components
This program will set up IPA client.
Version 4.9.6

Unable to discover domain, not provided on command line
The ipa-client-install command failed. See /var/log/ipaclient-install.log for 
more information
Removing client side components
IPA client is not configured on this system.
The ipa-client-install command failed.

Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

Configuration of client side components failed!
The ipa-replica-install command failed. See /var/log/ipareplica-install.log for 
more information


[root@ipatest2 ~]# less /var/log/ipaclient-install.log
<-- snip
2022-05-03T08:53:10Z DEBUG [IPA Discovery]
2022-05-03T08:53:10Z DEBUG Starting IPA discovery with domain=None, 
servers=None, hostname=ipatest2.int.test
2022-05-03T08:53:10Z DEBUG Start searching for LDAP SRV record in "int.test" 
(domain of the hostname) and its sub-d
omains
2022-05-03T08:53:10Z DEBUG Search DNS for SRV record of _ldap._tcp.int.test
2022-05-03T08:53:10Z DEBUG DNS record not found: NXDOMAIN
2022-05-03T08:53:10Z DEBUG Search DNS for SRV record of _ldap._tcp.test
2022-05-03T08:53:10Z DEBUG DNS record found: 0 100 389 ipatest1.int.test.
2022-05-03T08:53:10Z DEBUG [Kerberos realm search]
2022-05-03T08:53:10Z DEBUG Search DNS for TXT record of _kerberos.test
2022-05-03T08:53:10Z DEBUG DNS record found: "TEST"
2022-05-03T08:53:10Z DEBUG Skipping invalid realm 'TEST' (single label realms 
are not supported)
2022-05-03T08:53:10Z DEBUG Search DNS for SRV record of _kerberos._udp.test
2022-05-03T08:53:10Z DEBUG DNS record found: 0 100 88 ipatest1.int.test.
2022-05-03T08:53:10Z DEBUG [LDAP server check]
2022-05-03T08:53:10Z DEBUG Verifying that ipatest1.int.test (realm None) is an 
IPA server
2022-05-03T08:53:10Z DEBUG Init LDAP connection to: ldap://ipatest1.int.test:389
2022-05-03T08:53:10Z DEBUG Search LDAP server for IPA base DN
2022-05-03T08:53:10Z DEBUG Check if naming context 'dc=test' is for IPA
2022-05-03T08:53:10Z DEBUG Naming context 'dc=test' is a valid IPA context
2022-05-03T08:53:10Z DEBUG Search for (objectClass=krbRealmContainer) in 
dc=test (sub)
2022-05-03T08:53:10Z DEBUG Found: 

[Freeipa-users] EL8 ipa upgrade / Single Level Domain

2022-05-03 Thread Angus Clarke via FreeIPA-users
Hello

We installed our IPA servers back in EL7.2 days and deployed with a single 
level domain and matching (uppercased) realm. Through various upgrades we are 
now at EL7.9 and are aware that the ipa-client-install command has become 
finickity about single level domains however thus far we have been able to 
continue joining EL7 clients.

I've setup my test environment similarly and have been unsuccessful in trying 
to upgrade (join new and replace old) these EL7 Freeipa servers to EL8, the 
ipa-client-install on EL8 skips the single level domain so I'm a bit stuck.

Is there a way around this in EL8?

EL7 ipa server (ipatest1):
ipa-server-4.6.8-5.0.1.el7_9.10.x86_64

EL8 (ipatest2):
ipa-server-4.9.6-12.0.1.module+el8.5.0+20642+b228f286.x86_64


​[root@ipatest2 ~]# ipa-replica-install --setup-ca --ip-address 192.168.180.141 
--password=Password1234 --principal=admin --setup-dns 
--forwarder=192.168.180.100
Configuring client side components
This program will set up IPA client.
Version 4.9.6

Unable to discover domain, not provided on command line
The ipa-client-install command failed. See /var/log/ipaclient-install.log for 
more information
Removing client side components
IPA client is not configured on this system.
The ipa-client-install command failed.

Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

Configuration of client side components failed!
The ipa-replica-install command failed. See /var/log/ipareplica-install.log for 
more information


[root@ipatest2 ~]# less /var/log/ipaclient-install.log
<-- snip
2022-05-03T08:53:10Z DEBUG [IPA Discovery]
2022-05-03T08:53:10Z DEBUG Starting IPA discovery with domain=None, 
servers=None, hostname=ipatest2.int.test
2022-05-03T08:53:10Z DEBUG Start searching for LDAP SRV record in "int.test" 
(domain of the hostname) and its sub-d
omains
2022-05-03T08:53:10Z DEBUG Search DNS for SRV record of _ldap._tcp.int.test
2022-05-03T08:53:10Z DEBUG DNS record not found: NXDOMAIN
2022-05-03T08:53:10Z DEBUG Search DNS for SRV record of _ldap._tcp.test
2022-05-03T08:53:10Z DEBUG DNS record found: 0 100 389 ipatest1.int.test.
2022-05-03T08:53:10Z DEBUG [Kerberos realm search]
2022-05-03T08:53:10Z DEBUG Search DNS for TXT record of _kerberos.test
2022-05-03T08:53:10Z DEBUG DNS record found: "TEST"
2022-05-03T08:53:10Z DEBUG Skipping invalid realm 'TEST' (single label realms 
are not supported)
2022-05-03T08:53:10Z DEBUG Search DNS for SRV record of _kerberos._udp.test
2022-05-03T08:53:10Z DEBUG DNS record found: 0 100 88 ipatest1.int.test.
2022-05-03T08:53:10Z DEBUG [LDAP server check]
2022-05-03T08:53:10Z DEBUG Verifying that ipatest1.int.test (realm None) is an 
IPA server
2022-05-03T08:53:10Z DEBUG Init LDAP connection to: ldap://ipatest1.int.test:389
2022-05-03T08:53:10Z DEBUG Search LDAP server for IPA base DN
2022-05-03T08:53:10Z DEBUG Check if naming context 'dc=test' is for IPA
2022-05-03T08:53:10Z DEBUG Naming context 'dc=test' is a valid IPA context
2022-05-03T08:53:10Z DEBUG Search for (objectClass=krbRealmContainer) in 
dc=test (sub)
2022-05-03T08:53:10Z DEBUG Found: cn=TEST,cn=kerberos,dc=test
2022-05-03T08:53:10Z DEBUG Skipping invalid realm 'TEST' (single label realms 
are not supported)
2022-05-03T08:53:10Z DEBUG Discovery result: NOT_IPA_SERVER; server=None, 
domain=test, kdc=ipatest1.int.test, bas
edn=dc=test
2022-05-03T08:53:10Z DEBUG Validated servers:
2022-05-03T08:53:10Z DEBUG No IPA server found
<-- snip


Thanks
Angus
___
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: Web service to receive callbacks via HTTP

2022-01-18 Thread Angus Clarke via FreeIPA-users
Hi Akshay

I'm unfamiliar with your specific question (I'm just a user) however the web 
interface and command line tools use the API to perform these processes which 
in turn get logged to Apache's error_log.

Regards
Angus



From: akshay p via FreeIPA-users 
Sent: Wednesday, January 19, 2022 5:27:53 AM
To: freeipa-users@lists.fedorahosted.org 
Cc: akshay p 
Subject: [Freeipa-users] Web service to receive callbacks via HTTP

I need to trap various FreeIPA events such as user addition or deletion. If I 
can trap these events (perhaps via callbacks), then I can do things like 
backing up home directories during user deletion or sending out a welcome mail 
on user addition.

Similarly, when staging users are added, I can use a callback and send an email 
to the admin notifying them of the same.

I can build a web service to receive callbacks via HTTP. Or if there is any 
other way to hook into the FreeIPA workflow, I will be glad to do that well.
___
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://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2Fdata=04%7C01%7C%7C51e3330e2e1f47cc519c08d9db041670%7C84df9e7fe9f640afb435%7C1%7C0%7C637781632875603703%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=9SZypXBzzg11maEh%2BU7o9Fk9JIupObqJk%2B%2FvQIQb7S0%3Dreserved=0
List Guidelines: 
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FMailing_list_guidelinesdata=04%7C01%7C%7C51e3330e2e1f47cc519c08d9db041670%7C84df9e7fe9f640afb435%7C1%7C0%7C637781632875603703%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=0C1cRTHCmWImL4EPxgvP9v1fvfuGs1vsnkgmRvCXtLA%3Dreserved=0
List Archives: 
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fedorahosted.org%2Farchives%2Flist%2Ffreeipa-users%40lists.fedorahosted.orgdata=04%7C01%7C%7C51e3330e2e1f47cc519c08d9db041670%7C84df9e7fe9f640afb435%7C1%7C0%7C637781632875603703%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=cwr5Qgv3HIbtFIy2Euk8RvgUf2tL9KB0Xs%2BqoOr57VQ%3Dreserved=0
Do not reply to spam on the list, report it: 
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpagure.io%2Ffedora-infrastructuredata=04%7C01%7C%7C51e3330e2e1f47cc519c08d9db041670%7C84df9e7fe9f640afb435%7C1%7C0%7C637781632875603703%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=hAdZcUfBRS9Ti1oSFpBAVeRWbAU3ilB2Pf0DkS7lEZU%3Dreserved=0
___
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: DNS and FreeIPA

2021-12-28 Thread Angus Clarke via FreeIPA-users
Hi Ian

Thanks for this, this actually comes back to my first suggestion however I was 
wanting to hide that private IP nameserver information from public view 
(infosec teams would not be happy otherwise) and so I had wondered about using 
a DNS view to only allow the external IPs of my internal DNS servers to see the 
int.angusclarke.com delegation on my public DNS servers. I'm not sure if this 
is possible with glue records and suspect that the DNS software in use (bind, 
nsd etc) probably has a bearing on that too.

I found this in my bookmarks ... it's a bit old but one of the options M$ were 
recommending at this point in time was to not configure any delegation 
information in your public DNS at all; rather just to configure your in-house 
DNS recursor to forward requests for ipa.angusclarke.com to the internal DNS 
server that handles that namespace.

https://docs.microsoft.com/en-gb/previous-versions/windows/it-pro/windows-server-2003/cc772970(v=ws.10)
(see points 1. and 2. specifically)

Delegating the subdomain from public DNS seems the more elegant (more correct?) 
option however the split view (or something) needs to be working to hide your 
delegation information from public view (infosec would insist.) Simply 
redirecting your internal DNS for a subdomain seems easier but probably isn't 
"the correct" way.

I wonder how Rafael has his DNS configured for making use of private subdomains 
as mentioned here:

> I have a (few) registered domain(s), which I use both as a public
> facing server (static, github pages), and within my private network,
> which no one from outside can see, I have a subdomain (ipa) which
> I use for managing my users and hosts.

Cheers
Angus


From: Ian Willis 
Sent: 28 December 2021 01:55
To: FreeIPA users list ; Rafael Jeffman 
; Peter Larsen 
Cc: Dave Mintz ; Angus Clarke 
Subject: Re: [Freeipa-users] Re: DNS and FreeIPA

Hi Angus,

Just be aware that maintaining parrellel records is an overhead in the longer 
term as it's a manual process of keeping things in sync.

Delegation is a simpler more natural solution in general.

Your pubic DNS servers can delegate to an internal DNS domain and then you'll 
only have the internal addresses of your DNS servers in the public domain.

For example angusclark.com has public nameservers a.b.c.d and a.b.c.e
which delegates
int.angusclark.com to internal freeipa nameservers ipa1.int.angusclark.com 
10.10.10.10 and ipa2.int.angusclark.com 10.10.10.11 using glue records on the 
public servers.

The you just follow the bouncing ball for setting up freeipa with integrated 
DNS.

Outbound Name resolution would use the freeipa servers which would forward to a 
convenient resolver or you do resolution via the root nameservers which is 
probably a more secure solution.



-Original Message-----
From: Angus Clarke via FreeIPA-users 
mailto:angus%20clarke%20via%20freeipa-users%20%3cfreeipa-us...@lists.fedorahosted.org%3e>>
Reply-To: FreeIPA users list 
mailto:freeipa%20users%20list%20%3cfreeipa-us...@lists.fedorahosted.org%3e>>
To: Rafael Jeffman 
mailto:rafael%20jeffman%20%3crjeff...@redhat.com%3e>>, 
Peter Larsen 
mailto:peter%20larsen%20%3cpe...@peterlarsen.org%3e>>
Cc: Dave Mintz 
mailto:dave%20mintz%20%3cdavemint...@gmail.com%3e>>, 
FreeIPA users list 
mailto:freeipa%20users%20list%20%3cfreeipa-us...@lists.fedorahosted.org%3e>>,
 Angus Clarke 
mailto:angus%20clarke%20%3can...@charworth.com%3e>>
Subject: [Freeipa-users] Re: DNS and FreeIPA
Date: Mon, 27 Dec 2021 23:26:31 +

Thanks for your replies, I think I need to focus on internal resolver 
configuration and less on public subdomain delegation.

Cheers
Angus








From: Rafael Jeffman 
Sent: Monday, 27 December 2021, 11:11 pm
To: Peter Larsen
Cc: Angus Clarke; FreeIPA users list; Dave Mintz
Subject: Re: [Freeipa-users] Re: DNS and FreeIPA

Hello Angus,

Besides what Peter has written, let's get this warning from FreeIPA site [1]:

> **Avoid name collisions**
> We strongly recommend that you do not use a domain name that is not
> delegated to you, even on a private network. For example, you should
> not use domain name 
> company.int<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcompany.int%2F=04%7C01%7C%7C67257c8f33854eb94bbb08d9c99cbf2d%7C84df9e7fe9f640afb435%7C1%7C0%7C637762497327894172%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=MclyFz3rEPrzI48VV%2Fv1KabWQ2fwLSCDNOkAvsHTInY%3D=0>
>  if you don't have valid delegation for
> it in public DNS tree.

As you can see, it is similar to what was on the Red Hat documentation you
mentioned before.

This first part of the warning says that you should not configure your domain
name with some "random" name if you don't own the domain. For example,
you should not use 
"cisco.com<https://emea01.

[Freeipa-users] Re: DNS and FreeIPA

2021-12-27 Thread Angus Clarke via FreeIPA-users
Thanks for sharing Harry, I really appreciate you and everyone else, taking the 
time to consider my situation.

Regards
Angus

From: Harry G. Coin via FreeIPA-users 
Sent: Tuesday, December 28, 2021 12:17:16 AM
To: freeipa-users@lists.fedorahosted.org 
Cc: Harry G. Coin 
Subject: [Freeipa-users] Re: DNS and FreeIPA

Angus,

There are two 'happy medium' approaches you can try with FreeIPA to
resolve the private/public issues you mention.

If you have just one or two addresses you want the public to see, get
one or two 'static ips' from your ISP, set them in your registrar's
setup for your name, do the routing at your isp interface and provide
the public services you prefer.   Then in Freeipa duplicate the domain,
duplicate the one or two ips the public can see, then set your in house
shop to use freeipa for resolution.   It's not 'pretty', but it is
'pretty easy' and for one or two addresses the public can see really not
so bad.  And in your use case dnssec for your domain appears to add
little of value.

The other approach for a 'happy medium' that is not the dreaded
split-view DNS is to have the ISP point to your static public IPs and
FreeIPA's dns to resolve, but with none of your private addresses in the
public domain.   Then create in the public domain a subdomain
'private.mydomain.com' or 'p.mydomain.com', but have the A record for
that point to a __ private , non routeable, __ local ipaddress -- one on
which your freeipa also listens.

Set that subdomain up in freeipa to not answer any but local IP queries.

So:  One authoritative DNS server, for which dnssec will work (it's
buggy, but for one domain you probably won't hit it), no split view DNS,
boxes checked.  Harder, and you have to deal with the
'myhost.p.mydomain' instead of 'myhost.mydomain' but checks the boxes.

HTH

Harry Coin



___
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://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2Fdata=04%7C01%7C%7C4457ec6f475142f275f908d9c98f10ce%7C84df9e7fe9f640afb435%7C1%7C0%7C637762438565036709%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=qCnC4UBL6X9yoJbIRx4xPHkgqa7h7%2BiOBcawEKXsvco%3Dreserved=0
List Guidelines: 
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FMailing_list_guidelinesdata=04%7C01%7C%7C4457ec6f475142f275f908d9c98f10ce%7C84df9e7fe9f640afb435%7C1%7C0%7C637762438565036709%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=KCYeB4cjPiDY1hBXBI2n8xinR1pjTA9noXKz2de3OXw%3Dreserved=0
List Archives: 
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fedorahosted.org%2Farchives%2Flist%2Ffreeipa-users%40lists.fedorahosted.orgdata=04%7C01%7C%7C4457ec6f475142f275f908d9c98f10ce%7C84df9e7fe9f640afb435%7C1%7C0%7C637762438565036709%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=6Jh57yHm4UOwCPitgwsJtX3fCSQGtqjbN%2BCnYP5l0oo%3Dreserved=0
Do not reply to spam on the list, report it: 
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpagure.io%2Ffedora-infrastructuredata=04%7C01%7C%7C4457ec6f475142f275f908d9c98f10ce%7C84df9e7fe9f640afb435%7C1%7C0%7C637762438565036709%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=hMT4NRLaHNC5RkP3iucigMuSr9mH0p2WtZBigvCfNGE%3Dreserved=0
___
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: DNS and FreeIPA

2021-12-27 Thread Angus Clarke via FreeIPA-users
Thanks Ian, a lot of good pointers in there!

Cheers
Angus

From: Ian Willis via FreeIPA-users 
Sent: Tuesday, December 28, 2021 12:06:52 AM
To: freeipa-users@lists.fedorahosted.org 
Cc: Ian Willis 
Subject: [Freeipa-users] Re: DNS and FreeIPA

Hi All,

Angus you appear to be struggling with fundamental concepts of how to manage 
DNS rather than how to manage FreeIPA. It appears you've already made design 
decisions without understanding the implications. You really need to understand 
the concept of split brain DNS and the complications associated with this 
approach and if delegation provides a better solution.


  1.  FreeIPA either needs to manage DNS, or you need to do it manually with a 
third party DNS system, or you can run two sets authoritative DNS servers one 
of which is freeIPA and the other which could be a third party and manually 
keep them in sync.
  2.  If you use FreeIPA to manage DNS in a public manner it will expose the 
DNS records of associated hosts. What is the issue with exposing your private 
IP addresses and hostnames, they're not routable? Its just security through 
obscurity, your security should rely upon stronger foundations.
  3.  It's not an admins vs devs thing. I'm an admin not a dev you're just 
struggling to understand how DNS works and are thrashing around thinking that a 
point and click solution will solve this lack of domain expertise. It won't, 
understand your requirements and design to them.

Read the BIND documentation, more specifically Split DNS
https://bind9.readthedocs.io/en/latest/<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbind9.readthedocs.io%2Fen%2Flatest%2F=04%7C01%7C%7Cd8de39646537493e0f4608d9c98da262%7C84df9e7fe9f640afb435%7C1%7C0%7C637762432434778672%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=mU2RmDgKmi0enUSgOM19rfFJpDjCcVmcsEG7Er8M3Tk%3D=0>
https://bind9.readthedocs.io/en/latest/advanced.html#split-dns<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbind9.readthedocs.io%2Fen%2Flatest%2Fadvanced.html%23split-dns=04%7C01%7C%7Cd8de39646537493e0f4608d9c98da262%7C84df9e7fe9f640afb435%7C1%7C0%7C637762432434778672%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=wu14zFyzaSKjDBHszO%2Bo%2F508C6jW6WDBAax64%2F3C4ck%3D=0>

In relation to your question.

  *   You've already decided that you are using a third party DNS provider for 
the domain, that's making this harder. You might want to consider delegating a 
subdomain of this domain to freeipa to manage as it's more straightforward to 
take that approach, especially if you want externally available services. 
However you need to understand how Delegation works, as the owner of a domain 
you can delegate a subdomain to another set of servers.
  *   You state that you're not exposing any of your internal servers to the 
internet. If this is the case why do you need a public DNS domain? Basically by 
definition you don't, so the problem is that you're asking a nonsense question 
and getting frustrated by the fact that you're not getting a response that 
answers you question. I suspect that the domain will offer some public services 
and some private services and that's what you're struggling with. However you 
haven't articulated this either.




-Original Message-
From: Angus Clarke via FreeIPA-users 
mailto:angus%20clarke%20via%20freeipa-users%20%3cfreeipa-us...@lists.fedorahosted.org%3e>>
Reply-To: FreeIPA users list 
mailto:freeipa%20users%20list%20%3cfreeipa-us...@lists.fedorahosted.org%3e>>
To: Rafael Jeffman 
mailto:rafael%20jeffman%20%3crjeff...@redhat.com%3e>>
Cc: Dave Mintz 
mailto:dave%20mintz%20%3cdavemint...@gmail.com%3e>>, 
FreeIPA users list 
mailto:freeipa%20users%20list%20%3cfreeipa-us...@lists.fedorahosted.org%3e>>,
 Peter Larsen 
mailto:peter%20larsen%20%3cpe...@peterlarsen.org%3e>>, 
Angus Clarke 
mailto:angus%20clarke%20%3can...@charworth.com%3e>>
Subject: [Freeipa-users] Re: DNS and FreeIPA
Date: Mon, 27 Dec 2021 20:27:14 +

Hi Rafael

I appreciate your response but we're (just me?) still lacking in direction as 
to how to properly use your software in the real world - to me It feels like an 
admins vs devs topic although I could easily be missing something :)

I mention the Microsoft documentation because i haven't found anything on this 
topic in RedHat land. I just remember the MS docs being the only source of 
useful information when last I checked.


Ok let's try this:

I've just registered angusclarke.com with a public DNS provider and am ready to 
deploy FreeIPA for my corporate network which uses a private IP space. How do I 
do this?

According to this
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/networking_guide/ch-configure_host_names#sec-Recommended_Naming_Practices<https:/

[Freeipa-users] Re: DNS and FreeIPA

2021-12-27 Thread Angus Clarke via FreeIPA-users
Thanks for your replies, I think I need to focus on internal resolver 
configuration and less on public subdomain delegation.

Cheers
Angus








From: Rafael Jeffman 
Sent: Monday, 27 December 2021, 11:11 pm
To: Peter Larsen
Cc: Angus Clarke; FreeIPA users list; Dave Mintz
Subject: Re: [Freeipa-users] Re: DNS and FreeIPA

Hello Angus,

Besides what Peter has written, let's get this warning from FreeIPA site [1]:

> **Avoid name collisions**
> We strongly recommend that you do not use a domain name that is not
> delegated to you, even on a private network. For example, you should
> not use domain name 
> company.int
>  if you don't have valid delegation for
> it in public DNS tree.

As you can see, it is similar to what was on the Red Hat documentation you
mentioned before.

This first part of the warning says that you should not configure your domain
name with some "random" name if you don't own the domain. For example,
you should not use 
"cisco.com",
 
"google.com"
 or 
"redhat.com",
 even if your
network is a private one. Note that, if it is a private network, you "could" do 
it,
but you shouldn't do it.

Why? The answer is on the warning itself:

> If this rule is not respected, the domain name will be resolved differently
> depending on the network configuration. As a result, network resources
> will become unavailable.
> Using domain names that are not delegated to
> you also makes DNSSEC more difficult to deploy and maintain. For
> further information about this issue please see the ICANN FAQ on
> domain name collisions.

Imagine you try to access google search and your private network uses
'google.com'
 as the domain. You would probably be redirected to an internal
server, instead of  Google's search engine. (I'll not even get into DNSSEC
issues.)

So, you find everywhere about "a domain that is delegated to you", well,
that domain is any domain you have registered (e.g.: 
angusclark.com).

Even as your domain have nameserver which is probably not under your
control (and controlled by whom you registered your domain), you have
control over your domain, and as such, you can create subdomains on
your private network that will not collide with any other domain (say,
ipa.angusclark.com).

If you manage this domain from your internal FreeIPA servers, there
will be no name collision.

I have a (few) registered domain(s), which I use both as a public
facing server (static, github pages), and within my private network,
which no one from outside can see, I have a subdomain (ipa) which
I use for managing my users and hosts.


[Freeipa-users] Re: DNS and FreeIPA

2021-12-27 Thread Angus Clarke via FreeIPA-users
Hi Rafael

I appreciate your response but we're (just me?) still lacking in direction as 
to how to properly use your software in the real world - to me It feels like an 
admins vs devs topic although I could easily be missing something :)

I mention the Microsoft documentation because i haven't found anything on this 
topic in RedHat land. I just remember the MS docs being the only source of 
useful information when last I checked.


Ok let's try this:

I've just registered angusclarke.com with a public DNS provider and am ready to 
deploy FreeIPA for my corporate network which uses a private IP space. How do I 
do this?

According to this
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/networking_guide/ch-configure_host_names#sec-Recommended_Naming_Practices

then I should have a domain delegated to me, but I am not a public DNS 
provider, I'm just Angus Clarke ... Nor do I want my private IP space available 
to be looked up in a public DNS record ... And I'd rather have my private IP 
records handled by my internal DNS system - all of this is standard practise 
for companies and individuals however I dont think this topic is suitably 
addressed in the redhat documentation - I see a disconnect in the 
recommendation pasted above vs the installation documentation for FreeIPA.

Maybe I've missed it, maybe I can promote the topic here and it can be 
championed in the right direction, maybe I can even help on the topic myself.

Regards
Angus



From: Rafael Jeffman 
Sent: Monday, 27 December 2021, 8:15 pm
To: Angus Clarke
Cc: FreeIPA users list; Dave Mintz; Peter Larsen
Subject: Re: [Freeipa-users] Re: DNS and FreeIPA

Hello Angus,

On Mon, Dec 27, 2021 at 11:31 AM Angus Clarke 
mailto:an...@charworth.com>> wrote:
Hi Rafael

What is not clear to me is how to integrate FreeIPA with a real public DNS 
domain, which I think is what Dave is referring to as he mentioned he owns a 
legitimate domain. In any case, AFAIK we're not supposed to use made up domains 
for internal DNS anymore ...

Although you shouldn't use a domain name you don't own, if your DNS
server is not visible outside of your network, the issues you have with
domain names would be contained to your local network (like not being
able to access 
'awellknowsearch.com'
 if you use this domain name in
your own network).



I see the docs talk about 
server.idm.example.com
 - presumably 
example.com
 is supposed to be some legitimate DNS domain and 
idm.example.com
 is a delegated subdomain, although this doesn't appear to be explained. 
Microsoft docs talk about using delegated subdomains of legitimate public DNS 
domains for internal corporate DNS, which is what got me into this train of 
thought in the first place.

Delegating a subdomain to a private IP (your internal DNS server) and hiding 
that delegation with a split view on your public DNS is one way of hiding the 
subdomain from public view whilst keeping all your private DNS data private and 
hosted/managed in house. Whether you use FreeIPA's DNS for internally hosting 
idm.example.com
 or not is a matter of choice I suppose.

A delegated subdomain is simply a subdomain for which the authoritative
DNS server is not the same as the main domain. I'm not 

[Freeipa-users] Re: DNS and FreeIPA

2021-12-26 Thread Angus Clarke via FreeIPA-users
Hi

You could host split view dns so as to only give responses to queries from 
certain (your) IP addresses, thus hiding your private DNS information from 
general public queries.

Similarly yet more succinctly, you could use a subdomain and delegate the DNS 
for that to a private IP in your network, again using a split view so that the 
delegation is only resolvable from certain (your) IPs. This way your private 
DNS records are fully internal (your DNS server) under a subdomain.

I've not yet done this myself but have considered this kind of setup (subdomain 
delegation) for some future company DNS implementation.

Regards
Angus


From: Dave Mintz via FreeIPA-users 
Sent: Sunday, 26 December 2021, 8:16 pm
To: freeipa-users@lists.fedorahosted.org
Cc: Dave Mintz
Subject: [Freeipa-users] DNS and FreeIPA

Hello,
I have been trying to set up FreeIPA on an internal CentOS 8 server.  I was 
successful in getting it running, I set up DNS for internal queries.  It 
worked.  However, when I tried to set up SSL certs I ran into issue.

My question is this:
I own a legitimate domain.
It is not “hosted”.
I have no intention of exposing any of my internal servers to the Internet.
How do I go about configuring the DNS at my registrar so that when I configure 
my internal servers, including FreeIPA, DNS, SSL, email, etc., any requests 
that go out to the Internet will resolve correctly?

Any help or pointers to documentation would be greatly appreciated.

Dave
___
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://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2Fdata=04%7C01%7C%7C735a8328373c4dfc788008d9c8a442ee%7C84df9e7fe9f640afb435%7C1%7C0%7C637761430092157142%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=OIXNMzv4ONJhUpVRA2khEvypcSDQ7Oa%2B6fVqwEaLmmg%3Dreserved=0
List Guidelines: 
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FMailing_list_guidelinesdata=04%7C01%7C%7C735a8328373c4dfc788008d9c8a442ee%7C84df9e7fe9f640afb435%7C1%7C0%7C637761430092157142%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=3SMuHPmrKA4vVO6KA%2FnCasNRt7Ss%2Bvnx8AbuhNs5XrY%3Dreserved=0
List Archives: 
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fedorahosted.org%2Farchives%2Flist%2Ffreeipa-users%40lists.fedorahosted.orgdata=04%7C01%7C%7C735a8328373c4dfc788008d9c8a442ee%7C84df9e7fe9f640afb435%7C1%7C0%7C637761430092157142%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=S3Yb%2FyHNtCDe2otDl3kh1jjUrCOYS8gqstXOeGYMBKI%3Dreserved=0
Do not reply to spam on the list, report it: 
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpagure.io%2Ffedora-infrastructuredata=04%7C01%7C%7C735a8328373c4dfc788008d9c8a442ee%7C84df9e7fe9f640afb435%7C1%7C0%7C637761430092157142%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=1r8hEHzDR1Pppe46r8CR4IeCfaTtqQ%2Fv5RBAXn90w04%3Dreserved=0

___
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: freeIPA Status Debian/Ubuntu

2021-09-06 Thread Angus Clarke via FreeIPA-users
AFAIK Oracle still produce RHEL based Linux releases for free, however I 
haven't yet migrated to EL8.

Regards
Angus


From: Nico Maas via FreeIPA-users 
Sent: 06 September 2021 07:52
To: Ian Willis 
Cc: FreeIPA users list ; Timo Aaltonen 
; Nico Maas ; Ilya Kogan 

Subject: [Freeipa-users] Re: freeIPA Status Debian/Ubuntu

Dear Ian,
thanks for the infos :)
I did need to migrate to CentOS 8 Stream as it was assured in this group this 
would be the best way in the future a few months ago.
Is there an easy way to go from CentOS 8 Stream to Rocky Linux and would this 
be the prefered way now?
(I need to have freeIPA running obviously and don't want anything to break :))

Second question:
We were talking about the Debian Bullseye Client, not freeIPA server.
e.g. how to integrate a Debian Bullseye machine into freeIPA...
With Buster, we had the freeipa-client which was easy to install via apt, now, 
it looks like thats not an option anymore... or are we just too early to the 
party? :

Cheers

Nico

Am Mo., 6. Sept. 2021 um 02:23 Uhr schrieb Ian Willis 
mailto:fed...@checksum.net.au>>:
Hi All,

If you're looking for a relatively simple solution the migration to Rocky linux 
can be achieved relatively painlessly. We've been kicking the tyres over the 
past few months and it fits our use case and Centos8 going forward doesn't. 
This isn't a shot at either Centos, Redhat or IBM its a simple statement of 
fact given the future direction of Centos.

They have a script for migration and the maintainer is one of the original 
creators of Centos which provides a degree of assurance in terms of project 
scope and continuity.

While I like Debian, the body of knowledge associated with Redhat based 
platforms and relative complexity/fragility of freeIPA would make me think 
twice before going down this path.
That being said, I would like to see a vibrant Debian freeIPA community however 
depending upon your use case there may be some issues.

Regards

Ian

-Original Message-
From: Ilya Kogan via FreeIPA-users 
mailto:ilya%20kogan%20via%20freeipa-users%20%3cfreeipa-us...@lists.fedorahosted.org%3e>>
Reply-To: FreeIPA users list 
mailto:freeipa%20users%20list%20%3cfreeipa-us...@lists.fedorahosted.org%3e>>
To: FreeIPA users list 
mailto:freeipa%20users%20list%20%3cfreeipa-us...@lists.fedorahosted.org%3e>>
Cc: Nico Maas 
mailto:nico%20maas%20%3cm...@nico-maas.de%3e>>, Timo 
Aaltonen 
mailto:timo%20aaltonen%20%3ctjaal...@ubuntu.com%3e>>, Ilya 
Kogan mailto:ilya%20kogan%20%3ciko...@mythicnet.org%3e>>
Subject: [Freeipa-users] Re: freeIPA Status Debian/Ubuntu
Date: Sun, 5 Sep 2021 16:19:38 -0400

It looks like Bullseye doesn't even have the client, if I'm not mistaken? After 
an upgrade, it's telling me that `freeipa-common` is no longer needed and 
there's no longer a `freeipa-client` package.
Is there any way to get an idea of what the situation is with this?

[http://www.gravatar.com/avatar/a35eac7a03cfc0049f13ff2d3e7a4a7f]
Ilya Kogan
w:  
github.com/ikogan
   e:  iko...@mythicnet.org
[http://cdn2.hubspot.net/hubfs/184235/dev_images/signature_app/twitter_sig.png] 


[http://cdn2.hubspot.net/hubfs/184235/dev_images/signature_app/linkedin_sig.png]
 



On Thu, Dec 10, 2020 at 2:20 PM Nico Maas via FreeIPA-users 
mailto:freeipa-users@lists.fedorahosted.org>>
 wrote:
Thank you for your update and hard work Timo :)!

Am Do., 10. Dez. 2020 um 19:38 Uhr schrieb Timo Aaltonen 
mailto:tjaal...@ubuntu.com>>:
On 9.12.2020 13.30, Nico Maas via FreeIPA-users wrote:
> Hello there,
>
> with the decline of CentOS I need to migrate away from CentOS 8 to something 
> different.
> I just wanted to ask how currently the status of the Debian or Ubuntu 
> versions of freeIPA is - and if there is any possibility to migrate freeIPA 
> installation / "backup and restore"?
>
> Best regards,
>
> Nico

Hi,

Short answer:

ipaserver-install 

[Freeipa-users] Re: [EXTERNAL] FreeIPA Enterprise or Paid Support

2021-03-18 Thread Angus Clarke via FreeIPA-users
Don't shoot me :)

Oracle support FreeIPA as part of their general Linux support package, expected 
to be on Oracle Linux of course however I think they offer support for other 
Linux OSs too but this might only be through some onboarding phase.

Suse used to support non-suse Linux as well but I don't think they are as 
flexible as Oracle.

Another option, if your FreeIPA is running on some other Linux, you could add 
more replicas running on Redhat or Orable and then decommission your existing 
installations (do your reading, pay attention to your CA!)

Regards
Angus


From: Morgan Marodin via FreeIPA-users 
Sent: Thursday, March 18, 2021 11:04:55 AM
To: FreeIPA users list 
Cc: White, Daniel E. (GSFC-770.0)[NICS] ; Morgan 
Marodin 
Subject: [Freeipa-users] Re: [EXTERNAL] FreeIPA Enterprise or Paid Support

Is it possible to have FreeIPA paid support in a no Red Hat environment?

Il giorno mer 10 mar 2021 alle ore 17:22 White, Daniel E. (GSFC-770.0)[NICS] 
via FreeIPA-users 
mailto:freeipa-users@lists.fedorahosted.org>>
 ha scritto:

This would be Red Hat Enterprise Linux Identity Manager

__



Daniel E. White
daniel.e.wh...@nasa.gov

NASCOM Linux Engineer
NASA Goddard Space Flight Center
Science Applications International Corporation (SAIC)
Office: (301) 286-6919

Mobile: (240) 513-5290



From: FreeIPA-Users 
mailto:freeipa-users@lists.fedorahosted.org>>
Reply-To: FreeIPA-Users 
mailto:freeipa-users@lists.fedorahosted.org>>
Date: Wednesday, March 10, 2021 at 11:15
To: FreeIPA-Users 
mailto:freeipa-users@lists.fedorahosted.org>>
Cc: Rohan Talkar mailto:talkar.ro...@gmail.com>>
Subject: [EXTERNAL] [Freeipa-users] FreeIPA Enterprise or Paid Support



HI,



I am new to FreeIPA & planning to implement it my organization.



I am not sure do FreeIPA have Enterprise or paid support.



Please let me know if any one have idea about this.



Regards,

Ron

___

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://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2Fdata=04%7C01%7Cdaniel.e.white%40nasa.gov%7Cbd1600fd53ca41d36afa08d8e3dfadc3%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C637509897122630598%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=ZE7ClT84zzM34sCxXaxZWLpMe8g04zcFebNGE6kAspc%3Dreserved=0

List Guidelines: 
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FMailing_list_guidelinesdata=04%7C01%7Cdaniel.e.white%40nasa.gov%7Cbd1600fd53ca41d36afa08d8e3dfadc3%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C637509897122630598%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=KmdkRtyeQGTzrsAksd4CRtAH9w34oJiU9oNgWR6wow0%3Dreserved=0

List Archives: 
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fedorahosted.org%2Farchives%2Flist%2Ffreeipa-users%40lists.fedorahosted.orgdata=04%7C01%7Cdaniel.e.white%40nasa.gov%7Cbd1600fd53ca41d36afa08d8e3dfadc3%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C637509897122630598%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=rTO1vbaI4PGz42oRLqQZFq8CZ%2FYhchPD%2BUIHo5a5aAU%3Dreserved=0

Do not reply to spam on the list, report it: 

[Freeipa-users] Re: Allow "sudo su - USER" to only the specified user

2021-01-22 Thread Angus Clarke via FreeIPA-users
sss_cache -E to invalidate all cache, you can be more refined with other 
options.

Regards
Angus


From: Russ Long via FreeIPA-users 
Sent: 22 January 2021 16:39
To: freeipa-users@lists.fedorahosted.org 
Cc: Russ Long 
Subject: [Freeipa-users] Re: Allow "sudo su - USER" to only the specified user

And caching is no fun.  The second option, to allow all commands to be run as 
the specified user works if I wait for the cache to expire.
___
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://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2Fdata=04%7C01%7C%7Cff773f8c876e449961bf08d8beebe885%7C84df9e7fe9f640afb435%7C1%7C0%7C637469267720153097%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=1ItsgQ7oPMDifpI8Q%2F24LEScwQtn7RTykT06SIISX2c%3Dreserved=0
List Guidelines: 
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FMailing_list_guidelinesdata=04%7C01%7C%7Cff773f8c876e449961bf08d8beebe885%7C84df9e7fe9f640afb435%7C1%7C0%7C637469267720153097%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=mpCR9YEbYXgDAF6LkaEdiv8idXHhHCgLNxxrp8d9aJM%3Dreserved=0
List Archives: 
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fedorahosted.org%2Farchives%2Flist%2Ffreeipa-users%40lists.fedorahosted.orgdata=04%7C01%7C%7Cff773f8c876e449961bf08d8beebe885%7C84df9e7fe9f640afb435%7C1%7C0%7C637469267720153097%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=IF%2FkmQliCV2hblUqkhfFcGQIuUDqC6yKiFo8kVvLxSw%3Dreserved=0
___
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: Allow "sudo su - USER" to only the specified user

2021-01-22 Thread Angus Clarke via FreeIPA-users
I edited sudoers by hand however it should give you something to aim towards ...

[root@orable76 ~]# grep angus /etc/sudoers
angus   ALL=NOPASSWD: /usr/bin/su - appuser

[root@orable76 ~]# su - angus
Last login: Fri Jan 22 17:01:30 CET 2021 on pts/0

[angus@orable76 ~]$ sudo su - appuser
Last login: Fri Jan 22 17:01:31 CET 2021 on pts/0
[appuser@orable76 ~]$

Regards
Angus


From: Russ Long via FreeIPA-users 
Sent: 22 January 2021 16:33
To: freeipa-users@lists.fedorahosted.org 
Cc: Russ Long 
Subject: [Freeipa-users] Allow "sudo su - USER" to only the specified user

I'm trying to come up with a Sudo rule that will allow a user to "su" to only a 
single specified user. I need to give a DBA access to the oracle user account.

This serverfault article details exactly what I want to do, however this is not 
for FreeIPA.

I've tried creating a sudo command that's "/usr/bin/su - USER" and other 
variations to no avail.

I've also tried creating a sudo rule that allows all commands to be run as 
"USER".
___
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://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2Fdata=04%7C01%7C%7Cc5865f04ac9742ca5c0e08d8beeb23c1%7C84df9e7fe9f640afb435%7C1%7C0%7C637469264416962239%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=0Ct2BwekRyBxRQElO93Z%2B%2BjhjHLKOteW0rnj4SS3LnY%3Dreserved=0
List Guidelines: 
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FMailing_list_guidelinesdata=04%7C01%7C%7Cc5865f04ac9742ca5c0e08d8beeb23c1%7C84df9e7fe9f640afb435%7C1%7C0%7C637469264416962239%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=qBXXBRnzVBEuvk0hyvxvZwWQyzTYud9f%2Fr19Y6yuOxY%3Dreserved=0
List Archives: 
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fedorahosted.org%2Farchives%2Flist%2Ffreeipa-users%40lists.fedorahosted.orgdata=04%7C01%7C%7Cc5865f04ac9742ca5c0e08d8beeb23c1%7C84df9e7fe9f640afb435%7C1%7C0%7C637469264416962239%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=zm%2F5%2Fat1R%2BfsgvRn7UrYAFk5aDlwwCLu8V5HMQBSAX0%3Dreserved=0
___
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: Helpo with DNS setup?

2020-12-30 Thread Angus Clarke via FreeIPA-users
Forward and reverse lookups use the resolver library which is configured 
through /etc/nsswitch.conf
As long as files is listed before dns then you should be good:

$ grep ^hosts: /etc/nsswitch.conf
hosts:  files dns myhostname

Regards
Angus


From: Dominik Vogt via FreeIPA-users 
Sent: 30 December 2020 16:36
To: FreeIPA users list 
Cc: Dominik Vogt 
Subject: [Freeipa-users] Re: Helpo with DNS setup?

On Wed, Dec 30, 2020 at 04:20:53PM +0100, François Cami wrote:
> On Wed, Dec 30, 2020 at 2:55 PM Dominik Vogt via FreeIPA-users <
> freeipa-users@lists.fedorahosted.org> wrote:
> > we need to install ipa-server on a box running RHEL8, say
> > server.foo.bar.baz, 192.168.123.45.  ipa-server-install needs
> > working name resolution for that host, and as there is no other
> > machine installed yet, this server must run named to provide it.
> >
> > Is there some working sample configuration for named (RHEL8 config
> > style) that suffices to install ipa-server (using the --setup-dns
> > option)?
> >
>
> An easier option is probably to use a (temporary) hosts file entry for this
> machine.
> Then use ipa-server-install ; you should then remote the hosts file entry.

Does that work?  The RHEL8 IdM server installation instructions
claim that forward and reverse lookup of the server have to work.

Ciao

Dominik ^_^  ^_^

--

Dominik Vogt
___
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://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2Fdata=04%7C01%7C%7C8389825b26d747b31bb208d8acd8bbaa%7C84df9e7fe9f640afb435%7C1%7C0%7C637449394142921106%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=uO56SCFQNUHfBBfc%2FRvFnzu9BPkp01j2UhqxDo%2BTsk0%3Dreserved=0
List Guidelines: 
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FMailing_list_guidelinesdata=04%7C01%7C%7C8389825b26d747b31bb208d8acd8bbaa%7C84df9e7fe9f640afb435%7C1%7C0%7C637449394142921106%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=w7fPZWzl7%2Bmn1T5gxrgv%2BC8SvPuz3XpuaAQ9dBr9RNY%3Dreserved=0
List Archives: 
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fedorahosted.org%2Farchives%2Flist%2Ffreeipa-users%40lists.fedorahosted.orgdata=04%7C01%7C%7C8389825b26d747b31bb208d8acd8bbaa%7C84df9e7fe9f640afb435%7C1%7C0%7C637449394142921106%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=kN8XTgQbJBUXfcoDRi3YoYaMWuFgQExDL3rxfiBS%2F%2B8%3Dreserved=0
___
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: Reinstalling client's OS

2020-12-04 Thread Angus Clarke via FreeIPA-users
The steps you mention seem fine to me Roberto, Detlev has detailed an 
alternative.

If you lose a client and need to rebuild (i.e. you didn't get chance to run the 
"--uninstall" option) then you can also just delete the host entry from IPA 
through the web gui or ipa command line before running the ipa-client-install 
(join) command.

When I have issues with clients (very infrequent and I have some 5000 clients) 
I find that running the "--uninstall" and then the install (steps 1 and 3) fix 
most issues without having to look into them (blind fix for the time wary!)

Regards
Angus


From: Detlev Habicht via FreeIPA-users 
Sent: 04 December 2020 11:59
To: FreeIPA users list 
Cc: Detlev Habicht 
Subject: [Freeipa-users] Re: Reinstalling client's OS

Hi,

you can reinstall a client with something like this:

/usr/sbin/ipa-client-install --force --unattended —domain=xxx —realm=xxx 
—server=xxx —server=yyy --force-ntpd —keytab=./krb5.keytab 
--ca-cert-file=./ca.crt

But you must save your keytab and ca file before.

For me it is working …

Detlev

--
  Detlev  | Institut fuer Mikroelektronische Systeme
  Habicht | D-30167 Hannover +49 511 76219662 habi...@ims.uni-hannover.de
  + Handy+49 172 5415752  ---



> Am 04.12.2020 um 11:46 schrieb Roberto Cornacchia via FreeIPA-users 
> :
>
> Hello,
>
> Apologies if this is a trivial question, I could not find an obvious answer 
> anywhere.
>
> If I want to reinstall from scratch the OS of an already enrolled client, is 
> this the right procedure?
>
> 1. ipa-client-install --uninstall
> 2. 
> 3. ipa-client-install
>
> Best regards,
> Roberto
> ___
> 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2Fdata=04%7C01%7C%7Ca51e09497c794cfb098908d89843bc39%7C84df9e7fe9f640afb435%7C1%7C0%7C637426763967360942%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=fyz1F%2Bu9GU4%2BSe1iqHKETf1aXIetl7jt5RNrWaThsIs%3Dreserved=0
> List Guidelines: 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FMailing_list_guidelinesdata=04%7C01%7C%7Ca51e09497c794cfb098908d89843bc39%7C84df9e7fe9f640afb435%7C1%7C0%7C637426763967360942%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=fdVD5aYltsHDH9OfcX3M7tRNSA5gQuIex%2BsUEXnEjpI%3Dreserved=0
> List Archives: 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fedorahosted.org%2Farchives%2Flist%2Ffreeipa-users%40lists.fedorahosted.orgdata=04%7C01%7C%7Ca51e09497c794cfb098908d89843bc39%7C84df9e7fe9f640afb435%7C1%7C0%7C637426763967360942%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=oIA%2BVUaGSmbN6BNGGeGFSApHNGWG6aolwCkd8CVNWHg%3Dreserved=0
___
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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2Fdata=04%7C01%7C%7Ca51e09497c794cfb098908d89843bc39%7C84df9e7fe9f640afb435%7C1%7C0%7C637426763967360942%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=fyz1F%2Bu9GU4%2BSe1iqHKETf1aXIetl7jt5RNrWaThsIs%3Dreserved=0
List Guidelines: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FMailing_list_guidelinesdata=04%7C01%7C%7Ca51e09497c794cfb098908d89843bc39%7C84df9e7fe9f640afb435%7C1%7C0%7C637426763967360942%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=fdVD5aYltsHDH9OfcX3M7tRNSA5gQuIex%2BsUEXnEjpI%3Dreserved=0
List Archives: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fedorahosted.org%2Farchives%2Flist%2Ffreeipa-users%40lists.fedorahosted.orgdata=04%7C01%7C%7Ca51e09497c794cfb098908d89843bc39%7C84df9e7fe9f640afb435%7C1%7C0%7C637426763967370935%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Qdfjr8UsivPZLJS9uOam0EwEasVvanYpFnYIF6BkVnE%3Dreserved=0
___
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 

[Freeipa-users] Re: Stop/Disable Apache on IdM servers

2020-10-09 Thread Angus Clarke via FreeIPA-users
Thanks for your input Rob - you've said enough to scare me off the topic!

Cheers
Angus


From: Rob Crittenden 
Sent: 08 October 2020 20:52
To: FreeIPA users list 
Cc: Angus Clarke 
Subject: Re: [Freeipa-users] Stop/Disable Apache on IdM servers

Angus Clarke via FreeIPA-users wrote:
> Hello
>
> We have a single mesh of FreeIPA servers in several different locations,
> we capture logs (apache ErrorLog directive) to a log server in each of
> those locations. When auditors ask us questions we have to trawl log
> servers from all locations as our IdM administrators might have used any
> of the IdM servers to make changes.
>
> To limit that access to one site, I am considering stopping and
> disabling apache on all IdM servers at other sites and just wanted to
> check there are no unintended consequences in that action.
>
> I'm not looking for enforcement, merely a means of persuading the team
> to use the web interface or command line tools at one site.

It's completely untested so if something went wrong you'd be pretty far
out on the ledge.

You're purposely creating a single-point-of-failure. You'd need to work
out some system to transition the web server to another server.

The chosen server would need to run a CA, otherwise it will try to find
one and fail at connecting since the CA connect is proxied through Apache.

Establishing a new CA would likewise almost certainly be problematic.

The ipa-ca CNAME is used so clients can use OCSP. You'd have to manually
limit this value to only the available web server. Same with CRL.

Running other administrative commands on those hosts would fail
miserably (ipa-certupdate, ipa-cacert-manage for sure).

I'm not certain if ipa-server-upgrade which is also run at package
installation needs local API access. IPA servers make certain
assumptions about what basic services are available.

So this could well be the kind of thing that seems to work, you relax
and forget about it, then all heck breaks loose.

Either way, masking/stopping the service wouldn't really work since it
is managed via ipactl. You'd have to mark the service as disabled in
IPA, and I'm not sure you can do that to an IPA service so you'd
probably have to do it manually using ldapmodify.

rob

___
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] Stop/Disable Apache on IdM servers

2020-10-08 Thread Angus Clarke via FreeIPA-users
Hello

We have a single mesh of FreeIPA servers in several different locations, we 
capture logs (apache ErrorLog directive) to a log server in each of those 
locations. When auditors ask us questions we have to trawl log servers from all 
locations as our IdM administrators might have used any of the IdM servers to 
make changes.

To limit that access to one site, I am considering stopping and disabling 
apache on all IdM servers at other sites and just wanted to check there are no 
unintended consequences in that action.

I'm not looking for enforcement, merely a means of persuading the team to use 
the web interface or command line tools at one site.

Thanks!
Angus
___
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: POSIX ids of all AD users

2020-10-03 Thread Angus Clarke via FreeIPA-users
Hi Ronald

Look at the "Attribute Editor" tab against a user account in "Active Directory 
users and computers." It should be in the list there (uidNumber) amongst other 
useful things.

I'm no Microsoft administrator but am aware that this "Attribute Editor" tab is 
not listed if you search for the user; rather you have to browse to the user 
through the tree.

Regards
Angus


From: Ronald Wimmer via FreeIPA-users 
Sent: Saturday, October 3, 2020 8:31:35 AM
To: Simo Sorce via FreeIPA-users 
Cc: Ronald Wimmer 
Subject: [Freeipa-users] Re: POSIX ids of all AD users

On 02.10.20 16:03, Simo Sorce via FreeIPA-users wrote:
> On Fri, 2020-10-02 at 12:27 +0200, Ronald Wimmer via FreeIPA-users
> wrote:
>> How could I possibly find the POSIX ids of all mapped Active Directory
>> users?
>>
>> I do neither see them in LDAP nor do I find them with IPA user find.
> They are in AD, query AD please.
>
> The only other option is to use a command like: id , but that
> requires knowledge of each AD username you care for.
>
> Keep in mind IPA is not a caching LDAP server, that's not its role, its
> role is to provide the means to establish a point of trust between the
> two worlds, so that AD clients can use services hosted in the IPA
> domain servers.

Before reading your answer I always thought that IPA holds a unique UID
for each user. I was not aware that they could be found in AD. But where
in AD? What do I need to query for? When I take a look at my user in AD
i cannot find the UID attribute anywhere.

Cheers,
Ronald
___
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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2Fdata=02%7C01%7C%7C660e108c8fc848b3c30008d86766121a%7C84df9e7fe9f640afb435%7C1%7C0%7C637373035384689909sdata=E7jpcbw19BgJypo7DO%2FAPBjeO3%2ByYFyFGn7KNHo3wBg%3Dreserved=0
List Guidelines: 
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FMailing_list_guidelinesdata=02%7C01%7C%7C660e108c8fc848b3c30008d86766121a%7C84df9e7fe9f640afb435%7C1%7C0%7C637373035384699904sdata=%2BUjasGtKypIFd%2BrtN4XBhjUJvHs%2FfHwhfk3k%2BR1DK9I%3Dreserved=0
List Archives: 
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fedorahosted.org%2Farchives%2Flist%2Ffreeipa-users%40lists.fedorahosted.orgdata=02%7C01%7C%7C660e108c8fc848b3c30008d86766121a%7C84df9e7fe9f640afb435%7C1%7C0%7C637373035384699904sdata=utXOj09jKFR43pybkgSDoTlgpsugD0u2gnUXfwovT3A%3Dreserved=0
___
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: migrate IPA server to new OS

2020-09-04 Thread Angus Clarke via FreeIPA-users
You could build a replica, reinstall your original with Centos and then build 
that as a replica. Not too much downtime for your original whilst it is being 
rebuilt.

Regards
Angus

From: Boris Behrens via FreeIPA-users 
Sent: Friday, September 4, 2020 11:34:02 AM
To: François Cami 
Cc: FreeIPA users list ; Boris Behrens 

Subject: [Freeipa-users] Re: migrate IPA server to new OS

Well, maybe "migrate" is the wrong word. I would like to copy files to another 
system and have IPA running on the new OS. (like a wordpress or something).


Am Fr., 4. Sept. 2020 um 10:02 Uhr schrieb François Cami 
mailto:fc...@redhat.com>>:
Hi,

On Fri, Sep 4, 2020 at 9:29 AM Boris Behrens via FreeIPA-users
mailto:freeipa-users@lists.fedorahosted.org>>
 wrote:
>
> Hi,
> just a short question:
>
> Is it possible to migrate a freeIPA server to a new host?

Yes

> I'd like to move from fedora 26 to centos8, but I wouldn't like to "add a new 
> master, then remove the older master, test everything, move ip addresses and 
> fw rules" and all that stuff.

The above is the way to migrate.

François


> Cheers
>  Boris
> --
> Die Selbsthilfegruppe "UTF-8-Probleme" trifft sich diesmal abweichend im 
> groüen Saal.
> ___
> 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



--
Die Selbsthilfegruppe "UTF-8-Probleme" trifft sich diesmal abweichend im 
groüen Saal.
___
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] Web UI behind Reverse proxy

2020-08-25 Thread Angus Clarke via FreeIPA-users
Hello

We want to give freeipa web ui access to a corporate team, our security guys 
insist we hide this behind a reverse proxy, we're putting 2 of our 10 freeipa 
servers behind the RP address.

In our initial testing we get the kerberos error "Unable to verify your 
Kerberos credentials" in the browser.

I saw this
https://www.redhat.com/archives/freeipa-users/2015-April/msg00597.html

which led me to this
https://ssimo.org/blog/id_019.html

The last paragraph mentions "... until the FreeIPA project provides a way to 
officially access the Web UI using aliases." - is this a thing now?

Otherwise I presume to follow the step mentioned in the very last sentence and 
to investigate redirection.

Thanks for any pointers.

Regards
Angus

___
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: Multimaster error adding user when one master down.

2020-08-12 Thread Angus Clarke via FreeIPA-users
Hi

Just a bit of user experience ...

I'm guessing you ran the ipa-client-install program on your client specifying 
"--server=ipa01.bos1.domain.com" rather than relying on auto-discovery 
(requires SRV DNS records)

If DNS SRV records are not configured and you need to manually specify the IPA 
servers, then Instead of trying to fix by hand, uninstall the client with 
"ipa-client-istall --uninstall" and then reinstall giving the --server= option 
twice (once for each IPA server) to the ipa-client-install command

Regards
Angus


From: Louis Bohm via FreeIPA-users 
Sent: 11 August 2020 23:16
To: freeipa-users@lists.fedorahosted.org 
Cc: Louis Bohm 
Subject: [Freeipa-users] Multimaster error adding user when one master down.

Environment:
2 IPA Masters running Centos 8 and IPA Server 4.8.0.13
Client running Lentos 8 and IPA Client 4.8.0.13

The masters were setup as MultiMasters (I think I have it correct).

If I shutdown the first master (ipa01) so only ipa02 is running then try to 
login to the client I cannot. Found I needed to add both hosts to the 
IPA_server line in the SSSD.conf under the domain section to make that work.

Now if I try to add a user via the command line on the client I get the 
following error:
ipa: ERROR: cannot connect to 
'https://ipa01.bos1.domain.com/ipa/json':
 [Errno 113] No route to host

Do I need to list both IPA servers some where else?  If so where?  I did try 
adding both IPA servers on the URL line of openldap.conf (only ipa01 was 
listed).

Louis
-<<—->>-
Louis Bohm
louisb...@gmail.com

[cid:e7976d93-d339-46e9-b2ef-5ca2045cf46b] 



___
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: Planing multi-site deployment

2020-06-03 Thread Angus Clarke via FreeIPA-users
Hi

We run a similar setup (multiple sites, different dns domain per site, 2 IPA 
servers per site) without the issues you mention, we're not using DNS discovery 
however that shouldn't make a huge difference.

Are you passing --realm=blah to the ipa-client-install command? That and other 
options will help for sure.

Regards
Angus


From: Willie Cadete de Lima via FreeIPA-users 

Sent: 03 June 2020 14:58
To: freeipa-users@lists.fedorahosted.org 
Cc: Willie Cadete de Lima 
Subject: [Freeipa-users] Planing multi-site deployment

Hi guys,

It's my first time attending the Fedora mailing list if someone can help me I 
appreciate

I've decided to ask here because I couldn't find any answer in the docs or 
googling.

I'd like to deploy the Feeipa with the following scenario:

domains:
site1.prod.int.mydomain.com
site2.prod.int.mydomain.com

Each site with 2 servers and set up a replication agreement between them and 
the datacenters.

EX:
ipa01.site1.prod.int.mydomain.com <--> ipa01.site2.prod.int.mydomain.com
  | 
  |
ipa02.site1.prod.int.mydomain.com <--> ipa02.site2.prod.int.mydomain.com



But all clients authenticating in only one Kerberos domain INT.MYDOMAIN.COM

I've tried deploying that way and I come across with two issues:

- The first server deployment works fine, but the client installation fails 
because it couldn't find the KDC (autodiscovery works fine).

After some searching, I found out that it's because the way Kerberos 
autodiscovery works ( it look up the DNS using _kerberos.REALM.). Passing the 
arguments --server and --domain the installation works fine.

- A different site client enrollment works, but the replica promotion fails 
with "IPA different domain"

server - ipa01.site1.prod.int.mydomain.com
replica - ipa01.site2.prod.int.mydomain.com

I found out it's because of that patch.
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.redhat.com%2Farchives%2Ffreeipa-devel%2F2016-June%2Fmsg00620.htmldata=02%7C01%7C%7C22a84ccdc7d244d7d92a08d807bddec8%7C84df9e7fe9f640afb435%7C1%7C0%7C637267859346417445sdata=jnDbTGC80haqbm3B2newU6CQG3kSd54hzoZ1UbY2rSU%3Dreserved=0

That being said, how can I deploy the Freeipa with a multi-site scenario?

And if it isn't possible that way, What's the recommended way to do it?


Regards

___
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://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2Fdata=02%7C01%7C%7C22a84ccdc7d244d7d92a08d807bddec8%7C84df9e7fe9f640afb435%7C1%7C0%7C637267859346417445sdata=BXUH2uhVV9EVOVBNfq419H%2Fv8vlMHhp5%2BdaBVW3BKbw%3Dreserved=0
List Guidelines: 
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FMailing_list_guidelinesdata=02%7C01%7C%7C22a84ccdc7d244d7d92a08d807bddec8%7C84df9e7fe9f640afb435%7C1%7C0%7C637267859346417445sdata=ujGoYeR40gJpUl2Fqr1EW%2BYfIUQelQOfFGFJ0OebenM%3Dreserved=0
List Archives: 
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fedorahosted.org%2Farchives%2Flist%2Ffreeipa-users%40lists.fedorahosted.orgdata=02%7C01%7C%7C22a84ccdc7d244d7d92a08d807bddec8%7C84df9e7fe9f640afb435%7C1%7C0%7C637267859346417445sdata=Z4zysxx8T0Tq5z6AXVHZyCDk5Rx9LE%2BCmaFVylLBHcU%3Dreserved=0
___
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: where to place the freeipa server in a segmented network

2020-05-08 Thread Angus Clarke via FreeIPA-users
Hi

At the one end of things you might want to secure your IPA server in your 
production network however this might not be reachable from other networks 
(your network policy.) At the other end of things you might want to place it in 
your most accessible network however then the system is more at risk from 
outside involvement. Worth remembering there is no "read only" version of IPA 
(yet.) The point here is that if you have some secured IPA instances in 
production connected to IPA servers outside of production then your whole IPA 
infra is exposed by the member in the weakest security zone.

We run out IPA infrastructure globally with VPN connected sites, no issue 
there. I don't have experience of road warrior VPN clients though. I'm not sure 
how IPA behaves when hosts connect with possibly different FQDNs for example.

Regards
Angus
___
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: Unset passwords for accounts

2020-05-05 Thread Angus Clarke via FreeIPA-users
After running, the web UI no longer shows a string of asterisks next to the 
password field of the user.

Thanks ever so much!
Angus


From: Rob Crittenden 
Sent: 04 May 2020 15:34
To: FreeIPA users list 
Cc: Angus Clarke 
Subject: Re: [Freeipa-users] Unset passwords for accounts

Angus Clarke via FreeIPA-users wrote:
> Hello
>
> We don't use FreeIPA passwords for user accounts however some accounts
> have had passwords set which is noticed from time to time. I would like
> to revert those account passwords to the point when the user was newly
> added but the password not yet set.
>
> I don't see anything obvious in the documentation, perhaps there is some
> behind the scenes way of achieving this? (For reference, I used to put
> "!!" in /etc/shadow when using local files)

There is no equivalent of "no password allowed" in IPA. I think there is
or was an RFE for this at one point.

To clear out existing password attributes you'd need to use ldapmodify
and bind as the Directory Manager to remove them.

$ ldapmodify -x -D 'cn=directory manager' -W
Enter LDAP Password:
dn: uid=tuser1,cn=users,cn=accounts,dc=example,dc=test
changetype: modify
delete: krbprincipalkey
-
delete: userpassword
-
delete: krbextradata
-
delete: krbpasswordexpiration
-
delete: krblastpwdchange

^D

rob

___
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] Unset passwords for accounts

2020-05-04 Thread Angus Clarke via FreeIPA-users
Hello

We don't use FreeIPA passwords for user accounts however some accounts have had 
passwords set which is noticed from time to time. I would like to revert those 
account passwords to the point when the user was newly added but the password 
not yet set.

I don't see anything obvious in the documentation, perhaps there is some behind 
the scenes way of achieving this? (For reference, I used to put "!!" in 
/etc/shadow when using local files)

Thanks a lot
Angus
___
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: EL7 Upgrades

2020-04-21 Thread Angus Clarke via FreeIPA-users
Other issues have kept me from returning to this topic and I haven't yet made 
any further progress, so I'll just say thanks now for the advice - thanks a lot!

Regards
Angus


From: Rob Crittenden 
Sent: Tuesday, April 7, 2020 5:15:41 PM
To: FreeIPA users list 
Cc: Angus Clarke 
Subject: Re: [Freeipa-users] EL7 Upgrades

Angus Clarke via FreeIPA-users wrote:
> Hello
>
> Our environment has grown and as additional IPA servers have been added,
> different versions have been deployed. I am looking to bring IPA servers
> up to the latest version for EL7 and wanted some guidance or reassurance.
>
> Here are my versions, they are all VMWare VMs:
>
> idm001 ipa-server-4.5.4-10.0.1.el7.x86_64 Red Hat Enterprise Linux
> Server release 7.4 (Maipo) * UPGRADED *
> idm002 ipa-server-4.5.0-22.0.1.el7_4.x86_64   Red Hat Enterprise Linux
> Server release 7.4 (Maipo) * CA MASTER *
> idm003 ipa-server-4.5.0-22.0.1.el7_4.x86_64   Red Hat Enterprise Linux
> Server release 7.4 (Maipo)
> idm004 ipa-server-4.5.0-22.0.1.el7_4.x86_64   Red Hat Enterprise Linux
> Server release 7.4 (Maipo)
> idm005 ipa-server-4.6.5-11.0.1.el7_7.4.x86_64 Red Hat Enterprise Linux
> Server release 7.7 (Maipo)
> idm006 ipa-server-4.6.5-11.0.1.el7_7.4.x86_64 Red Hat Enterprise Linux
> Server release 7.7 (Maipo)
> idm007 ipa-server-4.6.5-11.0.1.el7_7.3.x86_64 Red Hat Enterprise Linux
> Server release 7.7 (Maipo)
> idm008 ipa-server-4.6.5-11.0.1.el7_7.3.x86_64 Red Hat Enterprise Linux
> Server release 7.7 (Maipo)
> idm009 ipa-server-4.6.4-10.0.1.el7_6.6.x86_64 Red Hat Enterprise Linux
> Server release 7.6 (Maipo)
> idm010 ipa-server-4.6.4-10.0.1.el7_6.6.x86_64 Red Hat Enterprise Linux
> Server release 7.6 (Maipo)
>
> I have upgraded idm001 without issue, the path was:
>
> 1) take VMWare snapshot
> 2) ipactl stop
> 3) yum update (channel with latest EL versions)
> 4) reboot
> 5) after a day or so, remove VMWare snapshot
>
> and it now shows:
>
> idm001 ipa-server-4.6.5-11.0.1.el7_7.4.x86_64Red Hat Enterprise Linux
> Server release 7.7 (Maipo)
>
> Post upgrade checks on idm001:
>
> I see network connections to port 88 and 389
> I can obtain a kerberos ticket through kinit
> I can login through the web interface and issue ipa commands.
> I don't see anything particularly alarming in log files.
>
> I understand the distributed LDAP schema was already up-to-date due to
> the roll out of idm005-006 on EL7.7/ipa-server-4.6.5-11.0.1.el7_7.4.
>
> I'm particularly concerned about upgrading idm002, my CA server -
> perhaps I should upgrade through each EL iteration? Are VMWare snapshots
> a suitable roll back mechanism for IPA (and IPA CA master) server upgrades?

Yes and yes, especially given your already mixed versions.

Given you have other CAs in your network there is nothing too special
about idm002 other than it has the additional role as CA renewal master.

> I was reading Rob's reply to Christian Reiss regarding his upgrade path
> to EL8 (bookmarked for future reference,) I don't have the
> ipa-crlgen-manage command on my CA server (presumably due to older
> version) to check if it is the CRL generator - I assume it is though,
> although in any case I'm unsure of the relevance with this EL7 series of
> ipa-server.

There are instructions at
https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.freeipa.org%2Fpage%2FHowto%2FPromote_CA_to_Renewal_and_CRL_Masterdata=02%7C01%7C%7C75670f0afb3741064fc808d7db068da0%7C84df9e7fe9f640afb435%7C1%7C0%7C637218693507938594sdata=dUzYXOIuVoXPWBTq4HsE2LEz8pMDRosrS362BEQ4CdA%3Dreserved=0
which can tell you which one is doing it. If you aren't using CRLs at
all then this is probably not super important but you want to avoid
having 2 or more masters generating one since there is a race condition
where separate CA's could generate different, but otherwise valid, CRLs.

> All my IPA servers have CA capability except for idm001 - I presume I
> deployed it incorrectly in the first place. I would like to add CA
> facility to it, perhaps this is for a different thread though ...

ipa-ca-install should do it but yeah, I'd probably focus on getting the
other masters up to 7.7 or 7.8 before trying to add on the CA. You don't
necessarily need a CA on every master. You want to avoid single point of
failure but you don't need it everywhere.

rob

___
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] EL7 Upgrades

2020-04-07 Thread Angus Clarke via FreeIPA-users
Hello

Our environment has grown and as additional IPA servers have been added, 
different versions have been deployed. I am looking to bring IPA servers up to 
the latest version for EL7 and wanted some guidance or reassurance.

Here are my versions, they are all VMWare VMs:

idm001 ipa-server-4.5.4-10.0.1.el7.x86_64 Red Hat Enterprise Linux Server 
release 7.4 (Maipo) * UPGRADED *
idm002 ipa-server-4.5.0-22.0.1.el7_4.x86_64   Red Hat Enterprise Linux Server 
release 7.4 (Maipo) * CA MASTER *
idm003 ipa-server-4.5.0-22.0.1.el7_4.x86_64   Red Hat Enterprise Linux Server 
release 7.4 (Maipo)
idm004 ipa-server-4.5.0-22.0.1.el7_4.x86_64   Red Hat Enterprise Linux Server 
release 7.4 (Maipo)
idm005 ipa-server-4.6.5-11.0.1.el7_7.4.x86_64 Red Hat Enterprise Linux Server 
release 7.7 (Maipo)
idm006 ipa-server-4.6.5-11.0.1.el7_7.4.x86_64 Red Hat Enterprise Linux Server 
release 7.7 (Maipo)
idm007 ipa-server-4.6.5-11.0.1.el7_7.3.x86_64 Red Hat Enterprise Linux Server 
release 7.7 (Maipo)
idm008 ipa-server-4.6.5-11.0.1.el7_7.3.x86_64 Red Hat Enterprise Linux Server 
release 7.7 (Maipo)
idm009 ipa-server-4.6.4-10.0.1.el7_6.6.x86_64 Red Hat Enterprise Linux Server 
release 7.6 (Maipo)
idm010 ipa-server-4.6.4-10.0.1.el7_6.6.x86_64 Red Hat Enterprise Linux Server 
release 7.6 (Maipo)

I have upgraded idm001 without issue, the path was:

1) take VMWare snapshot
2) ipactl stop
3) yum update (channel with latest EL versions)
4) reboot
5) after a day or so, remove VMWare snapshot

and it now shows:

idm001 ipa-server-4.6.5-11.0.1.el7_7.4.x86_64 Red Hat Enterprise Linux Server 
release 7.7 (Maipo)

Post upgrade checks on idm001:

I see network connections to port 88 and 389
I can obtain a kerberos ticket through kinit
I can login through the web interface and issue ipa commands.
I don't see anything particularly alarming in log files.

I understand the distributed LDAP schema was already up-to-date due to the roll 
out of idm005-006 on EL7.7/ipa-server-4.6.5-11.0.1.el7_7.4.

I'm particularly concerned about upgrading idm002, my CA server - perhaps I 
should upgrade through each EL iteration? Are VMWare snapshots a suitable roll 
back mechanism for IPA (and IPA CA master) server upgrades?

I was reading Rob's reply to Christian Reiss regarding his upgrade path to EL8 
(bookmarked for future reference,) I don't have the ipa-crlgen-manage command 
on my CA server (presumably due to older version) to check if it is the CRL 
generator - I assume it is though, although in any case I'm unsure of the 
relevance with this EL7 series of ipa-server.

All my IPA servers have CA capability except for idm001 - I presume I deployed 
it incorrectly in the first place. I would like to add CA facility to it, 
perhaps this is for a different thread though ...

Thank you for any feedback.

Regards
Angus

___
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: Some users unable to log in to host

2020-03-17 Thread Angus Clarke via FreeIPA-users
Hello

I suggest running the hbactest function, somrthing like:

ipa hbactest --user=user1 --host=fqdn.of.target.server --service=login

Regards
Angus


From: Kristian Petersen via FreeIPA-users 
Sent: 16 March 2020 21:57
To: FreeIPA users list 
Cc: Kristian Petersen 
Subject: [Freeipa-users] Some users unable to log in to host

Hey all,

I have a user that is trying to log into a host that is configured to have 
access restricted via an HBAC rule.  This user is a member of one of the groups 
defined in the HBAC rule that should be granted access.  When this user tries 
to SSH in to this host, they get 3 consecutive password prompts like 
"Password:" and then one like "username@domain's password:" and then they get a 
response of "Permission denied, please try again."  I am not seeing any entries 
in the messages log or secure log for this user from these log in attempts.  
Anyone have any thoughts about why this is happening?
--
Kristian Petersen
System Administrator
BYU Dept. of Chemistry and Biochemistry
___
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: freeIPA in a complex multi-subnet, multi-domain, multi-identity provider lab environment

2020-03-06 Thread Angus Clarke via FreeIPA-users
Aaah, for me that is outside of my knowledge.

Regards
Angus

From: Todd Grayson via FreeIPA-users 
Sent: Friday, March 6, 2020 11:31:36 PM
To: freeipa-users@lists.fedorahosted.org 
Cc: Todd Grayson 
Subject: [Freeipa-users] Re: freeIPA in a complex multi-subnet, multi-domain, 
multi-identity provider lab environment

Thanks Rob,  Thanks Angus,

I am aware of how to point the client to the specific IPA server, what I'm 
struggling more with is freeIPA in an environment where its not using DNS for 
domain and realm resolution for kerberos, which does work today.
I should have limited my question to the following:

Is it possible to use ipaClient but manage static mappings in the krb5.conf 
[realm] and [domain realm] and run with dns_lookup_kdc=false and 
dns_lookup_realm=false (including the krb5.conf on the ipa server itself so its 
aware of all).  The question from Angus makes me believe that having the 
dns_lookup* = false is a unsupported context in an IPA environment.

Thanks for your feedback.
___
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://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2Fdata=02%7C01%7C%7C6d5c12bb19d7453808d7c21e319f%7C84df9e7fe9f640afb435%7C1%7C0%7C637191307245791585sdata=VApA4XyNHNHRrlkjbMXjyPD8C2wP2ISlrJZYGFBxIE0%3Dreserved=0
List Guidelines: 
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FMailing_list_guidelinesdata=02%7C01%7C%7C6d5c12bb19d7453808d7c21e319f%7C84df9e7fe9f640afb435%7C1%7C0%7C637191307245791585sdata=XWHZFHKCEGlkq0KNerNLtK0MbnHDlaAqxt%2FqKFYpc7Y%3Dreserved=0
List Archives: 
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fedorahosted.org%2Farchives%2Flist%2Ffreeipa-users%40lists.fedorahosted.orgdata=02%7C01%7C%7C6d5c12bb19d7453808d7c21e319f%7C84df9e7fe9f640afb435%7C1%7C0%7C637191307245791585sdata=hpVkU7jFfhRgCbNtXoiZUuXoOB6TsxsnMcyRgKnbLDI%3Dreserved=0
___
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: freeIPA in a complex multi-subnet, multi-domain, multi-identity provider lab environment

2020-03-06 Thread Angus Clarke via FreeIPA-users
Or indeed chose any of your existing DNS domains for the IPA servers, I suspect 
changing the domain at a later time might be troublesome, so maybe pick one 
that has some assured longevity to it!

Regards
Angus


From: Angus Clarke via FreeIPA-users 
Sent: Friday, March 6, 2020 9:49:20 PM
To: FreeIPA users list 
Cc: Todd Grayson ; Angus Clarke 
Subject: [Freeipa-users] Re: freeIPA in a complex multi-subnet, multi-domain, 
multi-identity provider lab environment

Hello

As far as I'm aware, Kerberos requires DNS A records for clients and servers. 
Could you not just setup freeIPA using its internal DNS using a new domain just 
to add the ipa servers to, and then have forwarding between the different DNS 
systems? Clients can be under any DNS domain you like, as long as they resolve.

Regards
Angus


From: Todd Grayson via FreeIPA-users 
Sent: Friday, March 6, 2020 4:50:25 PM
To: freeipa-users@lists.fedorahosted.org 
Cc: Todd Grayson 
Subject: [Freeipa-users] freeIPA in a complex multi-subnet, multi-domain, 
multi-identity provider lab environment

Hello,

Reading what I can find,  it seems that its almost impossible to use freeIPA 
clients and expect to not have to configure DNS SRV or TEXT records to resolve 
the freeIPA for eveything, which is a shock... is appears to be no simple way 
to just have krb5.conf's that fall back on non DNS related resolution of KDC 
[realm] and [domain_realm] based resolution and mapping is that correct?  
Or am I missing some discussion on how to force a ipaclient setup to handle 
this kind of "krb5.conf" mapping instead of depending on DNS?

I'm tasked with trying to bring IPA into what is a long standing lab 
environment that spans multiple cloud providers, multiple data centers, and 
collections of ad-hoc environments that we need to develop, train, and test 
within.  Naturally this is spanning about 10 or so unique BIND dns domains.   
There are 6 separate active directory domains as well representing the range of 
domain functional levels from 2008 - 2016 that handle their own DNS.

The environment historically includes a mix of MIT kerberos and Active 
directory domains,as well as ad-hoc MIT realms that are set up for exercising 
various cross realm trust scenarios from Java, Python and other application 
stacks.

I'm hoping to end up with a few discreete freeIPA domains as a centralized 
static service that can be shared, rather than make everyone setup ad-hoc IPA 
instances, but its looking like my approach is NOT going to work and we are 
going to have to cookbook adhoc IPA setups that will be in conflict with each 
other within the subnets they pop up in.

Am I mssing something as far as non DNS aware freeIPA integration? Or is the 
design really locked down as much as it seems to where everything must be 
coordinated at the network DNS level to get these lab systems (small clusters) 
scattered across these lab environments to be able to register as ipa clients?

Any pointers to blogs, threads etc that speak to this would be greatly 
appreciated...
___
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://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2Fdata=02%7C01%7C%7Cd5713db9bb4c4421b16508d7c1e6225b%7C84df9e7fe9f640afb435%7C1%7C0%7C637191066476823588sdata=ecrX%2F9y7ko0TtqLgfGWifqbWWHM%2BvQRMzehTB9SMc7E%3Dreserved=0<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F=02%7C01%7C%7C84615b0298de44d1eed108d7c20fef80%7C84df9e7fe9f640afb435%7C1%7C0%7C637191246004129170=y9euc2bDyQD5%2F1Jd4GnHIyN7HVyqiDy3UXjwOodg8n4%3D=0>
List Guidelines: 
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FMailing_list_guidelinesdata=02%7C01%7C%7Cd5713db9bb4c4421b16508d7c1e6225b%7C84df9e7fe9f640afb435%7C1%7C0%7C637191066476833599sdata=le2CP0oFUb8FlSRSG31wCycUxs6VV7Km0uyuS%2FNo3so%3Dreserved=0<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FMailing_list_guidelines=02%7C01%7C%7C84615b0298de44d1eed108d7c20fef80%7C84df9e7fe9f640afb435%7C1%7C0%7C637191246004139166=YghuQGke7NK0F7LdC7RaGtfFtm%2F3yi0jy%2Brt%2Bk4%2BPGQ%3D=0>
List Archives: 
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fedorahosted.org%2Farchives%2Flist%2Ffreeipa-users%40lists.fedorahosted.orgdata=02%7C01%7C%7Cd5713db9bb4c4421b16508d7c1e6225b%7C84df9e7fe9f640afb435%7C1%7C0%7C637191066476833599sdata=BblBt%2FrlfvhAdVt07V4EJPTSF84V%2FazZMS4XDjI4P6c%3Dreserved=0<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fedorahosted.org%2Farchiv

[Freeipa-users] Re: freeIPA in a complex multi-subnet, multi-domain, multi-identity provider lab environment

2020-03-06 Thread Angus Clarke via FreeIPA-users
Hello

As far as I'm aware, Kerberos requires DNS A records for clients and servers. 
Could you not just setup freeIPA using its internal DNS using a new domain just 
to add the ipa servers to, and then have forwarding between the different DNS 
systems? Clients can be under any DNS domain you like, as long as they resolve.

Regards
Angus


From: Todd Grayson via FreeIPA-users 
Sent: Friday, March 6, 2020 4:50:25 PM
To: freeipa-users@lists.fedorahosted.org 
Cc: Todd Grayson 
Subject: [Freeipa-users] freeIPA in a complex multi-subnet, multi-domain, 
multi-identity provider lab environment

Hello,

Reading what I can find,  it seems that its almost impossible to use freeIPA 
clients and expect to not have to configure DNS SRV or TEXT records to resolve 
the freeIPA for eveything, which is a shock... is appears to be no simple way 
to just have krb5.conf's that fall back on non DNS related resolution of KDC 
[realm] and [domain_realm] based resolution and mapping is that correct?  
Or am I missing some discussion on how to force a ipaclient setup to handle 
this kind of "krb5.conf" mapping instead of depending on DNS?

I'm tasked with trying to bring IPA into what is a long standing lab 
environment that spans multiple cloud providers, multiple data centers, and 
collections of ad-hoc environments that we need to develop, train, and test 
within.  Naturally this is spanning about 10 or so unique BIND dns domains.   
There are 6 separate active directory domains as well representing the range of 
domain functional levels from 2008 - 2016 that handle their own DNS.

The environment historically includes a mix of MIT kerberos and Active 
directory domains,as well as ad-hoc MIT realms that are set up for exercising 
various cross realm trust scenarios from Java, Python and other application 
stacks.

I'm hoping to end up with a few discreete freeIPA domains as a centralized 
static service that can be shared, rather than make everyone setup ad-hoc IPA 
instances, but its looking like my approach is NOT going to work and we are 
going to have to cookbook adhoc IPA setups that will be in conflict with each 
other within the subnets they pop up in.

Am I mssing something as far as non DNS aware freeIPA integration? Or is the 
design really locked down as much as it seems to where everything must be 
coordinated at the network DNS level to get these lab systems (small clusters) 
scattered across these lab environments to be able to register as ipa clients?

Any pointers to blogs, threads etc that speak to this would be greatly 
appreciated...
___
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://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2Fdata=02%7C01%7C%7Cd5713db9bb4c4421b16508d7c1e6225b%7C84df9e7fe9f640afb435%7C1%7C0%7C637191066476823588sdata=ecrX%2F9y7ko0TtqLgfGWifqbWWHM%2BvQRMzehTB9SMc7E%3Dreserved=0
List Guidelines: 
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FMailing_list_guidelinesdata=02%7C01%7C%7Cd5713db9bb4c4421b16508d7c1e6225b%7C84df9e7fe9f640afb435%7C1%7C0%7C637191066476833599sdata=le2CP0oFUb8FlSRSG31wCycUxs6VV7Km0uyuS%2FNo3so%3Dreserved=0
List Archives: 
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fedorahosted.org%2Farchives%2Flist%2Ffreeipa-users%40lists.fedorahosted.orgdata=02%7C01%7C%7Cd5713db9bb4c4421b16508d7c1e6225b%7C84df9e7fe9f640afb435%7C1%7C0%7C637191066476833599sdata=BblBt%2FrlfvhAdVt07V4EJPTSF84V%2FazZMS4XDjI4P6c%3Dreserved=0
___
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: Traffic from client to server through management's interface

2020-02-17 Thread Angus Clarke via FreeIPA-users
Not very helpful I realise but in my experience, moving away from 
multi-interfaced servers to single interface was the best thing we ever did. It 
took massive change in the tech department to do that but was well worth it 
with respect to reduced complexity.

Regards
Angus


From: Daniel PC via FreeIPA-users 
Sent: Monday, February 17, 2020 9:18:41 PM
To: freeipa-users@lists.fedorahosted.org 
Cc: Daniel PC 
Subject: [Freeipa-users] Traffic from client to server through management's 
interface

I would like to know what do you think about using the management network 
(eth1) to enable the flow from clients to IPA servers? My company is concerned 
about using the production network interface (eth0) and is considering doing 
everything on the second interface.

Is it worth it?
Pros and cons?
What does your experience say?

Thank you
___
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://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2Fdata=02%7C01%7C%7Cae9b529c88e84bd1cc8c08d7b3e6a5b0%7C84df9e7fe9f640afb435%7C1%7C0%7C637175675509277926sdata=0qe7cEywWSN0XjDZCtduynOpZeztHlLbseVZvJbi1qU%3Dreserved=0
List Guidelines: 
https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FMailing_list_guidelinesdata=02%7C01%7C%7Cae9b529c88e84bd1cc8c08d7b3e6a5b0%7C84df9e7fe9f640afb435%7C1%7C0%7C637175675509277926sdata=w6%2FjnsHJp0VVYC036omMzqVMsZfBXT8sWbYI6AUKkxM%3Dreserved=0
List Archives: 
https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fedorahosted.org%2Farchives%2Flist%2Ffreeipa-users%40lists.fedorahosted.orgdata=02%7C01%7C%7Cae9b529c88e84bd1cc8c08d7b3e6a5b0%7C84df9e7fe9f640afb435%7C1%7C0%7C637175675509277926sdata=lC3qLzdo3B876jxSOKogdfbfRIQviaBnK7%2F%2B6Hhi5hI%3Dreserved=0
___
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: Integrated DNS - best solution to unique domain

2020-01-17 Thread Angus Clarke via FreeIPA-users
As is often the case, ours was an operational experience decision - we already 
had a DNS which was already managed by my team.

All the best
Angus


From: Daniel PC via FreeIPA-users 
Sent: 16 January 2020 16:19
To: freeipa-users@lists.fedorahosted.org 
Cc: Daniel PC 
Subject: [Freeipa-users] Re: Integrated DNS - best solution to unique domain

Ok but I'm thinking to this: "there is tight integration between DNS and native 
IdM tools
which enables automating some of the DNS record management".

Your choice is not a bad idea but my first option is to use IdM DNS integrated.

Thank you
___
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: Where is the "Audit" in IPA?

2020-01-15 Thread Angus Clarke via FreeIPA-users
Yeah, to find what I'm looking for I keep a list of grep examples, as auditors 
generally ask for the same things! I modify httpd.conf to send ErrorLog 
messages to syslog and then use syslog to send those to a server with cheap 
storage to keep a long history.

Regards
Angus


From: Charles Hedrick 
Sent: 15 January 2020 22:54
To: FreeIPA users list 
Cc: Ryan Slominski ; Angus Clarke 
Subject: Re: [Freeipa-users] Where is the "Audit" in IPA?

This looks pretty reasonable. Unfortunately it intermixed lots of info. The 
files grow rapidly enough that it’s probably not practical to keep them for a 
long time. It might not be hard to pull out just the things that make changes.

On Jan 15, 2020, at 4:47 PM, Angus Clarke via FreeIPA-users 
mailto:freeipa-users@lists.fedorahosted.org>>
 wrote:

Just a note from a fellow user ...

Changes made through the API are logged via apache's ErrorLog directive, I've 
been using this to some degree of success to answer 3rd party audit queries. 
However it does miss things like "which groups was this user a member of when 
they were deleted" though ... The facilities you are asking about sound 
excellent Ryan!

Regards
Angus


From: Ryan Slominski via FreeIPA-users 
mailto:freeipa-users@lists.fedorahosted.org>>
Sent: 15 January 2020 20:28
To: 
freeipa-users@lists.fedorahosted.org<mailto:freeipa-users@lists.fedorahosted.org>
 
mailto:freeipa-users@lists.fedorahosted.org>>
Cc: Ryan Slominski mailto:ry...@jlab.org>>
Subject: [Freeipa-users] Where is the "Audit" in IPA?

Hi FreeIPA dudes,

What is the status of audit in IPA?  Specifically, is there an easy way to 
determine what was the group membership of a particular group was at a 
particular point in time, say last October?I noticed there is an audit log 
file (disabled by default), but that is going to be a not-so-easy way to try to 
re-construct group membership at a point in time in the past.   I was hoping to 
just navigate to a "history" tab on the GUI, but no such luck.   Is this on 
anyone's todo list?   I also noticed a "Centralized Logging" webpage that 
suggest setting up an ELK stack, but that doesn't quite provide snapshots of 
group membership.

What about the ability to subscribe to changes (as opposed to poll them)?  I 
suppose the replication features could be used somehow, but those are also 
polling based?  Would be nice to configure simple callbacks (perhaps HTTP post) 
when things change.  I believe this is called a webhook.Any support for 
this kind of notification system?

Thanks,

Ryan
___
FreeIPA-users mailing list -- 
freeipa-users@lists.fedorahosted.org<mailto:freeipa-users@lists.fedorahosted.org>
To unsubscribe send an email to 
freeipa-users-le...@lists.fedorahosted.org<mailto:freeipa-users-le...@lists.fedorahosted.org>
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F=02%7C01%7C%7C5ebd6552c5f84a1be69b08d79a0591b4%7C84df9e7fe9f640afb435%7C1%7C0%7C637147221015988868=w3NQB%2FaTzl5iXKwqC8XGPEbl8th9fX00djWYQ%2BjQKAI%3D=0>
List Guidelines: 
https://fedoraproject.org/wiki/Mailing_list_guidelines<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FMailing_list_guidelines=02%7C01%7C%7C5ebd6552c5f84a1be69b08d79a0591b4%7C84df9e7fe9f640afb435%7C1%7C0%7C637147221015998879=mvy%2Fgagxzz49ks3I4Ca3ThX3c2qIOS9JiRJTb1ufgIg%3D=0>
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fedorahosted.org%2Farchives%2Flist%2Ffreeipa-users%40lists.fedorahosted.org=02%7C01%7C%7C5ebd6552c5f84a1be69b08d79a0591b4%7C84df9e7fe9f640afb435%7C1%7C0%7C637147221016008890=0UhO%2FarwWoXhquvrAY65CQIjb%2Fnq6OBPBcy6UEB8dqg%3D=0>
___
FreeIPA-users mailing list -- 
freeipa-users@lists.fedorahosted.org<mailto:freeipa-users@lists.fedorahosted.org>
To unsubscribe send an email to 
freeipa-users-le...@lists.fedorahosted.org<mailto:freeipa-users-le...@lists.fedorahosted.org>
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F=02%7C01%7C%7C5ebd6552c5f84a1be69b08d79a0591b4%7C84df9e7fe9f640afb435%7C1%7C0%7C637147221016028900=1JMVCboRvIuQp5kgqwsS7IlmjTOPLIrvHEzb1ZpuJ4Q%3D=0>
List Guidelines: 
https://fedoraproject.org/wiki/Mailing_list_guidelines<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedorapr

[Freeipa-users] Re: Where is the "Audit" in IPA?

2020-01-15 Thread Angus Clarke via FreeIPA-users
Just a note from a fellow user ...

Changes made through the API are logged via apache's ErrorLog directive, I've 
been using this to some degree of success to answer 3rd party audit queries. 
However it does miss things like "which groups was this user a member of when 
they were deleted" though ... The facilities you are asking about sound 
excellent Ryan!

Regards
Angus


From: Ryan Slominski via FreeIPA-users 
Sent: 15 January 2020 20:28
To: freeipa-users@lists.fedorahosted.org 
Cc: Ryan Slominski 
Subject: [Freeipa-users] Where is the "Audit" in IPA?

Hi FreeIPA dudes,

What is the status of audit in IPA?  Specifically, is there an easy way to 
determine what was the group membership of a particular group was at a 
particular point in time, say last October?I noticed there is an audit log 
file (disabled by default), but that is going to be a not-so-easy way to try to 
re-construct group membership at a point in time in the past.   I was hoping to 
just navigate to a "history" tab on the GUI, but no such luck.   Is this on 
anyone's todo list?   I also noticed a "Centralized Logging" webpage that 
suggest setting up an ELK stack, but that doesn't quite provide snapshots of 
group membership.

What about the ability to subscribe to changes (as opposed to poll them)?  I 
suppose the replication features could be used somehow, but those are also 
polling based?  Would be nice to configure simple callbacks (perhaps HTTP post) 
when things change.  I believe this is called a webhook.Any support for 
this kind of notification system?

Thanks,

Ryan
___
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] DNS discovery / locations

2020-01-09 Thread Angus Clarke via FreeIPA-users
Hello

Not sure if this is more a generic DNS question or not ...

We run FreeIPA 4.6.4 on a RHEL7.6 clone, we do not use FreeIPA DNS and we 
currently do not use DNS discovery. I have read this: 
https://www.freeipa.org/page/Howto/IPA_locations
 and am comfortable configuring split view DNS records.


As we depoy more sites. I am looking to move to using DNS discovery, however we 
use site specific DNS domains (rightly or wrongly with a private TLD ... cross 
that bridge when we come to it ...) such as:

site1.blah
site2.blah

which is different from the given example of example.com being used across all 
sites.


Our Realm Domain is blah - I have put the location based DNS records 
immediately under .blah.

In testing, I see ipa clients initially query DNS for SRV records under 
site1.blah - when that fails the clients then perform a second DNS query for 
SRV records under .blah - which works and my test outcome is good - the setup 
works!

Is it safe for me to assume that this process will remain the same for future 
IDM client versions? My concern is that if future versions neglect the 
second-attempt DNS discovery lookup (under .blah) then my setup will break.

Thanks for any pointers
Angus
___
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: SOC documentation

2019-11-18 Thread Angus Clarke via FreeIPA-users
Not directly answering your question but sharing some knowledge ...

Similarly our IPA system falls under certain audit conditions, specifically 
with regard to user addition/deletion and what goup memberships have been 
ammended over some period of time (we base our sudo rules on group 
memberships.) I found all these things are logged by the API to Apache's error 
log dirctive so it was quite straight forward to see those logs sent over the 
network to a central log server. Both the web interface and "ipa" commands use 
the API.

It's not perfect, for example when a user is deleted there is no log as to 
which groups they were removed from as part of that deletion process - so far 
though that hasn't been identified as an issue by auditors!

Regards
Angus



From: Shumel Rahman via FreeIPA-users 
Sent: Monday, 18 November 2019, 20:18
To: freeipa-users@lists.fedorahosted.org
Cc: Shumel Rahman
Subject: [Freeipa-users] SOC documentation

Hi
I would like to know if you have any T's and other such documentation that 
would satisfy a SOC Audit? I understand that FreeIPA is Open Source but perhaps 
there some relevant documentation on this topic. FreeIPA is used by our 
organisation for access to a key application and as such falls into scope of 
our audit.

Do let me know if any clarification of the above is required. Or indeed any 
questions or feedback. I look forward to hearing from you.

Regards
Shumel

Shumel Rahman
Application Manager for Tech
+46 760009846

iZettle – Tools to build your business

izettle.com

___
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: number of topology segments for 3 servers clean setup?

2019-10-29 Thread Angus Clarke via FreeIPA-users
Just some user notes

I really like the IPA server topology graph through the web front end, 
visualising the agreements between servers is really useful. You can add or 
remove agreements here too, for both domain and CA (for servers that have CA 
enabled)

I've deployed 6 IPA servers equally across our three main sites and enabled CA 
on all of them, this seems to work fine and I've succefully moved the CA 
renewal master twice (due to external reasons.)

Check the red hat documentation on replication agreements, I recall there are 
some useful notes there on planning.

Regards
Angus



From: lejeczek via FreeIPA-users 
Sent: Tuesday, 29 October 2019, 14:24
To: FreeIPA users list
Cc: lejeczek
Subject: [Freeipa-users] Re: number of topology segments for 3 servers clean 
setup?

On 29/10/2019 08:51, Alexander Bokovoy wrote:
> On ti, 29 loka 2019, lejeczek via FreeIPA-users wrote:
>> hi everyone,
>>
>> I wanted to ask about number of segments after a clean IPA setup with 3
>> servers.
>>
>> I see for both 'domain' & 'ca' two segments created by master/replica
>> installations, which makes me wonder - should there not be three? no/yes
>> & why?
> You really need to show what you have rather than assume we know what
> you have.
>
> For three masters, there are several ways of connecting them so that
> there are two segments. Or may be you connected all three in a triangle.
>
> For example: A <-> B <-> C, B <-> A <-> C, A <-> B <-> C <-> A
>
> Without knowing your topology it is not possible to say what is correct
> and what is not.
>
sorry was being vague. Question was not about correct or not but rather
I sought to confirm that what IPA replicas (3 masters in total)
installers created in topology - which was two segments - was what IPA
does by default (and not seek to create every every possible chain in
topology, in my case it'd be that triangle) and not a result of some
error/problem.

I now assume that it simply is - each replica installation process
creates just one segment: new-replica <-> used_master ?

many thanks, L.


___
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: Full Server backup fails with IPA version error

2019-10-29 Thread Angus Clarke via FreeIPA-users
Sorry that's out of my depth

I took it that you still had a remaining replica, in which case you should be 
able to follow the path I mentioned earlier. If so, you just need to understand 
the CA situation. I build all my IPA servers in the way I mentioned and specify 
--setup-ca on all of them.

Regards
Angus


From: Saurabh Garg 
Sent: Tuesday, October 29, 2019 9:08:06 AM
To: Angus Clarke 
Cc: FreeIPA users list 
Subject: Re: [Freeipa-users] Re: Full Server backup fails with IPA version error

Thanks Angus for the reply.

In my case, original IPA server is completely damaged / deleted, and now I am 
attempting to create an exactly similar server using "full-server" backup.
Do you have any suggestions for such a scenario?

Thanks
sgarg

On Fri, Oct 25, 2019 at 6:05 PM Angus Clarke 
mailto:p...@angusclarke.com>> wrote:
Hi

An alternative approach would be to setup your new server as an IPA client and 
then to promote it.

On new server:
# ipa-client-install

Followed by
# ipa-replica-install

Check the man pages for options suitable to your environment, otherwise I 
specify --setup-ca for all our new IPA instances.

I use this process for rolling out new IPA servers when we add new environments.

Regards
Angus


From: Saurabh Garg via FreeIPA-users 
mailto:freeipa-users@lists.fedorahosted.org>>
Sent: Friday, October 25, 2019 11:55:40 AM
To: 
freeipa-users@lists.fedorahosted.org
 
mailto:freeipa-users@lists.fedorahosted.org>>
Cc: Saurabh Garg mailto:saurabh@gmail.com>>
Subject: [Freeipa-users] Full Server backup fails with IPA version error

Background -
We are trying to restore "full server" from an existing IPA server (with 
replication ON to another server) to a newly created IPA Server from the same 
golden image as all other servers.

Source IPA Server: Red Hat Enterprise Linux Server release 7.7 (Maipo)
# ipa-server-install --version
4.6.4

Destination IPA Server: Red Hat Enterprise Linux Server release 7.7 (Maipo)
# ipa-server-install --version
4.6.4

Problem Statement -
While running  "ipa-restore" (exact command: # ipa-restore /root/backup/) on 
the new IPA server for full server backup, system throws the following error 
lines in iparestore.log:


2019-10-25T08:19:26Z DEBUG stderr=IPA version error: data needs to be upgraded 
(expected version '4.6.4-10.el7_6.6', current version '4.6.4-10.el7_6.3')
Automatically running upgrade, for details see /var/log/ipaupgrade.log
Be patient, this may take a few minutes.
Automatic upgrade failed: Update complete
Upgrading the configuration of the IPA services
[Verifying that root certificate is published]
[Migrate CRL publish directory]
Publish directory already set to new location
[Verifying that CA proxy configuration is correct]
IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command 
ipa-server-upgrade manually.
CA did not start in 300.0s
The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for more 
information

See the upgrade log for more details and/or run /usr/sbin/ipa-server-upgrade 
again
Aborting ipactl

2019-10-25T08:19:26Z INFO Restoring umask to 23
2019-10-25T08:19:26Z DEBUG   File 
"/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 178, in execute
return_value = self.run()
  File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_restore.py", 
line 428, in run
run(['ipactl', 'start'])
  File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 562, in run
raise CalledProcessError(p.returncode, arg_string, str(output))

2019-10-25T08:19:26Z DEBUG The ipa-restore command failed, exception: 
CalledProcessError: Command 'ipactl start' returned non-zero exit status 1
2019-10-25T08:19:26Z ERROR Command 'ipactl start' returned non-zero exit status 
1
2019-10-25T08:19:26Z ERROR The ipa-restore command failed. See 
/var/log/iparestore.log for more information

In case you are aware of its fix/workaround, kindly share the steps.

Thanks,
sgarg
___
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://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2Fdata=02%7C01%7C%7Cf387ce2c794d4e68d3e108d759318ccc%7C84df9e7fe9f640afb435%7C1%7C0%7C637075941655510312sdata=P9YiAhfLP52C%2FuH0C%2BqyJYWovpEM90fMVy8VBgGsZh0%3Dreserved=0
List Guidelines: 

[Freeipa-users] Re: Full Server backup fails with IPA version error

2019-10-25 Thread Angus Clarke via FreeIPA-users
Hi

An alternative approach would be to setup your new server as an IPA client and 
then to promote it.

On new server:
# ipa-client-install

Followed by
# ipa-replica-install

Check the man pages for options suitable to your environment, otherwise I 
specify --setup-ca for all our new IPA instances.

I use this process for rolling out new IPA servers when we add new environments.

Regards
Angus


From: Saurabh Garg via FreeIPA-users 
Sent: Friday, October 25, 2019 11:55:40 AM
To: freeipa-users@lists.fedorahosted.org 
Cc: Saurabh Garg 
Subject: [Freeipa-users] Full Server backup fails with IPA version error

Background -
We are trying to restore "full server" from an existing IPA server (with 
replication ON to another server) to a newly created IPA Server from the same 
golden image as all other servers.

Source IPA Server: Red Hat Enterprise Linux Server release 7.7 (Maipo)
# ipa-server-install --version
4.6.4

Destination IPA Server: Red Hat Enterprise Linux Server release 7.7 (Maipo)
# ipa-server-install --version
4.6.4

Problem Statement -
While running  "ipa-restore" (exact command: # ipa-restore /root/backup/) on 
the new IPA server for full server backup, system throws the following error 
lines in iparestore.log:


2019-10-25T08:19:26Z DEBUG stderr=IPA version error: data needs to be upgraded 
(expected version '4.6.4-10.el7_6.6', current version '4.6.4-10.el7_6.3')
Automatically running upgrade, for details see /var/log/ipaupgrade.log
Be patient, this may take a few minutes.
Automatic upgrade failed: Update complete
Upgrading the configuration of the IPA services
[Verifying that root certificate is published]
[Migrate CRL publish directory]
Publish directory already set to new location
[Verifying that CA proxy configuration is correct]
IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command 
ipa-server-upgrade manually.
CA did not start in 300.0s
The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for more 
information

See the upgrade log for more details and/or run /usr/sbin/ipa-server-upgrade 
again
Aborting ipactl

2019-10-25T08:19:26Z INFO Restoring umask to 23
2019-10-25T08:19:26Z DEBUG   File 
"/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 178, in execute
return_value = self.run()
  File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_restore.py", 
line 428, in run
run(['ipactl', 'start'])
  File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 562, in run
raise CalledProcessError(p.returncode, arg_string, str(output))

2019-10-25T08:19:26Z DEBUG The ipa-restore command failed, exception: 
CalledProcessError: Command 'ipactl start' returned non-zero exit status 1
2019-10-25T08:19:26Z ERROR Command 'ipactl start' returned non-zero exit status 
1
2019-10-25T08:19:26Z ERROR The ipa-restore command failed. See 
/var/log/iparestore.log for more information

In case you are aware of its fix/workaround, kindly share the steps.

Thanks,
sgarg
___
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://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2Fdata=02%7C01%7C%7Cf387ce2c794d4e68d3e108d759318ccc%7C84df9e7fe9f640afb435%7C1%7C0%7C637075941655510312sdata=P9YiAhfLP52C%2FuH0C%2BqyJYWovpEM90fMVy8VBgGsZh0%3Dreserved=0
List Guidelines: 
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FMailing_list_guidelinesdata=02%7C01%7C%7Cf387ce2c794d4e68d3e108d759318ccc%7C84df9e7fe9f640afb435%7C1%7C0%7C637075941655510312sdata=211CDIyJCx7zCeyfeAfx34CRw08LGZbzneFgGZX%2Bggg%3Dreserved=0
List Archives: 
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fedorahosted.org%2Farchives%2Flist%2Ffreeipa-users%40lists.fedorahosted.orgdata=02%7C01%7C%7Cf387ce2c794d4e68d3e108d759318ccc%7C84df9e7fe9f640afb435%7C1%7C0%7C637075941655510312sdata=nSLzErDuiZ6F0w5PD5WQLwobi3xqjvl6o9iu06daywo%3Dreserved=0
___
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: FreeIPA new network with DNS

2019-10-17 Thread Angus Clarke via FreeIPA-users
My guess is that you have the domain "intra.example.com" listed in the "search" 
order found in /etc/resolv.conf on server ipa1 but not on server mahavishnu.

Regards
Angus



From: Jason Dunham via FreeIPA-users 
Sent: Thursday, 17 October 2019, 20:31
To: freeipa-users@lists.fedorahosted.org
Cc: Jason Dunham
Subject: [Freeipa-users] Re: FreeIPA new network with DNS

Okay I am making some progress with this, currently just trying to get one 
server running before I add any failover. Thanks for the help so far.
Currently the freeipa server "ipa1" (ipa1.intra.example.com) seems to be 
working it can resolve hosts on the LAN either with a short hostname or a fqdn 
hostname.

[root@ipa1 ~]# nslookup
> frisell
Server: 127.0.0.1
Address:127.0.0.1#53

Name:   frisell.intra.example.com
Address: 10.1.10.193
> frisell.intra.example.com
Server: 127.0.0.1
Address:127.0.0.1#53

Name:   frisell.intra.example.com
Address: 10.1.10.193
>
==> so far so good.
However on another computer on the network, the same thing doesn't work even 
though it is asking the same DNS server (10.1.10.15 = ipa1)

jdunham@mahavishnu:~$ nslookup
> ipa1
Server: 10.1.10.15
Address:10.1.10.15#53

** server can't find ipa1: NXDOMAIN
> ipa.intra.example.com
Server: 10.1.10.15
Address:10.1.10.15#53

** server can't find ipa.intra.example.com: NXDOMAIN
> ipa1.intra.example.com
Server: 10.1.10.15
Address:10.1.10.15#53

Name:   ipa1.intra.example.com
Address: 10.1.10.15
> frisell
Server: 10.1.10.15
Address:10.1.10.15#53

** server can't find frisell: NXDOMAIN
> frisell.intra.example.com
Server: 10.1.10.15
Address:10.1.10.15#53

Name:   frisell.intra.example.com
Address: 10.1.10.193

It this a client problem or a server problem?
___
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://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2Fdata=02%7C01%7C%7Cd3db1a8944d7475bbf3708d75330321f%7C84df9e7fe9f640afb435%7C1%7C0%7C637069338769855610sdata=FNGMsq8s5Ti79oQsN3emazO7wUBCoa7qlvoJjmwEMqU%3Dreserved=0
List Guidelines: 
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FMailing_list_guidelinesdata=02%7C01%7C%7Cd3db1a8944d7475bbf3708d75330321f%7C84df9e7fe9f640afb435%7C1%7C0%7C637069338769865615sdata=YHm%2Fsuj5J6IRjPOleKcBO5imACpqO5RhSBOBF2nuRxc%3Dreserved=0
List Archives: 
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fedorahosted.org%2Farchives%2Flist%2Ffreeipa-users%40lists.fedorahosted.orgdata=02%7C01%7C%7Cd3db1a8944d7475bbf3708d75330321f%7C84df9e7fe9f640afb435%7C1%7C0%7C637069338769865615sdata=VDJcynACuL32x7s4rzl0jnZmpsJMXwVRot7CEz9ROYE%3Dreserved=0

___
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] Remove stale server entry from LDAP

2019-10-04 Thread Angus Clarke via FreeIPA-users
Hi all

After decommissioning 2 IPA servers some time back (reduced from 8 to 6) I 
recently noticed that one of the decommissioned servers still appears when 
issuing commands like "ipa server-find." It only appears on 2 of the existing 
servers, not the other 4.

"ipa server-del" and "ipa-replica-manage del" both report "server not found" 
for the decomm'ed server entry, when issued on any of the 6 IPA servers.

So I suspect I have some stale LDAP entry left behind from the decommission 
process (I forget exactly what process I followed, it was over a year ago) and 
was thinking about deleting that entry from LDAP.

Not having much familiarity with LDAP, I found a post here from the venerable 
Rob which tells me how to find such entries (with a bit of fumbling with grep!) 
and indeed I see the entry on the 2 IPA servers but not the other 4.
https://www.redhat.com/archives/freeipa-users/2015-December/msg00089.html


[root@ipa6 ~]# ldapsearch -Y GSSAPI -b cn=computers,cn=accounts,dc=dom 
"krbprincipalkey=*" dn 2>/dev/null | grep ipa7.example.dom
# ipa7.example.dom + 9554ab01-42e811e8-a6dce53f-3a18cb6e, computers, acc
dn: fqdn=ipa7.example.dom+nsuniqueid=9554ab01-42e811e8-a6dce53f-3a18cb6


Assuming this is the right thing to do, I could do with some advice on how to 
delete this entry from the 2 LDAP servers.

Thanks in advance
Angus
___
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: Manually join machines in stateless environment

2019-09-26 Thread Angus Clarke via FreeIPA-users
Hmm, yes I see the problem, when a previously registered node reboots, all the 
local configuration is lost however it still has entries in IPA server.

I've not tried running ipa-client-install on such a node but it sounds like you 
have and the --force option is achieving what you desire.

Alternatively, you could identify all the configuration files that the 
ipa-client-install command updates locally and move them to some stateful 
filesystem (NFS for example) and sym-link back (I'm just thinking out loud - 
I've successfully done such things on other topics before now!) From memory, 
you would need at least:

/etc/krb5.conf
/etc/krb5.keytab
/etc/ipa/default.conf
/etc/sssd/sssd.conf

I'm keeping in mind that the DNS is still correct as per the original names 
initially registered in IPA ...



You can create a separate account for registering/adding hosts to IPA with 
restricted privileges to do just that.

Regards
Angus


From: Vinícius Ferrão via FreeIPA-users 
Sent: 26 September 2019 01:20
To: Rob Crittenden 
Cc: FreeIPA users list ; Alexander 
Bokovoy ; Florence Blanc-Renaud ; 
Vinícius Ferrão 
Subject: [Freeipa-users] Re: Manually join machines in stateless environment



On 25 Sep 2019, at 17:41, Rob Crittenden 
mailto:rcrit...@redhat.com>> wrote:

Vinícius Ferrão wrote:
Hello,

First of all thanks for everyone helping out. Answers inline.

On 24 Sep 2019, at 20:48, Rob Crittenden 
mailto:rcrit...@redhat.com>
> wrote:

Vinícius Ferrão via FreeIPA-users wrote:
Hello all,

On 23 Sep 2019, at 12:59, Alexander Bokovoy 
mailto:aboko...@redhat.com>

> wrote:

On Mon, 23 Sep 2019, Vinícius Ferrão via FreeIPA-users wrote:
Florence and Angus, thanks for the replies.

xCAT definitely can run scripts at boot time. And the kickstart
method seems to be the way to go. But I sill have some questions:

The nodes are stateless, so in a reboot all the configuration is lost
and get back from the image. FreeIPA configuration will be lost and
then restarted. Which appears to be ok. But there are two issues:

* The password for “joining” the FreeIPA domain that expires after
the first use
* The necessity of the hostname on the ipa-client-install command:
hostname=client.example.com
>
 

>>
>

With this two things I think we are unable to move forward, so the
first question is:

1. Do I really need this password? Or better, the password can be
permanent? It’s a “closed” system, so in terms of security I think
there’s no problem.
Please check ipa-client-install manual page. It has all explanations for
methods of enrollment. You can create a special user that has privileges
to create machines and enroll them and record the user's credentials in
the kickstart file.

I was worried about the RTM but I really can’t find the exact answer.
That’s why I came to the list. Searching a little but further, I came
across the Forced Re-enrollment page and I think you’re mentioning this
one, right? 
https://www.freeipa.org/page/V3/Forced_client_re-enrollment

But in this page it says about the OTP to primary join the FreeIPA
domain, but I can’t use another OTP to do the re-enrollment. Is this
expected?

Did you get an error about unenrolling? You probably need to call
host-disable to mark it as unenrolled, 

[Freeipa-users] Re: log dispatching for IPA servers

2019-09-24 Thread Angus Clarke via FreeIPA-users
Hi

If you just want an audit trail of the FreeIPA server(s) API, then apache's 
ErrorLog directive catches all that.

Regards
Angus


From: Fraser Tweedale via FreeIPA-users 
Sent: 24 September 2019 11:08
To: Nazan CENGİZ ; 
freeipa-users@lists.fedorahosted.org 
Cc: Fraser Tweedale 
Subject: [Freeipa-users] Re: log dispatching for IPA servers

Hi Nazan,

I'm not sure what are the best practices for log dispatching on IPA
servers, or what is suitable for your customer's environment and
requirement.  I assume the customer is running RHEL and therefore
wants the solution to only use supported components.  Adding
freeipa-users@ for a wider audience.

Cheers,
Fraser

On Tue, Sep 24, 2019 at 07:50:14AM +, Nazan CENGİZ wrote:
> Hi Fraser,
>
>
> I working 5G project in Turkey. Redhat supported me for Openstack 13.
>
>
> We install FreeIPA. We wanted log monitoring on FreeIPA server and clients.I 
> think it should Kibana,Elasticsearch and fluentd.
>
>
> I see 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsysadmin.miniconf.org%2F2018%2Flca2018-fraser_tweedale-user_session_recording_for_the_enterprise.pdfdata=02%7C01%7C%7Cf4b7f1d30dc74455af7c08d740ced294%7C84df9e7fe9f640afb435%7C1%7C0%7C637049129351734102sdata=L7bOEDFlQlY3aVETpmb75ThT6C2UStx0yDU8IWXE%2BpQ%3Dreserved=0.
>
>
> But I don't know installing on FreeIPA server and clients.Where is installed 
> fluentd on IPA server and clients?
>
>
> I following 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmzamora9913%2FCollecting-Syslogs-from-FreeIPA-and-clients-using-ELK-Stackdata=02%7C01%7C%7Cf4b7f1d30dc74455af7c08d740ced294%7C84df9e7fe9f640afb435%7C1%7C0%7C637049129351734102sdata=EsggaTyZ4hRSOPg3lnUocvPrWqDAVj4lZ%2BM7dzTqUwA%3Dreserved=0
>  but It not answer the questions.
>
>
> Could you please help me?
>
>
> Best Regards,
>
>
> Nazan.
>
>
> [cid:image556c62.PNG@8bf41986.459c739a]
>  [cid:imageb02311.JPG@73a7601e.418b1956]
> Nazan CENGİZ
> AR-GE MÜHENDİSİ
> Mustafa Kemal Mahallesi 2120 Cad. No:39 06510 Çankaya Ankara TÜRKİYE
> [cid:imagea8935c.PNG@9a2bfb11.4c8dd354] +90 312 219 57 87   
> [cid:image2cbf6d.PNG@6b6c6178.42ba3343] +90 312 219 57 97
>
>
> [cid:image67d26a.JPG@1a093bf4.45953fd9]
> YASAL UYARI: Bu elektronik posta işbu linki kullanarak ulaşabileceğiniz Koşul 
> ve Şartlar dokümanına tabidir. 
> 
> LEGAL NOTICE: This e-mail is subject to the Terms and Conditions document 
> which can be accessed with this link. 
> 
>
> [https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.havelsan.com.tr%2FLibrary%2Fimages%2Fmail%2Femail.jpgdata=02%7C01%7C%7Cf4b7f1d30dc74455af7c08d740ced294%7C84df9e7fe9f640afb435%7C1%7C0%7C637049129351744107sdata=i9p35mtgX3b7jpGUhnG2Lqzm%2BN%2BM2IHJtlzqagUTQsM%3Dreserved=0]
>   Lütfen gerekmedikçe bu sayfa ve eklerini yazdırmayınız / Please 
> consider the environment before printing this email
>
>





___
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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2Fdata=02%7C01%7C%7Cf4b7f1d30dc74455af7c08d740ced294%7C84df9e7fe9f640afb435%7C1%7C0%7C637049129351744107sdata=M%2F0jvtCwsWK%2B2k5Nbx8VlULxLTqVGAxc17kN1yqevmk%3Dreserved=0
List Guidelines: 
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FMailing_list_guidelinesdata=02%7C01%7C%7Cf4b7f1d30dc74455af7c08d740ced294%7C84df9e7fe9f640afb435%7C1%7C0%7C637049129351744107sdata=izgzD56RjXMSoX7sjBkq28u7VByO3HSpYcByk%2FXXwhw%3Dreserved=0
List Archives: 

[Freeipa-users] Re: Manually join machines in stateless environment

2019-09-23 Thread Angus Clarke via FreeIPA-users
Hi

Perhaps some boot script to run the ipa-client-install command when a new 
instance boots up? I'm not sure how the system would behave if you run the 
ipa-client-install command multiple times, should the same machine name boots 
more than once.

For HBAC rules you can use "auto-member" to automatically put new hosts into 
particular host groups for which you would have existing HABC rules.

Regards
Angus




From: Vinícius Ferrão via FreeIPA-users 
Sent: 23 September 2019 01:10
To: freeipa-users@lists.fedorahosted.org 
Cc: Vinícius Ferrão 
Subject: [Freeipa-users] Manually join machines in stateless environment

Hello, the subject of the message may sound a little bit strange, but let me 
explain what I’m trying to do.

I have a machine with an provisioner (xCAT) that is able to boot and control 
different types of computer nodes. A stateless node is just a machine that 
boots over the network from a shared image on the server.

What I’m trying to do?

Join those stateless nodes to FreeIPA Server.

To do this, I’m aware that I can’t just run freeipa-client-install on the image 
chroot, since it will not behave as expected.

At this point xCAT (the provisioner) can create the DNS registers of the 
stateless nodes on FreeIPA integrated DNS (using TSIG keys). But I need to 
properly join the nodes to the server.

There’s a way to manually register the nodes on the server?
And about the users? How to enable them? Just Configure SSSD on the image and 
it should be fine?
The certificates, client certificates and things like this? There’s something 
that I need to do?
Automount?

Any help is really appreciated.

Thanks,


___
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: remove bad replica from list not working

2019-09-20 Thread Angus Clarke via FreeIPA-users
Hi

A bit late I realise but I noticed ...

https://www.freeipa.org/page/Domain_Levels
(# ipa domainlevel-get)
IPA 4.5 is likely domain level 1. According to the ipa-replica-del man page:

<-- snip
To manage IPA replication agreements in a domain at domain level 1, use IPA CLI 
or Web UI, see `ipa help topology` for additional information.
<-- snip

When I decommissioned a site recently with 2 IPA servers, I followed this 
advice and ended up using this command from a remote  IPA server:

# ipa server-del 

Which initially threw errors, giving very specific messages about how 
replication would fail due to missing topology agreements should the server 
removal carry on, allowing me to sort those agreements out separately. Once all 
the agreements were in place to support the removal of the server, the command 
removed all topology agreements related to this server and then deleted the 
server altogether.

In our environment, one of the the servers to be decomm'ed was the CA renewal 
server so I had to move that first - these are tasks I perform very rarely 
(once so far!) and have little knowledge of - all the tools worked really well, 
I went home on time and slept well!

Regards
Angus


From: Satish Patel via FreeIPA-users 
Sent: 20 September 2019 02:51
To: FreeIPA users list 
Cc: Dmitry Perets ; Satish Patel 
Subject: [Freeipa-users] Re: remove bad replica from list not working

You are awesome!!!

ipa topologysegment-del works!! and i am successfully able to remove bad replica

On Thu, Sep 19, 2019 at 6:08 PM Dmitry Perets via FreeIPA-users
 wrote:
>
> Hi,
>
> Try using these, to delete replication agreements:
>
> ipa topologysegment-find
> ipa topologysegment-del
>
> Then you can repeat "ipa-replica-manage del".
>
> ---
> Regards,
> Dmitry Perets
> ___
> 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://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2Fdata=02%7C01%7C%7C75dcabdc56244c481c0d08d73d64d455%7C84df9e7fe9f640afb435%7C1%7C0%7C637045375572764530sdata=2YUtKQmQRWbWV1VqmeXI%2BJOWeH0CE47TvAVIUKA6iA8%3Dreserved=0
> List Guidelines: 
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FMailing_list_guidelinesdata=02%7C01%7C%7C75dcabdc56244c481c0d08d73d64d455%7C84df9e7fe9f640afb435%7C1%7C0%7C637045375572764530sdata=LdSnouDrzXBuQoxHZGmb%2BF8lpqekBbyz%2B%2F96f1RbJp0%3Dreserved=0
> List Archives: 
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fedorahosted.org%2Farchives%2Flist%2Ffreeipa-users%40lists.fedorahosted.orgdata=02%7C01%7C%7C75dcabdc56244c481c0d08d73d64d455%7C84df9e7fe9f640afb435%7C1%7C0%7C637045375572764530sdata=NsD4oDjziW4J4WVA2Aj0FM8ewa7ewuiSj6RZqkJa3Io%3Dreserved=0
___
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://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2Fdata=02%7C01%7C%7C75dcabdc56244c481c0d08d73d64d455%7C84df9e7fe9f640afb435%7C1%7C0%7C637045375572774543sdata=8jgo%2BPzx9oGIlbj5R%2Bw9qnTn3knwg%2FIDFqoYzhqzyGw%3Dreserved=0
List Guidelines: 
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FMailing_list_guidelinesdata=02%7C01%7C%7C75dcabdc56244c481c0d08d73d64d455%7C84df9e7fe9f640afb435%7C1%7C0%7C637045375572774543sdata=bYspsbSYEYMunM3wKmN%2FanSkoST1p8xkCIQ4WGcunIo%3Dreserved=0
List Archives: 
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fedorahosted.org%2Farchives%2Flist%2Ffreeipa-users%40lists.fedorahosted.orgdata=02%7C01%7C%7C75dcabdc56244c481c0d08d73d64d455%7C84df9e7fe9f640afb435%7C1%7C0%7C637045375572774543sdata=h%2FMKtEnCUN4vTvdjRraYK7HLanOgczGlmpV1eb%2BbMR4%3Dreserved=0
___
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: ipausers unable to sudo

2019-09-09 Thread Angus Clarke via FreeIPA-users
Hi Albert

I use sss_cache to drop a client's cache when testing some change I've applied.

sss_cache -E to drop all cache.

Take a look at the man page for other options.

Regards
Angus




From: Albert Szostkiewicz via FreeIPA-users 

Sent: Monday, September 9, 2019 5:42:37 PM
To: freeipa-users@lists.fedorahosted.org 
Cc: Albert Szostkiewicz 
Subject: [Freeipa-users] Re: ipausers unable to sudo

while I was checking logs and runnign services, Sudo suddenly started working. 
So I guess it was a caching issue.
How can I enforce re-caching ?

It's already working now, but just in case if you see something odd, here is my 
sssd_$domain.log , those line are just repeating

[sssd[be[home.mydomain.com]]] [talloc_log_fn] (0x0010): talloc: access after 
free error - first free may be at src/providers/ipa/ipa_session.c:846
[sssd[be[home.mydomain.com]]] [talloc_log_fn] (0x0010): Bad talloc magic value 
- access after free
[sssd[be[home.mydomain.com]]] [orderly_shutdown] (0x0010): SIGTERM: killing 
children
[sssd[be[home.mydomain.com]]] [talloc_log_fn] (0x0010): Bad talloc magic value 
- unknown value

Thanks!
___
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: kadmin service fails to start

2019-09-03 Thread Angus Clarke via FreeIPA-users
Hi Mike

It's prolly too late but you could have tried this as root to identify which 
process had port 749 open:

netstat -pan | grep LISTEN | grep 749

Regards
Angus


From: Mike Conner via FreeIPA-users 
Sent: Wednesday, September 4, 2019 5:35:57 AM
To: freeipa-users@lists.fedorahosted.org 
Cc: Mike Conner 
Subject: [Freeipa-users] Re: kadmin service fails to start

I decided to reboot the master and the services came back up without a problem. 
Is it likely I was experiencing the bug that I linked earlier, and that just 
restarting the rpcbind service isn't enough to free the port for kadmin to use?
___
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: Disabled user accounts

2019-08-22 Thread Angus Clarke via FreeIPA-users
> You can rename accounts with
>
> ipa user-mod --rename
Thanks for the tip Alex

> How did you disable it? 'ipa user-disable'? This just leaves this user
> in the tree and marks its account not possible to use for
> authentication.
Most likely one of my guys disabled accounts via the web interface.

Regards
Angus


From: Alexander Bokovoy 
Sent: 22 August 2019 10:04
To: FreeIPA users list 
Cc: Angus Clarke 
Subject: Re: [Freeipa-users] Disabled user accounts

On to, 22 elo 2019, Angus Clarke via FreeIPA-users wrote:
>Hi all
>
>Just an observation really, some of our users complained that their IdM
>login names did not match other systems' - we saw IdM as the easiest
>place to fix this (as opposed to modifying local accounts on hundreds
>of none-IdM enabled *nix boxes around the estate)

You can rename accounts with

ipa user-mod --rename

$ ipa user-mod some-user --rename=another-user
-
Modified user "some-user"
-
  User login: another-user



>Rightly or wrongly, the approach we took was to disable angusc account
>and add new account aclarke using the same UID number.
How did you disable it? 'ipa user-disable'? This just leaves this user
in the tree and marks its account not possible to use for
authentication.

>One of our users spotted this happening occasionally:
>
>
>[aclarke@orabledb ~]$ id
>uid=1234(angusc) gid=1234(aclarke) groups=1234(aclarke),2345(dbas)
>
>We're now deleting the disabled accounts from IdM.
>
>$ rpm -q ipa-server
>ipa-server-4.6.4-10.0.1.el7_6.3.x86_64

--
/ 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] Disabled user accounts

2019-08-22 Thread Angus Clarke via FreeIPA-users
Hi all

Just an observation really, some of our users complained that their IdM login 
names did not match other systems' - we saw IdM as the easiest place to fix 
this (as opposed to modifying local accounts on hundreds of none-IdM enabled 
*nix boxes around the estate)

Rightly or wrongly, the approach we took was to disable angusc account and add 
new account aclarke using the same UID number.

One of our users spotted this happening occasionally:


[aclarke@orabledb ~]$ id
uid=1234(angusc) gid=1234(aclarke) groups=1234(aclarke),2345(dbas)

We're now deleting the disabled accounts from IdM.

$ rpm -q ipa-server
ipa-server-4.6.4-10.0.1.el7_6.3.x86_64

Regards
Angus
___
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: Windows Integration - Using SSH Without Passwords

2019-05-23 Thread Angus Clarke via FreeIPA-users
I suspect OP is enquiring about ssh keys.

You need to tell your SSH client about your SSH private key (keep it safe) and 
paste the public component of your key pair into the SSH key field in the 
FreeIPA web admin screen for the user (the field is about a third of the way 
down the screen on the right.)

Each user needs their own SSH key pairs, they can be generated by running:

ssh-keygen

use -t to specify the type of key to create (ed25519 is the latest and greatest 
but not supported on systems prior to Centos 7.3 or thereabouts, if in doubt 
specify "dsa")

Regards
Angus

> On 23 May 2019 at 15:56 Rob Crittenden via FreeIPA-users 
>  wrote:
> 
> 
> lejeczek via FreeIPA-users wrote:
> > hi guys,
> > 
> > reading official guide one may assume - I do - that "Using SSH Without
> > Passwords" should work out-of-box (centos 7.6) - is such assumption valid?
> > 
> > For me this does not work - ssh still asks for passwords.
> > 
> > If this is due to some failure/problem, then where to look and how to
> > troubleshoot?
> It's hard to know what you're doing, ssh from where to where, using what?
> 
> rob
> ___
> 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 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: secure freeipa exposed to internet

2019-05-23 Thread Angus Clarke via FreeIPA-users
Hello

Best practises say to deploy 2 - 3 IPA server per site (Deployment 
Recommendations) however I've never really understood why. We run 2 IPA servers 
in each of our primary DCs and then connect our smaller remote sites to those 
IPA servers over IPSEC VPNs. For example, IPA clients in a small site in Italy 
connect to an IPA server in London and an IPA server in Paris (I haven't yet 
looked at service discovery.)

Regards
Angus


> On 22 May 2019 at 22:46 Alex Corcoles via FreeIPA-users 
>  wrote:
> 
> 
> Well, in that scenario site-to-site VPNs should not be too terrible (AWS 
> provides one, for instance).
> 
> I think that certainly having a default install which is "safe" to 
> expose to the Internet would be a very nice feature. However, I realize 
> that has its cost and maybe its drawbacks, so of course I'm not sure if 
> it's the best use of development time for the project.
> 
> I can say that it would be one of the top items in my features wishlist 
> for FreeIPA*, but then again I'm neither a typical, nor paying, nor 
> particularly smart customer, so I'm just talking here and I don't think 
> I should be listened much. I think VPNs also have a cost, so not having 
> to setup them up and maintain them is a huge plus in my book.
> 
> Cheers,
> 
> Álex
> 
> * the other two would be very low effort monitoring (e.g. a built-in 
> health check URL or command line tool included in the default install) 
> and low effort full backup/restore + recovery.
> 
> On 5/22/19 6:42 PM, Stepan Vardanyan via FreeIPA-users wrote:
> > See this image to have basic understanding of our infrastructure - 
> > https://imgur.com/a/R5c8BWW
> > ___
> > 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 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 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] RSA using FreeIPA as an identity source

2018-11-22 Thread Angus Clarke via FreeIPA-users
Hi all

Excuse my ignorance, can anyone give me some pointers on getting RSA
Authentication Manager 8 to use FreeIPA 4.5 as an identity source over
LDAPS?

Many thanks
Angus
___
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: Changing domain name

2018-08-17 Thread Angus Clarke via FreeIPA-users
You might find some useful tips here:

https://www.redhat.com/archives/freeipa-users/2014-May/msg00158.html

Not sure if they did drop their other scripts into github (as suggested two
thirds down)

Regards
Angus


On 17 August 2018 at 10:09, Alfredo De Luca via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:

> Hi Rob. It worked. Thanks.
> It was confusing for me the name *migrated *thinking was the new host
> rather than the *"old"* .
> Now users/groups are there and whoever has the password needs to connect
> to the new server in order to recreate their password with kerberos. I
> guess who has the ssh keys don't need to to that...right?
>
> Now I need to migrate manually the hbac,sudo etc
>
> Thanks
>
>
> On Thu, Aug 16, 2018 at 4:00 PM Alfredo De Luca 
> wrote:
>
>> Thanks Rob. I ll give a try.
>> CHeers
>>
>> On Thu, Aug 16, 2018 at 2:31 PM Rob Crittenden 
>> wrote:
>>
>>> Alfredo De Luca via FreeIPA-users wrote:
>>> > Hi Florence.
>>> > But the example says  ldap://*migrated*.freeipa.server.test
>>> >
>>> > so I ran the command from the actual server where I want migrate the
>>> > users from and pointing to the migrated (so the new which I will
>>> migrate
>>> > to) server...
>>> > So is it wrong?
>>> > So should I run the command instead fron the new ipa server pointing to
>>> > the old server?
>>>
>>> The old server. You have been trying to migrate the server to itself.
>>>
>>> rob
>>>
>>> >
>>> >
>>> >
>>> > On Thu, Aug 16, 2018 at 1:02 PM Florence Blanc-Renaud >> > > wrote:
>>> >
>>> > On 08/16/2018 12:37 PM, Alfredo De Luca via FreeIPA-users wrote:
>>> > > The IP is the new server where I'd like to migrate all the
>>> > user/groups
>>> > > to and it  should be ok.
>>> > > The migrate-ds is the default I copy from the freeipa.org
>>> > 
>>> > >  migration section..
>>> > >
>>> > Hi,
>>> >
>>> > the ldap URI should point to the server where the users are
>>> currently
>>> > defined (=the FROM server).
>>> >
>>> > Hope this clarifies,
>>> > flo
>>> > >
>>> > >
>>> > >
>>> > > On Tue, Aug 14, 2018 at 7:00 PM Rob Crittenden
>>> > mailto:rcrit...@redhat.com>
>>> > > >>
>>> wrote:
>>> > >
>>> > > Alfredo De Luca via FreeIPA-users wrote:
>>> > >  > Hi Rob.
>>> > >  > Yes. I am following the link you sent. So now I can
>>> understand
>>> > > they need
>>> > >  > to create the new Kerberos but given the command I should
>>> have
>>> > > seen all
>>> > >  > the users in the new freeipa server... which are not
>>> there.
>>> > >  > Maybe I put a wrong command? (below)
>>> > >  >
>>> > >  > ipa migrate-ds --bind-dn="cn=Directory Manager"
>>> > >  > --user-container=cn=users,cn=accounts
>>> --group-overwrite-gid
>>> > >  > --group-container=cn=groups,cn=accounts
>>> > > --group-objectclass=posixgroup
>>> > >  >
>>> > >
>>> >  --user-ignore-attribute={krbPrincipalName,krbextradata,
>>> krblastfailedauth,krblastpwdchange,krblastsuccessfulauth,
>>> krbloginfailedcount,krbpasswordexpiration,krbticketflags,
>>> krbpwdpolicyreference,mepManagedEntry}
>>> > >  > --user-ignore-objectclass=mepOriginEntry --with-compat
>>> > >  > ldap://192.168.20.177:389 
>>> > 
>>> > > 
>>> > >  >
>>> > >  > Password:
>>> > >  > ---
>>> > >  > migrate-ds:
>>> > >  > ---
>>> > >  > Migrated:
>>> > >  >   group: admins, editors
>>> > >  > Failed user:
>>> > >  >   admin: This entry already exists
>>> > >  > Failed group:
>>> > >  > --
>>> > >  > Passwords have been migrated in pre-hashed format.
>>> > >  > IPA is unable to generate Kerberos keys unless provided
>>> > >  > with clear text passwords. All migrated users need to
>>> > >  > login at https://your.domain/ipa/migration/ before they
>>> > >  > can use their Kerberos accounts.
>>> > >
>>> > > It isn't finding any of your users. Are you sure that IP
>>> > address points
>>> > > to your existing IPA instance?
>>> > >
>>> > > rob
>>> > >
>>> > >
>>> > >
>>> > > --
>>> > > /Alfredo/
>>> > >
>>> > >
>>> > >
>>> > > ___
>>> > > 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-
>>> 

[Freeipa-users] Re: [BLOG] Replacing a lost or broken CA in FreeIPA

2018-05-31 Thread Angus Clarke via FreeIPA-users
Thanks Fraser!

On 31 May 2018 at 09:29, Fraser Tweedale via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:

> My latest blog post looks at how to clean up and install a *new* CA
> within an existing FreeIPA deployment.  This handles scenarios were
> a CA installation has failed, or the original CA has been lost (e.g.
> all CA replicas decommissioned).
>
> Enjoy!  As usual, I am keen for whatever feedback or questions you
> might have.
>
> https://frasertweedale.github.io/blog-redhat/posts/2018-05-
> 31-replacing-lost-ca.html
>
> Thanks,
> Fraser
> ___
> 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-
> us...@lists.fedorahosted.org/message/2UZYBLY6COYR3F3JNZVXKLOTZBZXCH6L/
>
___
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/OBRFSX55G6M52SMSOTMJEUHANLIVF4HL/


[Freeipa-users] Re: Overall users experience with Free-IPA

2018-05-08 Thread Angus Clarke via FreeIPA-users
Main gripe (which doesn't have any plans for resolution) - no facility for
read-only replicas in untrusted sites.

On 8 May 2018 at 12:04, Angus Clarke  wrote:

> Hi Duncan
>
> A few things I've learned:
>
> Understand how replication agreements work as part of your planning.
>
> Choose a suitable location for the live CA server.
>
> Deploy a replica by promoting an sssd client. Unless you have a reason not
> to, always use --setup-ca to the ipa-replica-install command to give the
> flexibility of having any of your replicas take over the role of CA if
> needed (we've certainly moved our CA from site to site before now)
>
> I wish I'd setup DNS within FreeIPA and had a mini DNS domain just for the
> FreeIPA systems themselves. We implemented our original IPAs into our
> existing DNS at site1, now when deploying replicas in site 2 - that has an
> existing, different DNS domain - we've had to extend the DNS of site 1 into
> site 2 just for the replicas there in site 2. So now we have nodes in site
> with DNS names used only in site 1 - this will only spread more and more as
> we extend into other sites. FreeIPA servers must be in the same DNS domain,
> that's all. sssd clients can be in any DNS domain.
>
> Best practises recommend to have at least 2 IPA replicas per site, however
> due to network constraints (I think promoting a sssd client to a replica
> requires connectivity to all other replicas, however one of our sites with
> working replicas is not reachable from this remote site) we have an entire
> remote site connecting to 2 IPA servers in 2 other locations, each location
> having its own IPSEC tunnel to the remote site - so far this works really
> well.
>
> Overall, a good experience, the ssh-key/sudo/hbac facilities are
> excellent. sssd on the clients is really good too, completely replaces
> legacy tools like nscd (woohoo!)
>
> Regards
> Angus
>
>
>
>
>
>
> On 8 May 2018 at 11:23, Duncan Colhoun via FreeIPA-users <
> freeipa-users@lists.fedorahosted.org> wrote:
>
>> Hi All
>>
>> I hope this is the appropriate forum for this question.
>>
>> Can I get some feedback on the overall experience setting up and running
>> Free-IPA. I am looking at implementing Free-IPA to enhance/replace an
>> OpenLDAP environment.
>>
>> So please share any horror/success stories.
>>
>> Rgds
>>
>> Duncan
>> ___
>> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>> To unsubscribe send an email to freeipa-users-le...@lists.fedo
>> rahosted.org
>>
>
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] Re: Overall users experience with Free-IPA

2018-05-08 Thread Angus Clarke via FreeIPA-users
Hi Duncan

A few things I've learned:

Understand how replication agreements work as part of your planning.

Choose a suitable location for the live CA server.

Deploy a replica by promoting an sssd client. Unless you have a reason not
to, always use --setup-ca to the ipa-replica-install command to give the
flexibility of having any of your replicas take over the role of CA if
needed (we've certainly moved our CA from site to site before now)

I wish I'd setup DNS within FreeIPA and had a mini DNS domain just for the
FreeIPA systems themselves. We implemented our original IPAs into our
existing DNS at site1, now when deploying replicas in site 2 - that has an
existing, different DNS domain - we've had to extend the DNS of site 1 into
site 2 just for the replicas there in site 2. So now we have nodes in site
with DNS names used only in site 1 - this will only spread more and more as
we extend into other sites. FreeIPA servers must be in the same DNS domain,
that's all. sssd clients can be in any DNS domain.

Best practises recommend to have at least 2 IPA replicas per site, however
due to network constraints (I think promoting a sssd client to a replica
requires connectivity to all other replicas, however one of our sites with
working replicas is not reachable from this remote site) we have an entire
remote site connecting to 2 IPA servers in 2 other locations, each location
having its own IPSEC tunnel to the remote site - so far this works really
well.

Overall, a good experience, the ssh-key/sudo/hbac facilities are excellent.
sssd on the clients is really good too, completely replaces legacy tools
like nscd (woohoo!)

Regards
Angus






On 8 May 2018 at 11:23, Duncan Colhoun via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:

> Hi All
>
> I hope this is the appropriate forum for this question.
>
> Can I get some feedback on the overall experience setting up and running
> Free-IPA. I am looking at implementing Free-IPA to enhance/replace an
> OpenLDAP environment.
>
> So please share any horror/success stories.
>
> Rgds
>
> Duncan
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] ipa-replica-install CA_REJECTED

2018-04-19 Thread Angus Clarke via FreeIPA-users
Hello

We've failed to deploy a replica in a remote DC, initially the CA Master
(ipa_server1) was in a location that this remote DC could not reach so I
moved the CA to a contactable IPA server in another location (ipa_server2.)

I still receive CA_REJECTED however and I suspect we may have hit
https://bugzilla.redhat.com/show_bug.cgi?id=1498523 as the previous week, a
colleague of mine rebuilt all of our existing IPA deployment using the
Damascus Group export/import scripts (his task was to migrate from SUSE
Linux to Oracle Linux and upgrade IPA to 4.5.0) If we have hit this issue,
I do not feel comfortable carrying out the steps Flo mentions in #c24.
'ipa-getcert list' certainly shows the remote ipa install trying to connect
to itself for certificates.


After moving the CA Master to ipa_server2 (contactable) we get the same
result as before for ipa-getcert list, but also notice an INFO message when
running the ipa-replica-install command in the remote DC.

==

INFO Waiting up to 300 seconds to see our keys appear on host: ipa_server1
(the un-contactable one)

==


I thought connections between IPA servers were only required along
replication agreement paths, this INFO message suggests we might need
connectivity between all nodes - perhaps it's just during the install
process - I'm unsure.



So we've opted to connect the sssd clients in the remote DC to IPA servers
in our 2 main DCs, which goes against best practises of having at least 2
IPA servers per DC. I will connect the clients to an IPA server in DC1 and
another IPA server in DC2 as each DC has a VPN tunnel connecting to the
remote site. The rhel7 documentation does not explain why best practises
requires at least 2 IPAs per DC - any thoughts on this setup and best
practises recommendation?


Thanks for your time.


Regards

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


[Freeipa-users] read only replicants

2018-04-06 Thread Angus Clarke via FreeIPA-users
Hi

Is there way to lock down a FreeIPA replica so that it can only receive
updates but not make changes to other FreeIPA systems.

Some of our environments are considered less secure than others, our
security team are concerned that a FreeIPA in a less secure environment
might become compromised at which point unwarranted changes could be
applied that affect our secure production environments.

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