Re: [Freeipa-users] question about Active Directory authentication
On 02/17/2015 05:21 PM, Steven Jones wrote: ***maybe*** c) You might be able to do both winsync and trusts at the same time then that is simpler provisioning. ie a user gets created in AD and automatically gets created in IPA ready for you to put in the user group you want. I am not sure this is the best solution really. Trust and sync do not help each other. The fact that you have trust does not help you to provision users the way you describe. 8-- They achieve different things. How otherwise do I get 2000+ AD users into IPA? To me winsync allows automated provisioning of users into IPA via AD, this greatly reduces manual effort. That I get. I do not understand how trust helps you in this case. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] [Solved] Help with debugging HBACs
Hi Sumit FreeIPA Users-
Your suggestion on updating the version of sssd worked like a charm.
Consider this issue solved.
Thanks Everyone,
-Andrew
On Mon, Feb 16, 2015 at 12:32 PM, Andrew Egelhofer
aegelho...@rubiconproject.com wrote:
Thank you for the reply Sumit - I will look into updating the version of
sssd. If that doesn't work, I will also try adding the
'sourceHostCategory' attribute to rules. Though, I would imagine I would
have to do this for *all* rules if I want them to work as intended. I'll
report back my findings tomorrow.
Thanks,
-Andrew
On Mon, Feb 16, 2015 at 12:40 AM, Sumit Bose sb...@redhat.com wrote:
On Sat, Feb 14, 2015 at 12:52:10PM -0800, Andrew Egelhofer wrote:
Hi FreeIPA Users-
I've deployed a FreeIPA instance in my Lab, and enrolled a single host,
and
a single user ('testuser'). The only HBAC rule I currently have is the
stock allow_all. Yet, when I attempt to log into the host via ssh, it
closes the connection.
$ ssh testuser@host
Warning: Permanently added 'host,host-ip' (RSA) to the list of known
hosts.
testuser@host's password:
Connection closed by host-ip
The host I'm attempting to login to can correctly look up the user using
getent:
# getent passwd testuser
testuser:*:16843:16843:Test User:/home/testuser:/bin/bash
Scanning /var/log/secure, I see these entries:
Feb 14 12:01:50 host sshd[6528]: pam_unix(sshd:auth): authentication
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=172.30.3.58
user=testuser
Feb 14 12:01:51 host sshd[6528]: pam_sss(sshd:auth): authentication
success; logname= uid=0 euid=0 tty=ssh ruser=
rhost=172.30.3.58 user=testuser
Feb 14 12:01:51 host sshd[6528]: pam_sss(sshd:account): Access denied
for
user testuser: 6 (Permission denied)
That tells me (From reading online) the user / password was correctly
authenticated, but failed authorization due to HBAC rules. I've tested
the
rule using the 'hbactest' utility and it passes
[root@Master ~]# ipa hbactest --user=testuser --host=host
--service=sshd
Access granted: True
Matched rules: allow_all
I'm at a loss here, because If I comment out the line:
account [default=bad success=ok user_unknown=ignore] pam_sss.so
in /etc/pam.d/system-auth, the user is able to login.
So what am I missing here? Is there a way I can debug HBAC rules? I've
already set debug_level = 10 in /etc/sssd/sssd.conf, and I see its able
to
access the HBAC 'allow_all' rule in the log
/var/log/sssd/sssd_domain.dc
.log:
(Fri Feb 13 21:38:15 2015) [sssd[be[domain.dc]]]
[sdap_get_generic_done] (7): Total count [0]
(Fri Feb 13 21:38:15 2015) [sssd[be[domain.dc]]]
[hbac_attrs_to_rule]
(7): Processing rule [allow_all]
(Fri Feb 13 21:38:15 2015) [sssd[be[domain.dc]]]
[hbac_user_attrs_to_rule] (7): Processing users for rule [allow_all]
(Fri Feb 13 21:38:15 2015) [sssd[be[domain.dc]]] [hbac_get_category]
(5): Category is set to 'all'.
(Fri Feb 13 21:38:15 2015) [sssd[be[domain.dc]]]
[hbac_service_attrs_to_rule] (7): Processing PAM services for rule
[allow_all]
(Fri Feb 13 21:38:15 2015) [sssd[be[domain.dc]]] [hbac_get_category]
(5): Category is set to 'all'.
(Fri Feb 13 21:38:15 2015) [sssd[be[domain.dc]]]
[hbac_thost_attrs_to_rule] (7): Processing target hosts for rule
[allow_all]
(Fri Feb 13 21:38:15 2015) [sssd[be[domain.dc]]] [hbac_get_category]
(5): Category is set to 'all'.
(Fri Feb 13 21:38:15 2015) [sssd[be[domain.dc]]]
[hbac_shost_attrs_to_rule] (7): Processing source hosts for rule
[allow_all]
(Fri Feb 13 21:38:15 2015) [sssd[be[domain.dc]]]
[hbac_host_attrs_to_rule] (4): No host specified, rule will never apply.
(Fri Feb 13 21:38:15 2015) [sssd[be[domain.dc]]]
[hbac_eval_user_element] (7): [12] groups for [admin]
(Fri Feb 13 21:38:15 2015) [sssd[be[domain.dc]]]
[hbac_eval_user_element] (7): Added group [admins] for user [admin]
(Fri Feb 13 21:38:15 2015) [sssd[be[domain.dc]]]
[hbac_eval_user_element] (8): Skipping non-group memberOf
[cn=replication
administrators,cn=privileges,cn=pbac,dc=domain,dc=dc]
(Fri Feb 13 21:38:15 2015) [sssd[be[domain.dc]]]
[hbac_eval_user_element] (8): Skipping non-group memberOf [cn=add
replication agreements,cn=permissions,cn=pbac,dc=domain,dc=dc]
(Fri Feb 13 21:38:15 2015) [sssd[be[domain.dc]]]
[hbac_eval_user_element] (8): Skipping non-group memberOf [cn=modify
replication agreements,cn=permissions,cn=pbac,dc=domain,dc=dc]
(Fri Feb 13 21:38:15 2015) [sssd[be[domain.dc]]]
[hbac_eval_user_element] (8): Skipping non-group memberOf [cn=remove
replication agreements,cn=permissions,cn=pbac,dc=domain,dc=dc]
(Fri Feb 13 21:38:15 2015) [sssd[be[domain.dc]]]
[hbac_eval_user_element] (8): Skipping non-group memberOf [cn=host
enrollment,cn=privileges,cn=pbac,dc=domain,dc=dc]
(Fri Feb 13 21:38:15 2015) [sssd[be[domain.dc]]]
[hbac_eval_user_element] (8):
Re: [Freeipa-users] question about Active Directory authentication
Ok, So with winsync I will have the 2000+ users in IPA. Within IPA I have several high risk/impact groups of servers and many low. For the low risk/impact servers and most desktops they can trust what AD tells them. For the high risk/impact servers/applications we do not want to reply on AD for any authorisation so permissions for these will be isolated from AD inside IPA. The idea is if we lose AD or IPA we should not lose both via any cross-linking. regards Steven From: freeipa-users-boun...@redhat.com freeipa-users-boun...@redhat.com on behalf of Dmitri Pal d...@redhat.com Sent: Wednesday, 18 February 2015 11:51 a.m. To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] question about Active Directory authentication On 02/17/2015 05:21 PM, Steven Jones wrote: ***maybe*** c) You might be able to do both winsync and trusts at the same time then that is simpler provisioning. ie a user gets created in AD and automatically gets created in IPA ready for you to put in the user group you want. I am not sure this is the best solution really. Trust and sync do not help each other. The fact that you have trust does not help you to provision users the way you describe. 8-- They achieve different things. How otherwise do I get 2000+ AD users into IPA? To me winsync allows automated provisioning of users into IPA via AD, this greatly reduces manual effort. That I get. I do not understand how trust helps you in this case. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] dirsrv hangs, 0% CPU util
On Wed, 18 Feb 2015, Thomas Raehalme wrote: Hi! On Mon, Feb 16, 2015 at 8:44 AM, Alexander Bokovoy aboko...@redhat.com wrote: I suspect you've triggered https://fedorahosted.org/freeipa/ticket/4586 and https://fedorahosted.org/freeipa/ticket/4635 -- slapi-nis plugin configuration does not limit itself to $SUFFIX and listens to changes in cn=changelog too so it may deadlock with a replication traffic. We fixed these partly by changing slapi-nis configuration, partly by fixing bugs in 389-ds. I wonder if amending your slapi-nis config to avoid triggering internal searches on cn=changelog would be enough. Is it possible to go around this issue by disabling replication? If so, is ipa-replica-manage disconnect enough or should we use del instead? I think you are solving wrong issue. Changing slapi-nis configuration to ignore cn=changelog was the change we did for FreeIPA 4.1. We ended up ignoring a bit more subtrees too: https://fedorahosted.org/freeipa/ticket/4635#comment:16 You need to show backtraces of nsslapd when it doesn't respond on LDAP queries to verify it is the same issue but I suspect it is very likely the issue. -- / Alexander Bokovoy pgpDxHlnUTSpF.pgp Description: PGP signature -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] issues with sudo on RHEL5.8
sure. Let me come back on that matter a bit later on next week. - Mail original - De: Dmitri Pal d...@redhat.com À: freeipa-users@redhat.com Envoyé: Mardi 17 Février 2015 19:39:40 Objet: Re: [Freeipa-users] issues with sudo on RHEL5.8 On 02/17/2015 05:18 AM, Nicolas Zin wrote: Thanks, that helps! I mistyped binddn and bindpw - Mail original - De: Lukasz Jaworski lukasz.jawor...@allegrogroup.com À: Nicolas Zin nicolas@savoirfairelinux.com Cc: freeipa-users@redhat.com Envoyé: Mardi 17 Février 2015 13:31:20 Objet: Re: [Freeipa-users] issues with sudo on RHEL5.8 With a RHEL7 IDM installation, I try to make sudo working. On RHEL6 no problem (via sssd) On RHEL5.8 I don't manage to make it working (credential are good, I manage to request the schema, see below) Where can I found more logs? What did I forget? [root@srv-rhel58-01 ~]# cat /etc/nss_ldap.conf bindn uid=sudo,cn=sysaccounts,cn=etc,dc=company,dc=com binpw redhat5Sudo ssl start_tls tls_cacertfile /etc/openldap/cacerts/ipa.crt #tls_cacert /etc/openldap/cacerts/ipa.crt tls_checkpeer yes #uri ldap://srv-idm7-01.company.com, ldap://srv-idm7-02.company.com uri ldap://srv-idm7-01.company.com sudoers_base ou=SUDOers,dc=company,dc=com sudoers_debug: 2 change last line (remove :) to: sudoers_debug 2 And then try sudo. Check: /etc/nsswitch.conf should be: sudoers: files ldap Best regards, Ender We quite frequently get questions about how to configure SUDO with IPA from RHEL5.x clients. Would you mind sharing this configuration as a howto solution? http://www.freeipa.org/page/HowTos -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] dirsrv hangs, 0% CPU util
Hi! On Mon, Feb 16, 2015 at 8:44 AM, Alexander Bokovoy aboko...@redhat.com wrote: I suspect you've triggered https://fedorahosted.org/freeipa/ticket/4586 and https://fedorahosted.org/freeipa/ticket/4635 -- slapi-nis plugin configuration does not limit itself to $SUFFIX and listens to changes in cn=changelog too so it may deadlock with a replication traffic. We fixed these partly by changing slapi-nis configuration, partly by fixing bugs in 389-ds. I wonder if amending your slapi-nis config to avoid triggering internal searches on cn=changelog would be enough. Is it possible to go around this issue by disabling replication? If so, is ipa-replica-manage disconnect enough or should we use del instead? Best regards, Thomas -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] No LDAPS for dirsrv
On Tue, 17 Feb 2015, Thomas Raehalme wrote: Hi! On Tue, Feb 17, 2015 at 8:43 PM, Thomas Raehalme thomas.raeha...@codecenter.fi wrote: Hi! On Tue, Feb 17, 2015 at 7:38 PM, Rob Crittenden rcrit...@redhat.com wrote: Now I only wish we could resolve what's causing the dirsrv process to hang (wrote about that in another message last Sunday) about 10 minutes after IPA services were started. Evidence suggests that the last upgrade failed so I'd start there. It is possible some plugins aren't configured properly, for example. After having restart ipa service, the upgrade command was completed successfully: # ipa-ldap-updater --upgrade Upgrading IPA: [1/8]: stopping directory server [2/8]: saving configuration [3/8]: disabling listeners [4/8]: starting directory server [5/8]: upgrading server [6/8]: stopping directory server [7/8]: restoring configuration [8/8]: starting directory server Done. Now dirsrv was stopped in 2 second when the previous time was over 500 seconds. Unfortunately this still didn't resolve the issue. After the system has been online for about 10 minutes, named starts complaining: Feb 17 21:04:14 ipa named[31117]: LDAP query timed out. Try to adjust timeout parameter Also ldapsearch just hangs if you try to perform any queries. Any ideas what could go wrong here? So, can you get us a backtrace again? -- / Alexander Bokovoy pgppXnHyCvtvH.pgp Description: PGP signature -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] bug in pki during install of CA replica and workaround/solution
Has anyone got any ideas on the below errors I am now receiving? Thanks in advance, Les I will test this out (update to 3.7.19-260) next week as I've got a few more CA replicas to setup. I'm still having issues. Different one this time. As I have previously worked around the install of CA replicas in my production Production environment as above, I went to setup CA replication in DR (both environments are completely separate). Make sure I did a yum update for all packages, including selinux-policy, and also making sure all needed modules were loaded in httpd.conf I proceeded to retry installation of CA replication. However, it failed with the following: Note: sb2sys01.domain.com is the replica I am trying to install (abbreviated below) # Attempting to connect to: sb2sys01.domain.com:9445 Connected. Posting Query = https://sb2sys01.domain.com:9445//ca/admin/console/config/wizard?p=7; op=nextxml=true__password=path=ca.p12 RESPONSE STATUS: HTTP/1.1 200 OK RESPONSE HEADER: Server: Apache-Coyote/1.1 RESPONSE HEADER: Content-Type: application/xml;charset=UTF-8 RESPONSE HEADER: Date: Fri, 13 Feb 2015 08:09:35 GMT RESPONSE HEADER: Connection: close ?xml version=1.0 encoding=UTF-8? !-- BEGIN COPYRIGHT BLOCK END COPYRIGHT BLOCK -- response paneladmin/console/config/restorekeycertpanel.vm/panel res/ updateStatusfailure/updateStatus password/ errorStringThe pkcs12 file is not correct./errorString size19/size Error in RestoreKeyCertPanel(): updateStatus returns failure ERROR: ConfigureCA: RestoreKeyCertPanel() failure ERROR: unable to create CA In /var/log/pki-ca/catalina.out I see... CMS Warning: FAILURE: Cannot build CA chain. Error java.security.cert.CertificateException: Certificate is not a PKCS #11 certificate|FAILURE: authz instance DirAclAuthz initialization failed and skipped, error=Property internaldb.ldapconn.port missing value| Server is started. Nothing gets populated in /etc/pki-ca/CS.cfg (based on comparison with a working system). grep DirAclAuthz /etc/pki-ca/CS.cfg authz.impl.DirAclAuthz.class=com.netscape.cms.authorization.DirAclAuthz authz.instance.DirAclAuthz.ldap=internaldb authz.instance.DirAclAuthz.pluginName=DirAclAuthz authz.instance.DirAclAuthz.ldap._000=## authz.instance.DirAclAuthz.ldap._001=## Internal Database authz.instance.DirAclAuthz.ldap._002=## authz.instance.DirAclAuthz.ldap.basedn= authz.instance.DirAclAuthz.ldap.maxConns=15 authz.instance.DirAclAuthz.ldap.minConns=3 authz.instance.DirAclAuthz.ldap.ldapauth.authtype=BasicAuth authz.instance.DirAclAuthz.ldap.ldapauth.bindDN=cn=Directory Manager authz.instance.DirAclAuthz.ldap.ldapauth.bindPWPrompt=Internal LDAP Database authz.instance.DirAclAuthz.ldap.ldapauth.clientCertNickname= authz.instance.DirAclAuthz.ldap.ldapconn.host= authz.instance.DirAclAuthz.ldap.ldapconn.port= authz.instance.DirAclAuthz.ldap.ldapconn.secureConn=false authz.instance.DirAclAuthz.ldap.multipleSuffix.enable=false The CA cert looks ok to me on the master. It does get copied to the replica in /usr/share/ipa/html/ca.crt I don't see any errors in httpd error or access logs on the master or the intended replica. The ipa-pki-proxy.conf config has the profilesubmit section. # matches for ee port LocationMatch ^/ca/ee/ca/checkRequest|^/ca/ee/ca/getCertChain|^/ca/ee/ca/getTokenI nfo|^/ca/ee/ca/tokenAuthenticate|^/ca/ocsp|^/ca/ee/ca/updateNumberR ange|^/ca/ee/ca/getCRL|^/ca/ee/ca/profileSubmit I can confirm that pki-cad does start (but is unconfigured) and that it does listen on port 9445. # netstat -apn |grep 9445 tcp0 0 :::9445 :::* LISTEN 31264/java # service pki-cad status pki-ca (pid 31264) is running... [ OK ] 'pki-ca' must still be CONFIGURED! (see /var/log/pki-ca-install.log) I am not sure what to try next. Appreciate any help to get over this error. Thanks, Les -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] No LDAPS for dirsrv
Hi Chris! On Tue, Feb 17, 2015 at 6:35 PM, Chris Mohler cmoh...@oberlin.edu wrote: As I wrote earlier we are having some serious problems with IPA right now. dirsrv seems to hang every 15 minutes or so, but that's another post. Are you running in a VM? If so check your entropy. cat /proc/sys/kernel/random/entropy_avail It should be ~1k less than 50 is not great and caused me some issues in the past. Yes, the server is a VM. Entropy value is 135 at the moment. Do you know how to increase the value? It seems that slapd/dirsrv is now only listening on port 389 for LDAP and socket for LDAPI requests. Any idea what could have caused previously available LDAPS port 636 to disappear? Did your certificates expire? I usually check the web interface and look at the SSL Cert in the browser to see when it expires. I bet there is a better way to check but I don't know it off hand. No, at least for the web interface certificates expire in August. It turned out the nsslapd-security was 'off' when it should have been 'on'. I really don't know what had changed the value. Now I only wish we could resolve what's causing the dirsrv process to hang (wrote about that in another message last Sunday) about 10 minutes after IPA services were started. Thanks for your help! Best regards, Thomas -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] No LDAPS for dirsrv
On 02/17/2015 11:26 AM, Thomas Raehalme wrote: Hi! As I wrote earlier we are having some serious problems with IPA right now. dirsrv seems to hang every 15 minutes or so, but that's another post. It seems that slapd/dirsrv is now only listening on port 389 for LDAP and socket for LDAPI requests. Any idea what could have caused previously available LDAPS port 636 to disappear? Looking at the logs before this whole ordeal started port 636 was also in use. After the latest upgrade I have re-enabled port 389 manually because it's used by some apps, but disabling it also doesn't bring back port 636. Best regards, Thomas Hi Thomas, I'm not an expert but just throwing out a few ideas for you. As I wrote earlier we are having some serious problems with IPA right now. dirsrv seems to hang every 15 minutes or so, but that's another post. Are you running in a VM? If so check your entropy. cat /proc/sys/kernel/random/entropy_avail It should be ~1k less than 50 is not great and caused me some issues in the past. It seems that slapd/dirsrv is now only listening on port 389 for LDAP and socket for LDAPI requests. Any idea what could have caused previously available LDAPS port 636 to disappear? Did your certificates expire? I usually check the web interface and look at the SSL Cert in the browser to see when it expires. I bet there is a better way to check but I don't know it off hand. It might help to know what OS/version you are using? and what version of FreeIPA you are using. Cheers, and Good luck, -Chris -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] No LDAPS for dirsrv
Thomas Raehalme wrote: Hi! As I wrote earlier we are having some serious problems with IPA right now. dirsrv seems to hang every 15 minutes or so, but that's another post. It seems that slapd/dirsrv is now only listening on port 389 for LDAP and socket for LDAPI requests. Any idea what could have caused previously available LDAPS port 636 to disappear? Looking at the logs before this whole ordeal started port 636 was also in use. After the latest upgrade I have re-enabled port 389 manually because it's used by some apps, but disabling it also doesn't bring back port 636. Best regards, Thomas If after an upgrade you had no listeners that means that the upgrade failed and wasn't able to restore the previous state. Look in /etc/dirsrv/slapd-YOURREALM for dse.ldif.ipa.###. This is the copy saved prior to the upgrade attempt. I'd diff it to dse.ldif to see what has changed. To enable port 636 just set nsslapd-security to on. If you do this via dse.ldif you'll need to stop the service before editing the file. Check /var/log/ipaupgrade.log for information on the upgrade. rob -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
[Freeipa-users] No LDAPS for dirsrv
Hi! As I wrote earlier we are having some serious problems with IPA right now. dirsrv seems to hang every 15 minutes or so, but that's another post. It seems that slapd/dirsrv is now only listening on port 389 for LDAP and socket for LDAPI requests. Any idea what could have caused previously available LDAPS port 636 to disappear? Looking at the logs before this whole ordeal started port 636 was also in use. After the latest upgrade I have re-enabled port 389 manually because it's used by some apps, but disabling it also doesn't bring back port 636. Best regards, Thomas -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] No LDAPS for dirsrv
Hi! On Tue, Feb 17, 2015 at 6:34 PM, Rob Crittenden rcrit...@redhat.com wrote: If after an upgrade you had no listeners that means that the upgrade failed and wasn't able to restore the previous state. Look in /etc/dirsrv/slapd-YOURREALM for dse.ldif.ipa.###. This is the copy saved prior to the upgrade attempt. I'd diff it to dse.ldif to see what has changed. To enable port 636 just set nsslapd-security to on. If you do this via dse.ldif you'll need to stop the service before editing the file. Thanks! For some reason the value of nsslapd-security is 'off' for the current version although previous dse.ldif.ipa.## files have it enabled. Changing the value back to 'on' re-enabled port 636. Best regards, Thomas -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] issues with sudo on RHEL5.8
On 02/17/2015 05:18 AM, Nicolas Zin wrote: Thanks, that helps! I mistyped binddn and bindpw - Mail original - De: Lukasz Jaworski lukasz.jawor...@allegrogroup.com À: Nicolas Zin nicolas@savoirfairelinux.com Cc: freeipa-users@redhat.com Envoyé: Mardi 17 Février 2015 13:31:20 Objet: Re: [Freeipa-users] issues with sudo on RHEL5.8 With a RHEL7 IDM installation, I try to make sudo working. On RHEL6 no problem (via sssd) On RHEL5.8 I don't manage to make it working (credential are good, I manage to request the schema, see below) Where can I found more logs? What did I forget? [root@srv-rhel58-01 ~]# cat /etc/nss_ldap.conf bindn uid=sudo,cn=sysaccounts,cn=etc,dc=company,dc=com binpw redhat5Sudo ssl start_tls tls_cacertfile /etc/openldap/cacerts/ipa.crt #tls_cacert /etc/openldap/cacerts/ipa.crt tls_checkpeer yes #uri ldap://srv-idm7-01.company.com, ldap://srv-idm7-02.company.com uri ldap://srv-idm7-01.company.com sudoers_base ou=SUDOers,dc=company,dc=com sudoers_debug: 2 change last line (remove :) to: sudoers_debug 2 And then try sudo. Check: /etc/nsswitch.conf should be: sudoers: files ldap Best regards, Ender We quite frequently get questions about how to configure SUDO with IPA from RHEL5.x clients. Would you mind sharing this configuration as a howto solution? http://www.freeipa.org/page/HowTos -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
[Freeipa-users] Passsync fails to connect to LDAP
All, After my education on what IPA/AD trusts can and can't do, I decided to give the IPA-AD sync option a try. After finally finding what I think is the proper software to install on the AD DC (389-PassSync-1.1.6-x86_64.exe from the Fedora site), I believe I have the settings correct, but the Password Synchronization software refuses to connect. After changing the Log Level option to 1, I get the below in the log file, which doesn't really tell me much of anything. 02/17/15 13:18:20: Backoff time expired. Attempting sync 02/17/15 13:18:20: Password list has 1 entries 02/17/15 13:18:20: Ldap bind error in Connect 81: Can't contact LDAP server 02/17/15 13:18:20: Attempting to sync password for ADSERVER$ 02/17/15 13:18:20: Searching for (ntuserdomainid=ADSERVER$) 02/17/15 13:18:20: Ldap error in QueryUsername 81: Can't contact LDAP server 02/17/15 13:18:20: Deferring password change for ADSERVER$ 02/17/15 13:18:20: Backing off for 256000ms The credentials are definitely correct and IPA is set up to do LDAPS as, on the same AD server, I can connect and bind using ldp.exe with the same settings/credentials and I'm able to browse the LDAP tree. I've done a wireshark capture and it looks like it's failing in the TLS negotiation. I can see this entry in the capture: TLSv1 Record Layer: Alert (Level: Fatal, Description: Protocol Version) Content Type: Alert (21) Version: TLS 1.2 (0x0303) Length: 2 Alert Message Level: Fatal (2) Description: Protocol Version (70) I added the IPA CA cert to the cert files in the 389 passsynch directory and I can confirm that as below. C:\Program Files\389 Directory Password Synchronizationcertutil -d . -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI IPA CA cert CT,, When I list that specific certificate, I can see the below in the output. Certificate Trust Flags: SSL Flags: Valid CA Trusted CA Trusted Client CA Email Flags: Object Signing Flags: Any pointers/ideas? Thanks in advance, Hugh -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Passsync fails to connect to LDAP
What version of 389-ds-base are you using? # rpm -q 389-ds-base Sorry for not specifying. I'm running FreeIPA on CentOS 6.5. Installed via yum - ipa-server-3.0.0-42.el6.centos.x86_64 -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] No LDAPS for dirsrv
Thomas Raehalme wrote: Hi Chris! On Tue, Feb 17, 2015 at 6:35 PM, Chris Mohler cmoh...@oberlin.edu mailto:cmoh...@oberlin.edu wrote: As I wrote earlier we are having some serious problems with IPA right now. dirsrv seems to hang every 15 minutes or so, but that's another post. Are you running in a VM? If so check your entropy. cat /proc/sys/kernel/random/entropy_avail It should be ~1k less than 50 is not great and caused me some issues in the past. Yes, the server is a VM. Entropy value is 135 at the moment. Do you know how to increase the value? I don't think that's an issue. It is more a problem during initial installation than during operation AFAIK. It seems that slapd/dirsrv is now only listening on port 389 for LDAP and socket for LDAPI requests. Any idea what could have caused previously available LDAPS port 636 to disappear? Did your certificates expire? I usually check the web interface and look at the SSL Cert in the browser to see when it expires. I bet there is a better way to check but I don't know it off hand. No, at least for the web interface certificates expire in August. It turned out the nsslapd-security was 'off' when it should have been 'on'. I really don't know what had changed the value. Now I only wish we could resolve what's causing the dirsrv process to hang (wrote about that in another message last Sunday) about 10 minutes after IPA services were started. Evidence suggests that the last upgrade failed so I'd start there. It is possible some plugins aren't configured properly, for example. You can try to re-run the upgrade manually. Note that the updater will disable all listeners while it is running. This is where things went sideways before. # /usr/sbin/ipa-ldap-updater --upgrade If that succeeds: # /usr/sbin/ipa-upgradeconfig Then # ipactl restart rob -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] No LDAPS for dirsrv
Hi! On Tue, Feb 17, 2015 at 7:38 PM, Rob Crittenden rcrit...@redhat.com wrote: Now I only wish we could resolve what's causing the dirsrv process to hang (wrote about that in another message last Sunday) about 10 minutes after IPA services were started. Evidence suggests that the last upgrade failed so I'd start there. It is possible some plugins aren't configured properly, for example. Looking at 'yum history' I performed an update after the problems had started an hour or two before. According to /var/log/ipaupgrade.log everything before ipa-ldap-updater ran smoothly. But when it got to 'service dirsrv stop', it took 562 seconds to shutdown dirsrv for EXAMPLE-COM and restarting dirsrv afterwards failed with: 2015-02-15T12:29:58Z DEBUG [4/8]: starting directory server 2015-02-15T12:30:09Z DEBUG args=/sbin/service dirsrv start 2015-02-15T12:30:09Z DEBUG stdout=Starting dirsrv: PKI-IPA... already running[ OK ]^M PVNET-CC...[FAILED]^M *** Error: 1 instance(s) failed to start 2015-02-15T12:30:09Z DEBUG stderr=[15/Feb/2015:14:29:58 +0200] - Information: Non-Secure Port Disabled 2015-02-15T12:30:09Z INFO File /usr/lib/python2.6/site-packages/ipapython/admintool.py, line 152, in execute return_value = self.run() File /usr/lib/python2.6/site-packages/ipaserver/install/ipa_ldap_updater.py, line 139, in run upgrade.create_instance() File /usr/lib/python2.6/site-packages/ipaserver/install/upgradeinstance.py, line 84, in create_instance show_service_name=False) File /usr/lib/python2.6/site-packages/ipaserver/install/service.py, line 358, in start_creation method() File /usr/lib/python2.6/site-packages/ipaserver/install/upgradeinstance.py, line 67, in __start_nowait super(IPAUpgrade, self).start(wait=False) File /usr/lib/python2.6/site-packages/ipaserver/install/service.py, line 265, in start self.service.start(instance_name, capture_output=capture_output, wait=wait) File /usr/lib/python2.6/site-packages/ipapython/platform/redhat.py, line 80, in start ipautil.run([/sbin/service, self.service_name, start, instance_name], capture_output=capture_output) File /usr/lib/python2.6/site-packages/ipapython/ipautil.py, line 316, in run raise CalledProcessError(p.returncode, args) 2015-02-15T12:30:09Z INFO The ipa-ldap-updater command failed, exception: CalledProcessError: Command '/sbin/service dirsrv start ' returned non-zero exit status 1 2015-02-15T12:30:09Z ERROR Unexpected error - see /var/log/ipaupgrade.log for details: CalledProcessError: Command '/sbin/service dirsrv start ' returned non-zero exit status 1 Best regards, Thomas -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] No LDAPS for dirsrv
I would agree with Rob, entropy is likely not one of your root issues. It may still do you good to have a bit more as it can cause system slowdown during SSL generation loads. It's really up to you how you go about generating entropy. Here is a link with some suggestions http://log.amitshah.net/2013/01/about-random-numbers-and-virtual-machines/ I would suggest you just yum install haveged It's worked good for me so far. Good luck, -Chris On 02/17/2015 12:38 PM, Rob Crittenden wrote: Thomas Raehalme wrote: Hi Chris! On Tue, Feb 17, 2015 at 6:35 PM, Chris Mohler cmoh...@oberlin.edu mailto:cmoh...@oberlin.edu wrote: As I wrote earlier we are having some serious problems with IPA right now. dirsrv seems to hang every 15 minutes or so, but that's another post. Are you running in a VM? If so check your entropy. cat /proc/sys/kernel/random/entropy_avail It should be ~1k less than 50 is not great and caused me some issues in the past. Yes, the server is a VM. Entropy value is 135 at the moment. Do you know how to increase the value? I don't think that's an issue. It is more a problem during initial installation than during operation AFAIK. It seems that slapd/dirsrv is now only listening on port 389 for LDAP and socket for LDAPI requests. Any idea what could have caused previously available LDAPS port 636 to disappear? Did your certificates expire? I usually check the web interface and look at the SSL Cert in the browser to see when it expires. I bet there is a better way to check but I don't know it off hand. No, at least for the web interface certificates expire in August. It turned out the nsslapd-security was 'off' when it should have been 'on'. I really don't know what had changed the value. Now I only wish we could resolve what's causing the dirsrv process to hang (wrote about that in another message last Sunday) about 10 minutes after IPA services were started. Evidence suggests that the last upgrade failed so I'd start there. It is possible some plugins aren't configured properly, for example. You can try to re-run the upgrade manually. Note that the updater will disable all listeners while it is running. This is where things went sideways before. # /usr/sbin/ipa-ldap-updater --upgrade If that succeeds: # /usr/sbin/ipa-upgradeconfig Then # ipactl restart rob -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] No LDAPS for dirsrv
Hi! On Tue, Feb 17, 2015 at 8:43 PM, Thomas Raehalme thomas.raeha...@codecenter.fi wrote: Hi! On Tue, Feb 17, 2015 at 7:38 PM, Rob Crittenden rcrit...@redhat.com wrote: Now I only wish we could resolve what's causing the dirsrv process to hang (wrote about that in another message last Sunday) about 10 minutes after IPA services were started. Evidence suggests that the last upgrade failed so I'd start there. It is possible some plugins aren't configured properly, for example. After having restart ipa service, the upgrade command was completed successfully: # ipa-ldap-updater --upgrade Upgrading IPA: [1/8]: stopping directory server [2/8]: saving configuration [3/8]: disabling listeners [4/8]: starting directory server [5/8]: upgrading server [6/8]: stopping directory server [7/8]: restoring configuration [8/8]: starting directory server Done. Now dirsrv was stopped in 2 second when the previous time was over 500 seconds. Unfortunately this still didn't resolve the issue. After the system has been online for about 10 minutes, named starts complaining: Feb 17 21:04:14 ipa named[31117]: LDAP query timed out. Try to adjust timeout parameter Also ldapsearch just hangs if you try to perform any queries. Any ideas what could go wrong here? Best regards, Thomas -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] trying to get a RHEL7.1 beta second master into a RHEL6.6 cluster so I can upgrade.
On 02/17/2015 12:08 AM, Rob Crittenden wrote: Steven Jones wrote: ? [root@xx ipa]# ldapsearch -Y GSSAPI -b cn=CAcert,cn=ipa,cn=etc,$SUFFIX SASL/GSSAPI authentication started SASL username: SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base cn=CAcert,cn=ipa,cn=etc, with scope subtree # filter: (objectclass=*) # requesting: ALL # # search result search: 4 result: 32 No such object # numResponses: 1 Did you literally use $SUFFIX? You need to use dc=example,dc=com, whatever is appropriate for your install. rob Right. Or even easier is to simply delete cn=CAcert,cn=ipa,cn=etc,SUFFIX and then running # ipa-ldap-updater --upgrade again. upload_cacrt.py plugin should simply re-upload the properly encoded certificate. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] issues with sudo on RHEL5.8
On Tue, Feb 17, 2015 at 03:52:31AM -0500, Nicolas Zin wrote: Hi, With a RHEL7 IDM installation, I try to make sudo working. On RHEL6 no problem (via sssd) On RHEL5.8 I don't manage to make it working (credential are good, I manage to request the schema, see below) Where can I found more logs? What did I forget? [root@srv-rhel58-01 ~]# cat /etc/nss_ldap.conf bindn uid=sudo,cn=sysaccounts,cn=etc,dc=company,dc=com binpw redhat5Sudo ssl start_tls tls_cacertfile /etc/openldap/cacerts/ipa.crt #tls_cacert /etc/openldap/cacerts/ipa.crt tls_checkpeer yes #uri ldap://srv-idm7-01.company.com, ldap://srv-idm7-02.company.com uri ldap://srv-idm7-01.company.com sudoers_base ou=SUDOers,dc=company,dc=com sudoers_debug: 2 [root@srv-rhel58-01 ~]# ldapsearch -x -ZZ -D uid=sudo,cn=sysaccounts,cn=etc,dc=company,dc=com -b ou=SUDOers,dc=company,dc=com -h srv-idm7-01.company.com -W Enter LDAP Password: # extended LDIF # # LDAPv3 # base ou=SUDOers,dc=company,dc=com with scope subtree # filter: (objectclass=*) # requesting: ALL # # sudoers, company.com dn: ou=sudoers,dc=company,dc=com objectClass: extensibleObject ou: sudoers # sudo4admin, sudoers, company.com dn: cn=sudo4admin,ou=sudoers,dc=company,dc=com objectClass: sudoRole sudoUser: nzin sudoHost: ALL sudoCommand: ALL cn: sudo4admin # search result search: 3 result: 0 Success # numResponses: 3 # numEntries: 2 In /var/log/secure: Feb 17 04:35:59 srv-rhel58-01 sudo: pam_unix(sudo-i:auth): authentication failure; logname=nzin uid=0 euid=0 tty=/dev/pts/3 ruser= rhost= user=nzin Feb 17 04:35:59 srv-rhel58-01 sudo: pam_sss(sudo-i:auth): authentication success; logname=nzin uid=0 euid=0 tty=/dev/pts/3 ruser= rhost= user=nzin Feb 17 04:35:59 srv-rhel58-01 sudo: nzin : user NOT in sudoers ; TTY=pts/3 ; PWD=/home/nzin ; USER=root ; COMMAND=/bin/bash Regards, I don't have a 5.8 machine around, but I would suggest to enable debugging from sudo itself. In newer versions, there is a Debug directive in sudo.conf, IIRC in earlier versions there was a '-D' option. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Passsync fails to connect to LDAP
On 02/17/2015 12:55 PM, Hugh wrote: All, After my education on what IPA/AD trusts can and can't do, I decided to give the IPA-AD sync option a try. After finally finding what I think is the proper software to install on the AD DC (389-PassSync-1.1.6-x86_64.exe from the Fedora site), I believe I have the settings correct, but the Password Synchronization software refuses to connect. After changing the Log Level option to 1, I get the below in the log file, which doesn't really tell me much of anything. 02/17/15 13:18:20: Backoff time expired. Attempting sync 02/17/15 13:18:20: Password list has 1 entries 02/17/15 13:18:20: Ldap bind error in Connect 81: Can't contact LDAP server 02/17/15 13:18:20: Attempting to sync password for ADSERVER$ 02/17/15 13:18:20: Searching for (ntuserdomainid=ADSERVER$) 02/17/15 13:18:20: Ldap error in QueryUsername 81: Can't contact LDAP server 02/17/15 13:18:20: Deferring password change for ADSERVER$ 02/17/15 13:18:20: Backing off for 256000ms The credentials are definitely correct and IPA is set up to do LDAPS as, on the same AD server, I can connect and bind using ldp.exe with the same settings/credentials and I'm able to browse the LDAP tree. I've done a wireshark capture and it looks like it's failing in the TLS negotiation. I can see this entry in the capture: TLSv1 Record Layer: Alert (Level: Fatal, Description: Protocol Version) Content Type: Alert (21) Version: TLS 1.2 (0x0303) Length: 2 Alert Message Level: Fatal (2) Description: Protocol Version (70) What version of 389-ds-base are you using? # rpm -q 389-ds-base I added the IPA CA cert to the cert files in the 389 passsynch directory and I can confirm that as below. C:\Program Files\389 Directory Password Synchronizationcertutil -d . -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI IPA CA cert CT,, When I list that specific certificate, I can see the below in the output. Certificate Trust Flags: SSL Flags: Valid CA Trusted CA Trusted Client CA Email Flags: Object Signing Flags: Any pointers/ideas? Thanks in advance, Hugh -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
[Freeipa-users] question about Active Directory authentication
Hello, I am currently running an IPA 3.3 server on Centos 7. I have 70 IPA client machines running Scientific Linux 6.6 and 150 users. User directories are auto-mounted from a Centos 7 file server. I have been informed that all computer users on our campus must now authenticate off of the University's Active Directory server, including all Linux machines. I have been looking through the IPA documentation and am getting myself confused and not completely understanding what needs to be done, thus I have some questions. 1. The docs talk about setting up a trust between the IPA server and the AD server. Will I need to change all of the IPA clients as well as the IPA server, or do I only need change the server and not have to touch the clients? 2. Do I even need to set up a full trust relationship just to authenticate my users with AD? 3. Since I already have 150 users, will I have to delete their IPA accounts before setting up the trust? W Sorry if my questions are a bit basic, but I need some guidance to get me started. Thanks! Dave ++ David Fitzgerald Department of Earth Sciences Millersville University Millersville, PA 17551 Phone: 717-871-2394 E-Mail: david.fitzger...@millersville.edu -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Passsync fails to connect to LDAP
On 02/17/2015 01:33 PM, Hugh wrote: What version of 389-ds-base are you using? # rpm -q 389-ds-base Sorry for not specifying. I'm running FreeIPA on CentOS 6.5. Installed via yum - ipa-server-3.0.0-42.el6.centos.x86_64 Ok, so I'm assuming 389-ds-base is 1.2.11.15-48 or later? I think we may need a new version of passsync. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Passsync fails to connect to LDAP
On Tue, Feb 17, 2015 at 2:46 PM, Rich Megginson rmegg...@redhat.com wrote: Ok, so I'm assuming 389-ds-base is 1.2.11.15-48 or later? I think we may need a new version of passsync. I didn't even know those were installed, but you're spot on. Here are the versions of *389*: 389-ds-base-1.2.11.15-48.el6_6.x86_64 389-ds-base-libs-1.2.11.15-48.el6_6.x86_64 From what I can tell in the passsync installer, it was packaged just last month, so I wouldn't think it would be too far out of date. Certainly more recent than my version of IPA. Were there changes to TLS support in passync or the 389-ds-base? Thanks, Hugh -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] question about Active Directory authentication
On 02/17/2015 04:05 PM, David Fitzgerald wrote: Hello, I am currently running an IPA 3.3 server on Centos 7. I have 70 IPA client machines running Scientific Linux 6.6 and 150 users. User directories are auto-mounted from a Centos 7 file server. I have been informed that all computer users on our campus must now authenticate off of the University's Active Directory server, including all Linux machines. I have been looking through the IPA documentation and am getting myself confused and not completely understanding what needs to be done, thus I have some questions. 1.The docs talk about setting up a trust between the IPA server and the AD server. Will I need to change all of the IPA clients as well as the IPA server, or do I only need change the server and not have to touch the clients? With IPA on Centos 7 you can establish trust and you 6.6 machines should be capable of picking the trust automatically. 2.Do I even need to set up a full trust relationship just to authenticate my users with AD? You have three options: - Establish trust - Sync users from AD to IPA - Drop IPA and go direct AD (but you loose a lot). We recommend the trust approach and yet it is a full trust but that does not mean that it is wild west. The trust just means that users can cross authenticate. But if there is no permissions set (which is the case by default) the users even if they are authenticated can't do anything. So if your AD guys a re worried that the trust would open the can of worms it would not. 3.Since I already have 150 users, will I have to delete their IPA accounts before setting up the trust? W Are these users the same as AD users? If they are you can move to IPA 4.1 and convert them to ID Views to assign posix data to the AD users and then remove. https://copr.fedoraproject.org/coprs/mkosek/freeipa/ Sorry if my questions are a bit basic, but I need some guidance to get me started. Thanks! Dave ++ David Fitzgerald Department of Earth Sciences Millersville University Millersville, PA 17551 Phone: 717-871-2394 E-Mail: david.fitzger...@millersville.edu -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] question about Active Directory authentication
I have been informed that all computer users on our campus must now authenticate off of the University's Active Directory server, including all Linux machines. dictated by a clueless Windows * no doubt, ***sigh*** Here we are keeping both separate as AD is so bad security wise, but want some low risk trusts for certain groups of machines (common desktops). If the expectation is its directly off the AD then you dont need IPA at all. However without an expensive commercial addon per Linux server/desktop you wont be able to do much management and control. this has security implications, if you had say a finance or HR server without these commercial tools you may find any AD user could get on them, not what you would want. So you have 2 options in keeping IPA, a) trusts and you should be able keep your users. b) winsync and passync and all the AD users are synced over to IPA. Existing users stay as is, the ones in AD but not in IPA get pulled over to IPA. ***maybe*** c) You might be able to do both winsync and trusts at the same time then that is simpler provisioning. ie a user gets created in AD and automatically gets created in IPA ready for you to put in the user group you want. I'd like to do c) which I am looking at at present, if I ever get IPA on RHEL6.6 upgraded to RHEL7.1! regards Steven J From: freeipa-users-boun...@redhat.com freeipa-users-boun...@redhat.com on behalf of David Fitzgerald david.fitzger...@millersville.edu Sent: Wednesday, 18 February 2015 10:05 a.m. To: freeipa-users@redhat.com Subject: [Freeipa-users] question about Active Directory authentication Hello, I am currently running an IPA 3.3 server on Centos 7. I have 70 IPA client machines running Scientific Linux 6.6 and 150 users. User directories are auto-mounted from a Centos 7 file server. I have been informed that all computer users on our campus must now authenticate off of the University's Active Directory server, including all Linux machines. I have been looking through the IPA documentation and am getting myself confused and not completely understanding what needs to be done, thus I have some questions. 1. The docs talk about setting up a trust between the IPA server and the AD server. Will I need to change all of the IPA clients as well as the IPA server, or do I only need change the server and not have to touch the clients? 2. Do I even need to set up a full trust relationship just to authenticate my users with AD? 3. Since I already have 150 users, will I have to delete their IPA accounts before setting up the trust? W Sorry if my questions are a bit basic, but I need some guidance to get me started. Thanks! Dave ++ David Fitzgerald Department of Earth Sciences Millersville University Millersville, PA 17551 Phone: 717-871-2394 E-Mail: david.fitzger...@millersville.edu -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Passsync fails to connect to LDAP
On 02/17/2015 02:03 PM, Hugh wrote: On Tue, Feb 17, 2015 at 2:46 PM, Rich Megginson rmegg...@redhat.com mailto:rmegg...@redhat.com wrote: Ok, so I'm assuming 389-ds-base is 1.2.11.15-48 or later? I think we may need a new version of passsync. I didn't even know those were installed, but you're spot on. Here are the versions of *389*: 389-ds-base-1.2.11.15-48.el6_6.x86_64 389-ds-base-libs-1.2.11.15-48.el6_6.x86_64 From what I can tell in the passsync installer, it was packaged just last month, so I wouldn't think it would be too far out of date. Certainly more recent than my version of IPA. Were there changes to TLS support in passync or the 389-ds-base? I'm trying to find out now. Thanks, Hugh -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] question about Active Directory authentication
On 02/17/2015 04:34 PM, Steven Jones wrote: I have been informed that all computer users on our campus must now authenticate off of the University's Active Directory server, including all Linux machines. dictated by a clueless Windows * no doubt, ***sigh*** Here we are keeping both separate as AD is so bad security wise, but want some low risk trusts for certain groups of machines (common desktops). If the expectation is its directly off the AD then you dont need IPA at all. However without an expensive commercial addon per Linux server/desktop you wont be able to do much management and control. this has security implications, if you had say a finance or HR server without these commercial tools you may find any AD user could get on them, not what you would want. So you have 2 options in keeping IPA, a) trusts and you should be able keep your users. b) winsync and passync and all the AD users are synced over to IPA. Existing users stay as is, the ones in AD but not in IPA get pulled over to IPA. ***maybe*** c) You might be able to do both winsync and trusts at the same time then that is simpler provisioning. ie a user gets created in AD and automatically gets created in IPA ready for you to put in the user group you want. I am not sure this is the best solution really. Trust and sync do not help each other. The fact that you have trust does not help you to provision users the way you describe. I'd like to do c) which I am looking at at present, if I ever get IPA on RHEL6.6 upgraded to RHEL7.1! regards Steven J *From:* freeipa-users-boun...@redhat.com freeipa-users-boun...@redhat.com on behalf of David Fitzgerald david.fitzger...@millersville.edu *Sent:* Wednesday, 18 February 2015 10:05 a.m. *To:* freeipa-users@redhat.com *Subject:* [Freeipa-users] question about Active Directory authentication Hello, I am currently running an IPA 3.3 server on Centos 7. I have 70 IPA client machines running Scientific Linux 6.6 and 150 users. User directories are auto-mounted from a Centos 7 file server. I have been informed that all computer users on our campus must now authenticate off of the University's Active Directory server, including all Linux machines. I have been looking through the IPA documentation and am getting myself confused and not completely understanding what needs to be done, thus I have some questions. 1.The docs talk about setting up a trust between the IPA server and the AD server. Will I need to change all of the IPA clients as well as the IPA server, or do I only need change the server and not have to touch the clients? 2.Do I even need to set up a full trust relationship just to authenticate my users with AD? 3.Since I already have 150 users, will I have to delete their IPA accounts before setting up the trust? W Sorry if my questions are a bit basic, but I need some guidance to get me started. Thanks! Dave ++ David Fitzgerald Department of Earth Sciences Millersville University Millersville, PA 17551 Phone: 717-871-2394 E-Mail: david.fitzger...@millersville.edu -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
[Freeipa-users] issues with sudo on RHEL5.8
Hi, With a RHEL7 IDM installation, I try to make sudo working. On RHEL6 no problem (via sssd) On RHEL5.8 I don't manage to make it working (credential are good, I manage to request the schema, see below) Where can I found more logs? What did I forget? [root@srv-rhel58-01 ~]# cat /etc/nss_ldap.conf bindn uid=sudo,cn=sysaccounts,cn=etc,dc=company,dc=com binpw redhat5Sudo ssl start_tls tls_cacertfile /etc/openldap/cacerts/ipa.crt #tls_cacert /etc/openldap/cacerts/ipa.crt tls_checkpeer yes #uri ldap://srv-idm7-01.company.com, ldap://srv-idm7-02.company.com uri ldap://srv-idm7-01.company.com sudoers_base ou=SUDOers,dc=company,dc=com sudoers_debug: 2 [root@srv-rhel58-01 ~]# ldapsearch -x -ZZ -D uid=sudo,cn=sysaccounts,cn=etc,dc=company,dc=com -b ou=SUDOers,dc=company,dc=com -h srv-idm7-01.company.com -W Enter LDAP Password: # extended LDIF # # LDAPv3 # base ou=SUDOers,dc=company,dc=com with scope subtree # filter: (objectclass=*) # requesting: ALL # # sudoers, company.com dn: ou=sudoers,dc=company,dc=com objectClass: extensibleObject ou: sudoers # sudo4admin, sudoers, company.com dn: cn=sudo4admin,ou=sudoers,dc=company,dc=com objectClass: sudoRole sudoUser: nzin sudoHost: ALL sudoCommand: ALL cn: sudo4admin # search result search: 3 result: 0 Success # numResponses: 3 # numEntries: 2 In /var/log/secure: Feb 17 04:35:59 srv-rhel58-01 sudo: pam_unix(sudo-i:auth): authentication failure; logname=nzin uid=0 euid=0 tty=/dev/pts/3 ruser= rhost= user=nzin Feb 17 04:35:59 srv-rhel58-01 sudo: pam_sss(sudo-i:auth): authentication success; logname=nzin uid=0 euid=0 tty=/dev/pts/3 ruser= rhost= user=nzin Feb 17 04:35:59 srv-rhel58-01 sudo: nzin : user NOT in sudoers ; TTY=pts/3 ; PWD=/home/nzin ; USER=root ; COMMAND=/bin/bash Regards, Nicolas Zin nicolas@savoirfairelinux.com Ligne directe: 514-276-5468 poste 135 Fax : 514-276-5465 7275 Saint Urbain Bureau 200 Montréal, QC, H2R 2Y5 -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] question about Active Directory authentication
***maybe*** c) You might be able to do both winsync and trusts at the same time then that is simpler provisioning. ie a user gets created in AD and automatically gets created in IPA ready for you to put in the user group you want. I am not sure this is the best solution really. Trust and sync do not help each other. The fact that you have trust does not help you to provision users the way you describe. 8-- They achieve different things. How otherwise do I get 2000+ AD users into IPA? To me winsync allows automated provisioning of users into IPA via AD, this greatly reduces manual effort. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] dirsrv hangs, 0% CPU util
On Mon, Feb 16, 2015 at 8:44 AM, Alexander Bokovoy aboko...@redhat.com wrote: I suspect you've triggered https://fedorahosted.org/freeipa/ticket/4586 and https://fedorahosted.org/freeipa/ticket/4635 -- slapi-nis plugin configuration does not limit itself to $SUFFIX and listens to changes in cn=changelog too so it may deadlock with a replication traffic. We fixed these partly by changing slapi-nis configuration, partly by fixing bugs in 389-ds. I wonder if amending your slapi-nis config to avoid triggering internal searches on cn=changelog would be enough. If you have RHEL subscription, please open a case with Red Hat's support. I opened a support case, but unfortunately the IPA server is running on CentOS so no help from the support. Any chance you could share the configuration changes you referred to above? At the moment we cannot even access ipa-replica-manage because it Can' contact LDAP server. I doubt it has something to do with Kerberos based authentication, as kinit is also really unstable at the moment. Best regards, Thomas -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] issues with sudo on RHEL5.8
Thanks, that helps! I mistyped binddn and bindpw - Mail original - De: Lukasz Jaworski lukasz.jawor...@allegrogroup.com À: Nicolas Zin nicolas@savoirfairelinux.com Cc: freeipa-users@redhat.com Envoyé: Mardi 17 Février 2015 13:31:20 Objet: Re: [Freeipa-users] issues with sudo on RHEL5.8 With a RHEL7 IDM installation, I try to make sudo working. On RHEL6 no problem (via sssd) On RHEL5.8 I don't manage to make it working (credential are good, I manage to request the schema, see below) Where can I found more logs? What did I forget? [root@srv-rhel58-01 ~]# cat /etc/nss_ldap.conf bindn uid=sudo,cn=sysaccounts,cn=etc,dc=company,dc=com binpw redhat5Sudo ssl start_tls tls_cacertfile /etc/openldap/cacerts/ipa.crt #tls_cacert /etc/openldap/cacerts/ipa.crt tls_checkpeer yes #uri ldap://srv-idm7-01.company.com, ldap://srv-idm7-02.company.com uri ldap://srv-idm7-01.company.com sudoers_base ou=SUDOers,dc=company,dc=com sudoers_debug: 2 change last line (remove :) to: sudoers_debug 2 And then try sudo. Check: /etc/nsswitch.conf should be: sudoers: files ldap Best regards, Ender -- Łukasz Jaworski -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
