Re: [Freeipa-users] Oracle Linux 5.5 - Legacy Question

2015-11-23 Thread Jakub Hrozek 
On Sat, Nov 21, 2015 at 02:21:52AM +, Jeffrey Stormshak wrote:
> Rob -
> Here’s the test configurations/data when I manipulate the BINDDN/BINDPW 
> fields to get get both AUTH and SUDO to work in Linux 5.5.  I have three 
> questions below that I would like to get your comments on or see what you may 
> recommend on this.  I’m seriously perplexed on this as to why its working 
> this way …  Please advise.  Thanks!
> 
> **
> AUTH successful on login; SUDO fails with the message listed
> below !!
> **
> [mjsmith@chi-infra-idm-client2 ~]$ sudo -l
> sudo: ldap_sasl_bind_s(): Server is unwilling to perform

Looks like the bind didn't finish successfully, can you look into
debugging sudo itself? The debugging changed a bit between releases, but
The sudo documentation would tell you..

> [sudo] password for mjsmith:
> Sorry, user mjsmith may not run sudo on chi-infra-idm-client2.
> *
> 
> *
> # grep -iv ‘#’ /etc/ldap.conf
> *
> base dc=linuxcccis,dc=com
> uri ldap://chi-infra-idm-p1.linuxcccis.com/
> binddn uid=admin,cn=users,cn=compat,dc=linuxcccis,dc=com
> bindpw secret_pass
> timelimit 15
> bind_timelimit 5
> idle_timelimit 3600
> nss_initgroups_ignoreusers 
> root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm
> pam_password md5
> sudoers_base ou=SUDOers,dc=linuxcccis,dc=com
> 
> *
> User Account AUTH and SUDO works when
> commenting both the binddn and bindpw fields !!
> *
> vi /etc/ldap.conf … Comment these two fields …
> #binddn uid=admin,cn=users,cn=compat,dc=linuxcccis,dc=com
> #bindpw secret_pass
> 
> 
> This file unchanged during the above testing !!
> 
> /etc/sudo-ldap.conf:
> binddn uid=sudo,cn=sysaccounts,cn=etc,dc=linuxcccis,dc=com
> bindpw secret_pass
> ssl start_tls
> tls_cacertfile /etc/ipa/ca.crt
> tls_checkpeer yes
> bind_timelimit 5
> timelimit 15
> uri ldap://chi-infra-idm-p1.linuxcccis.com
> sudoers_base ou=SUDOers,dc=linuxcccis,dc=com
> 
> QUESTIONS:
> 1) What BINDN account needs to be specified to allow the BINDDN/BINDPW to 
> work for SUDO?
> 2) Why does the AUTH work when setting values in the BINDDN/BINDPW, but SUDO 
> then fails?
> 3) If I leave BINDDN/BINDPW blank, what security risks are being introduced 
> by leaving it that way?

Anyone on the network can read sudo rules. I guess in theory, the
attacker might target accounts who are allowed to run sudo rules as a
gateway for getting elevated privileges on the machine..

-- 
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] service account for ovirt

2015-11-23 Thread Martin Kosek 
On 11/20/2015 08:16 PM, Rob Verduijn wrote:
> Hello,
> 
> I've tested the solution you suggested it doesnt work
> I think ovirt-engine looks for the other users in the same context as
> the bind user, it will ofcourse find not many there,

Ah, I see. oVirt apparently expects the users to be only in the users container
and not in the system user container. I am thinking this might be something
that can be improved, as it would be much easier to do with system user, on the
first look.

> I can't get the seconf option with the keytab to work.
> So I'm stuck with the full blown user account for this.

Can you show some error log, why ipa-getkeytab on a service failed? It should
just work, if you add appropriate service with service-add and then ask for the
keytab with power account.

> Here's what I did :
> 
> The ovirt os is centos 6 x86_64
> All the latest patches have been applied.
> It can be a member of the freeipa domain but this is not required for
> the ovirt-freeipa authentication to work.
> personally I think its nice to have the ovirt machine under freeipa
> supervision as wel.
> 
> the freeipa os is centos7 x*6_64
> All the latest patches have been applied.
> 
> The ovirt environment is configured, up and running.
> 
> There are two ways of single sign on for ovirt.
> see 
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.5/html/Administration_Guide/sect-Directory_Users.html
> 
> This howto is for the first option
> you require a search account in the freeipa domain.
> add a user account to the freeipa domain
> login with that account so it asks you to set a new password for it
> then reset the experation date for the password to somewhere in the
> far future with the procedure below
> 
> #
> # Add the search account for ovirt to the freeipa domain.
> #
> # executed these commands on the freeipa server as root.
> #
> 
> # first set the variables
> export SUFFIX='dc=example,dc=com'
> export OVIRT_SERVER=ovirt.example.com
> export FREEIPA_DOMAIN=EXAMPLE.COM
> export USERNAME=ovirt
> export YOUR_PASSWORD='top_secret_random_very_long_password'
> 
> # create an ldif file
> cat > resetexperation.ldif << EOF
> dn: uid=$USERNAME,cn=users,cn=accounts,$SUFFIX
> changetype: modify
> replace: krbpasswordexpiration
> krbpasswordexpiration: 20380119031407Z
> EOF
> 
> # apply the ldif file
> # the password requested is the directory admin password, this is NOT
> the same account as the freeipa admin
> ldapmodify -x -D "cn=directory manager" -W -vv -f resetexperation.ldif
> 
> # for the second option also :
> # add the service for http to freeipa
> kinit admin
> ipa service-add HTTP/$OVIRT_SERVER@$FREEIPA_DOMAIN
> 
> #
> # The following commands are executed as root on the ovirt-engine machine.
> # This is the example that allows single sign on from the portal to the vm's
> # Assuming the forementioned bindaccount exists in the freeipa domain
> #
> 
> #
> # first install the required package :
> #
> 
> yum install -y ovirt-engine-extension-aaa-ldap
> 
> #
> # create the ovirt configuration files
> # examples can be found here :
> # /usr/share/ovirt-engine-extension-aaa-ldap/examples/simple/.
> #
> 
> mkdir /etc/ovirt-engine/aaa
> mkdir /etc/ovirt-engine/extenstions.d
> 
> #
> # set the vars again ( exports do not work between vm's)
> #
> 
> export SUFFIX='dc=example,dc=com'
> export YOUR_PASSWORD='top_secret_random_very_long_password'
> export FREEIPA_SERVER=freeipa.example.com
> export PROFILE_NAME=profile1
> 
> #
> # create the config files
> #
> cat > /etc/ovirt-engine/aaa/$PROFILE_NAME.properties << EOF
> include = 
> vars.server = $FREEIPA_SERVER
> vars.user = uid=ovirt,cn=users,cn=accounts,$SUFFIX
> vars.password = $YOUR_PASSWORD
> pool.default.serverset.single.server = \${global:vars.server}
> pool.default.auth.simple.bindDN = \${global:vars.user}
> pool.default.auth.simple.password = \${global:vars.password}
> EOF
> 
> cat > /etc/ovirt-engine/extensions.d/$PROFILE_NAME-authz.properties << EOF
> ovirt.engine.extension.name = $PROFILE_NAME-authz
> ovirt.engine.extension.bindings.method = jbossmodule
> ovirt.engine.extension.binding.jbossmodule.module =
> org.ovirt.engine-extensions.aaa.ldap
> ovirt.engine.extension.binding.jbossmodule.class =
> org.ovirt.engineextensions.aaa.ldap.AuthzExtension
> ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Authz
> config.profile.file.1 = ../aaa/$PROFILE_NAME.properties
> EOF
> 
> cat > /etc/ovirt-engine/extensions.d/$PROFILE_NAME-authn.properties << EOF
> ovirt.engine.extension.name = $PROFILE_NAME-authn
> ovirt.engine.extension.bindings.method = jbossmodule
> ovirt.engine.extension.binding.jbossmodule.module =
> org.ovirt.engine-extensions.aaa.ldap
> ovirt.engine.extension.binding.jbossmodule.class =
> org.ovirt.engineextensions.aaa.ldap.AuthnExtension
> ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Authn
> ovirt.engine.aaa.authn.profile.name = $PROFILE_NAME
>

[Freeipa-users] Unspecified GSS failure. No credentials cache found

2015-11-23 Thread Roberto Cornacchia 
Hi there,

Although I can't see anything failing, the logs of all clients in my IPA
domain (FC22, freeipa 4.1.4) contain lots of these failures every day:

nov 23 10:43:34 hadron.hq.example.com gssproxy[742]: (OID: { 1 2 840 113554
1 2 2 }) Unspecified GSS failure.  Minor code may provide more information,
No credentials cache found


Do you have suggestions on how to find out what the problem might be?
Or is this something I should not worry about?

Thanks, Roberto
-- 
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] web ui runtime error

2015-11-23 Thread Petr Vobornik 

On 11/23/2015 04:44 AM, Orion Poplawski wrote:

Trying to install freeipa-server on Fedora 23.  When I try to connect to
the web UI from a non-domain EL7 client with firefox I get:


Runtime error

Web UI got in unrecoverable state during "init" phase
Technical details:
The operation is insecure.


Does the browser trust IPA CA?

If you open Firefox developer tools (usually F12 key). In "network 
monitor" after page refresh which(if any) network requests have status 
other than "200 success" - first column?




.cache["freeipa/app_container"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:426

.cache["dojo/_base/lang"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:26298

.cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:3162

.cache["dojo/_base/array"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:29751

.cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:3126

.cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:3588

.cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:3325

.cache["dojo/_base/lang"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:26298

.cache["dojo/Deferred"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:60959

.cache["dojo/Deferred"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:62245

.cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:3234

.cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:3588

.cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:3325

.cache["dojo/_base/lang"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:26298

.cache["dojo/Deferred"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:60959

.cache["dojo/Deferred"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:62245

.cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:3234

.cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:3588

.cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:3325

.cache["dojo/_base/lang"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:26298

.cache["dojo/Deferred"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:60959

.cache["dojo/Deferred"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:62245

.cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:3234

.cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:3588

.cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:2938

.cache["freeipa/app_container"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:1410

.cache["dojo/_base/lang"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:26298

.cache["dojo/Deferred"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:60959

.cache["dojo/Deferred"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:60885

.cache["dojo/Deferred"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:61872

.cache["freeipa/plugin_loader"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:2165

.cache["dojo/Deferred"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:60959

.cache["dojo/Deferred"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:62245

.cache["freeipa/plugin_loader"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:2143

.cache["dojo/_base/lang"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:26298

Vt@https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:7726
Zt@https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:8899
nn/<@https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:9085
tn@https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:8961
nn@https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:9025
ln/i@https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:10123
p.injectUrl/i@https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:12306



Do I have to do something to enable username/password auth for this
version of IPA?




--
Petr Vobornik

--
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] FreeIPA en Domain Trust

2015-11-23 Thread Winfried de Heiden 

  
  
Hi all,
  
  For some reason, we only want to use the Active Directory user
  from an Active Directory using a Trust. (groups like "Domain
  Users"  are of no use...)
  
  Is it possible to ignore (hide) ALL groups from a particular
  Domain (trust)/
  
  Kinds Regards,
  
  Winny

  


-- 
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] connection problems after reboot with unusual setting (Ubuntu 14.04 + freeipa docker)

2015-11-23 Thread Martin Babinsky 

On 11/20/2015 04:44 PM, Karl Forner wrote:

Hello,

My server runs ubuntu 14.04 and uses sssd 1.12.5-1~trusty1.
The freeipa server runs inside a docker (an adelton/freeipa-server), and
the docker host pretends to be the freeIPA server by forwarding the
appropriate ports.

This works very fine.
But when I reboot my server (which is in a locked server room. r), I
struggle to connect to it.

I'm unable to connect using ssh onto it, using any kind of local or
freeIPA accounts onto it.
The DNS server (provided by freeIPA) works kine though (i.e. nslookup
server server works).

Fortunately, I have the monit web app running on the server that allows
to restart the ssh service.

After restarting ssh remotely. I am now able to connect to the server.
It seems that all works fine again once I restart sssd on the server.

I know this is a pretty complex setup, but do you have hints that could
help me have a usable server after reboot ?

Thanks,
Karl Forner





We will need some more information to help you out. Is the ssh daemon 
running right after the reboot? Is there anything in sshd logs? We may 
also need sssd logs, see https://fedorahosted.org/sssd/wiki/Troubleshooting.


--
Martin^3 Babinsky

--
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] connection problems after reboot with unusual setting (Ubuntu 14.04 + freeipa docker)

2015-11-23 Thread Jan Pazdziora 
On Fri, Nov 20, 2015 at 04:44:38PM +0100, Karl Forner wrote:
> 
> My server runs ubuntu 14.04 and uses sssd 1.12.5-1~trusty1.
> The freeipa server runs inside a docker (an adelton/freeipa-server), and
> the docker host pretends to be the freeIPA server by forwarding the
> appropriate ports.

Is the Docker host the same machine that runs that sssd
1.12.5-1~trusty1 and that you try to ssh to?

Assuming it's the same machine, when you IPA-enrolled the host
machine, was Docker container's internal (172.*) IP address used or
the public interface of the host?

> I'm unable to connect using ssh onto it, using any kind of local or freeIPA
> accounts onto it.

What does ssh -v root@the-host say? Do you fail to connect or do you
fail to authenticate? How do you try to authenticate -- Kerberos ticket
(kinit on client) or using password on sshd prompt?

> The DNS server (provided by freeIPA) works kine though (i.e. nslookup
> server server works).

And does it return the correct IP address, the public address of the
host?

> Fortunately, I have the monit web app running on the server that allows to
> restart the ssh service.
> 
> After restarting ssh remotely. I am now able to connect to the server.
> It seems that all works fine again once I restart sssd on the server.

Do you restart the sshd service, sssd service, or both?

-- 
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

Re: [Freeipa-users] web ui runtime error

2015-11-23 Thread Orion Poplawski 

On 11/23/2015 04:50 AM, Petr Vobornik wrote:

On 11/23/2015 04:44 AM, Orion Poplawski wrote:

Trying to install freeipa-server on Fedora 23.  When I try to connect to
the web UI from a non-domain EL7 client with firefox I get:


Runtime error

Web UI got in unrecoverable state during "init" phase
Technical details:
The operation is insecure.


Does the browser trust IPA CA?


I believe I've now imported the CA, but no difference.


If you open Firefox developer tools (usually F12 key). In "network
monitor" after page refresh which(if any) network requests have status
other than "200 success" - first column?


Everything is 200 or 304 (not modified)





.cache["freeipa/app_container"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:426


.cache["dojo/_base/lang"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:26298


.cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:3162


.cache["dojo/_base/array"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:29751


.cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:3126


.cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:3588


.cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:3325


.cache["dojo/_base/lang"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:26298


.cache["dojo/Deferred"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:60959


.cache["dojo/Deferred"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:62245


.cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:3234


.cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:3588


.cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:3325


.cache["dojo/_base/lang"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:26298


.cache["dojo/Deferred"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:60959


.cache["dojo/Deferred"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:62245


.cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:3234


.cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:3588


.cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:3325


.cache["dojo/_base/lang"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:26298


.cache["dojo/Deferred"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:60959


.cache["dojo/Deferred"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:62245


.cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:3234


.cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:3588


.cache["freeipa/_base/Phase_controller"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:2938


.cache["freeipa/app_container"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:1410


.cache["dojo/_base/lang"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:26298


.cache["dojo/Deferred"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:60959


.cache["dojo/Deferred"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:60885


.cache["dojo/Deferred"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:61872


.cache["freeipa/plugin_loader"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:2165


.cache["dojo/Deferred"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:60959


.cache["dojo/Deferred"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:62245


.cache["freeipa/plugin_loader"]/https://moria.menegroth.us/ipa/ui/js/freeipa/app.js?40203:1:2143


.cache["dojo/_base/lang"]/https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:26298


Vt@https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:7726
Zt@https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:8899
nn/<@https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:9085
tn@https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:8961
nn@https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:9025
ln/i@https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:10123
p.injectUrl/i@https://moria.menegroth.us/ipa/ui/js/dojo/dojo.js?v=40203:1:12306




Do I have to do something to enable username/password auth for this
version of IPA?







--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com

--
Manage your subscription for

Re: [Freeipa-users] Oracle Linux 5.5 - Legacy Question

2015-11-23 Thread Jeffrey Stormshak 
Jakub/Rob -
Thanks for the feedback.  I was finally able to ditch the ‘binddn’ and was able 
to get SSL working upon upgrading the OpenSSL from the 5.5 base to the one 
supplied in 5.7 base. The SSL is fully authenticating and with sudo access.  
However, I’m riddled by the following item below.  I’m hoping that 
someone/somewhere encountered this issue and was able to resolve it using this 
legacy 5.5.  See details provided below.  All thoughts/suggestions are truly 
appreciated !!

$ id -a
uid=140321(pmoss) gid=7000(sysadmin) groups=7000(sysadmin)

$ passwd
Changing password for user pmoss.
Enter login(LDAP) password:
New UNIX password:
Retype new UNIX password:

LDAP password information update failed: Insufficient access
Insufficient 'write' privilege to the 'userPassword' attribute of entry 
'uid=pmoss,cn=users,cn=compat,dc=linuxcccis,dc=com'.


passwd: Permission denied

# ipa user-show pmoss --all --rights | grep -i userpass  ->  
attributelevelrights: {u'userpassword': u'swo’, …

pmoss shows u'userpassword': u'swo'
‘swo’ translates to ‘search,write,delete’

Why wouldn’t the above be enough rights to be able to change ‘pmoss’ personal 
password?  Thoughts ?

Jeffrey Stormshak, RHCSA | Sr. Linux Engineer
Platform Systems | IT Operations Infrastructure
CCC Information Services, Inc.
Phone: (312) 229-2552

From: Jakub Hrozek >
Date: Monday, November 23, 2015 at 1:58 AM
To: Jeffrey Stormshak >
Cc: Rob Crittenden >, 
"freeipa-users@redhat.com" 
>
Subject: Re: [Freeipa-users] Oracle Linux 5.5 - Legacy Question

On Sat, Nov 21, 2015 at 02:21:52AM +, Jeffrey Stormshak wrote:
Rob -
Here’s the test configurations/data when I manipulate the BINDDN/BINDPW fields 
to get get both AUTH and SUDO to work in Linux 5.5.  I have three questions 
below that I would like to get your comments on or see what you may recommend 
on this.  I’m seriously perplexed on this as to why its working this way …  
Please advise.  Thanks!
**
AUTH successful on login; SUDO fails with the message listed
below !!
**
[mjsmith@chi-infra-idm-client2 ~]$ sudo -l
sudo: ldap_sasl_bind_s(): Server is unwilling to perform

Looks like the bind didn't finish successfully, can you look into
debugging sudo itself? The debugging changed a bit between releases, but
The sudo documentation would tell you..

[sudo] password for mjsmith:
Sorry, user mjsmith may not run sudo on chi-infra-idm-client2.
*
*
# grep -iv ‘#’ /etc/ldap.conf
*
base dc=linuxcccis,dc=com
uri ldap://chi-infra-idm-p1.linuxcccis.com/
binddn uid=admin,cn=users,cn=compat,dc=linuxcccis,dc=com
bindpw secret_pass
timelimit 15
bind_timelimit 5
idle_timelimit 3600
nss_initgroups_ignoreusers 
root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm
pam_password md5
sudoers_base ou=SUDOers,dc=linuxcccis,dc=com
*
User Account AUTH and SUDO works when
commenting both the binddn and bindpw fields !!
*
vi /etc/ldap.conf … Comment these two fields …
#binddn uid=admin,cn=users,cn=compat,dc=linuxcccis,dc=com
#bindpw secret_pass

This file unchanged during the above testing !!

/etc/sudo-ldap.conf:
binddn uid=sudo,cn=sysaccounts,cn=etc,dc=linuxcccis,dc=com
bindpw secret_pass
ssl start_tls
tls_cacertfile /etc/ipa/ca.crt
tls_checkpeer yes
bind_timelimit 5
timelimit 15
uri ldap://chi-infra-idm-p1.linuxcccis.com
sudoers_base ou=SUDOers,dc=linuxcccis,dc=com
QUESTIONS:
1) What BINDN account needs to be specified to allow the BINDDN/BINDPW to work 
for SUDO?
2) Why does the AUTH work when setting values in the BINDDN/BINDPW, but SUDO 
then fails?
3) If I leave BINDDN/BINDPW blank, what security risks are being introduced by 
leaving it that way?

Anyone on the network can read sudo rules. I guess in theory, the
attacker might target accounts who are allowed to run sudo rules as a
gateway for getting elevated privileges on the machine..

-- 
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] Oracle Linux 5.5 - Legacy Question

2015-11-23 Thread Rob Crittenden 
Jeffrey Stormshak wrote:
> Jakub/Rob -
> Thanks for the feedback.  I was finally able to ditch the ‘binddn’ and
> was able to get SSL working upon upgrading the OpenSSL from the 5.5 base
> to the one supplied in 5.7 base. The SSL is fully authenticating and
> with sudo access.  However, I’m riddled by the following item below.
>  I’m hoping that someone/somewhere encountered this issue and was able
> to resolve it using this legacy 5.5.  See details provided below.  All
> thoughts/suggestions are truly appreciated !!
> 
> *
> *
> 
> $ id -a
> 
> uid=140321(pmoss) gid=7000(sysadmin) groups=7000(sysadmin)
> 
>  
> 
> $ passwd
> 
> Changing password for user pmoss.
> 
> Enter login(LDAP) password:
> 
> New UNIX password:
> 
> Retype new UNIX password:
> 
>  
> 
> LDAP password information update failed: Insufficient access
> 
> Insufficient 'write' privilege to the 'userPassword' attribute of entry
> 'uid=pmoss,cn=users,cn=compat,dc=linuxcccis,dc=com'.
> 
> 

> 
> passwd: Permission denied
> 
> *
> *
> 
> # ipa user-show pmoss --all --rights | grep -i userpass  -> 
> attributelevelrights: {u'userpassword': u'swo’, …
> 
> 
> pmoss shows *u'userpassword': u'swo'* 
> 
> ‘swo’ translates to ‘search,write,delete’
> 
> 
> Why wouldn’t the above be enough rights to be able to change ‘pmoss’
> personal password?  Thoughts ?

Because it is a different part of the tree.

Did you use ipa-advise to get the configuration? If so which profile?

It looks like that recommends using the compat tree.  It's been forever
since I've manually configured a RHEL 5 system so I don't know if that
is correct or not.

I'm pretty sure that nss_ldap supports RFC2307bis but it's really just a
distant memory.

rob

> *Jeffrey Stormshak, RHCSA | Sr. Linux Engineer*
> 
> Platform Systems | IT Operations Infrastructure
> 
> CCC Information Services, Inc.
> 
> Phone: (312) 229-2552
> 
> 
> From: Jakub Hrozek >
> Date: Monday, November 23, 2015 at 1:58 AM
> To: Jeffrey Stormshak >
> Cc: Rob Crittenden >,
> "freeipa-users@redhat.com "
> >
> Subject: Re: [Freeipa-users] Oracle Linux 5.5 - Legacy Question
> 
> On Sat, Nov 21, 2015 at 02:21:52AM +, Jeffrey Stormshak wrote:
> 
> Rob -
> Here’s the test configurations/data when I manipulate the
> BINDDN/BINDPW fields to get get both AUTH and SUDO to work in Linux
> 5.5.  I have three questions below that I would like to get your
> comments on or see what you may recommend on this.  I’m seriously
> perplexed on this as to why its working this way …  Please
> advise.  Thanks!
> **
> AUTH successful on login; SUDO fails with the message listed
> below !!
> **
> [mjsmith@chi-infra-idm-client2 ~]$ sudo -l
> sudo: ldap_sasl_bind_s(): Server is unwilling to perform
> 
> 
> Looks like the bind didn't finish successfully, can you look into
> debugging sudo itself? The debugging changed a bit between releases, but
> The sudo documentation would tell you..
> 
> [sudo] password for mjsmith:
> Sorry, user mjsmith may not run sudo on chi-infra-idm-client2.
> *
> *
> # grep -iv ‘#’ /etc/ldap.conf
> *
> base dc=linuxcccis,dc=com
> uri ldap://chi-infra-idm-p1.linuxcccis.com/
> binddn uid=admin,cn=users,cn=compat,dc=linuxcccis,dc=com
> bindpw secret_pass
> timelimit 15
> bind_timelimit 5
> idle_timelimit 3600
> nss_initgroups_ignoreusers
> 
> root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm
> pam_password md5
> sudoers_base ou=SUDOers,dc=linuxcccis,dc=com
> *
> User Account AUTH and SUDO works when
> commenting both the binddn and bindpw fields !!
> *
> vi /etc/ldap.conf … Comment these two fields …
> #binddn uid=admin,cn=users,cn=compat,dc=linuxcccis,dc=com
> #bindpw secret_pass
> 
> This file unchanged during the above testing !!
> 
> /etc/sudo-ldap.conf:
> binddn uid=sudo,cn=sysaccounts,cn=etc,dc=linuxcccis,dc=com
> bindpw secret_pass
> ssl start_tls
> tls_cacertfile /etc/ipa/ca.crt
> tls_checkpeer yes
> bind_timelimit 5
> timelimit 15
> uri ldap://chi-infra-idm-p1.linuxcccis.com
> sudoers_base ou=SUDOers,dc=linuxcccis,dc=com
> QUESTIONS:
> 1) What BINDN account needs to be

Re: [Freeipa-users] Active Directory Integration and limitations

2015-11-23 Thread Simo Sorce 
On Wed, 2015-11-18 at 11:46 +0100, Domineaux Philippe wrote:
> Here is my environment :
> 
> 1 Windows Domain
> Windows workstations
> Windows servers
> Multiple linux domains
> Linux workstations
> Linux servers
> 
> Here is my goal :
> 
> All users are centralized in the Active Directory.
> Users will authenticate on linux workstations with their AD accounts (
> using POSIX attributes).
> Linux workstations must have access to NFS shares on Linux servers.

Hi Domineaux,
you should look into setting up FreeIPA with a trust relationship to the
Windows Domain.

> What are the limitations ?

It is hard to say what kind of limitations you are interested into, when
we trust AD, then AD users can access Linux machines, one limitation (if
you think it is a limitation) is that AD users will have fully qualified
names on the host (example: u...@ad.example.com) and not just flat names
to avoid name clashes between ipa users, local users and AD users.

> Windows users equals ipa users in term of services ?

Yes.

> Do I have to configure kerberos to also join directly the Windows Kerberos
> Realm,
> or will IPA do the job to ask Windows server ?

If you set up a trust between servers all is taken care of for you wrt
clients.

> in etc/krb5.conf :
> 
> includedir /var/lib/sss/pubconf/krb5.include.d/
> 
> [libdefaults]
>   default_realm = IPA.ORG
>   dns_lookup_realm = true
>   dns_lookup_kdc = true
>   rdns = false
>   ticket_lifetime = 24h
>   forwardable = yes
>   udp_preference_limit = 0
>   default_ccache_name = KEYRING:persistent:%{uid}
>   canonicalize = yes
>   allow_weak_crypto = true
> 
> [realms]
>   IPA.ORG = {
> pkinit_anchors = FILE:/etc/ipa/ca.crt
> auth_to_local = RULE:[1:$1@
> $0](^.*@WINDOMAIN.LOCAL$)s/@WINDOMAIN.LOCAL/@windomain.local/
> auth_to_local = DEFAULT
> 
>   }
> 
> ### IS THIS NECESSARY
> WINDOMAIN.LOCAL = {
>kdc = srvadipa.windomain.local
>admin_server = srvadipa.windomain.local
> }
> 
> 
> [domain_realm]
>   .cosmo.org = COSMO.ORG
>   cosmo.org = COSMO.ORG
> 
> ### IS THIS NECESSARY
> 
>   .windomain.local = WINDOMAIN.LOCAL
>   windomain.local = WINDOMAIN.LOCAL

It depends on what client you are using, older RHEL may need this, newer
ones have an include directory in krb5.conf and sssd generates
appropriate configuration automatically based on server configuration.

> Is the bug in libnfsidmap still active and prevents Windows users to access
> to NFS4 krb5 secured shared folder ?

I am not sure what bug you refer to. You may need to configure nfs
client nfs idmap, but I am not aware of bugs that will prevent it from
working right if properly configured.

Specifically you may want to *not* try to consult LDAP from idmap, but
use a regex to transform the windows realm from upper case to lowercase
and then just use the getpwnam interface.

Simo.

> I currently have
> 
> bug here:
> https://www.redhat.com/archives/freeipa-users/2014-June/msg00163.html
> -- 
> 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


-- 
Simo Sorce * Red Hat, Inc * New York

-- 
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] hbac service allowed despite not listed

2015-11-23 Thread Winfried de Heiden 

  
  
Hi all,
  
  I created some hbac rule on freeipa-server 4.1.4 on Fedora 22
  
  # ipa hbacrule-show testuser
    Rule name: testuser
    Enabled: TRUE
    Users: testuser
    Hosts: fedora23-server.blabla.bla
    Services: sshd
  
  Hence, " testuser"  is only allowed using sshd on
  "fedora23-server". No surprise, this user is not allowed to use
  "su":
  
  # ipa hbactest --user testuser --host fedora23-server.blabla.bla
  --service su
  -
  Access granted: False
  
  (and yeah sshd is allowed)
  
  However, doing a "su"  on the fedora23-server.blabla.bla, and giving the
correct password, access is granted. This user is not a member
of any other groups.
HBAC Services like cron or console access are denied correctly
since they are not in the HBAC service list.

I noticed this behaviour also on IPA 4.1 (The Red Hat one) and
several other ipa-clients (RHEL/CentoOS 6.x, 7.x)

Shouldn't su or su -l be denied when not listed?

Kind regards,

Winny

   
  


-- 
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] "ASN.1 structure is missing a required field" - what is missing?

2015-11-23 Thread Simo Sorce 
On Tue, 2015-11-17 at 21:36 -0500, Marc Boorshtein wrote:
> I'm putting together a java kerberos client and am having an issue
> getting a SGT form IPA.  I get a TGT without issue, but when I submit
> the TGS-REQ I get the following errors in the ipa log:
> 
> Nov 17 20:53:15 freeipa.rhelent.lan krb5kdc[7507](info): AS_REQ (1
> etypes {17}) 192.168.2.129: ISSUE: authtime 1447811595, etypes {rep=17
> tkt=18 ses=17}, HTTP/s4u.rhelent@rhelent.lan for
> krbtgt/rhelent@rhelent.lan
> 
> Nov 17 20:53:15 freeipa.rhelent.lan krb5kdc[7507](info): TGS_REQ (1
> etypes {17}) 192.168.2.129: PROCESS_TGS: authtime 0,  
> for HTTP/ipa.rhelent@rhelent.lan, ASN.1 structure is missing a
> required field
> 
> Here's the TGS request:
> 
> Kerberos
> tgs-req
> pvno: 5
> msg-type: krb-tgs-req (12)
> padata: 1 item
> PA-DATA PA-TGS-REQ
> padata-type: kRB5-PADATA-TGS-REQ (1)
> padata-value:
> 6e8201f8308201f4a003020105a10302010ea2070305...
> ap-req
> pvno: 5
> msg-type: krb-ap-req (14)
> Padding: 0
> ap-options: 
> 0...  = reserved: False
> .0..  = use-session-key: False
> ..0.  = mutual-required: False
> ticket
> tkt-vno: 5
> realm: RHELENT.LAN
> sname
> name-type: kRB5-NT-PRINCIPAL (1)
> name-string: 2 items
> KerberosString: krbtgt
> KerberosString: RHELENT.LAN
> enc-part
> etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
> kvno: 1
> cipher:
> 0efd7452dafeb94323bcf7f6adc373aab78ce179f42c4c11...
> authenticator
> etype: eTYPE-AES128-CTS-HMAC-SHA1-96 (17)
> kvno: 255
> cipher:
> f40e91b920c6ae6bdc30a69d5f348bf106355a92da74ba74...
> req-body
> Padding: 0
> kdc-options: 
> 0...  = reserved: False
> .0..  = forwardable: False
> ..0.  = forwarded: False
> ...0  = proxiable: False
>  0... = proxy: False
>  .0.. = allow-postdate: False
>  ..0. = postdated: False
>  ...0 = unused7: False
> 0...  = renewable: False
> .0..  = unused9: False
> ..0.  = unused10: False
> ...0  = opt-hardware-auth: False
>  ..0. = request-anonymous: False
>  ...0 = canonicalize: False
> 0...  = constrained-delegation: False
> ..0.  = disable-transited-check: False
> ...0  = renewable-ok: False
>  0... = enc-tkt-in-skey: False
>  ..0. = renew: False
>  ...0 = validate: False
> cname
> name-type: kRB5-NT-PRINCIPAL (1)
> name-string: 2 items
> KerberosString: HTTP
> KerberosString: s4u.rhelent.lan
> realm: RHELENT.LAN
> sname
> name-type: kRB5-NT-PRINCIPAL (1)
> name-string: 2 items
> KerberosString: HTTP
> KerberosString: ipa.rhelent.lan
> from: 2015-11-18 02:17:44 (UTC)
> till: 2015-11-18 10:17:44 (UTC)
> nonce: 604310537
> etype: 1 item
> ENCTYPE: eTYPE-AES128-CTS-HMAC-SHA1-96 (17)
> 
> 
> Is there a field missing?

CCing Andreas as this one sounds like a bug we recently discovered in
the ASN.1 parser in samba.

Andreas,
does this ring a bell ?

Marc,
what version of IPA/OS are you seeing this on ?

Simo.


-- 
Simo Sorce * Red Hat, Inc * New York

-- 
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] Fwd: Re: FreeIPA en Domain Trust

2015-11-23 Thread Jakub Hrozek 
On Mon, Nov 23, 2015 at 04:43:11PM +0100, Winfried de Heiden wrote:
>Hi all,
> 
>One motivation: the customer demands like this...

Yes, but why? It doesn't make sense to me..

>Also: ignore Windows specific group info which is not important for the
>Linux domain
>Also: too much groups!
> 
>If it's a sssd thing, this might be solved on the IPA-server as well since
>getting the AD group info is handles by sssd on the IPA-server, right?
>Anyway: how to handle this issue?

Can't be done at the moment short of blacklisting each and every group
using filter_groups or min_id/max_id ranges. Both are hacks that should
be avoided, though..

The reason is that the trusted domain configuration on the SSSD side is
more or less always using defaults and things like search bases can't be
set for the subdomain at the moment.

> 
>Kind regards,
> 
>Winny
>Op 23-11-15 om 10:54 schreef Martin Kosek:
> 
>  On 11/23/2015 10:50 AM, Winfried de Heiden wrote:
> 
>  Hi all,
> 
>  For some reason, we only want to use the Active Directory user from an Active
>  Directory using a Trust. (groups like "Domain Users"  are of no use...)
> 
>  Is it possible to ignore (hide) ALL groups from a particular Domain (trust)/
> 
>  Kinds Regards,
> 
>  Winny
> 
>  This looks as a question for the client part (SSSD). I do not fully 
> understand
>  the use case, you want to allow AD user to authenticate to Linux box, but you
>  do not want the Linux box to see any of the AD groups? What is the 
> motivation,
>  if I may ask?

> -- 
> 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] "ASN.1 structure is missing a required field" - what is missing?

2015-11-23 Thread Marc Boorshtein 
We actually tracked it down.  The problem was the Authenticator was
missing the authenticatorkvno field per the RFC.  Once we set that to
5 we got past this issue.

IPA 4.1 on CentOS7

Thanks
Marc Boorshtein
CTO Tremolo Security
marc.boorsht...@tremolosecurity.com



On Mon, Nov 23, 2015 at 10:38 AM, Simo Sorce  wrote:
> On Tue, 2015-11-17 at 21:36 -0500, Marc Boorshtein wrote:
>> I'm putting together a java kerberos client and am having an issue
>> getting a SGT form IPA.  I get a TGT without issue, but when I submit
>> the TGS-REQ I get the following errors in the ipa log:
>>
>> Nov 17 20:53:15 freeipa.rhelent.lan krb5kdc[7507](info): AS_REQ (1
>> etypes {17}) 192.168.2.129: ISSUE: authtime 1447811595, etypes {rep=17
>> tkt=18 ses=17}, HTTP/s4u.rhelent@rhelent.lan for
>> krbtgt/rhelent@rhelent.lan
>>
>> Nov 17 20:53:15 freeipa.rhelent.lan krb5kdc[7507](info): TGS_REQ (1
>> etypes {17}) 192.168.2.129: PROCESS_TGS: authtime 0,  
>> for HTTP/ipa.rhelent@rhelent.lan, ASN.1 structure is missing a
>> required field
>>
>> Here's the TGS request:
>>
>> Kerberos
>> tgs-req
>> pvno: 5
>> msg-type: krb-tgs-req (12)
>> padata: 1 item
>> PA-DATA PA-TGS-REQ
>> padata-type: kRB5-PADATA-TGS-REQ (1)
>> padata-value:
>> 6e8201f8308201f4a003020105a10302010ea2070305...
>> ap-req
>> pvno: 5
>> msg-type: krb-ap-req (14)
>> Padding: 0
>> ap-options: 
>> 0...  = reserved: False
>> .0..  = use-session-key: False
>> ..0.  = mutual-required: False
>> ticket
>> tkt-vno: 5
>> realm: RHELENT.LAN
>> sname
>> name-type: kRB5-NT-PRINCIPAL (1)
>> name-string: 2 items
>> KerberosString: krbtgt
>> KerberosString: RHELENT.LAN
>> enc-part
>> etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
>> kvno: 1
>> cipher:
>> 0efd7452dafeb94323bcf7f6adc373aab78ce179f42c4c11...
>> authenticator
>> etype: eTYPE-AES128-CTS-HMAC-SHA1-96 (17)
>> kvno: 255
>> cipher:
>> f40e91b920c6ae6bdc30a69d5f348bf106355a92da74ba74...
>> req-body
>> Padding: 0
>> kdc-options: 
>> 0...  = reserved: False
>> .0..  = forwardable: False
>> ..0.  = forwarded: False
>> ...0  = proxiable: False
>>  0... = proxy: False
>>  .0.. = allow-postdate: False
>>  ..0. = postdated: False
>>  ...0 = unused7: False
>> 0...  = renewable: False
>> .0..  = unused9: False
>> ..0.  = unused10: False
>> ...0  = opt-hardware-auth: False
>>  ..0. = request-anonymous: False
>>  ...0 = canonicalize: False
>> 0...  = constrained-delegation: False
>> ..0.  = disable-transited-check: False
>> ...0  = renewable-ok: False
>>  0... = enc-tkt-in-skey: False
>>  ..0. = renew: False
>>  ...0 = validate: False
>> cname
>> name-type: kRB5-NT-PRINCIPAL (1)
>> name-string: 2 items
>> KerberosString: HTTP
>> KerberosString: s4u.rhelent.lan
>> realm: RHELENT.LAN
>> sname
>> name-type: kRB5-NT-PRINCIPAL (1)
>> name-string: 2 items
>> KerberosString: HTTP
>> KerberosString: ipa.rhelent.lan
>> from: 2015-11-18 02:17:44 (UTC)
>> till: 2015-11-18 10:17:44 (UTC)
>> nonce: 604310537
>> etype: 1 item
>> ENCTYPE: eTYPE-AES128-CTS-HMAC-SHA1-96 (17)
>>
>>
>> Is there a field missing?
>
> CCing Andreas as this one sounds like a bug we recently discovered in
> the ASN.1 parser in samba.
>
> Andreas,
> does this ring a bell ?
>
> Marc,
> what version of IPA/OS are you seeing this on ?
>
> Simo.
>
>
> --
> Simo Sorce * Red Hat, Inc * New York
>

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to

Re: [Freeipa-users] freeipa harware appliance

2015-11-23 Thread Martin Basti 



On 20.11.2015 18:37, Karl Forner wrote:

Thanks Martin.
My expected numbers: users ~ 50 max, concurrent clients/sessions < 20, 
hosts < 20.
I was thinking about a server with an old intel cpu, 4Gb RAM and smal 
HDD or USB key-based storage + an ethernet port.
I have no idea if it is a common use in IT to run such (critical) 
application on its own dedicated appliance.

This configuration should be enough.

Virtualization is everywhere, many users use IPA in virtualized 
environment :-)




On Fri, Nov 20, 2015 at 6:29 PM, Martin Basti > wrote:




On 20.11.2015 16:47, Karl Forner wrote:

Hello,

Could you recommend me a mini appliance/server to use as a
freeIPA server ?
I guess the main points are an ethernet port, minimal
consumption, robustness.

Thanks,
Karl Forner



Hello,

I would say that minimal amount of RAM is 2GB with IPA 4.2, of
course amount of resources depends on many things.

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/Preparing_for_an_IPA_Installation-Hardware_Requirements.html

Disk space at least 500MB for basic installation + baseOS + stored
data

I do not know if IPA is limited by a CPU in somehow, but with very
slow CPU you may need to increase timeouts (I saw the posts on
this lists that it is possible to run IPA on raspberry pi with
increased timeouts)

Maybe would be better if you write what do you need this minimal
configuration for and how many clients, users and connections
should IPA handle.

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

[Freeipa-users] [Solved] Re: "ASN.1 structure is missing a required field" - what is missing?

2015-11-23 Thread Simo Sorce 
On Mon, 2015-11-23 at 10:41 -0500, Marc Boorshtein wrote:
> We actually tracked it down.  The problem was the Authenticator was
> missing the authenticatorkvno field per the RFC.  Once we set that to
> 5 we got past this issue.

Ok, then we'll considered this solved, thanks for following up.

Simo.

> IPA 4.1 on CentOS7
> 
> Thanks
> Marc Boorshtein
> CTO Tremolo Security
> marc.boorsht...@tremolosecurity.com
> 
> 
> 
> On Mon, Nov 23, 2015 at 10:38 AM, Simo Sorce  wrote:
> > On Tue, 2015-11-17 at 21:36 -0500, Marc Boorshtein wrote:
> >> I'm putting together a java kerberos client and am having an issue
> >> getting a SGT form IPA.  I get a TGT without issue, but when I submit
> >> the TGS-REQ I get the following errors in the ipa log:
> >>
> >> Nov 17 20:53:15 freeipa.rhelent.lan krb5kdc[7507](info): AS_REQ (1
> >> etypes {17}) 192.168.2.129: ISSUE: authtime 1447811595, etypes {rep=17
> >> tkt=18 ses=17}, HTTP/s4u.rhelent@rhelent.lan for
> >> krbtgt/rhelent@rhelent.lan
> >>
> >> Nov 17 20:53:15 freeipa.rhelent.lan krb5kdc[7507](info): TGS_REQ (1
> >> etypes {17}) 192.168.2.129: PROCESS_TGS: authtime 0,  
> >> for HTTP/ipa.rhelent@rhelent.lan, ASN.1 structure is missing a
> >> required field
> >>
> >> Here's the TGS request:
> >>
> >> Kerberos
> >> tgs-req
> >> pvno: 5
> >> msg-type: krb-tgs-req (12)
> >> padata: 1 item
> >> PA-DATA PA-TGS-REQ
> >> padata-type: kRB5-PADATA-TGS-REQ (1)
> >> padata-value:
> >> 6e8201f8308201f4a003020105a10302010ea2070305...
> >> ap-req
> >> pvno: 5
> >> msg-type: krb-ap-req (14)
> >> Padding: 0
> >> ap-options: 
> >> 0...  = reserved: False
> >> .0..  = use-session-key: False
> >> ..0.  = mutual-required: False
> >> ticket
> >> tkt-vno: 5
> >> realm: RHELENT.LAN
> >> sname
> >> name-type: kRB5-NT-PRINCIPAL (1)
> >> name-string: 2 items
> >> KerberosString: krbtgt
> >> KerberosString: RHELENT.LAN
> >> enc-part
> >> etype: eTYPE-AES256-CTS-HMAC-SHA1-96 
> >> (18)
> >> kvno: 1
> >> cipher:
> >> 0efd7452dafeb94323bcf7f6adc373aab78ce179f42c4c11...
> >> authenticator
> >> etype: eTYPE-AES128-CTS-HMAC-SHA1-96 (17)
> >> kvno: 255
> >> cipher:
> >> f40e91b920c6ae6bdc30a69d5f348bf106355a92da74ba74...
> >> req-body
> >> Padding: 0
> >> kdc-options: 
> >> 0...  = reserved: False
> >> .0..  = forwardable: False
> >> ..0.  = forwarded: False
> >> ...0  = proxiable: False
> >>  0... = proxy: False
> >>  .0.. = allow-postdate: False
> >>  ..0. = postdated: False
> >>  ...0 = unused7: False
> >> 0...  = renewable: False
> >> .0..  = unused9: False
> >> ..0.  = unused10: False
> >> ...0  = opt-hardware-auth: False
> >>  ..0. = request-anonymous: False
> >>  ...0 = canonicalize: False
> >> 0...  = constrained-delegation: False
> >> ..0.  = disable-transited-check: False
> >> ...0  = renewable-ok: False
> >>  0... = enc-tkt-in-skey: False
> >>  ..0. = renew: False
> >>  ...0 = validate: False
> >> cname
> >> name-type: kRB5-NT-PRINCIPAL (1)
> >> name-string: 2 items
> >> KerberosString: HTTP
> >> KerberosString: s4u.rhelent.lan
> >> realm: RHELENT.LAN
> >> sname
> >> name-type: kRB5-NT-PRINCIPAL (1)
> >> name-string: 2 items
> >> KerberosString: HTTP
> >> KerberosString: ipa.rhelent.lan
> >> from: 2015-11-18 02:17:44 (UTC)
> >> till: 2015-11-18 10:17:44 (UTC)
> >> nonce: 604310537
> >> etype: 1 item
> >> ENCTYPE: eTYPE-AES128-CTS-HMAC-SHA1-96 (17)
> >>
> >>
> >> Is there a field missing?
> >
> > CCing Andreas as this one sounds like a bug

[Freeipa-users] Fwd: Re: FreeIPA en Domain Trust

2015-11-23 Thread Winfried de Heiden 

  
  

Hi all,

One motivation: the customer demands like this...
Also: ignore Windows specific group info which is not important
for the Linux domain
Also: too much groups!

If it's a sssd thing, this might be solved on the IPA-server as
well since getting the AD group info is handles by sssd on the
IPA-server, right?
Anyway: how to handle this issue?

Kind regards,

Winny
  
  Op 23-11-15 om 10:54 schreef Martin
Kosek:
  
  
On 11/23/2015 10:50 AM, Winfried de Heiden wrote:


  Hi all,

For some reason, we only want to use the Active Directory user from an Active 
Directory using a Trust. (groups like "Domain Users"  are of no use...)

Is it possible to ignore (hide) ALL groups from a particular Domain (trust)/

Kinds Regards,

Winny


This looks as a question for the client part (SSSD). I do not fully understand
the use case, you want to allow AD user to authenticate to Linux box, but you
do not want the Linux box to see any of the AD groups? What is the motivation,
if I may ask?


  
  
  


  


-- 
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] hbac service allowed despite not listed

2015-11-23 Thread Jakub Hrozek 
On Mon, Nov 23, 2015 at 04:55:31PM +0100, Winfried de Heiden wrote:
>Hi all,
> 
>I created some hbac rule on freeipa-server 4.1.4 on Fedora 22
> 
># ipa hbacrule-show testuser
>  Rule name: testuser
>  Enabled: TRUE
>  Users: testuser
>  Hosts: fedora23-server.blabla.bla
>  Services: sshd
> 
>Hence, " testuser"  is only allowed using sshd on "fedora23-server". No
>surprise, this user is not allowed to use "su":
> 
># ipa hbactest --user testuser --host fedora23-server.blabla.bla --service
>su
>-
>Access granted: False
> 
>(and yeah sshd is allowed)
> 
>However, doing a "su"  on the fedora23-server.blabla.bla, and giving the
>correct password, access is granted. This user is not a member of any
>other groups.
>HBAC Services like cron or console access are denied correctly since they
>are not in the HBAC service list.
> 
>I noticed this behaviour also on IPA 4.1 (The Red Hat one) and several
>other ipa-clients (RHEL/CentoOS 6.x, 7.x)
> 
>Shouldn't su or su -l be denied when not listed?

Yes, and in my testing with a similar rule:

$ ipa hbacrule-show allow_sshd
  Rule name: allow_sshd
  Enabled: TRUE
  Users: admin
  Hosts: client.ipa.test
  Services: sshd

admin can ssh to client.ipa.test but it's not possible to su to admin.

Please follow https://fedorahosted.org/sssd/wiki/Troubleshooting and check
/var/log/secure and the sssd logs.

Also, you're not calling su as root, are you?

-- 
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] hbac service allowed despite not listed

2015-11-23 Thread Sumit Bose 
On Mon, Nov 23, 2015 at 05:16:26PM +0100, Jakub Hrozek wrote:
> On Mon, Nov 23, 2015 at 04:55:31PM +0100, Winfried de Heiden wrote:
> >Hi all,
> > 
> >I created some hbac rule on freeipa-server 4.1.4 on Fedora 22
> > 
> ># ipa hbacrule-show testuser
> >  Rule name: testuser
> >  Enabled: TRUE
> >  Users: testuser
> >  Hosts: fedora23-server.blabla.bla
> >  Services: sshd
> > 
> >Hence, " testuser"  is only allowed using sshd on "fedora23-server". No
> >surprise, this user is not allowed to use "su":
> > 
> ># ipa hbactest --user testuser --host fedora23-server.blabla.bla 
> > --service
> >su
> >-
> >Access granted: False
> > 
> >(and yeah sshd is allowed)
> > 
> >However, doing a "su"  on the fedora23-server.blabla.bla, and giving the
> >correct password, access is granted. This user is not a member of any
> >other groups.
> >HBAC Services like cron or console access are denied correctly since they
> >are not in the HBAC service list.
> > 
> >I noticed this behaviour also on IPA 4.1 (The Red Hat one) and several
> >other ipa-clients (RHEL/CentoOS 6.x, 7.x)
> > 
> >Shouldn't su or su -l be denied when not listed?
> 
> Yes, and in my testing with a similar rule:
> 
> $ ipa hbacrule-show allow_sshd
>   Rule name: allow_sshd
>   Enabled: TRUE
>   Users: admin
>   Hosts: client.ipa.test
>   Services: sshd
> 
> admin can ssh to client.ipa.test but it's not possible to su to admin.
> 
> Please follow https://fedorahosted.org/sssd/wiki/Troubleshooting and check
> /var/log/secure and the sssd logs.
> 
> Also, you're not calling su as root, are you?

Have you disabled the allow_all rule?

bye,
Sumit

> 
> -- 
> 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