[Freeipa-users] Re: Lost password for CA private key

[John Stokes via FreeIPA-users]

One more thing: When exporting, I got these warnings:

WARNING: The SHA-1 algorithm used in 
org.mozilla.jss.pkcs12.SafeBag::getLocalKeyIDFromCert:264 is deprecated. Use a 
more secure algorithm.

I suppose the key was crated with SHA-1 back then (5 years ago). Is there 
anything I can do about this?
___
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: Lost password for CA private key

[John Stokes via FreeIPA-users]

What is the kracert.p12 used for? 

I get this error when I try to export:
[root@aaa-01 ca]# pki-server subsystem-cert-export kra 
--pkcs12-file=/root/kracertbackup.p12
ERROR: No kra subsystem in instance pki-tomcat.
___
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: Lost password for CA private key

[John Stokes via FreeIPA-users]

Thank you. I used the procedure mentioned here 
https://www.dogtagpki.org/wiki/PKCS12Export and was able to export the key.
___
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: Lost password for CA private key

[Sam Morris via FreeIPA-users]

On 21/09/2023 20:30, Rob Crittenden via FreeIPA-users wrote:

I ask because my /root/cacert.p12 and /root/kracert.p12 files also
aren't encrypted with my directory manager password and I am pretty sure
I haven't changed this password since installing any of my current IPA
servers. And when I install a replica I don't remember typing the
directory manager password anywhere...


I can't explain it. Mine is definitely encrypted by the DM password.


I just pulled the cacert.p12 and kracert.p12 files from the backup of my 
original ipa server and... my directory manager password is able to 
decrypt them!


So it's only my current servers where the file can't be decrypted... how 
strange...



Since the tooling for PKCS12 files is a tad awkward to use, here's a
handy command to print out the contents of these files:

# openssl pkcs12 -in /tmp/cacert.p12 -noenc | egrep -v '^[0-9A-Za-z/+]+=*$'


pk12util -l /path/to/cacert.p12 will print all the stored certs and
whether there is a private key included.


Ah that's a much nicer command, thanks.

--
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: Lost password for CA private key

[Rob Crittenden via FreeIPA-users]

Sam Morris via FreeIPA-users wrote:
> On 21/09/2023 15:38, Rob Crittenden via FreeIPA-users wrote:
>> John Stokes via FreeIPA-users wrote:
>>> Today while creating a backup I realized I don't know the
>>> password for the file /root/cacert.p12 where the private key
>>> of the CA shoudl be stored. The one I thought it should be
>>> (same as the pass for my admin user) does not seem to be
>>> working.
>>>
>>> Is there a way to reexport the private key of the CA?>
>> The password is the Directory Manager password provided during initial
>> installation.
> 
> Hmm... is the directory manager password stashed somewhere on an IPA
> server?

Not in plain text.
> I ask because my /root/cacert.p12 and /root/kracert.p12 files also
> aren't encrypted with my directory manager password and I am pretty sure
> I haven't changed this password since installing any of my current IPA
> servers. And when I install a replica I don't remember typing the
> directory manager password anywhere...

I can't explain it. Mine is definitely encrypted by the DM password.
> 
> (The knowledge base article about changing the Directory Manager
> password at https://access.redhat.com/solutions/203473 doesn't mention
> any steps other than setting a new hashed password in dse.ldif; if the
> original directory manager password is stashed somewhere then that
> article could do with an update...)
> 
> I went searching through the freeipa source code to figure out
> /root/cacert.p12 and /root/kracert.p12 are created myself. It seems that
> they are moved from /var/lib/pki/pki-tomcat/ca_backup_keys.p12 and
> /var/lib/pki/pki-tomcat/kra_backup_keys.p12 at the end of the
> server/replica installation process.
> 
> Those files are created by
> https://github.com/dogtagpki/pki/blob/6f50d7a68a34fcd3949e83b4ac607d8a65b37fb8/base/server/python/pki/server/deployment/scriptlets/finalization.py#L61;
> I've yet to figure out where pki_backup_password comes from. Hence me
> wondering if it's actually stored somewhere on the IPA server...

pki_backup_password is set to the DM password during installation.

>> You can use PKCS12EXPORT to create a new PKCS#12 file with the CA
>> private key.
> 
> Anyway, I found the command that actaully creates the files at
> https://github.com/dogtagpki/pki/blob/6f50d7a68a34fcd3949e83b4ac607d8a65b37fb8/base/server/python/pki/server/deployment/__init__.py#L3797
> and from that I came up with these commands to recreate /root/cacert.p12
> and /root/kracert.p12:
> 
> # pki-server subsystem-cert-export  ca --pkcs12-file=/root/cacert.p12
> # pki-server subsystem-cert-export kra --pkcs12-file=/root/kracert.p12
> 
> These commands prompt for a password if one is not provided via
> --pkcs-password-file= so it's convenient to type the directory manager
> password at this point rather than having to save it to a file for
> PKCS12Export to consume.
> 
> Since the tooling for PKCS12 files is a tad awkward to use, here's a
> handy command to print out the contents of these files:
> 
> # openssl pkcs12 -in /tmp/cacert.p12 -noenc | egrep -v '^[0-9A-Za-z/+]+=*$'

pk12util -l /path/to/cacert.p12 will print all the stored certs and
whether there is a private key included.

rob
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: prevent 'sudo -i ' from executing

[Sam Morris via FreeIPA-users]

On 21/09/2023 18:30, Ulf Volmer via FreeIPA-users wrote:

On 21.09.23 19:17, Rob Crittenden via FreeIPA-users wrote:


HBAC can do this better.
HBAC controls who is allowed to use PAM services. sudo-i is a PAM
service. It is allowed now, I'm assuming, because you have the HBAC
allow_all rule enabled.

If you disable or delete it then nobody will do anything so be careful.
Everything, including ssh, is denied by default without this rule.


So with HBAC I'm able to let a user to run 'vim /etc/fstab' and prevent 
him from escaping and start a shell?


No, HBAC controls whether a user can use the 'sudo' and/or 'sudo-i' PAM 
services.


If a user can use the 'sudo' PAM service then they are able to launch 
sudo with a command line of their choice. sudo rules then determine 
whether sudo will accept or reject that command line.


If the sudo rules let the user run 'vim' then it's game over. Same 
applies for most other programs unless proven safe!


The sudo-users mailing list 
 is probably a good 
place to ask for help with writing sudo rules.


One tool you have is the 'sudoedit' command. This lets you allow a user 
to edit files without running their editor as root.


However you still have to think very carefully about which files they're 
able to edit!


For instance, if you let them edit /etc/fstab then they can create a 
filesystem image containing a setuid executable, and then allow 
themselves to mount it by adding an fstab entry with the 'user' option...


--
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: Lost password for CA private key

[Sam Morris via FreeIPA-users]

On 21/09/2023 15:38, Rob Crittenden via FreeIPA-users wrote:

John Stokes via FreeIPA-users wrote:

Today while creating a backup I realized I don't know the

>> password for the file /root/cacert.p12 where the private key
>> of the CA shoudl be stored. The one I thought it should be
>> (same as the pass for my admin user) does not seem to be
>> working.
>>
>> Is there a way to reexport the private key of the CA?>

The password is the Directory Manager password provided during initial
installation.


Hmm... is the directory manager password stashed somewhere on an IPA server?

I ask because my /root/cacert.p12 and /root/kracert.p12 files also 
aren't encrypted with my directory manager password and I am pretty sure 
I haven't changed this password since installing any of my current IPA 
servers. And when I install a replica I don't remember typing the 
directory manager password anywhere...


(The knowledge base article about changing the Directory Manager 
password at https://access.redhat.com/solutions/203473 doesn't mention 
any steps other than setting a new hashed password in dse.ldif; if the 
original directory manager password is stashed somewhere then that 
article could do with an update...)


I went searching through the freeipa source code to figure out 
/root/cacert.p12 and /root/kracert.p12 are created myself. It seems that 
they are moved from /var/lib/pki/pki-tomcat/ca_backup_keys.p12 and 
/var/lib/pki/pki-tomcat/kra_backup_keys.p12 at the end of the 
server/replica installation process.


Those files are created by 
https://github.com/dogtagpki/pki/blob/6f50d7a68a34fcd3949e83b4ac607d8a65b37fb8/base/server/python/pki/server/deployment/scriptlets/finalization.py#L61; 
I've yet to figure out where pki_backup_password comes from. Hence me 
wondering if it's actually stored somewhere on the IPA server...


> You can use PKCS12EXPORT to create a new PKCS#12 file with the CA
> private key.

Anyway, I found the command that actaully creates the files at 
https://github.com/dogtagpki/pki/blob/6f50d7a68a34fcd3949e83b4ac607d8a65b37fb8/base/server/python/pki/server/deployment/__init__.py#L3797 
and from that I came up with these commands to recreate /root/cacert.p12 
and /root/kracert.p12:


# pki-server subsystem-cert-export  ca --pkcs12-file=/root/cacert.p12
# pki-server subsystem-cert-export kra --pkcs12-file=/root/kracert.p12

These commands prompt for a password if one is not provided via 
--pkcs-password-file= so it's convenient to type the directory manager 
password at this point rather than having to save it to a file for 
PKCS12Export to consume.


Since the tooling for PKCS12 files is a tad awkward to use, here's a 
handy command to print out the contents of these files:


# openssl pkcs12 -in /tmp/cacert.p12 -noenc | egrep -v '^[0-9A-Za-z/+]+=*$'

--
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: prevent 'sudo -i ' from executing

[Ulf Volmer via FreeIPA-users]

On 21.09.23 20:14, Rob Crittenden via FreeIPA-users wrote:

Ulf Volmer via FreeIPA-users wrote:

So with HBAC I'm able to let a user to run 'vim /etc/fstab' and prevent
him from escaping and start a shell?

That's great! I should try to look into it.

Not really. If you allow sudo to be executed then you're back to the
same issues. What the original poster ask for was a way to not allow
users to run sudo-i. That is possible with HBAC.



In this case maybe the OP ask the wrong question.

I assumed, he don't want to disallow only 'sudo -i', I thought he want 
to disable all shell access, so 'sudo bash' and so on. But maybe I was 
wrong.



Best regards

Ulf

___
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: prevent 'sudo -i ' from executing

[Rob Crittenden via FreeIPA-users]

Ulf Volmer via FreeIPA-users wrote:
> On 21.09.23 19:17, Rob Crittenden via FreeIPA-users wrote:
> 
>> HBAC can do this better.
>> HBAC controls who is allowed to use PAM services. sudo-i is a PAM
>> service. It is allowed now, I'm assuming, because you have the HBAC
>> allow_all rule enabled.
>>
>> If you disable or delete it then nobody will do anything so be careful.
>> Everything, including ssh, is denied by default without this rule.
> 
> 
> So with HBAC I'm able to let a user to run 'vim /etc/fstab' and prevent
> him from escaping and start a shell?
> 
> That's great! I should try to look into it.

Not really. If you allow sudo to be executed then you're back to the
same issues. What the original poster ask for was a way to not allow
users to run sudo-i. That is possible with HBAC.

rob
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: RedHat and 2FA Problem

[Jochen Kellner via FreeIPA-users]

Sam Morris via FreeIPA-users 
writes:

> On 21/09/2023 08:55, Sirio Sannipoli via FreeIPA-users wrote:
>> Thanks so much Sumit,
>> your suggestion works perfectly.
>> I'm still curious about the difference in behavior between
>> distributions, but it's not that important.
>> Greetings
>
> Probably on RHEL you have pam_sssd in your PAM stack, which is able to
> present separate prompts for both factors; whereas on Debian you have
> pam_unix which can only present a "Password:" prompt.
>
> This happens because pam_unix is registered in Debian's
> pam-auth-update mechanism with priority 256, whereas pam_sss is only
> registred with priority 128. Thus, the 'common-auth' PAM stack (which
> is included by sshd, login, gdm, etc) has pam_auth.so first, which
> prompts for the password; then pam_sss.so is called, with the
> 'use_first_pass' option, so it uses the password stashed by
> pam_unix.so instead of presenting its own prompts.
>
> I think pam_sss's priority should be bumped but I've not gotten around
> to chasing this request:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001644

Thanks for opening the bug - I think that's the right thing to do.
As a workaround I prepare a file /usr/share/pam-configs/unix+sss with
the config I wanted and enable that instead of "unix" in
pam-auth-update.

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: prevent 'sudo -i ' from executing

[Ulf Volmer via FreeIPA-users]

On 21.09.23 19:17, Rob Crittenden via FreeIPA-users wrote:


HBAC can do this better.
HBAC controls who is allowed to use PAM services. sudo-i is a PAM
service. It is allowed now, I'm assuming, because you have the HBAC
allow_all rule enabled.

If you disable or delete it then nobody will do anything so be careful.
Everything, including ssh, is denied by default without this rule.



So with HBAC I'm able to let a user to run 'vim /etc/fstab' and prevent 
him from escaping and start a shell?


That's great! I should try to look into it.


Best regards

Ulf

___
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: prevent 'sudo -i ' from executing

[Rob Crittenden via FreeIPA-users]

Ulf Volmer via FreeIPA-users wrote:
> On 21.09.23 18:21, Nathanaël Blanchet via FreeIPA-users wrote:
> 
>> I don't want my users to become root with simply executing the 'sudo
>> -i' command so they can execute all root commands. Users should only
>> execute with sudo the allowed defined commands.
>> I'm able to prevent them from executing 'sudo su -', but I didn't find
>> any informations about forbidding 'sudo -i'.
> 
> There is not good solution for.
> 
> You can try something like
> 
> username ALL=(ALL)  ALL, !/usr/bin/bash, !/usr/bin/vi
> 
> But you have to specify all dangerous command like vi, strace and so on.
> So please avoid this. To be safe, you have to define a whitelist of
> commands. Or to trust your users.

HBAC can do this better.

HBAC controls who is allowed to use PAM services. sudo-i is a PAM
service. It is allowed now, I'm assuming, because you have the HBAC
allow_all rule enabled.

If you disable or delete it then nobody will do anything so be careful.
Everything, including ssh, is denied by default without this rule.

So you'll need to create rules to allow the services you want, for the
users/groups you want, on the hosts you want. There is also a rule-level
glob for all users/groups and all hosts/hostgroups. So it can be as
fine-grained as you'd like.

You have to be very careful with sudo because users can be very crafty.
If they can call cp, ln or mv with sudo then they can create their own
/usr/bin/rcritsh which could allow them to do what they want because it
isn't in the prohibited. chmod can also be used in unexpected ways. The
sudoers man page has a lot to say about ! under SECURITY NOTES.

rob
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: prevent 'sudo -i ' from executing

[Christian Heimes via FreeIPA-users]

On 21/09/2023 18.21, Nathanaël Blanchet via FreeIPA-users wrote:

Hello,

I don't want my users to become root with simply executing the 'sudo
-i' command so they can execute all root commands. Users should only
execute with sudo the allowed defined commands.
I'm able to prevent them from executing 'sudo su -', but I didn't find
any informations about forbidding 'sudo -i'.


You can limit which commands a user can execute, the hosts, and target 
user/group with sudo rules and HBAC rules:


- https://freeipa.readthedocs.io/en/latest/workshop/8-sudorule.html
- 
https://access.redhat.com/documentation/de-de/red_hat_enterprise_linux/8/html/configuring_and_managing_identity_management/granting-sudo-access-to-an-idm-user-on-an-idm-client_configuring-and-managing-idm


The restrictions also allow you to block sudo -i and su -i either with a 
custom HBAC rule (you need to disable the default allowed_all rule) or 
with additional allow/deny commands for your sudo rule. "sudo -i" is 
just an alias for "run user's default shell as login shell". You could 
block all login shells. If you want a more secure rule, then only allow 
a well-defined list of commands and arguments.


Example:

$ sudo -i
Sorry, user testuser is not allowed to execute '/bin/bash' as root on 
client.ipa.example.


$ sudo -l
Matching Defaults entries for testuser on client:
!visiblepw, always_set_home, match_group_by_gid, 
always_query_group_plugin, env_reset, env_keep="COLORS DISPLAY HOSTNAME 
HISTSIZE KDEDIR LS_COLORS",
env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE", 
env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", 
env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY",

secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin

User testuser may run the following commands on client:
(ALL : ALL) NOPASSWD: !/usr/bin/zsh, !/usr/bin/sudo, !/usr/bin/su, 
!/usr/bin/sh, !/usr/bin/ksh, !/usr/bin/bash


$ ipa sudorule-show example-sudo
  Rule name: example-sudo
  Enabled: True
  RunAs User category: all
  RunAs Group category: all
  Users: testuser
  Host Groups: example-hosts
  Sudo Deny Command Groups: shells_sudo
  Sudo Option: !authenticate

$ ipa sudocmdgroup-show shells_sudo
  Sudo Command Group: shells_sudo
  Member Sudo commands: /usr/bin/bash, /usr/bin/ksh, /usr/bin/sh, 
/usr/bin/su, /usr/bin/sudo, /usr/bin/zsh



--
Christian Heimes
Principal Software Engineer, Identity Management and Platform Security

Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael 
O'Neill

___
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: prevent 'sudo -i ' from executing

[Ulf Volmer via FreeIPA-users]

On 21.09.23 18:21, Nathanaël Blanchet via FreeIPA-users wrote:


I don't want my users to become root with simply executing the 'sudo
-i' command so they can execute all root commands. Users should only
execute with sudo the allowed defined commands.
I'm able to prevent them from executing 'sudo su -', but I didn't find
any informations about forbidding 'sudo -i'.


There is not good solution for.

You can try something like

username ALL=(ALL)  ALL, !/usr/bin/bash, !/usr/bin/vi

But you have to specify all dangerous command like vi, strace and so on.
So please avoid this. To be safe, you have to define a whitelist of 
commands. Or to trust your users.


Best regards
Ulf
___
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] prevent 'sudo -i ' from executing

[Nathanaël Blanchet via FreeIPA-users]

Hello,

I don't want my users to become root with simply executing the 'sudo
-i' command so they can execute all root commands. Users should only
execute with sudo the allowed defined commands.
I'm able to prevent them from executing 'sudo su -', but I didn't find
any informations about forbidding 'sudo -i'.

Thank you for your help.

-- 
Nathanaël Blanchet

Administrateur Systèmes et Réseaux
Service Informatique et REseau (SIRE)
Département des systèmes d'information
227 avenue Professeur-Jean-Louis-Viala
34193 MONTPELLIER CEDEX 5   
Tél. 33 (0)4 67 54 84 55
Fax  33 (0)4 67 54 84 14
blanc...@abes.fr
___
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] Recovering from certificate exparation issues

[Cristian Le via FreeIPA-users]

I have tried my luck around with all the helpers: `pki-server cert-fix`, 
`ipa-cacert-manage`, `ipa-certupdate`, etc. but each one is failing on me for 
multiple reasons.
- `ipa-cacert-manage` Cannot update the CA with `--external-cert-file` because 
the root ca is not detected to be in the trust list
- `ipa-cert-fix` Was run without overlapping validity time, and the certificate 
were re-created, so now it is not recoverable, neither back in time, nor in 
current time
- `pki-tomcat` is failing

It is quite a mess and I would like to ask for some guidance on how one could 
recover manually from  such dependency issues:
- Is it possible to do a `ipa-server-install` and keep the user data?
- If I sign all of the service's certificates manually, what are all of the 
manual steps needed to get the services back up so that the helpers can be run.
  - I've tried to install the CA certificate in the nssdb database, ldap, and 
/etc/ipa/ca.crt. Are there other locations?
  - I've recreated an httpd certificate signed by the root, but I can't figure 
how to do the same with the ones located in the nssdb database, i.e. to 
recreate a csr with the same data as one of the certificates there
- What is the order of services that should be updated. My understanding is CA 
-> `certutil`'s CA -> httpd + slapd + pki-tomcat (not sure where the last one 
is or how to edit it) -> `ipa-certupdate`
___
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: Get running FreeIPA in Docker in Docker

[Rafael Jeffman via FreeIPA-users]

Hi Jay,

For running FreeIPA in a container you may want to check
https://github.com/freeipa/freeipa-container

The setup for it to work is somewhat sensible and following their
recommendations will prevent a lot of headaches.

Rafael

P.S.: Sorry for the top post.

On Wed, Sep 20, 2023 at 10:10 AM Ulf Volmer via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:

> On 20.09.23 09:05, Jay Smith via FreeIPA-users wrote:
> > For a test setup I try to get running a FreeIPA server within a docker
> container(DinD).
> > But I get some errors and I don't know why.
> >
> > 1. Create docker in docker container
> > => docker run --privileged -itd --name docker_swarm -v
> /sys/fs/cgroup:/sys/fs/cgroup docker
> >
> > 2. Connect to docker container and run the FreeIPA server
> > => docker exec -it docker_swarm \
> >   sh -c "docker run --sysctl
> net.ipv6.conf.all.disable_ipv6=0 --privileged=true --name ipa  -ti  -h
> ipa.example.test --cgroupns=host   \
> >   -v /sys/fs/cgroup:/sys/fs/cgroup:rw -v
> /tmp/freeipa-data:/data freeipa/freeipa-server:fedora-38-4.10.2
> --skip-mem-check --no-ntp"
> >
> > The error I get is:
> > docker: Error response from daemon: failed to create task for container:
> failed to create shim task: OCI runtime create failed: runc create failed:
> unable to start container process: unable to apply cgroup configuration:
> failed to write 670: write
> /sys/fs/cgroup/docker/3c2cc48a075d3f62143d70718aefe4c55938e4332262894e67f31328eaa5a006/cgroup.procs:
> no such file or directory: unknown.
> > ERRO[0038] error waiting for container:
>
>  From my knowledge:
>
> * We have cgroups v2 nowadays, please remove the volume /sys/fs/cgroup
> (from both commands)
> * you need cgroup nesting, please read the link below:
>
> https://github.com/containerd/containerd/issues/6659
>
> Best regards
> Ulf
>
> ___
> 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
>


-- 
Rafael Guterres Jeffman
Senior Software Engineer
FreeIPA - Red Hat
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: Lost password for CA private key

[Rob Crittenden via FreeIPA-users]

John Stokes via FreeIPA-users wrote:
> I have an IPA CA that is running fine for several years now. I also have two 
> replicas installed.
> 
> Today while creating a backup I realized I don't know the password for the 
> file /root/cacert.p12 where the private key of the CA should be stored. The 
> one I thought it should be (same as the pass for my admin user) does not seem 
> to be working.
> 
> Is there a way to reexport the private key of the CA? As I said everything is 
> working fine and I have access to the server.
> If not how should I proceed? Should I destroy the whole CA and build a new 
> one?

The password is the Directory Manager password provided during initial
installation.

You can use PKCS12EXPORT to create a new PKCS#12 file with the CA
private key.

There is no supported way to replace the CA in a running IPA server.

rob
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Lost password for CA private key

[John Stokes via FreeIPA-users]

I have an IPA CA that is running fine for several years now. I also have two 
replicas installed.

Today while creating a backup I realized I don't know the password for the file 
/root/cacert.p12 where the private key of the CA should be stored. The one I 
thought it should be (same as the pass for my admin user) does not seem to be 
working.

Is there a way to reexport the private key of the CA? As I said everything is 
working fine and I have access to the server.
If not how should I proceed? Should I destroy the whole CA and build a new one?
___
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: External bind with certs with sysaccounts

[Rob Crittenden via FreeIPA-users]

Tania Hagan via FreeIPA-users wrote:
> Hi Rob, 
> 
> As a company we turn off anonymous bind for security reasons, but have a 
> number of sysaccounts that are used in scripts to bind as that bind user and 
> complete an ldapsearch (e.g get list of users, get monitoring metrics).  We 
> also have systems such as phabricator that require a sysaccount to connect to 
> freeipa for user login. 
> 
> At the moment the search and binds are completed using user and password, but 
> we'd like to move away from having to store the password anywhere and instead 
> use certificates ideally provided by the freeipa server.  
> 
> Hope this makes more sense. 

It does, thanks.

I think all the capabilities are there but you'd have to figure out how
to put all the pieces together. This isn't something we're working on.

IPA can issue user certificates but you'd need to create a certificate
profile for it. There is some relevant discussion at
https://frasertweedale.github.io/blog-redhat/posts/2015-08-06-freeipa-custom-certprofile.html
. Note that this creates a signing cert and not a user cert, so you'd
have to tweak other things, but it goes over the basics. The same blog
may have additional pointers but this is the main one I found.

We did some design work about user certificates but never implemented it
all. Read this with that in mind as not everything was implemented,
https://www.freeipa.org/page/V4/User_Certificates . I can see my own
fingerprints on it, particularly with my common typos, but I honestly
pushed all of this out of my brain long ago.

As mentioned earlier, you'd need to manually add a new objectclass to
your sysaccount user and also set a uid for certificate matching.

And you'd be on the hook for managing renewal of the user certificate(s).

The final step is related to certificate mapping which maps a cert
subject to an entry (not to be confused with SSSD certificate mapping).
This is managed by /etc/dirsrv/slapd-EXAMPLE-TEST/certmap.conf. I
believe that the out-of-the-box configuration should work fine if the
sysaccount user has a uid that matches the uid in the cert subject.

rob
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: not thinking with the design of bind-dyndb-ldap

[Simo Sorce via FreeIPA-users]

This language is completely unacceptable.

You have been put in permanent moderation.

You can receive messages, but anything you send will be held in
moderation and may or not be acted upon as time permits by the
moderators.

You can appeal this decision by writing to the list owners.
But I warn you that using similar language in any communication will
simply cause you to be completely banned without a reply.

Learn to live a civil life in person and online.
Thank you,

Simo, on behalf of the project moderators.

On Thu, 2023-09-21 at 11:41 +, Marc via FreeIPA-users wrote:
[..]

-- 
Simo Sorce,
DE @ RHEL Crypto Team,
Red Hat, Inc



___
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: Would like to set up a "least privilege" admin only capable of managing POSIX groups, not users.

[Christian Heimes via FreeIPA-users]

On 20/09/2023 16.01, Chris Cowan via FreeIPA-users wrote:

Christian,

Rereading this, I'm wondering if besides the "admin" user and "admins" group if 
there are any other special users or groups with FreeIPA?   From my reading so far, I think the 
answer is no, but want to be sure.


The "ipaservers" host group is also special and has additional checks in 
place. An IPA client in this host group is privileged to promote itself 
to an IPA server without additional admin privileges.


Christian

--
Christian Heimes
Principal Software Engineer, Identity Management and Platform Security

Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael 
O'Neill

___
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] not thinking with the design of bind-dyndb-ldap

[Marc via FreeIPA-users]

1. Wtf are you assuming the ldap server is writable? Why would you think that 
changing this opposed to the older version is an improvement?

2. wtf do you want to download the whole ldap via sync? What is even the point 
of having it in ldap? My old named is using < 500MB, your new version is 700MB 
+ 500MB swap. 
Now everything is slow because you grab 99% data that is not even queried.

This plugin was good and you fucked it up, on security and on performance!!!



___
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] getting error "serial (xxxxxxxx) write back to LDAP failed"

[Marc via FreeIPA-users]

getting errors like this "serial () write back to LDAP failed"

Probably because it is trying to write to ldap? How to turn of this?


___
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: RedHat and 2FA Problem

[Sam Morris via FreeIPA-users]

On 21/09/2023 08:55, Sirio Sannipoli via FreeIPA-users wrote:

Thanks so much Sumit,
your suggestion works perfectly.
I'm still curious about the difference in behavior between distributions, but 
it's not that important.
Greetings


Probably on RHEL you have pam_sssd in your PAM stack, which is able to 
present separate prompts for both factors; whereas on Debian you have 
pam_unix which can only present a "Password:" prompt.


This happens because pam_unix is registered in Debian's pam-auth-update 
mechanism with priority 256, whereas pam_sss is only registred with 
priority 128. Thus, the 'common-auth' PAM stack (which is included by 
sshd, login, gdm, etc) has pam_auth.so first, which prompts for the 
password; then pam_sss.so is called, with the 'use_first_pass' option, 
so it uses the password stashed by pam_unix.so instead of presenting its 
own prompts.


I think pam_sss's priority should be bumped but I've not gotten around 
to chasing this request:


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001644

--
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: RedHat and 2FA Problem

[Sirio Sannipoli via FreeIPA-users]

Thanks so much Sumit,
your suggestion works perfectly.
I'm still curious about the difference in behavior between distributions, but 
it's not that important.
Greetings
___
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