[Freeipa-users] Re: Eliminating Basic Auth Prompt When Accessing FreeIPA Direct
For some extra context. This has to do with "Negotiate" authentication.
It is there to allow single sign on via Kerberos. However on Windows, if
"Negotiate" with kerberos fails, the browser will try to fall back to try
NTLM (which, I think, freeIPA does not support anyway). Browser asks for
your password to set up the NTLM hashes. Why it does this before checking
if NTLM is available escapes me. When browser sends the first Negotiate
authorization header with NTLMSSP content (which is a negotiation type
message that does not contain any user information) it receceives 401 and
does not continue. So in reality it is not "Basic Auth".
I believe some of the tools accessing freeIPA API may be using this
kerberos authentication. Most likely the "ipa" command also uses this. If
you are authenticated as a freeIPA user and have kerberos properly set up
you can get SSO via this. You can also set up your users in a "trusted" AD
domain to authenticate in the web interface using Negotiate with kerberos
tickets without a password. So it is sometimes beneficial (even on Windows).
The first "fix" disables "Negotiate" authentication for windows clients.
Which means kerberos login for trusted AD users (if set up) will not work.
The second one disables "Negotiate" authentication for all web UI users
(even those that are not using windows).
Kontakt Jeff Hochberg via FreeIPA-users (<
freeipa-users@lists.fedorahosted.org>) kirjutas kuupäeval N, 18. mai 2023
kell 20:34:
> Amazing!
>
> I decided to try both your suggested fix as well as the fix suggested in
> one of the linked posts - both worked.
>
> Your fix:
> 1. Create /etc/httpd/conf.d/no-login-popup.conf
> 2. Add the following text:
>
> BrowserMatch Windows gssapi-no-negotiate
>
> 3, Save and restart httpd
>
> I also tested the proposed fix in this post:
> https://jdshewey.blogspot.com/2017/08/fixing-annoying-popup-in-freeipa.html
>
> 1. Edited /etc/httpd/conf.d/ipa-rewrite.conf
> 2. Added the following to the bottom of the file:
>
> #The following disables the annoying kerberos popup for Chrome
> RewriteCond %{HTTP_COOKIE} !ipa_session
> RewriteCond %{HTTP_REFERER} ^(.+)/ipa/ui/$
> RewriteRule ^/ipa/session/json$ - [R=401,L]
> RedirectMatch 401 ^/ipa/session/login_kerberos
>
> 3, Restarted httpd
>
> I agree with you - I'd have to think others run into this as well. At the
> very least, there should be an option to enable/disable this in the FreeIPA
> dashboard.
>
> Thanks for the assistance!!!
> ___
> 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] Re: sftp HBAC
I don't think this can be done easily The way pam works is the program (sshd in this case) starts the pam context with a specific name. Looking at sshd source it seems this is __progname for sshd which should be the basename of the executable. There does not seem to be a separate authentication stack for sftp part specifically. So it does not matter if you create a pam.d/sftp configuration as sshd is not programmed to look for it. sshd can however be configured to limit ssh access and allow sftp based on a users group. So this could be achieved by having the sftp only users in a specific user group. Kontakt Kevin Vasko via FreeIPA-users () kirjutas kuupäeval T, 16. mai 2023 kell 19:45: > Try to make this simple. > > Have a HBAC, have the "Who" set to a user, have the "Accessing" set to a > server. > > Have the "Via Service" set to "sshd". The user can ssh into the server no > issue. > > I want to limit this user to only being able to sftp into this server (no > direct ssh). > > If I swap the "Via Service" from the sshd service to sftp that user is now > denied. They cannot access the server via sftp or ssh. I would expect it to > deny ssh access but allow sftp. > > I did copy "cp /etc/pam.d/sshd /etc/pam.d/sftp" as I saw it mentioned here > https://freeipa-users.redhat.narkive.com/tFQFZmNu/hbac-service-allowed-despite-not-listed > but that didn't seem to work. > > Can you point me to the instructions on how to make the HBAC work with a > particular service (e.g. sftp)? > ___ > 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] Re: How to add NOPASSWD for ALL commands (no prompt for password)
Just put “!authenticate” in sudo Options. On Tue, 24. May 2022 at 14:08, Damola Azeez via FreeIPA-users < freeipa-users@lists.fedorahosted.org> wrote: > I'm trying to create a user to use for my automation. I don't want to have > the Users created manually on each host as that's time-consuming. Is there > a way I can use IPA to handle this requirement such that the user I create > is sudo and runs Sudo commands without asking for a password? > ___ > 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: FreeIPA and AIX
OK, I do not know a lot about AIX, but I would suggest you look into freeIPAs schema compatibility plugin. If that is enabled and you answer yes to: "Do you want to enable support for trusted domains in Schema Compatibility plugin? This will allow clients older than SSSD 1.9 and non-Linux clients to work with trusted users. Enable trusted domains support in slapi-nis?" When running: ipa-adtrust-install on ipa servers Then AD users can be found with an ldap search from "cn=users,cn=compat,dc=your,dc=domain,dc=com". However the LDAP schema will be RFC 2307 instead of RFC 2307bis. Kontakt Jim Kinney via FreeIPA-users () kirjutas kuupäeval E, 14. veebruar 2022 kell 15:11: > "Trusted AD Domain". That's dubious line at best :-) > > I've not seen AIX use AD for user auth but I know AD will work for Linux > systems. > > HOWEVER - The AD admins must add the Linux domain as trusted so it can > exchange the encrypted data stream. Alternatively, there's a way to do this > without the Linux system having trust in the AD realm. Something to do with > not usng TLS. > The RHEL docs on user auth are pretty good for this. > > You could try to set up a FreeIPA instance that is in the AD realm and > provides auth for AIX. Not sure if AIX has a sssd-ipa package or not. SLES > has sssd-ipa but doen't have freeipa server so server runs on RHEL. > > On Mon, Feb 14, 2022, 1:54 AM Ronald Wimmer via FreeIPA-users < > freeipa-users@lists.fedorahosted.org> wrote: > >> I was wondering if one can configure AIX in a way that trusted AD domain >> users can be used to log in under AIX. We followed >> https://www.freeipa.org/page/ConfiguringUnixClients but this guide seems >> to be LDAP-only and AD users do not have a represenntation in FreeIPA's >> LDAP directory. >> >> Could someone please clarify if AD users could work or not? >> >> 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 >> 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: certificate management - best practices - ?
First of all. FreeIPA servers should be one of the best guarded servers in any infrastructure. In addition to service private keys they contain the private key to the internal CA certificate, the kerberos database (user password hashes) etc. It is a very bad idea to run other non-related services on these hosts. As far as I understand, the services under "Services" are mostly kerberos service principals. I haven't seen any standard list as to what a service name can be. So basically you can configure whateveryouwant/my-host. There are several standard service names (HTTP, cifs, nfs etc.) and the respective clients to these services know to query these. For example your web browser will go and make a request for HTTP/my_host@MY_REALM service ticket when you navigate to https://my_host and it has "Negotiate" authentication configured. This allows you to authenticate to that web service based on your logon credentials (kerberos ticket (no password)). Kontakt lejeczek via FreeIPA-users () kirjutas kuupäeval K, 9. veebruar 2022 kell 09:43: > On 08/02/2022 19:33, Ahti Seier via FreeIPA-users wrote: > > Hello, > > > > I don't think there is one correct answer to this question. It > > depends on the services and how those hosts and services are managed. > > > > From a security perspective you need to have confidence that your > > private keys are secure and have not been been compromised. So if the > > services are administered by different teams or people it is better to > > separate the keys and control access to them so that each team and > > service would have access only to their own keys. Meaning it is better > > to have a certificate for each service. This will not save you if one > > of the keys gets compromised, but it is better to figure out how it > > happened and who is responsible if/when it does. It is a good idea if > > these certificates are with a different subject name because when one > > is expiring or there is some issue with it it is easier to understand > > which one it is. The OU field in the subject DN is a good way to > > separate these. > > > > If the server and all its services are managed by a single > > team/person and the impact of key compromise is not that severe then > > having one certificate for multiple services can be simpler to manage. > > All services will have access to the same private key. This has the > > effect that when a key does get compromised you will have a hard time > > figuring out how or through which service it could have happened. > > > > Just my 2c, > > Ahti > > > okey, so another one obvious - how about masters themselves? (put the > recommendation that IPA boxes should be IPA exclusive aside for now) > > I assume most of us if did not do then at least were tempted to have > databases (other than IPA's) on masters - if you do/did that would you > then use master's or separate/dedicated cert? (risks possibilities are > what they are but I'm still curious to hear opinions & thoughts) > > and btw. Is there a defined list of - IPA's or greater standard - > approved/supported services or we create those at whim as we go? eg. > mysql/my-host posgresql/my-host .etc > > 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 > 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: certificate management - best practices - ?
Hello, I don't think there is one correct answer to this question. It depends on the services and how those hosts and services are managed. From a security perspective you need to have confidence that your private keys are secure and have not been been compromised. So if the services are administered by different teams or people it is better to separate the keys and control access to them so that each team and service would have access only to their own keys. Meaning it is better to have a certificate for each service. This will not save you if one of the keys gets compromised, but it is better to figure out how it happened and who is responsible if/when it does. It is a good idea if these certificates are with a different subject name because when one is expiring or there is some issue with it it is easier to understand which one it is. The OU field in the subject DN is a good way to separate these. If the server and all its services are managed by a single team/person and the impact of key compromise is not that severe then having one certificate for multiple services can be simpler to manage. All services will have access to the same private key. This has the effect that when a key does get compromised you will have a hard time figuring out how or through which service it could have happened. Just my 2c, Ahti Kontakt lejeczek via FreeIPA-users () kirjutas kuupäeval T, 8. veebruar 2022 kell 20:40: > Hi guys. > > I ponder what I think must be trivial for at the same time, > also an obvious idea - services & hosts. > All the hosts, domain members and all possible or maybe just > a handful services, one might run on those hosts - should > you want a unique certificate for each host+service or > perhaps a single cert for a host which then be used by all > services on the host, is a better practice? > > All ideas & notions shared are greatly appreciated. > 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 > 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
