[Freeipa-users] Re: CA Cert and CA Private key, or signing key.
On Tue, Apr 09, 2019 at 12:17:17PM -, Ralph Crongeyer via FreeIPA-users wrote: > Hi Fraser, > Sure thing. I was just pointing out that for testing we used the keys > generated on the FW for testing. Now we would like to use FreeIPA as the CA > for the FW's. > So I am trying to figure out how best to go about this using FreeIPA. > What I am trying to do is to create a sub CA cert and it's signing key on > FreeIPA and then export those from FreeIPA for use on the FW's. > > Hope that makes more sense. > Why does the firewall need a CA signing certificate? Are you going to be MITMing your users' TLS? Anyhow, you should generate the keys and CSR on the system that will be the sub-CA. Then follow the procedure outlined in my blog post for creating a sub-CA profile and issuing sub-CA certificate: https://frasertweedale.github.io/blog-redhat/posts/2018-08-21-ipa-subordinate-ca.html If you only need service certificates for the firewall, just create the keys and CSRs on the firewall machine, and submit them as you would any other service certificate. HTH, Fraser ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: AD Trust and ipa cli/Web UI
Alexander,
> This means it was unable to map the incoming Kerberos principal from the
> SASL GSSAPI (or GSS-SPNEGO) to the LDAP entry. Can you check if
> /usr/share/ipa/updates/71-idviews-sasl-mapping.update is applied at this
> server?
>
> You can apply it with
>
> ipa-ldap-updater /usr/share/ipa/updates/71-idviews-sasl-mapping.update
It showed up in the configuration, but just to test I went ahead and
ran it to be 100% sure, and the output stated nothing was modified and
reported a successful exit:
# ipa-ldap-updater /usr/share/ipa/updates/71-idviews-sasl-mapping.update
Update complete, no data were modified
The ipa-ldap-updater command was successful
Any other ideas?
Thank you!
John DeSantis
Il giorno mar 9 apr 2019 alle ore 02:48 Alexander Bokovoy
ha scritto:
>
> On ma, 08 huhti 2019, John Desantis via FreeIPA-users wrote:
> >Alexander,
> >
> >> Enable debugging for IPA server framework by creating a file
> >> /etc/ipa/server.conf with the following content:
> >>
> >>
> >> [global]
> >> debug=True
> >>
> >>
> >> Restart httpd and try again. Then collect logs and show that access
> >> attempt. The logs you attached so far only contain Apache modules'
> >> debugging information, not IPA framework's one.
> >
> >Thanks for your reply. I went ahead and disabled the debug logs via
> >httpd/conf.d/nss.conf to "warn", and now am only using server.conf
> >"debug=True" (which was already set). I've attached the logs
> >generated via a fresh request and `tail -f krb5kdc.log
> >httpd/{access,error}_log dirsrv/slapd-IPA-DOMAIN-COM/{access,error}`,
> >but you'll see that there is much less output.
> >
> >> Other than self-management, you wouldn't achieve anything in FreeIPA 4.6
> >> for that. Web UI / CLI administration with AD users is only available in
> >> RHEL 8.0 beta.
> >
> >Right. I did see a post suggesting limited AD user access in terms of
> >Web UI and cli, but the post below suggests that ipa cli access was/is
> >available as of FreeIPA 4.5.0:
> >
> >https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/message/5OWV3YTPG4ZETKJG2GVP2LDDTUUIAC2D/
> Right, but it has the same limits, namely, since ID Override for AD user
> is not a part of any group in LDAP that can be used to grant access
> controls, all you can do with such access is what self-service ACI
> allows. E.g. you can add your own public ssh keys to ID Override entry
> you are associated with and change other parameters of the same entry.
>
> RHEL 8 beta adds ability to associate ID Overrides with a group so that
> LDAP server sees this as a membership and applies ACIs correspondingly.
>
> >> Looks like fine -- the framework actually asked for the ldap/... ticket
> >> on behalf of AD user, so S4U2Proxy did work. Can you see anything in
> >> LDAP server access logs at the same time?
> >
> >Thanks for the suggestion. There is a "SASL(-14) authorization
> >failure" in the dirsrv/INSTANCE/access log, but no entries within the
> >dirsv/INSTANCE/error log; I've attached a copy of the relevant log
> >entries.
> This looks like the actual problem here.
>
> The only place where LDAP server returns SASL_NOAUTHZ is
>
> /* map the sasl username into an entry */
> entry = ids_sasl_user_to_entry(conn, context, user, user_realm);
> if (entry == NULL) {
> /* Specific return value is supposed to be set instead of
>an generic error (SASL_FAIL) for Cyrus SASL */
> returnvalue = SASL_NOAUTHZ;
> goto fail;
> }
>
> This means it was unable to map the incoming Kerberos principal from the
> SASL GSSAPI (or GSS-SPNEGO) to the LDAP entry. Can you check if
> /usr/share/ipa/updates/71-idviews-sasl-mapping.update is applied at this
> server?
>
> You can apply it with
>
> ipa-ldap-updater /usr/share/ipa/updates/71-idviews-sasl-mapping.update
>
> >
> >John DeSantis
> >
> >Il giorno lun 8 apr 2019 alle ore 14:46 Alexander Bokovoy
> > ha scritto:
> >>
> >> On ma, 08 huhti 2019, John Desantis via FreeIPA-users wrote:
> >> >Hello all,
> >> >
> >> >I'm wondering if anyone could help shed light on why IPA CLI commands
> >> >fail for a trusted AD user, and why Web UI logins for the same user
> >> >fail with the message "Your session has expired. Please re-login.",
> >> >despite creating a view for the user via `ipa idoverrideuser-add
> >> >'Default Trust View' ad_user@ad_domain.com`. The symptoms appear
> >> >almost identical to the post [0], except that the cli and Web UI were
> >> >never working previously.
> >> Enable debugging for IPA server framework by creating a file
> >> /etc/ipa/server.conf with the following content:
> >>
> >>
> >> [global]
> >> debug=True
> >>
> >>
> >> Restart httpd and try again. Then collect logs and show that access
> >> attempt. The logs you attached so far only contain Apache modules'
> >> debugging information, not IPA framework's one.
> >>
> >> >I am able to login via SSH (on a host with
[Freeipa-users] Re: different security policy for login(password+otp) and screenlock (password only) for workstation
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. >> >> 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
[Freeipa-users] Lost Dogtag admin certificate
Hello, I'm trying to solve following issue in our FreeIPA 4.6.4 deployment and ran our of ideas, so I'm asking for an advice. The main issue is the auditSigningCert having a printablestring subject: # certutil -d /etc/pki/pki-tomcat/alias/ -L -n 'auditSigningCert cert-pki-ca' -a | openssl x509 -noout -nameopt multiline,show_type -subject -issuer subject= organizationName = PRINTABLESTRING:DOMAIN.COM commonName= PRINTABLESTRING:CA Audit issuer= organizationName = UTF8STRING:DOMAIN.COM commonName= UTF8STRING:Certificate Authority It gets resubmitted with printablestring subject again, so I was hoping to fix it according to https://pagure.io/dogtagpki/issue/2865 by setting policyset.caLogSigningSet.1.default.params.useSysEncoding=true In order to modify the caSignedLogCert profile the Dogtag's admin certificate is required. Our domain is couple of years old and we don't have the original master anymore, neither we have any backups from it that would contain the /root/ca-agent.p12. So I was attempting to restore the admin cert by the method described in /etc/pki/pki-tomcat/ca/CS.cfg, but after setting ca.Policy.enable=true cmsgateway.enableAdminEnroll=true and restaring Dogtag, but it fails to start with following in /var/log/pki/pki-tomcat/ca/debug [08/Apr/2019:13:55:32][localhost-startStop-1]: CertificateAuthority init: initRequestQueue [08/Apr/2019:13:55:32][localhost-startStop-1]: selected policy processor = classic [08/Apr/2019:13:55:32][localhost-startStop-1]: GenericPolicyProcessor::init begins [08/Apr/2019:13:55:32][localhost-startStop-1]: GenericPolicyProcessor::init Certificate Policy Framework (deprecated) is ENABLED java.lang.ClassNotFoundException: com.netscape.cms.policy.constraints.ManualAuthentication at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1892) at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1735) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:264) at org.dogtagpki.legacy.core.policy.GenericPolicyProcessor.initSystemPolicies(GenericPolicyProcessor.java:1220) at org.dogtagpki.legacy.core.policy.GenericPolicyProcessor.init(GenericPolicyProcessor.java:200) at org.dogtagpki.legacy.ca.CAPolicy.init(CAPolicy.java:81) at com.netscape.ca.CertificateAuthority.initRequestQueue(CertificateAuthority.java:2183) at com.netscape.ca.CertificateAuthority.init(CertificateAuthority.java:591) at com.netscape.cmscore.apps.CMSEngine.initSubsystem(CMSEngine.java:1056) at com.netscape.cmscore.apps.CMSEngine.initSubsystems(CMSEngine.java:962) at com.netscape.cmscore.apps.CMSEngine.init(CMSEngine.java:578) at com.netscape.certsrv.apps.CMS.init(CMS.java:187) at com.netscape.certsrv.apps.CMS.start(CMS.java:1602) at com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:117) at javax.servlet.GenericServlet.init(GenericServlet.java:158) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:288) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:285) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAsPrivileged(Subject.java:549) at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:320) at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:175) at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:124) at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1257) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1182) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1072) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5368) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5660) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:145) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:899) at org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:133) at org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:156) at org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:145) at
[Freeipa-users] Re: CA Cert and CA Private key, or signing key.
Hi Fraser, Sure thing. I was just pointing out that for testing we used the keys generated on the FW for testing. Now we would like to use FreeIPA as the CA for the FW's. So I am trying to figure out how best to go about this using FreeIPA. What I am trying to do is to create a sub CA cert and it's signing key on FreeIPA and then export those from FreeIPA for use on the FW's. Hope that makes more sense. Ralph ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: AD Trust and ipa cli/Web UI
On ma, 08 huhti 2019, John Desantis via FreeIPA-users wrote:
Alexander,
Enable debugging for IPA server framework by creating a file
/etc/ipa/server.conf with the following content:
[global]
debug=True
Restart httpd and try again. Then collect logs and show that access
attempt. The logs you attached so far only contain Apache modules'
debugging information, not IPA framework's one.
Thanks for your reply. I went ahead and disabled the debug logs via
httpd/conf.d/nss.conf to "warn", and now am only using server.conf
"debug=True" (which was already set). I've attached the logs
generated via a fresh request and `tail -f krb5kdc.log
httpd/{access,error}_log dirsrv/slapd-IPA-DOMAIN-COM/{access,error}`,
but you'll see that there is much less output.
Other than self-management, you wouldn't achieve anything in FreeIPA 4.6
for that. Web UI / CLI administration with AD users is only available in
RHEL 8.0 beta.
Right. I did see a post suggesting limited AD user access in terms of
Web UI and cli, but the post below suggests that ipa cli access was/is
available as of FreeIPA 4.5.0:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/message/5OWV3YTPG4ZETKJG2GVP2LDDTUUIAC2D/
Right, but it has the same limits, namely, since ID Override for AD user
is not a part of any group in LDAP that can be used to grant access
controls, all you can do with such access is what self-service ACI
allows. E.g. you can add your own public ssh keys to ID Override entry
you are associated with and change other parameters of the same entry.
RHEL 8 beta adds ability to associate ID Overrides with a group so that
LDAP server sees this as a membership and applies ACIs correspondingly.
Looks like fine -- the framework actually asked for the ldap/... ticket
on behalf of AD user, so S4U2Proxy did work. Can you see anything in
LDAP server access logs at the same time?
Thanks for the suggestion. There is a "SASL(-14) authorization
failure" in the dirsrv/INSTANCE/access log, but no entries within the
dirsv/INSTANCE/error log; I've attached a copy of the relevant log
entries.
This looks like the actual problem here.
The only place where LDAP server returns SASL_NOAUTHZ is
/* map the sasl username into an entry */
entry = ids_sasl_user_to_entry(conn, context, user, user_realm);
if (entry == NULL) {
/* Specific return value is supposed to be set instead of
an generic error (SASL_FAIL) for Cyrus SASL */
returnvalue = SASL_NOAUTHZ;
goto fail;
}
This means it was unable to map the incoming Kerberos principal from the
SASL GSSAPI (or GSS-SPNEGO) to the LDAP entry. Can you check if
/usr/share/ipa/updates/71-idviews-sasl-mapping.update is applied at this
server?
You can apply it with
ipa-ldap-updater /usr/share/ipa/updates/71-idviews-sasl-mapping.update
John DeSantis
Il giorno lun 8 apr 2019 alle ore 14:46 Alexander Bokovoy
ha scritto:
On ma, 08 huhti 2019, John Desantis via FreeIPA-users wrote:
>Hello all,
>
>I'm wondering if anyone could help shed light on why IPA CLI commands
>fail for a trusted AD user, and why Web UI logins for the same user
>fail with the message "Your session has expired. Please re-login.",
>despite creating a view for the user via `ipa idoverrideuser-add
>'Default Trust View' ad_user@ad_domain.com`. The symptoms appear
>almost identical to the post [0], except that the cli and Web UI were
>never working previously.
Enable debugging for IPA server framework by creating a file
/etc/ipa/server.conf with the following content:
[global]
debug=True
Restart httpd and try again. Then collect logs and show that access
attempt. The logs you attached so far only contain Apache modules'
debugging information, not IPA framework's one.
>I am able to login via SSH (on a host with an HBAC configured), and
>able to `kinit` and obtain the appropriate tickets across the realms.
>I've configured the system accordingly, per the URL:
>https://www.freeipa.org/page/Active_Directory_trust_setup.
>
>I am running FreeIPA version 4.6.4 with a successful AD Trust (one
>way) using the range type "ipa-ad-trust-posix", both nodes completely
>re-provisioned (fresh installation purposes). SELinux is disabled,
>and the configuration IPA-wise is untouched, with the exception of
>enabling debugging and editing krb5.conf per the URL:
>https://www.freeipa.org/page/Active_Directory_trust_setup#Edit_.2Fetc.2Fkrb5.conf
>
>I've attached Apache logs referencing the Web UI and from the console.
>From what I have found online, it should be possible to allow an AD
>user to login to Web UI and ipa CLI commands should function, too.
>All IPA services are running and have been restarted, just in case
>something was "stuck". The interesting entries within the logs:
>(Failed to unseal session data!, GSSapiImpersonate not On) seem to be
>red herrings.
Other than self-management, you wouldn't achieve
