Re: [Freeipa-users] A public interface (aka My account management)
On 04/24/2013 10:30 PM, Chris Evich wrote: On 04/24/2013 08:32 AM, Tomas Babej wrote: On 04/24/2013 01:53 PM, Arturo Borrero wrote: Hi there. I'm wondering if it's possible to get FreeIPA with a 'public user interface'. This is: a place where a standar user can update his password and other personal data. I'm thinking in something similar to google.com/accounts Does this exists? If not, it is possible to develop this addon? We are strongly evaluating this functionality in order to actually implement FreeIPA as our identity management system. Best regards Hi, every user can log in to the Web UI using their login and Kerberos password. Having no other rights, there they can only edit their contact information, address information, reset their password, etc. See /ipa/ui/ on your FreeIPA server, that is https://ipa.example.com/ipa/ui/ https://vm-131.idm.lab.bos.redhat.com/ipa/ui/index.html#identity =usernavigation=identityuser-pkey=randomuser-facet=details Having played with it off/on a year or so ago, IIRC it's relatively easy to get apache + SSL speaking with LDAP + Kerberos. Even ignoring the direct python IPA interface. With some server-side scripting (I did it in python) you could emulate most of what's on the google accounts-page. The hardest part I found was getting my head around the lower-level LDAP + Kerberos python interfaces. However, going from understanding common-operations of both technologies from the command-line level to working with the API's isn't a very long road. Depending on how pretty the web-site needs to be, the code one yourself approach could be feasible, given educated developer resources. Since it sounds like your requirements are fairly basic, this may be an option to consider. (No I'm not volunteering, though it sounds fun :) Otherwise, I've also used the built-in web interface. It may be a bit cluttered for someone who _just_ needs to change a password or other very simplistic task (compared to google accounts-page). However if your users are somewhat technically-mided, they shouldn't have any trouble with the built-in self-service UI. It also offers a HUGE benefit to greatly extend self-service to the n-th degree, when it's multi-level rights-management features are used. Hello Chris, Thanks for info! Do you have any specific suggestions which would help you make the user self-service page more acceptable for regular users? Having users building their own selfservice pages instead of using the vanilla selfservice page does not seems like something we would like to have. We are already considering simplifying the self-service page, so any suggestions and ideas for improving it are welcome. Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] A public interface (aka My account management)
On 25/04/13 10:30, Martin Kosek wrote: On 04/24/2013 10:30 PM, Chris Evich wrote: On 04/24/2013 08:32 AM, Tomas Babej wrote: On 04/24/2013 01:53 PM, Arturo Borrero wrote: Hi there. I'm wondering if it's possible to get FreeIPA with a 'public user interface'. This is: a place where a standar user can update his password and other personal data. I'm thinking in something similar to google.com/accounts Does this exists? If not, it is possible to develop this addon? We are strongly evaluating this functionality in order to actually implement FreeIPA as our identity management system. Best regards Hi, every user can log in to the Web UI using their login and Kerberos password. Having no other rights, there they can only edit their contact information, address information, reset their password, etc. See /ipa/ui/ on your FreeIPA server, that is https://ipa.example.com/ipa/ui/ https://vm-131.idm.lab.bos.redhat.com/ipa/ui/index.html#identity =usernavigation=identityuser-pkey=randomuser-facet=details Having played with it off/on a year or so ago, IIRC it's relatively easy to get apache + SSL speaking with LDAP + Kerberos. Even ignoring the direct python IPA interface. With some server-side scripting (I did it in python) you could emulate most of what's on the google accounts-page. The hardest part I found was getting my head around the lower-level LDAP + Kerberos python interfaces. However, going from understanding common-operations of both technologies from the command-line level to working with the API's isn't a very long road. Depending on how pretty the web-site needs to be, the code one yourself approach could be feasible, given educated developer resources. Since it sounds like your requirements are fairly basic, this may be an option to consider. (No I'm not volunteering, though it sounds fun :) Otherwise, I've also used the built-in web interface. It may be a bit cluttered for someone who _just_ needs to change a password or other very simplistic task (compared to google accounts-page). However if your users are somewhat technically-mided, they shouldn't have any trouble with the built-in self-service UI. It also offers a HUGE benefit to greatly extend self-service to the n-th degree, when it's multi-level rights-management features are used. Hello Chris, Thanks for info! Do you have any specific suggestions which would help you make the user self-service page more acceptable for regular users? Having users building their own selfservice pages instead of using the vanilla selfservice page does not seems like something we would like to have. We are already considering simplifying the self-service page, so any suggestions and ideas for improving it are welcome. Hi all, thanks all for your quick and deep response. FreeIPA is an amazing tool :-) Best regards. -- Arturo Borrero González Departamento de Seguridad Informática (n...@cica.es) Centro Informático Científico de Andalucía (CICA) Avda. Reina Mercedes s/n - 41012 - Sevilla (Spain) Tfno.: +34 955 056 600 / FAX: +34 955 056 650 Consejería de Economía, Innovación, Ciencia y Empleo Junta de Andalucía smime.p7s Description: S/MIME Cryptographic Signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Issue IPA: AD Users and IPA Users when using SSS/LDAP with SUDO
On Thu, Apr 25, 2013 at 12:38:18PM +0200, Pavel Březina wrote: On 04/24/2013 07:20 PM, Aly Khimji wrote: (Wed Apr 24 13:07:35 2013) [sssd[be[nix.corpnonprd..com]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, NULL) [Success] (Wed Apr 24 13:07:35 2013) [sssd[be[nix.corpnonprd..com]]] [sss_selinux_extract_user] (0x0040): sysdb_search_user_by_name failed. (Wed Apr 24 13:07:35 2013) [sssd[be[nix.corpnonprd..com]]] [ipa_selinux_handler] (0x0040): Cannot create op context This issue is already know, https://bugzilla.redhat.com/show_bug.cgi?id=954342 and https://fedorahosted.org/sssd/ticket/1892 . I will send a fix for this to sssd-devel soon. bye, Sumit (Wed Apr 24 13:07:35 2013) [sssd[be[nix.corpnonprd..com]]] [be_pam_handler_callback] (0x0100): Backend returned: (3, 4, NULL) [Internal Error (System error)] Hi, this looks like a selinux problem to me. What happens when you set selinux to permissive? Also does this problem occur only with sudo, or other services are affected too (id, authentication, ssh)? Can you please perform following commands? It will remove cache and logs so do it in a safe non-production environment. As root: # service stop sssd # rm -f /var/lib/sss/db/* /var/lib/sss/mc/* /var/log/sssd/* # service sssd start As normal user: $ su ad-user@trusted-domain $ sudo -l $ exit And send us the sanitized logs (all of them). Thank you. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Freeipa -ssh keys
Hi Jan yes thats correct clinet is ldap1 and server is ldap1. root@ldap1 ssh]# /usr/bin/sss_ssh_knownhostsproxy -p 22 ldap1.eng.switchlab.net --debug 10 SSH-2.0-OpenSSH_6.1 Protocol mismatch. [root@ldap1 ssh]# /usr/bin/sss_ssh_authorizedkeys test@eng ssh-rsa B3NzaC1yc2EBIwAAAQEAzvp0DW9X6hJjbcoaY25HrzYvfNOZ37IUe5gvlhO1i+bMhj8vhwlKZN6OKeMW6AM37aJhd7jxhz1R+Cod18YTB+gHkrfwe75kkEKfVyvTjpp9j5DRPeTyGMyWt4VbbyYq1Po4BZT7wOtUjwFq320QD5QnNKU6nbQKsB61xCMQy1Peu0nV/33dQTWHzlGi4uV0MN/KBvaWHmTwN6ZJ34uyEQ8kQ+fStd9XNFREw0iYglk42mNd/SA35njqNlsUbtBAR9ZokruAwAVVZqrfQw== te...@ldap.eng. ssh-rsa B3NzaC1yc2Exxx4yb3prkr4oobGuyKJj/yd+S4Pf7OUzZT2xXzpy0TZAjiLnqlioxnhyZqgLO/Rdg5o+wt3R7H7L9kGDfMtAyBqUBrRqQeYgfGWvoVrm2UhkTcq/jxxACbYZq0Jg7OTFXodV40uAuRKqVgev6W4V+ozrTxpeVRElqTM4cEJ96V0UxLUpZUHvT1exFKk4F1crZ2hLEuPVWOlOj8NS/sQX3DDuDS69+CH89z5ftzZZCmohY89y2AsJXfA0piHxg2XE+n test@ubuntu ssh-rsa B3NzaC1yc2EAAAxsYsB/hx3gm2fIoKq6fm0g976L26oAmclDi12CpVFYbI/osIjsq6mIpr9de5Qus/n9kIoxTZLHTRuoCEj7xc4PSPG78oE7JoWKLMvBDiwyhXNa+O9X1RgYhfYmS2m+1nGJYC9DG4xo7K60nO6WogBg3T+EwuDjYrVIfB5Rfe4D8iWKqOTNlJ+MzK4Dk8W8hqSJvuQFq5155DsbeqDy00EY1dMaGYVUq81lHEM91oz t...@ldap0.eng. Nareshchandra Paturi 14, St. Augustine’s Court, Mornington Road, london. E11 3BQ. Mob:0746001,07856918100 Ph:02082579579 From: Jan Cholasta jchol...@redhat.com To: naresh reddy nareshbt...@yahoo.com Cc: Rob Crittenden rcrit...@redhat.com; freeipa-users@redhat.com freeipa-users@redhat.com Sent: Wednesday, April 24, 2013 11:30 AM Subject: Re: [Freeipa-users] Freeipa -ssh keys On 23.4.2013 20:20, naresh reddy wrote: Hi Rob I am sorry for coming back again i can see client can get the ssh keys from the server but still fails please suggest. By client you mean the machine that you are trying to ssh to, i.e. the machine that has sshd running? If not, make sure sss_ssh_authorizedkeys works on the machine with sshd, because that's the one that matters here. Also, what version of OpenSSH do you have installed? Honza -- Jan Cholasta___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Freeipa -ssh keys
Hi Jan I tried to flow this https://fedoraproject.org/wiki/QA:Testcase_FreeIPA_realmd_ssh https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/openssh-sssd.html still unable to loggin via ssh keys Please kindly suggest OpenSSH_6.1p1, OpenSSL 1.0.1e-fips 11 Feb 2013 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 55: Applying options for * debug1: Executing proxy command: exec /usr/bin/sss_ssh_knownhostsproxy -p 22 -d ENG.SWITCHLAB.COM ldap1.eng.switchlab.net --debug 40 debug1: identity file /home/np/.ssh/id_rsa type 1 debug1: identity file /home/np/.ssh/id_rsa-cert type -1 debug1: identity file /home/np/.ssh/id_dsa type -1 debug1: identity file /home/np/.ssh/id_dsa-cert type -1 debug1: permanently_drop_suid: 1000 (Thu Apr 25 17:45:58:088846 2013) [/usr/bin/sss_ssh_knownhostsproxy] [main] (0x0040): sss_ssh_get_ent() failed (2): No such file or directory debug1: Remote protocol version 2.0, remote software version OpenSSH_6.1 debug1: match: OpenSSH_6.1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.1 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server-client aes128-ctr hmac-md5 none debug1: kex: client-server aes128-ctr hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(102410248192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Server host key: RSA 22:fd:38:1c:25:80:fc:15:87:31:7b:b9:7b:59:f6:07 debug1: Host 'ldap1.eng.switchlab.net' is known and matches the RSA host key. debug1: Found key in /home/np/.ssh/known_hosts:1 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic debug1: Next authentication method: gssapi-keyex debug1: No valid Key exchange context debug1: Next authentication method: gssapi-with-mic debug1: Unspecified GSS failure. Minor code may provide more information Ticket expired debug1: Unspecified GSS failure. Minor code may provide more information Ticket expired debug1: Unspecified GSS failure. Minor code may provide more information debug1: Unspecified GSS failure. Minor code may provide more information Matching credential not found debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/np/.ssh/id_rsa debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic debug1: Trying private key: /home/np/.ssh/id_dsa debug1: No more authentication methods to try. Permission denied (publickey,gssapi-keyex,gssapi-with-mic). [np@ldap0 ~]$ ssh -v n...@eng.switchlab.net@ldap1.eng.switchlab.net OpenSSH_6.1p1, OpenSSL 1.0.1e-fips 11 Feb 2013 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 55: Applying options for * debug1: Executing proxy command: exec /usr/bin/sss_ssh_knownhostsproxy -p 22 -d ENG.SWITCHLAB.COM ldap1.eng.switchlab.net --debug 40 debug1: identity file /home/np/.ssh/id_rsa type 1 debug1: identity file /home/np/.ssh/id_rsa-cert type -1 debug1: identity file /home/np/.ssh/id_dsa type -1 debug1: identity file /home/np/.ssh/id_dsa-cert type -1 debug1: permanently_drop_suid: 1000 (Thu Apr 25 18:06:04:463614 2013) [/usr/bin/sss_ssh_knownhostsproxy] [main] (0x0040): sss_ssh_get_ent() failed (2): No such file or directory debug1: Remote protocol version 2.0, remote software version OpenSSH_6.1 debug1: match: OpenSSH_6.1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.1 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server-client aes128-ctr hmac-md5 none debug1: kex: client-server aes128-ctr hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(102410248192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Server host key: RSA 22:fd:38:1c:25:80:fc:15:87:31:7b:b9:7b:59:f6:07 debug1: Host 'ldap1.eng.switchlab.net' is known and matches the RSA host key. debug1: Found key in /home/np/.ssh/known_hosts:1 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic debug1: Next authentication method: gssapi-keyex debug1: No valid Key exchange context debug1: Next authentication method: gssapi-with-mic debug1: Unspecified GSS failure. Minor code may provide more information Ticket
[Freeipa-users] deleted ipa admin groups
Hello Someone did delete the admin group by mistake, how can we recover from this? No one change password, or any other admin task is allow. But we have the Directory server password. the remaining group is ipausers and we had only the default group Please any help will be appreciate -- Sylvain Angers ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] deleted ipa admin groups
Sylvain Angers wrote: Hello Someone did delete the admin group by mistake, how can we recover from this? No one change password, or any other admin task is allow. But we have the Directory server password. the remaining group is ipausers and we had only the default group Please any help will be appreciate We prevent this in newer versions. This is untested so YMMV. Try putting this into an LDIF. Change example.com and replace UID with the UID of the old group if you can. If you don't have it then use 999 and a new one should be assigned. dn: cn=admins,cn=groups,cn=accounts,dc=example,dc=com objectClass: top objectClass: groupofnames objectClass: posixgroup objectClass: ipausergroup objectClass: ipaobject objectClass: nestedGroup cn: admins description: Account administrators group member: uid=admin,cn=users,cn=accounts,dc=example,dc=com gidNumber: UID # ldapadd -x -D 'cn=Directory Manager' -W /path/to/ldif You also may need to fix up some delegations. You can use ipa-show --all --raw on these privileges to see if admins is a member, I doubt it is. You want to look at: Replication Administrators Host Enrollment Unlock user accounts Manage service keytab If not add it using something like this for each privilege: # ldapmodify -x -D 'cn=Directory Manager' -w password dn: cn=Replication Administrators,cn=privileges,cn=pbac,dc=example,dc=com changetype: modify add: member member: cn=admins,cn=groups,cn=accounts,dc=example,dc=com ^D rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Freeipa-users Digest, Vol 57, Issue 66
I use the following on my CentOS 6.3 servers for the ssh keys to work from IPA. sshd.conf AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys -- To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] Freeipa -ssh keys Message-ID: 517994ae.4050...@redhat.com AuthorizedKeysCommand '/usr/bin/sss_ssh_authorizedkeys %u' -- Brent S. Clark NOC Engineer 2580 55th St. | Boulder, Colorado 80301 www.tendrilinc.com | blog http://www.tendrilinc.com/news-room/blog/ [image: Tendril] http://www.tendrilinc.com/ This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Freeipa -ssh keys
On Thu, 25 Apr 2013, naresh reddy wrote: Hi all my sshd config file # $OpenBSD: sshd_config,v 1.87 2012/07/10 02:19:15 djm Exp $ # This is the sshd server system-wide configuration file. See # sshd_config(5) for more information. # This sshd was compiled with PATH=/usr/local/bin:/usr/bin # The strategy used for options in the default sshd_config shipped with # OpenSSH is to specify options with their default value where # possible, but leave them commented. Uncommented options override the # default value. # If you want to change the port on a SELinux system, you have to tell # SELinux about this change. # semanage port -a -t ssh_port_t -p tcp #PORTNUMBER # Port 22 #AddressFamily any #ListenAddress 0.0.0.0 #ListenAddress :: # The default requires explicit activation of protocol 1 #Protocol 2 # HostKey for protocol version 1 #HostKey /etc/ssh/ssh_host_key # HostKeys for protocol version 2 #HostKey /etc/ssh/ssh_host_rsa_key #HostKey /etc/ssh/ssh_host_dsa_key #HostKey /etc/ssh/ssh_host_ecdsa_key # Lifetime and size of ephemeral version 1 server key #KeyRegenerationInterval 1h #ServerKeyBits 1024 # Logging # obsoletes QuietMode and FascistLogging #SyslogFacility AUTH SyslogFacility AUTHPRIV #LogLevel INFO # Authentication: #LoginGraceTime 2m #PermitRootLogin yes #StrictModes yes #MaxAuthTries 6 #MaxSessions 10 RSAAuthentication yes PubkeyAuthentication yes # The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2 # but this is overridden so installations will only check .ssh/authorized_keys #AuthorizedKeysFile .ssh/authorized_keys #AuthorizedKeysCommand none AuthorizedKeysCommandUser nobody #AuthorizedPrincipalsFile none # For this to work you will also need host keys in /etc/ssh/ssh_known_hosts #RhostsRSAAuthentication no # similar for protocol version 2 #HostbasedAuthentication no # Change to yes if you don't trust ~/.ssh/known_hosts for # RhostsRSAAuthentication and HostbasedAuthentication #IgnoreUserKnownHosts no # Don't read the user's ~/.rhosts and ~/.shosts files #IgnoreRhosts yes # To disable tunneled clear text passwords, change to no here! #PasswordAuthentication yes #PermitEmptyPasswords no #PasswordAuthentication no # Change to no to disable s/key passwords #ChallengeResponseAuthentication yes #ChallengeResponseAuthentication no # Kerberos options #KerberosAuthentication no #KerberosOrLocalPasswd yes #KerberosTicketCleanup yes #KerberosGetAFSToken no #KerberosUseKuserok yes # GSSAPI options #GSSAPIAuthentication yes #GSSAPICleanupCredentials yes #GSSAPICleanupCredentials yes #GSSAPIStrictAcceptorCheck yes #GSSAPIKeyExchange no # Set this to 'yes' to enable PAM authentication, account processing, # and session processing. If this is enabled, PAM authentication will # be allowed through the ChallengeResponseAuthentication and # PasswordAuthentication. Depending on your PAM configuration, # PAM authentication via ChallengeResponseAuthentication may bypass # the setting of PermitRootLogin without-password. # If you just want the PAM account and session checks to run without # PAM authentication, then enable this but set PasswordAuthentication # and ChallengeResponseAuthentication to 'no'. # WARNING: 'UsePAM no' is not supported in Fedora and may cause several # problems. #UsePAM no #AllowAgentForwarding yes #AllowTcpForwarding yes #GatewayPorts no #X11Forwarding no X11Forwarding yes #X11DisplayOffset 10 #X11UseLocalhost yes #PrintMotd yes #PrintLastLog yes #TCPKeepAlive yes #UseLogin no UsePrivilegeSeparation sandbox # Default for new installations. #PermitUserEnvironment no #Compression delayed #ClientAliveInterval 0 #ClientAliveCountMax 3 #ShowPatchLevel no #UseDNS yes #PidFile /var/run/sshd.pid #MaxStartups 10 #PermitTunnel no #ChrootDirectory none #VersionAddendum none # no default banner path #Banner none # Accept locale-related environment variables AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE AcceptEnv XMODIFIERS # override default of no subsystems Subsystem sftp /usr/libexec/openssh/sftp-server # Uncomment this if you want to use .local domain #Host *.local # CheckHostIP no # Example of overriding settings on a per-user basis #Match User anoncvs # X11Forwarding no # AllowTcpForwarding no # ForceCommand cvs server KerberosAuthentication no PubkeyAuthentication yes UsePAM yes #GSSAPIAuthentication yes GSSAPIAuthentication defaults to 'no' in OpenSSH. We require it set to 'yes' in order to log in with Kerberos ticket. As your other Kerberos options were disabled as well, the result is predictable. It looks like you haven't configured this machine with ipa-client-install since that would have turned GSSAPIAuthentication to 'yes'. Or you did change sshd_config by yourself to non-working state. -- / Alexander Bokovoy
[Freeipa-users] exporting ldap certificate
Hi everyone. I am attempting to get Google Apps to sync with FreeIPA and I am having problems getting the sync utility to talk to freeipa. It complains about the ssl cert. I have it setup so it only accepts ssl or tls encrypted connections and I don't want to turn that off. I have imported the ca cert using the jre's keytool but it still refuses to connect. I am getting the impression I need to import the ssl cert for the ldap server into it as well. I have no idea which certificate that is and I have no idea how to export it. Can someone please tell me how to do this? Thanks in advance. Pete. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
