Re: [Freeipa-users] Certificate system unavailable
On 01/31/2014 08:32 PM, Rob Crittenden wrote: Sigbjorn Lie wrote: On Fri, January 17, 2014 16:37, Rob Crittenden wrote: Sigbjorn Lie wrote: This worked better than expected. Thank you! :) ipa01 and ipa02 seem to be happy again, getcert list no longer displays any certificates out of date, and all certificates in need of renewal within 28 days has been renewed. The webui also started working again and things seem to be back to normal. ipa03 however is still having issues. I could not renew any certificates on this server to begin with, but I managed to renew the certificates for the directory servers by changing the xmlrpc url to another ipa server in /etc/ipa/default.conf and resubmitting these requests. getcert resubmit -i request-id says SUBMITTING and the fails with NEED_GUIDANCE after a short while for the certificates for the PKI service. /var/log/messages says: certmonger: #033[?1034h28800 and python: Updated certificate for ipaCert not available. There is a lot of information in the /var/log/pki-ca/debug, but nothing that I can easily distinguish as an error from all the other output. Anything in particular I should look for? Ok, so this is a bug in IPA related to python readline. Garbage is getting inserted and causing bad things to happen, https://fedorahosted.org/freeipa/ticket/4064 So the question is, are the certs available or not. A number of the same certificates are shared amongst all the CAs. One does the renewal and stuffs the result into cn=ca_renewal,cn=ipa,cn=etc,$SUFFIX. The other CAs refer to that location for an updated cert and will load them if they are updated. Look to see if the certs are updated there. Given that you have 2 working masters I'm assuming that is the case, so it may just be a matter of fixing the python. I could not get anywhere even after manually patching the python script as mentioned in the ticket you provided. I ended up removing and re-adding the replica during a maintenance window. For future reference, what I did was to remove the replica as per the Identity Management Guide on docs.redhat.com. I then re-created the replica installation file and installed the replica. At this point Certmonger managed to retrieve new certificates for the expired certificates, but it kept segfaulting when it attempted to save the certificate to disk. I restarted certmonger a few times, but certmonger just ended up segfaulting over and over. I decided to block the ipa server off the network and change the date back to before the certs expired. After the date was changed I restarted certmonger. Certmonger managed to save the certs successfully this time and a getcert list now displays only certificates with an expire date of 2015 or 2016 and a status of MONTORING. I changed the date back to correct date and time and removed the iptables rules. The replica now works just fine. Thank you for your assistance. Sounds like https://bugzilla.redhat.com/show_bug.cgi?id=1032760 rob This one might be related as well: https://bugzilla.redhat.com/show_bug.cgi?id=1040009. Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Deploying freeipa behind nginx
Yes it works if I specify the -s as ldap.mycorp.com. So we have progress! It now appears to authenticate fine when it posts the session but I have a new error. I get an Ipa Error 911 Missing HTTP referer. br/ You have to configure your browser to send HTTP referer header. I assume this is because the external name doesn't match the internal name. Is there a way to modify this somewhere? Thanks. Steve On Mon, Feb 3, 2014 at 4:40 AM, Sumit Bose sb...@redhat.com wrote: On Fri, Jan 31, 2014 at 01:50:58PM -0800, Steve Severance wrote: Hi Sumit, That does indeed work. What does that tell us? I'm sorry, but it only tells that in general GSSAPI/Kerberos is working. I think it does not help much with your original issue. About ipa-getkeytab, does it work if you specify the server with the -s/--server option? bye, Sumit Steve On Wed, Jan 29, 2014 at 12:11 AM, Sumit Bose sb...@redhat.com wrote: On Tue, Jan 28, 2014 at 02:29:07PM -0800, Steve Severance wrote: Hi Everyone, I have deployed freeipa inside our production network. I want to be able to access the web ui so I am attempting to add it to our nginx edge machine. I can pass the requests upstream just fine but I am unable to login using a username/password. I have enabled password authentication in the kerberos section of the freeipa httpd config file. In the logs it looks like the authentication succeeds and a ticket is issued. I assume that the cookie that is returned (ipa_session) has the authentication information in it. The subsequent call to get json data fails and I am prompted to login again. I found this thread ( https://www.redhat.com/archives/freeipa-users/2013-August/msg00080.html) which has instructions on adding ipa.mydomain.com to the keytab. When I call ipa-getkeytab it hangs for a bit before returning: ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) Digging into this if I run: ldapsearch -d 1 -v -H ldaps:// ldap.mydomain.com I get: ldap_sasl_interactive_bind_s: Unknown authentication method (-6) additional info: SASL(-4): no mechanism available: Does it work if you add the mechanism explicitly, e.g. 'ldapsearch -Y GSSAPI ' ? bye, Sumit So we seem to have a SASL problem. If I run ldapsearch with -x simple authentication works just fine. Do I need to do something special to enable SASL so I can get the keytab? The ipa-getkeytab command does not seem to have an option to use simple authentication. Thanks. Steve ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Steve Severance Director of Engineering Altos Research e. st...@altosresearch.com m. (240) 472 - 9645 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Deploying freeipa behind nginx
On Mon, 03 Feb 2014, Steve Severance wrote: Yes it works if I specify the -s as ldap.mycorp.com. So we have progress! It now appears to authenticate fine when it posts the session but I have a new error. I get an Ipa Error 911 Missing HTTP referer. br/ You have to configure your browser to send HTTP referer header. I assume this is because the external name doesn't match the internal name. Is there a way to modify this somewhere? You can read https://bugzilla.redhat.com/show_bug.cgi?id=747710 for details and https://rhn.redhat.com/errata/RHSA-2011-1533.html is the security errata addressing it. We are deliberately closing cross-site forgery by enforcing HTTP referrer checks. Your nginx proxy would be a middle man which we are attempting to protect against. Recent discussions on how to allow your use case but still keep the security tight can be seen here: http://comments.gmane.org/gmane.linux.redhat.freeipa.user/8920 (latter part of the thread). Discussion stalled since then. Thanks. Steve On Mon, Feb 3, 2014 at 4:40 AM, Sumit Bose sb...@redhat.com wrote: On Fri, Jan 31, 2014 at 01:50:58PM -0800, Steve Severance wrote: Hi Sumit, That does indeed work. What does that tell us? I'm sorry, but it only tells that in general GSSAPI/Kerberos is working. I think it does not help much with your original issue. About ipa-getkeytab, does it work if you specify the server with the -s/--server option? bye, Sumit Steve On Wed, Jan 29, 2014 at 12:11 AM, Sumit Bose sb...@redhat.com wrote: On Tue, Jan 28, 2014 at 02:29:07PM -0800, Steve Severance wrote: Hi Everyone, I have deployed freeipa inside our production network. I want to be able to access the web ui so I am attempting to add it to our nginx edge machine. I can pass the requests upstream just fine but I am unable to login using a username/password. I have enabled password authentication in the kerberos section of the freeipa httpd config file. In the logs it looks like the authentication succeeds and a ticket is issued. I assume that the cookie that is returned (ipa_session) has the authentication information in it. The subsequent call to get json data fails and I am prompted to login again. I found this thread ( https://www.redhat.com/archives/freeipa-users/2013-August/msg00080.html) which has instructions on adding ipa.mydomain.com to the keytab. When I call ipa-getkeytab it hangs for a bit before returning: ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) Digging into this if I run: ldapsearch -d 1 -v -H ldaps:// ldap.mydomain.com I get: ldap_sasl_interactive_bind_s: Unknown authentication method (-6) additional info: SASL(-4): no mechanism available: Does it work if you add the mechanism explicitly, e.g. 'ldapsearch -Y GSSAPI ' ? bye, Sumit So we seem to have a SASL problem. If I run ldapsearch with -x simple authentication works just fine. Do I need to do something special to enable SASL so I can get the keytab? The ipa-getkeytab command does not seem to have an option to use simple authentication. Thanks. Steve ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Steve Severance Director of Engineering Altos Research e. st...@altosresearch.com m. (240) 472 - 9645 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- / Alexander Bokovoy ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Deploying freeipa behind nginx
So I understand the mitigation of CSRF attacks. I would like ipa to be able
to handle a specific set of referers. My use case may be less common since
my freeipa instance is handling our server infrastructure not desktops.
I have everything working now. Here is an example nginx server config in
case anyone else needs it:
server {
server_name ipa.corp.com;
listen 443 ssl;
location / {
proxy_cookie_domain ldap.corp.com ipa.corp.com;
proxy_pass https://ldap.corp.com/;
proxy_set_header Referer https://ldap.corp.com/ipa/ui;
}
}
ipa.corp.com would be the external server and ldap.corp.com would be the
internal server.
Thanks for your help.
Steve
On Mon, Feb 3, 2014 at 11:10 AM, Alexander Bokovoy aboko...@redhat.comwrote:
On Mon, 03 Feb 2014, Steve Severance wrote:
Yes it works if I specify the -s as ldap.mycorp.com. So we have progress!
It now appears to authenticate fine when it posts the session but I have a
new error.
I get an Ipa Error 911 Missing HTTP referer. br/ You have to configure
your browser to send HTTP referer header. I assume this is because the
external name doesn't match the internal name. Is there a way to modify
this somewhere?
You can read https://bugzilla.redhat.com/show_bug.cgi?id=747710 for
details and https://rhn.redhat.com/errata/RHSA-2011-1533.html is the
security errata addressing it.
We are deliberately closing cross-site forgery by enforcing
HTTP referrer checks.
Your nginx proxy would be a middle man which we are attempting to
protect against.
Recent discussions on how to allow your use case but still keep the
security tight can be seen here:
http://comments.gmane.org/gmane.linux.redhat.freeipa.user/8920 (latter
part of the thread). Discussion stalled since then.
Thanks.
Steve
On Mon, Feb 3, 2014 at 4:40 AM, Sumit Bose sb...@redhat.com wrote:
On Fri, Jan 31, 2014 at 01:50:58PM -0800, Steve Severance wrote:
Hi Sumit, That does indeed work. What does that tell us?
I'm sorry, but it only tells that in general GSSAPI/Kerberos is working.
I think it does not help much with your original issue. About
ipa-getkeytab, does it work if you specify the server with the
-s/--server option?
bye,
Sumit
Steve
On Wed, Jan 29, 2014 at 12:11 AM, Sumit Bose sb...@redhat.com wrote:
On Tue, Jan 28, 2014 at 02:29:07PM -0800, Steve Severance wrote:
Hi Everyone,
I have deployed freeipa inside our production network. I want to be
able
to
access the web ui so I am attempting to add it to our nginx edge
machine. I
can pass the requests upstream just fine but I am unable to login
using a
username/password. I have enabled password authentication in the
kerberos
section of the freeipa httpd config file. In the logs it looks like
the
authentication succeeds and a ticket is issued. I assume that the
cookie
that is returned (ipa_session) has the authentication information
in
it.
The subsequent call to get json data fails and I am prompted to
login
again.
I found this thread (
https://www.redhat.com/archives/freeipa-users/2013-August/msg00080.html)
which has instructions on adding ipa.mydomain.com to the keytab.
When I
call ipa-getkeytab it hangs for a bit before returning:
ldap_sasl_bind(SIMPLE):
Can't contact LDAP server (-1)
Digging into this if I run: ldapsearch -d 1 -v -H ldaps://
ldap.mydomain.com
I get:
ldap_sasl_interactive_bind_s: Unknown authentication method (-6)
additional info: SASL(-4): no mechanism available:
Does it work if you add the mechanism explicitly, e.g. 'ldapsearch -Y
GSSAPI ' ?
bye,
Sumit
So we seem to have a SASL problem. If I run ldapsearch with -x
simple
authentication works just fine.
Do I need to do something special to enable SASL so I can get the
keytab?
The ipa-getkeytab command does not seem to have an option to use
simple
authentication.
Thanks.
Steve
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
--
Steve Severance
Director of Engineering
Altos Research
e. st...@altosresearch.com
m. (240) 472 - 9645
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
--
/ Alexander Bokovoy
--
Steve Severance
Director of Engineering
Altos Research
e. st...@altosresearch.com
m. (240) 472 - 9645
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] HBAC - expected behaviour?
Hi, Running freeipa 3.0.0-37.el6 on rhel 6.4 and just had a query about HBAC rules and how the global allow_all rule applies. I configured a rule for a single host (host1) allowing access via ssh to only a single user (john) via ssh. i.e. # ipa hbacrule-show host1_access Rule name: host1_access Description: Only john can access host1 Enabled: TRUE Users: john Hosts: host1.domain.com Services: sshd When I run the hbac test against the rule, checking another user jane, it works as expected to deny access to jane. But if I include the allow_all rule in the test jane is granted access and can login. I also proved this by actually using ssh to login. If I access the host host1 and remove allow_all from its defined HBAC rules in the web ui, jane can still access host1 via ssh (actually tested login). In the end, for the rule to work as expected (jane to be disallowed access to host1), I've had to modify the allow_all HBAC rule and set it to apply to all hosts except host1. # ipa hbacrule-show allow_all Rule name: allow_all User category: all sourcehostcategory: all Service category: all Description: Allow all users to access any host from any host Enabled: TRUE Hosts: host2.domain.com, host3.domain.com, host4.domain.com Is this how its supposed to be? Or is it a bug in this older version? I would have thought that if the host didn't have the hbac rule allow_all applied to it, just the restrictive host1_access rule, that allow_all wouldn't apply. Thanks, Les ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] How to restore an IPA Replica when the CSN number generator has moved impossibly far into the future or past
If you are seeing clock skew errors in /var/log/dirsrv/slapd-EXAMPLE-COM/errors that look like this, then you will need to verify the time/date of the server to make sure NTP isn't freaked out. If the system date is correct, it is possible that the change numbergenerator has skewed.[01/Feb/2014:14:42:06 -0800] NSMMReplicationPlugin - conn=12949 op=7 repl="dc=example,dc=com": Excessive clock skew from supplier RUV[01/Feb/2014:14:42:06 -0800] - csngen_adjust_time: adjustment limit exceeded; value - 1448518, limit - 86400[01/Feb/2014:14:42:06 -0800] - CSN generator's state:[01/Feb/2014:14:42:06 -0800] - replica id: 115[01/Feb/2014:14:42:06 -0800] - sampled time: 1391294526[01/Feb/2014:14:42:06 -0800] - local offset: 0[01/Feb/2014:14:42:06 -0800] - remote offset: 0[01/Feb/2014:14:42:06 -0800] - sequence number: 55067The following NsState_Script should be used to determine whether the change number generator has jumped significantly from the real time/date.https://github.com/richm/scripts/blob/master/readNsState.pyThe usage for the script works like this:[r...@ipaserver.ops jaquino]# ./readNsState.py /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldifnsState is cwBGPfBSAQACAA==Little EndianFor replica cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config fmtstr=[H6x3QH6x] size=40 len of nsstate is 40 CSN generator state: Replica ID : 115 Sampled Time : 1391476038 Gen as csn : 52f03d4600020115 Time as str : Mon Feb 3 17:07:18 2014 Local Offset : 0 Remote Offset : 1 Seq. num : 2 System time : Mon Feb 3 17:09:11 2014 Diff in sec. : 113 Day:sec diff : 0:113If the output from the above command is over a day or more out of sync, then the reason is because the CSN generator has become grossly skewed. It will be necessary to perform the following steps to recover.How to resolve this issue• 1: Select an ipa server to be authoritative and write the contents of its database to an ldif file On the master supplier: /var/lib/dirsrv/scripts-EXAMPLE-COM/db2ldif.pl -D 'cn=Directory Manager' -w - -n userRoot -a /tmp/master-389.ldif Note that without the -r option it is deliberately ommiting the tainted replication data which contains the bad CSNs• 2: On the ipa server, shutdown its dirsrv daemon down so that you can reset the attribute responsible for the serial generation, and so that you can re-initialize its db from the known good ldif On the master supplier: ipactl stop• 3: Sanitize the dse.ldif Configuration File On the master supplier: edit the /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif file and remove the nsState attribute from the replica config entry You DO NOT want to remove the nsState from: dn: cn=uniqueid generator,cn=config The stanza you want to remove the value from is: dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config The attribute will look like this: nsState:: cwA3QPBSAQABAA== Delete the entire line• 3.1: Remove traces of stale CSN tracking in the Replica Agreements themeselves File location: /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif cat dse.ldif | sed -n '1 {h; $ !d}; $ {x; s/\n //g; p}; /^ / {H; d}; /^ /! {x; s/\n //g; p}' | grep -v nsds50ruv new.dse.ldif backup the old dse.ldif and replace it with the new one: # mv dse.ldif dse.saved.ldif # mv new.dse.ldif dse.ldif• 4: Import the data from the known good ldif. This will mark all the changes with CSNs that match the current time/date stamps On the master supplier: chmod 644 /tmp/master-389.ldif /var/lib/dirsrv/scripts-EXAMPLE-COM/ldif2db -n userRoot -i /tmp/master-389.ldif• 5: Restart the ipa daemons on the master supplier #ipactl start• 6: When the daemon starts, it will see that it does not have an nsState and will write new CSN's to -all- of the newly imported good data with today's timetamp, we need to take that data and write -it- out to an ldif file On the master supplier: /var/lib/dirsrv/scripts-EXAMPLE-COM/db2ldif.pl -D 'cn=Directory Manager' -w - -n userRoot -r -a /tmp/replication-master-389.ldif ^ the -r tells it to include all replica data which includes the newly blessed CSN data transfer the file to all of the ipa servers in the fleet• 7: Now we must re-initialize _every other_ ipa consumer server in the fleet with the new good data. Steps 7-10 need to be done 1 at a time on each ipa consumer server ipactl stop• 8: Sanitize the dse.ldif Configuration File On the ipa server: edit the /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif file and remove the nsState attribute from the replica config entry You DO NOT want to remove the nsState from: dn: cn=uniqueid generator,cn=config The stanza you want to remove the value from is: dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config The attribute will look like this: nsState:: cwA3QPBSAQABAA== Delete the entire line• 8.1: Remove traces of stale CSN tracking in the Replica Agreements themeselves File
Re: [Freeipa-users] HBAC - expected behaviour?
On 02/04/2014 05:11 AM, Les Stott wrote: Hi, Running freeipa 3.0.0-37.el6 on rhel 6.4 and just had a query about HBAC rules and how the global allow_all rule applies. I configured a rule for a single host (host1) allowing access via ssh to only a single user (john) via ssh. i.e. # ipa hbacrule-show host1_access Rule name: host1_access Description: Only john can access host1 Enabled: TRUE Users: john Hosts: host1.domain.com Services: sshd When I run the hbac test against the rule, checking another user jane, it works as expected to deny access to jane. But if I include the allow_all rule in the test jane is granted access and can login. I also proved this by actually using ssh to login. If I access the host host1 and remove allow_all from its defined HBAC rules in the web ui, jane can still access host1 via ssh (actually tested login). In the end, for the rule to work as expected (jane to be disallowed access to host1), I've had to modify the allow_all HBAC rule and set it to apply to all hosts except host1. # ipa hbacrule-show allow_all Rule name: allow_all User category: all sourcehostcategory: all Service category: all Description: Allow all users to access any host from any host Enabled: TRUE Hosts: host2.domain.com, host3.domain.com, host4.domain.com Is this how its supposed to be? Or is it a bug in this older version? I would have thought that if the host didn't have the hbac rule allow_all applied to it, just the restrictive host1_access rule, that allow_all wouldn't apply. Thanks, Les Hello Les, I am not aware of any recent bugs in HBAC, this is likely a configuration issue. This is how the default HBAC allow_all looks like: # ipa hbacrule-show allow_all Rule name: allow_all User category: all Host category: all sourcehostcategory: all Service category: all Description: Allow all users to access any host from any host Enabled: TRUE Host category: all means that the rule is effective for all hosts. By selectively specifying the hosts, you disabled this selector. Does it help? Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
