Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error)

[Rich Megginson]

On 11/10/2015 08:18 AM, Gronde, Christopher (Contractor) wrote:

Thank you!  I should have caught that...

I changed the log level and then restarted dirsrv and attempted to start 
krb5kdc and got the following...



[10/Nov/2015:10:12:02 -0500] conn=5 fd=64 slot=64 connection from 
172.16.100.208 to 172.16.100.161
[10/Nov/2015:10:12:02 -0500] conn=5 op=0 BIND dn="" method=sasl 
version=3 mech=GSSAPI
[10/Nov/2015:10:12:03 -0500] conn=5 op=0 RESULT err=14 tag=97 nentries=0 
etime=1, SASL bind in progress
[10/Nov/2015:10:12:03 -0500] conn=5 op=1 BIND dn="" method=sasl 
version=3 mech=GSSAPI
[10/Nov/2015:10:12:03 -0500] conn=5 op=1 RESULT err=14 tag=97 nentries=0 
etime=0, SASL bind in progress
[10/Nov/2015:10:12:03 -0500] conn=5 op=2 BIND dn="" method=sasl 
version=3 mech=GSSAPI
[10/Nov/2015:10:12:03 -0500] conn=Internal op=-1 SRCH 
base="dc=itmodev,dc=gov" scope=2 
filter="(uid=ldap/comipa01.itmodev.gov)" attrs=ALL
[10/Nov/2015:10:12:03 -0500] conn=Internal op=-1 RESULT err=0 tag=48 
nentries=0 etime=0
[10/Nov/2015:10:12:03 -0500] conn=5 op=2 RESULT err=49 tag=97 nentries=0 
etime=0

[10/Nov/2015:10:12:03 -0500] conn=5 op=3 UNBIND
[10/Nov/2015:10:12:03 -0500] conn=5 op=3 fd=64 closed - U1



This is the SASL bind.  It thinks the principal in the Kerberos 
credential is "ldap/comipa01.itmodev.gov", and the SASL map tells the 
code to look for something with uid=ldap/comipa01.itmodev.gov under 
dc=itmodev,dc=gov.  However, this entry is not found: RESULT err=0 
tag=48 nentries=0.  nentries=0 means no entries matched the search criteria.


You can do the search yourself with ldapsearch:

ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b 
"dc=itmodev,dc=gov" '(uid=ldap/comipa01.itmodev.gov)'


If you want to find out if there is some other ldap principal, do a 
search like this:


ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b 
"dc=itmodev,dc=gov" '(uid=ldap/*.gov)' uid



Ran into an error trying to set that

# ldapmodify -a -D "cn=directory manager" -W Enter LDAP Password:
dn: cn=config
changetype: modify
replace: nsslapd-acesslog-level
: 260

modifying entry "cn=config"
ldap_modify: Server is unwilling to perform (53)
  additional info: Unknown attribute nsslapd-acesslog-level
will be ignored

[root@comipa02 ~]# ldapmodify -a -D "cn=config" -W Enter LDAP
Password:
ldap_bind: Inappropriate authentication (48)

-Original Message-
From: Ludwig Krispenz [mailto:lkris...@redhat.com]
Sent: Tuesday, November 10, 2015 9:48 AM
To: Gronde, Christopher (Contractor) 
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos
authentication error)


On 11/10/2015 03:32 PM, Gronde, Christopher (Contractor) wrote:

How do I change that log setting?  Is that done in LDAP?  Using ldapmodify?

yes,
ldapmodify ...
dn: cn=config
changetype: modify
replace: nsslapd-acesslog-level
nsslapd-acesslog-level: 260

-Original Message-
From: freeipa-users-boun...@redhat.com
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Ludwig
Krispenz
Sent: Tuesday, November 10, 2015 9:03 AM
To: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos
authentication error)


On 11/10/2015 02:40 PM, Alexander Bokovoy wrote:

On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote:

Where can I verify or change the credentials it is trying to use?
Is it my LDAP password?

No, according to your logs, it is your LDAP master trying to
replicate (push changes) to your LDAP replica:

[09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from
 to 
[09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl
version=3 mech=GSSAPI

err=49 could also be a result if the entry which is mapped from the principal 
is not found in the directory. A bit more info could be gained by enabling 
logging of internal searches.
Set nsslapd-acesslog-level: 260

and then look what internal searches are done during the gssapi
authentication

If that is true, it would be ldap/ Kerberos principal
talking to ldap/ Kerberos principal. If that fails, it
means master and replica KDCs have different understanding of both
ldap/ and ldap/ keys which most likely means keys
were rotated on master and weren't propagated to replica.

How to solve it? One possibility is to set master's hostname as KDC
address in krb5.conf on replica, forcing LDAP server on replica to
use master's KDC. I'm absolutely not sure this will actually work
but at least it allows to see if we are indeed dealing with
inconsistent state of service principals' keys.


-Original Message-
From: Alexander Bokovoy [mailto:aboko...@redhat.com]
Sent: Tuesday, November 10, 2015 8:18 AM
To: Gronde, Christopher (Contractor)

Cc: Rob Crittenden ; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos
authentication error)

On Tue, 10 Nov 2015, Gronde, Christopher 

Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error)

[Martin Basti]

On 10.11.2015 15:53, Gronde, Christopher (Contractor) wrote:

Ran into an error trying to set that

# ldapmodify -a -D "cn=directory manager" -W
Enter LDAP Password:
dn: cn=config
changetype: modify
replace: nsslapd-acesslog-level
nsslapd-acesslog-level: 260

it is

nsslapd-accesslog-level  with 2 'c' in access

Martin



modifying entry "cn=config"
ldap_modify: Server is unwilling to perform (53)
 additional info: Unknown attribute nsslapd-acesslog-level will be 
ignored

[root@comipa02 ~]# ldapmodify -a -D "cn=config" -W
Enter LDAP Password:
ldap_bind: Inappropriate authentication (48)

-Original Message-
From: Ludwig Krispenz [mailto:lkris...@redhat.com]
Sent: Tuesday, November 10, 2015 9:48 AM
To: Gronde, Christopher (Contractor) 
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication 
error)


On 11/10/2015 03:32 PM, Gronde, Christopher (Contractor) wrote:

How do I change that log setting?  Is that done in LDAP?  Using ldapmodify?

yes,
ldapmodify ...
dn: cn=config
changetype: modify
replace: nsslapd-acesslog-level
nsslapd-acesslog-level: 260

-Original Message-
From: freeipa-users-boun...@redhat.com
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Ludwig Krispenz
Sent: Tuesday, November 10, 2015 9:03 AM
To: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos
authentication error)


On 11/10/2015 02:40 PM, Alexander Bokovoy wrote:

On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote:

Where can I verify or change the credentials it is trying to use?
Is it my LDAP password?

No, according to your logs, it is your LDAP master trying to
replicate (push changes) to your LDAP replica:

[09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from
 to 
[09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl
version=3 mech=GSSAPI

err=49 could also be a result if the entry which is mapped from the principal 
is not found in the directory. A bit more info could be gained by enabling 
logging of internal searches.
Set nsslapd-acesslog-level: 260

and then look what internal searches are done during the gssapi
authentication

If that is true, it would be ldap/ Kerberos principal talking
to ldap/ Kerberos principal. If that fails, it means master
and replica KDCs have different understanding of both ldap/
and ldap/ keys which most likely means keys were rotated on
master and weren't propagated to replica.

How to solve it? One possibility is to set master's hostname as KDC
address in krb5.conf on replica, forcing LDAP server on replica to
use master's KDC. I'm absolutely not sure this will actually work but
at least it allows to see if we are indeed dealing with inconsistent
state of service principals' keys.


-Original Message-
From: Alexander Bokovoy [mailto:aboko...@redhat.com]
Sent: Tuesday, November 10, 2015 8:18 AM
To: Gronde, Christopher (Contractor) 
Cc: Rob Crittenden ; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos
authentication error)

On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote:

When I tried to start the service again I got no response from tail
of the log, but this is a repeating entry I see in the access log

[09/Nov/2015:15:01:04 -0500] conn=1 fd=64 slot=64 connection from
127.0.0.1 to 127.0.0.1
[09/Nov/2015:15:01:04 -0500] conn=1 op=-1 fd=64 closed - B1
[09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from
 to 
[09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl
version=3 mech=GSSAPI
[09/Nov/2015:15:02:01 -0500] conn=2 op=0 RESULT err=14 tag=97
nentries=0 etime=0, SASL bind in progress
[09/Nov/2015:15:02:01 -0500] conn=2 op=1 BIND dn="" method=sasl
version=3 mech=GSSAPI
[09/Nov/2015:15:02:01 -0500] conn=2 op=1 RESULT err=14 tag=97
nentries=0 etime=0, SASL bind in progress
[09/Nov/2015:15:02:01 -0500] conn=2 op=2 BIND dn="" method=sasl
version=3 mech=GSSAPI
[09/Nov/2015:15:02:01 -0500] conn=2 op=2 RESULT err=49 tag=97
nentries=0 etime=0
[09/Nov/2015:15:02:01 -0500] conn=2 op=3 UNBIND
[09/Nov/2015:15:02:01 -0500] conn=2 op=3 fd=64 closed - U1

Does anyone know what err=14 or err=49 are?

err=14 means SASL bind in progress -- i.e. multi-round processing is
ongoing. This is normal for SASL GSSAPI.

err=49 is wrong password or username, i.e. credentials were incorrect.
It may also mean that LDAP server side was unable to process
Kerberos negotiation due to not having a current Kerberos ticket for
own service
(LDAP) and trying to request it from the Kerberos KDC but Kerberos
KDC is down.


-Original Message-
From: Rob Crittenden [mailto:rcrit...@redhat.com]
Sent: Monday, November 09, 2015 3:26 PM
To: Gronde, Christopher (Contractor)
; Alexander Bokovoy

Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] krb5kdc will not start 

Re: [Freeipa-users] Sync with SUN DS 5.2

[Rob Crittenden]

Seike neg wrote:
> Hello,
> Is there a way to import users and password from SUN DS automatically 
> (script, sync, etc...).
> I have a SUN DS LDAP in the office and I want to do a read only sync from him 
> to a brand new freeipa server.
> The freeipa server is suppose to act as a kerberos, ldap slave and ntp server.
> 
> 

It's a little unclear what you want to do. Do you want a periodic sync
or a one-time migration?

You can use ipa migrate-ds to migrate over LDAP. See
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/Migrating_from_a_Directory_Server_to_IPA.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

Re: [Freeipa-users] Sync with SUN DS 5.2

[Rich Megginson]

On 11/10/2015 08:39 AM, Rob Crittenden wrote:

Seike neg wrote:

Hello,
Is there a way to import users and password from SUN DS automatically (script, 
sync, etc...).
I have a SUN DS LDAP in the office and I want to do a read only sync from him 
to a brand new freeipa server.
The freeipa server is suppose to act as a kerberos, ldap slave and ntp server.



It's a little unclear what you want to do. Do you want a periodic sync
or a one-time migration?

You can use ipa migrate-ds to migrate over LDAP. See
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/Migrating_from_a_Directory_Server_to_IPA.html


You can also configure SunDS 5.2 to replicate to IPA, and vice versa.



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] krb5kdc will not start (kerberos authentication error)

[Gronde, Christopher (Contractor)]

Neither came back with anything

# ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b 
"dc=itmodev,dc=gov" '(uid=ldap/comipa01.itmodev.gov)'
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base 

Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error)

[Martin Babinsky]

On 11/10/2015 05:16 PM, Gronde, Christopher (Contractor) wrote:

Neither came back with anything

# ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b 
"dc=itmodev,dc=gov" '(uid=ldap/comipa01.itmodev.gov)'
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base 

Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error)

[Rich Megginson]

On 11/10/2015 09:49 AM, Gronde, Christopher (Contractor) wrote:

Note comipa01 is the master and comipa02 is the replica that is having the KDC 
issue

# ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b 
"dc=itmodev,dc=gov" '(krbprincipalname=ldap/comipa01.itmodev.gov*)'
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base 

Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error)

[Gronde, Christopher (Contractor)]

Thank you!  I should have caught that...

I changed the log level and then restarted dirsrv and attempted to start 
krb5kdc and got the following...

[10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 ADD dn=""
[10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 SRCH base="cn=mapping 
tree,cn=config" scope=1 
filter="(&(objectclass=nsMappingTree)(!(nsslapd-parent-suffix=*)))" attrs=ALL
[10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 
etime=0
[10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 SRCH base="cn=mapping 
tree,cn=config" scope=1 
filter="(&(objectclass=nsMappingTree)(|(nsslapd-parent-suffix="dc=itmodev,dc=gov")(nsslapd-parent-suffix=dc=itmodev,dc=gov)))"
 attrs=ALL
[10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 
etime=0
[10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 RESULT err=68 tag=48 
nentries=0 etime=0
[10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 ADD 
dn="oid=2.16.840.1.113730.3.4.9,cn=features,cn=config"
[10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 RESULT err=32 tag=48 
nentries=0 etime=0
[10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 ADD 
dn="oid=2.16.840.1.113730.3.5.7,cn=features,cn=config"
[10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 RESULT err=32 tag=48 
nentries=0 etime=0
[10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 ADD 
dn="cn=options,cn=features,cn=config"
[10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 RESULT err=32 tag=48 
nentries=0 etime=0
[10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 ADD 
dn="cn=encryption,cn=config"
[10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 RESULT err=68 tag=48 
nentries=0 etime=0
[10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 ADD dn="cn=monitor"
[10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 RESULT err=68 tag=48 
nentries=0 etime=0
[10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 ADD dn="cn=snmp,cn=monitor"
[10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 RESULT err=68 tag=48 
nentries=0 etime=0
[10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 ADD dn="cn=counters,cn=monitor"
[10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 RESULT err=68 tag=48 
nentries=0 etime=0
[10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 ADD dn="cn=sasl,cn=config"
[10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 RESULT err=68 tag=48 
nentries=0 etime=0
[10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 ADD 
dn="cn=mapping,cn=sasl,cn=config"
[10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 RESULT err=68 tag=48 
nentries=0 etime=0
[10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 ADD dn="cn=SNMP,cn=config"
[10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 RESULT err=68 tag=48 
nentries=0 etime=0
[10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 ADD dn="ou=Netscape Directory 
Team,cn=monitor"
[10/Nov/2015:10:09:31 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 
etime=0
[10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 SRCH base="cn=SNMP,cn=config" 
scope=0 filter="(|(objectclass=*)(objectclass=ldapsubentry))" attrs=ALL
[10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 
etime=0
[10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 SRCH base="cn=uniqueid 
generator,cn=config" scope=0 filter="objectclass=*" attrs=ALL
[10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 
etime=0
[10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 MOD dn="cn=uniqueid 
generator,cn=config"
[10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 
etime=0
[10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 SRCH base="cn=tasks,cn=config" 
scope=2 filter="(objectclass=*)" attrs=ALL
[10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 
nentries=15 etime=0
[10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 DEL 
dn="cn=upgradedb,cn=tasks,cn=config"
[10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 
etime=0
[10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 DEL dn="cn=syntax 
validate,cn=tasks,cn=config"
[10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 
etime=0
[10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 DEL dn="cn=schema reload 
task,cn=tasks,cn=config"
[10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 
etime=0
[10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 DEL 
dn="cn=restore,cn=tasks,cn=config"
[10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 
etime=0
[10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 DEL 
dn="cn=index,cn=tasks,cn=config"
[10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 
etime=0
[10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 DEL 
dn="cn=import,cn=tasks,cn=config"
[10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 
etime=0
[10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 DEL dn="cn=fixup linked 
attributes,cn=tasks,cn=config"
[10/Nov/2015:10:09:32 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 
etime=0
[10/Nov/2015:10:09:32 

[Freeipa-users] Sync with SUN DS 5.2

[Seike neg]

Hello,
Is there a way to import users and password from SUN DS automatically (script, 
sync, etc...).
I have a SUN DS LDAP in the office and I want to do a read only sync from him 
to a brand new freeipa server.
The freeipa server is suppose to act as a kerberos, ldap slave and ntp server.
  

-- 
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] krb5kdc will not start (kerberos authentication error)

[Gronde, Christopher (Contractor)]

This gave me a huge return!  Appears to be a long list of all the servers and 
applications whose users authenticate to the IPA servers.

ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b 
"dc=itmodev,dc=gov" '(objectclass=krbprincipal)'


# search result
search: 2
result: 0 Success

# numResponses: 142
# numEntries: 141

-Original Message-
From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Ludwig Krispenz
Sent: Tuesday, November 10, 2015 11:37 AM
To: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication 
error)

what do you get if you search for "objectclass=krbprincipal" ?

On 11/10/2015 05:27 PM, Rich Megginson wrote:
> On 11/10/2015 09:16 AM, Gronde, Christopher (Contractor) wrote:
>> Neither came back with anything
>>
>> # ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b 
>> "dc=itmodev,dc=gov" '(uid=ldap/comipa01.itmodev.gov)'
>> Enter LDAP Password:
>> # extended LDIF
>> #
>> # LDAPv3
>> # base 

Re: [Freeipa-users] First tests against the REST/JSON API

[Oliver Dörr]

Hi Alexander,

sorry for responding you privately. This was not my intention; I just 
recognized that my mail program has two reply buttons (replay and reply 
to mailing list).


I've played a bit around with your code and implemented a small Perl 
module and a test script. They both work in my environment, however I'm 
still not happy with them.


What I don't like is...
1st, I need to provide my client version
2nd, I get the message  'truncated' => bless( do{\(my $o = 0)}, 
'JSON::PP::Boolean' ) from the user_find API
3rd, I do not know what the id is used for and so I'm unsure if I could 
automatically handle it in my Perl module


However they should be a help for others who wants use Perl-script to 
access IPA-API.


Anyway thanks for your help. This was what I need to get on the track.

Oliver

Am 10.11.2015 um 09:14 schrieb Alexander Bokovoy:

On Mon, 09 Nov 2015, Natxo Asenjo wrote:

hi,

On Mon, Nov 9, 2015 at 6:58 PM, Oliver Dörr  
wrote:



Hi,

I'm completly new to this list and the product behind it. I'm trying to
use perl to get a list from my IPA installation of all users that 
are on

the server.



unfortunately I cannot help you right now, but have you taken a look at
this blog post:

https://vda.li/en/posts/2015/05/28/talking-to-freeipa-api-with-sessions/

It could give you some pointers.

Share your code if you get it to work :-)

The code in my response (see other mail) works fine, Oliver contacted me
privately.

Oliver, please respond to the list. :)


package freeipa;

use strict;
use REST::Client;
use JSON;
use Data::Dumper;

our $VERSION="0.0.1";


BEGIN {
};


sub new
# Constructor of the class freeipa
{   my ($Class)=@_;
my $self= {};

bless($self,$Class);
$self->{'id'}=0;
return $self;
}   # sub news


sub set
# Setter of the class freeipa. At this moment only usuable or scalar values 
{   my $ipaObj=shift;
my $scalar=shift;
my $value=shift;

$ipaObj->{$scalar}=$value;
}   # sub set


sub connect
# Connects to the specified IPA server
{   my $ipaObj=shift;

my $headers = {
'Accept' => 'text/plain',
'Content-Type' => 'application/x-www-form-urlencoded',
'Referer' => $ipaObj->{'baseUrl'}
};  # my $headers

my $client=REST::Client->new();
my $params = $client->buildQuery({'user' => $ipaObj->{'user'}, 
'password' => $ipaObj->{'password'} });
$client->setHost($ipaObj->{'baseUrl'});
$client->POST("/ipa/session/login_password", substr($params,1), 
$headers);
$ipaObj->{'authCookie'} = $client->responseHeader('Set-Cookie');
$ipaObj->{'restClient'}=$client;
}   # sub connect


sub ipaMethod
# Calls an API method against the IPA connection
{   my $ipaObj=shift;
my $hashRef=shift;
my $data = {
'id'=>$ipaObj->{'id'},
'params' => [
[],
{ 'version' => 
$ipaObj->{'version'} }
]
};  # my $data
$ipaObj->{'id'}++;

my $headers = {
'Accept' => 'text/plain',
'Content-Type' => 'application/json',
'Cookie' => $ipaObj->{'authCookie'},
'Referer' => $ipaObj->{'baseUrl'}."/ipa/session/json"
};

# Copy the specified part of the method over the default data defined 
in $data
foreach my $var (keys (%{$hashRef})) { $data->{$var}=$hashRef->{$var}; }

# Format the method and data to json and make a REST request against 
the IPA server
my $jsonMethod = to_json($data);
$ipaObj->{'restClient'}->POST("/ipa/session/json", $jsonMethod, 
$headers);

# bring the JSON-formed response into perl objects...
my $restRet=from_json($ipaObj->{'restClient'}->responseContent());

# ... and return ist
return $restRet;
}   # sub ipaMethod

testConnection.pl
Description: Perl program
-- 
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] First tests against the REST/JSON API

[Oliver Dörr]

Hello,

just because I could answer my 2nd problem by myself. The truncated does 
not come from user_find API. It came from the perl JSON module, this is 
using this to write boolean variables. There is a special handling for 
boolean values inside this module which I have to implement.


Regards
Oliver

Am 10.11.2015 um 15:53 schrieb Oliver Dörr:

Hi Alexander,

sorry for responding you privately. This was not my intention; I just 
recognized that my mail program has two reply buttons (replay and 
reply to mailing list).


I've played a bit around with your code and implemented a small Perl 
module and a test script. They both work in my environment, however 
I'm still not happy with them.


What I don't like is...
1st, I need to provide my client version
2nd, I get the message  'truncated' => bless( do{\(my $o = 0)}, 
'JSON::PP::Boolean' ) from the user_find API
3rd, I do not know what the id is used for and so I'm unsure if I 
could automatically handle it in my Perl module


However they should be a help for others who wants use Perl-script to 
access IPA-API.


Anyway thanks for your help. This was what I need to get on the track.

Oliver

Am 10.11.2015 um 09:14 schrieb Alexander Bokovoy:

On Mon, 09 Nov 2015, Natxo Asenjo wrote:

hi,

On Mon, Nov 9, 2015 at 6:58 PM, Oliver Dörr  
wrote:



Hi,

I'm completly new to this list and the product behind it. I'm 
trying to
use perl to get a list from my IPA installation of all users that 
are on

the server.



unfortunately I cannot help you right now, but have you taken a look at
this blog post:

https://vda.li/en/posts/2015/05/28/talking-to-freeipa-api-with-sessions/ 



It could give you some pointers.

Share your code if you get it to work :-)

The code in my response (see other mail) works fine, Oliver contacted me
privately.

Oliver, please respond to the list. :)






-- 
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] krb5kdc will not start (kerberos authentication error)

[Rich Megginson]

On 11/10/2015 09:16 AM, Gronde, Christopher (Contractor) wrote:

Neither came back with anything

# ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b 
"dc=itmodev,dc=gov" '(uid=ldap/comipa01.itmodev.gov)'
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base 

Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error)

[Ludwig Krispenz]

it was a typo, try

nsslapd-accesslog-level

On 11/10/2015 03:53 PM, Gronde, Christopher (Contractor) wrote:

Ran into an error trying to set that

# ldapmodify -a -D "cn=directory manager" -W
Enter LDAP Password:
dn: cn=config
changetype: modify
replace: nsslapd-acesslog-level
: 260

modifying entry "cn=config"
ldap_modify: Server is unwilling to perform (53)
 additional info: Unknown attribute nsslapd-acesslog-level will be 
ignored

[root@comipa02 ~]# ldapmodify -a -D "cn=config" -W
Enter LDAP Password:
ldap_bind: Inappropriate authentication (48)

-Original Message-
From: Ludwig Krispenz [mailto:lkris...@redhat.com]
Sent: Tuesday, November 10, 2015 9:48 AM
To: Gronde, Christopher (Contractor) 
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication 
error)


On 11/10/2015 03:32 PM, Gronde, Christopher (Contractor) wrote:

How do I change that log setting?  Is that done in LDAP?  Using ldapmodify?

yes,
ldapmodify ...
dn: cn=config
changetype: modify
replace: nsslapd-acesslog-level
nsslapd-acesslog-level: 260

-Original Message-
From: freeipa-users-boun...@redhat.com
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Ludwig Krispenz
Sent: Tuesday, November 10, 2015 9:03 AM
To: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos
authentication error)


On 11/10/2015 02:40 PM, Alexander Bokovoy wrote:

On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote:

Where can I verify or change the credentials it is trying to use?
Is it my LDAP password?

No, according to your logs, it is your LDAP master trying to
replicate (push changes) to your LDAP replica:

[09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from
 to 
[09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl
version=3 mech=GSSAPI

err=49 could also be a result if the entry which is mapped from the principal 
is not found in the directory. A bit more info could be gained by enabling 
logging of internal searches.
Set nsslapd-acesslog-level: 260

and then look what internal searches are done during the gssapi
authentication

If that is true, it would be ldap/ Kerberos principal talking
to ldap/ Kerberos principal. If that fails, it means master
and replica KDCs have different understanding of both ldap/
and ldap/ keys which most likely means keys were rotated on
master and weren't propagated to replica.

How to solve it? One possibility is to set master's hostname as KDC
address in krb5.conf on replica, forcing LDAP server on replica to
use master's KDC. I'm absolutely not sure this will actually work but
at least it allows to see if we are indeed dealing with inconsistent
state of service principals' keys.


-Original Message-
From: Alexander Bokovoy [mailto:aboko...@redhat.com]
Sent: Tuesday, November 10, 2015 8:18 AM
To: Gronde, Christopher (Contractor) 
Cc: Rob Crittenden ; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos
authentication error)

On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote:

When I tried to start the service again I got no response from tail
of the log, but this is a repeating entry I see in the access log

[09/Nov/2015:15:01:04 -0500] conn=1 fd=64 slot=64 connection from
127.0.0.1 to 127.0.0.1
[09/Nov/2015:15:01:04 -0500] conn=1 op=-1 fd=64 closed - B1
[09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from
 to 
[09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl
version=3 mech=GSSAPI
[09/Nov/2015:15:02:01 -0500] conn=2 op=0 RESULT err=14 tag=97
nentries=0 etime=0, SASL bind in progress
[09/Nov/2015:15:02:01 -0500] conn=2 op=1 BIND dn="" method=sasl
version=3 mech=GSSAPI
[09/Nov/2015:15:02:01 -0500] conn=2 op=1 RESULT err=14 tag=97
nentries=0 etime=0, SASL bind in progress
[09/Nov/2015:15:02:01 -0500] conn=2 op=2 BIND dn="" method=sasl
version=3 mech=GSSAPI
[09/Nov/2015:15:02:01 -0500] conn=2 op=2 RESULT err=49 tag=97
nentries=0 etime=0
[09/Nov/2015:15:02:01 -0500] conn=2 op=3 UNBIND
[09/Nov/2015:15:02:01 -0500] conn=2 op=3 fd=64 closed - U1

Does anyone know what err=14 or err=49 are?

err=14 means SASL bind in progress -- i.e. multi-round processing is
ongoing. This is normal for SASL GSSAPI.

err=49 is wrong password or username, i.e. credentials were incorrect.
It may also mean that LDAP server side was unable to process
Kerberos negotiation due to not having a current Kerberos ticket for
own service
(LDAP) and trying to request it from the Kerberos KDC but Kerberos
KDC is down.


-Original Message-
From: Rob Crittenden [mailto:rcrit...@redhat.com]
Sent: Monday, November 09, 2015 3:26 PM
To: Gronde, Christopher (Contractor)
; Alexander Bokovoy

Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos
authentication error)

Gronde, 

[Freeipa-users] crl url redirecting to https

[Natxo Asenjo]

hi,

I just noticed some stuff was not functioning properly and it's because the
crl url is being redirected to https (centos 6.7).


$ curl http://kdc01.unix.domain.tld/ipa/crl/


301 Moved Permanently

Moved Permanently
The document has moved https://kdc01.unix.domain.tld/ipa/crl/
">here.

Apache/2.2.15 (CentOS) Server at kdc01.unix.domain.tld Port
80


This is ipa-rewrite.conf, it should not be happening, but it does:

$ cat ipa-rewrite.conf
# VERSION 3 - DO NOT REMOVE THIS LINE

RewriteEngine on

# By default forward all requests to /ipa. If you don't want IPA
# to be the default on your web server comment this line out.
RewriteRule ^/$ https://kdc01.unix.iriszorg.nl/ipa/ui [L,NC,R=301]

# Redirect to the fully-qualified hostname. Not redirecting to secure
# port so configuration files can be retrieved without requiring SSL.
RewriteCond %{HTTP_HOST}!^kdc01.unix.iriszorg.nl$ [NC]
RewriteRule ^/ipa/(.*)  http://kdc01.unix.iriszorg.nl/ipa/$1 [L,R=301]

# Redirect to the secure port if not displaying an error or retrieving
# configuration.
RewriteCond %{SERVER_PORT}  !^443$
RewriteCond %{REQUEST_URI}  !^/ipa/(errors|config)
RewriteRule ^/ipa/(.*)  https://kdc01.unix.iriszorg.nl/ipa/$1
[L,R=301,NC]

Any ideas on how to fix this?

Thanks!
--
Groeten,
natxo
-- 
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] crl url redirecting to https

[Rob Crittenden]

Natxo Asenjo wrote:
> hi,
> 
> I just noticed some stuff was not functioning properly and it's because
> the crl url is being redirected to https (centos 6.7).
> 
> 
> $ curl http://kdc01.unix.domain.tld/ipa/crl/
> 
> 
> 301 Moved Permanently
> 
> Moved Permanently
> The document has moved  href="https://kdc01.unix.domain.tld/ipa/crl/;>here.
> 
> Apache/2.2.15 (CentOS) Server at kdc01.unix.domain.tld Port
> 80
> 
> 
> This is ipa-rewrite.conf, it should not be happening, but it does:
> 
> $ cat ipa-rewrite.conf
> # VERSION 3 - DO NOT REMOVE THIS LINE
> 
> RewriteEngine on
> 
> # By default forward all requests to /ipa. If you don't want IPA
> # to be the default on your web server comment this line out.
> RewriteRule ^/$ https://kdc01.unix.iriszorg.nl/ipa/ui [L,NC,R=301]
> 
> # Redirect to the fully-qualified hostname. Not redirecting to secure
> # port so configuration files can be retrieved without requiring SSL.
> RewriteCond %{HTTP_HOST}!^kdc01.unix.iriszorg.nl
> $ [NC]
> RewriteRule ^/ipa/(.*)  http://kdc01.unix.iriszorg.nl/ipa/$1 [L,R=301]
> 
> # Redirect to the secure port if not displaying an error or retrieving
> # configuration.
> RewriteCond %{SERVER_PORT}  !^443$
> RewriteCond %{REQUEST_URI}  !^/ipa/(errors|config)
> RewriteRule ^/ipa/(.*)  https://kdc01.unix.iriszorg.nl/ipa/$1
> [L,R=301,NC]
> 
> Any ideas on how to fix this?

You should have a sections like these in /etc/httpd/conf.d/ipa.conf:


  SetHandler None

...
# For CRL publishing
Alias /ipa/crl "/var/lib/ipa/pki-ca/publish"

  SetHandler None
  AllowOverride None
  Options Indexes FollowSymLinks
  Satisfy Any
  Allow from all


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] krb5kdc will not start (kerberos authentication error)

[Gronde, Christopher (Contractor)]

Note comipa01 is the master and comipa02 is the replica that is having the KDC 
issue

# ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b 
"dc=itmodev,dc=gov" '(krbprincipalname=ldap/comipa01.itmodev.gov*)'
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base 

Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error)

[Rob Crittenden]

Gronde, Christopher (Contractor) wrote:
> This gave me a huge return!  Appears to be a long list of all the servers and 
> applications whose users authenticate to the IPA servers.
> 
> ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b 
> "dc=itmodev,dc=gov" '(objectclass=krbprincipal)'
> 
> 
> # search result
> search: 2
> result: 0 Success
> 
> # numResponses: 142
> # numEntries: 141

Right, we need to see the sasl mapping:

$ ldapsearch -x -D 'cn=Directory Manager' -W -b cn=mapping,cn=sasl,cn=config

rob

> 
> -Original Message-
> From: freeipa-users-boun...@redhat.com 
> [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Ludwig Krispenz
> Sent: Tuesday, November 10, 2015 11:37 AM
> To: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication 
> error)
> 
> what do you get if you search for "objectclass=krbprincipal" ?
> 
> On 11/10/2015 05:27 PM, Rich Megginson wrote:
>> On 11/10/2015 09:16 AM, Gronde, Christopher (Contractor) wrote:
>>> Neither came back with anything
>>>
>>> # ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b 
>>> "dc=itmodev,dc=gov" '(uid=ldap/comipa01.itmodev.gov)'
>>> Enter LDAP Password:
>>> # extended LDIF
>>> #
>>> # LDAPv3
>>> # base 

Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error)

[Ludwig Krispenz]

what do you get if you search for "objectclass=krbprincipal" ?

On 11/10/2015 05:27 PM, Rich Megginson wrote:

On 11/10/2015 09:16 AM, Gronde, Christopher (Contractor) wrote:

Neither came back with anything

# ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b 
"dc=itmodev,dc=gov" '(uid=ldap/comipa01.itmodev.gov)'

Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base 

Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error)

[Gronde, Christopher (Contractor)]

Ran into an error trying to set that

# ldapmodify -a -D "cn=directory manager" -W
Enter LDAP Password:
dn: cn=config
changetype: modify
replace: nsslapd-acesslog-level
nsslapd-acesslog-level: 260

modifying entry "cn=config"
ldap_modify: Server is unwilling to perform (53)
additional info: Unknown attribute nsslapd-acesslog-level will be 
ignored

[root@comipa02 ~]# ldapmodify -a -D "cn=config" -W
Enter LDAP Password:
ldap_bind: Inappropriate authentication (48)

-Original Message-
From: Ludwig Krispenz [mailto:lkris...@redhat.com] 
Sent: Tuesday, November 10, 2015 9:48 AM
To: Gronde, Christopher (Contractor) 
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication 
error)


On 11/10/2015 03:32 PM, Gronde, Christopher (Contractor) wrote:
> How do I change that log setting?  Is that done in LDAP?  Using ldapmodify?
yes,
ldapmodify ...
dn: cn=config
changetype: modify
replace: nsslapd-acesslog-level
nsslapd-acesslog-level: 260
>
> -Original Message-
> From: freeipa-users-boun...@redhat.com 
> [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Ludwig Krispenz
> Sent: Tuesday, November 10, 2015 9:03 AM
> To: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos 
> authentication error)
>
>
> On 11/10/2015 02:40 PM, Alexander Bokovoy wrote:
>> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote:
>>> Where can I verify or change the credentials it is trying to use?  
>>> Is it my LDAP password?
>> No, according to your logs, it is your LDAP master trying to 
>> replicate (push changes) to your LDAP replica:
 [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from 
  to 
 [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl
 version=3 mech=GSSAPI
> err=49 could also be a result if the entry which is mapped from the principal 
> is not found in the directory. A bit more info could be gained by enabling 
> logging of internal searches.
> Set nsslapd-acesslog-level: 260
>
> and then look what internal searches are done during the gssapi 
> authentication
>> If that is true, it would be ldap/ Kerberos principal talking 
>> to ldap/ Kerberos principal. If that fails, it means master 
>> and replica KDCs have different understanding of both ldap/ 
>> and ldap/ keys which most likely means keys were rotated on 
>> master and weren't propagated to replica.
>>
>> How to solve it? One possibility is to set master's hostname as KDC 
>> address in krb5.conf on replica, forcing LDAP server on replica to 
>> use master's KDC. I'm absolutely not sure this will actually work but 
>> at least it allows to see if we are indeed dealing with inconsistent 
>> state of service principals' keys.
>>
>>> -Original Message-
>>> From: Alexander Bokovoy [mailto:aboko...@redhat.com]
>>> Sent: Tuesday, November 10, 2015 8:18 AM
>>> To: Gronde, Christopher (Contractor) 
>>> Cc: Rob Crittenden ; freeipa-users@redhat.com
>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos 
>>> authentication error)
>>>
>>> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote:
 When I tried to start the service again I got no response from tail 
 of the log, but this is a repeating entry I see in the access log

 [09/Nov/2015:15:01:04 -0500] conn=1 fd=64 slot=64 connection from
 127.0.0.1 to 127.0.0.1
 [09/Nov/2015:15:01:04 -0500] conn=1 op=-1 fd=64 closed - B1
 [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from 
  to 
 [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl
 version=3 mech=GSSAPI
 [09/Nov/2015:15:02:01 -0500] conn=2 op=0 RESULT err=14 tag=97
 nentries=0 etime=0, SASL bind in progress
 [09/Nov/2015:15:02:01 -0500] conn=2 op=1 BIND dn="" method=sasl
 version=3 mech=GSSAPI
 [09/Nov/2015:15:02:01 -0500] conn=2 op=1 RESULT err=14 tag=97
 nentries=0 etime=0, SASL bind in progress
 [09/Nov/2015:15:02:01 -0500] conn=2 op=2 BIND dn="" method=sasl
 version=3 mech=GSSAPI
 [09/Nov/2015:15:02:01 -0500] conn=2 op=2 RESULT err=49 tag=97
 nentries=0 etime=0
 [09/Nov/2015:15:02:01 -0500] conn=2 op=3 UNBIND
 [09/Nov/2015:15:02:01 -0500] conn=2 op=3 fd=64 closed - U1

 Does anyone know what err=14 or err=49 are?
>>> err=14 means SASL bind in progress -- i.e. multi-round processing is 
>>> ongoing. This is normal for SASL GSSAPI.
>>>
>>> err=49 is wrong password or username, i.e. credentials were incorrect.
>>> It may also mean that LDAP server side was unable to process 
>>> Kerberos negotiation due to not having a current Kerberos ticket for 
>>> own service
>>> (LDAP) and trying to request it from the Kerberos KDC but Kerberos 
>>> KDC is down.
>>>
 -Original Message-
 From: Rob Crittenden [mailto:rcrit...@redhat.com]
 Sent: Monday, November 09, 2015 3:26 PM

Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error)

[Martin Babinsky]

On 11/10/2015 05:54 PM, Gronde, Christopher (Contractor) wrote:

# ldapsearch -x -D 'cn=Directory Manager' -W -b cn=mapping,cn=sasl,cn=config
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base 

Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error)

[Gronde, Christopher (Contractor)]

>> # Kerberos uid mapping, mapping, sasl, config
>> dn: cn=Kerberos uid mapping,cn=mapping,cn=sasl,cn=config
>> objectClass: top
>> objectClass: nsSaslMapping
>> cn: Kerberos uid mapping
>> nsSaslMapRegexString: \(.*\)@\(.*\)\.\(.*\)
>> nsSaslMapBaseDNTemplate: dc=\2,dc=\3
>> nsSaslMapFilterTemplate: (uid=\1)
>Looks like this mapping rule causes the issues with incorrectly mapped service 
>principals.

Any idea what I need to do to fix it?

-Original Message-
From: Martin Babinsky [mailto:mbabi...@redhat.com] 
Sent: Tuesday, November 10, 2015 12:03 PM
To: Gronde, Christopher (Contractor) ; Rob 
Crittenden ; Ludwig Krispenz ; 
freeipa-users@redhat.com
Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication 
error)

On 11/10/2015 05:54 PM, Gronde, Christopher (Contractor) wrote:
> # ldapsearch -x -D 'cn=Directory Manager' -W -b 
> cn=mapping,cn=sasl,cn=config Enter LDAP Password:
> # extended LDIF
> #
> # LDAPv3
> # base 

[Freeipa-users] Default shell for AD trust users

[Orion Poplawski]

I see that AD trust users don't get their posix shell set:

# getent passwd user
u...@ad.nwra.com:*:2260345:2260345:A User:/export/home/user:

I can fix this on the clients with override_shell, but that would apply to the
IPA domain users as well.  Is there some way to configure this in the
trust/server?

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

-- 
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] krb5kdc will not start (kerberos authentication error)

[Gronde, Christopher (Contractor)]

This is the mappings from the Master...it looks very different from the replica

# ldapsearch -x -D 'cn=Directory Manager' -W -b cn=mapping,cn=sasl,cn=config
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base 

Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error)

[Gronde, Christopher (Contractor)]

Removed the bad mapping.  Krb5kdc service still will not start.  Here is the 
access log.

[10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="ou=Netscape Directory 
Team,cn=monitor"
[10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 
etime=0
[10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 SRCH base="cn=SNMP,cn=config" 
scope=0 filter="(|(objectclass=*)(objectclass=ldapsubentry))" attrs=ALL
[10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 
etime=0
[10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 SRCH base="cn=uniqueid 
generator,cn=config" scope=0 filter="objectclass=*" attrs=ALL
[10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1 
etime=0
[10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 MOD dn="cn=uniqueid 
generator,cn=config"
[10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 
etime=0
[10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 SRCH base="cn=tasks,cn=config" 
scope=2 filter="(objectclass=*)" attrs=ALL
[10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 
nentries=15 etime=0
[10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 DEL 
dn="cn=upgradedb,cn=tasks,cn=config"
[10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 
etime=0
[10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 DEL dn="cn=syntax 
validate,cn=tasks,cn=config"
[10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 
etime=0
[10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 DEL dn="cn=schema reload 
task,cn=tasks,cn=config"
[10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 
etime=0
[10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 DEL 
dn="cn=restore,cn=tasks,cn=config"
[10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 
etime=0
[10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 DEL 
dn="cn=index,cn=tasks,cn=config"
[10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 
etime=0
[10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 DEL 
dn="cn=import,cn=tasks,cn=config"
[10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 
etime=0
[10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 DEL dn="cn=fixup linked 
attributes,cn=tasks,cn=config"
[10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 
etime=0
[10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 DEL 
dn="cn=export,cn=tasks,cn=config"
[10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 
etime=0
[10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 DEL 
dn="cn=cleanallruv,cn=tasks,cn=config"
[10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 
etime=0
[10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 DEL 
dn="cn=backup,cn=tasks,cn=config"
[10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 
etime=0
[10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 DEL dn="cn=automember rebuild 
membership,cn=tasks,cn=config"
[10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 
etime=0
[10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 DEL dn="cn=automember map 
updates,cn=tasks,cn=config"
[10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 
etime=0
[10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 DEL dn="cn=automember export 
updates,cn=tasks,cn=config"
[10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 
etime=0
[10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 DEL dn="cn=abort 
cleanallruv,cn=tasks,cn=config"
[10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=0 tag=48 nentries=0 
etime=0
[10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Binary 
Syntax,cn=plugins,cn=config"
[10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 
nentries=0 etime=0
[10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Bit String 
Syntax,cn=plugins,cn=config"
[10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 
nentries=0 etime=0
[10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Bitwise 
Plugin,cn=plugins,cn=config"
[10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 
nentries=0 etime=0
[10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Boolean 
Syntax,cn=plugins,cn=config"
[10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 
nentries=0 etime=0
[10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Case Exact String 
Syntax,cn=plugins,cn=config"
[10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 
nentries=0 etime=0
[10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Case Ignore String 
Syntax,cn=plugins,cn=config"
[10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 RESULT err=68 tag=48 
nentries=0 etime=0
[10/Nov/2015:14:12:16 -0500] conn=Internal op=-1 ADD dn="cn=Country String 
Syntax,cn=plugins,cn=config"

Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error)

[Rob Crittenden]

Gronde, Christopher (Contractor) wrote:
> Is it possible to delete the mapping and try it and if it doesn't work or 
> breaks something else add it back?  How would I go about deleting this 
> mapping?  Or adding the mapping for principal name in the right order?
> 

So what I'd do is this:

Do the same cn=mappping ldapsearch on the working master to see what the
differences are. Determine if this is an ordering problem or if there is
just extra gunk on this non-working master.

And compare the versions of 389-ds: rpm -q 389-ds-base. They should be
the same. If not then maybe one supports the new ordering and one doesn't.

Then:

1. Stop dirsrv
2. cp dse.ldif dse.ldif.mappings
3. edit dse.ldif to match your findings. Either re-order the entries or
remove ones you don't need (or both).
4. Start dirsrv
5. Start krb5kdc

Step 1 is super important because 389-ds writes dse.ldif on shutdown so
all changes made while the service is running will be lost.

You can also do this via ldapmodify but it is far easier and less error
prone to use your favorite editor in this case.

rob

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

Re: [Freeipa-users] Sync with SUN DS 5.2

[Seike neg]

I want a periodic sync, the ldap is the center of our user management, all 
credentials are stored there and updated by the HR dept.
But I need a kerberos server to deal with the windows clients to provide a kind 
of SSO.

> Date: Tue, 10 Nov 2015 10:39:10 -0500
> From: rcrit...@redhat.com
> To: se...@outlook.com; freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] Sync with SUN DS 5.2
> 
> Seike neg wrote:
> > Hello,
> > Is there a way to import users and password from SUN DS automatically 
> > (script, sync, etc...).
> > I have a SUN DS LDAP in the office and I want to do a read only sync from 
> > him to a brand new freeipa server.
> > The freeipa server is suppose to act as a kerberos, ldap slave and ntp 
> > server.
> >   
> > 
> 
> It's a little unclear what you want to do. Do you want a periodic sync
> or a one-time migration?
> 
> You can use ipa migrate-ds to migrate over LDAP. See
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/Migrating_from_a_Directory_Server_to_IPA.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

Re: [Freeipa-users] crl url redirecting to https

[Natxo Asenjo]

hi,

On Tue, Nov 10, 2015 at 5:02 PM, Rob Crittenden  wrote:

> Natxo Asenjo wrote:> Any ideas on how to fix this?
>
> You should have a sections like these in /etc/httpd/conf.d/ipa.conf:
>
> 
>   SetHandler None
> 
> ...
> # For CRL publishing
> Alias /ipa/crl "/var/lib/ipa/pki-ca/publish"
> 
>   SetHandler None
>   AllowOverride None
>   Options Indexes FollowSymLinks
>   Satisfy Any
>   Allow from all
> 
>

yes, it's all there. I restarted httpd just in case, but it remains the
same. I get a 301 moved permantently to https.

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

[Freeipa-users] FreeIPA and Windows

[Randolph Morgan]

I am certain that everyone gets tired of answering the same questions 
over and over, so maybe an update to the documentation would be better.  
I am trying to get my Windows machines to authenticate against a FreeIPA 
server running IPA 4.2+ on RHEL 7.  I have followed the documentation 
listed on 
https://www.freeipa.org/page/Windows_authentication_against_FreeIPA, but 
there seems to be a few steps missing.


In the Configure FreeIPA you are told to create a keytab for the Windows 
machine in question.  After creating the keytab, what do you do with 
it?  It jumps from creating the keytab to configuring Windows but does 
not say what to do with the keytab and the instructions never reference 
it again.  Would someone please clarify this and is this something we 
would need to do for each and every Windows machine on our network?


Randy

--
Randy Morgan
CSR
Department of Chemistry and Biochemistry
Brigham Young University
801-422-4100

--
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] krb5kdc will not start (kerberos authentication error)

[Ludwig Krispenz]

On 11/10/2015 06:08 PM, Gronde, Christopher (Contractor) wrote:

# Kerberos uid mapping, mapping, sasl, config
dn: cn=Kerberos uid mapping,cn=mapping,cn=sasl,cn=config
objectClass: top
objectClass: nsSaslMapping
cn: Kerberos uid mapping
nsSaslMapRegexString: \(.*\)@\(.*\)\.\(.*\)
nsSaslMapBaseDNTemplate: dc=\2,dc=\3
nsSaslMapFilterTemplate: (uid=\1)

Looks like this mapping rule causes the issues with incorrectly mapped service 
principals.

Any idea what I need to do to fix it?
I don't know where this mapping comes from and if it is needed, so one 
try would be to delete it.
Another attempt would be to change the order of the mappings, but this 
would mean to rename them


-Original Message-
From: Martin Babinsky [mailto:mbabi...@redhat.com]
Sent: Tuesday, November 10, 2015 12:03 PM
To: Gronde, Christopher (Contractor) ; Rob Crittenden 
; Ludwig Krispenz ; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication 
error)

On 11/10/2015 05:54 PM, Gronde, Christopher (Contractor) wrote:

# ldapsearch -x -D 'cn=Directory Manager' -W -b
cn=mapping,cn=sasl,cn=config Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base 

Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error)

[Rich Megginson]

On 11/10/2015 10:50 AM, Gronde, Christopher (Contractor) wrote:

Is it possible to delete the mapping and try it and if it doesn't work or 
breaks something else add it back?  How would I go about deleting this mapping? 
 Or adding the mapping for principal name in the right order?


http://www.port389.org/docs/389ds/design/sasl-mapping-improvements-1-dot-3-1.html

However, looking at your version: 
https://www.redhat.com/archives/freeipa-users/2015-November/msg00124.html


You are using EL6 389-ds-base 1.2.11.x, which does not support the above 
sasl mapping improvements.


I have no idea how IPA is supposed to handle this situation with 
389-ds-base 1.2.11.




-Original Message-
From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Rich Megginson
Sent: Tuesday, November 10, 2015 12:26 PM
To: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication 
error)

On 11/10/2015 10:25 AM, Ludwig Krispenz wrote:

On 11/10/2015 06:08 PM, Gronde, Christopher (Contractor) wrote:

# Kerberos uid mapping, mapping, sasl, config
dn: cn=Kerberos uid mapping,cn=mapping,cn=sasl,cn=config
objectClass: top
objectClass: nsSaslMapping
cn: Kerberos uid mapping
nsSaslMapRegexString: \(.*\)@\(.*\)\.\(.*\)
nsSaslMapBaseDNTemplate: dc=\2,dc=\3
nsSaslMapFilterTemplate: (uid=\1)

Looks like this mapping rule causes the issues with incorrectly
mapped service principals.

Any idea what I need to do to fix it?

I don't know where this mapping comes from and if it is needed, so one
try would be to delete it.
Another attempt would be to change the order of the mappings, but this
would mean to rename them

In the older code, the SASL mappings were applied in reverse alphabetical 
order, which is why cn=uid mapping,cn=mapping,cn=sasl,cn=config is being 
applied first.  I thought there had been changes to this, so that you could 
explicitly define the order in which the mappings were applied.


-Original Message-
From: Martin Babinsky [mailto:mbabi...@redhat.com]
Sent: Tuesday, November 10, 2015 12:03 PM
To: Gronde, Christopher (Contractor) ;
Rob Crittenden ; Ludwig Krispenz
; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos
authentication error)

On 11/10/2015 05:54 PM, Gronde, Christopher (Contractor) wrote:

# ldapsearch -x -D 'cn=Directory Manager' -W -b
cn=mapping,cn=sasl,cn=config Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base 

Re: [Freeipa-users] FreeIPA and Windows

[Loris Santamaria]

El mar, 10-11-2015 a las 11:18 -0700, Randolph Morgan escribió:
> I am certain that everyone gets tired of answering the same questions
> over and over, so maybe an update to the documentation would be
> better.  
> I am trying to get my Windows machines to authenticate against a
> FreeIPA 
> server running IPA 4.2+ on RHEL 7.  I have followed the documentation
> listed on 
> https://www.freeipa.org/page/Windows_authentication_against_FreeIPA,
> but 
> there seems to be a few steps missing.
> 
> In the Configure FreeIPA you are told to create a keytab for the
> Windows 
> machine in question.  After creating the keytab, what do you do with 
> it?  It jumps from creating the keytab to configuring Windows but
> does 
> not say what to do with the keytab and the instructions never
> reference 
> it again.  Would someone please clarify this and is this something we
> would need to do for each and every Windows machine on our network?

Note that the ipa-getkeytab command is called with the -P option, so it
asks for a password: that password is used as a password for the
machine principal and is stored in the directory.

So no, the keytab is not really used anywhere else and can be deleted.
It is the act of generating (with a known password) it that needs to be
done for every windows machine in the network. Please use strong,
random and different passwords for each windows machine in the network.


-- 
Loris Santamaria   linux user #70506   xmpp:lo...@lgs.com.ve
Links Global Services, C.A.http://www.lgs.com.ve
Tel: 0286 952.06.87  Cel: 0414 095.00.10  sip:1...@lgs.com.ve

"If I'd asked my customers what they wanted, they'd have said
a faster horse" - Henry Ford



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

Re: [Freeipa-users] crl url redirecting to https

[Natxo Asenjo]

but going back to ipa-rewrite.conf, these 2 seem contradictory:

# Redirect to the fully-qualified hostname. Not redirecting to secure
# port so configuration files can be retrieved without requiring SSL.
RewriteCond %{HTTP_HOST}!^kdc01.unix.iriszorg.nl$ [NC]
RewriteRule ^/ipa/(.*)  http://kdc01.unix.iriszorg.nl/ipa/$1 [L,R=301]

# Redirect to the secure port if not displaying an error or retrieving
# configuration.
RewriteCond %{SERVER_PORT}  !^443$
RewriteCond %{REQUEST_URI}  !^/ipa/(errors|config)
RewriteRule ^/ipa/(.*)  https://kdc01.unix.iriszorg.nl/ipa/$1
[L,R=301,NC]

so I modified

RewriteCond %{REQUEST_URI}  !^/ipa/(errors|config)

with

RewriteCond %{REQUEST_URI}  !^/ipa/(errors|config|crl)

and now it works.

Is this ok?
-- 
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] mastercrl files

[Natxo Asenjo]

hi,

do we need to keep all the MasterCRL-MMDD-HHMMSS.der files or can we
purge them on a regular basis (say, keep 60 days dump the rest)?

$ ls -l | wc -l
3621

this is in a server installed 3 years ago.

--
Groeten,
natxo
-- 
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] krb5kdc will not start (kerberos authentication error)

[Rich Megginson]

On 11/10/2015 10:25 AM, Ludwig Krispenz wrote:


On 11/10/2015 06:08 PM, Gronde, Christopher (Contractor) wrote:

# Kerberos uid mapping, mapping, sasl, config
dn: cn=Kerberos uid mapping,cn=mapping,cn=sasl,cn=config
objectClass: top
objectClass: nsSaslMapping
cn: Kerberos uid mapping
nsSaslMapRegexString: \(.*\)@\(.*\)\.\(.*\)
nsSaslMapBaseDNTemplate: dc=\2,dc=\3
nsSaslMapFilterTemplate: (uid=\1)
Looks like this mapping rule causes the issues with incorrectly 
mapped service principals.

Any idea what I need to do to fix it?
I don't know where this mapping comes from and if it is needed, so one 
try would be to delete it.
Another attempt would be to change the order of the mappings, but this 
would mean to rename them


In the older code, the SASL mappings were applied in reverse 
alphabetical order, which is why cn=uid 
mapping,cn=mapping,cn=sasl,cn=config is being applied first.  I thought 
there had been changes to this, so that you could explicitly define the 
order in which the mappings were applied.




-Original Message-
From: Martin Babinsky [mailto:mbabi...@redhat.com]
Sent: Tuesday, November 10, 2015 12:03 PM
To: Gronde, Christopher (Contractor) ; 
Rob Crittenden ; Ludwig Krispenz 
; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos 
authentication error)


On 11/10/2015 05:54 PM, Gronde, Christopher (Contractor) wrote:

# ldapsearch -x -D 'cn=Directory Manager' -W -b
cn=mapping,cn=sasl,cn=config Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base 

Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error)

[Gronde, Christopher (Contractor)]

Is it possible to delete the mapping and try it and if it doesn't work or 
breaks something else add it back?  How would I go about deleting this mapping? 
 Or adding the mapping for principal name in the right order?

-Original Message-
From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Rich Megginson
Sent: Tuesday, November 10, 2015 12:26 PM
To: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication 
error)

On 11/10/2015 10:25 AM, Ludwig Krispenz wrote:
>
> On 11/10/2015 06:08 PM, Gronde, Christopher (Contractor) wrote:
 # Kerberos uid mapping, mapping, sasl, config
 dn: cn=Kerberos uid mapping,cn=mapping,cn=sasl,cn=config
 objectClass: top
 objectClass: nsSaslMapping
 cn: Kerberos uid mapping
 nsSaslMapRegexString: \(.*\)@\(.*\)\.\(.*\)
 nsSaslMapBaseDNTemplate: dc=\2,dc=\3
 nsSaslMapFilterTemplate: (uid=\1)
>>> Looks like this mapping rule causes the issues with incorrectly 
>>> mapped service principals.
>> Any idea what I need to do to fix it?
> I don't know where this mapping comes from and if it is needed, so one 
> try would be to delete it.
> Another attempt would be to change the order of the mappings, but this 
> would mean to rename them

In the older code, the SASL mappings were applied in reverse alphabetical 
order, which is why cn=uid mapping,cn=mapping,cn=sasl,cn=config is being 
applied first.  I thought there had been changes to this, so that you could 
explicitly define the order in which the mappings were applied.

>>
>> -Original Message-
>> From: Martin Babinsky [mailto:mbabi...@redhat.com]
>> Sent: Tuesday, November 10, 2015 12:03 PM
>> To: Gronde, Christopher (Contractor) ; 
>> Rob Crittenden ; Ludwig Krispenz 
>> ; freeipa-users@redhat.com
>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos 
>> authentication error)
>>
>> On 11/10/2015 05:54 PM, Gronde, Christopher (Contractor) wrote:
>>> # ldapsearch -x -D 'cn=Directory Manager' -W -b 
>>> cn=mapping,cn=sasl,cn=config Enter LDAP Password:
>>> # extended LDIF
>>> #
>>> # LDAPv3
>>> # base 

Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error)

[Ludwig Krispenz]

On 11/10/2015 06:26 PM, Rich Megginson wrote:

On 11/10/2015 10:25 AM, Ludwig Krispenz wrote:


On 11/10/2015 06:08 PM, Gronde, Christopher (Contractor) wrote:

# Kerberos uid mapping, mapping, sasl, config
dn: cn=Kerberos uid mapping,cn=mapping,cn=sasl,cn=config
objectClass: top
objectClass: nsSaslMapping
cn: Kerberos uid mapping
nsSaslMapRegexString: \(.*\)@\(.*\)\.\(.*\)
nsSaslMapBaseDNTemplate: dc=\2,dc=\3
nsSaslMapFilterTemplate: (uid=\1)
Looks like this mapping rule causes the issues with incorrectly 
mapped service principals.

Any idea what I need to do to fix it?
I don't know where this mapping comes from and if it is needed, so 
one try would be to delete it.
Another attempt would be to change the order of the mappings, but 
this would mean to rename them


In the older code, the SASL mappings were applied in reverse 
alphabetical order, which is why cn=uid 
mapping,cn=mapping,cn=sasl,cn=config is being applied first.  I 
thought there had been changes to this, so that you could explicitly 
define the order in which the mappings were applied.
yes, there is a saslmapPriority, but this is 1.2.11, don't know what you 
mean by Old :-)




-Original Message-
From: Martin Babinsky [mailto:mbabi...@redhat.com]
Sent: Tuesday, November 10, 2015 12:03 PM
To: Gronde, Christopher (Contractor) 
; Rob Crittenden 
; Ludwig Krispenz ; 
freeipa-users@redhat.com
Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos 
authentication error)


On 11/10/2015 05:54 PM, Gronde, Christopher (Contractor) wrote:

# ldapsearch -x -D 'cn=Directory Manager' -W -b
cn=mapping,cn=sasl,cn=config Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base 

Re: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl

[Fraser Tweedale]

On Tue, Nov 10, 2015 at 03:12:04PM -0800, Prasun Gera wrote:
> I tried using let's encrypt's certs manually, but I think I'm missing
> something. Let's encrypt creates the following files : cert.pem  chain.pem
>  fullchain.pem  privkey.pem. I was trying to follow
> http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP but i
> wasn't able to get it to work. That page says, "The certificate in
> mysite.crt must be signed by the CA used when installing FreeIPA." Since my
> ipa installation uses the default internal CA, how do I get lets encrypt's
> certs signed by the ipa CA ? Is that the missing step ?
> 
I do not think that text is correct, in the case of a
publicy-trusted certificate (i.e. the server cert is chained to a
trusted issuer).

Just ignore that text and follow the steps.  Does it work?

Cheers,
Fraser

> On Sat, Nov 7, 2015 at 9:15 PM, Prasun Gera  wrote:
> 
> > Thanks for the discussion. If someone can update the documentation with
> > mozilla style old, intermediate and modern cipher lists for mod_nss, that
> > would be great. Better still would be to add that option to the installer
> > scripts so that you can choose it during installation. Integrating that in
> > the package would also have the added benefit of settings remaining up to
> > date without manual intervention as standards evolve.
> >
> > On Thu, Nov 5, 2015 at 9:23 PM, Fraser Tweedale 
> > wrote:
> >
> >> On Thu, Nov 05, 2015 at 11:52:32PM -0500, Rob Crittenden wrote:
> >> > Prasun Gera wrote:
> >> > > Thanks. After the changes, most things seem to be in order. I see two
> >> > > orange flags though:
> >> > >
> >> > > Secure Client-Initiated Renegotiation   *Supported*   *DoS
> >> DANGER* (more
> >> > > info
> >> > > <
> >> https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks
> >> >)
> >> >
> >> > Renegotiation is required for the CA so you need to leave this enabled.
> >> >
> >> > > Session resumption (caching)*No (IDs assigned but not
> >> accepted)*
> >> >
> >> > I'll need to look at this in more detail. At worst it would slow new
> >> > connection performance slightly as it means every connection requires a
> >> > full SSL/TLS handshake. I don't think it's a show-stopper.
> >> >
> >> Definitely not a show-stopper.  The main reason this is an "orange"
> >> alert in SSLLabs is because the server is assigning Session IDs but
> >> then ignoring them; although confusing it is a fairly common default
> >> behaviour and doesn't cause any issues with compliant client
> >> implementation
> >>
> >> > rob
> >> >
> >> > >
> >> > > Are these relevant/serious ? Can they be mitigated ?
> >> > >
> >> > >
> >> > > On Thu, Nov 5, 2015 at 6:51 AM, Rob Crittenden  >> > > > wrote:
> >> > >
> >> > > Prasun Gera wrote:
> >> > > > Yes, that's what I was planning to do. i.e. Convert cipher
> >> names from
> >> > > > SSL to NSS. I wasn't sure about the other settings though. Is
> >> there an
> >> > > > equivalent NSSHonorCipherOrder ? Is that implicit ? Similarly,
> >> are there
> >> > > > equivalent configs for HSTS on the mozilla page? Does NSS allow
> >> using
> >> > > > generated DH parameters instead of standard ones ? For SSL, the
> >> > > > suggested modification to the config is 'SSLOpenSSLConfCmd
> >> DHParameters
> >> > > > "{path to dhparams.pem}"' after generating the params.
> >> > >
> >> > > NSS does not let the user specify cipher order. It uses its own
> >> internal
> >> > > sorting from strongest to weakest.
> >> > >
> >> > > HSTS is a header and not dependent upon SSL provider.
> >> > >
> >> > > mod_nss doesn't support DH ciphers.
> >> > >
> >> > > rob
> >> > >
> >> > > >
> >> > > > On Wed, Nov 4, 2015 at 8:21 PM, Fraser Tweedale <
> >> ftwee...@redhat.com 
> >> > > > >>
> >> wrote:
> >> > > >
> >> > > > On Wed, Nov 04, 2015 at 05:03:29PM -0800, Prasun Gera wrote:
> >> > > > > Thanks for the ticket information. I would still be
> >> interested in
> >> > > > > configuring mod_nss properly (irrespective of whether the
> >> certs are ipa
> >> > > > > generated or 3rd party). These are the worrying notes
> >> from ssllabs test:
> >> > > > >
> >> > > > > The server supports only older protocols, but not the
> >> current best TLS 1.2.
> >> > > > > Grade capped to C.
> >> > > > > This server accepts the RC4 cipher, which is weak. Grade
> >> capped to B.
> >> > > > > The server does not support Forward Secrecy with the
> >> reference browsers.
> >> > > > >
> >> > > > Use the "Modern" cipher suite[1] recommended by Mozilla as a
> >> > > > starting point.  See also the "Cipher names correspondence
> >> table" on
> >> > > 

Re: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl

[Prasun Gera]

No it didn't quite work.

I ran ipa-server-certinstall -w /etc/letsencrypt/live/
example.com/privkey.pem /etc/letsencrypt/live/example.com/fullchain.pem

which gives The full certificate chain is not present in
/etc/letsencrypt/live/example.com/privkey.pem, /etc/letsencrypt/live/
example.com/fullchain.pem


On Tue, Nov 10, 2015 at 3:31 PM, Fraser Tweedale 
wrote:

> On Tue, Nov 10, 2015 at 03:12:04PM -0800, Prasun Gera wrote:
> > I tried using let's encrypt's certs manually, but I think I'm missing
> > something. Let's encrypt creates the following files : cert.pem
> chain.pem
> >  fullchain.pem  privkey.pem. I was trying to follow
> > http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP
> but i
> > wasn't able to get it to work. That page says, "The certificate in
> > mysite.crt must be signed by the CA used when installing FreeIPA." Since
> my
> > ipa installation uses the default internal CA, how do I get lets
> encrypt's
> > certs signed by the ipa CA ? Is that the missing step ?
> >
> I do not think that text is correct, in the case of a
> publicy-trusted certificate (i.e. the server cert is chained to a
> trusted issuer).
>
> Just ignore that text and follow the steps.  Does it work?
>
> Cheers,
> Fraser
>
> > On Sat, Nov 7, 2015 at 9:15 PM, Prasun Gera 
> wrote:
> >
> > > Thanks for the discussion. If someone can update the documentation with
> > > mozilla style old, intermediate and modern cipher lists for mod_nss,
> that
> > > would be great. Better still would be to add that option to the
> installer
> > > scripts so that you can choose it during installation. Integrating
> that in
> > > the package would also have the added benefit of settings remaining up
> to
> > > date without manual intervention as standards evolve.
> > >
> > > On Thu, Nov 5, 2015 at 9:23 PM, Fraser Tweedale 
> > > wrote:
> > >
> > >> On Thu, Nov 05, 2015 at 11:52:32PM -0500, Rob Crittenden wrote:
> > >> > Prasun Gera wrote:
> > >> > > Thanks. After the changes, most things seem to be in order. I see
> two
> > >> > > orange flags though:
> > >> > >
> > >> > > Secure Client-Initiated Renegotiation   *Supported*   *DoS
> > >> DANGER* (more
> > >> > > info
> > >> > > <
> > >>
> https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks
> > >> >)
> > >> >
> > >> > Renegotiation is required for the CA so you need to leave this
> enabled.
> > >> >
> > >> > > Session resumption (caching)*No (IDs assigned but not
> > >> accepted)*
> > >> >
> > >> > I'll need to look at this in more detail. At worst it would slow new
> > >> > connection performance slightly as it means every connection
> requires a
> > >> > full SSL/TLS handshake. I don't think it's a show-stopper.
> > >> >
> > >> Definitely not a show-stopper.  The main reason this is an "orange"
> > >> alert in SSLLabs is because the server is assigning Session IDs but
> > >> then ignoring them; although confusing it is a fairly common default
> > >> behaviour and doesn't cause any issues with compliant client
> > >> implementation
> > >>
> > >> > rob
> > >> >
> > >> > >
> > >> > > Are these relevant/serious ? Can they be mitigated ?
> > >> > >
> > >> > >
> > >> > > On Thu, Nov 5, 2015 at 6:51 AM, Rob Crittenden <
> rcrit...@redhat.com
> > >> > > > wrote:
> > >> > >
> > >> > > Prasun Gera wrote:
> > >> > > > Yes, that's what I was planning to do. i.e. Convert cipher
> > >> names from
> > >> > > > SSL to NSS. I wasn't sure about the other settings though.
> Is
> > >> there an
> > >> > > > equivalent NSSHonorCipherOrder ? Is that implicit ?
> Similarly,
> > >> are there
> > >> > > > equivalent configs for HSTS on the mozilla page? Does NSS
> allow
> > >> using
> > >> > > > generated DH parameters instead of standard ones ? For SSL,
> the
> > >> > > > suggested modification to the config is 'SSLOpenSSLConfCmd
> > >> DHParameters
> > >> > > > "{path to dhparams.pem}"' after generating the params.
> > >> > >
> > >> > > NSS does not let the user specify cipher order. It uses its
> own
> > >> internal
> > >> > > sorting from strongest to weakest.
> > >> > >
> > >> > > HSTS is a header and not dependent upon SSL provider.
> > >> > >
> > >> > > mod_nss doesn't support DH ciphers.
> > >> > >
> > >> > > rob
> > >> > >
> > >> > > >
> > >> > > > On Wed, Nov 4, 2015 at 8:21 PM, Fraser Tweedale <
> > >> ftwee...@redhat.com 
> > >> > > > >>
> > >> wrote:
> > >> > > >
> > >> > > > On Wed, Nov 04, 2015 at 05:03:29PM -0800, Prasun Gera
> wrote:
> > >> > > > > Thanks for the ticket information. I would still be
> > >> interested in
> > >> > > > > configuring mod_nss properly (irrespective of whether
> the
> > >> certs are ipa
> > >> > > > > generated or 

Re: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl

[Prasun Gera]

I tried using let's encrypt's certs manually, but I think I'm missing
something. Let's encrypt creates the following files : cert.pem  chain.pem
 fullchain.pem  privkey.pem. I was trying to follow
http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP but i
wasn't able to get it to work. That page says, "The certificate in
mysite.crt must be signed by the CA used when installing FreeIPA." Since my
ipa installation uses the default internal CA, how do I get lets encrypt's
certs signed by the ipa CA ? Is that the missing step ?

On Sat, Nov 7, 2015 at 9:15 PM, Prasun Gera  wrote:

> Thanks for the discussion. If someone can update the documentation with
> mozilla style old, intermediate and modern cipher lists for mod_nss, that
> would be great. Better still would be to add that option to the installer
> scripts so that you can choose it during installation. Integrating that in
> the package would also have the added benefit of settings remaining up to
> date without manual intervention as standards evolve.
>
> On Thu, Nov 5, 2015 at 9:23 PM, Fraser Tweedale 
> wrote:
>
>> On Thu, Nov 05, 2015 at 11:52:32PM -0500, Rob Crittenden wrote:
>> > Prasun Gera wrote:
>> > > Thanks. After the changes, most things seem to be in order. I see two
>> > > orange flags though:
>> > >
>> > > Secure Client-Initiated Renegotiation   *Supported*   *DoS
>> DANGER* (more
>> > > info
>> > > <
>> https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks
>> >)
>> >
>> > Renegotiation is required for the CA so you need to leave this enabled.
>> >
>> > > Session resumption (caching)*No (IDs assigned but not
>> accepted)*
>> >
>> > I'll need to look at this in more detail. At worst it would slow new
>> > connection performance slightly as it means every connection requires a
>> > full SSL/TLS handshake. I don't think it's a show-stopper.
>> >
>> Definitely not a show-stopper.  The main reason this is an "orange"
>> alert in SSLLabs is because the server is assigning Session IDs but
>> then ignoring them; although confusing it is a fairly common default
>> behaviour and doesn't cause any issues with compliant client
>> implementation
>>
>> > rob
>> >
>> > >
>> > > Are these relevant/serious ? Can they be mitigated ?
>> > >
>> > >
>> > > On Thu, Nov 5, 2015 at 6:51 AM, Rob Crittenden > > > > wrote:
>> > >
>> > > Prasun Gera wrote:
>> > > > Yes, that's what I was planning to do. i.e. Convert cipher
>> names from
>> > > > SSL to NSS. I wasn't sure about the other settings though. Is
>> there an
>> > > > equivalent NSSHonorCipherOrder ? Is that implicit ? Similarly,
>> are there
>> > > > equivalent configs for HSTS on the mozilla page? Does NSS allow
>> using
>> > > > generated DH parameters instead of standard ones ? For SSL, the
>> > > > suggested modification to the config is 'SSLOpenSSLConfCmd
>> DHParameters
>> > > > "{path to dhparams.pem}"' after generating the params.
>> > >
>> > > NSS does not let the user specify cipher order. It uses its own
>> internal
>> > > sorting from strongest to weakest.
>> > >
>> > > HSTS is a header and not dependent upon SSL provider.
>> > >
>> > > mod_nss doesn't support DH ciphers.
>> > >
>> > > rob
>> > >
>> > > >
>> > > > On Wed, Nov 4, 2015 at 8:21 PM, Fraser Tweedale <
>> ftwee...@redhat.com 
>> > > > >>
>> wrote:
>> > > >
>> > > > On Wed, Nov 04, 2015 at 05:03:29PM -0800, Prasun Gera wrote:
>> > > > > Thanks for the ticket information. I would still be
>> interested in
>> > > > > configuring mod_nss properly (irrespective of whether the
>> certs are ipa
>> > > > > generated or 3rd party). These are the worrying notes
>> from ssllabs test:
>> > > > >
>> > > > > The server supports only older protocols, but not the
>> current best TLS 1.2.
>> > > > > Grade capped to C.
>> > > > > This server accepts the RC4 cipher, which is weak. Grade
>> capped to B.
>> > > > > The server does not support Forward Secrecy with the
>> reference browsers.
>> > > > >
>> > > > Use the "Modern" cipher suite[1] recommended by Mozilla as a
>> > > > starting point.  See also the "Cipher names correspondence
>> table" on
>> > > > the same page for translating it to cipher names understood
>> by NSS
>> > > > to construct a valid setting for the `NSSCipherSuite'
>> directive.
>> > > >
>> > > > [1]
>> > > >
>> https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility
>> > > >
>> > > > Cheers,
>> > > > Fraser
>> > > >
>> > > > >
>> > > > > On Wed, Nov 4, 2015 at 4:44 PM, Fraser Tweedale
>> > > > 

Re: [Freeipa-users] First tests against the REST/JSON API

[Alexander Bokovoy]

On Mon, 09 Nov 2015, Natxo Asenjo wrote:

hi,

On Mon, Nov 9, 2015 at 6:58 PM, Oliver Dörr  wrote:


Hi,

I'm completly new to this list and the product behind it. I'm trying to
use perl to get a list from my IPA installation of all users that are on
the server.



unfortunately I cannot help you right now, but have you taken a look at
this blog post:

https://vda.li/en/posts/2015/05/28/talking-to-freeipa-api-with-sessions/

It could give you some pointers.

Share your code if you get it to work :-)

The code in my response (see other mail) works fine, Oliver contacted me
privately.

Oliver, please respond to the list. :)
--
/ 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] let's encrypt integration and best practices for mod_nss/mod_ssl

[Fraser Tweedale]

On Tue, Nov 10, 2015 at 03:44:19PM -0800, Prasun Gera wrote:
> No it didn't quite work.
> 
> I ran ipa-server-certinstall -w /etc/letsencrypt/live/
> example.com/privkey.pem /etc/letsencrypt/live/example.com/fullchain.pem
> 
> which gives The full certificate chain is not present in
> /etc/letsencrypt/live/example.com/privkey.pem, /etc/letsencrypt/live/
> example.com/fullchain.pem
> 
It looks like this error is triggered when there is no self-signed
certificate in the trust chain (fullchain.pem).  Could you confirm
that this is the case, and if so, could you try appending the root
certificate to fullchain.pem and trying again?

It may be that ipa-server-certinstall assumes that your server certs
are signed by the same CA as your IPA CA certificate, which need not
be the case.

> 
> On Tue, Nov 10, 2015 at 3:31 PM, Fraser Tweedale 
> wrote:
> 
> > On Tue, Nov 10, 2015 at 03:12:04PM -0800, Prasun Gera wrote:
> > > I tried using let's encrypt's certs manually, but I think I'm missing
> > > something. Let's encrypt creates the following files : cert.pem
> > chain.pem
> > >  fullchain.pem  privkey.pem. I was trying to follow
> > > http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP
> > but i
> > > wasn't able to get it to work. That page says, "The certificate in
> > > mysite.crt must be signed by the CA used when installing FreeIPA." Since
> > my
> > > ipa installation uses the default internal CA, how do I get lets
> > encrypt's
> > > certs signed by the ipa CA ? Is that the missing step ?
> > >
> > I do not think that text is correct, in the case of a
> > publicy-trusted certificate (i.e. the server cert is chained to a
> > trusted issuer).
> >
> > Just ignore that text and follow the steps.  Does it work?
> >
> > Cheers,
> > Fraser
> >
> > > On Sat, Nov 7, 2015 at 9:15 PM, Prasun Gera 
> > wrote:
> > >
> > > > Thanks for the discussion. If someone can update the documentation with
> > > > mozilla style old, intermediate and modern cipher lists for mod_nss,
> > that
> > > > would be great. Better still would be to add that option to the
> > installer
> > > > scripts so that you can choose it during installation. Integrating
> > that in
> > > > the package would also have the added benefit of settings remaining up
> > to
> > > > date without manual intervention as standards evolve.
> > > >
> > > > On Thu, Nov 5, 2015 at 9:23 PM, Fraser Tweedale 
> > > > wrote:
> > > >
> > > >> On Thu, Nov 05, 2015 at 11:52:32PM -0500, Rob Crittenden wrote:
> > > >> > Prasun Gera wrote:
> > > >> > > Thanks. After the changes, most things seem to be in order. I see
> > two
> > > >> > > orange flags though:
> > > >> > >
> > > >> > > Secure Client-Initiated Renegotiation   *Supported*   *DoS
> > > >> DANGER* (more
> > > >> > > info
> > > >> > > <
> > > >>
> > https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks
> > > >> >)
> > > >> >
> > > >> > Renegotiation is required for the CA so you need to leave this
> > enabled.
> > > >> >
> > > >> > > Session resumption (caching)*No (IDs assigned but not
> > > >> accepted)*
> > > >> >
> > > >> > I'll need to look at this in more detail. At worst it would slow new
> > > >> > connection performance slightly as it means every connection
> > requires a
> > > >> > full SSL/TLS handshake. I don't think it's a show-stopper.
> > > >> >
> > > >> Definitely not a show-stopper.  The main reason this is an "orange"
> > > >> alert in SSLLabs is because the server is assigning Session IDs but
> > > >> then ignoring them; although confusing it is a fairly common default
> > > >> behaviour and doesn't cause any issues with compliant client
> > > >> implementation
> > > >>
> > > >> > rob
> > > >> >
> > > >> > >
> > > >> > > Are these relevant/serious ? Can they be mitigated ?
> > > >> > >
> > > >> > >
> > > >> > > On Thu, Nov 5, 2015 at 6:51 AM, Rob Crittenden <
> > rcrit...@redhat.com
> > > >> > > > wrote:
> > > >> > >
> > > >> > > Prasun Gera wrote:
> > > >> > > > Yes, that's what I was planning to do. i.e. Convert cipher
> > > >> names from
> > > >> > > > SSL to NSS. I wasn't sure about the other settings though.
> > Is
> > > >> there an
> > > >> > > > equivalent NSSHonorCipherOrder ? Is that implicit ?
> > Similarly,
> > > >> are there
> > > >> > > > equivalent configs for HSTS on the mozilla page? Does NSS
> > allow
> > > >> using
> > > >> > > > generated DH parameters instead of standard ones ? For SSL,
> > the
> > > >> > > > suggested modification to the config is 'SSLOpenSSLConfCmd
> > > >> DHParameters
> > > >> > > > "{path to dhparams.pem}"' after generating the params.
> > > >> > >
> > > >> > > NSS does not let the user specify cipher order. It uses its
> > own
> > > >> internal
> > > >> > > sorting from strongest to weakest.
> > > >> > >
> > > >> > > HSTS is a header and not 

Re: [Freeipa-users] FreeIPA and Windows

[David Kreitschmann]

If you use the MSLSA credential cache MIT kerberos works.
kinit -c MSLSA: user@REALM

Not sure about the MIT ticket manager.




Am 11.11.2015 um 01:54 schrieb Loris Santamaria :
> 
> 
> El mar, 10-11-2015 a las 16:15 -0700, Randolph Morgan escribió:
>> Yes they are in the same DNS domain as the IPAserver.  I am able to 
>> resolve the server address.  Which side would you like more
>> information 
>> on the server side or the client side.  We are not running any AD 
>> domains, so this is not a Windows based system.  We are running
>> FreeIPA 
>> 4.2+ on RHEL 7.1 using the stock Samba from RHEL.  On the client side
>> I 
>> am running Windows 10 and I have installed MIT Kerberos version
>> 4.01.  
>> In the MIT ticket manager I show a tgt and it works as it
>> should.  But 
>> from the command prompt in windows if I do a klist it reports:
>>  Current 
>> LogonId is 0:0x6320a
>> 
>>  Cached 
>> Tickets: (0)
>> 
>> So even though MIT Kerberos shows a successful negotiation with IPA
>> and 
>> a ticket is received, windows reports back the above when a klist is 
>> run. 
> 
> I think that is the problem, you shouldn't use MIT kerberos.
> 
> The commands listed on the howto:
> 
> 1. ksetup /setdomain [REALM NAME]
> 2. ksetup /addkdc [REALM NAME] [kdc DNS name]
> 3. ksetup /addkpasswd [REALM NAME] [kdc DNS name]
> 4. ksetup /setcomputerpassword [MACHINE_PASSWORD] (the one used above)
> 5. ksetup /mapuser * *
> 
> are meant to be run with windows native ksetup command. The native
> windows kerberos libraries cannot see tickets obtained with MT
> kerberos.
> 
> Best regards
> 
> 
>>  What I am trying to do is get the two to talk to each other, but I 
>> have not had any success as of yet.  I have edited the krb5.ini with
>> the 
>> correct information, and rebooted the machine multiple times with no 
>> change.  Any help here would be really appreciated, we are taking
>> this 
>> system live over the weekend and would really love to have this part
>> fixed.
>> 
>> Randy
>> 
>> Randy Morgan
>> CSR
>> Department of Chemistry and Biochemistry
>> Brigham Young University
>> 801-422-4100
>> 
>> On 11/10/2015 3:50 PM, Loris Santamaria wrote:
>>> El mar, 10-11-2015 a las 11:51 -0700, Randolph Morgan escribió:
 Ok, that makes sense, but could we not just create the host in
 the
 IPA
 UI as part of the DNS?
>>> That isn't enough, the dns object just maps to an ip address, you
>>> have
>>> to create a "host" object with ipa host-add, that object is needed
>>> to
>>> store kerberos principal and password for the host.
>>> 
 Also we seem to be having some difficulty with
 another part of the process, that is getting the Windows machines
 to
 even acknowledge that they have the ability to talk with the kdc.
 Following the commands yields only that the windows machine is
 unable
 to
 locate the kdc, are we missing something?  Is this one of the
 issues
 related to different versions of Kerberos, e.g. MIT vs Heimdal.
>>> You should check for dns inconsistencies first, are the windows
>>> machines in the same dns domain as windows? Can they solve the
>>> addresses of the ipa servers? If that doesn't help you should post
>>> more
>>> details of your setup...
>>> 
>>> Best regards
>>> 
>>> 
 On 11/10/2015 11:32 AM, Loris Santamaria wrote:
> El mar, 10-11-2015 a las 11:18 -0700, Randolph Morgan escribió:
>> I am certain that everyone gets tired of answering the same
>> questions
>> over and over, so maybe an update to the documentation would
>> be
>> better.
>> I am trying to get my Windows machines to authenticate
>> against a
>> FreeIPA
>> server running IPA 4.2+ on RHEL 7.  I have followed the
>> documentation
>> listed on
>> https://www.freeipa.org/page/Windows_authentication_against_F
>> reeI
>> PA,
>> but
>> there seems to be a few steps missing.
>> 
>> In the Configure FreeIPA you are told to create a keytab for
>> the
>> Windows
>> machine in question.  After creating the keytab, what do you
>> do
>> with
>> it?  It jumps from creating the keytab to configuring Windows
>> but
>> does
>> not say what to do with the keytab and the instructions never
>> reference
>> it again.  Would someone please clarify this and is this
>> something we
>> would need to do for each and every Windows machine on our
>> network?
> Note that the ipa-getkeytab command is called with the -P
> option,
> so it
> asks for a password: that password is used as a password for
> the
> machine principal and is stored in the directory.
> 
> So no, the keytab is not really used anywhere else and can be
> deleted.
> It is the act of generating (with a known password) it that
> needs
> 

Re: [Freeipa-users] FreeIPA and Windows

[Loris Santamaria]

El mar, 10-11-2015 a las 16:15 -0700, Randolph Morgan escribió:
> Yes they are in the same DNS domain as the IPAserver.  I am able to 
> resolve the server address.  Which side would you like more
> information 
> on the server side or the client side.  We are not running any AD 
> domains, so this is not a Windows based system.  We are running
> FreeIPA 
> 4.2+ on RHEL 7.1 using the stock Samba from RHEL.  On the client side
> I 
> am running Windows 10 and I have installed MIT Kerberos version
> 4.01.  
> In the MIT ticket manager I show a tgt and it works as it
> should.  But 
> from the command prompt in windows if I do a klist it reports:
>  Current 
> LogonId is 0:0x6320a
> 
>  Cached 
> Tickets: (0)
> 
> So even though MIT Kerberos shows a successful negotiation with IPA
> and 
> a ticket is received, windows reports back the above when a klist is 
> run. 

I think that is the problem, you shouldn't use MIT kerberos.

The commands listed on the howto:

1. ksetup /setdomain [REALM NAME]
2. ksetup /addkdc [REALM NAME] [kdc DNS name]
3. ksetup /addkpasswd [REALM NAME] [kdc DNS name]
4. ksetup /setcomputerpassword [MACHINE_PASSWORD] (the one used above)
5. ksetup /mapuser * *

are meant to be run with windows native ksetup command. The native
windows kerberos libraries cannot see tickets obtained with MT
kerberos.

Best regards


>  What I am trying to do is get the two to talk to each other, but I 
> have not had any success as of yet.  I have edited the krb5.ini with
> the 
> correct information, and rebooted the machine multiple times with no 
> change.  Any help here would be really appreciated, we are taking
> this 
> system live over the weekend and would really love to have this part
> fixed.
> 
> Randy
> 
> Randy Morgan
> CSR
> Department of Chemistry and Biochemistry
> Brigham Young University
> 801-422-4100
> 
> On 11/10/2015 3:50 PM, Loris Santamaria wrote:
> > El mar, 10-11-2015 a las 11:51 -0700, Randolph Morgan escribió:
> > > Ok, that makes sense, but could we not just create the host in
> > > the
> > > IPA
> > > UI as part of the DNS?
> > That isn't enough, the dns object just maps to an ip address, you
> > have
> > to create a "host" object with ipa host-add, that object is needed
> > to
> > store kerberos principal and password for the host.
> > 
> > > Also we seem to be having some difficulty with
> > > another part of the process, that is getting the Windows machines
> > > to
> > > even acknowledge that they have the ability to talk with the kdc.
> > > Following the commands yields only that the windows machine is
> > > unable
> > > to
> > > locate the kdc, are we missing something?  Is this one of the
> > > issues
> > > related to different versions of Kerberos, e.g. MIT vs Heimdal.
> > You should check for dns inconsistencies first, are the windows
> > machines in the same dns domain as windows? Can they solve the
> > addresses of the ipa servers? If that doesn't help you should post
> > more
> > details of your setup...
> > 
> > Best regards
> > 
> > 
> > > On 11/10/2015 11:32 AM, Loris Santamaria wrote:
> > > > El mar, 10-11-2015 a las 11:18 -0700, Randolph Morgan escribió:
> > > > > I am certain that everyone gets tired of answering the same
> > > > > questions
> > > > > over and over, so maybe an update to the documentation would
> > > > > be
> > > > > better.
> > > > > I am trying to get my Windows machines to authenticate
> > > > > against a
> > > > > FreeIPA
> > > > > server running IPA 4.2+ on RHEL 7.  I have followed the
> > > > > documentation
> > > > > listed on
> > > > > https://www.freeipa.org/page/Windows_authentication_against_F
> > > > > reeI
> > > > > PA,
> > > > > but
> > > > > there seems to be a few steps missing.
> > > > > 
> > > > > In the Configure FreeIPA you are told to create a keytab for
> > > > > the
> > > > > Windows
> > > > > machine in question.  After creating the keytab, what do you
> > > > > do
> > > > > with
> > > > > it?  It jumps from creating the keytab to configuring Windows
> > > > > but
> > > > > does
> > > > > not say what to do with the keytab and the instructions never
> > > > > reference
> > > > > it again.  Would someone please clarify this and is this
> > > > > something we
> > > > > would need to do for each and every Windows machine on our
> > > > > network?
> > > > Note that the ipa-getkeytab command is called with the -P
> > > > option,
> > > > so it
> > > > asks for a password: that password is used as a password for
> > > > the
> > > > machine principal and is stored in the directory.
> > > > 
> > > > So no, the keytab is not really used anywhere else and can be
> > > > deleted.
> > > > It is the act of generating (with a known password) it that
> > > > needs
> > > > to be
> > > > done for every windows machine in the network. Please use
> > > > strong,
> > > > random and different passwords for each windows 

Re: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl

[Prasun Gera]

On Tue, Nov 10, 2015 at 5:04 PM, Fraser Tweedale 
wrote:

> On Tue, Nov 10, 2015 at 03:44:19PM -0800, Prasun Gera wrote:
> > No it didn't quite work.
> >
> > I ran ipa-server-certinstall -w /etc/letsencrypt/live/
> > example.com/privkey.pem /etc/letsencrypt/live/example.com/fullchain.pem
> >
> > which gives The full certificate chain is not present in
> > /etc/letsencrypt/live/example.com/privkey.pem, /etc/letsencrypt/live/
> > example.com/fullchain.pem
> >
> It looks like this error is triggered when there is no self-signed
> certificate in the trust chain (fullchain.pem).  Could you confirm
> that this is the case, and if so, could you try appending the root
> certificate to fullchain.pem and trying again?
>
>

I'm sorry, I didn't quite follow. Can you elaborate what I need to append
to what ?

>From let's encrypt's documentation:

cert.pem
Server certificate only.

This is what Apache needs for SSLCertificateFile.

chain.pem
All certificates that need to be served by the browser excluding server
certificate, i.e. root and intermediate certificates only.

This is what Apache needs for SSLCertificateChainFile.

fullchain.pem
All certificates, including server certificate. This is concatenation of
chain.pem and cert.pem.

This is what nginx needs for ssl_certificate.


So fullchain.pem should have all the relevant bits right ? Do you mean I
should append ipa's root cert from /etc/ipa/ca.crt ?





> It may be that ipa-server-certinstall assumes that your server certs
> are signed by the same CA as your IPA CA certificate, which need not
> be the case.
>
> >
> > On Tue, Nov 10, 2015 at 3:31 PM, Fraser Tweedale 
> > wrote:
> >
> > > On Tue, Nov 10, 2015 at 03:12:04PM -0800, Prasun Gera wrote:
> > > > I tried using let's encrypt's certs manually, but I think I'm missing
> > > > something. Let's encrypt creates the following files : cert.pem
> > > chain.pem
> > > >  fullchain.pem  privkey.pem. I was trying to follow
> > > >
> http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP
> > > but i
> > > > wasn't able to get it to work. That page says, "The certificate in
> > > > mysite.crt must be signed by the CA used when installing FreeIPA."
> Since
> > > my
> > > > ipa installation uses the default internal CA, how do I get lets
> > > encrypt's
> > > > certs signed by the ipa CA ? Is that the missing step ?
> > > >
> > > I do not think that text is correct, in the case of a
> > > publicy-trusted certificate (i.e. the server cert is chained to a
> > > trusted issuer).
> > >
> > > Just ignore that text and follow the steps.  Does it work?
> > >
> > > Cheers,
> > > Fraser
> > >
> > > > On Sat, Nov 7, 2015 at 9:15 PM, Prasun Gera 
> > > wrote:
> > > >
> > > > > Thanks for the discussion. If someone can update the documentation
> with
> > > > > mozilla style old, intermediate and modern cipher lists for
> mod_nss,
> > > that
> > > > > would be great. Better still would be to add that option to the
> > > installer
> > > > > scripts so that you can choose it during installation. Integrating
> > > that in
> > > > > the package would also have the added benefit of settings
> remaining up
> > > to
> > > > > date without manual intervention as standards evolve.
> > > > >
> > > > > On Thu, Nov 5, 2015 at 9:23 PM, Fraser Tweedale <
> ftwee...@redhat.com>
> > > > > wrote:
> > > > >
> > > > >> On Thu, Nov 05, 2015 at 11:52:32PM -0500, Rob Crittenden wrote:
> > > > >> > Prasun Gera wrote:
> > > > >> > > Thanks. After the changes, most things seem to be in order. I
> see
> > > two
> > > > >> > > orange flags though:
> > > > >> > >
> > > > >> > > Secure Client-Initiated Renegotiation   *Supported*   *DoS
> > > > >> DANGER* (more
> > > > >> > > info
> > > > >> > > <
> > > > >>
> > >
> https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks
> > > > >> >)
> > > > >> >
> > > > >> > Renegotiation is required for the CA so you need to leave this
> > > enabled.
> > > > >> >
> > > > >> > > Session resumption (caching)*No (IDs assigned but not
> > > > >> accepted)*
> > > > >> >
> > > > >> > I'll need to look at this in more detail. At worst it would
> slow new
> > > > >> > connection performance slightly as it means every connection
> > > requires a
> > > > >> > full SSL/TLS handshake. I don't think it's a show-stopper.
> > > > >> >
> > > > >> Definitely not a show-stopper.  The main reason this is an
> "orange"
> > > > >> alert in SSLLabs is because the server is assigning Session IDs
> but
> > > > >> then ignoring them; although confusing it is a fairly common
> default
> > > > >> behaviour and doesn't cause any issues with compliant client
> > > > >> implementation
> > > > >>
> > > > >> > rob
> > > > >> >
> > > > >> > >
> > > > >> > > Are these relevant/serious ? Can they be mitigated ?
> > > > >> > >
> > > > >> > >
> > > > >> > > On Thu, Nov 5, 2015 at 6:51 AM, Rob Crittenden <
> > > 

Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error)

[Gronde, Christopher (Contractor)]

How do I change that log setting?  Is that done in LDAP?  Using ldapmodify?

-Original Message-
From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Ludwig Krispenz
Sent: Tuesday, November 10, 2015 9:03 AM
To: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication 
error)


On 11/10/2015 02:40 PM, Alexander Bokovoy wrote:
> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote:
>> Where can I verify or change the credentials it is trying to use?  Is 
>> it my LDAP password?
> No, according to your logs, it is your LDAP master trying to replicate 
> (push changes) to your LDAP replica:
>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from 
>>>  to 
>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl
>>> version=3 mech=GSSAPI
err=49 could also be a result if the entry which is mapped from the principal 
is not found in the directory. A bit more info could be gained by enabling 
logging of internal searches.
Set nsslapd-acesslog-level: 260

and then look what internal searches are done during the gssapi authentication
>
> If that is true, it would be ldap/ Kerberos principal talking 
> to ldap/ Kerberos principal. If that fails, it means master 
> and replica KDCs have different understanding of both ldap/ 
> and ldap/ keys which most likely means keys were rotated on 
> master and weren't propagated to replica.
>
> How to solve it? One possibility is to set master's hostname as KDC 
> address in krb5.conf on replica, forcing LDAP server on replica to use 
> master's KDC. I'm absolutely not sure this will actually work but at 
> least it allows to see if we are indeed dealing with inconsistent 
> state of service principals' keys.
>
>>
>> -Original Message-
>> From: Alexander Bokovoy [mailto:aboko...@redhat.com]
>> Sent: Tuesday, November 10, 2015 8:18 AM
>> To: Gronde, Christopher (Contractor) 
>> Cc: Rob Crittenden ; freeipa-users@redhat.com
>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos 
>> authentication error)
>>
>> On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote:
>>> When I tried to start the service again I got no response from tail 
>>> of the log, but this is a repeating entry I see in the access log
>>>
>>> [09/Nov/2015:15:01:04 -0500] conn=1 fd=64 slot=64 connection from
>>> 127.0.0.1 to 127.0.0.1
>>> [09/Nov/2015:15:01:04 -0500] conn=1 op=-1 fd=64 closed - B1
>>> [09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from 
>>>  to 
>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl
>>> version=3 mech=GSSAPI
>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=0 RESULT err=14 tag=97
>>> nentries=0 etime=0, SASL bind in progress
>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 BIND dn="" method=sasl
>>> version=3 mech=GSSAPI
>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=1 RESULT err=14 tag=97
>>> nentries=0 etime=0, SASL bind in progress
>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 BIND dn="" method=sasl
>>> version=3 mech=GSSAPI
>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=2 RESULT err=49 tag=97
>>> nentries=0 etime=0
>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 UNBIND
>>> [09/Nov/2015:15:02:01 -0500] conn=2 op=3 fd=64 closed - U1
>>>
>>> Does anyone know what err=14 or err=49 are?
>> err=14 means SASL bind in progress -- i.e. multi-round processing is 
>> ongoing. This is normal for SASL GSSAPI.
>>
>> err=49 is wrong password or username, i.e. credentials were incorrect.
>> It may also mean that LDAP server side was unable to process Kerberos 
>> negotiation due to not having a current Kerberos ticket for own 
>> service
>> (LDAP) and trying to request it from the Kerberos KDC but Kerberos 
>> KDC is down.
>>
>>>
>>> -Original Message-
>>> From: Rob Crittenden [mailto:rcrit...@redhat.com]
>>> Sent: Monday, November 09, 2015 3:26 PM
>>> To: Gronde, Christopher (Contractor) 
>>> ; Alexander Bokovoy 
>>> 
>>> Cc: freeipa-users@redhat.com
>>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos 
>>> authentication error)
>>>
>>> Gronde, Christopher (Contractor) wrote:
 Nothing bad came back and there is definitely data in the tree.
>>>
>>> Ok, I guess I'd try to start the kdc again and then watch the 389-ds 
>>> access log (buffered) to:
>>>
>>> 1. See if it is binding at all
>>> 2. See what the search is and what, if any, results were returned
>>>
>>> This would be in /var/log/dirsrv/slapd-YOUR_REALM/access
>>>
>>> rob
>>>

 -Original Message-
 From: Rob Crittenden [mailto:rcrit...@redhat.com]
 Sent: Monday, November 09, 2015 11:46 AM
 To: Gronde, Christopher (Contractor) 
 ; Alexander Bokovoy 
 
 Cc: freeipa-users@redhat.com
 Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos 
 authentication 

Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error)

[Ludwig Krispenz]

On 11/10/2015 03:32 PM, Gronde, Christopher (Contractor) wrote:

How do I change that log setting?  Is that done in LDAP?  Using ldapmodify?

yes,
ldapmodify ...
dn: cn=config
changetype: modify
replace: nsslapd-acesslog-level
nsslapd-acesslog-level: 260


-Original Message-
From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Ludwig Krispenz
Sent: Tuesday, November 10, 2015 9:03 AM
To: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication 
error)


On 11/10/2015 02:40 PM, Alexander Bokovoy wrote:

On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote:

Where can I verify or change the credentials it is trying to use?  Is
it my LDAP password?

No, according to your logs, it is your LDAP master trying to replicate
(push changes) to your LDAP replica:

[09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from
 to 
[09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl
version=3 mech=GSSAPI

err=49 could also be a result if the entry which is mapped from the principal 
is not found in the directory. A bit more info could be gained by enabling 
logging of internal searches.
Set nsslapd-acesslog-level: 260

and then look what internal searches are done during the gssapi authentication

If that is true, it would be ldap/ Kerberos principal talking
to ldap/ Kerberos principal. If that fails, it means master
and replica KDCs have different understanding of both ldap/
and ldap/ keys which most likely means keys were rotated on
master and weren't propagated to replica.

How to solve it? One possibility is to set master's hostname as KDC
address in krb5.conf on replica, forcing LDAP server on replica to use
master's KDC. I'm absolutely not sure this will actually work but at
least it allows to see if we are indeed dealing with inconsistent
state of service principals' keys.


-Original Message-
From: Alexander Bokovoy [mailto:aboko...@redhat.com]
Sent: Tuesday, November 10, 2015 8:18 AM
To: Gronde, Christopher (Contractor) 
Cc: Rob Crittenden ; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos
authentication error)

On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote:

When I tried to start the service again I got no response from tail
of the log, but this is a repeating entry I see in the access log

[09/Nov/2015:15:01:04 -0500] conn=1 fd=64 slot=64 connection from
127.0.0.1 to 127.0.0.1
[09/Nov/2015:15:01:04 -0500] conn=1 op=-1 fd=64 closed - B1
[09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from
 to 
[09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl
version=3 mech=GSSAPI
[09/Nov/2015:15:02:01 -0500] conn=2 op=0 RESULT err=14 tag=97
nentries=0 etime=0, SASL bind in progress
[09/Nov/2015:15:02:01 -0500] conn=2 op=1 BIND dn="" method=sasl
version=3 mech=GSSAPI
[09/Nov/2015:15:02:01 -0500] conn=2 op=1 RESULT err=14 tag=97
nentries=0 etime=0, SASL bind in progress
[09/Nov/2015:15:02:01 -0500] conn=2 op=2 BIND dn="" method=sasl
version=3 mech=GSSAPI
[09/Nov/2015:15:02:01 -0500] conn=2 op=2 RESULT err=49 tag=97
nentries=0 etime=0
[09/Nov/2015:15:02:01 -0500] conn=2 op=3 UNBIND
[09/Nov/2015:15:02:01 -0500] conn=2 op=3 fd=64 closed - U1

Does anyone know what err=14 or err=49 are?

err=14 means SASL bind in progress -- i.e. multi-round processing is
ongoing. This is normal for SASL GSSAPI.

err=49 is wrong password or username, i.e. credentials were incorrect.
It may also mean that LDAP server side was unable to process Kerberos
negotiation due to not having a current Kerberos ticket for own
service
(LDAP) and trying to request it from the Kerberos KDC but Kerberos
KDC is down.


-Original Message-
From: Rob Crittenden [mailto:rcrit...@redhat.com]
Sent: Monday, November 09, 2015 3:26 PM
To: Gronde, Christopher (Contractor)
; Alexander Bokovoy

Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos
authentication error)

Gronde, Christopher (Contractor) wrote:

Nothing bad came back and there is definitely data in the tree.

Ok, I guess I'd try to start the kdc again and then watch the 389-ds
access log (buffered) to:

1. See if it is binding at all
2. See what the search is and what, if any, results were returned

This would be in /var/log/dirsrv/slapd-YOUR_REALM/access

rob


-Original Message-
From: Rob Crittenden [mailto:rcrit...@redhat.com]
Sent: Monday, November 09, 2015 11:46 AM
To: Gronde, Christopher (Contractor)
; Alexander Bokovoy

Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos
authentication error)

Gronde, Christopher (Contractor) wrote:

I restarted dirsrv and attempted to start krb5kdc and this is what
the error log shows

# tail 

[Freeipa-users] ipa-getkeytab missing permissions after migration

[Dominik Korittki]

Hello folks,

I created a replica IPA host with version 4.1.0-18.el7.centos.4,
while the initial master is a FreeIPA 3.3.3.

Everything seems to work fine with the new host except for one thing:
We have a special IPA user, which has the rights for managing and enrolling 
hosts.
I am able to add hosts with this user, but ipa-getkeytab command returns the 
following message:

root@ipa01:~ > ipa-getkeytab -q -s ipa01.internal -p "host/testhost.internal" 
-k testhost.internal.keytab
Failed to parse result: Insufficient access rights

The keytab was successfully created, though. dirsrv error logs showed me this 
after raising log level:

[10/Nov/2015:10:40:36 +0100] NSACLPlugin -  conn=590 op=3 
binddn="uid=mw-integrator,cn=users,cn=accounts,dc=internal"
[10/Nov/2015:10:40:36 +0100] NSACLPlugin - conn=590 op=3 (main): Deny write on 
entry(fqdn=testhost.internal,cn=computers,cn=accounts,dc=internal).attr(ipaProtectedOperation;write_keys)
 to uid=mw-integrator,cn=users,cn=accounts,dc=internal: no aci matched the subject by aci(53): 
aciname= "Entities are allowed to rekey managed entries", 
acidn="cn=accounts,dc=internal"
[10/Nov/2015:10:40:36 +0100] is_allowed_to_access_attr - [file ipa_pwd_extop.c, 
line 756]: slapi_access_allowed does not allow WRITE to 
ipaProtectedOperation;write_keys!
[10/Nov/2015:10:40:36 +0100] ipapwd_getkeytab - [file ipa_pwd_extop.c, line 
1630]: Not allowed to set keytab on [host/testhost.internal@INTERNAL]!
[10/Nov/2015:10:40:36 +0100] NSACLPlugin -  conn=591 op=3 
binddn="uid=mw-integrator,cn=users,cn=accounts,dc=internal"
[10/Nov/2015:10:40:36 +0100] NSACLPlugin - conn=591 op=3 (main): Allow write on 
entry(fqdn=testhost.internal,cn=computers,cn=accounts,dc=internal).attr(krbPrincipalKey) to 
uid=mw-integrator,cn=users,cn=accounts,dc=internal: allowed by aci(277): aciname= 
"permission:System: Manage Host Keytab", 
acidn="cn=computers,cn=accounts,dc=internal"


So it seems he can't find a proper write permission for 
ipaProtectedOperation;write_keys.
When creating a permission with write access to this attribute everything works 
fine, but should'nt there
already be a proper permission? I discovered the following permission:

root@ipa01:~ > ipa permission-show --all --raw 'System: Manage Host Keytab 
Permissions'
  dn: cn=System: Manage Host Keytab 
Permissions,cn=permissions,cn=pbac,dc=internal
  cn: System: Manage Host Keytab Permissions
  ipapermright: write
  ipapermright: read
  ipapermright: compare
  ipapermright: search
  ipapermincludedattr: createtimestamp
  ipapermincludedattr: modifytimestamp
  ipapermincludedattr: entryusn
  ipapermdefaultattr: objectclass
  ipapermdefaultattr: ipaallowedtoperform;write_keys
  ipapermdefaultattr: ipaallowedtoperform;read_keys
  ipapermbindruletype: permission
  ipapermlocation: cn=computers,cn=accounts,dc=internal
  ipapermtargetfilter: (objectclass=ipahost)
  member: cn=Host Administrators,cn=privileges,cn=pbac,dc=internal
  aci: (targetattr = "createtimestamp || entryusn || ipaallowedtoperform;read_keys || 
ipaallowedtoperform;write_keys || modifytimestamp || objectclass")(targetfilter = 
"(objectclass=ipahost)")(version 3.0;acl "permission:System: Manage Host Keytab Permissions";allow 
(compare,read,search,write) groupdn = "ldap:///cn=System: Manage Host Keytab 
Permissions,cn=permissions,cn=pbac,dc=internal";)
  ipapermissiontype: V2
  ipapermissiontype: MANAGED
  ipapermissiontype: SYSTEM
  memberindirect: uid=mw-integrator,cn=users,cn=accounts,dc=internal
  memberindirect: cn=IT Specialist,cn=roles,cn=accounts,dc=internal
  memberindirect: cn=MW Host Enroller,cn=roles,cn=accounts,dc=internal
  objectclass: ipapermission
  objectclass: top
  objectclass: groupofnames
  objectclass: ipapermissionv2


So there is a aci with write access on ipaallowedtoperform;write_keys,
but not on ipaProtectedOperation;write_keys.

So the question is: Has something gone wrong while migrating the aci's to 
freeipa v4 style?
If yes, how can I fix it?


Dominik Korittki

--
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] krb5kdc will not start (kerberos authentication error)

[Gronde, Christopher (Contractor)]

So I changed the hostnames in krb5.conf

[realms]
  = {
  kdc = :88
  master_kdc = :88
  admin_server = :749
  default_domain = 
  pkinit_anchors = FILE:/etc/ipa/ca.crt
}

Service still will not start however now in the access log instead of showing 
the connection from master to replica it shows replica to replica

[10/Nov/2015:08:51:03 -0500] conn=52 op=3 UNBIND
[10/Nov/2015:08:51:03 -0500] conn=52 op=3 fd=64 closed - U1
[10/Nov/2015:08:51:03 -0500] conn=52 op=0 RESULT err=14 tag=97 nentries=0 
etime=0, SASL bind in progress
[10/Nov/2015:08:51:05 -0500] conn=53 fd=64 slot=64 connection from  
to 
[10/Nov/2015:08:51:05 -0500] conn=53 op=0 BIND dn="" method=sasl version=3 
mech=GSSAPI
[10/Nov/2015:08:51:05 -0500] conn=53 op=1 BIND dn="" method=sasl version=3 
mech=GSSAPI
[10/Nov/2015:08:51:05 -0500] conn=53 op=1 RESULT err=14 tag=97 nentries=0 
etime=0, SASL bind in progress
[10/Nov/2015:08:51:05 -0500] conn=53 op=2 BIND dn="" method=sasl version=3 
mech=GSSAPI
[10/Nov/2015:08:51:05 -0500] conn=53 op=2 RESULT err=49 tag=97 nentries=0 
etime=0
[10/Nov/2015:08:51:05 -0500] conn=53 op=3 UNBIND
[10/Nov/2015:08:51:05 -0500] conn=53 op=3 fd=64 closed - U1
[10/Nov/2015:08:51:05 -0500] conn=53 op=0 RESULT err=14 tag=97 nentries=0 
etime=0, SASL bind in progress

-Original Message-
From: Alexander Bokovoy [mailto:aboko...@redhat.com] 
Sent: Tuesday, November 10, 2015 8:41 AM
To: Gronde, Christopher (Contractor) 
Cc: Rob Crittenden ; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication 
error)

On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote:
>Where can I verify or change the credentials it is trying to use?  Is it my 
>LDAP password?
No, according to your logs, it is your LDAP master trying to replicate (push 
changes) to your LDAP replica:
>>[09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from 
>> to 
>>[09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl 
>>version=3 mech=GSSAPI

If that is true, it would be ldap/ Kerberos principal talking to 
ldap/ Kerberos principal. If that fails, it means master and replica 
KDCs have different understanding of both ldap/ and ldap/ keys 
which most likely means keys were rotated on master and weren't propagated to 
replica.

How to solve it? One possibility is to set master's hostname as KDC address in 
krb5.conf on replica, forcing LDAP server on replica to use master's KDC. I'm 
absolutely not sure this will actually work but at least it allows to see if we 
are indeed dealing with inconsistent state of service principals' keys.

>
>-Original Message-
>From: Alexander Bokovoy [mailto:aboko...@redhat.com]
>Sent: Tuesday, November 10, 2015 8:18 AM
>To: Gronde, Christopher (Contractor) 
>Cc: Rob Crittenden ; freeipa-users@redhat.com
>Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos 
>authentication error)
>
>On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote:
>>When I tried to start the service again I got no response from tail of 
>>the log, but this is a repeating entry I see in the access log
>>
>>[09/Nov/2015:15:01:04 -0500] conn=1 fd=64 slot=64 connection from
>>127.0.0.1 to 127.0.0.1
>>[09/Nov/2015:15:01:04 -0500] conn=1 op=-1 fd=64 closed - B1
>>[09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from 
>> to 
>>[09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl
>>version=3 mech=GSSAPI
>>[09/Nov/2015:15:02:01 -0500] conn=2 op=0 RESULT err=14 tag=97
>>nentries=0 etime=0, SASL bind in progress
>>[09/Nov/2015:15:02:01 -0500] conn=2 op=1 BIND dn="" method=sasl
>>version=3 mech=GSSAPI
>>[09/Nov/2015:15:02:01 -0500] conn=2 op=1 RESULT err=14 tag=97
>>nentries=0 etime=0, SASL bind in progress
>>[09/Nov/2015:15:02:01 -0500] conn=2 op=2 BIND dn="" method=sasl
>>version=3 mech=GSSAPI
>>[09/Nov/2015:15:02:01 -0500] conn=2 op=2 RESULT err=49 tag=97
>>nentries=0 etime=0
>>[09/Nov/2015:15:02:01 -0500] conn=2 op=3 UNBIND
>>[09/Nov/2015:15:02:01 -0500] conn=2 op=3 fd=64 closed - U1
>>
>>Does anyone know what err=14 or err=49 are?
>err=14 means SASL bind in progress -- i.e. multi-round processing is ongoing. 
>This is normal for SASL GSSAPI.
>
>err=49 is wrong password or username, i.e. credentials were incorrect.
>It may also mean that LDAP server side was unable to process Kerberos 
>negotiation due to not having a current Kerberos ticket for own service
>(LDAP) and trying to request it from the Kerberos KDC but Kerberos KDC is down.
>
>>
>>-Original Message-
>>From: Rob Crittenden [mailto:rcrit...@redhat.com]
>>Sent: Monday, November 09, 2015 3:26 PM
>>To: Gronde, Christopher (Contractor) ; 
>>Alexander Bokovoy 
>>Cc: freeipa-users@redhat.com
>>Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos 
>>authentication error)
>>
>>Gronde, Christopher (Contractor) wrote:
>>> 

Re: [Freeipa-users] mastercrl files

[Fraser Tweedale]

On Tue, Nov 10, 2015 at 07:02:42PM +0100, Natxo Asenjo wrote:
> hi,
> 
> do we need to keep all the MasterCRL-MMDD-HHMMSS.der files or can we
> purge them on a regular basis (say, keep 60 days dump the rest)?
> 
> $ ls -l | wc -l
> 3621
> 
> this is in a server installed 3 years ago.
> 
> --
> Groeten,
> natxo
>
Hi Natxo,

You can purge them.  I am not sure why we keep the old ones around;
can someone fill me in?

Cheers,
Fraser

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

-- 
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] let's encrypt integration and best practices for mod_nss/mod_ssl

[Fraser Tweedale]

On Tue, Nov 10, 2015 at 08:30:47PM -0800, Prasun Gera wrote:
> You are right in that the fullchain.pem doesn't have the root certificate.
> I ran "openssl x509 -in chain.pem -noout -text", and saw that it
> had Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3, and Subject:
> C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X1. So I got the root
> certificate for DST Root CA X3 from
> https://www.identrust.com/certificates/trustid/root-download-x3.html, which
> is self signed from what I can tell. The issuer and the subject are the
> same. I added that to the fullchain, and the command seemed to work.
> However, it messed something up, and httpd didn't start after that. httpd
> error log had "Unable to verify certificate 'Signing-Cert'. Add
> "NSSEnforceValidCerts off" to nss.conf so the server can start until the
> problem can be resolved ". I added that to nss.conf, and ipactl started
> successfully after that. However, the webui hadn't configured the
> certificates properly. At this point, I just restored my backups
> of /etc/httpd/conf.d/ and /etc/httpd/alias/, which brought things back to
> where things were earlier. I think it would be better to do these
> experiments on a test bed first.
> 
I am at a loss, and must have missed something.  The purpose of this
command is to be able to install 3rd party certificates, yet the
code is expecting the certs to be signed by the IPA CA?

Can someone explain what is going on here?

Fraser

> 
> On Tue, Nov 10, 2015 at 5:19 PM, Prasun Gera  wrote:
> 
> >
> >
> > On Tue, Nov 10, 2015 at 5:04 PM, Fraser Tweedale 
> > wrote:
> >
> >> On Tue, Nov 10, 2015 at 03:44:19PM -0800, Prasun Gera wrote:
> >> > No it didn't quite work.
> >> >
> >> > I ran ipa-server-certinstall -w /etc/letsencrypt/live/
> >> > example.com/privkey.pem /etc/letsencrypt/live/example.com/fullchain.pem
> >> >
> >> > which gives The full certificate chain is not present in
> >> > /etc/letsencrypt/live/example.com/privkey.pem, /etc/letsencrypt/live/
> >> > example.com/fullchain.pem
> >> >
> >> It looks like this error is triggered when there is no self-signed
> >> certificate in the trust chain (fullchain.pem).  Could you confirm
> >> that this is the case, and if so, could you try appending the root
> >> certificate to fullchain.pem and trying again?
> >>
> >>
> >
> > I'm sorry, I didn't quite follow. Can you elaborate what I need to append
> > to what ?
> >
> > From let's encrypt's documentation:
> >
> > cert.pem
> > Server certificate only.
> >
> > This is what Apache needs for SSLCertificateFile.
> >
> > chain.pem
> > All certificates that need to be served by the browser excluding server
> > certificate, i.e. root and intermediate certificates only.
> >
> > This is what Apache needs for SSLCertificateChainFile.
> >
> > fullchain.pem
> > All certificates, including server certificate. This is concatenation of
> > chain.pem and cert.pem.
> >
> > This is what nginx needs for ssl_certificate.
> >
> >
> > So fullchain.pem should have all the relevant bits right ? Do you mean I
> > should append ipa's root cert from /etc/ipa/ca.crt ?
> >
> >
> >
> >
> >
> >> It may be that ipa-server-certinstall assumes that your server certs
> >> are signed by the same CA as your IPA CA certificate, which need not
> >> be the case.
> >>
> >> >
> >> > On Tue, Nov 10, 2015 at 3:31 PM, Fraser Tweedale 
> >> > wrote:
> >> >
> >> > > On Tue, Nov 10, 2015 at 03:12:04PM -0800, Prasun Gera wrote:
> >> > > > I tried using let's encrypt's certs manually, but I think I'm
> >> missing
> >> > > > something. Let's encrypt creates the following files : cert.pem
> >> > > chain.pem
> >> > > >  fullchain.pem  privkey.pem. I was trying to follow
> >> > > >
> >> http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP
> >> > > but i
> >> > > > wasn't able to get it to work. That page says, "The certificate in
> >> > > > mysite.crt must be signed by the CA used when installing FreeIPA."
> >> Since
> >> > > my
> >> > > > ipa installation uses the default internal CA, how do I get lets
> >> > > encrypt's
> >> > > > certs signed by the ipa CA ? Is that the missing step ?
> >> > > >
> >> > > I do not think that text is correct, in the case of a
> >> > > publicy-trusted certificate (i.e. the server cert is chained to a
> >> > > trusted issuer).
> >> > >
> >> > > Just ignore that text and follow the steps.  Does it work?
> >> > >
> >> > > Cheers,
> >> > > Fraser
> >> > >
> >> > > > On Sat, Nov 7, 2015 at 9:15 PM, Prasun Gera 
> >> > > wrote:
> >> > > >
> >> > > > > Thanks for the discussion. If someone can update the
> >> documentation with
> >> > > > > mozilla style old, intermediate and modern cipher lists for
> >> mod_nss,
> >> > > that
> >> > > > > would be great. Better still would be to add that option to the
> >> > > installer
> >> > > > > scripts so that you can choose it during installation. Integrating
> >> > > that in
> >> 

Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error)

[Alexander Bokovoy]

On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote:

When I tried to start the service again I got no response from tail of the log, 
but this is a repeating entry I see in the access log

[09/Nov/2015:15:01:04 -0500] conn=1 fd=64 slot=64 connection from 127.0.0.1 to 
127.0.0.1
[09/Nov/2015:15:01:04 -0500] conn=1 op=-1 fd=64 closed - B1
[09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from  to 

[09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl version=3 
mech=GSSAPI
[09/Nov/2015:15:02:01 -0500] conn=2 op=0 RESULT err=14 tag=97 nentries=0 
etime=0, SASL bind in progress
[09/Nov/2015:15:02:01 -0500] conn=2 op=1 BIND dn="" method=sasl version=3 
mech=GSSAPI
[09/Nov/2015:15:02:01 -0500] conn=2 op=1 RESULT err=14 tag=97 nentries=0 
etime=0, SASL bind in progress
[09/Nov/2015:15:02:01 -0500] conn=2 op=2 BIND dn="" method=sasl version=3 
mech=GSSAPI
[09/Nov/2015:15:02:01 -0500] conn=2 op=2 RESULT err=49 tag=97 nentries=0 etime=0
[09/Nov/2015:15:02:01 -0500] conn=2 op=3 UNBIND
[09/Nov/2015:15:02:01 -0500] conn=2 op=3 fd=64 closed - U1

Does anyone know what err=14 or err=49 are?

err=14 means SASL bind in progress -- i.e. multi-round processing is
ongoing. This is normal for SASL GSSAPI.

err=49 is wrong password or username, i.e. credentials were incorrect.
It may also mean that LDAP server side was unable to process Kerberos
negotiation due to not having a current Kerberos ticket for own service
(LDAP) and trying to request it from the Kerberos KDC but Kerberos KDC
is down.



-Original Message-
From: Rob Crittenden [mailto:rcrit...@redhat.com]
Sent: Monday, November 09, 2015 3:26 PM
To: Gronde, Christopher (Contractor) ; Alexander 
Bokovoy 
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication 
error)

Gronde, Christopher (Contractor) wrote:

Nothing bad came back and there is definitely data in the tree.


Ok, I guess I'd try to start the kdc again and then watch the 389-ds access log 
(buffered) to:

1. See if it is binding at all
2. See what the search is and what, if any, results were returned

This would be in /var/log/dirsrv/slapd-YOUR_REALM/access

rob



-Original Message-
From: Rob Crittenden [mailto:rcrit...@redhat.com]
Sent: Monday, November 09, 2015 11:46 AM
To: Gronde, Christopher (Contractor) ;
Alexander Bokovoy 
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos
authentication error)

Gronde, Christopher (Contractor) wrote:

I restarted dirsrv and attempted to start krb5kdc and this is what
the error log shows

# tail /var/log/dirsrv/slapd-ITMODEV-GOV/errors
[09/Nov/2015:11:01:02 -0500] - WARNING: userRoot: entry cache size 10485760B is 
less than db size 28016640B; We recommend to increase the entry cache size 
nsslapd-cachememsize.
[09/Nov/2015:11:01:02 -0500] - slapd started.  Listening on All
Interfaces port 389 for LDAP requests
[09/Nov/2015:11:06:04 -0500] - slapd shutting down - signaling
operation threads
[09/Nov/2015:11:06:04 -0500] - slapd shutting down - closing down
internal subsystems and plugins
[09/Nov/2015:11:06:04 -0500] - Waiting for 4 database threads to stop
[09/Nov/2015:11:06:04 -0500] - All database threads now stopped
[09/Nov/2015:11:06:04 -0500] - slapd stopped.
[09/Nov/2015:11:14:20 -0500] - 389-Directory/1.2.11.15 B2015.247.1737
starting up
[09/Nov/2015:11:14:20 -0500] - WARNING: userRoot: entry cache size 10485760B is 
less than db size 28016640B; We recommend to increase the entry cache size 
nsslapd-cachememsize.
[09/Nov/2015:11:14:20 -0500] - slapd started.  Listening on All
Interfaces port 389 for LDAP requests


Ok, that's good.

I'd do something like this to see what is in the db (substitute example.com 
with your domain):

$ ldapsearch -x -D 'cn=Directory Manager' -W -s one -b
cn=kerberos,dc=example,dc=com

(don't post the output as it would include the kerberos master key).

If that returns nothing that's bad.

If it succeeds I'd broaden the search base a bit to see what data you
do
have:

$ ldapsearch -x -D 'cn=Directory Manager' -W -b
cn=groups,cn=accounts,dc=example,dc=com

I picked groups because usually groups << users in numbers. This is just to see 
if you have data in the tree.

Let us know if either or both turns up nothing.

rob



-Original Message-
From: Alexander Bokovoy [mailto:aboko...@redhat.com]
Sent: Monday, November 09, 2015 10:51 AM
To: Gronde, Christopher (Contractor) 
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos
authentication error)

On Mon, 09 Nov 2015, Gronde, Christopher (Contractor) wrote:

Hello all!

On my replica IPA server after fixing a cert issue that had been going on for 
sometime, I have all my certs figured out but the krb5kdc service will not 
start.

# service krb5kdc start
Starting Kerberos 5 

Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error)

[Gronde, Christopher (Contractor)]

Where can I verify or change the credentials it is trying to use?  Is it my 
LDAP password?

-Original Message-
From: Alexander Bokovoy [mailto:aboko...@redhat.com] 
Sent: Tuesday, November 10, 2015 8:18 AM
To: Gronde, Christopher (Contractor) 
Cc: Rob Crittenden ; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication 
error)

On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote:
>When I tried to start the service again I got no response from tail of 
>the log, but this is a repeating entry I see in the access log
>
>[09/Nov/2015:15:01:04 -0500] conn=1 fd=64 slot=64 connection from 
>127.0.0.1 to 127.0.0.1
>[09/Nov/2015:15:01:04 -0500] conn=1 op=-1 fd=64 closed - B1
>[09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from 
> to 
>[09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl 
>version=3 mech=GSSAPI
>[09/Nov/2015:15:02:01 -0500] conn=2 op=0 RESULT err=14 tag=97 
>nentries=0 etime=0, SASL bind in progress
>[09/Nov/2015:15:02:01 -0500] conn=2 op=1 BIND dn="" method=sasl 
>version=3 mech=GSSAPI
>[09/Nov/2015:15:02:01 -0500] conn=2 op=1 RESULT err=14 tag=97 
>nentries=0 etime=0, SASL bind in progress
>[09/Nov/2015:15:02:01 -0500] conn=2 op=2 BIND dn="" method=sasl 
>version=3 mech=GSSAPI
>[09/Nov/2015:15:02:01 -0500] conn=2 op=2 RESULT err=49 tag=97 
>nentries=0 etime=0
>[09/Nov/2015:15:02:01 -0500] conn=2 op=3 UNBIND
>[09/Nov/2015:15:02:01 -0500] conn=2 op=3 fd=64 closed - U1
>
>Does anyone know what err=14 or err=49 are?
err=14 means SASL bind in progress -- i.e. multi-round processing is ongoing. 
This is normal for SASL GSSAPI.

err=49 is wrong password or username, i.e. credentials were incorrect.
It may also mean that LDAP server side was unable to process Kerberos 
negotiation due to not having a current Kerberos ticket for own service
(LDAP) and trying to request it from the Kerberos KDC but Kerberos KDC is down.

>
>-Original Message-
>From: Rob Crittenden [mailto:rcrit...@redhat.com]
>Sent: Monday, November 09, 2015 3:26 PM
>To: Gronde, Christopher (Contractor) ; 
>Alexander Bokovoy 
>Cc: freeipa-users@redhat.com
>Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos 
>authentication error)
>
>Gronde, Christopher (Contractor) wrote:
>> Nothing bad came back and there is definitely data in the tree.
>
>Ok, I guess I'd try to start the kdc again and then watch the 389-ds access 
>log (buffered) to:
>
>1. See if it is binding at all
>2. See what the search is and what, if any, results were returned
>
>This would be in /var/log/dirsrv/slapd-YOUR_REALM/access
>
>rob
>
>>
>> -Original Message-
>> From: Rob Crittenden [mailto:rcrit...@redhat.com]
>> Sent: Monday, November 09, 2015 11:46 AM
>> To: Gronde, Christopher (Contractor) ; 
>> Alexander Bokovoy 
>> Cc: freeipa-users@redhat.com
>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos 
>> authentication error)
>>
>> Gronde, Christopher (Contractor) wrote:
>>> I restarted dirsrv and attempted to start krb5kdc and this is what 
>>> the error log shows
>>>
>>> # tail /var/log/dirsrv/slapd-ITMODEV-GOV/errors
>>> [09/Nov/2015:11:01:02 -0500] - WARNING: userRoot: entry cache size 
>>> 10485760B is less than db size 28016640B; We recommend to increase the 
>>> entry cache size nsslapd-cachememsize.
>>> [09/Nov/2015:11:01:02 -0500] - slapd started.  Listening on All 
>>> Interfaces port 389 for LDAP requests
>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - signaling 
>>> operation threads
>>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - closing down 
>>> internal subsystems and plugins
>>> [09/Nov/2015:11:06:04 -0500] - Waiting for 4 database threads to 
>>> stop
>>> [09/Nov/2015:11:06:04 -0500] - All database threads now stopped
>>> [09/Nov/2015:11:06:04 -0500] - slapd stopped.
>>> [09/Nov/2015:11:14:20 -0500] - 389-Directory/1.2.11.15 
>>> B2015.247.1737 starting up
>>> [09/Nov/2015:11:14:20 -0500] - WARNING: userRoot: entry cache size 
>>> 10485760B is less than db size 28016640B; We recommend to increase the 
>>> entry cache size nsslapd-cachememsize.
>>> [09/Nov/2015:11:14:20 -0500] - slapd started.  Listening on All 
>>> Interfaces port 389 for LDAP requests
>>
>> Ok, that's good.
>>
>> I'd do something like this to see what is in the db (substitute example.com 
>> with your domain):
>>
>> $ ldapsearch -x -D 'cn=Directory Manager' -W -s one -b 
>> cn=kerberos,dc=example,dc=com
>>
>> (don't post the output as it would include the kerberos master key).
>>
>> If that returns nothing that's bad.
>>
>> If it succeeds I'd broaden the search base a bit to see what data you 
>> do
>> have:
>>
>> $ ldapsearch -x -D 'cn=Directory Manager' -W -b 
>> cn=groups,cn=accounts,dc=example,dc=com
>>
>> I picked groups because usually groups << users in numbers. This is just to 
>> 

Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error)

[Alexander Bokovoy]

On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote:

Where can I verify or change the credentials it is trying to use?  Is it my 
LDAP password?

No, according to your logs, it is your LDAP master trying to replicate
(push changes) to your LDAP replica:

[09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from  to 

[09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl version=3 
mech=GSSAPI


If that is true, it would be ldap/ Kerberos principal talking to
ldap/ Kerberos principal. If that fails, it means master and
replica KDCs have different understanding of both ldap/ and
ldap/ keys which most likely means keys were rotated on master
and weren't propagated to replica.

How to solve it? One possibility is to set master's hostname as KDC
address in krb5.conf on replica, forcing LDAP server on replica to use
master's KDC. I'm absolutely not sure this will actually work but at
least it allows to see if we are indeed dealing with inconsistent state
of service principals' keys.



-Original Message-
From: Alexander Bokovoy [mailto:aboko...@redhat.com]
Sent: Tuesday, November 10, 2015 8:18 AM
To: Gronde, Christopher (Contractor) 
Cc: Rob Crittenden ; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication 
error)

On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote:

When I tried to start the service again I got no response from tail of
the log, but this is a repeating entry I see in the access log

[09/Nov/2015:15:01:04 -0500] conn=1 fd=64 slot=64 connection from
127.0.0.1 to 127.0.0.1
[09/Nov/2015:15:01:04 -0500] conn=1 op=-1 fd=64 closed - B1
[09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from
 to 
[09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl
version=3 mech=GSSAPI
[09/Nov/2015:15:02:01 -0500] conn=2 op=0 RESULT err=14 tag=97
nentries=0 etime=0, SASL bind in progress
[09/Nov/2015:15:02:01 -0500] conn=2 op=1 BIND dn="" method=sasl
version=3 mech=GSSAPI
[09/Nov/2015:15:02:01 -0500] conn=2 op=1 RESULT err=14 tag=97
nentries=0 etime=0, SASL bind in progress
[09/Nov/2015:15:02:01 -0500] conn=2 op=2 BIND dn="" method=sasl
version=3 mech=GSSAPI
[09/Nov/2015:15:02:01 -0500] conn=2 op=2 RESULT err=49 tag=97
nentries=0 etime=0
[09/Nov/2015:15:02:01 -0500] conn=2 op=3 UNBIND
[09/Nov/2015:15:02:01 -0500] conn=2 op=3 fd=64 closed - U1

Does anyone know what err=14 or err=49 are?

err=14 means SASL bind in progress -- i.e. multi-round processing is ongoing. 
This is normal for SASL GSSAPI.

err=49 is wrong password or username, i.e. credentials were incorrect.
It may also mean that LDAP server side was unable to process Kerberos 
negotiation due to not having a current Kerberos ticket for own service
(LDAP) and trying to request it from the Kerberos KDC but Kerberos KDC is down.



-Original Message-
From: Rob Crittenden [mailto:rcrit...@redhat.com]
Sent: Monday, November 09, 2015 3:26 PM
To: Gronde, Christopher (Contractor) ;
Alexander Bokovoy 
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos
authentication error)

Gronde, Christopher (Contractor) wrote:

Nothing bad came back and there is definitely data in the tree.


Ok, I guess I'd try to start the kdc again and then watch the 389-ds access log 
(buffered) to:

1. See if it is binding at all
2. See what the search is and what, if any, results were returned

This would be in /var/log/dirsrv/slapd-YOUR_REALM/access

rob



-Original Message-
From: Rob Crittenden [mailto:rcrit...@redhat.com]
Sent: Monday, November 09, 2015 11:46 AM
To: Gronde, Christopher (Contractor) ;
Alexander Bokovoy 
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos
authentication error)

Gronde, Christopher (Contractor) wrote:

I restarted dirsrv and attempted to start krb5kdc and this is what
the error log shows

# tail /var/log/dirsrv/slapd-ITMODEV-GOV/errors
[09/Nov/2015:11:01:02 -0500] - WARNING: userRoot: entry cache size 10485760B is 
less than db size 28016640B; We recommend to increase the entry cache size 
nsslapd-cachememsize.
[09/Nov/2015:11:01:02 -0500] - slapd started.  Listening on All
Interfaces port 389 for LDAP requests
[09/Nov/2015:11:06:04 -0500] - slapd shutting down - signaling
operation threads
[09/Nov/2015:11:06:04 -0500] - slapd shutting down - closing down
internal subsystems and plugins
[09/Nov/2015:11:06:04 -0500] - Waiting for 4 database threads to
stop
[09/Nov/2015:11:06:04 -0500] - All database threads now stopped
[09/Nov/2015:11:06:04 -0500] - slapd stopped.
[09/Nov/2015:11:14:20 -0500] - 389-Directory/1.2.11.15
B2015.247.1737 starting up
[09/Nov/2015:11:14:20 -0500] - WARNING: userRoot: entry cache size 10485760B is 
less than db size 28016640B; We recommend to increase the entry cache size 

Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error)

[Gronde, Christopher (Contractor)]

When I tried to start the service again I got no response from tail of the log, 
but this is a repeating entry I see in the access log

[09/Nov/2015:15:01:04 -0500] conn=1 fd=64 slot=64 connection from 127.0.0.1 to 
127.0.0.1
[09/Nov/2015:15:01:04 -0500] conn=1 op=-1 fd=64 closed - B1
[09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from  
to 
[09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl version=3 
mech=GSSAPI
[09/Nov/2015:15:02:01 -0500] conn=2 op=0 RESULT err=14 tag=97 nentries=0 
etime=0, SASL bind in progress
[09/Nov/2015:15:02:01 -0500] conn=2 op=1 BIND dn="" method=sasl version=3 
mech=GSSAPI
[09/Nov/2015:15:02:01 -0500] conn=2 op=1 RESULT err=14 tag=97 nentries=0 
etime=0, SASL bind in progress
[09/Nov/2015:15:02:01 -0500] conn=2 op=2 BIND dn="" method=sasl version=3 
mech=GSSAPI
[09/Nov/2015:15:02:01 -0500] conn=2 op=2 RESULT err=49 tag=97 nentries=0 etime=0
[09/Nov/2015:15:02:01 -0500] conn=2 op=3 UNBIND
[09/Nov/2015:15:02:01 -0500] conn=2 op=3 fd=64 closed - U1

Does anyone know what err=14 or err=49 are?

-Original Message-
From: Rob Crittenden [mailto:rcrit...@redhat.com] 
Sent: Monday, November 09, 2015 3:26 PM
To: Gronde, Christopher (Contractor) ; Alexander 
Bokovoy 
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication 
error)

Gronde, Christopher (Contractor) wrote:
> Nothing bad came back and there is definitely data in the tree.

Ok, I guess I'd try to start the kdc again and then watch the 389-ds access log 
(buffered) to:

1. See if it is binding at all
2. See what the search is and what, if any, results were returned

This would be in /var/log/dirsrv/slapd-YOUR_REALM/access

rob

> 
> -Original Message-
> From: Rob Crittenden [mailto:rcrit...@redhat.com]
> Sent: Monday, November 09, 2015 11:46 AM
> To: Gronde, Christopher (Contractor) ; 
> Alexander Bokovoy 
> Cc: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos 
> authentication error)
> 
> Gronde, Christopher (Contractor) wrote:
>> I restarted dirsrv and attempted to start krb5kdc and this is what 
>> the error log shows
>>
>> # tail /var/log/dirsrv/slapd-ITMODEV-GOV/errors
>> [09/Nov/2015:11:01:02 -0500] - WARNING: userRoot: entry cache size 10485760B 
>> is less than db size 28016640B; We recommend to increase the entry cache 
>> size nsslapd-cachememsize.
>> [09/Nov/2015:11:01:02 -0500] - slapd started.  Listening on All 
>> Interfaces port 389 for LDAP requests
>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - signaling 
>> operation threads
>> [09/Nov/2015:11:06:04 -0500] - slapd shutting down - closing down 
>> internal subsystems and plugins
>> [09/Nov/2015:11:06:04 -0500] - Waiting for 4 database threads to stop
>> [09/Nov/2015:11:06:04 -0500] - All database threads now stopped
>> [09/Nov/2015:11:06:04 -0500] - slapd stopped.
>> [09/Nov/2015:11:14:20 -0500] - 389-Directory/1.2.11.15 B2015.247.1737 
>> starting up
>> [09/Nov/2015:11:14:20 -0500] - WARNING: userRoot: entry cache size 10485760B 
>> is less than db size 28016640B; We recommend to increase the entry cache 
>> size nsslapd-cachememsize.
>> [09/Nov/2015:11:14:20 -0500] - slapd started.  Listening on All 
>> Interfaces port 389 for LDAP requests
> 
> Ok, that's good.
> 
> I'd do something like this to see what is in the db (substitute example.com 
> with your domain):
> 
> $ ldapsearch -x -D 'cn=Directory Manager' -W -s one -b 
> cn=kerberos,dc=example,dc=com
> 
> (don't post the output as it would include the kerberos master key).
> 
> If that returns nothing that's bad.
> 
> If it succeeds I'd broaden the search base a bit to see what data you 
> do
> have:
> 
> $ ldapsearch -x -D 'cn=Directory Manager' -W -b 
> cn=groups,cn=accounts,dc=example,dc=com
> 
> I picked groups because usually groups << users in numbers. This is just to 
> see if you have data in the tree.
> 
> Let us know if either or both turns up nothing.
> 
> rob
> 
>>
>> -Original Message-
>> From: Alexander Bokovoy [mailto:aboko...@redhat.com]
>> Sent: Monday, November 09, 2015 10:51 AM
>> To: Gronde, Christopher (Contractor) 
>> Cc: freeipa-users@redhat.com
>> Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos 
>> authentication error)
>>
>> On Mon, 09 Nov 2015, Gronde, Christopher (Contractor) wrote:
>>> Hello all!
>>>
>>> On my replica IPA server after fixing a cert issue that had been going on 
>>> for sometime, I have all my certs figured out but the krb5kdc service will 
>>> not start.
>>>
>>> # service krb5kdc start
>>> Starting Kerberos 5 KDC: krb5kdc: cannot initialize realm ITMODEV.GOV - see 
>>> log file for details  [FAILED]
>>>
>>> # cat /var/log/krb5kdc.log
>>> krb5kdc: Server error - while fetching master key K/M for realm 
>>> ITMODEV.GOV
>>> krb5kdc: Server error - while 

Re: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl

[Prasun Gera]

You are right in that the fullchain.pem doesn't have the root certificate.
I ran "openssl x509 -in chain.pem -noout -text", and saw that it
had Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3, and Subject:
C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X1. So I got the root
certificate for DST Root CA X3 from
https://www.identrust.com/certificates/trustid/root-download-x3.html, which
is self signed from what I can tell. The issuer and the subject are the
same. I added that to the fullchain, and the command seemed to work.
However, it messed something up, and httpd didn't start after that. httpd
error log had "Unable to verify certificate 'Signing-Cert'. Add
"NSSEnforceValidCerts off" to nss.conf so the server can start until the
problem can be resolved ". I added that to nss.conf, and ipactl started
successfully after that. However, the webui hadn't configured the
certificates properly. At this point, I just restored my backups
of /etc/httpd/conf.d/ and /etc/httpd/alias/, which brought things back to
where things were earlier. I think it would be better to do these
experiments on a test bed first.


On Tue, Nov 10, 2015 at 5:19 PM, Prasun Gera  wrote:

>
>
> On Tue, Nov 10, 2015 at 5:04 PM, Fraser Tweedale 
> wrote:
>
>> On Tue, Nov 10, 2015 at 03:44:19PM -0800, Prasun Gera wrote:
>> > No it didn't quite work.
>> >
>> > I ran ipa-server-certinstall -w /etc/letsencrypt/live/
>> > example.com/privkey.pem /etc/letsencrypt/live/example.com/fullchain.pem
>> >
>> > which gives The full certificate chain is not present in
>> > /etc/letsencrypt/live/example.com/privkey.pem, /etc/letsencrypt/live/
>> > example.com/fullchain.pem
>> >
>> It looks like this error is triggered when there is no self-signed
>> certificate in the trust chain (fullchain.pem).  Could you confirm
>> that this is the case, and if so, could you try appending the root
>> certificate to fullchain.pem and trying again?
>>
>>
>
> I'm sorry, I didn't quite follow. Can you elaborate what I need to append
> to what ?
>
> From let's encrypt's documentation:
>
> cert.pem
> Server certificate only.
>
> This is what Apache needs for SSLCertificateFile.
>
> chain.pem
> All certificates that need to be served by the browser excluding server
> certificate, i.e. root and intermediate certificates only.
>
> This is what Apache needs for SSLCertificateChainFile.
>
> fullchain.pem
> All certificates, including server certificate. This is concatenation of
> chain.pem and cert.pem.
>
> This is what nginx needs for ssl_certificate.
>
>
> So fullchain.pem should have all the relevant bits right ? Do you mean I
> should append ipa's root cert from /etc/ipa/ca.crt ?
>
>
>
>
>
>> It may be that ipa-server-certinstall assumes that your server certs
>> are signed by the same CA as your IPA CA certificate, which need not
>> be the case.
>>
>> >
>> > On Tue, Nov 10, 2015 at 3:31 PM, Fraser Tweedale 
>> > wrote:
>> >
>> > > On Tue, Nov 10, 2015 at 03:12:04PM -0800, Prasun Gera wrote:
>> > > > I tried using let's encrypt's certs manually, but I think I'm
>> missing
>> > > > something. Let's encrypt creates the following files : cert.pem
>> > > chain.pem
>> > > >  fullchain.pem  privkey.pem. I was trying to follow
>> > > >
>> http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP
>> > > but i
>> > > > wasn't able to get it to work. That page says, "The certificate in
>> > > > mysite.crt must be signed by the CA used when installing FreeIPA."
>> Since
>> > > my
>> > > > ipa installation uses the default internal CA, how do I get lets
>> > > encrypt's
>> > > > certs signed by the ipa CA ? Is that the missing step ?
>> > > >
>> > > I do not think that text is correct, in the case of a
>> > > publicy-trusted certificate (i.e. the server cert is chained to a
>> > > trusted issuer).
>> > >
>> > > Just ignore that text and follow the steps.  Does it work?
>> > >
>> > > Cheers,
>> > > Fraser
>> > >
>> > > > On Sat, Nov 7, 2015 at 9:15 PM, Prasun Gera 
>> > > wrote:
>> > > >
>> > > > > Thanks for the discussion. If someone can update the
>> documentation with
>> > > > > mozilla style old, intermediate and modern cipher lists for
>> mod_nss,
>> > > that
>> > > > > would be great. Better still would be to add that option to the
>> > > installer
>> > > > > scripts so that you can choose it during installation. Integrating
>> > > that in
>> > > > > the package would also have the added benefit of settings
>> remaining up
>> > > to
>> > > > > date without manual intervention as standards evolve.
>> > > > >
>> > > > > On Thu, Nov 5, 2015 at 9:23 PM, Fraser Tweedale <
>> ftwee...@redhat.com>
>> > > > > wrote:
>> > > > >
>> > > > >> On Thu, Nov 05, 2015 at 11:52:32PM -0500, Rob Crittenden wrote:
>> > > > >> > Prasun Gera wrote:
>> > > > >> > > Thanks. After the changes, most things seem to be in order.
>> I see
>> > > two
>> > > > >> > > orange flags though:
>> > > > >> > >
>>