date:20150518


On 05/19/2015 04:04 AM, Dewangga Bachrul Alam wrote:

Hello!

I'm trying to reinstall ipa client, but have a problem with old/existing
ca.crt in `/etc/ipa/ca.crt`. Should I remove it manually? Since the IPA
server still on development and always reinstalled, I need to reproduce
any possible problem/error on FreeIPA 4.x on CentOS 7.

The error was :
LDAP Error: Connect error: TLS error -8054:You are attempting to import
a cert with the same issuer/serial as an existing cert, but that is not
the same cert.

Currently, I was renamed ca.crt to ca.crt.old and the ipa client
successfully reconnected to new FreeIPA Server using dns discovery.

Is it normal? And why the ipa-client-install --uninstall didn't
completely remove the old ca.crt?


Hello,

ipa-client-install uninstall the CA certificate properly since FreeIPA 3.2. 
This is the upstream ticket:

https://fedorahosted.org/freeipa/ticket/3537

CentOS/RHEL speaking, this should be thus fixed in 7.0+. In 6.x versions, you 
need to delete the certificate manually if you reinstalled the IPA server.


HTH,
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] replication again :-(


On 05/19/2015 03:23 AM, Janelle wrote:

Once again, replication/sync has been lost. I really wish the product was more
stable, it is so much potential and yet.

Servers running for 6 days no issues. No new accounts or changes (maybe a few
users changing passwords) and again, 5 out of 16 servers are no longer in sync.

I can test it easily by adding an account and then waiting a few minutes, then
run "ipa  user-show --all username" on all the servers, and only a few of them
have the account.  I have now waited 15 minutes, still no luck.

Oh well.. I guess I will go look at alternatives. I had such high hopes for
this tool. Thanks so much everyone for all your help in trying to get things
stable, but for whatever reason, there is a random loss of sync among the
servers and obviously this is not acceptable.


Hello Janelle,

I am very sorry to hear about your troubles. Would you be still OK with helping 
us (mostly Ludwig and Thierry) investigate what is the root cause of the 
instability of the replication agreements? This is obviously something that 
should not be happening at this rate as in your deployment, so I would really 
like to be able to identity and fix this issue in the 389 DS.


--
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] Reinstall ipa client, problem with old CA

2015-05-18 Thread Dewangga Bachrul Alam

Hello!

I'm trying to reinstall ipa client, but have a problem with old/existing
ca.crt in `/etc/ipa/ca.crt`. Should I remove it manually? Since the IPA
server still on development and always reinstalled, I need to reproduce
any possible problem/error on FreeIPA 4.x on CentOS 7.

The error was :
LDAP Error: Connect error: TLS error -8054:You are attempting to import
a cert with the same issuer/serial as an existing cert, but that is not
the same cert.

Currently, I was renamed ca.crt to ca.crt.old and the ipa client
successfully reconnected to new FreeIPA Server using dns discovery.

Is it normal? And why the ipa-client-install --uninstall didn't
completely remove the old ca.crt?

Thank 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] replication again :-(


On 5/18/15 6:23 PM, Janelle wrote:
Once again, replication/sync has been lost. I really wish the product 
was more stable, it is so much potential and yet.


Servers running for 6 days no issues. No new accounts or changes 
(maybe a few users changing passwords) and again, 5 out of 16 servers 
are no longer in sync.


I can test it easily by adding an account and then waiting a few 
minutes, then run "ipa  user-show --all username" on all the servers, 
and only a few of them have the account.  I have now waited 15 
minutes, still no luck.


Oh well.. I guess I will go look at alternatives. I had such high 
hopes for this tool. Thanks so much everyone for all your help in 
trying to get things stable, but for whatever reason, there is a 
random loss of sync among the servers and obviously this is not 
acceptable.


regards
~J

A new error:

[ipa03.example.com] reports: Update failed! Status: [49  - LDAP error: 
Invalid credentials]



--
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] replication again :-(

Once again, replication/sync has been lost. I really wish the product 
was more stable, it is so much potential and yet.


Servers running for 6 days no issues. No new accounts or changes (maybe 
a few users changing passwords) and again, 5 out of 16 servers are no 
longer in sync.


I can test it easily by adding an account and then waiting a few 
minutes, then run "ipa  user-show --all username" on all the servers, 
and only a few of them have the account.  I have now waited 15 minutes, 
still no luck.


Oh well.. I guess I will go look at alternatives. I had such high hopes 
for this tool. Thanks so much everyone for all your help in trying to 
get things stable, but for whatever reason, there is a random loss of 
sync among the servers and obviously this is not acceptable.


regards
~J

--
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] interesting Kerberos issue


On 5/18/15 7:47 AM, Nathaniel McCallum wrote:

On Mon, 2015-05-18 at 09:45 -0500, Janelle wrote:

Ok, let me ask this a different way, because maybe there is a way,
and I am just not seeing it.

I have 2 datacenters with typical bastions in each. I have enabled
OTP and that works fine via ssh. But the user has to login to both
and opening ssh tunnels is problematic at best.

Using all the creativity in this list, maybe someone knows of another
way to have a user authenticate from a Mac where they would only have
to do it once to get their ticket?

I guess I can't think of anything, but no harm in asking.

Without support for the OTP pre-authentication mechanism, I don't know
of any way to do this while still retaining the security properties of
Kerberos. Basically, you'll have to hand over your password to a third
party (which has OTP support). This is ill advised.

Nathaniel
Going to see about installing MIT version from source on  Yosemite and 
see what happens.. Current is 1.13.2


Will let you know
~J

--
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] Certificate operation cannot be completed: Unable to communicate with CMS (Not Found)


Sina Owolabi wrote:

Hi Rob

There are  some logs in /var/log/pki-ca/catalina.out that appear to
indicate  a problem:


[SNIP]

These are mostly white noise from tomcat and can be ignored.




Also running "getcert list" tells me there are two expired certs:

Request ID '20130524104636':
 status: CA_UNREACHABLE
 ca-error: Server at https://dc.ourdom.com/ipa/xml failed
request, will retry: 907 (RPC failed at server.  cannot connect to
'https://dc.ourdom.com:443/ca/agent/ca/displayBySerial': [Errno
-12269] (SSL_ERROR_EXPIRED_CERT_ALERT) SSL peer rejected your
certificate as expired.).
 stuck: no


Request ID '20130524104828':
 status: CA_UNREACHABLE
 ca-error: Server at https://dc.ourdom.com/ipa/xml failed
request, will retry: 907 (RPC failed at server.  cannot connect to
'https://dc.ourdom.com:443/ca/agent/ca/displayBySerial': [Errno
-12269] (SSL_ERROR_EXPIRED_CERT_ALERT) SSL peer rejected your
certificate as expired.).
 stuck: no

I'd be grateful to know what to do.


Your CA subsystem certificates are expired so while the process is up 
the CA won't serve requests. See 
http://www.freeipa.org/page/Howto/CA_Certificate_Renewal


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] LDAP uid to cn modify


Vangass wrote:

Yes, I saw that discussion but there is no solution.
So how to create compat tree?
In my ldap there is somenting like
"uid=bartosz,cn=users,cn=compat,dc=example,dc=com" - but it is still
with uid.
PS. I have fresh instalation CentOS 7.1 and IPA 4.1.


Take a look at /usr/share/doc/slapi-nis/sch-getting-started.txt

You'll need to write your own set of rules to create new compat tree 
entries.


rob



2015-05-18 16:03 GMT+02:00 Rob Crittenden mailto:rcrit...@redhat.com>>:

Vangass wrote:

Hi,

I try to set FreeIPA as a LDAP server for HP iLO authentication. iLO
client sends dn as
"cn=bartosz,cn=users,cn=accounts,dc=example,dc=com"
but in FreeIPA there is no cn=bartosz just uid=bartosz (as for
any other
user I create is uid). Is it possible to modify uid to cn or is
there
any other option?

Thanks,
Bartosz Witkowski



Others have had the same issue,
https://www.redhat.com/archives/freeipa-users/2014-January/msg00180.html

If you are running EL 7+ you should be able to create a compat
configuration to make it work but it isn't clear if anyone has done
this work on IPA 3.3+ or not yet (IIRC the users in this thread were
all still on RHEL 6).

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] Securing IPA Redux

Rich Megginson wrote:

On 05/18/2015 08:26 AM, Martin Kosek wrote:

Adding freeipa-users list back, to keep others in the loop.

On 05/18/2015 12:32 PM, Brian Topping wrote:

Thanks for taking the time to write that, Martin. It's good to have a
reference to build from.

Result of "ida-client-install" outside the firewall with port 636
accessible:

Ah, I mostly just use 636 as a convenience port to show the supported
cryptos,
389 is really the port we should be using by default.

Of course, 389 port + STARTTLS environment turned on, to make sure
passwords do
not go in clean over the wire.

Please make sure the following ports are opened in the firewall
settings:
TCP: 80, 88, 389
UDP: 88 (at least one of TCP/UDP ports 88 has to be open)
Also note that following ports are necessary for ipa-client working
properly after enrollment:
TCP: 464
UDP: 464, 123 (if NTP enabled)

No mention of 636, confirmed by tcpdump that it's not trying. Also no
option on command line to specify 636.

Opening up 389 means that some misconfigured client could expose
passwords.

Not necessarily.
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/SecureConnections.html#requiring-secure-connections

It's possible to remove null ciphers, but then there's really no
reason not to use 636.

Seems like ipa-client-install should try 636 by default, then fall
back to 389 in it's various forms, no?

I think the general direction here was the opposite. To work on the
port 389 as
the common denominator, offering both password-less traffic and encrypted
traffic. I am not sure if there were other reasons too, I would let
Rob or
Ludwig reply here if they know.

ldaps / port 636 is deprecated in favor of StartTLS. For OpenLDAP's take
on it see http://www.openldap.org/faq/data/cache/605.html

rob

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] Apache htaccess replacement

2015-05-18 Thread thewebbie

Hello

I have been attempting to use my 4.1.4  FreeIPA server to authenticate
folders on a web server as a replacement for the normal htaccess feature. I
do require group authentication. I have tried just about online example and
have only been able to get basic ldap and basic kerbos authentication.  How
do I go about getting group based authentication working.

I have tried to add the following to either example below and no luck. I
added the httpbind user from an ldif file from examples. I created a user
group named htaccess and added the users to it.

AuthLDAPBindDN uid=httpbind,cn=sysaccounts,cn=etc,dc=test,dc=com
AuthLDAPBindPassword XX
AuthLDAPGroupAttributeIsDN off
AuthLDAPUrl ldap://ipa.test.com/dc=test,dc=com?uid
Require ldap-group cn=htaccess,cn=groups,cn=compat,dc=test,dc=com

My error logs look like

[Mon May 18 14:31:19 2015] [debug] src/mod_auth_kerb.c(1944): [client
xxx.xxx.xxx.xxx] kerb_authenticate_user entered with user (NULL) and
auth_type Kerberos

[Mon May 18 14:31:19 2015] [debug] src/mod_auth_kerb.c(1032): [client
xxx.xxx.xxx.xxx] Using HTTP/server1.test@test.com as server principal
for password verification

[Mon May 18 14:31:19 2015] [debug] src/mod_auth_kerb.c(736): [client
xxx.xxx.xxx.xxx] Trying to get TGT for user js...@test.com

[Mon May 18 14:31:19 2015] [debug] src/mod_auth_kerb.c(646): [client
xxx.xxx.xxx.xxx] Trying to verify authenticity of KDC using principal
HTTP/server1.test@test.com

[Mon May 18 14:31:19 2015] [debug] src/mod_auth_kerb.c(): [client
xxx.xxx.xxx.xxx] kerb_authenticate_user_krb5pwd ret=0 user=js...@test.com
authtype=Basic

[Mon May 18 14:31:19 2015] [debug] mod_authnz_ldap.c(727): [client
xxx.xxx.xxx.xxx] ldap authorize: Creating LDAP req structure

[Mon May 18 14:31:19 2015] [debug] mod_authnz_ldap.c(739): [client
xxx.xxx.xxx.xxx] auth_ldap authorise: User DN not found, LDAP:
ldap_simple_bind_s() failed

I have this working.

 

SSLRequireSSL
AuthName "LDAP Authentication"
AuthType Basic
AuthzLDAPMethod ldap
AuthzLDAPServer ipa.test.com
AuthzLDAPUserBase cn=users,cn=compat,dc=test,dc=com
AuthzLDAPUserKey uid
AuthzLDAPUserScope base
require valid-user

   

And this is working

 

SSLRequireSSL
AuthName "KERBEROS Authentication"
AuthType Kerberos
KrbServiceName HTTP
KrbMethodK5Passwd On
KrbSaveCredentials On
KrbMethodNegotiate On
KrbAuthRealms TEST.COM
Krb5KeyTab /etc/httpd/conf.d/keytab

AuthLDAPUrl ldap://ipa.test.com/dc=test,dc=com?krbPrincipalName
Require valid-user

   
-- 

=
Matthew Feinberg
-- 
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] Certificate operation cannot be completed: Unable to communicate with CMS (Not Found)

2015-05-18 Thread Sina Owolabi

Hi Rob

There are some logs in /var/log/pki-ca/catalina.out that appear to
indicate a problem:
CMS Warning: FAILURE: Cannot build CA chain. Error
java.security.cert.CertificateException: Certificate is not a PKCS #11
certificate|FAILURE: authz instance DirAclAuthz initialization failed
and skipped, error=Property internaldb.ldapconn.port missing value|
Server is started.

SEVERE: A web application appears to have started a thread named
[Timer-0] but has failed to stop it. This is very likely to create a
memory leak.
May 24, 2013 11:47:35 AM org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads
SEVERE: A web application appears to have started a thread named
[/var/lib/pki-ca/logs/signedAudit/ca_audit.flush-3] but has failed to
stop it. This is very likely to create a memory leak.
May 24, 2013 11:47:35 AM org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads
SEVERE: A web application appears to have started a thread named
[/var/lib/pki-ca/logs/signedAudit/ca_audit.rollover-4] but has failed
to stop it. This is very likely to create a memory leak.
May 24, 2013 11:47:35 AM org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads
SEVERE: A web application appears to have started a thread named
[/var/lib/pki-ca/logs/system.flush-5] but has failed to stop it. This
is very likely to create a memory leak.
May 24, 2013 11:47:35 AM org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads
SEVERE: A web application appears to have started a thread named
[/var/lib/pki-ca/logs/system.rollover-6] but has failed to stop it.
This is very likely to create a memory leak.
May 24, 2013 11:47:35 AM org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads
SEVERE: A web application appears to have started a thread named
[/var/lib/pki-ca/logs/transactions.flush-7] but has failed to stop it.
This is very likely to create a memory leak.
May 24, 2013 11:47:35 AM org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads
SEVERE: A web application appears to have started a thread named
[/var/lib/pki-ca/logs/transactions.rollover-8] but has failed to stop
it. This is very likely to create a memory leak.
May 24, 2013 11:47:35 AM org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads
SEVERE: A web application appears to have started a thread named
[/var/lib/pki-ca/logs/selftests.log.flush-9] but has failed to stop
it. This is very likely to create a memory leak.
May 24, 2013 11:47:35 AM org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads
SEVERE: A web application appears to have started a thread named
[/var/lib/pki-ca/logs/selftests.log.rollover-10] but has failed to
stop it. This is very likely to create a memory leak.
May 24, 2013 11:47:35 AM org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads
SEVERE: A web application appears to have started a thread named
[LDAPConnThread-2 ldap://dc.ourdom.com:7389] but has failed to stop
it. This is very likely to create a memory leak.
May 24, 2013 11:47:35 AM org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads
SEVERE: A web application appears to have started a thread named
[LDAPConnThread-3 ldap://dc.ourdom.com:7389] but has failed to stop
it. This is very likely to create a memory leak.
May 24, 2013 11:47:35 AM org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads
SEVERE: A web application appears to have started a thread named
[LDAPConnThread-4 ldap://dc.ourdom.com:7389] but has failed to stop
it. This is very likely to create a memory leak.
May 24, 2013 11:47:35 AM org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads
SEVERE: A web application appears to have started a thread named
[LDAPConnThread-5 ldap://dc.ourdom.com:7389] but has failed to stop
it. This is very likely to create a memory leak.
May 24, 2013 11:47:35 AM org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads
SEVERE: A web application appears to have started a thread named
[LDAPConnThread-6 ldap://dc.ourdom.com:7389] but has failed to stop
it. This is very likely to create a memory leak.
May 24, 2013 11:47:35 AM org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads
SEVERE: A web application appears to have started a thread named
[LDAPConnThread-8 ldap://dc.ourdom.com:7389] but has failed to stop
it. This is very likely to create a memory leak.
May 24, 2013 11:47:35 AM org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads

May 24, 2013 11:48:10 AM org.apache.catalina.core.AprLifecycleListener init
INFO: The APR based Apache Tomcat Native library which allows optimal
performance in production environments was not found on the
java.library.path:
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server:/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64:/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/../lib/amd64:/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib

SEVERE: A web application created a Thr

Re: [Freeipa-users] interesting Kerberos issue


> On May 18, 2015, at 09:47, Nathaniel McCallum  wrote:
> 
>> On Mon, 2015-05-18 at 09:45 -0500, Janelle wrote:
>> Ok, let me ask this a different way, because maybe there is a way, 
>> and I am just not seeing it.
>> 
>> I have 2 datacenters with typical bastions in each. I have enabled 
>> OTP and that works fine via ssh. But the user has to login to both 
>> and opening ssh tunnels is problematic at best.
>> 
>> Using all the creativity in this list, maybe someone knows of another 
>> way to have a user authenticate from a Mac where they would only have 
>> to do it once to get their ticket?
>> 
>> I guess I can't think of anything, but no harm in asking.
> 
> Without support for the OTP pre-authentication mechanism, I don't know
> of any way to do this while still retaining the security properties of
> Kerberos. Basically, you'll have to hand over your password to a third
> party (which has OTP support). This is ill advised.
> 
> Nathaniel

Excellent point.  Thanks for all the tips and advice. 
And of course for a great product that continues to get better.

~J

-- 
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] LDAP uid to cn modify

2015-05-18 Thread Vangass

Yes, I saw that discussion but there is no solution.
So how to create compat tree?
In my ldap there is somenting like
"uid=bartosz,cn=users,cn=compat,dc=example,dc=com" - but it is still with
uid.
PS. I have fresh instalation CentOS 7.1 and IPA 4.1.

2015-05-18 16:03 GMT+02:00 Rob Crittenden :

> Vangass wrote:
>
>> Hi,
>>
>> I try to set FreeIPA as a LDAP server for HP iLO authentication. iLO
>> client sends dn as "cn=bartosz,cn=users,cn=accounts,dc=example,dc=com"
>> but in FreeIPA there is no cn=bartosz just uid=bartosz (as for any other
>> user I create is uid). Is it possible to modify uid to cn or is there
>> any other option?
>>
>> Thanks,
>> Bartosz Witkowski
>>
>>
>>
> Others have had the same issue,
> https://www.redhat.com/archives/freeipa-users/2014-January/msg00180.html
>
> If you are running EL 7+ you should be able to create a compat
> configuration to make it work but it isn't clear if anyone has done this
> work on IPA 3.3+ or not yet (IIRC the users in this thread were all still
> on RHEL 6).
>
> 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] Securing IPA Redux

2015-05-18 Thread Brian Topping


> On May 18, 2015, at 9:55 PM, Rich Megginson  > wrote:
> 
> Not necessarily.
> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/SecureConnections.html#requiring-secure-connections
>  
> 

I think that covers what I need in combination with what Martin previously 
provided.

Thanks guys!


signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
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] trusted user groups

On 05/18/2015 04:50 PM, Andy Thompson wrote:
>> -Original Message-
>> From: Lukas Slebodnik [mailto:lsleb...@redhat.com]
>> Sent: Monday, May 18, 2015 10:33 AM
>> To: Andy Thompson
>> Cc: freeipa-users@redhat.com
>> Subject: Re: [Freeipa-users] trusted user groups
>>
>> On (18/05/15 13:55), Andy Thompson wrote:
 -Original Message-
 From: Lukas Slebodnik [mailto:lsleb...@redhat.com]
 Sent: Thursday, May 14, 2015 4:41 PM
 To: Andy Thompson
 Cc: freeipa-users@redhat.com
 Subject: Re: [Freeipa-users] trusted user groups

 On (14/05/15 15:53), Andy Thompson wrote:
>> -Original Message-
>> From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
>> boun...@redhat.com] On Behalf Of Jakub Hrozek
>> Sent: Thursday, May 14, 2015 11:46 AM
>> To: freeipa-users@redhat.com
>> Subject: Re: [Freeipa-users] trusted user groups
>>
>> On Thu, May 14, 2015 at 03:33:28PM +, Andy Thompson wrote:
>>> I've noticed that trusted users supplementary ad groups don't
>>> show up
>> until after the users login to the box at least once.
>>
>> That's expected with the versions you're running. Prior to 6.7, we
>> could only read the trusted users' group membership from the PAC
>> blob attached to the Kerberos ticket.
>>
>>
>>> Is there a chance that information will be dropped again at any
>>> point going
>> forward?
>>
>> No, otherwise it's a bug.
>>
>>>
>>> The reason I ask is that on our sftp boxes we chroot users based
>>> on group membership.  I set that up as an external group in
>>> freeIPA and the first time the user logs in to the sftp box,
>>> they are dropped in their normal home directory as opposed to
>>> the chroot environment.  If there is a chance the group
>>> membership will not show up correctly again in the future, I'm
>>> inclined to change the chroot stanzas to match on
>> user as opposed to group.
>>>
>>> Is that by design?
>>
>> If you can't see the correct group memberships after a login, then
>> something is fishy. However, we're rebasing to sssd 1.12.x in 6.7
>> and there's so many fixes and enhancements in this area..is there
>> a chance you could try out 6.7 beta or some custom packages?
>>
>
> Group memberships show up fine after the first login so it is
> working as
 expected then.  The accounts are very controlled so it shouldn't be a
 huge sticking point.  I could try out some custom packages on this
 box but I can't move to 6.7 until we upgrade the entire environment.
>
 Here you are
 https://copr.fedoraproject.org/coprs/lslebodn/sssd-1-12-latest/

>>>
>>> To just bring this full circle, the latest sssd release reads group 
>>> membership
>> correctly without a Kerberos ticket.  I tested this release on 6.6 and 
>> tested a
>> 7.1 box and both worked without issue.
>>>
>> I'm glad it works for you.
>>
>>> I just can't roll them in production yet :/
>>>
>> I see.
>>
> 
> You have any insight into when 6.7 will be released?

We cannot give any exact date at the moment, but given that 6.7 Beta is already
out, the GA should be out summer-ish. You can try to use the Beta packages now
or wait until it really hits GA.

HTH,
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] Securing IPA Redux

2015-05-18 Thread Rich Megginson

On 05/18/2015 08:26 AM, Martin Kosek wrote:

Adding freeipa-users list back, to keep others in the loop.

On 05/18/2015 12:32 PM, Brian Topping wrote:

Thanks for taking the time to write that, Martin. It's good to have a reference
to build from.

Result of "ida-client-install" outside the firewall with port 636 accessible:

Ah, I mostly just use 636 as a convenience port to show the supported cryptos,
389 is really the port we should be using by default.

Of course, 389 port + STARTTLS environment turned on, to make sure passwords do
not go in clean over the wire.

Please make sure the following ports are opened in the firewall settings:
TCP: 80, 88, 389
UDP: 88 (at least one of TCP/UDP ports 88 has to be open)
Also note that following ports are necessary for ipa-client working properly
after enrollment:
TCP: 464
UDP: 464, 123 (if NTP enabled)

No mention of 636, confirmed by tcpdump that it's not trying. Also no option on
command line to specify 636.

Opening up 389 means that some misconfigured client could expose passwords.

Not necessarily.
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/SecureConnections.html#requiring-secure-connections

It's possible to remove null ciphers, but then there's really no reason not to
use 636.

Seems like ipa-client-install should try 636 by default, then fall back to 389
in it's various forms, no?

I think the general direction here was the opposite. To work on the port 389 as
the common denominator, offering both password-less traffic and encrypted
traffic. I am not sure if there were other reasons too, I would let Rob or
Ludwig reply here if they know.

Martin

On May 18, 2015, at 4:10 PM, Martin Kosek wrote:

On 05/15/2015 01:33 PM, Brian Topping wrote:

In the (apparently) first message to the list in 2014,
https://www.redhat.com/archives/freeipa-users/2014-January/msg0.html

addressed questions about securing IPA and I don't see much other talk about it. Now
that 4.x is prevalent, I wanted to bring it up again.

This is the default by design. However, note that in FreeIPA 4.0+ you can
change that default (permission-mod) and let users or some of the user
attributes be only shown for authenticated users.

https://www.freeipa.org/page/V4/Permissions_V2

So, from my POV, this is not a flaw.

I'd like my installation to be allow hardened machines (i.e. in the cloud with encrypted
filesystems) to be a part of the domain. I believe this means that I need to expose
Kerberos and LDAP to the world, since the machines could live anywhere. I don't believe I
need to worry about KRB5, but I am concerned about 389-DS since it seems somewhat difficult
to force TLS (https://blog.routedlogic.net/?p=119
) and maybe that's a bad idea under IPA for
reasons I thought I'd ask here about. Last year's thread also referenced
https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/disabling-anon-binds.html

and I thought I would check to see if that's still necessary under 4.x.

389-DS and TLS should be also fixed, since FreeIPA 4.1 (RHEL/CentOS 7.1):

https://fedorahosted.org/freeipa/ticket/4653

This is an nmap test against the FreeIPA public demo (4.1.x):

$ nmap --script ssl-enum-ciphers -p 636 ipa.demo1.freeipa.org

Nmap done: 1 IP address (1 host up) scanned in 6.19 seconds

Setting up the firewall to allow cloud networks in is always an option, but if
I can get a secure IPA setup going, it would also allow road warriors to kinit
and use their credentials for configured intranet sites without having to turn
on the VPN (which can really slow things down from remote parts of the globe).

BTW, if you are concerned about exposed Kerberos traffic, FreeIPA 4.2 plans to
offer Kerberos-over-HTTP functionality by default:
https://fedorahosted.org/freeipa/ticket/4801

Even now, it can be manually configured. This is what GNOME used:
https://www.dragonsreach.it/2014/10/07/the-gnome-infrastructure-is-now-powered-by-freeipa/

So, if I am reading my notes correctly, there should be no blockers in using
FreeIPA in your

Re: [Freeipa-users] trusted user groups

2015-05-18 Thread Andy Thompson

> -Original Message-
> From: Lukas Slebodnik [mailto:lsleb...@redhat.com]
> Sent: Monday, May 18, 2015 10:33 AM
> To: Andy Thompson
> Cc: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] trusted user groups
> 
> On (18/05/15 13:55), Andy Thompson wrote:
> >> -Original Message-
> >> From: Lukas Slebodnik [mailto:lsleb...@redhat.com]
> >> Sent: Thursday, May 14, 2015 4:41 PM
> >> To: Andy Thompson
> >> Cc: freeipa-users@redhat.com
> >> Subject: Re: [Freeipa-users] trusted user groups
> >>
> >> On (14/05/15 15:53), Andy Thompson wrote:
> >> >> -Original Message-
> >> >> From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
> >> >> boun...@redhat.com] On Behalf Of Jakub Hrozek
> >> >> Sent: Thursday, May 14, 2015 11:46 AM
> >> >> To: freeipa-users@redhat.com
> >> >> Subject: Re: [Freeipa-users] trusted user groups
> >> >>
> >> >> On Thu, May 14, 2015 at 03:33:28PM +, Andy Thompson wrote:
> >> >> > I've noticed that trusted users supplementary ad groups don't
> >> >> > show up
> >> >> until after the users login to the box at least once.
> >> >>
> >> >> That's expected with the versions you're running. Prior to 6.7, we
> >> >> could only read the trusted users' group membership from the PAC
> >> >> blob attached to the Kerberos ticket.
> >> >>
> >> >>
> >> >> > Is there a chance that information will be dropped again at any
> >> >> > point going
> >> >> forward?
> >> >>
> >> >> No, otherwise it's a bug.
> >> >>
> >> >> >
> >> >> > The reason I ask is that on our sftp boxes we chroot users based
> >> >> > on group membership.  I set that up as an external group in
> >> >> > freeIPA and the first time the user logs in to the sftp box,
> >> >> > they are dropped in their normal home directory as opposed to
> >> >> > the chroot environment.  If there is a chance the group
> >> >> > membership will not show up correctly again in the future, I'm
> >> >> > inclined to change the chroot stanzas to match on
> >> >> user as opposed to group.
> >> >> >
> >> >> > Is that by design?
> >> >>
> >> >> If you can't see the correct group memberships after a login, then
> >> >> something is fishy. However, we're rebasing to sssd 1.12.x in 6.7
> >> >> and there's so many fixes and enhancements in this area..is there
> >> >> a chance you could try out 6.7 beta or some custom packages?
> >> >>
> >> >
> >> >Group memberships show up fine after the first login so it is
> >> >working as
> >> expected then.  The accounts are very controlled so it shouldn't be a
> >> huge sticking point.  I could try out some custom packages on this
> >> box but I can't move to 6.7 until we upgrade the entire environment.
> >> >
> >> Here you are
> >> https://copr.fedoraproject.org/coprs/lslebodn/sssd-1-12-latest/
> >>
> >
> >To just bring this full circle, the latest sssd release reads group 
> >membership
> correctly without a Kerberos ticket.  I tested this release on 6.6 and tested 
> a
> 7.1 box and both worked without issue.
> >
> I'm glad it works for you.
> 
> >I just can't roll them in production yet :/
> >
> I see.
> 

You have any insight into when 6.7 will be released?

-- 
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] interesting Kerberos issue

On Mon, 2015-05-18 at 09:45 -0500, Janelle wrote:
> Ok, let me ask this a different way, because maybe there is a way, 
> and I am just not seeing it.
> 
> I have 2 datacenters with typical bastions in each. I have enabled 
> OTP and that works fine via ssh. But the user has to login to both 
> and opening ssh tunnels is problematic at best.
> 
> Using all the creativity in this list, maybe someone knows of another 
> way to have a user authenticate from a Mac where they would only have 
> to do it once to get their ticket?
> 
> I guess I can't think of anything, but no harm in asking.

Without support for the OTP pre-authentication mechanism, I don't know
of any way to do this while still retaining the security properties of
Kerberos. Basically, you'll have to hand over your password to a third
party (which has OTP support). This is ill advised.

Nathaniel

-- 
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] interesting Kerberos issue

Ok, let me ask this a different way, because maybe there is a way, and I am 
just not seeing it.

I have 2 datacenters with typical bastions in each. I have enabled OTP and that 
works fine via ssh. But the user has to login to both and opening ssh tunnels 
is problematic at best.

Using all the creativity in this list, maybe someone knows of another way to 
have a user authenticate from a Mac where they would only have to do it once to 
get their ticket?

I guess I can't think of anything, but no harm in asking.

:)
~J

-- 
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] trusted user groups

2015-05-18 Thread Lukas Slebodnik

On (18/05/15 13:55), Andy Thompson wrote:
>> -Original Message-
>> From: Lukas Slebodnik [mailto:lsleb...@redhat.com]
>> Sent: Thursday, May 14, 2015 4:41 PM
>> To: Andy Thompson
>> Cc: freeipa-users@redhat.com
>> Subject: Re: [Freeipa-users] trusted user groups
>> 
>> On (14/05/15 15:53), Andy Thompson wrote:
>> >> -Original Message-
>> >> From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
>> >> boun...@redhat.com] On Behalf Of Jakub Hrozek
>> >> Sent: Thursday, May 14, 2015 11:46 AM
>> >> To: freeipa-users@redhat.com
>> >> Subject: Re: [Freeipa-users] trusted user groups
>> >>
>> >> On Thu, May 14, 2015 at 03:33:28PM +, Andy Thompson wrote:
>> >> > I've noticed that trusted users supplementary ad groups don't show
>> >> > up
>> >> until after the users login to the box at least once.
>> >>
>> >> That's expected with the versions you're running. Prior to 6.7, we
>> >> could only read the trusted users' group membership from the PAC blob
>> >> attached to the Kerberos ticket.
>> >>
>> >>
>> >> > Is there a chance that information will be dropped again at any
>> >> > point going
>> >> forward?
>> >>
>> >> No, otherwise it's a bug.
>> >>
>> >> >
>> >> > The reason I ask is that on our sftp boxes we chroot users based on
>> >> > group membership.  I set that up as an external group in freeIPA
>> >> > and the first time the user logs in to the sftp box, they are
>> >> > dropped in their normal home directory as opposed to the chroot
>> >> > environment.  If there is a chance the group membership will not
>> >> > show up correctly again in the future, I'm inclined to change the
>> >> > chroot stanzas to match on
>> >> user as opposed to group.
>> >> >
>> >> > Is that by design?
>> >>
>> >> If you can't see the correct group memberships after a login, then
>> >> something is fishy. However, we're rebasing to sssd 1.12.x in 6.7 and
>> >> there's so many fixes and enhancements in this area..is there a
>> >> chance you could try out 6.7 beta or some custom packages?
>> >>
>> >
>> >Group memberships show up fine after the first login so it is working as
>> expected then.  The accounts are very controlled so it shouldn't be a huge
>> sticking point.  I could try out some custom packages on this box but I can't
>> move to 6.7 until we upgrade the entire environment.
>> >
>> Here you are
>> https://copr.fedoraproject.org/coprs/lslebodn/sssd-1-12-latest/
>> 
>
>To just bring this full circle, the latest sssd release reads group membership 
>correctly without a Kerberos ticket.  I tested this release on 6.6 and tested 
>a 7.1 box and both worked without issue.
>
I'm glad it works for you.

>I just can't roll them in production yet :/
>
I see.

LS

-- 
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] RedHat IDM Replica runs ony dirsrv, kinit and getent fail after reboot

On 05/18/2015 02:17 PM, Sina Owolabi wrote:
> Hi Martin
> 
> And thanks for getting back, greatly appreciated.
> I tore down the replica and reinstalled from scratch, using an old
> replica-info file
> I had on the primary. Im not sure if this is a good thing to do, but I
> would appreciate
> if you could point me to the logs you'd be interested in seeing.
> I had to reinstall the replica without CA before it would complete, too.
> 
> Thanks again for your precious time.

It depends what component you are actually fighting with. There is a separate
log for LDAP server, KDC server, Apache and PKI servers.

Most directions are specific here
http://www.freeipa.org/page/Troubleshooting

We need to know first what specific error you are dealing with right now, to
point you to right direction.

Martin

> 
> On Mon, May 18, 2015 at 10:15 AM, Martin Kosek  wrote:
>> On 05/16/2015 12:19 PM, Sina Owolabi wrote:
>>> Please help me. I am in dire straits, this is the linchpin of our
>>> network and we are suffering.
>>
>> I am sorry for delay in answering, but not many people here show up on the
>> weekend. Comments below.
>>
>>> On Sat, May 16, 2015 at 6:00 AM, Sina Owolabi  wrote:
 Hi!

 I am running an IPA domain with two servers, one is a replica. Red Hat 6.6,
 with the following versions:
 libipa_hbac-1.11.6-30.el6_6.4.x86_64
 ipa-server-selinux-3.0.0-42.el6.x86_64
 libipa_hbac-python-1.11.6-30.el6_6.4.x86_64
 ipa-admintools-3.0.0-42.el6.x86_64
 python-iniparse-0.3.1-2.1.el6.noarch
 ipa-client-3.0.0-42.el6.x86_64
 ipa-pki-common-theme-9.0.3-7.el6.noarch
 device-mapper-multipath-libs-0.4.9-80.el6_6.3.x86_64
 device-mapper-multipath-0.4.9-80.el6_6.3.x86_64
 ipa-server-3.0.0-42.el6.x86_64
 ipa-python-3.0.0-42.el6.x86_64
 ipa-pki-ca-theme-9.0.3-7.el6.noarch
 sssd-ipa-1.11.6-30.el6_6.4.x86_64


 I noticed the replica did not seem to be in sync with the primary IPA
 server, as login requests to ipa clients using the replica for domain
 authentication failed with
 "Too many authentication failures for user UNKNOWN".
 I forced a sync with the primary server and rebooted the replica 
 afterwards.
 Now the replica is back up, but when I run "ipactl status", only
 dirsrv is running:
 # ipactl status
 Directory Service: RUNNING
>>
>> This is strange, try
>>
>> # ipactl restart
>>
>> see which services fail to start and see the logs they produce.
>>
 No other service shows up. I also tried editing /etc/krb5.conf to
 change the [realms] information to point to the primary server, but
 while I can now kinit admin,
 nothing else works.

 Please how can I fix this problem?

 Please what can I do fix this?
>>
>> First things first. You need to first see if all service start and operate
>> properly, if not, we need to see their logs in order to help or advise.
>>
>> 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] Securing IPA Redux

Adding freeipa-users list back, to keep others in the loop.

On 05/18/2015 12:32 PM, Brian Topping wrote:
> Thanks for taking the time to write that, Martin. It's good to have a 
> reference to build from.
> 
> Result of "ida-client-install" outside the firewall with port 636 accessible:

Ah, I mostly just use 636 as a convenience port to show the supported cryptos,
389 is really the port we should be using by default.

Of course, 389 port + STARTTLS environment turned on, to make sure passwords do
not go in clean over the wire.

>> Please make sure the following ports are opened in the firewall settings:
>>  TCP: 80, 88, 389
>>  UDP: 88 (at least one of TCP/UDP ports 88 has to be open)
>> Also note that following ports are necessary for ipa-client working properly 
>> after enrollment:
>>  TCP: 464
>>  UDP: 464, 123 (if NTP enabled)
> 
> No mention of 636, confirmed by tcpdump that it's not trying. Also no option 
> on command line to specify 636.
> 
> Opening up 389 means that some misconfigured client could expose passwords. 
> It's possible to remove null ciphers, but then there's really no reason not 
> to use 636.
> 
> Seems like ipa-client-install should try 636 by default, then fall back to 
> 389 in it's various forms, no?

I think the general direction here was the opposite. To work on the port 389 as
the common denominator, offering both password-less traffic and encrypted
traffic. I am not sure if there were other reasons too, I would let Rob or
Ludwig reply here if they know.

Martin

>> On May 18, 2015, at 4:10 PM, Martin Kosek  wrote:
>>
>> On 05/15/2015 01:33 PM, Brian Topping wrote:
>>> In the (apparently) first message to the list in 2014, 
>>> https://www.redhat.com/archives/freeipa-users/2014-January/msg0.html 
>>>  
>>> addressed questions about securing IPA and I don't see much other talk 
>>> about it. Now that 4.x is prevalent, I wanted to bring it up again.
>>
>> This is the default by design. However, note that in FreeIPA 4.0+ you can
>> change that default (permission-mod) and let users or some of the user
>> attributes be only shown for authenticated users.
>>
>> https://www.freeipa.org/page/V4/Permissions_V2
>>
>> So, from my POV, this is not a flaw.
>>
>>> I'd like my installation to be allow hardened machines (i.e. in the cloud 
>>> with encrypted filesystems) to be a part of the domain. I believe this 
>>> means that I need to expose Kerberos and LDAP to the world, since the 
>>> machines could live anywhere. I don't believe I need to worry about KRB5, 
>>> but I am concerned about 389-DS since it seems somewhat difficult to force 
>>> TLS (https://blog.routedlogic.net/?p=119 
>>> ) and maybe that's a bad idea under 
>>> IPA for reasons I thought I'd ask here about. Last year's thread also 
>>> referenced 
>>> https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/disabling-anon-binds.html
>>>  
>>> 
>>>  and I thought I would check to see if that's still necessary under 4.x.
>>
>> 389-DS and TLS should be also fixed, since FreeIPA 4.1 (RHEL/CentOS 7.1):
>>
>> https://fedorahosted.org/freeipa/ticket/4653
>>
>> This is an nmap test against the FreeIPA public demo (4.1.x):
>>
>> $ nmap --script ssl-enum-ciphers -p 636 ipa.demo1.freeipa.org
>>
>> Starting Nmap 6.47 ( http://nmap.org ) at 2015-05-18 11:08 CEST
>> Nmap scan report for ipa.demo1.freeipa.org (209.132.178.99)
>> Host is up (0.19s latency).
>> PORTSTATE SERVICE
>> 636/tcp open  ldapssl
>> | ssl-enum-ciphers:
>> |   TLSv1.2:
>> | ciphers:
>> |   TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
>> |   TLS_RSA_WITH_AES_128_CBC_SHA - strong
>> |   TLS_RSA_WITH_AES_128_CBC_SHA256 - strong
>> |   TLS_RSA_WITH_AES_128_GCM_SHA256 - strong
>> |   TLS_RSA_WITH_AES_256_CBC_SHA - strong
>> |   TLS_RSA_WITH_AES_256_CBC_SHA256 - strong
>> |   TLS_RSA_WITH_RC4_128_MD5 - strong
>> |   TLS_RSA_WITH_RC4_128_SHA - strong
>> | compressors:
>> |   NULL
>> |_  least strength: strong
>>
>> Nmap done: 1 IP address (1 host up) scanned in 6.19 seconds
>>
>>> Setting up the firewall to allow cloud networks in is always an option, but 
>>> if I can get a secure IPA setup going, it would also allow road warriors to 
>>> kinit and use their credentials for configured intranet sites without 
>>> having to turn on the VPN (which can really slow things down from remote 
>>> parts of the globe).
>>
>> BTW, if you are concerned about exposed Kerberos traffic, FreeIPA 4.2 plans 
>> to
>> offer Kerberos-over-HTTP functionality by default:
>> https://fedorahosted.org/freeipa/ticket/4801
>>
>> Even now, it can be manually configured. This is what GNOME used:
>> https://www.dragonsreach.it/2014/10/07/the-gnome-infrastructure-is-now-powered-by-freeipa/
>>
>> So, if I am reading my notes co

Re: [Freeipa-users] interesting Kerberos issue

2015-05-18 Thread Alexander Bokovoy


On Mon, 18 May 2015, Nathaniel McCallum wrote:

On Mon, 2015-05-18 at 17:18 +0300, Alexander Bokovoy wrote:

On Mon, 18 May 2015, Nathaniel McCallum wrote:
> On Mon, 2015-05-18 at 17:03 +0300, Alexander Bokovoy wrote:
> > On Mon, 18 May 2015, Janelle wrote:
> > > On 5/10/15 11:57 PM, Alexander Bokovoy wrote:
> > > > On Sun, 10 May 2015, Janelle wrote:
> > > > > On 5/5/15 6:47 AM, Dmitri Pal wrote:
> > > > > > On 05/04/2015 09:38 PM, Janelle wrote:
> > > > > > > On 5/4/15 6:06 PM, Nathaniel McCallum wrote:
> > > > > > > > On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote:
> > > > > > > > > Happy Star Wars Day!
> > > > > > > > > May the Fourth be with you!
> > > > > > > > >
> > > > > > > > > So I have a strange Kerberos problem trying to
> > > > > > > > > figure
> > > > > > > > > out. On a
> > > > > > > > > CLIENT,  (CentOS 7.1) if I login to account "usera"
> > > > > > > > > they get a
> > > > > > > > > ticket as
> > > > > > > > > expected.  However, if I login to a 6.6 client, it
> > > > > > > > > doesn't seem to
> > > > > > > > > work.
> > > > > > > > > Both were enrolled the same, obviously one is
> > > > > > > > > newer.
> > > > > > > > >
> > > > > > > > > Now, it gets stranger. The "servers" are CentOS 7.1
> > > > > > > > > also. If I login
> > > > > > > > > as
> > > > > > > > > root, bypassing kerberos, and then do "kinit admin"
> > > > > > > > > it
> > > > > > > > > works just
> > > > > > > > > fine.
> > > > > > > > > But if I do "kinit usera" I get:
> > > > > > > > >
> > > > > > > > > kinit: Generic preauthentication failure while
> > > > > > > > > getting
> > > > > > > > > initial
> > > > > > > > > credentials
> > > > > > > > >
> > > > > > > > > Which makes no sense. The account works with a 7.1
> > > > > > > > > client but not a
> > > > > > > > > 6.x
> > > > > > > > > client?? And yet "admin" works, no matter what.
> > > > > > > > > What am
> > > > > > > > > I missing
> > > > > > > > > here?
> > > > > > > > If I had to guess, usera is enabled for OTP-only
> > > > > > > > login.
> > > > > > > > Is that
> > > > > > > > correct?
> > > > > > > >
> > > > > > > > If so, clients require RHEL 7.1 for OTP support.
> > > > > > > > Also,
> > > > > > > > the error you
> > > > > > > > are getting is the result of not enabling FAST
> > > > > > > > support
> > > > > > > > for OTP
> > > > > > > > authentication (see the -T option).
> > > > > > > >
> > > > > > > > Nathaniel
> > > > > > > Ok, this did give me an idea (Thanks Nathaniel)  -- the
> > > > > > > account was set for BOTH "password" and OTP.
> > > > > > > Apparently setting both does nothing. Yes a user can
> > > > > > > login
> > > > > > > with their password-only, but trying to use kinit does
> > > > > > > not
> > > > > > > work.
> > > > > > >
> > > > > > > I am not sure I understand where the FAST support or
> > > > > > > the -T
> > > > > > >
> > > > > > > option is to be applied. On kinit? That does not seem
> > > > > > > correct.
> > > > > > > Perhaps I am misunderstanding this option?
> > > > > > >
> > > > > > > ~J
> > > > > > >
> > > > > > If the user is enabled for OTP his credential are sent
> > > > > > differently than in the case when it is not enabled.
> > > > > > Effectively
> > > > > > instead of using encrypted timestamp the password and OTP
> > > > > > are
> > > > > >
> > > > > > sent to the server as data. But they can't be sent in
> > > > > > clear.
> > > > > > You
> > > > > > need to encrypt the data. To encrypt it you need another
> > > > > > key
> > > > > > -
> > > > > > the host key. The encryption of the data in this context
> > > > > > is
> > > > > > called tunneling . FAST is the Kerberos protocol feature
> > > > > > to
> > > > > > provide tunneling of the data sent over the wire. To use
> > > > > > FAST
> > > > > >
> > > > > > one needs to use -T on the kinit command line.
> > > > > > Does this help?
> > > > > >
> > > > > It helps -- thank you.
> > > > >
> > > > > Now allow me to add a little more fun, and there may not be
> > > > > a
> > > > > solution.
> > > > > > From OS X (Yosemite) I am able to "kinit --kdc
> > > > > > -hostname=IPA
> > > > > > -server
> > > > > principal" and it works, gives me a ticket, and if I
> > > > > attempt to
> > > > >
> > > > > login to the web interface, since I already have my ticket
> > > > > -
> > > > > boom,
> > > > > works fine.
> > > > >
> > > > > Now, I enable 2FA and setup a token and change my account
> > > > > to
> > > > > OTP
> > > > > (with TOTP).  But as previously discussed, can't seem to
> > > > > specify a
> > > > > -T option from OS X.
> > > > >
> > > > > I know this sounds tricky -- Any ideas?
> > > > Use
> > > > kinit --fast-armor-cache /path/to/ccache to specify already
> > > > existing ccache to armor the FAST processing.
> > > >
> > > > This is Heimdal-specific, and you should have Heimdal 1.6rc2
> > > > at
> > > > least.
> > > > You can check version number by running 'kinit --version'.
> > > Aha, so thee default on OS X Yosemite is
> > >
> > > $ kinit --version
> > > kinit

Re: [Freeipa-users] interesting Kerberos issue

On Mon, 2015-05-18 at 17:18 +0300, Alexander Bokovoy wrote:
> On Mon, 18 May 2015, Nathaniel McCallum wrote:
> > On Mon, 2015-05-18 at 17:03 +0300, Alexander Bokovoy wrote:
> > > On Mon, 18 May 2015, Janelle wrote:
> > > > On 5/10/15 11:57 PM, Alexander Bokovoy wrote:
> > > > > On Sun, 10 May 2015, Janelle wrote:
> > > > > > On 5/5/15 6:47 AM, Dmitri Pal wrote:
> > > > > > > On 05/04/2015 09:38 PM, Janelle wrote:
> > > > > > > > On 5/4/15 6:06 PM, Nathaniel McCallum wrote:
> > > > > > > > > On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote:
> > > > > > > > > > Happy Star Wars Day!
> > > > > > > > > > May the Fourth be with you!
> > > > > > > > > > 
> > > > > > > > > > So I have a strange Kerberos problem trying to 
> > > > > > > > > > figure
> > > > > > > > > > out. On a
> > > > > > > > > > CLIENT,  (CentOS 7.1) if I login to account "usera"
> > > > > > > > > > they get a
> > > > > > > > > > ticket as
> > > > > > > > > > expected.  However, if I login to a 6.6 client, it
> > > > > > > > > > doesn't seem to
> > > > > > > > > > work.
> > > > > > > > > > Both were enrolled the same, obviously one is 
> > > > > > > > > > newer.
> > > > > > > > > > 
> > > > > > > > > > Now, it gets stranger. The "servers" are CentOS 7.1
> > > > > > > > > > also. If I login
> > > > > > > > > > as
> > > > > > > > > > root, bypassing kerberos, and then do "kinit admin" 
> > > > > > > > > > it
> > > > > > > > > > works just
> > > > > > > > > > fine.
> > > > > > > > > > But if I do "kinit usera" I get:
> > > > > > > > > > 
> > > > > > > > > > kinit: Generic preauthentication failure while 
> > > > > > > > > > getting
> > > > > > > > > > initial
> > > > > > > > > > credentials
> > > > > > > > > > 
> > > > > > > > > > Which makes no sense. The account works with a 7.1
> > > > > > > > > > client but not a
> > > > > > > > > > 6.x
> > > > > > > > > > client?? And yet "admin" works, no matter what. 
> > > > > > > > > > What am
> > > > > > > > > > I missing
> > > > > > > > > > here?
> > > > > > > > > If I had to guess, usera is enabled for OTP-only 
> > > > > > > > > login.
> > > > > > > > > Is that
> > > > > > > > > correct?
> > > > > > > > > 
> > > > > > > > > If so, clients require RHEL 7.1 for OTP support. 
> > > > > > > > > Also,
> > > > > > > > > the error you
> > > > > > > > > are getting is the result of not enabling FAST 
> > > > > > > > > support
> > > > > > > > > for OTP
> > > > > > > > > authentication (see the -T option).
> > > > > > > > > 
> > > > > > > > > Nathaniel
> > > > > > > > Ok, this did give me an idea (Thanks Nathaniel)  -- the
> > > > > > > > account was set for BOTH "password" and OTP.
> > > > > > > > Apparently setting both does nothing. Yes a user can 
> > > > > > > > login
> > > > > > > > with their password-only, but trying to use kinit does 
> > > > > > > > not
> > > > > > > > work.
> > > > > > > > 
> > > > > > > > I am not sure I understand where the FAST support or 
> > > > > > > > the -T
> > > > > > > > 
> > > > > > > > option is to be applied. On kinit? That does not seem
> > > > > > > > correct.
> > > > > > > > Perhaps I am misunderstanding this option?
> > > > > > > > 
> > > > > > > > ~J
> > > > > > > > 
> > > > > > > If the user is enabled for OTP his credential are sent
> > > > > > > differently than in the case when it is not enabled.
> > > > > > > Effectively
> > > > > > > instead of using encrypted timestamp the password and OTP 
> > > > > > > are
> > > > > > > 
> > > > > > > sent to the server as data. But they can't be sent in 
> > > > > > > clear.
> > > > > > > You
> > > > > > > need to encrypt the data. To encrypt it you need another 
> > > > > > > key
> > > > > > > -
> > > > > > > the host key. The encryption of the data in this context 
> > > > > > > is
> > > > > > > called tunneling . FAST is the Kerberos protocol feature 
> > > > > > > to
> > > > > > > provide tunneling of the data sent over the wire. To use 
> > > > > > > FAST
> > > > > > > 
> > > > > > > one needs to use -T on the kinit command line.
> > > > > > > Does this help?
> > > > > > > 
> > > > > > It helps -- thank you.
> > > > > > 
> > > > > > Now allow me to add a little more fun, and there may not be 
> > > > > > a
> > > > > > solution.
> > > > > > > From OS X (Yosemite) I am able to "kinit --kdc
> > > > > > > -hostname=IPA
> > > > > > > -server
> > > > > > principal" and it works, gives me a ticket, and if I 
> > > > > > attempt to
> > > > > > 
> > > > > > login to the web interface, since I already have my ticket 
> > > > > > -
> > > > > > boom,
> > > > > > works fine.
> > > > > > 
> > > > > > Now, I enable 2FA and setup a token and change my account 
> > > > > > to
> > > > > > OTP
> > > > > > (with TOTP).  But as previously discussed, can't seem to
> > > > > > specify a
> > > > > > -T option from OS X.
> > > > > > 
> > > > > > I know this sounds tricky -- Any ideas?
> > > > > Use
> > > > > kinit --fast-armor-cache /path/to/ccache to specify already
> > > > > existing ccache to armor the FAST processing.
> > > > > 
> > > > >

Re: [Freeipa-users] Replication Update in progress : FALSE LDAP ERROR

2015-05-18 Thread Rich Megginson


On 05/16/2015 04:06 PM, Nathan Peters wrote:

I have updated the bug report you filed below.

The issue was that the instructions would only work in Windows Server 
2003 because My Network Places was removed in 2008 and above.  Since 
the manual clearly states that the AD sync is to be performed with 
server 2008 / 2012 only it made no sense to give instructions for an 
incompatible version of windows.


I have added to the ticket 2 methods to get the *correct* certificate 
that will work in both server 2008 r2 and server 2012 r2.


I am cc'd on the bug and have seen all of the information you added.  
Thanks!




On 05/15/2015 03:09 PM, nat...@nathanpeters.com wrote:

On 05/14/2015 11:33 PM, nat...@nathanpeters.com wrote:

[root@ipadc1 cacerts]# ipa-replica-manage connect --winsync --binddn
"cn=ad sync,cn=Users,dc=test,dc=mycompany,dc=net" --bindpw
supersecretpassword --passsync supersecretpassword --cacert
/etc/openldap/cacerts/addc2-test.cer addc2.test.mycompany.net -v
Directory Manager password:

Added CA certificate /etc/openldap/cacerts/addc2-test.cer to
certificate
database for ipadc1.ipadomain.net
ipa: INFO: AD Suffix is: DC=test,DC=mycompany,DC=net
The user for the Windows PassSync service is
uid=passsync,cn=sysaccounts,cn=etc,dc=ipadomain,dc=net
Windows PassSync system account exists, not resetting password
ipa: INFO: Added new sync agreement, waiting for it to become 
ready .

.
.
ipa: INFO: Replication Update in progress: FALSE: status: -11  - 
LDAP

error: Connect error: start: 0: end: 0
ipa: INFO: Agreement is ready, starting replication . . .
Starting replication, please wait until this has completed.

[ipadc1.ipadomain.net] reports: Update failed! Status: [-11  - LDAP
error:
Connect error]

Have you tried using ldapsearch to verify the connection?

# LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-DOMAIN-COM ldapsearch -xLLL -ZZ
-h
addc2.test.mycompany.net -D "cn=ad
sync,cn=Users,dc=test,dc=mycompany,dc=net" -w
"supersecretpassword" -s base -b 
"cn=Users,dc=test,dc=mycompany,dc=net"

"objectclass=*"

and/or

# LDAPTLS_CACERT=/etc/openldap/cacerts/addc2-test.cer ldapsearch 
-xLLL

-ZZ -h addc2.test.mycompany.net -D "cn=ad
sync,cn=Users,dc=test,dc=mycompany,dc=net" -w
"supersecretpassword" -s base -b 
"cn=Users,dc=test,dc=mycompany,dc=net"

"objectclass=*"


Both commands give the same successful result.  I don't think it's a
problem with the credentials because I was able to generate different
error messages during the attempted sync setup if I intentionally 
gave a

bad password or username.

Ok.  Have you tried enabling the replication log level?

http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting

Ok, that helped a lot.  I got this fixed now.  Because the manual tells
you to export the cert using a way that doesn't work on newer 
versions of

windows, I tried to improvise and my first attempt exported the wrong
cert.

The correct way is to go to mmc.exe and add the certificates snap-in.
Then go to personal certificates store for the machine account and 
export

the one that has -CA at the end of it in the issued to column.

Now that the correct certificate was exported, replication 
succeeded.  The

docs should be updated though to reflect the proper way to export.


https://bugzilla.redhat.com/show_bug.cgi?id=1222161

Please add yourself to the bug and provide any additional information.


--
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] interesting Kerberos issue

2015-05-18 Thread Alexander Bokovoy


On Mon, 18 May 2015, Nathaniel McCallum wrote:

On Mon, 2015-05-18 at 17:03 +0300, Alexander Bokovoy wrote:

On Mon, 18 May 2015, Janelle wrote:
> On 5/10/15 11:57 PM, Alexander Bokovoy wrote:
> > On Sun, 10 May 2015, Janelle wrote:
> > > On 5/5/15 6:47 AM, Dmitri Pal wrote:
> > > > On 05/04/2015 09:38 PM, Janelle wrote:
> > > > > On 5/4/15 6:06 PM, Nathaniel McCallum wrote:
> > > > > > On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote:
> > > > > > > Happy Star Wars Day!
> > > > > > > May the Fourth be with you!
> > > > > > >
> > > > > > > So I have a strange Kerberos problem trying to figure
> > > > > > > out. On a
> > > > > > > CLIENT,  (CentOS 7.1) if I login to account "usera"
> > > > > > > they get a
> > > > > > > ticket as
> > > > > > > expected.  However, if I login to a 6.6 client, it
> > > > > > > doesn't seem to
> > > > > > > work.
> > > > > > > Both were enrolled the same, obviously one is newer.
> > > > > > >
> > > > > > > Now, it gets stranger. The "servers" are CentOS 7.1
> > > > > > > also. If I login
> > > > > > > as
> > > > > > > root, bypassing kerberos, and then do "kinit admin" it
> > > > > > > works just
> > > > > > > fine.
> > > > > > > But if I do "kinit usera" I get:
> > > > > > >
> > > > > > > kinit: Generic preauthentication failure while getting
> > > > > > > initial
> > > > > > > credentials
> > > > > > >
> > > > > > > Which makes no sense. The account works with a 7.1
> > > > > > > client but not a
> > > > > > > 6.x
> > > > > > > client?? And yet "admin" works, no matter what. What am
> > > > > > > I missing
> > > > > > > here?
> > > > > > If I had to guess, usera is enabled for OTP-only login.
> > > > > > Is that
> > > > > > correct?
> > > > > >
> > > > > > If so, clients require RHEL 7.1 for OTP support. Also,
> > > > > > the error you
> > > > > > are getting is the result of not enabling FAST support
> > > > > > for OTP
> > > > > > authentication (see the -T option).
> > > > > >
> > > > > > Nathaniel
> > > > > Ok, this did give me an idea (Thanks Nathaniel)  -- the
> > > > > account was set for BOTH "password" and OTP.
> > > > > Apparently setting both does nothing. Yes a user can login
> > > > > with their password-only, but trying to use kinit does not
> > > > > work.
> > > > >
> > > > > I am not sure I understand where the FAST support or the -T
> > > > >
> > > > > option is to be applied. On kinit? That does not seem
> > > > > correct.
> > > > > Perhaps I am misunderstanding this option?
> > > > >
> > > > > ~J
> > > > >
> > > > If the user is enabled for OTP his credential are sent
> > > > differently than in the case when it is not enabled.
> > > > Effectively
> > > > instead of using encrypted timestamp the password and OTP are
> > > >
> > > > sent to the server as data. But they can't be sent in clear.
> > > > You
> > > > need to encrypt the data. To encrypt it you need another key
> > > > -
> > > > the host key. The encryption of the data in this context is
> > > > called tunneling . FAST is the Kerberos protocol feature to
> > > > provide tunneling of the data sent over the wire. To use FAST
> > > >
> > > > one needs to use -T on the kinit command line.
> > > > Does this help?
> > > >
> > > It helps -- thank you.
> > >
> > > Now allow me to add a little more fun, and there may not be a
> > > solution.
> > > > From OS X (Yosemite) I am able to "kinit --kdc-hostname=IPA
> > > > -server
> > > principal" and it works, gives me a ticket, and if I attempt to
> > >
> > > login to the web interface, since I already have my ticket -
> > > boom,
> > > works fine.
> > >
> > > Now, I enable 2FA and setup a token and change my account to
> > > OTP
> > > (with TOTP).  But as previously discussed, can't seem to
> > > specify a
> > > -T option from OS X.
> > >
> > > I know this sounds tricky -- Any ideas?
> > Use
> > kinit --fast-armor-cache /path/to/ccache to specify already
> > existing ccache to armor the FAST processing.
> >
> > This is Heimdal-specific, and you should have Heimdal 1.6rc2 at
> > least.
> > You can check version number by running 'kinit --version'.
> Aha, so thee default on OS X Yosemite is
>
> $ kinit --version
> kinit (Heimdal 1.5.1apple1)
>
> so this won't work?
Yes, you have to have the feature in your Kerberos library.


Browsing the Heimdal source code, I don't even see any support for OTP
at all. :(

The support is since 1.6rc2, it uses the Richards' draft
(draft-richards-otp-kerberos-01.txt) as a base and handles preauth but I
don't think anything but login and ftpd supports passing the OTP token.
--
/ 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

Re: [Freeipa-users] AD-trust and external DNS

2015-05-18 Thread Baird, Josh

You should add your IPA zone as a slave on your 'external' DNS servers so they 
are able to resolve the IPA zone.

Josh

From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Winfried de Heiden
Sent: Monday, May 18, 2015 10:10 AM
To: Freeipa-users
Subject: [Freeipa-users] AD-trust and external DNS

Hi all,

Creating an AD-trust works nicely. However, for some customers both AD and IPA 
don't have have DNS "for their own", the use external DNS (Infoblox for example)

Now, is is possible to create an AD trust without a build-in (bind) IPA-DNS?

Thankz!

Winfried

-- 
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] AD-trust and external DNS

2015-05-18 Thread Winfried de Heiden


  
  
Hi all,
  
  Creating an AD-trust works nicely. However, for some customers
  both AD and IPA don't have have DNS "for their own", the use
  external DNS (Infoblox for example)
  
  Now, is is possible to create an AD trust without a build-in
  (bind) IPA-DNS?
  
  Thankz!
  
  Winfried
   

  


-- 
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] interesting Kerberos issue

On Mon, 2015-05-18 at 17:03 +0300, Alexander Bokovoy wrote:
> On Mon, 18 May 2015, Janelle wrote:
> > On 5/10/15 11:57 PM, Alexander Bokovoy wrote:
> > > On Sun, 10 May 2015, Janelle wrote:
> > > > On 5/5/15 6:47 AM, Dmitri Pal wrote:
> > > > > On 05/04/2015 09:38 PM, Janelle wrote:
> > > > > > On 5/4/15 6:06 PM, Nathaniel McCallum wrote:
> > > > > > > On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote:
> > > > > > > > Happy Star Wars Day!
> > > > > > > > May the Fourth be with you!
> > > > > > > > 
> > > > > > > > So I have a strange Kerberos problem trying to figure 
> > > > > > > > out. On a
> > > > > > > > CLIENT,  (CentOS 7.1) if I login to account "usera" 
> > > > > > > > they get a
> > > > > > > > ticket as
> > > > > > > > expected.  However, if I login to a 6.6 client, it 
> > > > > > > > doesn't seem to
> > > > > > > > work.
> > > > > > > > Both were enrolled the same, obviously one is newer.
> > > > > > > > 
> > > > > > > > Now, it gets stranger. The "servers" are CentOS 7.1 
> > > > > > > > also. If I login
> > > > > > > > as
> > > > > > > > root, bypassing kerberos, and then do "kinit admin" it 
> > > > > > > > works just
> > > > > > > > fine.
> > > > > > > > But if I do "kinit usera" I get:
> > > > > > > > 
> > > > > > > > kinit: Generic preauthentication failure while getting 
> > > > > > > > initial
> > > > > > > > credentials
> > > > > > > > 
> > > > > > > > Which makes no sense. The account works with a 7.1 
> > > > > > > > client but not a
> > > > > > > > 6.x
> > > > > > > > client?? And yet "admin" works, no matter what. What am 
> > > > > > > > I missing
> > > > > > > > here?
> > > > > > > If I had to guess, usera is enabled for OTP-only login. 
> > > > > > > Is that
> > > > > > > correct?
> > > > > > > 
> > > > > > > If so, clients require RHEL 7.1 for OTP support. Also, 
> > > > > > > the error you
> > > > > > > are getting is the result of not enabling FAST support 
> > > > > > > for OTP
> > > > > > > authentication (see the -T option).
> > > > > > > 
> > > > > > > Nathaniel
> > > > > > Ok, this did give me an idea (Thanks Nathaniel)  -- the 
> > > > > > account was set for BOTH "password" and OTP.
> > > > > > Apparently setting both does nothing. Yes a user can login 
> > > > > > with their password-only, but trying to use kinit does not 
> > > > > > work.
> > > > > > 
> > > > > > I am not sure I understand where the FAST support or the -T 
> > > > > > 
> > > > > > option is to be applied. On kinit? That does not seem 
> > > > > > correct. 
> > > > > > Perhaps I am misunderstanding this option?
> > > > > > 
> > > > > > ~J
> > > > > > 
> > > > > If the user is enabled for OTP his credential are sent 
> > > > > differently than in the case when it is not enabled. 
> > > > > Effectively 
> > > > > instead of using encrypted timestamp the password and OTP are 
> > > > > 
> > > > > sent to the server as data. But they can't be sent in clear. 
> > > > > You 
> > > > > need to encrypt the data. To encrypt it you need another key 
> > > > > - 
> > > > > the host key. The encryption of the data in this context is 
> > > > > called tunneling . FAST is the Kerberos protocol feature to 
> > > > > provide tunneling of the data sent over the wire. To use FAST 
> > > > > 
> > > > > one needs to use -T on the kinit command line.
> > > > > Does this help?
> > > > > 
> > > > It helps -- thank you.
> > > > 
> > > > Now allow me to add a little more fun, and there may not be a 
> > > > solution.
> > > > > From OS X (Yosemite) I am able to "kinit --kdc-hostname=IPA
> > > > > -server
> > > > principal" and it works, gives me a ticket, and if I attempt to 
> > > > 
> > > > login to the web interface, since I already have my ticket - 
> > > > boom, 
> > > > works fine.
> > > > 
> > > > Now, I enable 2FA and setup a token and change my account to 
> > > > OTP 
> > > > (with TOTP).  But as previously discussed, can't seem to 
> > > > specify a 
> > > > -T option from OS X.
> > > > 
> > > > I know this sounds tricky -- Any ideas?
> > > Use
> > > kinit --fast-armor-cache /path/to/ccache to specify already 
> > > existing ccache to armor the FAST processing.
> > > 
> > > This is Heimdal-specific, and you should have Heimdal 1.6rc2 at 
> > > least.
> > > You can check version number by running 'kinit --version'.
> > Aha, so thee default on OS X Yosemite is
> > 
> > $ kinit --version
> > kinit (Heimdal 1.5.1apple1)
> > 
> > so this won't work?
> Yes, you have to have the feature in your Kerberos library.

Browsing the Heimdal source code, I don't even see any support for OTP
at all. :(

Nathaniel

-- 
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] Certificate operation cannot be completed: Unable to communicate with CMS (Not Found)


Sina Owolabi wrote:

Yes CA is running,  and it's on the same machine.

[root@dc ~]# ipa-replica-prepare dc01.ourdom.com
 --ip-address 192.168.2.40

Directory Manager (existing master) password:


Preparing replica for dc01.ourdom.com  from
dc.ourdom.com 

Creating SSL certificate for the Directory Server

Certificate operation cannot be completed: Unable to communicate with
CMS (Not Found)

[root@dc ~]# ipactl status

Directory Service: RUNNING

KDC Service: RUNNING

KPASSWD Service: RUNNING

DNS Service: RUNNING

MEMCACHE Service: RUNNING

HTTP Service: RUNNING

CA Service: RUNNING

[root@dc ~]#


This suggests that while the process is running the CA isn't actually 
operational. You'll need to poke through the logs in /var/log/pki* to 
see if there are any errors.


I'd also see if the certificates are expired by running `getcert list` 
as root.


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] interesting Kerberos issue

2015-05-18 Thread Alexander Bokovoy


On Mon, 18 May 2015, Janelle wrote:

On 5/10/15 11:57 PM, Alexander Bokovoy wrote:

On Sun, 10 May 2015, Janelle wrote:

On 5/5/15 6:47 AM, Dmitri Pal wrote:

On 05/04/2015 09:38 PM, Janelle wrote:

On 5/4/15 6:06 PM, Nathaniel McCallum wrote:

On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote:

Happy Star Wars Day!
May the Fourth be with you!

So I have a strange Kerberos problem trying to figure out. On a
CLIENT,  (CentOS 7.1) if I login to account "usera" they get a
ticket as
expected.  However, if I login to a 6.6 client, it doesn't seem to
work.
Both were enrolled the same, obviously one is newer.

Now, it gets stranger. The "servers" are CentOS 7.1 also. If I login
as
root, bypassing kerberos, and then do "kinit admin" it works just
fine.
But if I do "kinit usera" I get:

kinit: Generic preauthentication failure while getting initial
credentials

Which makes no sense. The account works with a 7.1 client but not a
6.x
client?? And yet "admin" works, no matter what. What am I missing
here?

If I had to guess, usera is enabled for OTP-only login. Is that
correct?

If so, clients require RHEL 7.1 for OTP support. Also, the error you
are getting is the result of not enabling FAST support for OTP
authentication (see the -T option).

Nathaniel
Ok, this did give me an idea (Thanks Nathaniel)  -- the 
account was set for BOTH "password" and OTP.
Apparently setting both does nothing. Yes a user can login 
with their password-only, but trying to use kinit does not 
work.


I am not sure I understand where the FAST support or the -T 
option is to be applied. On kinit? That does not seem correct. 
Perhaps I am misunderstanding this option?


~J

If the user is enabled for OTP his credential are sent 
differently than in the case when it is not enabled. Effectively 
instead of using encrypted timestamp the password and OTP are 
sent to the server as data. But they can't be sent in clear. You 
need to encrypt the data. To encrypt it you need another key - 
the host key. The encryption of the data in this context is 
called tunneling . FAST is the Kerberos protocol feature to 
provide tunneling of the data sent over the wire. To use FAST 
one needs to use -T on the kinit command line.

Does this help?


It helps -- thank you.

Now allow me to add a little more fun, and there may not be a solution.

From OS X (Yosemite) I am able to "kinit --kdc-hostname=IPA-server
principal" and it works, gives me a ticket, and if I attempt to 
login to the web interface, since I already have my ticket - boom, 
works fine.


Now, I enable 2FA and setup a token and change my account to OTP 
(with TOTP).  But as previously discussed, can't seem to specify a 
-T option from OS X.


I know this sounds tricky -- Any ideas?

Use
kinit --fast-armor-cache /path/to/ccache to specify already 
existing ccache to armor the FAST processing.


This is Heimdal-specific, and you should have Heimdal 1.6rc2 at least.
You can check version number by running 'kinit --version'.

Aha, so thee default on OS X Yosemite is

$ kinit --version
kinit (Heimdal 1.5.1apple1)

so this won't work?

Yes, you have to have the feature in your Kerberos library.

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

Re: [Freeipa-users] LDAP uid to cn modify


Vangass wrote:

Hi,

I try to set FreeIPA as a LDAP server for HP iLO authentication. iLO
client sends dn as "cn=bartosz,cn=users,cn=accounts,dc=example,dc=com"
but in FreeIPA there is no cn=bartosz just uid=bartosz (as for any other
user I create is uid). Is it possible to modify uid to cn or is there
any other option?

Thanks,
Bartosz Witkowski




Others have had the same issue, 
https://www.redhat.com/archives/freeipa-users/2014-January/msg00180.html


If you are running EL 7+ you should be able to create a compat 
configuration to make it work but it isn't clear if anyone has done this 
work on IPA 3.3+ or not yet (IIRC the users in this thread were all 
still on RHEL 6).


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] trusted user groups

2015-05-18 Thread Andy Thompson

> -Original Message-
> From: Lukas Slebodnik [mailto:lsleb...@redhat.com]
> Sent: Thursday, May 14, 2015 4:41 PM
> To: Andy Thompson
> Cc: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] trusted user groups
> 
> On (14/05/15 15:53), Andy Thompson wrote:
> >> -Original Message-
> >> From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
> >> boun...@redhat.com] On Behalf Of Jakub Hrozek
> >> Sent: Thursday, May 14, 2015 11:46 AM
> >> To: freeipa-users@redhat.com
> >> Subject: Re: [Freeipa-users] trusted user groups
> >>
> >> On Thu, May 14, 2015 at 03:33:28PM +, Andy Thompson wrote:
> >> > I've noticed that trusted users supplementary ad groups don't show
> >> > up
> >> until after the users login to the box at least once.
> >>
> >> That's expected with the versions you're running. Prior to 6.7, we
> >> could only read the trusted users' group membership from the PAC blob
> >> attached to the Kerberos ticket.
> >>
> >>
> >> > Is there a chance that information will be dropped again at any
> >> > point going
> >> forward?
> >>
> >> No, otherwise it's a bug.
> >>
> >> >
> >> > The reason I ask is that on our sftp boxes we chroot users based on
> >> > group membership.  I set that up as an external group in freeIPA
> >> > and the first time the user logs in to the sftp box, they are
> >> > dropped in their normal home directory as opposed to the chroot
> >> > environment.  If there is a chance the group membership will not
> >> > show up correctly again in the future, I'm inclined to change the
> >> > chroot stanzas to match on
> >> user as opposed to group.
> >> >
> >> > Is that by design?
> >>
> >> If you can't see the correct group memberships after a login, then
> >> something is fishy. However, we're rebasing to sssd 1.12.x in 6.7 and
> >> there's so many fixes and enhancements in this area..is there a
> >> chance you could try out 6.7 beta or some custom packages?
> >>
> >
> >Group memberships show up fine after the first login so it is working as
> expected then.  The accounts are very controlled so it shouldn't be a huge
> sticking point.  I could try out some custom packages on this box but I can't
> move to 6.7 until we upgrade the entire environment.
> >
> Here you are
> https://copr.fedoraproject.org/coprs/lslebodn/sssd-1-12-latest/
> 

To just bring this full circle, the latest sssd release reads group membership 
correctly without a Kerberos ticket.  I tested this release on 6.6 and tested a 
7.1 box and both worked without issue.

I just can't roll them in production yet :/
 
Thanks

-andy





-- 
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] LDAP uid to cn modify

2015-05-18 Thread Vangass

Hi,

I try to set FreeIPA as a LDAP server for HP iLO authentication. iLO client
sends dn as "cn=bartosz,cn=users,cn=accounts,dc=example,dc=com" but in
FreeIPA there is no cn=bartosz just uid=bartosz (as for any other user I
create is uid). Is it possible to modify uid to cn or is there any other
option?

Thanks,
Bartosz Witkowski
-- 
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] host usercertificate attribute


Natxo Asenjo wrote:

On Sat, May 16, 2015 at 10:24 PM, Natxo Asenjo mailto:natxo.ase...@gmail.com>> wrote:

hi,

If I retrieve the usercertificate attribute for host objects I get
some gibberish.

How can I decode the info I get from ldapsearch?


maybe there is a way to feed that to openssl. What I ended up doing was
using Perl and Crypt::X509 and I can see all the certificate elements.


They are DER-encoded files. Something like this will show the contents:

$ openssl x509 -text -in /tmp/file

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] 4.1.4 and OTP

On Mon, 2015-05-18 at 07:59 -0500, Janelle wrote:
> > 
> > On May 18, 2015, at 04:31, Martin Kosek  wrote:
> > 
> > > On 05/18/2015 01:49 AM, Janelle wrote:
> > > > On 4/28/15 6:44 AM, Nathaniel McCallum wrote:
> > > > > On Fri, 2015-04-17 at 20:21 -0700, Janelle wrote:
> > > > > > On 4/17/15 5:59 PM, Dmitri Pal wrote:
> > > > > > > On 04/17/2015 08:07 PM, Janelle wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > On Apr 17, 2015, at 16:36, Dmitri Pal  
> > > > > > > wrote:
> > > > > > > 
> > >  for shorter thread
> > > > > > > Simple. And my test made it simple.
> > > > > > > Stand up new vm running fc21/freeipa.
> > > > > > > Configure user.
> > > > > > > Add password.
> > > > > > > Add token.
> > > > > > > 
> > > > > > > Login to the vm with the user created using password. 
> > > > > > > Kerberos
> > > > > > > ticket assigned, all is well.
> > > > > > > 
> > > > > > > Login to web interface with admin. Change user to OTP 
> > > > > > > only.
> > > > > > > Go to web UI and click sync OTP.
> > > > > > > Enter username, password and 2 OTP sequences. Click sync. 
> > > > > > > Error
> > > > > > > appears.
> > > > > > > 
> > > > > > > Now, ssh to same vm using OTP username. Enter password + 
> > > > > > > OTP
> > > > > > > value.
> > > > > > > Login successful.
> > > > > > I can reproduce this issue with demo instance.
> > > > > > I will file a bug later today.
> > > > > > I think it is a bug with sync.
> > > > > > Which token do you use time based or event based?
> > > > > TOTP...
> > > > > 
> > > > > Hmm, makes me wonder - with HOTP fail the same? Off to try 
> > > > > it.
> > > > This should just affect TOTP. I have posted a patch that should 
> > > > fix
> > > > this problem. Are you able to test it?
> > > > 
> > > > https://www.redhat.com/archives/freeipa-devel/2015
> > > > -April/msg00282.html
> > > > 
> > > > 
> > > Sorry - I just got around to testing this and it does resolve the 
> > > problem -
> > > HOWEVER, you took away the ability to "Name" the tokens? They are 
> > > now
> > > "assigned" unique IDs??
> > > 
> > > Was this intentional?
> > 
> > It was, we track this (half-done) change in this ticket:
> > https://fedorahosted.org/freeipa/ticket/4456
> > 
> > The main problem here is that user token names share the same name 
> > space and we
> > thus do not want to create completely arbitrary names as they would 
> > collide.
> > 
> > Applications like FreeOTP allow users to set own labels, so this is 
> > IMO the way
> > how to add friendly names to the OTP tokens.
> > 
> > Martin
> > 
> 
> Makes sense, my only concern is syncing tokens.  Once you add a 
> second to,en and want to sync it you have to give it a token ID, 
> otherwise it does not know which to sync. In the past if you named 
> it, that was easy, but it does not seem to take description field as 
> a token name. Guess I need to tell my users it is cut/paste time, or 
> is there another option perhaps?

You do not need to specify the token id when syncing. It is optional.
If you leave it blank, FreeIPA will do the right thing.

> Also, I was wondering, looking for a way to use both FreeOTP and 
> yubikey and wondering if anyone has tried this and possible caveats?

There shouldn't be any caveats. Yubikey is just an HOTP token.

Nathaniel

-- 
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] interesting Kerberos issue


On 5/10/15 11:57 PM, Alexander Bokovoy wrote:

On Sun, 10 May 2015, Janelle wrote:

On 5/5/15 6:47 AM, Dmitri Pal wrote:

On 05/04/2015 09:38 PM, Janelle wrote:

On 5/4/15 6:06 PM, Nathaniel McCallum wrote:

On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote:

Happy Star Wars Day!
May the Fourth be with you!

So I have a strange Kerberos problem trying to figure out. On a
CLIENT,  (CentOS 7.1) if I login to account "usera" they get a
ticket as
expected.  However, if I login to a 6.6 client, it doesn't seem to
work.
Both were enrolled the same, obviously one is newer.

Now, it gets stranger. The "servers" are CentOS 7.1 also. If I login
as
root, bypassing kerberos, and then do "kinit admin" it works just
fine.
But if I do "kinit usera" I get:

kinit: Generic preauthentication failure while getting initial
credentials

Which makes no sense. The account works with a 7.1 client but not a
6.x
client?? And yet "admin" works, no matter what. What am I missing
here?

If I had to guess, usera is enabled for OTP-only login. Is that
correct?

If so, clients require RHEL 7.1 for OTP support. Also, the error you
are getting is the result of not enabling FAST support for OTP
authentication (see the -T option).

Nathaniel
Ok, this did give me an idea (Thanks Nathaniel)  -- the account was 
set for BOTH "password" and OTP.
Apparently setting both does nothing. Yes a user can login with 
their password-only, but trying to use kinit does not work.


I am not sure I understand where the FAST support or the -T option 
is to be applied. On kinit? That does not seem correct. Perhaps I 
am misunderstanding this option?


~J

If the user is enabled for OTP his credential are sent differently 
than in the case when it is not enabled. Effectively instead of 
using encrypted timestamp the password and OTP are sent to the 
server as data. But they can't be sent in clear. You need to encrypt 
the data. To encrypt it you need another key - the host key. The 
encryption of the data in this context is called tunneling . FAST is 
the Kerberos protocol feature to provide tunneling of the data sent 
over the wire. To use FAST one needs to use -T on the kinit command 
line.

Does this help?


It helps -- thank you.

Now allow me to add a little more fun, and there may not be a solution.

From OS X (Yosemite) I am able to "kinit --kdc-hostname=IPA-server
principal" and it works, gives me a ticket, and if I attempt to login 
to the web interface, since I already have my ticket - boom, works fine.


Now, I enable 2FA and setup a token and change my account to OTP 
(with TOTP).  But as previously discussed, can't seem to specify a -T 
option from OS X.


I know this sounds tricky -- Any ideas?

Use
 kinit --fast-armor-cache /path/to/ccache to specify already existing 
ccache to armor the FAST processing.


This is Heimdal-specific, and you should have Heimdal 1.6rc2 at least.
You can check version number by running 'kinit --version'.

Aha, so thee default on OS X Yosemite is

$ kinit --version
kinit (Heimdal 1.5.1apple1)

so this won't work?

~J

PS - sorry for the questions, still trying to wrap my head around how to 
get OTP working from a term session so you can get your ticket and then 
login to all the hosts you need without reauthenticating.


--
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] 4.1.4 and OTP


> On May 18, 2015, at 04:31, Martin Kosek  wrote:
> 
>> On 05/18/2015 01:49 AM, Janelle wrote:
>>> On 4/28/15 6:44 AM, Nathaniel McCallum wrote:
 On Fri, 2015-04-17 at 20:21 -0700, Janelle wrote:
> On 4/17/15 5:59 PM, Dmitri Pal wrote:
>> On 04/17/2015 08:07 PM, Janelle wrote:
>> 
>> 
>> 
>> On Apr 17, 2015, at 16:36, Dmitri Pal  wrote:
>> 
>>  for shorter thread
>> Simple. And my test made it simple.
>> Stand up new vm running fc21/freeipa.
>> Configure user.
>> Add password.
>> Add token.
>> 
>> Login to the vm with the user created using password. Kerberos
>> ticket assigned, all is well.
>> 
>> Login to web interface with admin. Change user to OTP only.
>> Go to web UI and click sync OTP.
>> Enter username, password and 2 OTP sequences. Click sync. Error
>> appears.
>> 
>> Now, ssh to same vm using OTP username. Enter password + OTP
>> value.
>> Login successful.
> I can reproduce this issue with demo instance.
> I will file a bug later today.
> I think it is a bug with sync.
> Which token do you use time based or event based?
 TOTP...
 
 Hmm, makes me wonder - with HOTP fail the same? Off to try it.
>>> This should just affect TOTP. I have posted a patch that should fix
>>> this problem. Are you able to test it?
>>> 
>>> https://www.redhat.com/archives/freeipa-devel/2015-April/msg00282.html
>>> 
>>> 
>> Sorry - I just got around to testing this and it does resolve the problem -
>> HOWEVER, you took away the ability to "Name" the tokens? They are now
>> "assigned" unique IDs??
>> 
>> Was this intentional?
> 
> It was, we track this (half-done) change in this ticket:
> https://fedorahosted.org/freeipa/ticket/4456
> 
> The main problem here is that user token names share the same name space and 
> we
> thus do not want to create completely arbitrary names as they would collide.
> 
> Applications like FreeOTP allow users to set own labels, so this is IMO the 
> way
> how to add friendly names to the OTP tokens.
> 
> Martin
> 

Makes sense, my only concern is syncing tokens.  Once you add a second to,en 
and want to sync it you have to give it a token ID, otherwise it does not know 
which to sync. In the past if you named it, that was easy, but it does not seem 
to take description field as a token name. Guess I need to tell my users it is 
cut/paste time, or is there another option perhaps?

Also, I was wondering, looking for a way to use both FreeOTP and yubikey and 
wondering if anyone has tried this and possible caveats?

Janelle

-- 
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] RedHat IDM Replica runs ony dirsrv, kinit and getent fail after reboot

2015-05-18 Thread Sina Owolabi

Hi Martin

And thanks for getting back, greatly appreciated.
I tore down the replica and reinstalled from scratch, using an old
replica-info file
I had on the primary. Im not sure if this is a good thing to do, but I
would appreciate
if you could point me to the logs you'd be interested in seeing.
I had to reinstall the replica without CA before it would complete, too.

Thanks again for your precious time.

On Mon, May 18, 2015 at 10:15 AM, Martin Kosek  wrote:
> On 05/16/2015 12:19 PM, Sina Owolabi wrote:
>> Please help me. I am in dire straits, this is the linchpin of our
>> network and we are suffering.
>
> I am sorry for delay in answering, but not many people here show up on the
> weekend. Comments below.
>
>> On Sat, May 16, 2015 at 6:00 AM, Sina Owolabi  wrote:
>>> Hi!
>>>
>>> I am running an IPA domain with two servers, one is a replica. Red Hat 6.6,
>>> with the following versions:
>>> libipa_hbac-1.11.6-30.el6_6.4.x86_64
>>> ipa-server-selinux-3.0.0-42.el6.x86_64
>>> libipa_hbac-python-1.11.6-30.el6_6.4.x86_64
>>> ipa-admintools-3.0.0-42.el6.x86_64
>>> python-iniparse-0.3.1-2.1.el6.noarch
>>> ipa-client-3.0.0-42.el6.x86_64
>>> ipa-pki-common-theme-9.0.3-7.el6.noarch
>>> device-mapper-multipath-libs-0.4.9-80.el6_6.3.x86_64
>>> device-mapper-multipath-0.4.9-80.el6_6.3.x86_64
>>> ipa-server-3.0.0-42.el6.x86_64
>>> ipa-python-3.0.0-42.el6.x86_64
>>> ipa-pki-ca-theme-9.0.3-7.el6.noarch
>>> sssd-ipa-1.11.6-30.el6_6.4.x86_64
>>>
>>>
>>> I noticed the replica did not seem to be in sync with the primary IPA
>>> server, as login requests to ipa clients using the replica for domain
>>> authentication failed with
>>> "Too many authentication failures for user UNKNOWN".
>>> I forced a sync with the primary server and rebooted the replica afterwards.
>>> Now the replica is back up, but when I run "ipactl status", only
>>> dirsrv is running:
>>> # ipactl status
>>> Directory Service: RUNNING
>
> This is strange, try
>
> # ipactl restart
>
> see which services fail to start and see the logs they produce.
>
>>> No other service shows up. I also tried editing /etc/krb5.conf to
>>> change the [realms] information to point to the primary server, but
>>> while I can now kinit admin,
>>> nothing else works.
>>>
>>> Please how can I fix this problem?
>>>
>>> Please what can I do fix this?
>
> First things first. You need to first see if all service start and operate
> properly, if not, we need to see their logs in order to help or advise.
>
> 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] Certificate operation cannot be completed: Unable to communicate with CMS (Not Found)

2015-05-18 Thread Sina Owolabi

Yes CA is running,  and it's on the same machine.

[root@dc ~]# ipa-replica-prepare dc01.ourdom.com --ip-address 192.168.2.40

Directory Manager (existing master) password:


Preparing replica for dc01.ourdom.com from dc.ourdom.com

Creating SSL certificate for the Directory Server

Certificate operation cannot be completed: Unable to communicate with CMS
(Not Found)

[root@dc ~]# ipactl status

Directory Service: RUNNING

KDC Service: RUNNING

KPASSWD Service: RUNNING

DNS Service: RUNNING

MEMCACHE Service: RUNNING

HTTP Service: RUNNING

CA Service: RUNNING

[root@dc ~]#


On Mon, May 18, 2015, 10:19 AM Martin Kosek  wrote:

> On 05/16/2015 12:18 PM, Sina Owolabi wrote:
> > Hi Group,
> >
> > I'm attempting again to rebuild and reinstall a troublesome replica. I
> > have two freshly upgraded RHEL6.6 IdM servers.
> >
> > Problem is when I try to run createreplica I have this output:
> >
> >  ipa-replica-prepare services01.ours.com --ip-address 192.168.2.40
> > Directory Manager (existing master) password:
> >
> > Preparing replica for services01.ours.com from services.ours.com
> > Creating SSL certificate for the Directory Server
> > Certificate operation cannot be completed: Unable to communicate with
> > CMS (Not Found)
>
> It looks like CA is not reachable. Is CA on the machine where you run
> ipa-replica-manage? Or other machine?
>
> Is the CA running? (ipactl status)
>
> >
> > I have check the different threads where I find this same error but
> > all symlinks are correctly defined.
> >
> > Please can someone kindly guide a noob in the right path?
> >
>
>
-- 
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] Replication seems to begin but failed after 127 seconds ...

2015-05-18 Thread thierry bordaz

On 05/15/2015 05:11 PM, James James wrote:

ok Rob. Thanks for your help. I will wait for the Scientific Linux 6.7 .

Hi James,

Unfortunately there is no workaround. This is a timing issue mostly seen 
when the master is more powerful than the consumer.
If you are using VM you may try to get master/replica with nearly the 
same cpu/memory.

thanks
thierry

Best.

James

2015-05-15 16:58 GMT+02:00 Rich Megginson >:

On 05/15/2015 08:46 AM, James James wrote:

[root@ipa ~]#  rpm -q 389-ds-base
389-ds-base-1.2.11.15-50.el6_6.x86_64

Ok.  Looks like this is planned to be fixed in RHEL 6.7 with
version 389-ds-base-1.2.11.15-56.el6

I don't know if there are any workarounds.

2015-05-15 16:32 GMT+02:00 Rich Megginson mailto:rmegg...@redhat.com>>:

On 05/15/2015 08:22 AM, James James wrote:

I think that :

Starting replication, please wait until this has completed.
Update in progress, 127 seconds elapsed
Update in progress yet not in progress

looks like a time error :
https://fedorahosted.org/freeipa/ticket/4756

That issue should have been fixed in 389-ds-base-1.3.3
branch.  What version of 389-ds-base?  rpm -q 389-ds-base

2015-05-15 16:00 GMT+02:00 Rich Megginson
mailto:rmegg...@redhat.com>>:

On 05/15/2015 07:55 AM, James James wrote:

Is it possible to change the nsds5ReplicaTimeout value
to get rid of this timeout error ?

What timeout error?

2015-04-17 4:52 GMT+02:00 Rich Megginson
mailto:rmegg...@redhat.com>>:

On 04/15/2015 10:44 PM, James James wrote:

The ipareplica-install.log file in attachment ...

Here are the pertinent bits:

2015-04-15T15:06:31Z DEBUG wait_for_open_ports:
localhost [389] timeout 300
2015-04-15T15:06:32Z DEBUG flushing
ldap://ipa.example.com:389 from SchemaCache
2015-04-15T15:06:32Z DEBUG retrieving schema for
SchemaCache url=ldap://ipa.example.com:389
conn=
2015-04-15T15:06:32Z DEBUG flushing
ldaps://ipa1.example.com:636 from SchemaCache
2015-04-15T15:06:32Z DEBUG retrieving schema for
SchemaCache url=ldaps://ipa1.example.com:636
conn=
2015-04-15T15:08:44Z DEBUG Traceback (most recent
call last):
  File
"/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
line 382, in start_creation
run_step(full_msg, method)
  File
"/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
line 372, in run_step
method()
  File

"/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py",
line 368, in __setup_replica
r_bindpw=self.dm_password)
  File

"/usr/lib/python2.7/site-packages/ipaserver/install/replication.py",
line 969, in setup_replication
raise RuntimeError("Failed to start replication")
RuntimeError: Failed to start replication

2015-04-15T15:08:44Z DEBUG   [error] RuntimeError:
Failed to start replication

The times are a little off, but I believe this
corresponds to
[15/Apr/2015:17:08:39 +0200] - import userRoot:
Import complete. Processed 1539 entries in 126
seconds. (12.21 entries/sec)
[15/Apr/2015:17:08:39 +0200] NSMMReplicationPlugin
- multimaster_be_state_change: replica
dc=lix,dc=polytechnique,dc=fr is coming online;
enabling replication

I don't know why setup_replication is reporting an
error if replication completed successfully.

2015-04-16 2:22 GMT+02:00 Rob Crittenden
mailto:rcrit...@redhat.com>>:

Rich Megginson wrote:
> On 04/15/2015 02:58 PM, James James wrote:
>> Nothing on the replica .. maybye a process
on the master. How can I
>> check that ?
>
> I have no idea.  But it seems highly
unlikely that a process on the
> master is able to shutdown a process on the
replica . . .
>
> I would say that there is some problem with
the ipa-replica-install not
> properly checking the status - see below:
>
>>

Re: [Freeipa-users] username case sensitivity

2015-05-18 Thread Andy Thompson

> -Original Message-
> From: Jakub Hrozek [mailto:jhro...@redhat.com]
> Sent: Monday, May 18, 2015 4:07 AM
> To: Andy Thompson
> Cc: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] username case sensitivity
> 
> On Sun, May 17, 2015 at 10:26:45PM +, Andy Thompson wrote:
> > > -Original Message-
> > > From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
> > > boun...@redhat.com] On Behalf Of Jakub Hrozek
> > > Sent: Sunday, May 17, 2015 5:23 PM
> > > To: freeipa-users@redhat.com
> > > Subject: Re: [Freeipa-users] username case sensitivity
> > >
> > > On Fri, May 15, 2015 at 09:44:31PM +0200, Lukas Slebodnik wrote:
> > > > On (15/05/15 17:27), Andy Thompson wrote:
> > > > >Is there a way to enforce case sensitivity for trusted AD users?
> > > > >I am
> > > > trying to use username for ssh chroots and I can authenticated
> > > > with any case combination of  but if ssh is set to match
> > > > on  then the chroot is not enforced and the user is
> > > > dropped to their usual home directory.  I found a case_sensitive
> > > > option for sssd but it
> > > does not
> > > > seem to have any affect.   Running RHEL6.6 clients.
> > > > >
> > > >
> > > > IPA domain is by default case sensitive.
> > > > So You will not change anything if you put "case_sensitive = true"
> > > > into domain section of sssd.conf.
> > > >
> > > > But SSSD will create subdomains for each AD domain. It is
> > > > different id_provider therefore different default values are used
> > > > for subdomains and for AD provider it is case *insensitive* by default.
> > > >
> > > > Currently there's no way how to change it for subdomains (AD
> > > > trusted
> > > > domains)
> > > >
> > >
> > > What are you using for the SSH matching? The way the case
> > > insensitiveness is implemented in SSSD is that all usernames are
> > > forcibly lowercased on output, so as long as SSH uses the standard
> > > NSS calls, you should be good with using the lowecase usernames..
> > >
> >
> > They were initially all in lower case and working  when I tested and 
> > finalized
> the setup.  I passed the credentials off and they used mixed case and the
> match stopped working.
> 
> What is "they" ? I guess not SSSD but grabbing the data directly from LDAP?

The match clauses in the sshd config were set to use lower case names.  It is 
using sssd, just a regular ipa client installation.  If I logged in using 
USERName insetad of username, the match clause did not work.

-andy

-- 
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] 4.1.4 and OTP

On 05/18/2015 01:49 AM, Janelle wrote:
> On 4/28/15 6:44 AM, Nathaniel McCallum wrote:
>> On Fri, 2015-04-17 at 20:21 -0700, Janelle wrote:
>>> On 4/17/15 5:59 PM, Dmitri Pal wrote:
 On 04/17/2015 08:07 PM, Janelle wrote:
>
>
>
> On Apr 17, 2015, at 16:36, Dmitri Pal  wrote:
>
>  for shorter thread
> Simple. And my test made it simple.
> Stand up new vm running fc21/freeipa.
> Configure user.
> Add password.
> Add token.
>
> Login to the vm with the user created using password. Kerberos
> ticket assigned, all is well.
>
> Login to web interface with admin. Change user to OTP only.
> Go to web UI and click sync OTP.
> Enter username, password and 2 OTP sequences. Click sync. Error
> appears.
>
> Now, ssh to same vm using OTP username. Enter password + OTP
> value.
> Login successful.
 I can reproduce this issue with demo instance.
 I will file a bug later today.
 I think it is a bug with sync.
 Which token do you use time based or event based?
>>> TOTP...
>>>
>>> Hmm, makes me wonder - with HOTP fail the same? Off to try it.
>> This should just affect TOTP. I have posted a patch that should fix
>> this problem. Are you able to test it?
>>
>> https://www.redhat.com/archives/freeipa-devel/2015-April/msg00282.html
>>
>>
> Sorry - I just got around to testing this and it does resolve the problem -
> HOWEVER, you took away the ability to "Name" the tokens? They are now
> "assigned" unique IDs??
> 
> Was this intentional?

It was, we track this (half-done) change in this ticket:
https://fedorahosted.org/freeipa/ticket/4456

The main problem here is that user token names share the same name space and we
thus do not want to create completely arbitrary names as they would collide.

Applications like FreeOTP allow users to set own labels, so this is IMO the way
how to add friendly names to the OTP tokens.

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] Securing IPA Redux

On 05/15/2015 01:33 PM, Brian Topping wrote:
> In the (apparently) first message to the list in 2014, 
> https://www.redhat.com/archives/freeipa-users/2014-January/msg0.html 
>  
> addressed questions about securing IPA and I don't see much other talk about 
> it. Now that 4.x is prevalent, I wanted to bring it up again.

This is the default by design. However, note that in FreeIPA 4.0+ you can
change that default (permission-mod) and let users or some of the user
attributes be only shown for authenticated users.

https://www.freeipa.org/page/V4/Permissions_V2

So, from my POV, this is not a flaw.

> I'd like my installation to be allow hardened machines (i.e. in the cloud 
> with encrypted filesystems) to be a part of the domain. I believe this means 
> that I need to expose Kerberos and LDAP to the world, since the machines 
> could live anywhere. I don't believe I need to worry about KRB5, but I am 
> concerned about 389-DS since it seems somewhat difficult to force TLS 
> (https://blog.routedlogic.net/?p=119 ) 
> and maybe that's a bad idea under IPA for reasons I thought I'd ask here 
> about. Last year's thread also referenced 
> https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/disabling-anon-binds.html
>  
> 
>  and I thought I would check to see if that's still necessary under 4.x.

389-DS and TLS should be also fixed, since FreeIPA 4.1 (RHEL/CentOS 7.1):

https://fedorahosted.org/freeipa/ticket/4653

This is an nmap test against the FreeIPA public demo (4.1.x):

$ nmap --script ssl-enum-ciphers -p 636 ipa.demo1.freeipa.org

Starting Nmap 6.47 ( http://nmap.org ) at 2015-05-18 11:08 CEST
Nmap scan report for ipa.demo1.freeipa.org (209.132.178.99)
Host is up (0.19s latency).
PORTSTATE SERVICE
636/tcp open  ldapssl
| ssl-enum-ciphers:
|   TLSv1.2:
| ciphers:
|   TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
|   TLS_RSA_WITH_AES_128_CBC_SHA - strong
|   TLS_RSA_WITH_AES_128_CBC_SHA256 - strong
|   TLS_RSA_WITH_AES_128_GCM_SHA256 - strong
|   TLS_RSA_WITH_AES_256_CBC_SHA - strong
|   TLS_RSA_WITH_AES_256_CBC_SHA256 - strong
|   TLS_RSA_WITH_RC4_128_MD5 - strong
|   TLS_RSA_WITH_RC4_128_SHA - strong
| compressors:
|   NULL
|_  least strength: strong

Nmap done: 1 IP address (1 host up) scanned in 6.19 seconds

> Setting up the firewall to allow cloud networks in is always an option, but 
> if I can get a secure IPA setup going, it would also allow road warriors to 
> kinit and use their credentials for configured intranet sites without having 
> to turn on the VPN (which can really slow things down from remote parts of 
> the globe).

BTW, if you are concerned about exposed Kerberos traffic, FreeIPA 4.2 plans to
offer Kerberos-over-HTTP functionality by default:
https://fedorahosted.org/freeipa/ticket/4801

Even now, it can be manually configured. This is what GNOME used:
https://www.dragonsreach.it/2014/10/07/the-gnome-infrastructure-is-now-powered-by-freeipa/

So, if I am reading my notes correctly, there should be no blockers in using
FreeIPA in your environment. If yes, please let me know.

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] Certificate operation cannot be completed: Unable to communicate with CMS (Not Found)

On 05/16/2015 12:18 PM, Sina Owolabi wrote:
> Hi Group,
> 
> I'm attempting again to rebuild and reinstall a troublesome replica. I
> have two freshly upgraded RHEL6.6 IdM servers.
> 
> Problem is when I try to run createreplica I have this output:
> 
>  ipa-replica-prepare services01.ours.com --ip-address 192.168.2.40
> Directory Manager (existing master) password:
> 
> Preparing replica for services01.ours.com from services.ours.com
> Creating SSL certificate for the Directory Server
> Certificate operation cannot be completed: Unable to communicate with
> CMS (Not Found)

It looks like CA is not reachable. Is CA on the machine where you run
ipa-replica-manage? Or other machine?

Is the CA running? (ipactl status)

> 
> I have check the different threads where I find this same error but
> all symlinks are correctly defined.
> 
> Please can someone kindly guide a noob in the right path?
> 

-- 
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] RedHat IDM Replica runs ony dirsrv, kinit and getent fail after reboot