[Freeipa-users] Re: reliability of external radius

[Charles Hedrick via FreeIPA-users]

ugh. It doesn't look like we can do this until this patch happens. The actual 
authentication would use DUO. Since that requires the user to respond, the 
delay could be significant. 10 sec is definitely not enough.

This looks like a client patch. We're using Ubuntu for our clients. (RHEL for 
the KDCs.) We have purchased support, but the PO is waiting in Purchasing. So I 
may be able to help get it into Ubuntu.

From: Alexander Bokovoy 
Sent: Monday, February 12, 2024 2:45 PM
To: FreeIPA users list 
Cc: Charles Hedrick 
Subject: Re: [Freeipa-users] reliability of external radius

On Пан, 12 лют 2024, Charles Hedrick via FreeIPA-users wrote:
>Currently our department uses passwords in IPA, with a few users using
>OTP. I'm considering using a University radius server for most users.
>Are there reliability implications? My concern is what happens if the
>radius server is slow to respond or even is down. I'd like users with
>accounts in IPA to still work, and I'd hope things would survive
>conditions of slow response.

There is one potential issue that we fixed recently in MIT Kerberos:
https://github.com/krb5/krb5/pull/1318

It is not yet part of any release. If you have RHEL subscription, making
it known to RHEL support organization might help to get this fix out
faster.




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

[Freeipa-users] reliability of external radius

[Charles Hedrick via FreeIPA-users]

Currently our department uses passwords in IPA, with a few users using OTP. I'm 
considering using a University radius server for most users. Are there 
reliability implications? My concern is what happens if the radius server is 
slow to respond or even is down. I'd like users with accounts in IPA to still 
work, and I'd hope things would survive conditions of slow response.

--
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: possible issue with ipa-backup on RHEL 9.3

[Charles Hedrick via FreeIPA-users]

A bit more info. Looking at errors, a normal backup terminates with

[20/Dec/2023:23:01:32.943228301 -0500] - INFO - archive_copyfile - Copying 
/etc/dirsrv/slapd-CS-RUTGERS-EDU/pwdfile.txt to /var/lib/dirsrv/slapd-\
CS-RUTGERS-EDU/bak/CS-RUTGERS-EDU/config_files/pwdfile.txt
[20/Dec/2023:23:01:32.957342035 -0500] - INFO - archive_copyfile - Copying 
/etc/dirsrv/slapd-CS-RUTGERS-EDU/certmap.conf to /var/lib/dirsrv/slapd\
-CS-RUTGERS-EDU/bak/CS-RUTGERS-EDU/config_files/certmap.conf
[20/Dec/2023:23:01:32.969828971 -0500] - INFO - archive_copyfile - Copying 
/etc/dirsrv/slapd-CS-RUTGERS-EDU/slapd-collations.conf to /var/lib/dir\
srv/slapd-CS-RUTGERS-EDU/bak/CS-RUTGERS-EDU/config_files/slapd-collations.conf
[20/Dec/2023:23:01:32.983763256 -0500] - INFO - task_backup_thread - Backup 
finished.
[2

The backup that hung is missing the last line, "Backup finished." ldap stopped 
giving normal responses about a minute later, according to the access log.

From: Charles Hedrick
Sent: Friday, December 22, 2023 9:56 AM
To: freeipa-users@lists.fedorahosted.org 
Subject: possible issue with ipa-backup on RHEL 9.3

I just upgraded one of three servers from RHEL 9.2. to 9.3. I have a clone of 
our three servers, on which all three have been upgraded to 9.3.

All of the servers run a cron job

/sbin/ipa-backup --online --data > /usr/local/scripts/ipa-backup.log 2>&1

The LDAP server hung (needed kill -9) at about the time that job ran, on the 
production server but not the testing copy. Obviously I can't prove that the 
backup caused the hang, but it's suspicious. I've commented out the cron job, 
since the backup isn't actually all the useful. If we have to restore we'd use 
a snapshot of the VM.

The backup completed successfully on the clone. On the production server it 
failed. Here is the log:

Preparing backup on krb4.cs.rutgers.edu
Local roles match globally used roles, proceeding.
Backing up userRoot in CS-RUTGERS-EDU to LDIF
Waiting for LDIF to finish
Backing up CS-RUTGERS-EDU
Waiting for BAK to finish
cannot connect to 'ldapi://%2Frun%2Fslapd-CS-RUTGERS-EDU.socket':
The ipa-backup command failed. See /var/log/ipabackup.log for more information

I'm wondering whether there's a bug that only happens under load.

We're been doing this in production for years with no trouble up to RHEL 9.2.

--
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] possible issue with ipa-backup on RHEL 9.3

[Charles Hedrick via FreeIPA-users]

I just upgraded one of three servers from RHEL 9.2. to 9.3. I have a clone of 
our three servers, on which all three have been upgraded to 9.3.

All of the servers run a cron job

/sbin/ipa-backup --online --data > /usr/local/scripts/ipa-backup.log 2>&1

The LDAP server hung (needed kill -9) at about the time that job ran, on the 
production server but not the testing copy. Obviously I can't prove that the 
backup caused the hang, but it's suspicious. I've commented out the cron job, 
since the backup isn't actually all the useful. If we have to restore we'd use 
a snapshot of the VM.

The backup completed successfully on the clone. On the production server it 
failed. Here is the log:

Preparing backup on krb4.cs.rutgers.edu
Local roles match globally used roles, proceeding.
Backing up userRoot in CS-RUTGERS-EDU to LDIF
Waiting for LDIF to finish
Backing up CS-RUTGERS-EDU
Waiting for BAK to finish
cannot connect to 'ldapi://%2Frun%2Fslapd-CS-RUTGERS-EDU.socket':
The ipa-backup command failed. See /var/log/ipabackup.log for more information

I'm wondering whether there's a bug that only happens under load.

We're been doing this in production for years with no trouble up to RHEL 9.2.

--
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] aes256-sha2

[Charles Hedrick via FreeIPA-users]

If I wanted to using aes256-sha2 for tickets by default, how would I do that? 
I've verified that our KDC can issue service tickets for that if I specify -e 
aes256-sha2 with ipa-getkeytab, but kinit and everything else seems to use 
older encryptioni types.
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: Plans for integrating DHCP

[Charles Hedrick via FreeIPA-users]

We did most of this, and have been using it for a few years. However it depends 
upon the ISC DHCP server, which is now EOL. The replacement, KEA, does not 
support LDAP, and there are no plans for it to.

I think the reason is that they didn't want to put dynamic addresses in LDAP, 
because LDAP is thought of as read-mostly. The way LDAP is used in IPA, of 
course, means there are lots of changes going on. For most sites, I suspect 
putting leases in LDAP would be OK. But ISC isn't going to help, I don't think.

From: Ellsworth, Nathan Andrew via FreeIPA-users 

Sent: Monday, September 25, 2023 2:09 PM
To: freeipa-users@lists.fedorahosted.org 
Cc: Ellsworth, Nathan Andrew 
Subject: [Freeipa-users] Re: Plans for integrating DHCP


There is an interesting design document already for DHCP with FreeIPA.



https://www.freeipa.org/page/DHCP_Integration_Design
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: Authentication failures on a RHEL 9.2 IPA server

[Charles Hedrick via FreeIPA-users]

I got my test servers working properly. But when I did my first production 
server, I ran into problems that might affect others:

Unlike the test, for the primary migration I wanted to generate SIDs before 
doing the upgrade, to minimize downtime after the upgrade. In testing, I used 
"ipa config-mod --add-sids --enable-sid" on an upgraded (RHEL 9.2) server. It 
worked fine once I got the  necessary idranges set up. However on the 
production service "ipa config-mod --add-sids --enable-sid" was done under RHEL 
9.0 with IPA 4.9.8. It gave an error when there was a UID and GID with the same 
numeric value. In the new version, it used the secondary SID, but not always 
with the old version. I had to set the SIDs manually in some cases.

This is simply a warning for people trying the same thing. Error messages occur 
in /var/log/dirserv/.../errors. There's no sign from the command line of any 
problems.

________
From: Charles Hedrick via FreeIPA-users 
Sent: Monday, May 15, 2023 4:33 PM
To: Rob Crittenden ; FreeIPA users list 

Cc: Sam Morris ; Alexander Bokovoy ; 
Charles Hedrick 
Subject: [Freeipa-users] Re: Authentication failures on a RHEL 9.2 IPA server

ipa id-range-find didn't find the ranges on the other servers after I added 
them on one. It found the primary ranges (managed by ipa-replica-manage) on all 
3 systems, but of course they are different.


From: Rob Crittenden 
Sent: Monday, May 15, 2023 4:15 PM
To: FreeIPA users list 
Cc: Sam Morris ; Alexander Bokovoy ; 
Charles Hedrick 
Subject: Re: [Freeipa-users] Re: Authentication failures on a RHEL 9.2 IPA 
server

Charles Hedrick via FreeIPA-users wrote:
> OK, so I see the answer to my problem is to run
>
> ipa config-mod --add-sids --enable-sid
>
> But we have old UIDs that with low numbers. It looks like I need to do
>
> ipa idrange-add CS.RUTGERS.EDU_low_id_range --base-id=1
> --range-size=20 --rid-base=2 --secondary-rid-base=3
> ipa idrange-add CS.RUTGERS.EDU_mid_id_range --base-id=60
> --range-size=20 --rid-base=4  --secondary-rid-base=5
>
> In order for ipa user-add for those UIDs to work on any system,
> presumably I have to do that on all IPA servers. Is that OK? I'm
> assuming new id's where we don't specify a UID will be put in the same
> range before, which is different on each server.

Ranges are global, not per-server. So assuming your ranges are ok and
there are no overlaps for the IDs or RID ranges this is probably ok, but
I'm not a PAC expert.

I think what you're seeing is the DNA  (Distributed Numeric Assignment)
plugin at work.

On the first installed server, DNA has the full range of id_range values
to generate UIDs and GIDs. The first time a replica needs to generate a
UID/GID it requests a range and gets half of the allocation. A replica
does not automatically get a range on install. The more servers you have
AND the more replicas you've added entries on, the smaller the available
ranges may be. You can use ipa-replica-manage to display and manipulate
the ranges.

rob

>
>
>
>
>
> 
> *From:* Sam Morris via FreeIPA-users 
> *Sent:* Monday, May 15, 2023 8:08 AM
> *To:* FreeIPA users list 
> *Cc:* Alexander Bokovoy ; Sam Morris
> 
> *Subject:* [Freeipa-users] Re: Authentication failures on a RHEL 9.2 IPA
> server
>
> On Mon, May 15, 2023 at 09:28:22AM +0300, Alexander Bokovoy via
> FreeIPA-users wrote:
>> On su, 14 touko 2023, Sam Morris wrote:
>> > On Fri, May 12, 2023 at 06:19:44PM +0100, Sam Morris via FreeIPA-users 
>> > wrote:
>> > > I wonder about the root cause; is this because MIT Kerberos 1.20 always
>> > > wants to include a PAC in its issued TGTs, and it gives up if it can't
>> > > retrieve a user's SID from the directory? (If so I wonder if setting
>> > > disable_pac = true in the realm section of krb5.conf would have worked
>> > > around the problem?)
>> >
>> > This seems to be the case. Specifically I:
>> >
>> > 1. Removed the ipantsecurityidentifier attribute from a user, and
>> >removed ipantuserattrs from the user's objectclass
>> > 2. Tried to log in as the user & got the same failures + 'No such file
>> >or directory' message in /var/log/krb5kdc.log
>> > 3. Edited /var/kerberos/krb5kdc/kdc.conf, adding 'disable_pac = true'
>> >within the realm-specific configuration in the realms section
>> > 4. Restarted krb5kdc
>> > 5. Tried to log in as the user and it worked!
>> >
>> > The docs for disable_pac say:
>> >
>> >If true, the KDC will not issue PACs for this realm, and S4U2Self
>> >

[Freeipa-users] Re: Authentication failures on a RHEL 9.2 IPA server

[Charles Hedrick via FreeIPA-users]

ipa id-range-find didn't find the ranges on the other servers after I added 
them on one. It found the primary ranges (managed by ipa-replica-manage) on all 
3 systems, but of course they are different.


From: Rob Crittenden 
Sent: Monday, May 15, 2023 4:15 PM
To: FreeIPA users list 
Cc: Sam Morris ; Alexander Bokovoy ; 
Charles Hedrick 
Subject: Re: [Freeipa-users] Re: Authentication failures on a RHEL 9.2 IPA 
server

Charles Hedrick via FreeIPA-users wrote:
> OK, so I see the answer to my problem is to run
>
> ipa config-mod --add-sids --enable-sid
>
> But we have old UIDs that with low numbers. It looks like I need to do
>
> ipa idrange-add CS.RUTGERS.EDU_low_id_range --base-id=1
> --range-size=20 --rid-base=2 --secondary-rid-base=3
> ipa idrange-add CS.RUTGERS.EDU_mid_id_range --base-id=60
> --range-size=20 --rid-base=4  --secondary-rid-base=5
>
> In order for ipa user-add for those UIDs to work on any system,
> presumably I have to do that on all IPA servers. Is that OK? I'm
> assuming new id's where we don't specify a UID will be put in the same
> range before, which is different on each server.

Ranges are global, not per-server. So assuming your ranges are ok and
there are no overlaps for the IDs or RID ranges this is probably ok, but
I'm not a PAC expert.

I think what you're seeing is the DNA  (Distributed Numeric Assignment)
plugin at work.

On the first installed server, DNA has the full range of id_range values
to generate UIDs and GIDs. The first time a replica needs to generate a
UID/GID it requests a range and gets half of the allocation. A replica
does not automatically get a range on install. The more servers you have
AND the more replicas you've added entries on, the smaller the available
ranges may be. You can use ipa-replica-manage to display and manipulate
the ranges.

rob

>
>
>
>
>
> 
> *From:* Sam Morris via FreeIPA-users 
> *Sent:* Monday, May 15, 2023 8:08 AM
> *To:* FreeIPA users list 
> *Cc:* Alexander Bokovoy ; Sam Morris
> 
> *Subject:* [Freeipa-users] Re: Authentication failures on a RHEL 9.2 IPA
> server
>
> On Mon, May 15, 2023 at 09:28:22AM +0300, Alexander Bokovoy via
> FreeIPA-users wrote:
>> On su, 14 touko 2023, Sam Morris wrote:
>> > On Fri, May 12, 2023 at 06:19:44PM +0100, Sam Morris via FreeIPA-users 
>> > wrote:
>> > > I wonder about the root cause; is this because MIT Kerberos 1.20 always
>> > > wants to include a PAC in its issued TGTs, and it gives up if it can't
>> > > retrieve a user's SID from the directory? (If so I wonder if setting
>> > > disable_pac = true in the realm section of krb5.conf would have worked
>> > > around the problem?)
>> >
>> > This seems to be the case. Specifically I:
>> >
>> > 1. Removed the ipantsecurityidentifier attribute from a user, and
>> >removed ipantuserattrs from the user's objectclass
>> > 2. Tried to log in as the user & got the same failures + 'No such file
>> >or directory' message in /var/log/krb5kdc.log
>> > 3. Edited /var/kerberos/krb5kdc/kdc.conf, adding 'disable_pac = true'
>> >within the realm-specific configuration in the realms section
>> > 4. Restarted krb5kdc
>> > 5. Tried to log in as the user and it worked!
>> >
>> > The docs for disable_pac say:
>> >
>> >If true, the KDC will not issue PACs for this realm, and S4U2Self
>> >and S4U2Proxy operations will be disabled.  The default is false,
>> >which will permit the KDC to issue PACs.  New in release 1.20.
>> >
>> > ... which doesn't explain that if the KDC can't issue a PAC for some
>> > reason then the KDC will fail to issue the TGT. But at least I've gotten
>> > to the bottom of things now. :)
>>
>> RHEL IdM documentation has a separate chapter related to it.
>>
>> RHEL 9:
>> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/managing_idm_users_groups_hosts_and_access_control_rules/assembly_strengthening-kerberos-security-with-pac-information_managing-users-groups-hosts
>>
>> RHEL 8:
>> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/managing_idm_users_groups_hosts_and_access_control_rules/assembly_strengthening-kerberos-security-with-pac-information_managing-users-groups-hosts
>>
>> This documentation is in place since summer 2022.
>
> Brilliant. It's interesting that the docs say "As of RHEL 8.6, Kerberos
> in IdM requires that your IdM objects have SIDs, which are necessary for

[Freeipa-users] Re: Authentication failures on a RHEL 9.2 IPA server

[Charles Hedrick via FreeIPA-users]

OK, so I see the answer to my problem is to run

ipa config-mod --add-sids --enable-sid

But we have old UIDs that with low numbers. It looks like I need to do

ipa idrange-add CS.RUTGERS.EDU_low_id_range --base-id=1 --range-size=20 
--rid-base=2 --secondary-rid-base=3
ipa idrange-add CS.RUTGERS.EDU_mid_id_range --base-id=60 
--range-size=20 --rid-base=4  --secondary-rid-base=5

In order for ipa user-add for those UIDs to work on any system, presumably I 
have to do that on all IPA servers. Is that OK? I'm assuming new id's where we 
don't specify a UID will be put in the same range before, which is different on 
each server.






From: Sam Morris via FreeIPA-users 
Sent: Monday, May 15, 2023 8:08 AM
To: FreeIPA users list 
Cc: Alexander Bokovoy ; Sam Morris 
Subject: [Freeipa-users] Re: Authentication failures on a RHEL 9.2 IPA server

On Mon, May 15, 2023 at 09:28:22AM +0300, Alexander Bokovoy via FreeIPA-users 
wrote:
> On su, 14 touko 2023, Sam Morris wrote:
> > On Fri, May 12, 2023 at 06:19:44PM +0100, Sam Morris via FreeIPA-users 
> > wrote:
> > > I wonder about the root cause; is this because MIT Kerberos 1.20 always
> > > wants to include a PAC in its issued TGTs, and it gives up if it can't
> > > retrieve a user's SID from the directory? (If so I wonder if setting
> > > disable_pac = true in the realm section of krb5.conf would have worked
> > > around the problem?)
> >
> > This seems to be the case. Specifically I:
> >
> > 1. Removed the ipantsecurityidentifier attribute from a user, and
> >removed ipantuserattrs from the user's objectclass
> > 2. Tried to log in as the user & got the same failures + 'No such file
> >or directory' message in /var/log/krb5kdc.log
> > 3. Edited /var/kerberos/krb5kdc/kdc.conf, adding 'disable_pac = true'
> >within the realm-specific configuration in the realms section
> > 4. Restarted krb5kdc
> > 5. Tried to log in as the user and it worked!
> >
> > The docs for disable_pac say:
> >
> >If true, the KDC will not issue PACs for this realm, and S4U2Self
> >and S4U2Proxy operations will be disabled.  The default is false,
> >which will permit the KDC to issue PACs.  New in release 1.20.
> >
> > ... which doesn't explain that if the KDC can't issue a PAC for some
> > reason then the KDC will fail to issue the TGT. But at least I've gotten
> > to the bottom of things now. :)
>
> RHEL IdM documentation has a separate chapter related to it.
>
> RHEL 9:
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/managing_idm_users_groups_hosts_and_access_control_rules/assembly_strengthening-kerberos-security-with-pac-information_managing-users-groups-hosts
>
> RHEL 8:
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/managing_idm_users_groups_hosts_and_access_control_rules/assembly_strengthening-kerberos-security-with-pac-information_managing-users-groups-hosts
>
> This documentation is in place since summer 2022.

Brilliant. It's interesting that the docs say "As of RHEL 8.6, Kerberos
in IdM requires that your IdM objects have SIDs, which are necessary for
security based on Privilege Access Certificate (PAC) information.", but
I had no problems with authentication on my RHEL 8.6/8.7 servers...

> > > "After upgrading, krb5kdc may fail to issue TGTs to users who have not
> > > had a SID assigned to their accounts ('ipa user-show user --all' will
> > > not include an ipantsecurityidentifier attribute). In this case
> > > krb5kdc.log will log a message "HANDLE_AUTHDATA: u...@example.com for
> > > krbtgt/example@example.com, No such file or directory". This can be
> > > fixed by running 'ipa config-mod --enable-sid --add-sids' as an IPA
> > > admin on another IPA server."
> >
> > ... "or on the same server after temporarily setting "disable_pac =
> > true" in kdc.conf, and restarting krb5kdc."
>
> You should not be disabling PAC because you are really setting yourself
> up to an attack with a known exploit out in a wild.

Absolutely--I just wanted to document what I'd found out, because there
isn't a clear connection documented between the behaviour in RHEL 9.2
with MIT Kerberos 1.20 and the behaviour seen when your IPA users don't
have SIDs assigned.

--
Sam Morris 
PGP: rsa4096/CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue
___

[Freeipa-users] Re: Authentication failures on a RHEL 9.2 IPA server

[Charles Hedrick via FreeIPA-users]

is there a way to do a bulk update of existing users? We have this issue. I can 
disable the pac, but that might not be a good long term solution

From: Sam Morris via FreeIPA-users 
Sent: Monday, May 15, 2023 8:08 AM
To: FreeIPA users list 
Cc: Alexander Bokovoy ; Sam Morris 
Subject: [Freeipa-users] Re: Authentication failures on a RHEL 9.2 IPA server

On Mon, May 15, 2023 at 09:28:22AM +0300, Alexander Bokovoy via FreeIPA-users 
wrote:
> On su, 14 touko 2023, Sam Morris wrote:
> > On Fri, May 12, 2023 at 06:19:44PM +0100, Sam Morris via FreeIPA-users 
> > wrote:
> > > I wonder about the root cause; is this because MIT Kerberos 1.20 always
> > > wants to include a PAC in its issued TGTs, and it gives up if it can't
> > > retrieve a user's SID from the directory? (If so I wonder if setting
> > > disable_pac = true in the realm section of krb5.conf would have worked
> > > around the problem?)
> >
> > This seems to be the case. Specifically I:
> >
> > 1. Removed the ipantsecurityidentifier attribute from a user, and
> >removed ipantuserattrs from the user's objectclass
> > 2. Tried to log in as the user & got the same failures + 'No such file
> >or directory' message in /var/log/krb5kdc.log
> > 3. Edited /var/kerberos/krb5kdc/kdc.conf, adding 'disable_pac = true'
> >within the realm-specific configuration in the realms section
> > 4. Restarted krb5kdc
> > 5. Tried to log in as the user and it worked!
> >
> > The docs for disable_pac say:
> >
> >If true, the KDC will not issue PACs for this realm, and S4U2Self
> >and S4U2Proxy operations will be disabled.  The default is false,
> >which will permit the KDC to issue PACs.  New in release 1.20.
> >
> > ... which doesn't explain that if the KDC can't issue a PAC for some
> > reason then the KDC will fail to issue the TGT. But at least I've gotten
> > to the bottom of things now. :)
>
> RHEL IdM documentation has a separate chapter related to it.
>
> RHEL 9:
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/managing_idm_users_groups_hosts_and_access_control_rules/assembly_strengthening-kerberos-security-with-pac-information_managing-users-groups-hosts
>
> RHEL 8:
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/managing_idm_users_groups_hosts_and_access_control_rules/assembly_strengthening-kerberos-security-with-pac-information_managing-users-groups-hosts
>
> This documentation is in place since summer 2022.

Brilliant. It's interesting that the docs say "As of RHEL 8.6, Kerberos
in IdM requires that your IdM objects have SIDs, which are necessary for
security based on Privilege Access Certificate (PAC) information.", but
I had no problems with authentication on my RHEL 8.6/8.7 servers...

> > > "After upgrading, krb5kdc may fail to issue TGTs to users who have not
> > > had a SID assigned to their accounts ('ipa user-show user --all' will
> > > not include an ipantsecurityidentifier attribute). In this case
> > > krb5kdc.log will log a message "HANDLE_AUTHDATA: u...@example.com for
> > > krbtgt/example@example.com, No such file or directory". This can be
> > > fixed by running 'ipa config-mod --enable-sid --add-sids' as an IPA
> > > admin on another IPA server."
> >
> > ... "or on the same server after temporarily setting "disable_pac =
> > true" in kdc.conf, and restarting krb5kdc."
>
> You should not be disabling PAC because you are really setting yourself
> up to an attack with a known exploit out in a wild.

Absolutely--I just wanted to document what I'd found out, because there
isn't a clear connection documented between the behaviour in RHEL 9.2
with MIT Kerberos 1.20 and the behaviour seen when your IPA users don't
have SIDs assigned.

--
Sam Morris 
PGP: rsa4096/CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] can't kinit after upgrade to redhat 9.2

[Charles Hedrick via FreeIPA-users]

I just upgraded from redhat 9.0 to 9.2 on a set of kerberos servers, 
fortunately a test system. I can't kinit as existing users. If I add a user I 
can kinit as them. Changing the password doesn't help. krb5kdc says


May 15 13:58:30 krb1.cs.rutgers.edu krb5kdc[652884](info): AS_REQ (4 etypes 
{aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), 
aes128-cts-hmac-sha256-128(19), aes128-cts-hmac-sha1-96(17)}) 128.6.157.187: 
HANDLE_AUTHDATA: c...@cs.rutgers.edu for kadmin/chang...@cs.rutgers.edu, No 
such file or directory

The only difference I see in ldap attributes between the existing and new user 
is that the new user has
ipaNTSecurityIdentifier: S-1-5-21-3719230765-1403434741-3275474567-88461
and
objectClass: ipantuserattrs

We are not using anything Windows-related

___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] any disadvantages to using gssproxy?

[Charles Hedrick via FreeIPA-users]

We have a site where some users want to be able to run cron jobs with 
credentials so they can access files via NFS. We are currently using a local 
mechanism to generate those credentials. I'm considering using gssproxy 
instead. I've verified that it will work.

Is there any disadvantage to installing gssproxy on all systems, and setting 
use_gss_proxy in /etc/nfs.conf? We're on Ubuntu 20.04 and 22.04.

The only issue I can see is that attempts to access files will cause something 
(the server?) to check for delegation entries in LDAP. If this only happens 
when credentials aren't already present, the extra overhead should be minimal. 
But we have lots of calls to rpc.gss, particularly since we expire contexts in 
30 min, to deal with the problem that removing users from a group doesn't 
remove their access to files protected by the group until their NFS session 
credentials are refreshed.


___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: /run/ipa/ccaches filling

[Charles Hedrick via FreeIPA-users]

Ok. Makes sense. I’ll use that solution too.

> On Aug 14, 2022, at 4:35 PM, Jochen Kellner  wrote:
> 
> Charles Hedrick via FreeIPA-users 
> writes:
> 
>> it's active, but it seems not to do anything:
>> 
>> ● ipa-ccache-sweep.timer - Remove Expired Kerberos Credential Caches
>> Loaded: loaded (/usr/lib/systemd/system/ipa-ccache-sweep.timer; enabled; 
>> vendor preset: disabled)
>> -
>> 
>> I believe the intent is that it should run every 12 hours. It doesn't
>> seem to be doing so. From a web discussion:
> 
> That's the same on my system... I did enable and start the timer with my
> local ansible plav - but that only worked for the current boot.
> 
>> OnUnitActiveSec does indeed refer to the time since the service
>> referred to by the timer has run.  But if you only use OnUnitActiveSec
>> and no other trigger then issue the command to start or enable
>> foo.timer, foo.service will never run.  Why would it, no trigger would
>> ever be activated in the first place: something needs to trigger the
>> first run of foo.service in order to for you to ever have 3 seconds
>> pass since it was last run.
>> 
>> So in other words, OnUnitActiveSec can be used to define the interval
>> between repetitions, but another trigger (like OnActiveSec or
>> OnBootSec) would be needed to trigger the first run of foo.service to
>> get the ball rolling.
> 
> In other words: you must also enable the
> /usr/lib/systemd/system/ipa-ccache-sweep.service.
> That way it will run once at system reboot and later every 12
> hours. I've just changed my playbook and I'll see with the next reboot
> how that works out.
> 
> Jochen
> 
> -- 
> This space is intentionally left blank.
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: /run/ipa/ccaches filling

[Charles Hedrick via FreeIPA-users]

it's active, but it seems not to do anything:

● ipa-ccache-sweep.timer - Remove Expired Kerberos Credential Caches
 Loaded: loaded (/usr/lib/systemd/system/ipa-ccache-sweep.timer; enabled; 
vendor preset: disabled)
 Active: active (elapsed) since Thu 2022-08-11 11:22:44 EDT; 3 days ago
  Until: Thu 2022-08-11 11:22:44 EDT; 3 days ago
Trigger: n/a
   Triggers: ● ipa-ccache-sweep.service


[Unit]
Description=Remove Expired Kerberos Credential Caches

[Timer]
OnUnitActiveSec=12h

[Install]
WantedBy=timers.target
-

I believe the intent is that it should run every 12 hours. It doesn't seem to 
be doing so. From a web discussion:

OnUnitActiveSec does indeed refer to the time since the service referred to by 
the timer has run.  But if you only use OnUnitActiveSec and no other trigger 
then issue the command to start or enable foo.timer, foo.service will never 
run.  Why would it, no trigger would ever be activated in the first place: 
something needs to trigger the first run of foo.service in order to for you to 
ever have 3 seconds pass since it was last run.

So in other words, OnUnitActiveSec can be used to define the interval between 
repetitions, but another trigger (like OnActiveSec or OnBootSec) would be 
needed to trigger the first run of foo.service to get the ball rolling.


From: Jochen Kellner 
Sent: Sunday, August 14, 2022 12:39 PM
To: Charles Hedrick via FreeIPA-users 
Cc: Charles Hedrick 
Subject: Re: [Freeipa-users] /run/ipa/ccaches filling

Charles Hedrick via FreeIPA-users 
writes:

> RHEL 9.0. /run/ipa/ccaches is filling with credential caches. Many are too 
> old to be valid.
>
> I assume it's safe to have a cron job delete any more than a day old?
> (that's our maxmum lifetime.) I can't see the lifetime directly,
> because they are encrypted.

On my system I have a (disabled( systemd-timer named
ipa-ccache-sweep.timer. My guess would be that it get's enabled on new
installs, but somehow missed on updates. See the release notes of 4.9.9:
https://www.freeipa.org/page/Releases/4.9.9

Jochen

--
This space is intentionally left blank.
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] /run/ipa/ccaches filling

[Charles Hedrick via FreeIPA-users]

RHEL 9.0. /run/ipa/ccaches is filling with credential caches. Many are too old 
to be valid.

I assume it's safe to have a cron job delete any more than a day old? (that's 
our maxmum lifetime.) I can't see the lifetime directly, because they are 
encrypted.

___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: ipa-server-certinstall -k

[Charles Hedrick via FreeIPA-users]

We use ansible to set up all systems. Configuration isn’t a problem.

> On Jun 20, 2022, at 9:05 PM, Fraser Tweedale  wrote:
> 
> On Mon, Jun 20, 2022 at 07:49:16PM +, Charles Hedrick wrote:
>> Keeping our own certificates up to date on the various types of
>> clients is messy enough that we gave up on that.
>> 
>> The only thing we would actually use it for is kinit -n, to
>> bootstrap kinit for OTP. While kinit -n would be the most elegant
>> way to do it, we have several other approaches.
>> 
>> Documentation seems to say that if pkinit_eku_checking is set to
>> kpServerAuth, we don't need the extension. I've found that kinit
>> -n actually does work when the client sets this. However I have to
>> install the certificates manually on the KDC, since the command
>> won't do it.
> 
> This approach substitutes a certificate distribution requirement
> with a config distribution requirement.  Every client would have to
> accept the certificate with id-kp-serverAuth instead of
> id-pkinit-KPKdc** - non-default behaviour which does not conform to
> RFC 4556.  Some client implementations might not have a workaround.
> 
> This workaround might be acceptable for your environment.  In
> general, accepting certificates that do not conform to the
> requirements of RFC 4556 introduces a substantial risk of FreeIPA
> administrators misconfiguring their environment.
> 
> Rob & Michal, perhaps this can be considered as an RFE: to relax
> this requirement via a flag, accompanied by ample warnings?
> 
> ** id-pkinit-KPKdc is not required if the krbtgt/REALM principal
>   name appears in a id-pkinit-san otherName SAN value.  But public
>   CAs will not include that either.
> 
> Thanks,
> Fraser
> 
>> 
>> From: Fraser Tweedale 
>> Sent: Sunday, June 19, 2022 11:34 PM
>> To: Charles Hedrick ; Rob Crittenden via FreeIPA-users 
>> 
>> Cc: Rob Crittenden 
>> Subject: Re: [Freeipa-users] Re: ipa-server-certinstall -k
>> 
>>> On Wed, Jun 15, 2022 at 04:23:30PM -0400, Rob Crittenden via FreeIPA-users 
>>> wrote:
>>> Charles Hedrick via FreeIPA-users wrote:
>>>> the error is
>>>> 
>>>> The KDC certificate in cert.pem, privkey.pem is not valid: invalid for a 
>>>> KDC
>>> 
>>> A PKINIT certificate needs an EKU extension,
>>> https://datatracker.ietf.org/doc/html/rfc4556
>>> 
>>> When generating the key with OpenSSL you need to include "-extensions
>>> kdc_cert"
>>> 
>> It's unlikely that publicly trusted CAs will issue certs with
>> id-pkinit-KPKdc in EKU.  CABForum Baseline Requirements[1]
>> 7.1.2.3(f) says:
>> 
>>Either the value id-kp-serverAuth [RFC5280] or id-kp-clientAuth
>>[RFC5280] or both values MUST be present. id-kp-emailProtection
>>[RFC5280] MAY be present. Other values SHOULD NOT be present.
>> 
>> [1]: https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.8.4.pdf
>> 
>> Charles, you might need to use a certificate issued directly by the
>> IPA CA for your KDC, or else do without PKINIT.
>> 
>> Thanks,
>> Fraser
>> 
>>> 
>>>> 
>>>> 
>>>> 
>>>> *From:* Charles Hedrick via FreeIPA-users
>>>> 
>>>> *Sent:* Wednesday, June 15, 2022 3:39 PM
>>>> *To:* freeipa-users@lists.fedorahosted.org
>>>> 
>>>> *Cc:* Charles Hedrick 
>>>> *Subject:* [Freeipa-users] ipa-server-certinstall -k
>>>> 
>>>> ipa-server-certinstall works fine for http and ldap. But I can't get the
>>>> -k option to work.
>>>> 
>>>> I've tried cert.pem and privkey.pem with and without chain.pem, as well
>>>> as fullchain.pem and privkey.pem (fullchain has both the cert and the
>>>> chain).
>>>> 
>>>> The certs were issued by Internet2, which chains up to addtrust.
>>>> 
>>>> kinit -n works fine if I install the pem files manually, so presumably
>>>> my files are valid.
>>>> 
>>>> 
>>>> ___
>>>> 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

[Freeipa-users] Re: ipa-server-certinstall -k

[Charles Hedrick via FreeIPA-users]

Keeping our own certificates up to date on the various types of clients is 
messy enough that we gave up on that.

The only thing we would actually use it for is kinit -n, to bootstrap kinit for 
OTP. While kinit -n would be the most elegant way to do it, we have several 
other approaches.

Documentation seems to say that if pkinit_eku_checking is set to kpServerAuth, 
we don't need the extension. I've found that kinit -n actually does work when 
the client sets this. However I have to install the certificates manually on 
the KDC, since the command won't do it.



From: Fraser Tweedale 
Sent: Sunday, June 19, 2022 11:34 PM
To: Charles Hedrick ; Rob Crittenden via FreeIPA-users 

Cc: Rob Crittenden 
Subject: Re: [Freeipa-users] Re: ipa-server-certinstall -k

On Wed, Jun 15, 2022 at 04:23:30PM -0400, Rob Crittenden via FreeIPA-users 
wrote:
> Charles Hedrick via FreeIPA-users wrote:
> > the error is
> >
> > The KDC certificate in cert.pem, privkey.pem is not valid: invalid for a KDC
>
> A PKINIT certificate needs an EKU extension,
> https://datatracker.ietf.org/doc/html/rfc4556
>
> When generating the key with OpenSSL you need to include "-extensions
> kdc_cert"
>
It's unlikely that publicly trusted CAs will issue certs with
id-pkinit-KPKdc in EKU.  CABForum Baseline Requirements[1]
7.1.2.3(f) says:

Either the value id-kp-serverAuth [RFC5280] or id-kp-clientAuth
[RFC5280] or both values MUST be present. id-kp-emailProtection
[RFC5280] MAY be present. Other values SHOULD NOT be present.

[1]: https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.8.4.pdf

Charles, you might need to use a certificate issued directly by the
IPA CA for your KDC, or else do without PKINIT.

Thanks,
Fraser

>
> >
> >
> > --------------------
> > *From:* Charles Hedrick via FreeIPA-users
> > 
> > *Sent:* Wednesday, June 15, 2022 3:39 PM
> > *To:* freeipa-users@lists.fedorahosted.org
> > 
> > *Cc:* Charles Hedrick 
> > *Subject:* [Freeipa-users] ipa-server-certinstall -k
> >
> > ipa-server-certinstall works fine for http and ldap. But I can't get the
> > -k option to work.
> >
> > I've tried cert.pem and privkey.pem with and without chain.pem, as well
> > as fullchain.pem and privkey.pem (fullchain has both the cert and the
> > chain).
> >
> > The certs were issued by Internet2, which chains up to addtrust.
> >
> > kinit -n works fine if I install the pem files manually, so presumably
> > my files are valid.
> >
> >
> > ___
> > 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 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 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: ipa-server-certinstall -k

[Charles Hedrick via FreeIPA-users]

the error is

The KDC certificate in cert.pem, privkey.pem is not valid: invalid for a KDC



From: Charles Hedrick via FreeIPA-users 
Sent: Wednesday, June 15, 2022 3:39 PM
To: freeipa-users@lists.fedorahosted.org 
Cc: Charles Hedrick 
Subject: [Freeipa-users] ipa-server-certinstall -k

ipa-server-certinstall works fine for http and ldap. But I can't get the -k 
option to work.

I've tried cert.pem and privkey.pem with and without chain.pem, as well as 
fullchain.pem and privkey.pem (fullchain has both the cert and the chain).

The certs were issued by Internet2, which chains up to addtrust.

kinit -n works fine if I install the pem files manually, so presumably my files 
are valid.

___
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] ipa-server-certinstall -k

[Charles Hedrick via FreeIPA-users]

ipa-server-certinstall works fine for http and ldap. But I can't get the -k 
option to work.

I've tried cert.pem and privkey.pem with and without chain.pem, as well as 
fullchain.pem and privkey.pem (fullchain has both the cert and the chain).

The certs were issued by Internet2, which chains up to addtrust.

kinit -n works fine if I install the pem files manually, so presumably my files 
are valid.

___
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: Strategy to renew TGT - any thoughts?

[Charles Hedrick via FreeIPA-users]

See clhedrick/kerberos in github. The README identifies the various things 
there.

From: Francis Augusto Medeiros-Logeay 
Sent: Sunday, April 24, 2022 8:35 AM
To: FreeIPA users list 
Cc: Charles Hedrick 
Subject: Re: [Freeipa-users] Re: Strategy to renew TGT - any thoughts?


Hey Charles,


Thanks a lot for what you just described - it gives me a lot to think about.

If you have th etime, could you describe how the pam module is called from the 
cron job, and how the TGT is fetched for the users? I mean, if it is a cron 
job, how the tgt is fetched without passwords? And how does the kdc issues the 
ticket?

This info would help me a lot!

Best,

Francis


---
Francis Augusto Medeiros-Logeay
Oslo, Norway


On 2022-04-22 20:59, Charles Hedrick via FreeIPA-users wrote:

We have a script that renews all tickets that are still in use, and kills those 
that are not. The original version of this is a bit complex, but I now have a 
bash script in testing that seems reasonable.

I agree that keytables are a bit of a risk. They work on any host, and root can 
steal them. Here's what we do instead: For cron jobs, a user registers that 
they want to run cron jobs on a specific host. There's a pam module that will 
get a TGT for them when a cron job starts. It talks to a daemon on the kdc that 
verifies that they authorized it to issue tickets for that host and returns a 
ticket. The tickets are locked to that IP address and are not forwardble (since 
we are only using them from NFS).

None of this code is specific to Rutgers, but the script requires less 
infrastructure than the cron support. I have concerns about what we're doing 
for cron. I suspect the right solution is to use constrained delegation for 
NFS. I think that can be done with gssproxy.


From: Francis Augusto Medeiros-Logeay via FreeIPA-users 

Sent: Friday, April 8, 2022 2:19 PM
To: FreeIPA users list 
Cc: Sam Morris ; Alexander Bokovoy ; 
Francis Augusto Medeiros-Logeay 
Subject: [Freeipa-users] Re: Strategy to renew TGT - any thoughts?



On 2022-04-08 10:57, Alexander Bokovoy via FreeIPA-users wrote:
> On pe, 08 huhti 2022, Francis Augusto Medeiros-Logeay via FreeIPA-users
> wrote:

>> I've looked k5start before, and, correct me if I am wrong, but the
>> difference between using a `kinit -k -i | -t keytab` and k5start is
>> that the later takes care of the daemonization aspect, right? As I see
>> it, both need a keytab to work. The issue for me here is that it is a
>> bit undesirable to leave a keytab around. What I like about FreeIPA is
>> that you can fetch the keytab from a cached credential, so that it you
>> could fetch it, use k5start or kinit -kt, and then erase it.
>>
>> I guess there's no way to renew those tickets without a keytab, right?
>
> Nope -- unless you store that password somewhere and run a systemd
> timer, effectively.
>
> If you store your user credentials into a keytab and just set
> KRB5_CLIENT_KTNAME, this will work too. A systemd timer could be used
> to
> replace k5start.
>
> Alternatively, gssproxy could be used for that. It already knows how to
> handle NFS, for example, so it would work just fine. But it also
> expects
> to have a keytab in a proper place.

Thanks a lot, Alexander.

I am clueless now on how to solve this. We experienced that, on machines
where the user uses nfsv4+kerberos to mount their home directory, what
happens is that if the user has some job that writes to some file on his
home directory, the machine goes bananas if the ticket expires (ie, if
the user goes on vacation and doesn't log in). This is already a problem
for a machine with one user, imagine when the machine has dozens of
users. This happened with a RHEL 8.5, and I see no remedy for this,
other than:

- storing a user keytab somewhere in his home folder, and use a
mechanism (k5start, crond, etc) to fetch new TGT's, but seems to be a
potential security risk;
- having some cron job that checks for expired credentials and kills all
processes of that user to avoid a problem with the machine.

Would you have any idea of something out of these lines?

Best,

Francis
___
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 mailing list -- 
freeipa-users@lists.fedorahosted.org<mailto:freeipa-users@lists.fedorahosted.org>
To unsubscribe send 

[Freeipa-users] Re: dse.ldif and dse.ldif.bak gone after powerloss

[Charles Hedrick via FreeIPA-users]

this happens a lot. We use a cron job to save copies of dse.ldif.

From: Sigbjorn Lie via FreeIPA-users 
Sent: Tuesday, April 19, 2022 6:25 AM
To: freeipa-users@lists.fedorahosted.org 
Cc: Sigbjorn Lie 
Subject: [Freeipa-users] dse.ldif and dse.ldif.bak gone after powerloss

Hi,

We recently had a failure causing an IPA server to experience an
immediate powerloss. When the server power was switched back on, the
dirsrv service refused to start. The following we're logged in
journalctl.


Apr 19 10:58:13 ipa2.redacted.tld ns-slapd[2811868]:
[19/Apr/2022:10:58:13.757492036 +0200] - INFO - dse_check_file - The
config /etc/dirsrv/slapd-REDACTED/dse.ldif can not be accessed.
Attempting restore ... (reason: 0)
Apr 19 10:58:13 ipa2.redacted.tld ns-slapd[2811868]:
[19/Apr/2022:10:58:13.757544913 +0200] - ERR - dse_check_file - The
backup file /etc/dirsrv/slapd-REDACTED/dse.ldif.bak has zero length,
refusing to restore it.
Apr 19 10:58:13 ipa2.redacted.tld ns-slapd[2811868]:
[19/Apr/2022:10:58:13.757548466 +0200] - ERR - slapd_bootstrap_config -
No valid configurations can be accessed! You must restore
/etc/dirsrv/slapd-REDACTED/dse.ldif from backup!
Apr 19 10:58:13 ipa2.redacted.tld ns-slapd[2811868]:
[19/Apr/2022:10:58:13.757551275 +0200] - EMERG - main - The
configuration files in directory /etc/dirsrv/slapd-REDACTED could not be
read or were not found.  Please refer to the error log or output for
more info


Upon further troubleshooting we discovered that
/etc/dirsrv/slapd-REDACTED/dse.ldif was missing, and
/etc/dirsrv/slapd-REDACTED/dse.ldif.backup was 0 bytes long. The
dse.ldif.startOK file is still there, however it is now over 2 months
old.


# ls -la dse.ldif.*
-rw---. 1 dirsrv dirsrv  0 Apr 11 14:42 dse.ldif.bak
-rw---. 1 dirsrv root   173135 Feb  9 13:33
dse.ldif.ipa.dd88c8e1bbf92a7c
-rw-rw. 1 dirsrv root   194829 Feb  9 13:33 dse.ldif.modified.out
-rw---. 1 dirsrv dirsrv 226867 Feb 17 11:41 dse.ldif.startOK


When inspecting some of our other still running IPA servers, the
difference between the dse.ldif and the dse.ldif.startOK displays
updates to modifyTimestamp and nsState on entries such as:

dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config

dn: cn=uniqueid generator,cn=config
dn: cn=abort cleanallruv,cn=tasks,cn=config
dn: cn=automember export updates,cn=tasks,cn=config
dn: cn=automember rebuild membership,cn=tasks,cn=config
dn: cn=backup,cn=tasks,cn=config
dn: cn=cleanallruv,cn=tasks,cn=config
dn: cn=compact db,cn=tasks,cn=config
dn: cn=des2aes,cn=tasks,cn=config
dn: cn=entryuuid task,cn=tasks,cn=config
... and the list goes on ...



I would presume the list on the faulty IPA server to be similar if I
still had the files available for comparison.


What is the recommended action to enable the faulty IPA server to
successfully start the dirsrv service?




Regards,
Siggi
___
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 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: Strategy to renew TGT - any thoughts?

[Charles Hedrick via FreeIPA-users]

We have a script that renews all tickets that are still in use, and kills those 
that are not. The original version of this is a bit complex, but I now have a 
bash script in testing that seems reasonable.

I agree that keytables are a bit of a risk. They work on any host, and root can 
steal them. Here's what we do instead: For cron jobs, a user registers that 
they want to run cron jobs on a specific host. There's a pam module that will 
get a TGT for them when a cron job starts. It talks to a daemon on the kdc that 
verifies that they authorized it to issue tickets for that host and returns a 
ticket. The tickets are locked to that IP address and are not forwardble (since 
we are only using them from NFS).

None of this code is specific to Rutgers, but the script requires less 
infrastructure than the cron support. I have concerns about what we're doing 
for cron. I suspect the right solution is to use constrained delegation for 
NFS. I think that can be done with gssproxy.


From: Francis Augusto Medeiros-Logeay via FreeIPA-users 

Sent: Friday, April 8, 2022 2:19 PM
To: FreeIPA users list 
Cc: Sam Morris ; Alexander Bokovoy ; 
Francis Augusto Medeiros-Logeay 
Subject: [Freeipa-users] Re: Strategy to renew TGT - any thoughts?



On 2022-04-08 10:57, Alexander Bokovoy via FreeIPA-users wrote:
> On pe, 08 huhti 2022, Francis Augusto Medeiros-Logeay via FreeIPA-users
> wrote:

>> I've looked k5start before, and, correct me if I am wrong, but the
>> difference between using a `kinit -k -i | -t keytab` and k5start is
>> that the later takes care of the daemonization aspect, right? As I see
>> it, both need a keytab to work. The issue for me here is that it is a
>> bit undesirable to leave a keytab around. What I like about FreeIPA is
>> that you can fetch the keytab from a cached credential, so that it you
>> could fetch it, use k5start or kinit -kt, and then erase it.
>>
>> I guess there's no way to renew those tickets without a keytab, right?
>
> Nope -- unless you store that password somewhere and run a systemd
> timer, effectively.
>
> If you store your user credentials into a keytab and just set
> KRB5_CLIENT_KTNAME, this will work too. A systemd timer could be used
> to
> replace k5start.
>
> Alternatively, gssproxy could be used for that. It already knows how to
> handle NFS, for example, so it would work just fine. But it also
> expects
> to have a keytab in a proper place.

Thanks a lot, Alexander.

I am clueless now on how to solve this. We experienced that, on machines
where the user uses nfsv4+kerberos to mount their home directory, what
happens is that if the user has some job that writes to some file on his
home directory, the machine goes bananas if the ticket expires (ie, if
the user goes on vacation and doesn't log in). This is already a problem
for a machine with one user, imagine when the machine has dozens of
users. This happened with a RHEL 8.5, and I see no remedy for this,
other than:

- storing a user keytab somewhere in his home folder, and use a
mechanism (k5start, crond, etc) to fetch new TGT's, but seems to be a
potential security risk;
- having some cron job that checks for expired credentials and kills all
processes of that user to avoid a problem with the machine.

Would you have any idea of something out of these lines?

Best,

Francis
___
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 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] ipa with duo

[Charles Hedrick via FreeIPA-users]

Our campus uses DUO. We're wondering whether it's possible to use that from 
IPA. My main concern is that user interaction can take time.

I see that it's possible to raise the timeout. But is that safe to do? I'm 
wondering whether otpd is really designed to have lots of threads waiting for 
the user to respond.

___
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] allowing password only one place

[Charles Hedrick via FreeIPA-users]

We have users who have otp set. I want to require them to use it except in one 
specific situation, where I want to be able to use a keytable to generate 
credentials for them (which have to work for all services).

Can anyone think of a way to do this?

Auth indicators doesn't seem to do the job, since it looks like a constraint on 
using the ticket, where I'm concerned with how it's generated. The only thing 
I've come up with is setting the directory server to override ipaUserAuthType 
for that host. There's got to be a better way.


___
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] listing current KCM ccaches

[Charles Hedrick via FreeIPA-users]

I'm trying to find ways to get rid of as much of my custom C coding as 
possible, since I may be the only one that can maintain it. One major one is 
renewd, which renews tgt's automatically.

sssd can now do this. However I also need to kill the tickets when the user is 
no longer active. This could be done in a fairly simple shell script, but only 
if I can find a list of current active credential caches. At the moment the 
only way I can see to do that is to use tdbdump on secrets.ldb. I'm probably 
going to try that, but I'd prefer a better approach.

___
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 server packages upgrade best practice

[Charles Hedrick via FreeIPA-users]

We’ve had good experience doing just release upgrades, e.g from 8.1 to 8.2. For 
that I do yum update, I,e. the whole thing. My assumption is that testing is 
done on systems with the full release.! So upgrading just some things gives us 
a configuration that hasn’t been tested. We did a full reinstall from 7 to 8, 
and presumably will for future major releases. Of course if there’s a security 
problem in ssh, I’d upgrade just that immediately. I’d be more skeptical of 
upgrading any package actually used by IPA.

We also clone all the VMs and try out the full set of upgrades before doing it 
on production. This requires using a hacked copy of DNS that identifies the 
production hostnames with the IPs of the clones. I did a similar test before 
the move from 7 to 8.

On Jul 16, 2021, at 5:38 PM, Suchismita Panda  wrote:


Hello,

Following up again for my question in the previous email, pasted below. It 
would be really helpful, if it could be answered -

We are using CentOS currently for our FreeIPA servers, as per your advice we 
will skip the full OS automatic patching. If we limit the automated patching to 
just target kernel packages, will that be risk free?

Thanks
Suchi

On Fri, Jun 18, 2021 at 11:21 AM Suchismita Panda 
mailto:suchismita...@gmail.com>> wrote:
Thank you for your reply. We are using CentOS currently for our FreeIPA 
servers, as per your advice we will skip the full OS automatic patching. If we 
limit the automated patching to just target kernel packages, will that be risk 
free?

-Suchi

On Thu, Jun 17, 2021 at 1:00 PM Rob Crittenden 
mailto:rcrit...@redhat.com>> wrote:
Suchismita Panda via FreeIPA-users wrote:
> Thanks all for the reply.
>
> Circling back again - We have to do the normal OS upgrade for the
> FreeIPA servers and would like to exclude the FreeIPA package to be
> upgraded. I would like to know the name of the Freeipa packages which
> should be held back from automatic upgrade.
>
> A list would be really helpful.

It's a tricky question. IPA is more than just the freeipa-* packages.
It's 389-ds, pki-*, sssd-*, a ton of python packages, openldap client
libraries, openssl, nss, bind, krb5. And that's just off the top of my head.

In a CentOS/RHEL environment we discourage picking and choosing packages
to upgrade since we only test against what is in a given release. In
Fedora things are bit more fluid so we do the best we can with Requires,
but it isn't feasible to set dependencies on every possible package.

So by blocking freeipa-server and freeipa-client you'll likely hit the
highlights but no promises nothing will break. There can be big
differences between Fedora releases.

rob

>
> On Thu, Apr 15, 2021 at 1:34 PM 
> mailto:hedr...@rutgers.edu>
> >> wrote:
>
> We haven’t had a failure in the last couple of updates. But there
> have been enough problems in upgrades that we do it manually. In
> fact we duplicate all of our VMs, setting up a duplicate set of
> servers, and first try the upgrade on them before we do it in
> production. We have too many eggs in one basket to risk problems
> with IPA.
>
> > On Mar 31, 2021, at 2:45 PM, Suchismita Panda via FreeIPA-users
> 
> mailto:freeipa-users@lists.fedorahosted.org>
> 
> >>
>  wrote:
> >
> > Hi,
> >
> > I would like to know the best practice for patching FreeIPA-Server
> packages. We generally have daily patching enabled in our servers.
> Will it be a good idea to do automatic patching of FreeIPA-Server
> packages?
> >
> > If we want to restrict the FreeIPA-Server packages from
> automatomatic upgrade and rather keep it for manual upgrade, what
> are the packages we should hold back with a version restriction? And
> how frequently should we do the manual upgrade? If the
> FreeIPA-client packages are upgraded regularly by daily
> patching(yum-cron or unattended upgrade) will there be any problem
> with authentication, if the FreeIPA-Servers  are behind version upgrade?
> >
> > We have two FreeIPA environments, one with CentOS7 and another
> with CentOS8. And we have FreeIPA clients mostly with Ubuntu(18 and
> 20) and CentOS (7 and 8).
> >
> > Any help and guidance is appreciated.
> >
> > Thanks
> > Suchi
> > ___
> > FreeIPA-users mailing list -- 
> freeipa-users@lists.fedorahosted.org
> 
> >
> > To unsubscribe send an email to
> 
> freeipa-users-le...@lists.fedorahosted.org
> 
> >
> > Fedora Code 

[Freeipa-users] odd problem updating to Centos 8.3

[Charles Hedrick via FreeIPA-users]

I just upgraded copies of our 3 servers from Centos 8.2 to 8.3. I always try it 
on copies before doing it on the real thing.

The upgrades all went fine, but on one of the servers, the services weren’t 
running, and ipactl status complained

Failed to get list of services to probe status!
Configured hostname z does not match any master server in LDAP:
x
y
z

Adding prints to the python code, I found the issue was that the services, e.g.

dn: cn=KPASSWD,cn=z,cn=masters,cn=ipa,cn=etc,dc=cs,dc=rutgers,dc=edu

had 

ipaConfigString: configuredService

when they should have had

ipaConfigString: enabledService

It was easy to fix. Things now look OK.

Since I’ve fixed it, I don’t need any help, but I thought it was worth 
reporting. There were some oddities in getting the copies working. Initially I 
had bad IP addresses various places. That broke synchronization, and I had to 
reinitialize server z by copying from x. But that was before the upgrade. 
Before doing any upgrades I made sure everything worked, and the replicas were 
all syncing.

The fix did sync to the other servers.

The error message wasn’t entirely helpful.

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

[Charles Hedrick via FreeIPA-users]

thanks. There’s enough jargon in this that I’m not sure I understand. What’s 
the difference in level of QA between freeipa in Stream and RHEL? I’d be happy 
to have new versions of IPA sooner, if they’ve actually been tested well enough 
that they’re ready for the next RHEL release. Are things in good enough shape 
that it would make sense to convert to stream now?

Do you think the in-place upgrade of Centos to RHEL would be safe to do with 
freeipa? I’d assume there’s no actual difference in the packages.

I’m really only concerned with IPA. We use Ubuntu for everything else. We’re a 
computer science department. Our researchers want Ubuntu, and we have to do 
what our users want.

> On Dec 9, 2020, at 11:23 AM, Alexander Bokovoy  wrote:
> 
> I can only talk about FreeIPA and few other projects I am involved with.
> For example, we are getting incredible feedback from both Rawhide and
> RHEL 8.x QA processes for FreeIPA 4.9.0 release candidates. The packages
> are not yet in RHEL 8.x development composes as we do fixes to issues
> found through the QA pre-verification work. Once overall state of the
> release candidate is at the level RHEL IdM QA team accepts, those
> packages will get to RHEL composes and eventually land in C8S (once the
> infra is ready). Once C8S is there in full capacity and running upstream
> CI tests on it would become a reality, we'll see even more shortening of
> that feedback loop length.

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

[Charles Hedrick via FreeIPA-users]

We’e in the same situation. I’d actually be willing to pay for Redhat, but not 
with the requirement to do a reinstall. So until RHEL 9 I need an alternative. 
While I have lots of reasons to dislike it, I’m currently thinking of Oracle 
Linux for our remaining time on 8. I’ve found delays in Centos 8 a concern 
already, so I’m not inclined to wait.

If the IPA developers can assure us that the version in Centos 8 Stream is well 
tested, I’d use that instead. Historically IPA administrative tools have been 
brittle. Any slight difference from the environment they expect and there’s a 
failure, requiring days of reverse engineering an understanding of complex 
Python code. So I’m not inclined to gamble on a release with less testing than 
usual.

> On Dec 9, 2020, at 7:45 AM, Alexander Bokovoy via FreeIPA-users 
>  wrote:
> 
> On ke, 09 joulu 2020, Nico Maas via FreeIPA-users wrote:
>> Yes, however, rolling-release is not for everyone and every usecase,
>> hence I am asking of the status of the Debian and Ubuntu
>> implementations :).
> 
> It is the same as in past: FreeIPA upstream development team has no
> influence or control over Debian or Ubuntu packages. There is a single
> person (thank you, Timo!) doing whole packaging for Debian and Ubuntu
> and this effort is not his primary focus at Canonical.
> 
> With the change of the CentOS project, there is a hope that downstream
> packagers for RHEL and FreeIPA upstream developers will have a better
> way to address needs of IPA users currently utilizing CentOS.
> 
> -- 
> / Alexander Bokovoy
> Sr. Principal Software Engineer
> Security / Identity Management Engineering
> Red Hat Limited, Finland
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Plans for integrating DHCP

[Charles Hedrick via FreeIPA-users]

hmmm. so the problem with our integration is that we use the standard schema. 
that makes DHCP data a separate tree. To make it a real part of freeipa you’d 
want to get data for a  host from its normal host entry. Either you’d need to 
modify the server to read data from the normal freeipa data, or you could keep 
the official DHCP schema, but make the management tools see the items as 
attributes of the freeipa host entry. Both are pretty easy to do. But I can see 
that a real integration like this would be a project that would compete with 
other priorities for IPA.

From my point of view, it’s kind of the biggest missing piece in IPA at the 
moment, though our integration works fine and shouldn’t present any maintenance 
issues.

(You may ask, why use IPA for your DHCP data? In our case it’s because IPA is 
the only multimaster replicated data we have. I’d rather not have to manage a 
mulitimasteir SQL database just to do DHCP.)


> On Jul 6, 2020, at 2:24:43 PM, Charles Hedrick via FreeIPA-users 
>  wrote:
> 
> The main issues are
> * adding to the schema
> * tools for managing
> * dynamic address allocation
> 
> We don’t use dynamic allocation. so that’s not an issue for us. That means 
> the normal ISC dhcpd works fine. It supports getting data from LDAP. They 
> supply a schema file, which with some tweaking works fine with freeipa.
> 
> I have a .py file that will add commands to the IPA command line to manage 
> most data. That should work anywhere with possible minor changes because the 
> base DN will not be Rutgers. I also have a web GUI which is part of my larger 
> user management system. That might be a bit harder to port, though in 
> principle the whole system is designed to be portable. (It uses Spring Boot.)
> 
> The issues I see with integration into freeipa are
> * adding it to the freeipa web GUI. I think that can be done with their 
> defined extension method, so it doesn’t need a change in core code
> * dynamic address management. 
> 
> The current ISC daemon uses a master / backup approach for dynamic address 
> allocation. So it stores allocations locally on the server. That means it 
> doesn’t need LDAP or another database. It should work just fine with freeipa. 
> However the newer ISC DHCP code (currently a separate project) really wants a 
> symmetrical database. LDAP might work, depending upon how often you need to 
> allocate addresses, but LDAP really isn’t intended for high write rates.
> 
>> On Apr 24, 2020, at 6:23 AM, Ronald Wimmer via FreeIPA-users 
>>  wrote:
>> 
>> Hi there,
>> 
>> are there any plans to integrate a DHCP server into FreeIPA. We have several 
>> environments where a lack of DHCP is a showstopper at the moment.
>> 
>> 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://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 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: Plans for integrating DHCP

[Charles Hedrick via FreeIPA-users]

The main issues are
* adding to the schema
* tools for managing
* dynamic address allocation

We don’t use dynamic allocation. so that’s not an issue for us. That means the 
normal ISC dhcpd works fine. It supports getting data from LDAP. They supply a 
schema file, which with some tweaking works fine with freeipa.

I have a .py file that will add commands to the IPA command line to manage most 
data. That should work anywhere with possible minor changes because the base DN 
will not be Rutgers. I also have a web GUI which is part of my larger user 
management system. That might be a bit harder to port, though in principle the 
whole system is designed to be portable. (It uses Spring Boot.)

The issues I see with integration into freeipa are
* adding it to the freeipa web GUI. I think that can be done with their defined 
extension method, so it doesn’t need a change in core code
* dynamic address management. 

The current ISC daemon uses a master / backup approach for dynamic address 
allocation. So it stores allocations locally on the server. That means it 
doesn’t need LDAP or another database. It should work just fine with freeipa. 
However the newer ISC DHCP code (currently a separate project) really wants a 
symmetrical database. LDAP might work, depending upon how often you need to 
allocate addresses, but LDAP really isn’t intended for high write rates.

> On Apr 24, 2020, at 6:23 AM, Ronald Wimmer via FreeIPA-users 
>  wrote:
> 
> Hi there,
> 
> are there any plans to integrate a DHCP server into FreeIPA. We have several 
> environments where a lack of DHCP is a showstopper at the moment.
> 
> 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://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: Ansible and Kerberos

[Charles Hedrick via FreeIPA-users]

for what it’s worth, you can use ansible’s ldap module with GSSAPI if you make 
a one-line patch. In this case we’re only concerned with issuing the ldap 
command locally. Ansible defaults SASL to using external rather than GSSAPI. 
You’d think they’d make it an option, but it’s hardcoded. I was unable to find 
a way to override it.

It’s more complex than you’re expect because I’m worried that ansible might 
choose a different version of python than the default, so I’m trying to figure 
out the location of the file that it’s actually using.

- name: Find correct ldap module to patch
  local_action: command "{{ ansible_playbook_python }}" -c "import 
ansible.module_utils.ldap; print(ansible.module_utils.ldap.__file__)"
  register: ldapfile

- debug:
var: ldapfile

- name: patch ldap.py
  become: true
  local_action: replace path="{{ ldapfile.stdout }}" 
regexp="ldap\.sasl\.external" replace="ldap.sasl.gssapi"


> On Mar 18, 2020, at 11:05:15 AM, Kimmo Rantala via FreeIPA-users 
>  wrote:
> 
> There was a question from Angus that he did not CC here but I think he kind 
> of asked what I/we are trying to do and told that Foreman is a bit like 
> ansible.
> 
> I thought it would be fair to tell what is the goal here.
> 
> We are enrolling clients and we set the userclass attribute to a certain 
> value to then assign the host to host groups with automember rules. This host 
> group is for the environment, customer etc. so the correct users get the 
> correct privileges to the hosts.
> 
> We have the ansible playbooks in bitbucket but currently the playbooks are 
> ran on peoples' workstations that may or may not be enrolled to the same IPA 
> domain. Yes, I know this is sub-optimal but this is the current situation. I, 
> myself, want some kind of centralized solution to this in the (preferably 
> near) future.
> 
> I know that people could use kinit on their workstations to obtain a ticket. 
> That would require that me and my team would need to teach the various actors 
> (who sometimes have surprising lack of knowledge in basic IT stuff) the basic 
> operations of Kerberos.
> 
> The current style works and we are refining it. Gonna take a look at 
> ansible-freeipa again. Looked at it ages ago.
> ___
> 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: Ubuntu client: Kerberos works, authentication does not

[Charles Hedrick via FreeIPA-users]

On Mar 7, 2020, at 12:32:38 PM, Nicholas DeMarco via FreeIPA-users 
mailto:freeipa-users@lists.fedorahosted.org>>
 wrote:

# getent passwd | grep ndemarco

Are you sure this is supposed to work? Typically you want to disable 
enumeration. Does

getent passwd ndemarco

also fail?

___
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

[Charles Hedrick via FreeIPA-users]

> On Mar 6, 2020, at 5:31:36 PM, Todd Grayson via FreeIPA-users 
>  wrote:
> 
> 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.
> 
I don’t see why not. We did that for a while. You need to configure servers in 
both krb5.conf and sssd.conf. But I’m not sure why you need this. The SRV 
records are for finding the server based on the Kerberos domain. As far as I 
know it has nothing to do with the hostname of the client. As long as krb5.conf 
and sssd.conf have the proper Kerberos domain, the client should be able to 
look up the servers in that domain.


> 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://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: suggestion for password policy

[Charles Hedrick via FreeIPA-users]

OK, I was wrong.

First, it doesn't appear the dict_file in kdc.conf does anything, at least not 
with the code used in freeipa. I suspect it’s because it only applies to users 
with password policies, and the standard kerberos code probably doesn’t see the 
freeipa global policy as a policy for specific users. kadmin.local getprinc 
says there’s no policy for my users.

Second, the pwqual plugin works for kpasswd but not for IPA passwd.

That ipa bypasses that plugin seems like a bug. I’m going to look at fixing it 
with a python site-specific plugin.

> On Jan 30, 2020, at 3:11 PM, Charles Hedrick via FreeIPA-users 
>  wrote:
> 
> One thing that concerns me about pipe / socket connection is that ds389, and 
> I assume kadmind, are multithreaded. If  you’re going to send queries to a 
> separate process you either have to serialize it or use a protocol that lets 
> several queries be done at the same time asynchronously. Any approach other 
> than calling an external program and checking the return code is likely to 
> have that issue. Obviously most programming languages can support this kind 
> of thing, but the moment you require code to be asynchronous and use locking 
> you’re putting it beyond a typical sysadmin to write the code. If you want 
> sysadmins to be able to write policy, the cleanest approach is to call a 
> separate process. That would allow a simple shell script. The threading would 
> all be handled in the C plugin that does the call. But there would be more 
> overhead, because for each password change you’d have to start a process and 
> open any files.
> 
>> On Jan 30, 2020, at 1:46:14 PM, Rob Crittenden  wrote:
>> 
>> Charles Hedrick wrote:
>>> I looked into this a bit more. Currently we’re using a kerberos pwqual 
>>> plugin. That is called by both “IPA passwd” and “kpasswd”. You’ve described 
>>> an interface that I know nothing about and can’t find any documentation 
>>> for. I’d be happy either to clean up our pwqual plugin, or create a pwqual 
>>> plugin that talks to a a pipe and supply a dictionary check as an example.
>>> 
>>> The difference is that a pwqual plugin has to be done in C. A small C 
>>> plugin that talks to a pipe would make it easy to write a policy module in 
>>> something like python. The advantage of the pipe is that it avoids having 
>>> to start the program each time there’s a request.
>>> 
>>> Another option, which I might do if it were just for me, is to call python 
>>> from C. Of course that requires you to commit to python, while any language 
>>> can support pipes.
>> 
>> Where have you done the integration to date?
>> 
>> Your pipe idea is similar to the idea of sockets, so that it is more
>> easily user-configurable. The socket would be on the server side as that
>> is where policy is enforced.
>> 
>> rob
>> 
>>> 
>>> 
>>>> On Jan 28, 2020, at 4:34 PM, Charles Hedrick  wrote:
>>>> 
>>>> If you’d prefer an interface to ds389 I’d be wiling to work on that. But 
>>>> it’s not clear from your reference whether the API is finished. If so, 
>>>> could you point to documentation, or at least source?
>>>> 
>>>>> On Jan 28, 2020, at 4:12 PM, Charles Hedrick via FreeIPA-users 
>>>>>  wrote:
>>>>> 
>>>>> I can clean up our code, but it’s for a Kerberos pwqual plugin. That 
>>>>> doesn’t seem to be the approach you’re using. We’re actually using code 
>>>>> from Stanford that’s configurable for all kinds of policies, but we’re 
>>>>> only using it for the database. Code that just checks the database would 
>>>>> be much simpler.  I’m using an sqlite database, but I’d be happy with 
>>>>> other formats if you have a preference. (Stanford was doing additional 
>>>>> checks that really needed something as powerful as SQL. We’d implementing 
>>>>> the NIST recommendation strictly, and don’t need those other checks._
>>>>> 
>>>>>> On Jan 28, 2020, at 2:40 PM, Rob Crittenden  wrote:
>>>>>> 
>>>>>> Charles Hedrick via FreeIPA-users wrote:
>>>>>>> The NIST recommendations for passwords say they don’t think character 
>>>>>>> classes and expiration are useful. Instead, they recommend using a 
>>>>>>> blacklist of known common passwords. There’s no way to implement this 
>>>>>>> policy without writing your own plugin. It would be useful for IPA’s 
>>>>>>>

[Freeipa-users] files to omit from backup

[Charles Hedrick via FreeIPA-users]

We currently do rsync backups of our server. On an MIT server, you’d want to 
omit the stash file. But IPA doesn’t use that. Is there anything like that that 
should be omitted? I’m not sure just how freeipa bootstraps trust when it 
starts up.

___
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: suggestion for password policy

[Charles Hedrick via FreeIPA-users]

One thing that concerns me about pipe / socket connection is that ds389, and I 
assume kadmind, are multithreaded. If  you’re going to send queries to a 
separate process you either have to serialize it or use a protocol that lets 
several queries be done at the same time asynchronously. Any approach other 
than calling an external program and checking the return code is likely to have 
that issue. Obviously most programming languages can support this kind of 
thing, but the moment you require code to be asynchronous and use locking 
you’re putting it beyond a typical sysadmin to write the code. If you want 
sysadmins to be able to write policy, the cleanest approach is to call a 
separate process. That would allow a simple shell script. The threading would 
all be handled in the C plugin that does the call. But there would be more 
overhead, because for each password change you’d have to start a process and 
open any files.

> On Jan 30, 2020, at 1:46:14 PM, Rob Crittenden  wrote:
> 
> Charles Hedrick wrote:
>> I looked into this a bit more. Currently we’re using a kerberos pwqual 
>> plugin. That is called by both “IPA passwd” and “kpasswd”. You’ve described 
>> an interface that I know nothing about and can’t find any documentation for. 
>> I’d be happy either to clean up our pwqual plugin, or create a pwqual plugin 
>> that talks to a a pipe and supply a dictionary check as an example.
>> 
>> The difference is that a pwqual plugin has to be done in C. A small C plugin 
>> that talks to a pipe would make it easy to write a policy module in 
>> something like python. The advantage of the pipe is that it avoids having to 
>> start the program each time there’s a request.
>> 
>> Another option, which I might do if it were just for me, is to call python 
>> from C. Of course that requires you to commit to python, while any language 
>> can support pipes.
> 
> Where have you done the integration to date?
> 
> Your pipe idea is similar to the idea of sockets, so that it is more
> easily user-configurable. The socket would be on the server side as that
> is where policy is enforced.
> 
> rob
> 
>> 
>> 
>>> On Jan 28, 2020, at 4:34 PM, Charles Hedrick  wrote:
>>> 
>>> If you’d prefer an interface to ds389 I’d be wiling to work on that. But 
>>> it’s not clear from your reference whether the API is finished. If so, 
>>> could you point to documentation, or at least source?
>>> 
>>>> On Jan 28, 2020, at 4:12 PM, Charles Hedrick via FreeIPA-users 
>>>>  wrote:
>>>> 
>>>> I can clean up our code, but it’s for a Kerberos pwqual plugin. That 
>>>> doesn’t seem to be the approach you’re using. We’re actually using code 
>>>> from Stanford that’s configurable for all kinds of policies, but we’re 
>>>> only using it for the database. Code that just checks the database would 
>>>> be much simpler.  I’m using an sqlite database, but I’d be happy with 
>>>> other formats if you have a preference. (Stanford was doing additional 
>>>> checks that really needed something as powerful as SQL. We’d implementing 
>>>> the NIST recommendation strictly, and don’t need those other checks._
>>>> 
>>>>> On Jan 28, 2020, at 2:40 PM, Rob Crittenden  wrote:
>>>>> 
>>>>> Charles Hedrick via FreeIPA-users wrote:
>>>>>> The NIST recommendations for passwords say they don’t think character 
>>>>>> classes and expiration are useful. Instead, they recommend using a 
>>>>>> blacklist of known common passwords. There’s no way to implement this 
>>>>>> policy without writing your own plugin. It would be useful for IPA’s 
>>>>>> password policy to allow you to specify a database of forbidden 
>>>>>> passwords.
>>>>>> 
>>>>>> We’ve done this using a plugin, but I’d rather not have to write C code 
>>>>>> to implement policy.
>>>>> 
>>>>> This sort of falls under the long-standing upstream issue
>>>>> https://pagure.io/freeipa/issue/5948 , the idea being that socket
>>>>> activation is used to pass off policy onto some configurable daemon
>>>>> which would return a yes/no.
>>>>> 
>>>>> Password policy is very much hardcoded in IPA for old, legacy reasons.
>>>>> 
>>>>> And I'll just throw out that patches are welcome, even if they need some
>>>>> additional work.
>>>>> 
>>>>> rob
>>>>> 
>>>> 
>>>> ___

[Freeipa-users] Re: suggestion for password policy

[Charles Hedrick via FreeIPA-users]

> On Jan 30, 2020, at 1:46:14 PM, Rob Crittenden  wrote:
> 
> Charles Hedrick wrote:
>> I looked into this a bit more. Currently we’re using a kerberos pwqual 
>> plugin. That is called by both “IPA passwd” and “kpasswd”. You’ve described 
>> an interface that I know nothing about and can’t find any documentation for. 
>> I’d be happy either to clean up our pwqual plugin, or create a pwqual plugin 
>> that talks to a a pipe and supply a dictionary check as an example.
>> 
>> The difference is that a pwqual plugin has to be done in C. A small C plugin 
>> that talks to a pipe would make it easy to write a policy module in 
>> something like python. The advantage of the pipe is that it avoids having to 
>> start the program each time there’s a request.
>> 
>> Another option, which I might do if it were just for me, is to call python 
>> from C. Of course that requires you to commit to python, while any language 
>> can support pipes.
> 
> Where have you done the integration to date?
> 
> Your pipe idea is similar to the idea of sockets, so that it is more
> easily user-configurable. The socket would be on the server side as that
> is where policy is enforced.

At the moment it’s a pwqual plugin. There’s an API defined by MIT for a plugin 
to check password acceptabiity. It’s a sharable library. It’s declared in 
/etc/krb5.conf on the servers, in a [plugins] section. tt can reject a password 
or pass it on to the next module in the chain.

There’s an initialization section, so the database can be opened once, and 
anything necessary cached. They way that works is that the API allows a pointer 
to any state information. So init can allocate data structures, stick pointers 
to all the data into a single struct, and hand that back through the API as the 
state to be maintained. Either it would be readonly or you’d have to use a lock 
to change it. The only disadvantage I can see to this approach is that these 
plugins have to be written in C, and writing Kerberos code in C isn’t something 
you want novices to do, because there’s a lot of danger of memory leaks or 
corruption.

Obviously this handles kpasswd, since that goes through the normal Kerberos 
code. I was a bit surprised to see to a proposal to add something extra to 
ds389, since the pwqual interface is the standard way to do password policy. I 
wondered if maybe “ipa passwd” bypassed it, somehow talking directly to ds389. 
But I don’t think that’s the case. I tried setting a password in “ipa passwd” 
that our tests would reject, and it was rejected. (That was a password for 
myself. When authenticated as a passwd sync agent and changed someone else’s 
password, it seems to bypass the checks.)

Actually as I’ve looked a bit more, I’m thinking that this whole thing is 
unnecessary. I haven’t tested it yet, but there’s a standard MIT module 
pwqual_dict that already does dictionary checks. You just have to declare the 
dictionary file in kdc.conf. I’m going to try that shortly. If it works, 
there’s no reason to continue using our plugin, and you should just document 
this for Freeipa users. Ideally it might be interesting for the password policy 
to control whether to do a dictionary check. The way it currently works is the 
dictionary check is done if any password policy is in effect for that 
principal. That’s good enough for us.

It still  might be useful to have a plugin that calls something like an 
external python program, to make it easier for people to write their own 
policies. But if the existing pwqual_dict works, we wouldn’t need it. If you’re 
interested in that kind of extension mechanism, the MIT approach would be to 
create a pwqual plugin. it could either talk to an external service through a 
pipe / socket, or if you’re  willing to standardize on python, load a piece of 
python code. Since there’s a one-time initialization call, the python could 
open any databases or load any caches at that point, though maintaining state 
would require sone investigation into how C and python data structures 
interoperate. If you’re willing to say that password changes aren’t frequent 
enough to be a performance issue, you could just call a program and check the 
return code. That would make it easy to do a policy in any language, including 
a bash script. In our installation that would be OK, but you might have users 
whose sites are so big that password change becomes a performance concern.

> 
> rob
> 
>> 
>> 
>>> On Jan 28, 2020, at 4:34 PM, Charles Hedrick  wrote:
>>> 
>>> If you’d prefer an interface to ds389 I’d be wiling to work on that. But 
>>> it’s not clear from your reference whether the API is finished. If so, 
>>> could you point to documentation, or at least source?
>>> 
>>>> On Jan 28, 2020, at 4:12 PM, Charles Hedrick via FreeIPA

[Freeipa-users] Re: suggestion for password policy

[Charles Hedrick via FreeIPA-users]

I looked into this a bit more. Currently we’re using a kerberos pwqual plugin. 
That is called by both “IPA passwd” and “kpasswd”. You’ve described an 
interface that I know nothing about and can’t find any documentation for. I’d 
be happy either to clean up our pwqual plugin, or create a pwqual plugin that 
talks to a a pipe and supply a dictionary check as an example.

The difference is that a pwqual plugin has to be done in C. A small C plugin 
that talks to a pipe would make it easy to write a policy module in something 
like python. The advantage of the pipe is that it avoids having to start the 
program each time there’s a request.

Another option, which I might do if it were just for me, is to call python from 
C. Of course that requires you to commit to python, while any language can 
support pipes.


> On Jan 28, 2020, at 4:34 PM, Charles Hedrick  wrote:
> 
> If you’d prefer an interface to ds389 I’d be wiling to work on that. But it’s 
> not clear from your reference whether the API is finished. If so, could you 
> point to documentation, or at least source?
> 
>> On Jan 28, 2020, at 4:12 PM, Charles Hedrick via FreeIPA-users 
>>  wrote:
>> 
>> I can clean up our code, but it’s for a Kerberos pwqual plugin. That doesn’t 
>> seem to be the approach you’re using. We’re actually using code from 
>> Stanford that’s configurable for all kinds of policies, but we’re only using 
>> it for the database. Code that just checks the database would be much 
>> simpler.  I’m using an sqlite database, but I’d be happy with other formats 
>> if you have a preference. (Stanford was doing additional checks that really 
>> needed something as powerful as SQL. We’d implementing the NIST 
>> recommendation strictly, and don’t need those other checks._
>> 
>>> On Jan 28, 2020, at 2:40 PM, Rob Crittenden  wrote:
>>> 
>>> Charles Hedrick via FreeIPA-users wrote:
>>>> The NIST recommendations for passwords say they don’t think character 
>>>> classes and expiration are useful. Instead, they recommend using a 
>>>> blacklist of known common passwords. There’s no way to implement this 
>>>> policy without writing your own plugin. It would be useful for IPA’s 
>>>> password policy to allow you to specify a database of forbidden passwords.
>>>> 
>>>> We’ve done this using a plugin, but I’d rather not have to write C code to 
>>>> implement policy.
>>> 
>>> This sort of falls under the long-standing upstream issue
>>> https://pagure.io/freeipa/issue/5948 , the idea being that socket
>>> activation is used to pass off policy onto some configurable daemon
>>> which would return a yes/no.
>>> 
>>> Password policy is very much hardcoded in IPA for old, legacy reasons.
>>> 
>>> And I'll just throw out that patches are welcome, even if they need some
>>> additional work.
>>> 
>>> 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 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: after recreating server, ipa: ERROR: No valid Negotiate header in server response

[Charles Hedrick via FreeIPA-users]

I found the problem. Someone when one of our servers was created, it’s password 
(actually Kerberos credentials) didn’t propagate to the other servers.

I pulled the value of krbprincipalkey from the server and used ldapmodify to 
fix it on the other servers. Now the credentials are the same on all our 
systems, and things work.

We had a number of issues that happened when not all the old data was deleted 
before we recreated the server. This looks like yet another symptom.

On Jan 28, 2020, at 5:48:45 PM, Charles Hedrick via FreeIPA-users 
mailto:freeipa-users@lists.fedorahosted.org>>
 wrote:

we just upgraded servers to centos 8.1, by dealing them and recreating them.

On a few systems when I try to use the IPA command I get

ipa: ERROR: No valid Negotiate header in server response

This doesn’t happen on all hosts. The IPA command works fine on the server 
itself. Since it’s only on some hosts the obvious suspicion is that something 
is cached from the old server. Any idea what’s going on?

___
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/
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] after recreating server, ipa: ERROR: No valid Negotiate header in server response

[Charles Hedrick via FreeIPA-users]

we just upgraded servers to centos 8.1, by dealing them and recreating them.

On a few systems when I try to use the IPA command I get

ipa: ERROR: No valid Negotiate header in server response

This doesn’t happen on all hosts. The IPA command works fine on the server 
itself. Since it’s only on some hosts the obvious suspicion is that something 
is cached from the old server. Any idea what’s going on?

___
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: suggestion for password policy

[Charles Hedrick via FreeIPA-users]

I can clean up our code, but it’s for a Kerberos pwqual plugin. That doesn’t 
seem to be the approach you’re using. We’re actually using code from Stanford 
that’s configurable for all kinds of policies, but we’re only using it for the 
database. Code that just checks the database would be much simpler.  I’m using 
an sqlite database, but I’d be happy with other formats if you have a 
preference. (Stanford was doing additional checks that really needed something 
as powerful as SQL. We’d implementing the NIST recommendation strictly, and 
don’t need those other checks._

> On Jan 28, 2020, at 2:40 PM, Rob Crittenden  wrote:
> 
> Charles Hedrick via FreeIPA-users wrote:
>> The NIST recommendations for passwords say they don’t think character 
>> classes and expiration are useful. Instead, they recommend using a blacklist 
>> of known common passwords. There’s no way to implement this policy without 
>> writing your own plugin. It would be useful for IPA’s password policy to 
>> allow you to specify a database of forbidden passwords.
>> 
>> We’ve done this using a plugin, but I’d rather not have to write C code to 
>> implement policy.
> 
> This sort of falls under the long-standing upstream issue
> https://pagure.io/freeipa/issue/5948 , the idea being that socket
> activation is used to pass off policy onto some configurable daemon
> which would return a yes/no.
> 
> Password policy is very much hardcoded in IPA for old, legacy reasons.
> 
> And I'll just throw out that patches are welcome, even if they need some
> additional work.
> 
> 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] suggestion for password policy

[Charles Hedrick via FreeIPA-users]

The NIST recommendations for passwords say they don’t think character classes 
and expiration are useful. Instead, they recommend using a blacklist of known 
common passwords. There’s no way to implement this policy without writing your 
own plugin. It would be useful for IPA’s password policy to allow you to 
specify a database of forbidden passwords.

We’ve done this using a plugin, but I’d rather not have to write C code to 
implement policy.

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

[Freeipa-users] Re: can't install replica

[Charles Hedrick via FreeIPA-users]

Here’s my workaround:


It appears that this happens only when using commercial certs. It's trying to 
fetch the Directory Manager password (encrypted) from the primary to put it in 
the new sysstem. I commented out custodiainstance.py:211,

def import_dm_password(self):
cli = self._get_custodia_client()
#cli.fetch_key('dm/DMHash') 
   <


and copied it manually.

On the primary, open /etc/dirsrv/slapd-CS-RUTGERS-EDU/dse.ldif. Look for

nsslapd-rootpw: {SSHA}


It should be under cn=config. Now shutdown ipa on the new server (ipactl stop), 
edit /etc/dirsrv/slapd-CS-RUTGERS-EDU/dse.ldif, and replace that line with the 
one you copied from the original server. Restart ipa.

On Jan 24, 2020, at 7:52 PM, Charles Hedrick 
mailto:hedr...@rutgers.edu>> wrote:

We are moving from Centos 7 to 8. I did a test on copies and it worked with 
8.0. i made the mistake of doing it on the production servers under 8.1. It 
fails.

I removed one server and recreated it as a replica. It worked fine. However the 
second one failed near the end of the process:

Restart of krb5kdc.service complete
Waiting up to 300 seconds to see our keys appear on host 
ldap://krb1.cs.rutgers.edu
Starting new HTTPS connection (1): 
krb1.cs.rutgers.edu:443
https://krb1.cs.rutgers.edu:443 "GET 
/ipa/keys/dm/DMHash?type=kem=eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZDQkMtSFM1MTIiLCJraWQiOm51bGx9.KgdU3jtIIC3bRIoqToXzmZIl3QFUKqbrBbT0sBerqmR2YWNWQTEp8ABbTSHINOUhtgPubXhwaAsqPzXTee3urtrK6lmf9wJ6OkecdVPY1PS9sWhMNUz4gEJkR-vVM8bN6gfk4g2Lc8jq2o2LMFloNMgCqUQyeRuiec09NsjIvR8X18xYQfXJXvlhuz-d2OJW1CsKO6_T1z8O_vsxlZ-vAeB8j3dbZiXJOlzdcxYYqjMHY-IM4LroUzCVNXtHloiq28e6R-uVTX9O7ActEbiSy6UePgE76K0cWVl1kJyHFozEZChH1_rzCgP6zdhAf8QqPOdde_860nxIUmroRuECjA.gnnrHcTs9ucgqLntquJltw.GAWBOG_aMTgwzwxQqSIFrThgTTiqg3fM3POZWccCqqs3PiwJq5vW2S-tF9VsV1topXcRdlKb6fUOyjE6wrffJ5hYRyE1c3ocAlG3QTVC8QWRn7Ol_IfoVfW-hTe-cAhELcdIOIEand_BYjSTEO6rDXv83iXRFxwno9ZYYppF8bQY7EC1r_wW5xTdXftILCDmkJbhXmGPnlCQ2Ah9cG3qZAKNBRsvk400_kRQec-4LBKWGYYd0y56zd6-PpcVO6p72AldDF_YoeettzaaxbYyH0bRFt7y9aHH3GaD5BOkVp_ZgSHZWbWf8-2zB76f1OKrz6TktCfcb4_ChUZ6BZZ41MX6T06Xjp3ft6p5KzPfY_gUq0fKWWESHMLOEZg8fAl15l9ZwMiRmpd1PZW3oLVxF3rO94OM4H7_8WVehrcO3dAuAVA7_ykmIKv-WBWvjNHbsXXTyb76a2ka2WYuVxeKGMklEyQgOaMPJa7BqSOCiPljt7juTXAMGRupuDG62bP9PdFQkervv4p_9wvwpEZkuWPLlHqgzrdspgBbQoXkbcyiv9qf7oyB_xHQaoMxlwfvGwlNu8Go9t8oHJkalVdjxCPL-qG0GxKHuh0uFNYR0Z3uP545HkzVECv8uUkm08Jc.SCBVE0utvtniR8-8qAe02swg5GzDZxfN0O6JkKsWN2Y
 HTTP/1.1" 502 415
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

 File "/usr/lib/python3.6/site-packages/ipapython/admintool.py", line 179, in 
execute
   return_value = self.run()
 File "/usr/lib/python3.6/site-packages/ipapython/install/cli.py", line 340, in 
run
   return cfgr.run()
 File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 360, 
in run
   return self.execute()
 File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 386, 
in execute
   for rval in self._executor():
 File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 431, 
in __runner
   exc_handler(exc_info)
 File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 460, 
in _handle_execute_exception
   self._handle_exception(exc_info)
 File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 450, 
in _handle_exception
   six.reraise(*exc_info)
 File "/usr/lib/python3.6/site-packages/six.py", line 693, in reraise
   raise value
 File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 421, 
in __runner
   step()
 File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 418, 
in 
   step = lambda: next(self.__gen)
 File "/usr/lib/python3.6/site-packages/ipapython/install/util.py", line 81, in 
run_generator_with_yield_from
   six.reraise(*exc_info)
 File "/usr/lib/python3.6/site-packages/six.py", line 693, in reraise
   raise value
 File "/usr/lib/python3.6/site-packages/ipapython/install/util.py", line 59, in 
run_generator_with_yield_from
   value = gen.send(prev_value)
 File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 655, 
in _configure
   next(executor)
 File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 431, 
in __runner
   exc_handler(exc_info)
 File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 460, 
in _handle_execute_exception
   self._handle_exception(exc_info)
 File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 518, 
in _handle_exception
   self.__parent._handle_exception(exc_info)
 File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 450, 
in _handle_exception
   six.reraise(*exc_info)
 File "/usr/lib/python3.6/site-packages/six.py", line 693, in reraise
   raise value
 File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 515, 
in 

[Freeipa-users] Re: can't install replica

[Charles Hedrick via FreeIPA-users]

This is when trying to set up from the centos 7 server. When it tries from the 
server that is already centos 8, I get

  [error] DatabaseError: Server is unwilling to perform: Entry is managed by 
topology plugin. Adding of entry not allow 

as it’s trying to add the replication agreement.

> On Jan 24, 2020, at 7:52 PM, Charles Hedrick  wrote:
> 
> We are moving from Centos 7 to 8. I did a test on copies and it worked with 
> 8.0. i made the mistake of doing it on the production servers under 8.1. It 
> fails.
> 
> I removed one server and recreated it as a replica. It worked fine. However 
> the second one failed near the end of the process:
> 
> Restart of krb5kdc.service complete
> Waiting up to 300 seconds to see our keys appear on host 
> ldap://krb1.cs.rutgers.edu
> Starting new HTTPS connection (1): krb1.cs.rutgers.edu:443
> https://krb1.cs.rutgers.edu:443 "GET 
> /ipa/keys/dm/DMHash?type=kem=eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZDQkMtSFM1MTIiLCJraWQiOm51bGx9.KgdU3jtIIC3bRIoqToXzmZIl3QFUKqbrBbT0sBerqmR2YWNWQTEp8ABbTSHINOUhtgPubXhwaAsqPzXTee3urtrK6lmf9wJ6OkecdVPY1PS9sWhMNUz4gEJkR-vVM8bN6gfk4g2Lc8jq2o2LMFloNMgCqUQyeRuiec09NsjIvR8X18xYQfXJXvlhuz-d2OJW1CsKO6_T1z8O_vsxlZ-vAeB8j3dbZiXJOlzdcxYYqjMHY-IM4LroUzCVNXtHloiq28e6R-uVTX9O7ActEbiSy6UePgE76K0cWVl1kJyHFozEZChH1_rzCgP6zdhAf8QqPOdde_860nxIUmroRuECjA.gnnrHcTs9ucgqLntquJltw.GAWBOG_aMTgwzwxQqSIFrThgTTiqg3fM3POZWccCqqs3PiwJq5vW2S-tF9VsV1topXcRdlKb6fUOyjE6wrffJ5hYRyE1c3ocAlG3QTVC8QWRn7Ol_IfoVfW-hTe-cAhELcdIOIEand_BYjSTEO6rDXv83iXRFxwno9ZYYppF8bQY7EC1r_wW5xTdXftILCDmkJbhXmGPnlCQ2Ah9cG3qZAKNBRsvk400_kRQec-4LBKWGYYd0y56zd6-PpcVO6p72AldDF_YoeettzaaxbYyH0bRFt7y9aHH3GaD5BOkVp_ZgSHZWbWf8-2zB76f1OKrz6TktCfcb4_ChUZ6BZZ41MX6T06Xjp3ft6p5KzPfY_gUq0fKWWESHMLOEZg8fAl15l9ZwMiRmpd1PZW3oLVxF3rO94OM4H7_8WVehrcO3dAuAVA7_ykmIKv-WBWvjNHbsXXTyb76a2ka2WYuVxeKGMklEyQgOaMPJa7BqSOCiPljt7juTXAMGRupuDG62bP9PdFQkervv4p_9wvwpEZkuWPLlHqgzrdspgBbQoXkbcyiv9qf7oyB_xHQaoMxlwfvGwlNu8Go9t8oHJkalVdjxCPL-qG0GxKHuh0uFNYR0Z3uP545HkzVECv8uUkm08Jc.SCBVE0utvtniR8-8qAe02swg5GzDZxfN0O6JkKsWN2Y
>  HTTP/1.1" 502 415
> Your system may be partly configured.
> Run /usr/sbin/ipa-server-install --uninstall to clean up.
> 
>  File "/usr/lib/python3.6/site-packages/ipapython/admintool.py", line 179, in 
> execute
>return_value = self.run()
>  File "/usr/lib/python3.6/site-packages/ipapython/install/cli.py", line 340, 
> in run
>return cfgr.run()
>  File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 360, 
> in run
>return self.execute()
>  File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 386, 
> in execute
>for rval in self._executor():
>  File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 431, 
> in __runner
>exc_handler(exc_info)
>  File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 460, 
> in _handle_execute_exception
>self._handle_exception(exc_info)
>  File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 450, 
> in _handle_exception
>six.reraise(*exc_info)
>  File "/usr/lib/python3.6/site-packages/six.py", line 693, in reraise
>raise value
>  File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 421, 
> in __runner
>step()
>  File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 418, 
> in 
>step = lambda: next(self.__gen)
>  File "/usr/lib/python3.6/site-packages/ipapython/install/util.py", line 81, 
> in run_generator_with_yield_from
>six.reraise(*exc_info)
>  File "/usr/lib/python3.6/site-packages/six.py", line 693, in reraise
>raise value
>  File "/usr/lib/python3.6/site-packages/ipapython/install/util.py", line 59, 
> in run_generator_with_yield_from
>value = gen.send(prev_value)
>  File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 655, 
> in _configure
>next(executor)
>  File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 431, 
> in __runner
>exc_handler(exc_info)
>  File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 460, 
> in _handle_execute_exception
>self._handle_exception(exc_info)
>  File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 518, 
> in _handle_exception
>self.__parent._handle_exception(exc_info)
>  File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 450, 
> in _handle_exception
>six.reraise(*exc_info)
>  File "/usr/lib/python3.6/site-packages/six.py", line 693, in reraise
>raise value
>  File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 515, 
> in _handle_exception
>super(ComponentBase, self)._handle_exception(exc_info)
>  File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 450, 
> in _handle_exception
>six.reraise(*exc_info)
>  File "/usr/lib/python3.6/site-packages/six.py", line 693, in reraise
>raise value
>  File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 421, 
> in __runner
>step()
> 

[Freeipa-users] can't install replica

[Charles Hedrick via FreeIPA-users]

We are moving from Centos 7 to 8. I did a test on copies and it worked with 
8.0. i made the mistake of doing it on the production servers under 8.1. It 
fails.

I removed one server and recreated it as a replica. It worked fine. However the 
second one failed near the end of the process:

Restart of krb5kdc.service complete
Waiting up to 300 seconds to see our keys appear on host 
ldap://krb1.cs.rutgers.edu
Starting new HTTPS connection (1): krb1.cs.rutgers.edu:443
https://krb1.cs.rutgers.edu:443 "GET 
/ipa/keys/dm/DMHash?type=kem=eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZDQkMtSFM1MTIiLCJraWQiOm51bGx9.KgdU3jtIIC3bRIoqToXzmZIl3QFUKqbrBbT0sBerqmR2YWNWQTEp8ABbTSHINOUhtgPubXhwaAsqPzXTee3urtrK6lmf9wJ6OkecdVPY1PS9sWhMNUz4gEJkR-vVM8bN6gfk4g2Lc8jq2o2LMFloNMgCqUQyeRuiec09NsjIvR8X18xYQfXJXvlhuz-d2OJW1CsKO6_T1z8O_vsxlZ-vAeB8j3dbZiXJOlzdcxYYqjMHY-IM4LroUzCVNXtHloiq28e6R-uVTX9O7ActEbiSy6UePgE76K0cWVl1kJyHFozEZChH1_rzCgP6zdhAf8QqPOdde_860nxIUmroRuECjA.gnnrHcTs9ucgqLntquJltw.GAWBOG_aMTgwzwxQqSIFrThgTTiqg3fM3POZWccCqqs3PiwJq5vW2S-tF9VsV1topXcRdlKb6fUOyjE6wrffJ5hYRyE1c3ocAlG3QTVC8QWRn7Ol_IfoVfW-hTe-cAhELcdIOIEand_BYjSTEO6rDXv83iXRFxwno9ZYYppF8bQY7EC1r_wW5xTdXftILCDmkJbhXmGPnlCQ2Ah9cG3qZAKNBRsvk400_kRQec-4LBKWGYYd0y56zd6-PpcVO6p72AldDF_YoeettzaaxbYyH0bRFt7y9aHH3GaD5BOkVp_ZgSHZWbWf8-2zB76f1OKrz6TktCfcb4_ChUZ6BZZ41MX6T06Xjp3ft6p5KzPfY_gUq0fKWWESHMLOEZg8fAl15l9ZwMiRmpd1PZW3oLVxF3rO94OM4H7_8WVehrcO3dAuAVA7_ykmIKv-WBWvjNHbsXXTyb76a2ka2WYuVxeKGMklEyQgOaMPJa7BqSOCiPljt7juTXAMGRupuDG62bP9PdFQkervv4p_9wvwpEZkuWPLlHqgzrdspgBbQoXkbcyiv9qf7oyB_xHQaoMxlwfvGwlNu8Go9t8oHJkalVdjxCPL-qG0GxKHuh0uFNYR0Z3uP545HkzVECv8uUkm08Jc.SCBVE0utvtniR8-8qAe02swg5GzDZxfN0O6JkKsWN2Y
 HTTP/1.1" 502 415
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

  File "/usr/lib/python3.6/site-packages/ipapython/admintool.py", line 179, in 
execute
return_value = self.run()
  File "/usr/lib/python3.6/site-packages/ipapython/install/cli.py", line 340, 
in run
return cfgr.run()
  File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 360, 
in run
return self.execute()
  File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 386, 
in execute
for rval in self._executor():
  File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 431, 
in __runner
exc_handler(exc_info)
  File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 460, 
in _handle_execute_exception
self._handle_exception(exc_info)
  File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 450, 
in _handle_exception
six.reraise(*exc_info)
  File "/usr/lib/python3.6/site-packages/six.py", line 693, in reraise
raise value
  File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 421, 
in __runner
step()
  File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 418, 
in 
step = lambda: next(self.__gen)
  File "/usr/lib/python3.6/site-packages/ipapython/install/util.py", line 81, 
in run_generator_with_yield_from
six.reraise(*exc_info)
  File "/usr/lib/python3.6/site-packages/six.py", line 693, in reraise
raise value
  File "/usr/lib/python3.6/site-packages/ipapython/install/util.py", line 59, 
in run_generator_with_yield_from
value = gen.send(prev_value)
  File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 655, 
in _configure
next(executor)
  File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 431, 
in __runner
exc_handler(exc_info)
  File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 460, 
in _handle_execute_exception
self._handle_exception(exc_info)
  File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 518, 
in _handle_exception
self.__parent._handle_exception(exc_info)
  File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 450, 
in _handle_exception
six.reraise(*exc_info)
  File "/usr/lib/python3.6/site-packages/six.py", line 693, in reraise
raise value
  File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 515, 
in _handle_exception
super(ComponentBase, self)._handle_exception(exc_info)
  File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 450, 
in _handle_exception
six.reraise(*exc_info)
  File "/usr/lib/python3.6/site-packages/six.py", line 693, in reraise
raise value
  File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 421, 
in __runner
step()
  File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 418, 
in 
step = lambda: next(self.__gen)
  File "/usr/lib/python3.6/site-packages/ipapython/install/util.py", line 81, 
in run_generator_with_yield_from
six.reraise(*exc_info)
  File "/usr/lib/python3.6/site-packages/six.py", line 693, in reraise
raise value
  File "/usr/lib/python3.6/site-packages/ipapython/install/util.py", line 59, 
in run_generator_with_yield_from
value = 

[Freeipa-users] Re: Two interfaces on FreeIPA server.. How?

[Charles Hedrick via FreeIPA-users]

I haven’t tried this for the IPA server, but we have servers with two 
interfaces, one for general use and one as a storage backend network. 

We can’t just list both IPs in an A record, because then normal traffic will 
try to go through the backend, which it can’t get to.

What I ended up doing was maintaining a separate /etc/hosts for the machines 
with dual interfaces on the backend network. That file shows both IPs for each 
of the hosts as associated with the main hostname. Systems without an interface 
on that network don’t get that /etc/hosts, so they only see the primary address.

Then we use /etc/gai.conf to tell DNS to prefer the backend address. Of course 
that file is installed only on the dual-interface hosts.

We use anbiel to distribute the files, so keeping them up to date and in sync 
isn’t a problem, but we do have to add an entry to the special /etc/hosts 
everything we add a host with a second interface on that network.

I would guess that some variation of this might help with your situation. 

> On Jan 20, 2020, at 8:24 AM, Tony Brian Albers via FreeIPA-users 
>  wrote:
> 
> On Mon, 2020-01-20 at 13:55 +0200, Alexander Bokovoy wrote:
>> On ma, 20 tammi 2020, Tony Brian Albers via FreeIPA-users wrote:
>>> Ok guys,
>>> 
>>> I have a FreeIPA server with 2 interfaces. The primary is for
>>> normal
>>> usage and is the one that FreeIPA is set up with with regards to
>>> hostname and services. The other one is on an administrative
>>> network.
>>> The Web UI works fine on the primary interface, but I can't really
>>> access it on the other interface. It's obvious that the services
>>> bind
>>> to the primary interface, but isn't it possible to access the UI on
>>> the
>>> other interface somehow?
>> 
>> Short answer: not now.
>> For details see 
>> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/VN3RXS36GFK4JMZCCSHPJ3DKLSBEXDE4/
>> 
> 
> Thx Alex,
> 
> I guess we'll manage without.
> 
> /tony
> ___
> 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: Kerberized NFS Home directories

[Charles Hedrick via FreeIPA-users]

another issue to beware of. In my copy of ubuntu 18, common-auth has pam_unix 
before pam_sss, and its set so that if pam_unix succeeds, it skips pam_sss. 
That means that if the user has an entry in /etc/passwd and they type a 
password matching that entry, it will skip the Kerberos authentication, and 
you’ll end up without a Kerberos credential.

On Jan 17, 2020, at 4:33 PM, Charles Hedrick via FreeIPA-users 
mailto:freeipa-users@lists.fedorahosted.org>>
 wrote:

If it works for one login type and not for the other, chances are there’s a 
different tin the pam configuration files. Each service, which would include 
gdm and sshd, has a configuration file in /etc/pam.d, which determines how 
authentication is done. If you are using sssd for your authentication (which I 
recommend) authentication is done with an auth entry using pam_sss. The file 
you want to look at it /var/log/auth.log.

You don’t want anything that relies on the user having a Kerberos ticket to 
come before the pam_sss entry (which will likely be in common-auth, including 
from the sshd and gdm files). You also don’t want anything that might need 
access to files, including config files in the home directory, to come before 
the ticket is there.

On Jan 17, 2020, at 12:16 PM, Kristian Petersen via FreeIPA-users 
mailto:freeipa-users@lists.fedorahosted.org>>
 wrote:

The host is enrolled in Red Hat IdM and (as I understand it) pulls a kerberos 
key from the IdM server on login when the user in from IdM.  From looking at 
the syslog, it authenticates me, begins a session, and then the failure occurs. 
 I can see that it has pulled down info about my user account in the syslog 
before it fails.  Some of the lines I see in the syslog are:
zorin systemd[1]: Started Session 4 of user 
sam...@chem.byu.edu<mailto:sam...@chem.byu.edu>.

kernel: [  134.496794] lockd: server fs2.chem.byu.edu<http://fs2.chem.byu.edu/> 
not responding, still trying
.
.and after some other normal stuff we eventually we get to...
.
Jan 16 12:17:11 zorin kernel: [  153.305521] lockd: server 
fs2.chem.byu.edu<http://fs2.chem.byu.edu/> not responding, still trying
Jan 16 12:17:11 zorin gnome-session[1545]: gnome-session-binary[1545]: WARNING: 
Application 'org.gnome.Shell.desktop' failed to register before timeout
Jan 16 12:17:11 zorin gnome-session[1545]: gnome-session-binary[1545]: 
CRITICAL: We failed, but the fail whale is dead. Sorry
Jan 16 12:17:11 zorin gnome-session-binary[1545]: Unrecoverable failure in 
required component org.gnome.Shell.desktop
Jan 16 12:17:11 zorin gnome-session-binary[1545]: WARNING: Application 
'org.gnome.Shell.desktop' failed to register before timeout
Jan 16 12:17:11 zorin gnome-session-binary[1545]: CRITICAL: We failed, but the 
fail whale is dead. Sorry
Jan 16 12:17:11 zorin at-spi-bus-launcher[1649]: XIO:  fatal IO error 11 
(Resource temporarily unavailable) on X server ":0"
On Fri, Jan 17, 2020 at 9:48 AM Simo Sorce 
mailto:s...@redhat.com>> wrote:
On Fri, 2020-01-17 at 09:35 -0700, Kristian Petersen via FreeIPA-users
wrote:
> Hey all,
>
> I am trying to get kerberized NFS home directories working in Ubuntu 18.04
> with the mapping info coming from IPA.  I can get them to mount on login in
> a multi-user target (terminal only), but not a graphical one (using gdm for
> login).  The messages I am seeing in the syslog seem to indicate that it is
> having issues communicating with the server hosting the NFS share and times
> out.  That doesn't make sense though since it works to mount in the
> terminal like I would expect.

Is GDM trying to mount or walk the home directory *before* performing
authentication?
Or are you tying to manually mount/walk in the home in a terminal and
failing?

A failure indicates that the rpc.gssd daemon cannot find kerberos
credentials of the user.

What kind of credential cache do you use? Is it the same between
graphical and console logins? Do you use rpc.gssd integrated with gss-
proxy or standalone?

Simo.

--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc






--
Kristian Petersen
System Administrator
BYU Dept. of Chemistry and Biochemistry
___
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/
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<mailto:freeipa-users@lists.fedorahosted.org>
To unsubscribe send an email to 
freeipa-users-le...@lists.fedorah

[Freeipa-users] Re: Kerberized NFS Home directories

[Charles Hedrick via FreeIPA-users]

If it works for one login type and not for the other, chances are there’s a 
different tin the pam configuration files. Each service, which would include 
gdm and sshd, has a configuration file in /etc/pam.d, which determines how 
authentication is done. If you are using sssd for your authentication (which I 
recommend) authentication is done with an auth entry using pam_sss. The file 
you want to look at it /var/log/auth.log.

You don’t want anything that relies on the user having a Kerberos ticket to 
come before the pam_sss entry (which will likely be in common-auth, including 
from the sshd and gdm files). You also don’t want anything that might need 
access to files, including config files in the home directory, to come before 
the ticket is there.

On Jan 17, 2020, at 12:16 PM, Kristian Petersen via FreeIPA-users 
mailto:freeipa-users@lists.fedorahosted.org>>
 wrote:

The host is enrolled in Red Hat IdM and (as I understand it) pulls a kerberos 
key from the IdM server on login when the user in from IdM.  From looking at 
the syslog, it authenticates me, begins a session, and then the failure occurs. 
 I can see that it has pulled down info about my user account in the syslog 
before it fails.  Some of the lines I see in the syslog are:
zorin systemd[1]: Started Session 4 of user 
sam...@chem.byu.edu.

kernel: [  134.496794] lockd: server fs2.chem.byu.edu 
not responding, still trying
.
.and after some other normal stuff we eventually we get to...
.
Jan 16 12:17:11 zorin kernel: [  153.305521] lockd: server 
fs2.chem.byu.edu not responding, still trying
Jan 16 12:17:11 zorin gnome-session[1545]: gnome-session-binary[1545]: WARNING: 
Application 'org.gnome.Shell.desktop' failed to register before timeout
Jan 16 12:17:11 zorin gnome-session[1545]: gnome-session-binary[1545]: 
CRITICAL: We failed, but the fail whale is dead. Sorry
Jan 16 12:17:11 zorin gnome-session-binary[1545]: Unrecoverable failure in 
required component org.gnome.Shell.desktop
Jan 16 12:17:11 zorin gnome-session-binary[1545]: WARNING: Application 
'org.gnome.Shell.desktop' failed to register before timeout
Jan 16 12:17:11 zorin gnome-session-binary[1545]: CRITICAL: We failed, but the 
fail whale is dead. Sorry
Jan 16 12:17:11 zorin at-spi-bus-launcher[1649]: XIO:  fatal IO error 11 
(Resource temporarily unavailable) on X server ":0"
On Fri, Jan 17, 2020 at 9:48 AM Simo Sorce 
mailto:s...@redhat.com>> wrote:
On Fri, 2020-01-17 at 09:35 -0700, Kristian Petersen via FreeIPA-users
wrote:
> Hey all,
>
> I am trying to get kerberized NFS home directories working in Ubuntu 18.04
> with the mapping info coming from IPA.  I can get them to mount on login in
> a multi-user target (terminal only), but not a graphical one (using gdm for
> login).  The messages I am seeing in the syslog seem to indicate that it is
> having issues communicating with the server hosting the NFS share and times
> out.  That doesn't make sense though since it works to mount in the
> terminal like I would expect.

Is GDM trying to mount or walk the home directory *before* performing
authentication?
Or are you tying to manually mount/walk in the home in a terminal and
failing?

A failure indicates that the rpc.gssd daemon cannot find kerberos
credentials of the user.

What kind of credential cache do you use? Is it the same between
graphical and console logins? Do you use rpc.gssd integrated with gss-
proxy or standalone?

Simo.

--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc






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

[Charles Hedrick via FreeIPA-users]

I’ve thought about this a bit more. I think it would be useful if log entries 
showing changes could be routed differently by syslog. The simplest would be to 
use a different log level, e.g. NOTICE, where other things are INFO. Another 
approach would be to put a specific tag in the try, e.g. AUDIT.

On Jan 15, 2020, at 5:20 PM, Angus Clarke 
mailto:p...@angusclarke.com>> wrote:

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 mailto:hedr...@rutgers.edu>>
Sent: 15 January 2020 22:54
To: FreeIPA users list 
mailto:freeipa-users@lists.fedorahosted.org>>
Cc: Ryan Slominski mailto:ry...@jlab.org>>; Angus Clarke 
mailto:p...@angusclarke.com>>
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>>
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
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: 

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

[Charles Hedrick via FreeIPA-users]

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

[Charles Hedrick via FreeIPA-users]

Most of our IPA activity occurs through a local web application. It logs all 
IPA commands that it issues. This includes creating user, managing groups, etc. 
I will say that this log has proven really useful. However it doesn’t capture 
IPA commands issued directly. It would be really great for the IPA server to 
log commands some format that’s fairly easy to make sense of.

> On Jan 15, 2020, at 2:28 PM, Ryan Slominski via FreeIPA-users 
>  wrote:
> 
> 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] centos 7.6 or 8.0?

[Charles Hedrick via FreeIPA-users]

We have a limited time period when I would prefer to do major changes. I had 
expected to update our Centos 7.6 to 8 during January. Unfortunately it appears 
that there have been no updates to 8, pending 8.1 and 8.1 is waiting for a 
surprising mount of time. I have a test 8.0 installation, and it works, but 
obviously it isn’t under any load. Would you feel safer with 7.6 or 8.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: ipa-getkeytab -r for user keytabs

[Charles Hedrick via FreeIPA-users]

Here’s an approach that will work if you’re on the kdc. Become root. Run 
kadmin.local.

ktadd -k XXX.kt -norandkey XXX

-rorandley is the equivalent of -r

That creates a key table XXX.kt (or adds to if it already exists). No password 
needed except what you normally do to become root.

On Nov 22, 2019, at 3:48 PM, Dmitry Perets 
mailto:dmitry.per...@gmail.com>> wrote:

Oh ok, so I just need to create IPA host and let admin fetch its keytab on all 
real hosts running the service. Fair enough, thanks!

Btw in the meantime I discovered that it is possible to retrieve user's keytab 
with "ipa-getkeytab -r" if you authenticate as "cn=Directory Manager". 
Apparently, it has the rights to do this. But the only way then is by 
specifying its password in command line with "ipa-getkeytab -w" (it doesn't 
support prompting you securely, like kinit or ldapsearch do). So it is NOT a 
good idea to do so, unless you then clean up your history etc Better not :)

___
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: ipa-getkeytab -r for user keytabs

[Charles Hedrick via FreeIPA-users]

You can always fetch key tables using kadmin.local on one of the kdc’s.

I haven't actually tried using ipa-getkeytab on the wrong host. I just copied 
the key table. I doubt ipa-getkeytab checks that the hostname matches, but it’s 
always possible.

On Nov 22, 2019, at 3:48 PM, Dmitry Perets 
mailto:dmitry.per...@gmail.com>> wrote:

Oh ok, so I just need to create IPA host and let admin fetch its keytab on all 
real hosts running the service. Fair enough, thanks!

Btw in the meantime I discovered that it is possible to retrieve user's keytab 
with "ipa-getkeytab -r" if you authenticate as "cn=Directory Manager". 
Apparently, it has the rights to do this. But the only way then is by 
specifying its password in command line with "ipa-getkeytab -w" (it doesn't 
support prompting you securely, like kinit or ldapsearch do). So it is NOT a 
good idea to do so, unless you then clean up your history etc Better not :)

---
Regards,
Dmitry Perets

On Fri, 22 Nov 2019, 21:01 Alexander Bokovoy, 
mailto:aboko...@redhat.com>> wrote:
On pe, 22 marras 2019, Charles Hedrick wrote:
>Bound in the sense that it has the hostname as part of the principal,
>not in the sense that there’s any actual connection with that host when
>you use it.
>
>Dmitry Perets wants to use the same principal and key table on several
>hosts. They can simply create a principal for one of them. It and its
>key table can be used anywhere. We do it regularly. I would prefer this
>not to work, but it does.

Correct. And it doesn't need any of the newer functionality too.

>
>On Nov 22, 2019, at 2:40 PM, Alexander Bokovoy 
>mailto:aboko...@redhat.com>>>
> wrote:
>
>No, this is not really what it is. Service principals are always bound
>to a host name but starting with FreeIPA 4.7.0 it is possible to create
>service principals that have no host object with the same host name.
>


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland


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

[Freeipa-users] Re: ipa-getkeytab -r for user keytabs

[Charles Hedrick via FreeIPA-users]

Bound in the sense that it has the hostname as part of the principal, not in 
the sense that there’s any actual connection with that host when you use it.

Dmitry Perets wants to use the same principal and key table on several hosts. 
They can simply create a principal for one of them. It and its key table can be 
used anywhere. We do it regularly. I would prefer this not to work, but it does.

On Nov 22, 2019, at 2:40 PM, Alexander Bokovoy 
mailto:aboko...@redhat.com>> wrote:

No, this is not really what it is. Service principals are always bound
to a host name but starting with FreeIPA 4.7.0 it is possible to create
service principals that have no host object with the same host name.

___
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: ipa-getkeytab -r for user keytabs

[Charles Hedrick via FreeIPA-users]

service principals have never been bound to hosts. The hostname is just part of 
the principal name. It’s not enforced. Pick whatever hostname you want. (I 
actually think this is a bug.)

On Nov 22, 2019, at 2:14 PM, Dmitry Perets 
mailto:dmitry.per...@gmail.com>> wrote:

Hi,

Can you please remind me from which IPA version you support service principals 
not bound to hosts? I think that would be then a better solution for my case, 
as I am really using this user for non-interactive workloads.

And in the meantime, what is the nicest solution for some service that has 
instances on multiple hosts? I could of course define separate service 
principals for each one of them (e.g.. MYSVC/hostname), but if - for example - 
they need to read secrets from the same shared Vault, I then must add all of 
them as its members. And there are 30 instances... That is why I thought to let 
them authenticate with the same principal.

Any solution for this in current version of IPA (4.6)?

---
Regards,
Dmitry Perets

On Fri, 22 Nov 2019, 20:05 Alexander Bokovoy, 
mailto:aboko...@redhat.com>> wrote:
On pe, 22 marras 2019, Charles Hedrick via FreeIPA-users wrote:
>Interesting idea, but seems to require a time machine. The kerberos in
>centos 8 is 1.16. I believe Ubuntu 18 is also.

Actually, I did check of the source code commits in upstream MIT
Kerberos and I attributed it wrongly. '-f' is part of 1.17 release and
'-s' is in 1.16 release. So, it should be in RHEL 8.

>On Nov 22, 2019, at 1:21 PM, Alexander Bokovoy via FreeIPA-users
>mailto:freeipa-users@lists.fedorahosted.org><mailto:freeipa-users@lists.fedorahosted.org<mailto:freeipa-users@lists.fedorahosted.org>>>
>wrote:
>
>ktutil> add_entry -password -p principal -k kvno -f
>
>The key part here is '-f' which fetches a salt from KDC. Otherwise,
>you'd need to use '-s salt' option to specify a salt manually. Option
>'-f' appeared in MIT 1.18, '-s' in MIT Kerberos 1.17.
>


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland


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

[Freeipa-users] Re: ipa-getkeytab -r for user keytabs

[Charles Hedrick via FreeIPA-users]

Incidentally, I’m not entirely sure we want this to work. We’re concerned about 
what happens if a system is compromised. That’s a concern because many of our 
systems are run by grad students. With root you could get a copy of someone 
else’s key table. At that point you could use it on any machine in the system, 
and the real user would probably never know.

We use a daemon that allows a user to register that they want to be able to do 
cron jobs (could be used for other things) on that system. The client can fetch 
a credential, which is locked to the IP address and not forward able. (The 
primary intent is to use it with NFS. It doesn’t need forward able 
credentials.) 

> On Nov 22, 2019, at 2:04 PM, Alexander Bokovoy  wrote:
> 
> On pe, 22 marras 2019, Charles Hedrick via FreeIPA-users wrote:
>> Interesting idea, but seems to require a time machine. The kerberos in
>> centos 8 is 1.16. I believe Ubuntu 18 is also.
> 
> Actually, I did check of the source code commits in upstream MIT
> Kerberos and I attributed it wrongly. '-f' is part of 1.17 release and
> '-s' is in 1.16 release. So, it should be in RHEL 8.
> 
>> On Nov 22, 2019, at 1:21 PM, Alexander Bokovoy via FreeIPA-users
>> mailto:freeipa-users@lists.fedorahosted.org>>
>> wrote:
>> 
>> ktutil> add_entry -password -p principal -k kvno -f
>> 
>> The key part here is '-f' which fetches a salt from KDC. Otherwise,
>> you'd need to use '-s salt' option to specify a salt manually. Option
>> '-f' appeared in MIT 1.18, '-s' in MIT Kerberos 1.17.
>> 
> 
> 
> -- 
> / Alexander Bokovoy
> Sr. Principal Software Engineer
> Security / Identity Management Engineering
> Red Hat Limited, Finland
> 

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

[Freeipa-users] Re: ipa-getkeytab -r for user keytabs

[Charles Hedrick via FreeIPA-users]

In centos 8, the man page for ktuil says 1.16.1. -f isn’t in the man page nor 
does it work. yum also shows the version of 1.16.1.

-s is there but not -f. When I tried it without -f the resulting key table 
didn’t work.

Ubuntu 20.4 will be out shortly. Hopefully Centos 8.x will include 17. But for 
the moment this isn’t a realistic solution.

On Nov 22, 2019, at 2:04 PM, Alexander Bokovoy 
mailto:aboko...@redhat.com>> wrote:

Actually, I did check of the source code commits in upstream MIT
Kerberos and I attributed it wrongly. '-f' is part of 1.17 release and
'-s' is in 1.16 release. So, it should be in RHEL 8.

___
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: ipa-getkeytab -r for user keytabs

[Charles Hedrick via FreeIPA-users]

Interesting idea, but seems to require a time machine. The kerberos in centos 8 
is 1.16. I believe Ubuntu 18 is also.

On Nov 22, 2019, at 1:21 PM, Alexander Bokovoy via FreeIPA-users 
mailto:freeipa-users@lists.fedorahosted.org>>
 wrote:

ktutil> add_entry -password -p principal -k kvno -f

The key part here is '-f' which fetches a salt from KDC. Otherwise,
you'd need to use '-s salt' option to specify a salt manually. Option
'-f' appeared in MIT 1.18, '-s' in MIT Kerberos 1.17.

___
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: what is the difference between idm:client and idm:DL1

[Charles Hedrick via FreeIPA-users]

so it’s valid to use DL1 on a system that isn’t a KDC but needs some package 
such as the proxy that isn’t in client?

> On Nov 11, 2019, at 2:28 PM, Rob Crittenden  wrote:
> 
> Charles Hedrick via FreeIPA-users wrote:
>> In Centos 8, there are two streams for idm software. You need DL1 for a 
>> server. But it seems to have client software as well. Is that the same in 
>> both streams? We have a web server with the KDC proxy. It appears that we 
>> would need DL1 to get that. Is that reasonable for a system that isn’t a KDC?
> 
> DL1 contains ipa-client because a master is a client of itself.
> 
> As to your stream question sure, it's appropriate. The client stream is
> for pure clients that don't run any IPA services on them.
> 
> 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] what is the difference between idm:client and idm:DL1

[Charles Hedrick via FreeIPA-users]

In Centos 8, there are two streams for idm software. You need DL1 for a server. 
But it seems to have client software as well. Is that the same in both streams? 
We have a web server with the KDC proxy. It appears that we would need DL1 to 
get that. Is that reasonable for a system that isn’t a KDC?
___
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: IPA healthcheck for older versions

[Charles Hedrick via FreeIPA-users]

Wouldn’t that also expose the main web UI, and IPA commands? Seems like a much 
larger attack surface.

On Nov 11, 2019, at 1:27 PM, Alex Corcoles 
mailto:a...@corcoles.net>> wrote:

On Mon, Nov 11, 2019 at 5:45 PM Charles Hedrick 
mailto:hedr...@rutgers.edu>> wrote:
I use Kerberos at home. So do a couple of faculty. I have a Kerberos https: 
proxy set up on one of our public web servers. This is less than ideal, as it 
requires installing separate Kerberos software for both Mac and Windows. The 
Kerberos protocol is standardized across OSs, but not the proxy support (nor 
the OTP support).

Oh, FreeIPA runs a proxy in the standard setup (see 
/etc/httpd/conf.d/ipa-kdc-proxy.conf ), so I suppose clientwise if you just 
expose tcp:443 to the Internet things should just work.

___
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: IPA healthcheck for older versions

[Charles Hedrick via FreeIPA-users]

I use Kerberos at home. So do a couple of faculty. I have a Kerberos https: 
proxy set up on one of our public web servers. This is less than ideal, as it 
requires installing separate Kerberos software for both Mac and Windows. The 
Kerberos protocol is standardized across OSs, but not the proxy support (nor 
the OTP support).

On Nov 11, 2019, at 5:00 AM, Alex Corcoles via FreeIPA-users 
mailto:freeipa-users@lists.fedorahosted.org>>
 wrote:

Yeah, I think running FreeIPA servers on the public Internet is really not a 
supported configuration, so I wouldn't worry too much about this (IMHO, 
supporting running FreeIPA on the public Internet would be nice, but this has 
already been discussed).


___
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] DHCP integration

[Charles Hedrick via FreeIPA-users]

We’re in the process of moving DHCP service to our IPA LDAP server. IN our 
environment it makes sense to include DHCP as part of our centralized system 
management scheme, which is based on IPA.  We seem to be getting about a DHCP 
request per second, so I don’t see this causing a performance problem.

As part of this I’ve created a plugin file that defines most of the DHCP 
commands (global config, subnets, hosts, groups, and pools — not IPV6, classes 
or subclasses, but they wouldn’t be hard to add following the examples in the 
file). Because adding a subnet requires restarting the server, I’m concerned 
about changes in LDAP having errors that would prevent a server start. For that 
reason, the plugin writes a file with the object whose configuration is 
changing, and calls dhcpd in test mode to verify that the configuration is OK. 
If not, the error information is returned to the user. This isn’t necessary for 
host entries, as they are read directly from LDAP. So changes that have to be 
checked are comparatively rare.

We don’t currently using dynamic address allocation, so we don’t have to worry 
about coordinating leases. If we did, we’d using the DHCP server’s standard 
mechanism, and wouldn’t try to put leases into LDAP.



___
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: Disaster Recovery Architecture for IPA servers setup replicating in full mesh

[Charles Hedrick via FreeIPA-users]

On Nov 5, 2019, at 2:25 AM, Florence Blanc-Renaud via FreeIPA-users 
mailto:freeipa-users@lists.fedorahosted.org>>
 wrote:

As a general rule, we recommend rebuilding from an existing replica, rather 
than using backup-restore.

Right. Our strategy is

* all of our systems are VMs. We take snapshots periodically. So in a failure 
we would start from a snapshot rather than trying to restore in some way. You 
could then reinitialize the data from another replica
* installing a replica seems to be more reliable than it used to be. I’ve been 
playing with IPA on Centos 8. I’ve found that remove and recreating replicas 
works fine, even after errors, though before creating a replica after deleting 
it, I look through the configuration file and remove some old info before 
reinstalling. My experience with replicas is documented at 
https://github.com/clhedrick/kerberos/wiki/Setting-up-new-server-%28replica%29-in-an-existing-system#Clearing_remains_of_old_servers
* In general you should be able take a VM snapshot and start it. however I’ve 
noticed a tendency for /etc/dirsrv/slapd-NAME/dse.ldif to be missing. I now 
copy this file somewhere safe every few minutes with a cron job.


___
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?

[Charles Hedrick via FreeIPA-users]

I followed the thread, and I’m not sure you ever got an answer. Generally ipa 
replica install seems to create one replication agreement. The exact 
relationships for 3 servers depends upon which master the replica was created 
from. It could be 2 replicas talking to the original, or 3 in a line. But 
either way there’s two replication agreements. The obvious thing for 3 servers 
is a complete triangle. Without that, failure of the wrong node could cause the 
other two to become disconnected from each other, which is probably not 
desirable. So you’d want to add the third node. Whichever one is missing.

I assume the reason they don’t add more replicas by default is that in larger 
configurations you probably don’t want a fully-connected mesh. 
ipa-replica-install has no way of knowing what your final topology is going to 
be, and no way to guess what replication agreements you really need. So it does 
the minimal necessary to maintain connectivity.

> On Oct 29, 2019, at 4:44 AM, 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?
> 
> 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 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: using SPAKE

[Charles Hedrick via FreeIPA-users]

actually I found a solution to this. You can use a normal commercial cert for 
PKINIT. You just need a couple of extra lines in /etc/krb5.conf. The only 
disadvantage is that you have to have a line in /etc/krb5.conf for each KDC. 
That means you lose the ability to add a KDC and depend upon DNS discovery. Not 
a big deal in our context.

It doesn’t appear that ipa-server-certinstall -k works with a normal commercial 
cert, but it’s not hard to edit /var/kerberos/krb5kdc/kdc.conf to point to the 
cert.

> On Oct 23, 2019, at 11:09 AM, Robbie Harwood via FreeIPA-users 
>  wrote:
> 
> Charles Hedrick  writes:
> 
>> Thanks. So if we’re going to continue using FAST, it would be nice to
>> get “kinit -n” working properly.
>> 
>> We currently use external certificates. The KDC generates certificates
>> for kinit -n if we don’t supply an external cert, and they work, but
>> then I have to get them on all the clients, and update them when they
>> expire. I’d prefer to use an external cert, which could be verified
>> using the normal certificate infrastructure (I assume). However the
>> MIT documentation doesn’t say how to generate a certificate request. I
>> describe how to put the right extension in if I sign it myself but not
>> how to get them into a cert request that an external CA can sign.
>> 
>> Can you point to instructions for generating an appropriate
>> certificate request?
>> 
>> (At the moment I use a local program instead of kinit -n. It generates
>> an anonymous credential cache itself. I prefer to use standard
>> mechanisms where possible.)
> 
> I'm not a cert expert, so hopefully someone can reply with better
> information.  I would look at what krb5 does for its test suite, which
> can be seen here:
> https://github.com/krb5/krb5/tree/master/src/tests/dejagnu/pkinit-certs
> 
> Thanks,
> --Robbie
> ___
> 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: is it possible to enable constrained delegation for only some users?

[Charles Hedrick via FreeIPA-users]

I have something working. It may be enough.

In principle there’s a two-stage process, with cron getting a ticket from 
s4u2self, and then using s4u2proxy get the final nfs credentials. If that 
worked, gssproxy would only be able to get an NFS credential if there’s 
actually a cron job for the user. because the first step would be done by cron 
only at the start of a cron job.

At the moment it doesn’t appear that I can give gssproxy a credential cache 
with the tickets from s4u2self. However I can configure gssproxy to read cron’s 
key table itself, and thus do both steps of the impersonation. That works just 
fine. What it means is that users who use cron jobs will be able to access NFS 
at any time, not just from the cron jobs. But it’s not clear how much 
difference there is in practice. Root can of course su to any user. But root 
can also create a cron job for any user, so requiring there to be a cron job 
doesn’t give any additional real protection.

I did verify that ipaAllowToImpersonate works. I would definitely prefer a way 
to do that through IPA commands.

This looks like a better approach than the daemon I’m currently using.

> On Oct 22, 2019, at 11:43 AM, Alexander Bokovoy  wrote:
> 
> On ti, 22 loka 2019, Charles Hedrick via FreeIPA-users wrote:
>> ok. So delegation works. Now we come to the question of how to
>> configure it in gssproxy. The man page describes the syntax of the file
>> but not how it actually works. Any suggestions?
> 
> That is something for Simo, as gssproxy upstream. Unfortunately, I have
> no time right now to investigate that.
> 
> May be you can file a ticket to gssproxy asking to document that?
> 
> -- 
> / Alexander Bokovoy
> Sr. Principal Software Engineer
> Security / Identity Management Engineering
> Red Hat Limited, Finland
> 

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

[Freeipa-users] Re: is it possible to enable constrained delegation for only some users?

[Charles Hedrick via FreeIPA-users]

ok. So delegation works. Now we come to the question of how to configure it in 
gssproxy. The man page describes the syntax of the file but not how it actually 
works. Any suggestions?


> On Oct 22, 2019, at 9:52 AM, Alexander Bokovoy  wrote:
> 
> On ti, 22 loka 2019, Charles Hedrick wrote:
>> within a department it’s actually pretty good, as long as you know the
>> limitations. I wouldn’t use it as my only security, but it’s a useful
>> supplement to checking a key table.
> You already can write an ebpf filter that would reject AS-REQ requests
> from incorrect locations.
> 
> In a quick internal discussion with Simo and Robbie (Kerberos
> maintainer) we came to a common conclusion we don't want to have this
> supported in MIT Kerberos/FreeIPA.
> 
>> 
>> On Oct 22, 2019, at 9:40 AM, Alexander Bokovoy 
>> mailto:aboko...@redhat.com>> wrote:
>> 
>> Since IP addresses are practically spoofable or NATable, they don't make
>> a good source of policy decision.
>> 
> 
> 
> -- 
> / Alexander Bokovoy
> Sr. Principal Software Engineer
> Security / Identity Management Engineering
> Red Hat Limited, Finland
> 

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

[Freeipa-users] Re: is it possible to enable constrained delegation for only some users?

[Charles Hedrick via FreeIPA-users]

within a department it’s actually pretty good, as long as you know the 
limitations. I wouldn’t use it as my only security, but it’s a useful 
supplement to checking a key table.

On Oct 22, 2019, at 9:40 AM, Alexander Bokovoy 
mailto:aboko...@redhat.com>> wrote:

Since IP addresses are practically spoofable or NATable, they don't make
a good source of policy decision.

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

[Freeipa-users] Re: is it possible to enable constrained delegation for only some users?

[Charles Hedrick via FreeIPA-users]

I just realized a problem with the whole scheme. Our situation may be unusual, 
but we have machines run by users. They can become root. Linux is also not 
provably secure, so I have to worry about it even on systems we administer.

Schemes based on constrained delegation have to start with a service that is 
authorized to get credentials. It’s hard to see any way of doing the original 
service authentication other than a key table. But key tables can be stolen by 
root and used anywhere. Is there any way to get IPA to refuse to grant 
credentials for service/HOST except if the request comes from HOST? I know IP 
addresses aren’t perfect, but our subnets have machines with similar security 
properties, and our switches prevent people from sending packets with a source 
address off their subnet. So IP restrictions are actually worthwhile.

Our current scheme uses a daemon that implements what is effectively 
constrained delegation. Users register that they want to run cron jobs on a 
specific host. We have a pam module used when cron starts are job. It talks to 
the daemon, and gets back a ticket for the user, if the user has authorized it. 
The daemon won’t return a ticket unless the request comes from root on a host 
that the user has authorized. The tickets returned by the daemon have the IP 
address set, and the forward bit off, so they’re as constrained as I can make 
them. It could be that we should actually return just an NFS service ticket 
rather than a TGT.

> On Oct 22, 2019, at 7:18:58 AM, Alexander Bokovoy  wrote:
> 
> On ti, 22 loka 2019, Charles Hedrick wrote:
>> Thanks. This is what I’m looking to do. The main question was doing it
>> only for some users. The IPA commands to set it up, and the
>> documentation, don’t show any way to limit delegation to specific
>> users. But the text file describes an additional attribute. It is
>> described one place as not implemented, but I looked at the IPA source,
>> and it looks like it is implemented. I’ll try this. If it works it
>> would be a significant improvement for us.
> Yes. Please share your findings, even if negative. Perhaps, we would
> need to add something to support his case. At least,
> ipaAllowToImpersonate needs to be added into IPA framework to allow
> manage it.
> 
>> 
>>> On Oct 22, 2019, at 6:22 AM, Alexander Bokovoy  wrote:
>>> 
>>> On ma, 21 loka 2019, Charles Hedrick via FreeIPA-users wrote:
>>>> We have kerberos everywhere, and use it for access to NFS home
>>>> directories.
>>>> 
>>>> So what do we do about cron jobs? We have a solution, but it involves
>>>> custom code that impersonates the KDC. I’d like to do someone more
>>>> standard.
>>>> 
>>>> Constained delegation seems like a possibility. But I’d need to be able
>>>> to say “allow cron to get credentials for NFS for a specific group of
>>>> users.” Since all of our systems run cron, I don’t want to allow any
>>>> system to be able to get an NFS credential for any user. That would let
>>>> root on any system see anyone’s files. So the user has to authorize it.
>>>> Presumably if the user runs his own desktop, he’s willing to allow it
>>>> to get credentials for himself. But I wouldn’t trust his machine to be
>>>> able to get mine.
>>>> 
>>>> The constrained delegation mechanism seems to handle this, except that
>>>> I don’t see a way to constrain it to specific users. Am I missing
>>>> something?
>>> There are two parts here: S4U2Self and S4U2Proxy. The former is for
>>> allowing protocol transition: a service can claim that it has
>>> authenticated the user some way beyond Kerberos and now want a service
>>> ticket to itself from that user. Once the service has a ticket to
>>> itself, S4U2Proxy can be used to operate on behalf of that user against
>>> another service. The right to allow it is on the KDC side and in FreeIPA
>>> we use it, for example, to operate on behalf of a user when managing IPA
>>> itself (IPA management framework runs in Apache and talks to LDAP and
>>> Samba with SASL GSS-SPNEGO).
>>> 
>>> We don't have nice tools to enable constraint delegation in an easy way
>>> (and there is no templating) but you can look at 
>>> https://pagure.io/freeipa/blob/master/f/daemons/ipa-kdb/README.s4u2proxy.txt
>>> and
>>> https://pagure.io/freeipa/blob/master/f/install/share/bootstrap-template.ldif#_200
>>> (until line 221)
>>> 
>>> Also, you don't need to use kadmin.local as in the README document, it
>>> is now possible to change Kerberos flags through 'ipa servic

[Freeipa-users] Re: is it possible to enable constrained delegation for only some users?

[Charles Hedrick via FreeIPA-users]

Thanks. This is what I’m looking to do. The main question was doing it only for 
some users. The IPA commands to set it up, and the documentation, don’t show 
any way to limit delegation to specific users. But the text file describes an 
additional attribute. It is described one place as not implemented, but I 
looked at the IPA source, and it looks like it is implemented. I’ll try this. 
If it works it would be a significant improvement for us. 

> On Oct 22, 2019, at 6:22 AM, Alexander Bokovoy  wrote:
> 
> On ma, 21 loka 2019, Charles Hedrick via FreeIPA-users wrote:
>> We have kerberos everywhere, and use it for access to NFS home
>> directories.
>> 
>> So what do we do about cron jobs? We have a solution, but it involves
>> custom code that impersonates the KDC. I’d like to do someone more
>> standard.
>> 
>> Constained delegation seems like a possibility. But I’d need to be able
>> to say “allow cron to get credentials for NFS for a specific group of
>> users.” Since all of our systems run cron, I don’t want to allow any
>> system to be able to get an NFS credential for any user. That would let
>> root on any system see anyone’s files. So the user has to authorize it.
>> Presumably if the user runs his own desktop, he’s willing to allow it
>> to get credentials for himself. But I wouldn’t trust his machine to be
>> able to get mine.
>> 
>> The constrained delegation mechanism seems to handle this, except that
>> I don’t see a way to constrain it to specific users. Am I missing
>> something?
> There are two parts here: S4U2Self and S4U2Proxy. The former is for
> allowing protocol transition: a service can claim that it has
> authenticated the user some way beyond Kerberos and now want a service
> ticket to itself from that user. Once the service has a ticket to
> itself, S4U2Proxy can be used to operate on behalf of that user against
> another service. The right to allow it is on the KDC side and in FreeIPA
> we use it, for example, to operate on behalf of a user when managing IPA
> itself (IPA management framework runs in Apache and talks to LDAP and
> Samba with SASL GSS-SPNEGO).
> 
> We don't have nice tools to enable constraint delegation in an easy way
> (and there is no templating) but you can look at 
> https://pagure.io/freeipa/blob/master/f/daemons/ipa-kdb/README.s4u2proxy.txt
> and
> https://pagure.io/freeipa/blob/master/f/install/share/bootstrap-template.ldif#_200
> (until line 221)
> 
> Also, you don't need to use kadmin.local as in the README document, it
> is now possible to change Kerberos flags through 'ipa service-mod'.
> 
> In cron environment you don't have user's credentials or existing TGT.
> So you'd use S4U2Self as a 'cron' service to request one. You may want
> to protect access to 'cron' service credentials with GSS-Proxy and use
> keytab-based initialization there, also allowing both protocol
> transition and constrained delegation. 
> However, something needs to perform S4U2Self first. The document above
> mentions use of kinit/kvno tools. However, these tools are raw Kerberos,
> they do not support using GSS-Proxy. You need something that uses
> GSSAPI, not low-level Kerberos APIs. For example, python-gssapi could be
> used to build a simple app or you might write GSSAPI application in C,
> similar to 
> https://github.com/krb5/krb5/blob/master/src/tests/gssapi/t_s4u2proxy_krb5.c
> and https://github.com/krb5/krb5/blob/master/src/tests/gssapi/t_s4u.c
> 
> -- 
> / 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] is it possible to enable constrained delegation for only some users?

[Charles Hedrick via FreeIPA-users]

We have kerberos everywhere, and use it for access to NFS home directories.

So what do we do about cron jobs? We have a solution, but it involves custom 
code that impersonates the KDC. I’d like to do someone more standard.

Constained delegation seems like a possibility. But I’d need to be able to say 
“allow cron to get credentials for NFS for a specific group of users.” Since 
all of our systems run cron, I don’t want to allow any system to be able to get 
an NFS credential for any user. That would let root on any system see anyone’s 
files. So the user has to authorize it. Presumably if the user runs his own 
desktop, he’s willing to allow it to get credentials for himself. But I 
wouldn’t trust his machine to be able to get mine.

The constrained delegation mechanism seems to handle this, except that I don’t 
see a way to constrain it to specific users. Am I missing something?

___
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: using SPAKE

[Charles Hedrick via FreeIPA-users]

Thanks. So if we’re going to continue using FAST, it would be nice to get 
“kinit -n” working properly. 

We currently use external certificates. The KDC generates certificates for 
kinit -n if we don’t supply an external cert, and they work, but then I have to 
get them on all the clients, and update them when they expire. I’d prefer to 
use an external cert, which could be verified using the normal certificate 
infrastructure (I assume). However the MIT documentation doesn’t say how to 
generate a certificate request. I describe how to put the right extension in if 
I sign it myself but not how to get them into a cert request that an external 
CA can sign.

Can you point to instructions for generating an appropriate certificate request?

(At the moment I use a local program instead of kinit -n. It generates an 
anonymous credential cache itself. I prefer to use standard mechanisms where 
possible.)

> On Oct 18, 2019, at 2:47 PM, Robbie Harwood  wrote:
> 
> Charles Hedrick via FreeIPA-users 
> writes:
> 
>> I’d like to avoid having to use a second cache to armor 2FA
>> requests. My impression was that SPAKE was supposed to fix this. I
>> just installed a new kdc (replica of an old one) in Centos 8. It
>> understands SPAKE, offering it as preauthebtication for normal
>> users. But a user with 2FA is not offered SPAKE preach. I still have
>> to use FAST.
>> 
>> Have I misunderstood, or is extra configuration needed?
> 
> SPAKE is a variant preauthentication mechanism for acquiring TGTs.  It
> is fully supported in el8.  However, what you're looking for is an
> appropriate 2FA mechanism - currently none of those have been created
> yet.
> 
> What you're after is a planned future goal (but requires me to have more
> time to work on it :) ).
> 
> Thanks,
> --Robbie

___
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] using SPAKE

[Charles Hedrick via FreeIPA-users]

I’d like to avoid having to use a second cache to armor 2FA requests. My 
impression was that SPAKE was supposed to fix this. I just installed a new kdc 
(replica of an old one) in Centos 8. It understands SPAKE, offering it as 
preauthebtication for normal users. But a user with 2FA is not offered SPAKE 
preach. I still have to use FAST.

Have I misunderstood, or is extra configuration needed?

___
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: Online migration from internal CA to no-CA setup

[Charles Hedrick via FreeIPA-users]

this will let you add outside certs for the services that would be visible to 
users: https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP

It doesn’t actually turn off the CA functionality, but it becomes largely 
unused. 

I’d actually be interested in a way to completely move no CAless operation if 
there is one.

> On Oct 3, 2019, at 5:15 AM, Marco V. via FreeIPA-users 
>  wrote:
> 
> Hi,
> 
> We've installed a replicated 7Server IPA setup with a internal CA.
> Now, due to corporate policies we need to migrate to a no-CA setup (because 
> we need to use corporate signed Certificates
> and a sub-CA is also not allowed..) So we need to migrate from 7Server 
> internal-CA replicated IPA to 8Server no-CA replicated IPA.
> 
> ipa-replica-install does not support --ca-cert-file, so we cannot install the 
> new replica with the corporate certificates straight away.
> What would be the correct procedure?
> 
> I've come up with the following steps:
>   1. install the new 8Server replicas without CA, (They will get the 
> self-signed certificates from existing 7Server master (first master))
>   2. first add corporate root CA to both 7Server and 8Server nodes systems 
> ca-bundle.trust.crt
>   3. manually replace HTTP and LDAP certificates with corporated signed 
> certificates
>   4. remove 7Server replica and first master, so we end up with the no-CA 
> 8Server nodes only
> 
> I'm wondering whether replication will still be functional when performing 
> step 3, but I can perform additional testing on that.
> We are running production with our setup, so we need a 'online' migration 
> strategy.
> 
> Would this be the best approach or do I need another solution? ;-)
> ___
> 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: reinstall freeIPA server without loosing data

[Charles Hedrick via FreeIPA-users]

I have another reason to want to do a reinstall.

I have 3 Centos 7 servers. I want to move to Centos 8. (eventually. I’ll do 
some testing first). The official approach is a new installation. Obviously I 
can create 3 replicas and kill the originals. But then I’ll have to find every 
client and update the hostnames of the servers in their configurations. We use 
DNS discovery where possible, but we have software that can’t do it, and of 
course the admin server attribute in krb5.conf doesn’t support it. Trying to 
find everything that needs reconfiguring is going to be a bit of a mess. 

I’d like to end up with new servers having the same hostnames. This is a bit of 
a different situation from the original request, since I have all the data on 3 
servers. Does it make sense to kill a replica and then create a new replica 
with the same hostname?

Last time I tried to kill a replica and reinstall, it failed. There were things 
left over preventing the installation. But that was a couple of years ago, so 
things might be better now.


> On Sep 19, 2019, at 11:51 AM, Albert Szostkiewicz via FreeIPA-users 
>  wrote:
> 
> Thanks for reply Rob!
> 
>> /var/log/krb5kdc.log might have more details on the GSS failures, or the
>> journal.
> 
> Yeah, I've checked that as well. Unfortunately 'Preauthentication failed' Was 
> no more explanatory to me.
> After two weeks of searching for answers, I gave up and decided to reinstall 
> ipa server.
> 
> I guess, one has to have much deeper knowledge to use it properly and I am 
> just a mortal user :)
> 
> /var/log/krb5kdc.log 
> 38:21 (info): TGS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), 
> aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), 
> aes128-cts-hmac-sha256-128(19), DEPRECATED:des3-cbc-sha1(16), 
> DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), 
> camellia256-cts-cmac(26)}) 10.0.1.10: ISSUE: authtime 1568572691, etypes 
> {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18), 
> ses=aes256-cts-hmac-sha1-96(18)}, ad...@home.mydomain.com for 
> HTTP/ipa.home.mydomain@home.mydomain.com
> 38:21 (info): closing down fd 11
> 38:21 (info): AS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), 
> aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), 
> aes128-cts-hmac-sha256-128(19), DEPRECATED:des3-cbc-sha1(16), 
> DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), 
> camellia256-cts-cmac(26)}) 10.0.1.10: NEEDED_PREAUTH: 
> HTTP/ipa.home.mydomain@home.mydomain.com for 
> krbtgt/home.mydomain@home.mydomain.com, Additional pre-authentication 
> required
> 38:21 (info): closing down fd 11
> 38:21 (info): preauth (spake) verify failure: Preauthentication failed
> 38:21 (info): AS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), 
> aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), 
> aes128-cts-hmac-sha256-128(19), DEPRECATED:des3-cbc-sha1(16), 
> DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), 
> camellia256-cts-cmac(26)}) 10.0.1.10: PREAUTH_FAILED: 
> HTTP/ipa.home.mydomain@home.mydomain.com for 
> krbtgt/home.mydomain@home.mydomain.com, Preauthentication failed
> 38:21 (info): closing down fd 11
> 38:21 (info): AS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), 
> aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), 
> aes128-cts-hmac-sha256-128(19), DEPRECATED:des3-cbc-sha1(16), 
> DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), 
> camellia256-cts-cmac(26)}) 10.0.1.10: NEEDED_PREAUTH: 
> HTTP/ipa.home.mydomain@home.mydomain.com for 
> krbtgt/home.mydomain@home.mydomain.com, Additional pre-authentication 
> required
> 38:21 (info): closing down fd 11
> 38:21 (info): preauth (spake) verify failure: Preauthentication failed
> 38:21 (info): AS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), 
> aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), 
> aes128-cts-hmac-sha256-128(19), DEPRECATED:des3-cbc-sha1(16), 
> DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), 
> camellia256-cts-cmac(26)}) 10.0.1.10: PREAUTH_FAILED: 
> HTTP/ipa.home.mydomain@home.mydomain.com for 
> krbtgt/home.mydomain@home.mydomain.com, Preauthentication failed
> 38:21 (info): closing down fd 11
> 
> Cheers!
> ___
> 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: 

[Freeipa-users] how do you update certs for kinit -n?

[Charles Hedrick via FreeIPA-users]

Recent versions of freeipa support kinit -n. However we need a file that has 
certificates from all the servers.

We have three servers. Their certificates renew themselves automatically a few 
hours before expiration. But then we need to concatenate all of them and put 
them on all clients. 

It should be part of the ipa client, or may sssd to retrieve the updated certs. 

We depend upon kinit -n as part of the script for doing kinit for users for 
one-time passwords. I had written a hack that uses a random user with no 
abilities. Until we ca find a way to distribute certs whenever they change I’m 
going to return to the hack rather than kinit -n.

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

[Freeipa-users] Re: can't delete host, apparent problem setting up RA

[Charles Hedrick via FreeIPA-users]

Yes "Removing self-signed CA.” is there.

Our configuration may have confused the upgrader.

We initially did a default install, which sets up certificate management with a 
self-signed cert. Then we moved to a commercial certificate, which was a 
documented procedure. So one of our 3 servers actually has a CA authority 
running, but as far as I know we don’t use it (unless it’s used for the 
self-signed certificates used by “kinit -a”). There were bugs with this 
particular pattern in previous releases. One of my replica installs was a mess 
and required lots of hand fixups, and one of the first upgrades did also. Maybe 
this is a remnant of that. I haven’t had any issues with upgrades in recent 
releases. I have no idea what at the  next replica-install is going to look 
like. I guess I’ll have to do that when we move to Centos 8.

As long as we’re OK with

ra_plugin = dogtag
dogtag_version = 10
enable_ra = True

and it won’t cause trouble for future upgrades, I’m fine. I took those lines 
from the other non-CA replica, so I assume it’s OK.

On Aug 28, 2019, at 4:38 PM, Rob Crittenden 
mailto:rcrit...@redhat.com>> wrote:

Hard to know for sure. It looks like the upgrader will set that when
uninstalling the old selfsign CA. That might still be in
/var/log/ipaupgrade.log. Look for "Removing self-signed CA. Certificates
will need to managed manually."

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

[Freeipa-users] Re: can't delete host, apparent problem setting up RA

[Charles Hedrick via FreeIPA-users]

looks like that was it. 

was

enable_ra = False   
 
ra_plugin = None
 

now:

ra_plugin = dogtag
dogtag_version = 10
enable_ra = True

works

I guess that was wrong from when it was originally set up?

> On Aug 28, 2019, at 4:24 PM, Rob Crittenden  wrote:
> 
> Charles Hedrick via FreeIPA-users wrote:
>> On one of 3 IPA servers (most recent centos 7.6, 4.6.4-10.el7.centos.6). I 
>> can’t delete hosts. error_log show a bunch of python errors, ending in
>> 
>> Wed Aug 28 15:59:11.634233 2019] [:error] [pid 18035]   File 
>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 478, in __do_call
>> [Wed Aug 28 15:59:11.634240 2019] [:error] [pid 18035] ret = 
>> self.run(*args, **options)
>> [Wed Aug 28 15:59:11.634246 2019] [:error] [pid 18035]   File 
>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 800, in run
>> [Wed Aug 28 15:59:11.634252 2019] [:error] [pid 18035] return 
>> self.execute(*args, **options)
>> [Wed Aug 28 15:59:11.634258 2019] [:error] [pid 18035]   File 
>> "/usr/lib/python2.7/site-packages/ipaserver/plugins/cert.py", line 1657, in 
>> execute
>> [Wed Aug 28 15:59:11.634264 2019] [:error] [pid 18035] **options)
>> [Wed Aug 28 15:59:11.634270 2019] [:error] [pid 18035]   File 
>> "/usr/lib/python2.7/site-packages/ipaserver/plugins/cert.py", line 1502, in 
>> _ca_search
>> [Wed Aug 28 15:59:11.634277 2019] [:error] [pid 18035] ra = 
>> self.api.Backend.ra
>> [Wed Aug 28 15:59:11.634283 2019] [:error] [pid 18035]   File 
>> "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 339, in 
>> __getattr__
>> [Wed Aug 28 15:59:11.634289 2019] [:error] [pid 18035] raise 
>> AttributeError(repr(key) + ' ' + repr(self))
>> [Wed Aug 28 15:59:11.634295 2019] [:error] [pid 18035] AttributeError: 'ra' 
>> 
>> 
>> (I modified the error to give more info, but without getting much useful.)
>> 
>> Any idea what’s going on. It looks like self.api.Backend doesn’t have ra 
>> set. It would take quite a while for me to find out where it’s supposed to 
>> be set.
> 
> What are the contents of /etc/ipa/default.conf?
> 
> 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] can't delete host, apparent problem setting up RA

[Charles Hedrick via FreeIPA-users]

On one of 3 IPA servers (most recent centos 7.6, 4.6.4-10.el7.centos.6). I 
can’t delete hosts. error_log show a bunch of python errors, ending in

Wed Aug 28 15:59:11.634233 2019] [:error] [pid 18035]   File 
"/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 478, in __do_call
[Wed Aug 28 15:59:11.634240 2019] [:error] [pid 18035] ret = 
self.run(*args, **options)
[Wed Aug 28 15:59:11.634246 2019] [:error] [pid 18035]   File 
"/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 800, in run
[Wed Aug 28 15:59:11.634252 2019] [:error] [pid 18035] return 
self.execute(*args, **options)
[Wed Aug 28 15:59:11.634258 2019] [:error] [pid 18035]   File 
"/usr/lib/python2.7/site-packages/ipaserver/plugins/cert.py", line 1657, in 
execute
[Wed Aug 28 15:59:11.634264 2019] [:error] [pid 18035] **options)
[Wed Aug 28 15:59:11.634270 2019] [:error] [pid 18035]   File 
"/usr/lib/python2.7/site-packages/ipaserver/plugins/cert.py", line 1502, in 
_ca_search
[Wed Aug 28 15:59:11.634277 2019] [:error] [pid 18035] ra = 
self.api.Backend.ra
[Wed Aug 28 15:59:11.634283 2019] [:error] [pid 18035]   File 
"/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 339, in __getattr__
[Wed Aug 28 15:59:11.634289 2019] [:error] [pid 18035] raise 
AttributeError(repr(key) + ' ' + repr(self))
[Wed Aug 28 15:59:11.634295 2019] [:error] [pid 18035] AttributeError: 'ra' 


(I modified the error to give more info, but without getting much useful.)

Any idea what’s going on. It looks like self.api.Backend doesn’t have ra set. 
It would take quite a while for me to find out where it’s supposed to be set.

___
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: Upgrade path in CentOS 7

[Charles Hedrick via FreeIPA-users]

We’ve done a number of upgrades without problems. I believe we’ve done all 7.x 
versions, though, and not skipped any.

On Jul 3, 2019, at 5:40 PM, John Keates via FreeIPA-users 
mailto:freeipa-users@lists.fedorahosted.org>>
 wrote:

To be safe, I’d just add a new server with the latest of everything, join it to 
the domain and decommission the old one. Not a direct answer to your question, 
I know, but as soon as you are unsure of the upgrade path, putting in those 30 
minutes to do the install-and-replace routine solves it faster than a 
back-and-forth ;-)

In the 3.x and early 4.x versions I’d still upgrade on every release one by 
one, but now, if I miss a few updates, I just don’t bother anymore.

John

On 3 Jul 2019, at 23:36, Christophe TREFOIS via FreeIPA-users 
mailto:freeipa-users@lists.fedorahosted.org>>
 wrote:

Hi,

Is it required to upgrade via every minor release of CentOS, say 7.2,7.3,7.4 
etc to have a successful IPA upgrade, or can one also go from 7.2 to 7.6 
directly?

Any advice will be appreciated,
Thanks,

Chris


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

___
FreeIPA-users 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: Fedora 30 Client

[Charles Hedrick via FreeIPA-users]

It’s hard to guess without seeing your system:

* pam should be set to check both local password and sssd. If the first fails 
you need to go on
* /etc/nsswitch.conf should probably put files before sss
* user info in /etc/passwd should be the same as in IPA. If the UID or group is 
different I could imagine weird effects

> On Jun 29, 2019, at 4:46 PM, Christian Reiss via FreeIPA-users 
>  wrote:
> 
> Hey folks,
> 
> after testing servers, replications et all (all with awesome success) I
> am getting to test with clients.
> 
> Everything is working except Fedora 30 (Workstation, not Server). I can
> do the usual ipa-client-install dance, which will create the kerberos
> information. I can get a kerberos ticket using kinit as well as logging
> in from a remote host to this one.
> 
> However, it is not possible to do a local (gdm) login with valid IPA
> account. Neither with "Other User" nor via normal Linux Console (tty*).
> sudo denies everything but the local login.
> 
> Hint: I am trying to login into the machine that has an existing user
> account. Wait, what?
> 
> 
> [ 10 Minutes later ]
> 
> 
> I created a new user in IPA and logged in from that one. Worked like
> magic. So no non-existent users.
> 
> So assuming that there might be some users that might have accounts
> (read: all  and everyone) -- what's the smartest way to mitigate or migrate?
> 
> Thanks!
> -Chris.
> 
> -- 
> Christian Reiss - em...@christian-reiss.de /"\  ASCII Ribbon
>   supp...@alpha-labs.net   \ /Campaign
> X   against HTML
> WEB alpha-labs.net / \   in eMails
> 
> GPG Retrieval https://gpg.christian-reiss.de
> GPG ID ABCD43C5, 0x44E29126ABCD43C5
> GPG fingerprint = 9549 F537 2596 86BA 733C  A4ED 44E2 9126 ABCD 43C5
> 
> "It's better to reign in hell than to serve in heaven.",
>  John Milton, Paradise lost.
> 
> ___
> 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: secure freeipa exposed to internet

[Charles Hedrick via FreeIPA-users]

2 of our 3 IPA servers are exposed to the Internet. However we have a host 
firewall that limits the hosts that can access us. We use iptables with an 
ipset. I have a cron job that dumps a list of hosts known to IPA and adds them 
to the ipset. So basically we’ll only accept connections from hosts that we 
know about. That was easier for us to manage than to do things on a network 
basis, since we’ve got hosts in lots of subnets. I use the kdcproxy for working 
at home.

Initially I thought we’d expose the IPA web interface. But in the end users 
normally do things with custom web applications I’ve written, so we didn’t need 
to make the IPA web app available. My web application runs on a different 
server.

> On May 21, 2019, at 12:48 PM, Stepan Vardanyan via FreeIPA-users 
>  wrote:
> 
> Hi Natxo, 
> 
>> A vpn between data centers is a best practice. It does not have to be very
>> complex or expensive, openvpn comes to mind, but if you have no experience
>> with vpns I can understand that they can look very hard.
> I have enough experience with OpenVPN) The problem is that we have dozens of 
> AWS accounts (or datacenters) so openvpn server should be set up in every 
> account with proper monitoring, because if VPN fail authentication stop 
> working (sssd cache save some time but it's still one point of failure). 
> Things get worse if we stick with private DNS zone in FreeIPA. This requires 
> setup local DNS forwarding in every AWS account. Maintaining this is pretty 
> hard.
> 
>> This is ok, I would probably bump tls to 1.2 but you may have applications
>> that do not work properly with that so you know better ;-)
> You guess correct) Some legacy applications still in place and they binded to 
> LDAP
> 
>> Take a look at the 'Security hardening' section of the documentation:
>> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/...
> Thanks. WIll take a look
> 
>> This is a bit unclear. All objects in the ldap servers are replicated (all
>> ldap servers are masters).
>> 
>> You do not need to open the whole internet to your environmnent, you can
>> firewall everything but the hosts that need authenticating/authorizing.
> The problem is that AWS is kind of dynamic. If host not use elastic IP 
> (static), but public it will change after instance started and stopped. 
> Firewalling AWS hosts would be nightmare)
> As for HTTP. We would like to keep LDAP consistent. Actually we want master 
> slave schema, trying to achieve it with that dirty way. Problem with multi 
> master is that it give possibility for replication conflicts when 
> simultaneous changes of one object from different replica take place. Even 
> RFC exists which describe it 
> https://tools.ietf.org/html/draft-zeilenga-ldup-harmful-00
> 
> 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://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] upgrade 7 to 8

[Charles Hedrick via FreeIPA-users]

I see that RHEL 8 has been released. It has an in place upgrade option. How 
well (if at all) has inplace upgrade on an IPA server been tested?
___
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: Doing SSO on a non-IPA joined OS X system

[Charles Hedrick via FreeIPA-users]

Kerberos works fine on OS X. as long as you don’t need Two Factor 
authentication or HTTPS proxy. If you need those, install the kerberos5 and ssh 
packages from MacPorts.

ssh, sshd, the NFS client (Kerberized NFS version 3 and 4), Chome and Firefox 
(SPNEGO) all support Kerberos.

I think “join the domain” would simply mean that login uses IPA. I assume you 
can do that, though I haven’t tried. I do kinit manually. Once I have a TGT 
from kinit, everything else works.

ssh:
Edit /etc/ssh/ssh_config. Add  "GSSAPIAuthentication yes”

Firefox. Here’s what the IPA web client says:
Import CA certificate for your IPA realm. This assumes you’re not using 
a commercial cert, which should use a CA that the system already knows about
• Make sure you select all three checkboxes.
• In the address bar of Firefox, type about:config to display the list of 
current configuration options.
• In the Filter field, type negotiate to restrict the list of options.
• Double-click the network.negotiate-auth.trusted-uris entry to display the 
Enter string value dialog box.
• Enter the name of the domain against which you want to authenticate, for 
example, .example.com.

Note that the instructions for Chrome from the IPA webclient don’t work for 
MacOS. See 
https://www.jeffgeerling.com/blogs/jeff-geerling/kerberos-authentication-mac-os 
for the magic “defaults write” commands.



On Apr 24, 2019, at 7:33 AM, Alex Corcoles via FreeIPA-users 
mailto:freeipa-users@lists.fedorahosted.org>>
 wrote:

So I now have an OS X work laptop and did a kinit user@MYDOMAIN and... it 
worked!

I've seen some guides about joining an OS X system to FreeIPA, but I don't 
think I want that (we are not currently joining work OS X systems to a domain, 
but I suppose we will soon- and I guess joining two domains would be hairy), 
but I'm wondering if it's not crazy to kinit, get my Kerberos tickets and get 
SSO for https/ssh?

While having a ticket seems to not be enough to get SSH/Firefox to work, I'm 
wondering if it's viable to get it to work or if it's a waste of time because 
it cannot work or has serious limitations. It's mostly for learning purposes...

Cheers,

Álex
--
   ___
 {~._.~}
  ( Y )
 ()~*~()  mail: alex at corcoles dot net
 (_)-(_)  http://alex.corcoles.net/

___
FreeIPA-users mailing list -- 
freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to 
freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://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: different security policy for login(password+otp) and screenlock (password only) for workstation

[Charles Hedrick via FreeIPA-users]

The purpose of suggesting pam_unix was to get a single prompt. I didn’t expect 
pam_unix to actually authenticate your users.

I thought you had an issue with OTPs. In the newest RH/Centos, the normal pam 
file will prompt separately for password and OTP token. THat’s fine its ssh, 
but many web apps don’t have the ability to prompt separately, and thus will 
fail.

If you set up pam to use pam_unix all the time you’ll get a single prompt, 
which will expect password and OTP key to be on the same line. That will work 
with web apps. Obviously pam_unix won’t understand those password, but it will 
sad the password on the stack, and pam_sss will use it.

> On Mar 29, 2019, at 8:28 AM, Jelle de Jong via FreeIPA-users 
>  wrote:
> 
> Hello everybody,
> 
> I tried the bellow configuration, but I can still only authorize with 
> pass+otp.
> 
> I assume pam_unix.so only works for local users? I only have sssd freeipa 
> users. Is there a way to tell pam_sss.so to only use the password if 
> --user-auth-type=otp is set?
> 
> /etc/pam.d/common-auth
> 
> auth[success=2 default=ignore] pam_succeed_if.so service in 
> mate-screensaver:lightdm:xrdp-sesman
> auth[default=1 ignore=ignore success=ok] pam_succeed_if.so uid >= 
> 1000 quiet
> auth[default=1 ignore=ignore success=ok] pam_localuser.so
> authsufficientpam_unix.so nullok try_first_pass
> authrequisite pam_succeed_if.so uid >= 1000 quiet_success
> authsufficientpam_sss.so forward_pass
> authrequisite pam_deny.so
> authrequired  pam_permit.so
> authoptional  pam_ecryptfs.so unwrap
> authoptional  pam_cap.so
> 
> Mar 29 13:19:01 workstation01 mate-screensaver-dialog: 
> pam_succeed_if(mate-screensaver:auth): requirement "service in 
> mate-screensaver:lightdm:xrdp-sesman" was met by user "jdejong"
> Mar 29 13:19:49 workstation01 mate-screensaver-dialog: 
> pam_unix(mate-screensaver:auth): authentication failure; logname= 
> uid=350600026 euid=350600026 tty=:10.0 ruser= rhost=  user=jdejong
> Mar 29 13:19:50 workstation01 mate-screensaver-dialog: 
> pam_sss(mate-screensaver:auth): authentication success; logname= 
> uid=350600026 euid=350600026 tty=:10.0 ruser= rhost= user=jdejong
> 
> Kind regards,
> 
> Jelle de Jong
> 
> On 26/03/2019 18:04, Charles Hedrick via FreeIPA-users wrote:
>> Basically if you put pam_unix before pam_sss, you’ll get a single prompt, 
>> and things like RDP will work with OTP.
>> Here’s the default in password-auth and system-auth for Centos 7
>> auth[default=1 ignore=ignore success=ok] pam_succeed_if.so uid >= 
>> 1000 quiet
>> auth[default=1 ignore=ignore success=ok] pam_localuser.so
>> authsufficientpam_unix.so nullok try_first_pass
>> authrequisite pam_succeed_if.so uid >= 1000 quiet_success
>> authsufficientpam_sss.so forward_pass
>> This causes local users and users with UID <  1000 to use Unix, otherwise go 
>> directly to sss.
>> You can add another line to test for specific services, and force pam_unix, 
>> i.e. a single prompt, e.g.
>> auth[success=2 default=ignore] pam_succeed_if.so service in 
>> lightdm:xrdp-sesman.
>> auth[default=1 ignore=ignore success=ok] pam_succeed_if.so uid >= 
>> 1000 quiet
>> auth[default=1 ignore=ignore success=ok] pam_localuser.so
>> authsufficientpam_unix.so nullok try_first_pass
>> authrequisite pam_succeed_if.so uid >= 1000 quiet_success
>> authsufficientpam_sss.so forward_pass
>> The one that gets messy is x2go, because it uses ssh, and can’t be detected 
>> by a service test.
>>> On Mar 19, 2019, at 2:16 PM, Jelle de Jong via FreeIPA-users 
>>>  wrote:
>>> 
>>> Hello everybody,
>>> 
>>> Thank you all for replying.
>>> 
>>> On 18/03/2019 20:44, Jakub Hrozek wrote:
>>>> On Mon, Mar 18, 2019 at 06:14:16PM +0200, Alexander Bokovoy wrote:
>>>>> On ma, 18 maalis 2019, Jelle de Jong via FreeIPA-users wrote:
>>>>>> Hello everybody,
>>>>>> 
>>>>>> 
>>>>>> I am looking for a way to have different authentication policy for a
>>>>>> freeia-client logout and screenlock on linux workstations.
>>>>>> 
>>>>>> When a user logs in I want to use my password+otp (this is working)!
>>>>>> 
>>>>>> When a user locks it screen I want to be able unlock it with only the
>>>>>> password.
>>>>>> 
>>>>&

[Freeipa-users] Re: different security policy for login(password+otp) and screenlock (password only) for workstation

[Charles Hedrick via FreeIPA-users]

Basically if you put pam_unix before pam_sss, you’ll get a single prompt, and 
things like RDP will work with OTP.

Here’s the default in password-auth and system-auth for Centos 7

auth[default=1 ignore=ignore success=ok] pam_succeed_if.so uid >= 1000 
quiet
auth[default=1 ignore=ignore success=ok] pam_localuser.so
authsufficientpam_unix.so nullok try_first_pass
authrequisite pam_succeed_if.so uid >= 1000 quiet_success
authsufficientpam_sss.so forward_pass

This causes local users and users with UID <  1000 to use Unix, otherwise go 
directly to sss.
You can add another line to test for specific services, and force pam_unix, 
i.e. a single prompt, e.g.

auth[success=2 default=ignore] pam_succeed_if.so service in 
lightdm:xrdp-sesman.
auth[default=1 ignore=ignore success=ok] pam_succeed_if.so uid >= 1000 
quiet
auth[default=1 ignore=ignore success=ok] pam_localuser.so
authsufficientpam_unix.so nullok try_first_pass
authrequisite pam_succeed_if.so uid >= 1000 quiet_success
authsufficientpam_sss.so forward_pass

The one that gets messy is x2go, because it uses ssh, and can’t be detected by 
a service test.

> On Mar 19, 2019, at 2:16 PM, Jelle de Jong via FreeIPA-users 
>  wrote:
> 
> Hello everybody,
> 
> Thank you all for replying.
> 
> On 18/03/2019 20:44, Jakub Hrozek wrote:
>> On Mon, Mar 18, 2019 at 06:14:16PM +0200, Alexander Bokovoy wrote:
>>> On ma, 18 maalis 2019, Jelle de Jong via FreeIPA-users wrote:
 Hello everybody,
 
 
 I am looking for a way to have different authentication policy for a
 freeia-client logout and screenlock on linux workstations.
 
 When a user logs in I want to use my password+otp (this is working)!
 
 When a user locks it screen I want to be able unlock it with only the
 password.
 
 When a user logs out and back in then it needs to use the password+otp
 again.
 
 I am aware of the security implications for this.
 
 How can I configure this policy?
>>> I don't think there is a way to deploy such policy through SSSD at all.
>>> 
>>> Jakub, do you have an idea how to make that possible?
>> Currently I can't think of anything clean either. Is the lock screen and the
>> login manager the same PAM service? If they are different, maybe some
>> hack like letting pam_unix to always read the password and then just
>> pass it on to pam_sss would work..
>> But I know Sumit is working on improving the 2FA prompting lately, so
>> maybe this will be improved in the upcoming release.
> 
> I seem to have mate-screensaver, lightdm and xrdp-sesman.
> 
> Will that be enough to hook a custom pam rule together for mate-screensaver?
> 
> If not is it possible to disable OTP for all the destkop systems in 
> sssd.conf? and have it still working for all other systems with 
> --user-auth-type=otp as only enabled option in freeipa?
> 
> Also for laptop systems in offline
> 
> disable_preauth
> forward_pass
> 
> Mar 19 18:54:50 workstation01 mate-screensaver-dialog: 
> pam_unix(mate-screensaver:auth): authentication failure; logname= 
> uid=350600021 euid=350600021 tty=:10.0 ruser= rhost=  user=jdejong
> 
> Mar 19 18:54:51 workstation01 mate-screensaver-dialog: 
> pam_sss(mate-screensaver:auth): authentication success; logname= 
> uid=350600021 euid=350600021 tty=:10.0 ruser= rhost= user=jdejong
> 
> Mar 19 18:56:48 workstation01 xrdp-sesman[788]: pam_unix(xrdp-sesman:auth): 
> authentication failure; logname= uid=0 euid=0 tty=xrdp-sesman ruser= rhost=  
> user=jdejong
> 
> Mar 19 18:56:48 workstation01 xrdp-sesman[788]: pam_sss(xrdp-sesman:auth): 
> authentication success; logname= uid=0 euid=0 tty=xrdp-sesman ruser= rhost= 
> user=jdejong
> 
> Mar 19 19:01:01 workstation01 lightdm: pam_unix(lightdm:auth): authentication 
> failure; logname= uid=0 euid=0 tty=:0 ruser= rhost= user=jdejong
> 
> Mar 19 19:01:01 workstation01 lightdm: pam_sss(lightdm:auth): authentication 
> success; logname= uid=0 euid=0 tty=:0 ruser= rhost= user=jdejong
> 
> cat /etc/pam.d/mate-screensaver
> @include common-auth
> auth optional pam_gnome_keyring.so
> 
> cat /etc/pam.d/common-auth
> #
> # /etc/pam.d/common-auth - authentication settings common to all services
> #
> # This file is included from other service-specific PAM config files,
> # and should contain a list of the authentication modules that define
> # the central authentication scheme for use on the system
> # (e.g., /etc/shadow, LDAP, Kerberos, etc.).  The default is to use the
> # traditional Unix authentication mechanisms.
> #
> # As of pam 1.0.1-6, this file is managed by pam-auth-update by default.
> # To take advantage of this, it is recommended that you configure any
> # local modules either before or after the default block, and use
> # pam-auth-update to manage selection of other modules.  See
> # pam-auth-update(8) for details.
> 
> # here are the per-package modules (the 

[Freeipa-users] timeout for IPA command

[Charles Hedrick via FreeIPA-users]

It appears that the IPA command uses a host hardwired in /etc/ipa/default.conf. 

If that fails, it then gets a list from DNS. This works fine if there’s a 
connection refused, but if there is no response, it takes so long to time out 
that most users will give up.

Is there a way to change the timeout?

___
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: FreeIPA for the maximally paranoid and overworked?

[Charles Hedrick via FreeIPA-users]

Rob mentioned issues with restoring data for one entry. We run on VMs, and 
periodically take snapshots. We can copy a snapshot to a new VM. Since the 
hostname is critical, edit /etc/hosts and add an entry for the new IP address 
giving it the original hostname. That way the system will think it’s the 
original host. Then the system works. At that point you can get entries. 
ldapsearch will let you get all the attributes, so you could put an old entry 
back. We actually did this one time.

I generally feel pretty safe with ongoing operation. The last few updates have 
been mostly OK, though we often have to do some minor intervention. To me the 
scary thing is adding replicas. Last time I tried, the first attempt failed, 
and I also had to go through a text dump to find all references and get rid of 
them. We actually ended up using a new name when we did the second  try, just 
to avoid any chance of issues.

We use commercial certs, so I don’t have to worry about ipa’s cert management. 
From postings here it looks like a weak point.

On Jan 9, 2019, at 1:05 PM, K. M. Peterson via FreeIPA-users 
mailto:freeipa-users@lists.fedorahosted.org>>
 wrote:

Rob,

Thanks for your response, it was very helpful!

A monitoring tool would be great, I should say that I am sleeping better 
because I'm getting to the point where I can at least back-out things when 
there's that kind of failure.

It sounds like the level of caution that I've applied to this is appropriate.  
I was reading a blog 
post 
yesterday from William Brown that to some extent confirms what you'd said - and 
my experience.

It's really helpful to hear, and I appreciate the assist.  I hope I can get to 
the point where I have something to contribute to this project.

One more thing: I think I've figured out the series (or, perhaps "a" series) of 
events that got me into this situation.  It appears that initially on client 
installation for some reason, I would receive errors indicating that there was 
a problem with the OpenLDAP configuration and it failed because it could not 
update the /etc/openldap/ldap.conf file.  My base installation doesn't have 
such a file, and previous installations of clients may or may not have hit the 
same issue but it was never a problem for us.  I created 
/etc/openldap/ldap.conf with a single "#" line, re-spun the server and 
installed the client and ipa-replica-install - and everything is working as 
expected now.

Again, many thanks!

On Tue, Jan 8, 2019 at 5:25 PM Rob Crittenden 
mailto:rcrit...@redhat.com>> wrote:
K. M. Peterson via FreeIPA-users wrote:
> Hi all,
>
> This is a newbie question with respect to FreeIPA, and I haven't seen
> this elsewhere, so I thought I'd ask.
>
> I've just cleaned up an issue with trying to implement a new replica on
> our domain, and I've realized that there are a couple of areas I don't
> understand that are causing more stress than I need at this point, for I
> am maximally paranoid and overworked, and I need some advice on how not
> to make that worse when implementing FreeIPA.
>
> I've been reading this list on and off for most of the last year, and
> what's struck me is how complicated this project is, especially of
> course areas where I personally have less expertise (e.g., LDAP,
> Kerberos).  Implementing and managing this is just one of my jobs, and
> our IdM becomes more critical as time goes on, so I need to understand a
> few things.
>
> Question 1: As I just had, for the first time, to manually modify LDAP
> to remove data, I'd like to understand how taking that approach can
> backfire.  In other words, it's clear this isn't habitually a good idea,
> because mistakes will replicate, for example.  But, where are the real
> danger points:  for example, I've seen stories of having to recover a
> server in an environment where the time was intentionally set back to
> allow an operation on an expired cert.  As with a database update that
> triggers other (unexpected) changes, are there LDAP operations that
> can't practically be "un-done"?  I know that deleting records is
> permanent (obvious), but are there gotchas like changing a particular
> object fires some large number of events that there's no way to revert?
> Or, in colloquial terms, are there places that are really, really bad to
> try to outwit the management interfaces?  I'm not talking everyday
> updates, but instances where we get stuck (as I was yesterday and today)?
>
> Question 2: How to stay safe.  Our installation on a small network as a
> pair of masters replicating with each other, CA and DNS installed on
> both.  They are VMs allocated on separate physical hosts.  Before
> updates, I snapshot both for recovery purposes.  I update one at a time,
> now, and ensure that they're functional before doing the other one (I
> know that schema changes will propagate before service is applied
> elsewhere, but I can't do anything else about 

[Freeipa-users] Re: system time

[Charles Hedrick via FreeIPA-users]

In Linux, time is always in UTC internally. The time zone controls how time it 
shown to users. Changing the time zone thus has no effect on the internal 
operations of the servers. It just changes log files and user displays. If you 
actually reset the time on the server to local time, Kerberos will fail, unless 
you do the same thing on all clients, and even then you’ll have problems with 
day light savings. So don’t do that. 

> On Jan 9, 2019, at 5:27 AM, Md. Khairul Hasan via FreeIPA-users 
>  wrote:
> 
> Hi Rob,
> 
> Thanks for your response .
> In my server following service are running . Do you have any idea what's 
> service depends on system time .
> 
>  dirsrv@BANGLALINK-NET.service  = 389 Directory Server BANGLALINK-NET.
>  httpd.service  = The Apache HTTP Server
>  ipa-custodia.service   = IPA Custodia Service
>  kadmin.service = Password-changing and Administration
>  krb5kdc.service= Kerberos 5 KDC
>  pki-tomcatd@pki-tomcat.service = PKI Tomcat Server pki-tomcat
>  rpc-gssd.service   =  RPC security service for NFS client and 
> server
> ___
> 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: uid/gid mapping from windows to IPA

[Charles Hedrick via FreeIPA-users]

I forgot to note that you use “nfsadmin” to enable to mapping.

nfsadmin mapping config addomain=krb1.cs.rutgers.edu
nfsadmin mapping config adlookup=yes

In this case I’m pointing to your KDC. I believe it will work if you use your 
domain name, as long as you have the appropriate DNS entries. I’m hardcoding 
the server because it makes debugging easier.

> On Jan 9, 2019, at 12:24 PM, Charles Hedrick via FreeIPA-users 
>  wrote:
> 
> We’re in the process of setting up Windows machines to authenticate against 
> IPA and use home directories from our NFS servers with Kerberized NFS. 
> 
> The process is not easy, but possible. One thing I’ve found frustrating is 
> that documentation on Windows NFS is terrible. In particular, when you do a 
> mount, it’s critical to get it mounted with the right UID and GID. The 
> procedure most people are using is to set the UID and GID in the registry. 
> That’s fine if the same person always uses the system, but it won’t work for 
> us.
> 
> In older versions of windows, you could set up 
> /windows/system32/drivers/etc/passwd. But in Windows 10 they no longer seem 
> to pay attention. The only real way to do it is with active directory lookup. 
> Fortunately, IPA can handle that. The query is
> 
> GSSAPI authenticate as machine$
> ldapsearch -Y GSSAPI -b dc=cs,dc=rutgers,dc=edu '(sAMAccountName=clh)’ 
> uidnumber gidnumber
> 
> To get the GSSAPI authentication to work, you need MACHINE$ set as an alias 
> for the host. And you need to configure Windows to use principal 
> canonicalization. Otherwise Kerberos ignores the alias. That means doing 
> "ksetup /setrealmflags DOMAIN ncsupported” on Windows.
> 
> You also need to add samaccountname as an attribute for users, populate it, 
> and make it readable and searchable.
> 
> With this, mapping works.
> 
> Off course this assumes that Windows Kerberos is set up pointing to IPA as 
> the KDC, but there are plenty of other instructions on how to do that.
> 
> ___
> 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] uid/gid mapping from windows to IPA

[Charles Hedrick via FreeIPA-users]

We’re in the process of setting up Windows machines to authenticate against IPA 
and use home directories from our NFS servers with Kerberized NFS. 

The process is not easy, but possible. One thing I’ve found frustrating is that 
documentation on Windows NFS is terrible. In particular, when you do a mount, 
it’s critical to get it mounted with the right UID and GID. The procedure most 
people are using is to set the UID and GID in the registry. That’s fine if the 
same person always uses the system, but it won’t work for us.

In older versions of windows, you could set up 
/windows/system32/drivers/etc/passwd. But in Windows 10 they no longer seem to 
pay attention. The only real way to do it is with active directory lookup. 
Fortunately, IPA can handle that. The query is

GSSAPI authenticate as machine$
ldapsearch -Y GSSAPI -b dc=cs,dc=rutgers,dc=edu '(sAMAccountName=clh)’ 
uidnumber gidnumber

To get the GSSAPI authentication to work, you need MACHINE$ set as an alias for 
the host. And you need to configure Windows to use principal canonicalization. 
Otherwise Kerberos ignores the alias. That means doing "ksetup /setrealmflags 
DOMAIN ncsupported” on Windows.

You also need to add samaccountname as an attribute for users, populate it, and 
make it readable and searchable.

With this, mapping works.

Off course this assumes that Windows Kerberos is set up pointing to IPA as the 
KDC, but there are plenty of other instructions on how to do that.

___
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] yum upgrade doesn't do IPA upgrade

[Charles Hedrick via FreeIPA-users]

For some reason on one of our 3 servers, yum update didn’t run the IPA upgrade. 
/var/log/ipaupgrade.log was zero length. “ipactl start” noted that an upgraded 
was needed, and did it. So it wasn’t a big deal. But it would be nice for yum 
update to show some sign if there’s an issue. And perhaps output a message 
saying that the upgrade was done successfully.
___
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: Is IPA secure enough for public exposure plus trust management issue

[Charles Hedrick via FreeIPA-users]

We have a separate web app to change passwords. But the normal approach if they 
haven’t forgotten their password is the kpasswd command. Of course we’re in a 
Linux environment where our users know the command line.

> On Oct 18, 2018, at 9:58 AM, William Muriithi via FreeIPA-users 
>  wrote:
> 
> Hello,
> 
> I am looking for a way of allowing users to reset their password
> without going through the VPN.  I usually send users notification when
> the password are about to expire, but they don't follow up until
> something stop working.  At that point, they can't even VPN.
> 
> Have anyone else exposed IPA to the public and have it faired well?
> 
> Also, is there a way of changing one way trust (The default) to two
> way trust without first removing the current trust?
> 
> Regards,
> William
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://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: NFSv4 question

[Charles Hedrick via FreeIPA-users]

Right. the documentation is often not clear. Most Linux client software will 
try several principals. One of them is host/hostname. So you don’t need 
nfs/hostname. Since nfs/hostname is one of the principals it tries, some 
documentation says to use that principal.

> On Jun 19, 2018, at 3:24 AM, Tony Brian Albers via FreeIPA-users 
>  wrote:
> 
> In case you haven't found out yet, only the nfs servers need service 
> principals.
> 
> /tony
> 
> 
> On 09/06/18 01:29, Zane Zak via FreeIPA-users wrote:
>> I know that this is not the ideal list for NFS questions, but I'm not
>> sure of a better one.
>> 
>> I'm exploring NFSv4 with kerberos security, all tied into FreeIPA.
>> 
>> My question is whether or not the NFSv4 clients need nfs service
>> principals. Obviously the NFSv4 server needs both, but the client side
>> is where I'm confused.
>> 
>> Some documentations say the client needs both a host and nfs service
>> principal:
>> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/storage_administration_guide/s3-nfs-security-hosts-nfsv4
>> 
>> Other documentations say the client needs just a host principal:
>> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/storage_administration_guide/s1-nfs-security#s3-nfs-security-hosts-nfsv4
>> 
>> Any clarification would be appreciated.
>> 
>> Thanks!
>> 
>> ZZ
>> ___
>> 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/XB5RFPK6K2NAMXDGOUIZNQ4HJLGQH2FG/
>> 
> 
> 
> -- 
> Tony Albers
> Systems administrator, IT-development
> Royal Danish Library, Victor Albecks Vej 1, 8000 Aarhus C, Denmark.
> Tel: +45 2566 2383 / +45 8946 2316
> ___
> 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/UNKMVLCFE2ZODRXVS6A4OS7HURLN4BRE/
___
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/V5HGDYELJ3UQJXSWOZ625JGBDMJSPA7K/

[Freeipa-users] Re: 2FA integration: FreeIPA and Mac OS

[Charles Hedrick via FreeIPA-users]

You can get an MIT Kerberos implementation from Macports. I use that myself. 
However I don’t use it for login, so I haven’t tried the pam support on the 
Mac. The Macports implementation supports both 2FA and the https proxy. We 
restrict access to our kerberos servers, so people at home have to use the 
proxy.

> On Jun 20, 2018, at 6:00 AM, Oleksandr Yermolenko via FreeIPA-users 
>  wrote:
> 
> Hi,
> 
> Has someone managed to setup OTP 2FA between FreeIPA 4.5.X and Mac OS (High 
> Sierra)?
> When authenticating with a non 2FA user, works fine.
> 
> THE FIRST WAY: native heimdal client:
> 
> aae$ kinit --version
> kinit (Heimdal 1.5.1apple1)
> Copyright 1995-2011 Kungliga Tekniska Högskolan
> Send bug-reports to heimdal-b...@h5l.org
> aae$
> 
> aae$ kdestroy
> aae$ kinit --anonymous
>aae$ klist   Credentials cache: 
> KCM:74E6A71B-BCB9-43E1-8832-AFC7B17831E7
>   Principal: WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS
> 
> IssuedExpires   Principal
> Jun 20 12:41:07 2018  Jun 21 12:41:06 2018  krbtgt/idm@idm.crp
> 
> aae$ kinit --fast-armor-cache=KCM:74E6A71B-BCB9-43E1-8832-AFC7B17831E7 
> a...@idm.crp
> kinit: krb5_init_creds_set_fast_ccache: Matching credential 
> (krbtgt/WELLKNOWN:ANONYMOUS@WELLKNOWN:ANONYMOUS) not found
> aae$
> 
> Found [1] that FAST is supported but is it enough for OTP I have no idea. 
> Tried tcp protocol [2] without success. I can't find information how to 
> activate anon FAST on Mac OS if this protocol is supported. What about OTP? 
> I'm not sure that old heimdal kerberos client is compatible with pkinit/fast. 
> I know so many questions to apple developers and support
> 
> -
> THE SECOND WAY: client MIT version krb5-1.16.1
> port install kerberos5
> ...
> --->  Installing kerberos5 @1.16.1_0
> ...
> 
> slightly changed /etc/krb5.conf
> 
> aae$ kdestroy
> kdestroy: No credentials cache found while destroying cache
> 
> aae$ kinit -n
> aae$ klist -A
> Ticket cache: KCM:501
> Default principal: WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS
> 
> Valid starting   Expires  Service principal
> 06/20/2018 12:46:22  06/21/2018 12:46:22  krbtgt/idm@idm.crp
> 
> aae$ kinit -T KCM:501 a...@idm.crp
> Enter OTP Token Value: aae$
> 
> aae$ klist -A
> Ticket cache: KCM:501:2
> Default principal: a...@idm.crp
> 
> Valid starting   Expires  Service principal
> 06/20/2018 12:47:13  06/21/2018 12:46:59  krbtgt/idm@idm.crp
> 
> Ticket cache: KCM:501
> Default principal: WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS
> 
> Valid starting   Expires  Service principal
> 06/20/2018 12:46:22  06/21/2018 12:46:22  krbtgt/idm@idm.crp
> aae$ 
> much much better, but it's not enough because I can't use TGT. As you can see 
> I tried to use KCM cache believing that I use native heimdal KCM server on my 
> Mac, but without success: I do not see any valid tickets here 
> /System/Library/CoreServices/ and of course don't have 
> kerberos related access to corporate resources. 
> --
> 
> 
> Any help is appreciated. Possible directions/ideas how to implement 2FA on 
> Mac OS without hacks?
> 
> I have successfully setup linux using pam-krb5 and anon_fast option.
> 
> References:
> [1] https://www.redhat.com/archives/freeipa-users/2016-December/msg00214.html
> [2] https://www.redhat.com/archives/freeipa-users/2016-December/msg00219.html
> 
> -- 
> Oleksandr Yermolenko
> systems engineer
> ___
> 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/DK5AFM2KZS4AYETQYLZTSDQZ3KCI4YKP/
___
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/5IXVMH3XIS72ILD5KRQHADOKG4UAJLY7/

[Freeipa-users] Re: freeIPA backup

[Charles Hedrick via FreeIPA-users]

Our IPA servers are VMs. We do backups of snapshots, either through VMware or 
when the image is on a Netapp, through a Netapp snapshot. That guarantees that 
you have all the pieces in a consistent state. I’ve never had to restore a 
production server, but I have started copies of one of the backups to do 
experiments that I didn’t want to do on a production system. I’ve never had an 
issue starting from a backup, though I need to do some changes so the system 
thinks it has the same hostname as the original one.

> On Jun 11, 2018, at 9:10 AM, Alfredo De Luca via FreeIPA-users 
>  wrote:
> 
> Hi all. 
> What's the best procedure/practice  to periodically perform a backup on a 
> single freeipa server with CA? 
> 
> Cheers
> 
> -- 
> 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-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/KKKIFFZZQS4V562HUWYYR6FHGEA4KOYL/

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

[Freeipa-users] Re: auth to pther providers still using freeipa

[Charles Hedrick via FreeIPA-users]

It depends upon what you want to do. If you want a user to authenticate for all 
purposes using some external service, you can do that, as long as the external 
service supports radius. You may have to et up a radius server and configure it 
to use the external authentication. You can have more than one external 
service. You add the various radius services to ipa. At that point you can set 
specific users to use the specific service. I’ve used this to authenticate 
against our University’s certain LDAP, though we don’t intend to use this in 
production.

Kerberos considers this a one-time password, so it only works for clients that 
support one-time passwords. sssd and kinit do, but not all software does. You 
also can’t generate a keytab for a user with a one-time password (though we 
have another approach to authenticate cron jobs and services for such users). 
Here’s how I set that up: 
https://github.com/clhedrick/kerberos/wiki/Using-Rutgers-passwords-(also,-radius-as-front-end-for-IPA)

> On May 16, 2018, at 4:23 PM, Andrew Meyer via FreeIPA-users 
>  wrote:
> 
> My company is wanting to use FreeIPA for everything.  However we also utilize 
> other external services that have their own auth system but can support 
> oauth, or gsuite/facebook etc etc.  Is this possible w/ FreeIPA?
> 
> Also,
> Searching through google I found this - Ipsilon 
> .  Would you recommend I use that?
> 
> 
> Ipsilon
> By Ipsilon Project
> Ipsilon identity provider project homepage
>  
> 
> 
> Thank you!
> ___
> 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
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/ZLCEZTVCVKUKIULZW3J275YSSREVE7M2/