Re: [Freeipa-users] FreeIPA vs DogTag CA

2016-08-11 Thread Fraser Tweedale 
On Thu, Aug 11, 2016 at 11:54:25AM -0400, Rob Crittenden wrote:
> Kamal Perera wrote:
> > Dear all,
> > 
> > Seeking your kind advices.
> > 
> > If the requirement is for having a scalable corporate CA only, is it
> > possible to get this requirement fulfilled with DogTag only, or install
> > FreeIPA and use the CA functionality only.
> 
> IPA limits dogtag to only those features it is interested in. This has been
> expanding recently but you still lose some functionality.
> 
> IMHO if all you want is a CA then managing IPA is overkill.
> 
> > What are the functional differences and support limitations?
> 
> Functionally it depends on what version of IPA you're talking about. Older
> versions only exposed server certificates. Newer versions support user
> certifications, custom profiles and more. It is still just a subset of what
> dogtag supports.
> 
> Support from whom? The dogtag community is happy to help (they've always
> helped us).
> 
There are lots of questions that can help you decide which path to
take: what kinds of certs do you want to issue; to what entities;
who will issue them; are you already using FreeIPA in your
organisation?

In regards to functional differences, Dogtag CA and KRA are
supported with FreeIPA; token processing and standalone OCSP are
not.  I disagree somewhat with Rob in that unless you need those
other Dogtag subsystems, I see little disadvantage in using FreeIPA.
It definitely makes deploying the CA easier and managing renewals
easier.

The more you tell us of your requirements, the more we can help :)

Thanks,
Fraser

-- 
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] sudo rules question on ubuntu 16.0.1

2016-08-11 Thread Justin Stephenson 

Hello,

Could you increase the debug level to 9, restart sssd  + clear the cache 
and reproduce the problem then provide the sssd_.log as well as 
the sssd_sudo.log ?


Also you may want to rule out HBAC issues with the below command:

 # ipa hbactest --user 'jgoddard' --host $(hostname) --service sudo

Kind regards,

Justin Stephenson

On 08/11/2016 02:24 PM, Jeff Goddard wrote:

Here is relevant configuration files:

*nsswitch.conf:*

passwd: compat sss
group:  compat sss
shadow: compat sss
gshadow:files

hosts:  files dns
networks:   files

protocols:  db files
services:   db files sss
ethers: db files
rpc:db files

netgroup:   nis sss
sudoers: sss files

*sssd.conf:*

[domain/internal.emerlyn.com ]

cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = internal.emerlyn.com 
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = docker-dev-01.internal.emerlyn.com 


chpass_provider = ipa
ipa_server = _srv_, id-management-1.internal.emerlyn.com 


ldap_tls_cacert = /etc/ipa/ca.crt
sudo_provider=ipa
ldap_uri=ldap://id-management-1.internal.emerlyn.com 


ldap_sudo_search_base=ou=sudoers,dc=internal,dc=emerlyn,dc=com
debug_level=7

[sssd]
services = nss, pam, sudo, ssh
debug_level=7
domains = internal.emerlyn.com 

[nss]
homedir_substring = /home

[pam]

[sudo]
debug_level=7
[autofs]

[ssh]
debug_level=7
[pac]

[ifp]

*Log output - /var/log/sssd/sssd_sudo.log:

*(Thu Aug 11 12:21:43 2016) [sssd[sudo]] [accept_fd_handler] (0x0400): 
Client connected!
(Thu Aug 11 12:21:43 2016) [sssd[sudo]] [sss_cmd_get_version] 
(0x0200): Received client version [1].
(Thu Aug 11 12:21:43 2016) [sssd[sudo]] [sss_cmd_get_version] 
(0x0200): Offered version [1].
(Thu Aug 11 12:21:43 2016) [sssd[sudo]] [sss_parse_name_for_domains] 
(0x0200): name 'jgoddard' matched without domain, user is jgoddard
(Thu Aug 11 12:21:43 2016) [sssd[sudo]] [sss_parse_name_for_domains] 
(0x0200): name 'jgoddard' matched without domain, user is jgoddard
(Thu Aug 11 12:21:43 2016) [sssd[sudo]] [sudosrv_cmd_parse_query_done] 
(0x0200): Requesting default options for [jgoddard] from []
(Thu Aug 11 12:21:43 2016) [sssd[sudo]] [sudosrv_get_user] (0x0200): 
Requesting info about [jgodd...@internal.emerlyn.com 
]
(Thu Aug 11 12:21:43 2016) [sssd[sudo]] [sudosrv_get_user] (0x0400): 
Returning info for user [jgodd...@internal.emerlyn.com 
]
(Thu Aug 11 12:21:43 2016) [sssd[sudo]] [sudosrv_get_rules] (0x0400): 
Retrieving default options for [jgoddard] from [internal.emerlyn.com 
]
(Thu Aug 11 12:21:43 2016) [sssd[sudo]] 
[sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with 
[(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=jgoddard)(sudoUser=#32001)(sudoUser=%developers)(sudoUser=%jira-administrators)(sudoUser=%admins)(sudoUser=%ipausers)(sudoUser=%jgoddard)(sudoUser=+*))(&(dataExpireTimestamp<=1470932503)))]
(Thu Aug 11 12:21:43 2016) [sssd[sudo]] 
[sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with 
[(&(objectClass=sudoRule)(|(name=defaults)))]
(Thu Aug 11 12:21:43 2016) [sssd[sudo]] 
[sudosrv_get_sudorules_from_cache] (0x0400): Returning 0 rules for 
[@internal.emerlyn.com ]
(Thu Aug 11 12:21:43 2016) [sssd[sudo]] [sss_parse_name_for_domains] 
(0x0200): name 'jgoddard' matched without domain, user is jgoddard*
(*Thu Aug 11 12:21:43 2016) [sssd[sudo]] [sss_parse_name_for_domains] 
(0x0200): name 'jgoddard' matched without domain, user is jgoddard
(Thu Aug 11 12:21:43 2016) [sssd[sudo]] [sudosrv_cmd_parse_query_done] 
(0x0200): Requesting rules for [jgoddard] from []
(Thu Aug 11 12:21:43 2016) [sssd[sudo]] [sudosrv_get_user] (0x0200): 
Requesting info about [jgodd...@internal.emerlyn.com 
]
(Thu Aug 11 12:21:43 2016) [sssd[sudo]] [sudosrv_get_user] (0x0400): 
Returning info for user [jgodd...@internal.emerlyn.com 
]
(Thu Aug 11 12:21:43 2016) [sssd[sudo]] [sudosrv_get_rules] (0x0400): 
Retrieving rules for [jgoddard] from [internal.emerlyn.com 
]
(Thu Aug 11 12:21:43 2016) [sssd[sudo]] 
[sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with 
[(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=jgoddard)(sudoUser=#32001)(sudoUser=%developers)(sudoUser=%jira-administrators)(sudoUser=%admins)(sudoUser=%ipausers)(sudoUser=%jgoddard)(sudoUser=+*))(&(dataExpireTimestamp<=1470932503)))]
(Thu Aug 11 12:21:43 2016) [sssd[sudo]] 
[sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with

Re: [Freeipa-users] headless ipa client join using kerberos ticket

2016-08-11 Thread Rob Crittenden 

Troels Hansen wrote:

I can see this have been discussed a lot here, but I still can't seem to
find the correct answer, so bare with me if i'm asking a question
already answered.

I'm trying to create a user that can be used for (headless) joining out
RHEL clients to IPA

Here is what have been done:
/etc/krb5.conf and /etc/ipa/ca.crt copied to the client.

a user created on IPA:

# ipa user-show joinipa
User login: joinipa
First name: Host
Last name: Adder
Home directory: /home/joinipa
Login shell: /bin/sh
Email address: join...@linux.dr.dk
UID: 10006
GID: 10006
Account disabled: False
Password: False
Member of groups: ipausers
Roles: joinipa
Kerberos keys available: True

has role joinipa

# ipa role-show "joinipa"
Role name: joinipa
Member users: joinipa
Privileges: Host Enrollment

Host Enrollemnt provilege also has the 'System: Add Hosts' permission:

# ipa privilege-show "Host Enrollment"
Privilege name: Host Enrollment
Description: Host Enrollment
Permissions: System: Add Hosts, System: Add krbPrincipalName to a Host,
System: Enroll a Host, System: Manage Host Certificates,
System: Manage Host Enrollment Password, System: Manage Host Keytab
Granting privilege to roles: joinipa

Get the keytab from IPA server (run on IPA server):
# ipa-getkeytab -s  `hostname` -p join...@linux.dr.dk -k /tmp/joinipa.keytab

Keytab copied to IPA client:

kinit keytab:
# kinit join...@linux.dr.dk -kt joinipa.keytab

# klist
Ticket cache: KEYRING:persistent:0:0
Default principal: join...@linux.dr.dk

Valid starting Expires Service principal
08/11/2016 10:12:33 08/12/2016 10:12:33 krbtgt/linux.dr...@linux.dr.dk

Try to join IPA server:
# ipa-join --server ipa01tst.linux.dr.dk
Failed to parse result: Insufficient access rights

Retrying with pre-4.0 keytab retrieval method...
Keytab successfully retrieved and stored in: /etc/krb5.keytab
Certificate subject base is: O=LINUX.DR.DK

Host gets created on IPA server, but what makes it fail?

If I try to join again I also get told its already joined:

# ipa-join --server ipa01tst.linux.dr.dk
Host is already joined.


Hard to say since you don't include what version of IPA this is, but I 
think you're misinterpreting this. The join is successful (check the rval).


I think it failed trying to read the existing keytab (and it doesn't 
matter that there isn't one yet) in LDAP. This fails so it then creates 
one using another method. That permission is separate (but probably not 
too important in this use case).


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] sudo rules question on ubuntu 16.0.1

2016-08-11 Thread Jeff Goddard 
Here is relevant configuration files:

*nsswitch.conf:*

passwd: compat sss
group:  compat sss
shadow: compat sss
gshadow:files

hosts:  files dns
networks:   files

protocols:  db files
services:   db files sss
ethers: db files
rpc:db files

netgroup:   nis sss
sudoers: sss files

*sssd.conf:*

[domain/internal.emerlyn.com]

cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = internal.emerlyn.com
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = docker-dev-01.internal.emerlyn.com
chpass_provider = ipa
ipa_server = _srv_, id-management-1.internal.emerlyn.com
ldap_tls_cacert = /etc/ipa/ca.crt
sudo_provider=ipa
ldap_uri=ldap://id-management-1.internal.emerlyn.com
ldap_sudo_search_base=ou=sudoers,dc=internal,dc=emerlyn,dc=com
debug_level=7

[sssd]
services = nss, pam, sudo, ssh
debug_level=7
domains = internal.emerlyn.com

[nss]
homedir_substring = /home

[pam]

[sudo]
debug_level=7
[autofs]

[ssh]
debug_level=7
[pac]

[ifp]



*Log output - /var/log/sssd/sssd_sudo.log:*(Thu Aug 11 12:21:43 2016)
[sssd[sudo]] [accept_fd_handler] (0x0400): Client connected!
(Thu Aug 11 12:21:43 2016) [sssd[sudo]] [sss_cmd_get_version] (0x0200):
Received client version [1].
(Thu Aug 11 12:21:43 2016) [sssd[sudo]] [sss_cmd_get_version] (0x0200):
Offered version [1].
(Thu Aug 11 12:21:43 2016) [sssd[sudo]] [sss_parse_name_for_domains]
(0x0200): name 'jgoddard' matched without domain, user is jgoddard
(Thu Aug 11 12:21:43 2016) [sssd[sudo]] [sss_parse_name_for_domains]
(0x0200): name 'jgoddard' matched without domain, user is jgoddard
(Thu Aug 11 12:21:43 2016) [sssd[sudo]] [sudosrv_cmd_parse_query_done]
(0x0200): Requesting default options for [jgoddard] from []
(Thu Aug 11 12:21:43 2016) [sssd[sudo]] [sudosrv_get_user] (0x0200):
Requesting info about [jgodd...@internal.emerlyn.com]
(Thu Aug 11 12:21:43 2016) [sssd[sudo]] [sudosrv_get_user] (0x0400):
Returning info for user [jgodd...@internal.emerlyn.com]
(Thu Aug 11 12:21:43 2016) [sssd[sudo]] [sudosrv_get_rules] (0x0400):
Retrieving default options for [jgoddard] from [internal.emerlyn.com]
(Thu Aug 11 12:21:43 2016) [sssd[sudo]] [sudosrv_get_sudorules_query_cache]
(0x0200): Searching sysdb with
[(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=jgoddard)(sudoUser=#32001)(sudoUser=%developers)(sudoUser=%jira-administrators)(sudoUser=%admins)(sudoUser=%ipausers)(sudoUser=%jgoddard)(sudoUser=+*))(&(dataExpireTimestamp<=1470932503)))]
(Thu Aug 11 12:21:43 2016) [sssd[sudo]] [sudosrv_get_sudorules_query_cache]
(0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(name=defaults)))]
(Thu Aug 11 12:21:43 2016) [sssd[sudo]] [sudosrv_get_sudorules_from_cache]
(0x0400): Returning 0 rules for [@internal.emerlyn.com]
(Thu Aug 11 12:21:43 2016) [sssd[sudo]] [sss_parse_name_for_domains]
(0x0200): name 'jgoddard' matched without domain, user is jgoddard
*(*Thu Aug 11 12:21:43 2016) [sssd[sudo]] [sss_parse_name_for_domains]
(0x0200): name 'jgoddard' matched without domain, user is jgoddard
(Thu Aug 11 12:21:43 2016) [sssd[sudo]] [sudosrv_cmd_parse_query_done]
(0x0200): Requesting rules for [jgoddard] from []
(Thu Aug 11 12:21:43 2016) [sssd[sudo]] [sudosrv_get_user] (0x0200):
Requesting info about [jgodd...@internal.emerlyn.com]
(Thu Aug 11 12:21:43 2016) [sssd[sudo]] [sudosrv_get_user] (0x0400):
Returning info for user [jgodd...@internal.emerlyn.com]
(Thu Aug 11 12:21:43 2016) [sssd[sudo]] [sudosrv_get_rules] (0x0400):
Retrieving rules for [jgoddard] from [internal.emerlyn.com]
(Thu Aug 11 12:21:43 2016) [sssd[sudo]] [sudosrv_get_sudorules_query_cache]
(0x0200): Searching sysdb with
[(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=jgoddard)(sudoUser=#32001)(sudoUser=%developers)(sudoUser=%jira-administrators)(sudoUser=%admins)(sudoUser=%ipausers)(sudoUser=%jgoddard)(sudoUser=+*))(&(dataExpireTimestamp<=1470932503)))]
(Thu Aug 11 12:21:43 2016) [sssd[sudo]] [sudosrv_get_sudorules_query_cache]
(0x0200): Searching sysdb with
[(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=jgoddard)(sudoUser=#32001)(sudoUser=%developers)(sudoUser=%jira-administrators)(sudoUser=%admins)(sudoUser=%ipausers)(sudoUser=%jgoddard)(sudoUser=+*)))]
(Thu Aug 11 12:21:43 2016) [sssd[sudo]] [sort_sudo_rules] (0x0400): Sorting
rules with higher-wins logic
(Thu Aug 11 12:21:43 2016) [sssd[sudo]] [sudosrv_get_sudorules_from_cache]
(0x0400): Returning 1 rules for [jgodd...@internal.emerlyn.com]
(Thu Aug 11 12:21:47 2016) [sssd[sudo]] [client_recv] (0x0200): Client
disconnected!
(Thu Aug 11 12:22:12 2016) [sssd[sudo]] [accept_fd_handler] (0x0400):
Client connected!
(Thu Aug 11 12:22:12 2016) [sssd[sudo]] [sss_cmd_get_version] (0x0200):
Received client version [1].
(Thu Aug 11 12:22:12 2016) [sssd[sudo]] [sss_cmd_get_version] (0x0200):
Offered version [1].
(Thu Aug 11 12:22:12 2016) [sssd[sudo]] [sss_parse_name_for_domains]
(0x0200): name 'jgoddard'

Re: [Freeipa-users] sudo rules question on ubuntu 16.0.1

2016-08-11 Thread Rob Crittenden 

Jeff Goddard wrote:

I've looked though these but not found anything helpful. It appears as
though my previous statement about the 1 group being found was
misleading as the sssd.$mydomain.com.log file reports that no sudo rules
are found. Does this mean that the LDAP tree being searched is different
on ubuntu vs centos?


I find that extremely unlikely.

You may want to outline more what you've already checked.

For example, is sss in sudoers in /etc/nsswitch.conf?

You can check the 389-ds access log to see what, if any queries are 
being made. I'd clean the sssd cache in advance.


rob



Jeff

On Wed, Aug 10, 2016 at 2:13 PM, Rob Crittenden > wrote:

Jeff Goddard wrote:

Sean,

Thanks for the reply. I don't think that's my problem but I'm
posting a
redacted copy of the sssd.conf file for review below.


I'd start here:
https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO


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] unable to delete a replica server

2016-08-11 Thread Rob Crittenden 

Torsten Harenberg wrote:

Hi,

we have three ipa servers

- ipa
- ipa2
- ipacentos7

We wanted to re-install ipa2 from scratch as this server gave us strange
issues in the past (for example, you have to do a "ipactl stop && ipactl
start" after boot to have everything running - a step which is not
needed on the other two).

However, the ipa-replica-manage del ipa2.pleiades.uni-wuppertal.de gave
an error at the end (it scrolled out of the terminal, but ended with
"unexpected error: Not allowed on non-leaf entry").

It seems to be impossible to get rid of this replica now:

[root@ipa ~]#  ipa-replica-manage -v -f -c  del
ipa2.pleiades.uni-wuppertal.de
Directory Manager password:

Cleaning a master is irreversible.
This should not normally be require, so use cautiously.
Continue to clean master? [no]: yes
unexpected error: Not allowed on non-leaf entry
[root@ipa ~]# ipa-replica-manage list
Directory Manager password:

ipacentos7.pleiades.uni-wuppertal.de: master
ipa.pleiades.uni-wuppertal.de: master
ipa2.pleiades.uni-wuppertal.de: master
[root@ipa ~]#

[root@ipa ~]#  ipa-csreplica-manage -v del ipa2.pleiades.uni-wuppertal.de
Directory Manager password:

Deleted replication agreement from 'ipa.pleiades.uni-wuppertal.de' to
'ipa2.pleiades.uni-wuppertal.de'
[root@ipa ~]# ipa-replica-manage list
Directory Manager password:

ipacentos7.pleiades.uni-wuppertal.de: master
ipa.pleiades.uni-wuppertal.de: master
ipa2.pleiades.uni-wuppertal.de: master
[root@ipa ~]#

Any ideas how to proceed from here?


Seems like an error that LDAP is throwing. There might be details in 
/var/log/dirsrv/slapd-REALM/{access|errors}


It sounds like when IPA tried to delete some entry it failed because 
that entry has children. The logs should help pinpoint which entry it is 
failing on.


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] A question related to ipa webui

2016-08-11 Thread Rob Crittenden 

Jan Pazdziora wrote:

On Thu, Aug 11, 2016 at 11:10:21AM +0200, bahan w wrote:


I'm using ipa 3.0.0.47.

I have an architecture where the IPA server is located on a secure zone,
not accessible from anyone.

The IPA server has 2 network interfaces :
- IP1
- IP2

In the secure zone, the IP1 network is used for the communication between
the servers.
The IP2 is used for administrators to connect to the servers inside the
secure zone.

The only way to connect to the IPA server for external users is a proxy
which allows us to connect to the IP2.

I installed the ipa-server using the IP1 network interface.
When I try to connect through proxy to the IPA webui, I use the IP2 network
interface.

My problem is the following :
I type the following URL :
https://

It redirects me to the following URL :
https:///ipa/ui

When I try https:///ipa/ui, it redirects me to https:///ipa/ui.


[...]


httpd2433 apache4u  IPv4 xx  0t0  TCP *:https (LISTEN)
httpd2434 apache4u  IPv4 xx  0t0  TCP *:https (LISTEN)
httpd   30861   root4u  IPv4 xx  0t0  TCP *:https (LISTEN)
###

Is there something I am missing in the IPA configuration for the WebUI
please ?


Perhaps

https://www.adelton.com/freeipa/freeipa-behind-proxy-with-different-name

could give some hints.

It was tested on FreeIPA 4.* -- on 3.0, you might need to tweak it
a bit but the theory and goal should be the same.



It is the mod_rewrite rules in /etc/httpd/conf.d/ipa-rewrite.conf doing 
the redirects. As Jan points out there are going to be hostname issues, 
etc that his blog should help with.


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] FreeIPA vs DogTag CA

2016-08-11 Thread Rob Crittenden 

Kamal Perera wrote:

Dear all,

Seeking your kind advices.

If the requirement is for having a scalable corporate CA only, is it
possible to get this requirement fulfilled with DogTag only, or install
FreeIPA and use the CA functionality only.


IPA limits dogtag to only those features it is interested in. This has 
been expanding recently but you still lose some functionality.


IMHO if all you want is a CA then managing IPA is overkill.


What are the functional differences and support limitations?


Functionally it depends on what version of IPA you're talking about. 
Older versions only exposed server certificates. Newer versions support 
user certifications, custom profiles and more. It is still just a subset 
of what dogtag supports.


Support from whom? The dogtag community is happy to help (they've always 
helped us).


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] ipa-replica-install fails with python import error for module ssl_match_hostname

2016-08-11 Thread Rob Crittenden 

White Hat wrote:

When attempting to run ipa-replica-install I get a python error, No
module named ssl_match_hostname


This is on a CentOS 7.2 x86_64 testing box.

All available updates including kernel installed, and system rebooted
same day. Same error before and after patching and reboot.

Let me know if you want to see the yum history log info.

- Operating system version
[root@lcars site-packages]# cat /etc/redhat-release
CentOS Linux release 7.2.1511 (Core)

[root@lcars site-packages]# uname -a
Linux lcars.internal.madisonrentals.biz 3.10.0-327.28.2.el7.x86_64 #1
SMP Wed Aug 3 11:11:39 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

- Here are the installed packages.  All were installed using yum.
[root@lcars site-packages]# yum list installed | awk '/backports|ipa-/'
ipa-admintools.x86_64  4.2.0-15.0.1.el7.centos.18  @updates
ipa-client.x86_64  4.2.0-15.0.1.el7.centos.18  @updates
ipa-python.x86_64  4.2.0-15.0.1.el7.centos.18  @updates
ipa-server.x86_64  4.2.0-15.0.1.el7.centos.18  @updates
ipa-server-dns.x86_64  4.2.0-15.0.1.el7.centos.18  @updates
python-backports.noarch1.0-6.el7   @anaconda
python-backports.x86_641.0-8.el7   installed
python-backports-ssl_match_hostname.noarch

I have the following repositories enabled:
base/7/x86_64
epel/x86_64
extras/7/x86_64
updates/7/x86_64

- Other threads on this issue suggest using pip to install
backports.ssl_match_hostname.  I still get the same error after doing
that.

[root@lcars site-packages]# pip install backports.ssl_match_hostname
Requirement already satisfied (use --upgrade to upgrade):
backports.ssl_match_hostname in /usr/lib/python2.7/site-packages

[root@lcars site-packages]# pip install --upgrade backports.ssl_match_hostname
Requirement already up-to-date: backports.ssl_match_hostname in
/usr/lib/python2.7/site-packages

- Here's the actual attempt
[root@lcars site-packages]# ipa-replica-install --setup-ca --setup-dns
--forwarder=4.2.2.1
/root/replica-info-lcars.internal.madisonrentals.biz.gpg
WARNING: conflicting time synchronization service 'chronyd' will
be disabled in favor of ntpd

Directory Manager (existing master) password:

Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

ipa.ipapython.install.cli.install_tool(Replica): ERRORNo module
named ssl_match_hostname

Even when running the suggested ipa-server-install --uninstall, I
still receive the error about the missing module.

Here's what I have in /usr/lib/python2.7/site-packages

[root@lcars site-packages]# pwd
/usr/lib/python2.7/site-packages
[root@lcars site-packages]# ls | awk '/backports.ssl/'
backports.ssl_match_hostname-3.4.0.2-py2.7.egg-info
backports.ssl_match_hostname-3.5.0.1-py2.7.egg-info

- And here are the contents of each directory.
[root@lcars site-packages]# cd
backports.ssl_match_hostname-3.4.0.2-py2.7.egg-info/

[root@lcars backports.ssl_match_hostname-3.4.0.2-py2.7.egg-info]# ls
dependency_links.txt  PKG-INFO  SOURCES.txt  top_level.txt

[root@lcars backports.ssl_match_hostname-3.4.0.2-py2.7.egg-info]# cd ..
[root@lcars site-packages]# ls
backports.ssl_match_hostname-3.5.0.1-py2.7.egg-info
dependency_links.txt  installed-files.txt  PKG-INFO  SOURCES.txt  top_level.txt

Another thread suggested that this can be caused by a missing
__init__.py file, however, creating this file in both directories
doesn't help.

A commit by Heimes may shed some light on this.
The commit is in regards to otptoken and states that:

"The otptoken plugin is the only module in FreeIPA that uses Python's ssl
module instead of NSS. The patch replaces ssl with NSSConnection. It
uses the default NSS database to lookup trust anchors. NSSConnection
uses NSS for hostname matching. The package
python-backports-ssl_match_hostname is no longer required."

The master IPA server is up and running with no issues.

An ipa connection between replica server and master reports that the
connection is working.

What else could I be missing?


Is there a more complete traceback in /var/log/ipareplica-install? I'm 
curious where the import is originating? If not instrumenting 
ipa-replica-install with pdb would be a way to find it.


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] sudo rules question on ubuntu 16.0.1

2016-08-11 Thread Jeff Goddard 
I've looked though these but not found anything helpful. It appears as
though my previous statement about the 1 group being found was misleading
as the sssd.$mydomain.com.log file reports that no sudo rules are found.
Does this mean that the LDAP tree being searched is different on ubuntu vs
centos?

Jeff

On Wed, Aug 10, 2016 at 2:13 PM, Rob Crittenden  wrote:

> Jeff Goddard wrote:
>
>> Sean,
>>
>> Thanks for the reply. I don't think that's my problem but I'm posting a
>> redacted copy of the sssd.conf file for review below.
>>
>
> I'd start here: https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO
>
> 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] Possible bug in SSSD/IPA/AD trust

2016-08-11 Thread Jakub Hrozek 
On Thu, Aug 11, 2016 at 03:11:10PM +0200, Troels Hansen wrote:
> Hi, we are curretly workig on a larger IPA test project and I have a problems 
> which have been buggin me for some time now: 

Which version?

> 
> 
> On the client we are have set "full_name_format = %1$s" to have users 
> presented without the AD domain part. 
> However, this seems to make SSSD not lookup a users group membership? 

This only works with sssd-1.14+

-- 
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] Possible bug in SSSD/IPA/AD trust

2016-08-11 Thread Troels Hansen 
Hi, we are curretly workig on a larger IPA test project and I have a problems 
which have been buggin me for some time now: 


On the client we are have set "full_name_format = %1$s" to have users presented 
without the AD domain part. 
However, this seems to make SSSD not lookup a users group membership? 

sssd.conf from server: 

[domain/linux.dr.dk] 

cache_credentials = True 
# krb5_store_password_if_offline = True 
ipa_domain = linux.dr.dk 
id_provider = ipa 
auth_provider = ipa 
access_provider = ipa 
ipa_hostname = ipa01tst.linux.dr.dk 
chpass_provider = ipa 
ipa_server = ipa01tst.linux.dr.dk 
ipa_server_mode = True 
ldap_tls_cacert = /etc/ipa/ca.crt 

# Bugfix untill RHEL 7.3 arrives 
# http://www.redhat.com/archives/freeipa-users/2016-May/msg00209.html 
ldap_user_principal = nosuchattr 

ignore_group_members = True 
ldap_purge_cache_timeout = 0 
subdomain_inherit = ldap_user_principal, ignore_group_members, 
ldap_purge_cache_timeout 

debug_level=3 

# Added to list users faster eg id j...@net.dr.dk 
ldap_use_tokengroups = True 
ldap_id_mapping = True 

[sssd] 
services = nss, sudo, pam, ssh 
config_file_version = 2 
domains = linux.dr.dk 
default_domain_suffix = NET.DR.DK 

[nss] 
memcache_timeout = 600 
homedir_substring = /home 

[pam] 
[sudo] 
[autofs] 
[ssh] 
[pac] 
[ifp] 



sssd.conf from client: 

[domain/linux.dr.dk] 

cache_credentials = True 
krb5_store_password_if_offline = True 
ipa_domain = linux.dr.dk 
id_provider = ipa 
auth_provider = ipa 
access_provider = ipa 
ipa_hostname = rhel01udv.linux.dr.dk 
chpass_provider = ipa 
ipa_server = ipa01tst.linux.dr.dk 
ldap_tls_cacert = /etc/ipa/ca.crt 

debug_level=5 

[sssd] 
services = nss, sudo, pam, ssh 
config_file_version = 2 
domains = linux.dr.dk 
default_domain_suffix = NET.DR.DK 
# full_name_format = %1$s 

[nss] 
homedir_substring = /home 

[pam] 
[sudo] 
[autofs] 
[ssh] 
[pac] 
[ifp] 


With " full_name_format " commented out on client I get the full list of groups 
for a user: 

# sss_cache -E && rm -f /var/lib/sss/db/* && systemctl restart sssd 
# getent passwd drext...@net.dr.dk 
drext...@net.dr.dk:*:1349938498:1349938498:DREXTRHA:/home/net.dr.dk/drextrha: 

# id drext...@net.dr.dk 
gives full groups list 


If I enable the " full_name_format " parameter I get: 

Clear cache. 
# sss_cache -E && rm -f /var/lib/sss/db/* && systemctl restart sssd 

#getent passwd drext...@net.dr.dk 
drextrha:*:1349938498:1349938498:DREXTRHA:/home/net.dr.dk/drextrha: 

but: 
id drext...@net.dr.dk 
uid=1349938498(drextrha) gid=1349938498(drextrha) 
groups=1349938498(drextrha),10012(ad_admins) 

only gives my primary group and a single IPA group 

Everything runnig RHEL 7.2, sssd 1.13.0-40.el7_2.12 

Am I doing something wrong? 

-- 
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] Declarative configuration options?

2016-08-11 Thread Marc Boorshtein 
> Something declarative which can be version controlled and considered a
> "source of truth" and driven from configuration management (chef,
> puppet, ansible - whatever your flavor)
>

This is generally not done with a configuration management system
because it tends to be more dynamic.  Usually you'll use an identity
management system that maintains your "authoritative source" that can
be audited against.  Depending on your needs it can have workflows for
user approvals, etc.  There are several open source identity
management solutions including OpenUnison (our -Tremolo Security- own
project - http://openunison.io) or ForgeRock's OpenIDM or OpenIAM.



> A scheme to reconcile account properties, group memberships,
> permissions, etc... I could see how this would be a slippery slope
> because of the depth of groupings/permissions/etc... but a
> version-controlled declarative user config gives a nice record for
> auditors (When did mike get an account, who granted access to him,
> when did he get access, what other access has he had over the last
> year... etc..)
>

This is the use case for an identity management system.  Something
that will let you identify who created an account, who approved it,
etc.

-- 
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] Declarative configuration options?

2016-08-11 Thread Martin Basti 



On 10.08.2016 22:52, Mike LoSapio wrote:

Something declarative which can be version controlled and considered a
"source of truth" and driven from configuration management (chef,
puppet, ansible - whatever your flavor)

A scheme to reconcile account properties, group memberships,
permissions, etc... I could see how this would be a slippery slope
because of the depth of groupings/permissions/etc... but a
version-controlled declarative user config gives a nice record for
auditors (When did mike get an account, who granted access to him,
when did he get access, what other access has he had over the last
year... etc..)

~~ Pseudo declaraion
ipa_user: mike
   uid: mlosapio
   first_name: mike
   last_name: losapio


No, we don't have this declaractive way to import data.

You can create a script using python IPA API to process JSON/YAML file 
for example.
Or this RFE maybe is what you need 
https://fedorahosted.org/freeipa/ticket/5821, but it didn't get priority.


Martin




On Wed, Aug 3, 2016 at 1:56 PM, Martin Basti  wrote:


On 01.08.2016 22:50, Mike LoSapio wrote:

Hi there,

Is there anyone out there with a good system for storing users,
groups, hosts, etc.. in some sort of version controlled repo w/ flat
files that could plug into "two-man" workflows for user-account
creation and privilege/group membership changes, etc.

There's some github projects out there to help installing FreeIPA
server and a few to get clients up and running, but nothing (that I
could find) for the on-going management of FreeIPA resources.



So in puppet world (just as an example) - I'd be looking for something
like a puppet-defined-type freeipa_user with all the attributes
required and more-importantly all the code-glue that puts it all
together...


Figured I'd ask if there if there's anything already out there before
I re-invent the wheel.


TIA,
--Mike


Hello,

sorry but I don't understand what you exactly need, can you be more
specific? Do you need a script that provision users?

Martin




--
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] unable to delete a replica server

2016-08-11 Thread Torsten Harenberg 
Some more information about that:

[root@ipa ~]# ipa-replica-manage list-ruv
Directory Manager password:

unable to decode: {replica 3} 5620bd3b00050003 5620bd3b00050003
ipacentos7.pleiades.uni-wuppertal.de:389: 9
ipa.pleiades.uni-wuppertal.de:389: 4
[root@ipa ~]# ipa-replica-manage list-clean-ruv
Directory Manager password:

No CLEANALLRUV tasks running

No abort CLEANALLRUV tasks running
[root@ipa ~]# ipa-replica-manage clean-ruv 3
Directory Manager password:

unable to decode: {replica 3} 5620bd3b00050003 5620bd3b00050003
Replica ID 3 not found
[root@ipa ~]#

Best regards

  Torsten

-- 
Dr. Torsten Harenberg harenb...@physik.uni-wuppertal.de
Bergische Universitaet
Fakultät 4 - Physik   Tel.: +49 (0)202 439-3521
Gaussstr. 20  Fax : +49 (0)202 439-2811
42097 Wuppertal

-- 
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] unable to delete a replica server

2016-08-11 Thread Torsten Harenberg 
Hi,

we have three ipa servers

- ipa
- ipa2
- ipacentos7

We wanted to re-install ipa2 from scratch as this server gave us strange
issues in the past (for example, you have to do a "ipactl stop && ipactl
start" after boot to have everything running - a step which is not
needed on the other two).

However, the ipa-replica-manage del ipa2.pleiades.uni-wuppertal.de gave
an error at the end (it scrolled out of the terminal, but ended with
"unexpected error: Not allowed on non-leaf entry").

It seems to be impossible to get rid of this replica now:

[root@ipa ~]#  ipa-replica-manage -v -f -c  del
ipa2.pleiades.uni-wuppertal.de
Directory Manager password:

Cleaning a master is irreversible.
This should not normally be require, so use cautiously.
Continue to clean master? [no]: yes
unexpected error: Not allowed on non-leaf entry
[root@ipa ~]# ipa-replica-manage list
Directory Manager password:

ipacentos7.pleiades.uni-wuppertal.de: master
ipa.pleiades.uni-wuppertal.de: master
ipa2.pleiades.uni-wuppertal.de: master
[root@ipa ~]#

[root@ipa ~]#  ipa-csreplica-manage -v del ipa2.pleiades.uni-wuppertal.de
Directory Manager password:

Deleted replication agreement from 'ipa.pleiades.uni-wuppertal.de' to
'ipa2.pleiades.uni-wuppertal.de'
[root@ipa ~]# ipa-replica-manage list
Directory Manager password:

ipacentos7.pleiades.uni-wuppertal.de: master
ipa.pleiades.uni-wuppertal.de: master
ipa2.pleiades.uni-wuppertal.de: master
[root@ipa ~]#

Any ideas how to proceed from here?

Thanks a lot

  Torsten


-- 
Dr. Torsten Harenberg harenb...@physik.uni-wuppertal.de
Bergische Universitaet
Fakultät 4 - Physik   Tel.: +49 (0)202 439-3521
Gaussstr. 20  Fax : +49 (0)202 439-2811
42097 Wuppertal

-- 
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] A question related to ipa webui

2016-08-11 Thread Jan Pazdziora 
On Thu, Aug 11, 2016 at 11:10:21AM +0200, bahan w wrote:
> 
> I'm using ipa 3.0.0.47.
> 
> I have an architecture where the IPA server is located on a secure zone,
> not accessible from anyone.
> 
> The IPA server has 2 network interfaces :
> - IP1
> - IP2
> 
> In the secure zone, the IP1 network is used for the communication between
> the servers.
> The IP2 is used for administrators to connect to the servers inside the
> secure zone.
> 
> The only way to connect to the IPA server for external users is a proxy
> which allows us to connect to the IP2.
> 
> I installed the ipa-server using the IP1 network interface.
> When I try to connect through proxy to the IPA webui, I use the IP2 network
> interface.
> 
> My problem is the following :
> I type the following URL :
> https://
> 
> It redirects me to the following URL :
> https:///ipa/ui
> 
> When I try https:///ipa/ui, it redirects me to https:///ipa/ui.

[...]

> httpd2433 apache4u  IPv4 xx  0t0  TCP *:https (LISTEN)
> httpd2434 apache4u  IPv4 xx  0t0  TCP *:https (LISTEN)
> httpd   30861   root4u  IPv4 xx  0t0  TCP *:https (LISTEN)
> ###
> 
> Is there something I am missing in the IPA configuration for the WebUI
> please ?

Perhaps

https://www.adelton.com/freeipa/freeipa-behind-proxy-with-different-name

could give some hints.

It was tested on FreeIPA 4.* -- on 3.0, you might need to tweak it
a bit but the theory and goal should be the same.

-- 
Jan Pazdziora
Senior Principal Software Engineer, Identity Management Engineering, Red Hat

-- 
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] A question related to ipa webui

2016-08-11 Thread bahan w 
Hello !

I'm using ipa 3.0.0.47.

I have an architecture where the IPA server is located on a secure zone,
not accessible from anyone.

The IPA server has 2 network interfaces :
- IP1
- IP2

In the secure zone, the IP1 network is used for the communication between
the servers.
The IP2 is used for administrators to connect to the servers inside the
secure zone.

The only way to connect to the IPA server for external users is a proxy
which allows us to connect to the IP2.

I installed the ipa-server using the IP1 network interface.
When I try to connect through proxy to the IPA webui, I use the IP2 network
interface.

My problem is the following :
I type the following URL :
https://

It redirects me to the following URL :
https:///ipa/ui

When I try https:///ipa/ui, it redirects me to https:///ipa/ui.

And unfortunately, this IP1 is not reachable from outside of the secure
zone.

When I check from the server, I can see the service is listening on all
network interfaces.
###
# lsof -i :443
COMMAND   PID   USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
httpd2427 apache4u  IPv4 xx  0t0  TCP *:https (LISTEN)
httpd2428 apache4u  IPv4 xx  0t0  TCP *:https (LISTEN)
httpd2429 apache4u  IPv4 xx  0t0  TCP *:https (LISTEN)
httpd2430 apache4u  IPv4 xx  0t0  TCP *:https (LISTEN)
httpd2431 apache4u  IPv4 xx  0t0  TCP *:https (LISTEN)
httpd2432 apache4u  IPv4 xx  0t0  TCP *:https (LISTEN)
httpd2433 apache4u  IPv4 xx  0t0  TCP *:https (LISTEN)
httpd2434 apache4u  IPv4 xx  0t0  TCP *:https (LISTEN)
httpd   30861   root4u  IPv4 xx  0t0  TCP *:https (LISTEN)
###

Is there something I am missing in the IPA configuration for the WebUI
please ?

Best regards.

Bahan
-- 
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] headless ipa client join using kerberos ticket

2016-08-11 Thread Troels Hansen 
I can see this have been discussed a lot here, but I still can't seem to find 
the correct answer, so bare with me if i'm asking a question already answered. 

I'm trying to create a user that can be used for (headless) joining out RHEL 
clients to IPA 

Here is what have been done: 
/etc/krb5.conf and /etc/ipa/ca.crt copied to the client. 

a user created on IPA: 

# ipa user-show joinipa 
User login: joinipa 
First name: Host 
Last name: Adder 
Home directory: /home/joinipa 
Login shell: /bin/sh 
Email address: join...@linux.dr.dk 
UID: 10006 
GID: 10006 
Account disabled: False 
Password: False 
Member of groups: ipausers 
Roles: joinipa 
Kerberos keys available: True 

has role joinipa 

# ipa role-show "joinipa" 
Role name: joinipa 
Member users: joinipa 
Privileges: Host Enrollment 

Host Enrollemnt provilege also has the 'System: Add Hosts' permission: 

# ipa privilege-show "Host Enrollment" 
Privilege name: Host Enrollment 
Description: Host Enrollment 
Permissions: System: Add Hosts, System: Add krbPrincipalName to a Host, System: 
Enroll a Host, System: Manage Host Certificates, 
System: Manage Host Enrollment Password, System: Manage Host Keytab 
Granting privilege to roles: joinipa 

Get the keytab from IPA server (run on IPA server): 
# ipa-getkeytab -s `hostname` -p join...@linux.dr.dk -k /tmp/joinipa.keytab 

Keytab copied to IPA client: 

kinit keytab: 
# kinit join...@linux.dr.dk -kt joinipa.keytab 

# klist 
Ticket cache: KEYRING:persistent:0:0 
Default principal: join...@linux.dr.dk 

Valid starting Expires Service principal 
08/11/2016 10:12:33 08/12/2016 10:12:33 krbtgt/linux.dr...@linux.dr.dk 

Try to join IPA server: 
# ipa-join --server ipa01tst.linux.dr.dk 
Failed to parse result: Insufficient access rights 

Retrying with pre-4.0 keytab retrieval method... 
Keytab successfully retrieved and stored in: /etc/krb5.keytab 
Certificate subject base is: O=LINUX.DR.DK 

Host gets created on IPA server, but what makes it fail? 

If I try to join again I also get told its already joined: 

# ipa-join --server ipa01tst.linux.dr.dk 
Host is already joined. 

-- 
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] Why is user status different on each master replica?

2016-08-11 Thread Petr Spacek 
On 10.8.2016 17:19, Martin Basti wrote:
> 
> 
> On 09.08.2016 23:04, Larry Rosen wrote:
>>
>> This user was locked out due to Max Failure policy = 5
>>
>> If they’re supposed to be replicas, why the different status?
>>
>> [root@il10 ~]# ipa user-status  lramey
>>
>> ---
>>
>> Account disabled: False
>>
>> ---
>>
>>   Server: ipa-idm-01.ipajdr.local
>>
>>   Failed logins: 0
>>
>>   Last successful authentication: 20160808191857Z
>>
>>   Last failed authentication: 20160808191848Z
>>
>>   Time now: 2016-08-09T19:57:20Z
>>
>>   Server: ipa-idm-02.ipajdr.local
>>
>>   Failed logins: 5
>>
>>   Last successful authentication: 20160809151406Z
>>
>>   Last failed authentication: 20160809194741Z
>>
>>   Time now: 2016-08-09T19:57:21Z
>>
>> 
>>
>> Number of entries returned 2
>>
>>
>>
> Hi,
> 
> This is not replicated, because it may cause replication storms. So this
> status is local on each replica

Let me add that you can configure LDAP server to replicate this information:
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication.html#Fractional_Replication

Of course, you will have to accept the performance penalty and higher risk of
replication conflicts.

-- 
Petr^2 Spacek

-- 
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] key+OTP to SSH into publicly exposed redHat instances

2016-08-11 Thread Alexander Bokovoy 

On Thu, 11 Aug 2016, Deepak Dimri wrote:

Hi All,
I want to protect my publicly exposed AWS EC2 instances with SSH key
and OTP. I have my freeIPA v4 all up and running. I am able to SSH in
to my IPA clients with my private key however i want to include OTP
into this login process. I have enabled OTP for one test user in my
FreeIPA and i am able to login with password+OTP using browser admin
URL BUT how do i challenge the same user for OTP when trying to SSH
login into RedHat?  I have tried adding this in my freeIPA server
/etc/ssh/sshd_config but no luck - do not get challenged for OTP when
using SSH.

man sshd_config -> AuthenticationMethods.

--
/ Alexander Bokovoy

--
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] key+OTP to SSH into publicly exposed redHat instances

2016-08-11 Thread Deepak Dimri 
Hi All,
I want to protect my publicly exposed AWS EC2 instances with SSH key and OTP. I 
have my freeIPA v4 all up and running. I am able to SSH in to my IPA clients 
with my private key however i want to include OTP into this login process. I 
have enabled OTP for one test user in my FreeIPA and i am able to login with 
password+OTP using browser admin URL BUT how do i challenge the same user for 
OTP when trying to SSH login into RedHat?
I have tried adding this in my freeIPA server /etc/ssh/sshd_config but no luck 
- do not get challenged for OTP when using SSH.








ChallengeResponseAuthentication yes
UsePAM yes
AuthenticationMethods publickey,keyboard-interactive
PasswordAuthentication no
Thanks in Advance,Deepak  -- 
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