Re: [Freeipa-users] Change Password problems (Unsupported Version)

2011-09-28 Thread Goff, Raal

On 28/09/2011, at 12:27 AM, Nalin Dahyabhai wrote:


 Additionally, it seems some users can reset their passwords, but the error 
 still appears in the logs, and on the client software:

 Sep 27 15:08:52 ipa1 kpasswd[2630]: Unsupported version
 Sep 27 15:09:23 ipa1 kpasswd[2633]: Unsupported version
 Sep 27 15:09:54 ipa1 kpasswd[2637]: Password change succeeded

 Are the users who can change their passwords using different client
 software (specifically, versions of Kerberos, which supplies the kpasswd
 command) compared to the users who can't?

The only difference I know about is that the users who CAN change their 
passwords have not got an expired password (so they can login and use kpasswd 
from the shell), whereas those who CANNOT change their password need to reset 
it before logging in (i.e., they get the 'your password has expired, reset it 
now etc etc). I updated the kerberos libraries/tools on the CentOS 6.0 box 
using the Continuous Release repository, and then edited the ldap configuration 
to get around 
https://bugzilla.redhat.com/show_bug.cgi?format=multipleid=713525 and users 
can now reset their passwords on that box during login and on the shell 
(kpasswd). I'm not sure which of these actually fixed the problem (if any).

I'll continue to keep an eye on it for now. It may be as you say, a version 
difference, although I'm unaware of any large differences in versions between 
the machines, is kerberos very sensitive to version changes?


 If you can get a packet capture of a client request, we can examine the
 first few bytes to check what's triggering the failure.


tcpdump says its a V5 packet. I have captured the entire login/reset failure 
and can email it to you directly if you wish.

Thanks,

Raal

ZettaServe Disclaimer: This email and any files transmitted with it are 
confidential and intended solely for the use of the individual or entity to 
whom they are addressed. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately if you have received this email by mistake and delete this email 
from your system. Computer viruses can be transmitted via email. The recipient 
should check this email and any attachments for the presence of viruses. 
ZettaServe Pty Ltd accepts no liability for any damage caused by any virus 
transmitted by this email.


___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users


[Freeipa-users] user login exposes all users in UI

2011-09-28 Thread Stephen Ingram
When logging into the FreeIPA UI as a user, most everything is removed
with the exception of the Identity tab and the Users list. Although
I'm guessing that LDAP needs to expose the users list to all users
just as anyone can view the passwd file on any one system, is there a
technical need to expose all of the users to any user logging into the
UI?

Steve

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users


Re: [Freeipa-users] Change Password problems (Unsupported Version)

2011-09-28 Thread Nalin Dahyabhai
On Wed, Sep 28, 2011 at 02:49:02PM +0800, Goff, Raal wrote:
 The only difference I know about is that the users who CAN change their 
 passwords have not got an expired password (so they can login and use kpasswd 
 from the shell), whereas those who CANNOT change their password need to reset 
 it before logging in (i.e., they get the 'your password has expired, reset it 
 now etc etc). I updated the kerberos libraries/tools on the CentOS 6.0 box 
 using the Continuous Release repository, and then edited the ldap 
 configuration to get around 
 https://bugzilla.redhat.com/show_bug.cgi?format=multipleid=713525 and users 
 can now reset their passwords on that box during login and on the shell 
 (kpasswd). I'm not sure which of these actually fixed the problem (if any).

Ah, somehow I'd missed that you were running 6.0.  If your client
systems are using pam_krb5 instead of SSSD, then you're likely hitting
https://bugzilla.redhat.com/show_bug.cgi?id=690583, which was fixed in
6.1.

 I'll continue to keep an eye on it for now. It may be as you say, a version 
 difference, although I'm unaware of any large differences in versions between 
 the machines, is kerberos very sensitive to version changes?

It's not supposed to be, and usually isn't.  Barring bugs, of course.

  If you can get a packet capture of a client request, we can examine the
  first few bytes to check what's triggering the failure.
 
 tcpdump says its a V5 packet. I have captured the entire login/reset failure 
 and can email it to you directly if you wish.

Sure.  The first four bytes encode the message length (the first two
bytes) and the protocol version number (the next two), so just that part
should actually be enough to verify.

HTH,

Nalin

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users


Re: [Freeipa-users] Change Password problems (Unsupported Version)

2011-09-28 Thread Jakub Hrozek
On Wed, Sep 28, 2011 at 01:59:36PM -0400, Nalin Dahyabhai wrote:
 On Wed, Sep 28, 2011 at 02:49:02PM +0800, Goff, Raal wrote:
  The only difference I know about is that the users who CAN change their 
  passwords have not got an expired password (so they can login and use 
  kpasswd from the shell), whereas those who CANNOT change their password 
  need to reset it before logging in (i.e., they get the 'your password has 
  expired, reset it now etc etc). I updated the kerberos libraries/tools on 
  the CentOS 6.0 box using the Continuous Release repository, and then edited 
  the ldap configuration to get around 
  https://bugzilla.redhat.com/show_bug.cgi?format=multipleid=713525 and 
  users can now reset their passwords on that box during login and on the 
  shell (kpasswd). I'm not sure which of these actually fixed the problem (if 
  any).
 
 Ah, somehow I'd missed that you were running 6.0.  If your client
 systems are using pam_krb5 instead of SSSD, then you're likely hitting
 https://bugzilla.redhat.com/show_bug.cgi?id=690583, which was fixed in
 6.1.
 

He said he was updating the passwords with kpasswd, which should bypass
the pam stack and talk to the kpasswd deamon directly, right?

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users


Re: [Freeipa-users] Change Password problems (Unsupported Version)

2011-09-28 Thread Nalin Dahyabhai
On Wed, Sep 28, 2011 at 09:38:33PM +0200, Jakub Hrozek wrote:
 He said he was updating the passwords with kpasswd, which should bypass
 the pam stack and talk to the kpasswd deamon directly, right?

The users who can change their passwords can log in and do so with
kpasswd, but the ones who can't change their passwords can't log in
to run kpasswd because the login-time password change (which goes
through PAM) is failing.

I expect that users who attempt to change their passwords with the
passwd command are also triggering the same bug.

Nalin

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users


[Freeipa-users] Documentation Interface

2011-09-28 Thread Steven Jones
Hi,

Just going through the latest? F15 documentation and there are pretty pictures!

:D

This is a great improvement as it gives ppl who are unsure of where they are in 
the gui, confidence they are in the right place and are doing the right 
thing!..when you have a written description but looking at a gui its quite 
hard.So I often end up [re-]writing our own documentation because 
manuals are just useless for ppl who have never seen the interface(s) before 
or use it infrequently.

I have also been away from IPA for 2 or 3 months and coming back to it, the 
Interface also seems a bit more intuitive/polished

:D

Now to get my managers to let me loose with it.



regards

Steven Jones

Technical Specialist - Linux RHCE

Victoria University, Wellington, NZ




___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users


Re: [Freeipa-users] Certificate error when modifying/deleting a host

2011-09-28 Thread Sigbjorn Lie

On 09/28/2011 03:33 AM, Adam Young wrote:
After talking with the PKI developer that is fixing this, I found out 
that one other file needs to be modified:



/var/lib/pki-ca/conf/CS.cfg

http.port=8080
https.port=8443





On 09/27/2011 07:55 PM, Adam Young wrote:


Siggi,

This is my comment in the ticket: 
https://fedorahosted.org/freeipa/ticket/1889


We are working on a tool in the PKI project that will perform these 
steps in an automated fashion.



There are three files that need to be addressed.

On the tomcat side, the files are in the Tomcat instance managed by 
IPA in /var/lib/pki-ca. The first is


/var/lib/pki-ca/conf/server.xml

It needs the addition:

+ Connector port=9447 protocol=AJP/1.3 redirectPort=9444 /

You can place it around line 281, above the comment for the line 
Engine name=Catalina defaultHost=localhost


Second is: /var/lib/pki-ca/webapps/ca/WEB-INF/web.xml

For each of the filter entries it needs the code addition below:

init-param

param-nameproxy_port/param-name
param-value443/param-value

/init-param

+ init-param + param-nameproxy_port/param-name + 
param-value443/param-value + /init-param


init-param

param-nameactive/param-name param-valuetrue/param-value

/init-param

/filter

The third change is creating a symlink to /etc/pki-ca/proxy.conf in 
the directory /etc/httpd/conf.d






Sorry for the late reply.

I have performed the modifications you've suggested to 
/var/lib/pki-ca/conf/server.xml, and  
/var/lib/pki-ca/webapps/ca/WEB-INF/web.xml.


In the file /var/lib/pki-ca/conf/CS.cfg, the settings we're already 
http.port=8080 and https.port=8443.


I could not find the file /etc/pki-ca/proxy.conf. I did find 
/usr/share/pki/ca/conf/proxy.conf, I copied this into /etc/httpd/conf.d 
and replaced [PKI_MACHINE_NAME]:[PKI_AJP_PORT] with localhost:9447.


Then I restarted ipa: $ ipactl restart

I get a different error now, same error msg both in webui and cli:
ipa: ERROR: Certificate format error: [Errno -8192] (SEC_ERROR_IO) An 
I/O error occurred during security authorization.


What do you suggest doing next? :)

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Certificate error when modifying/deleting a host

2011-09-28 Thread Adam Young

On 09/28/2011 05:03 PM, Sigbjorn Lie wrote:

On 09/28/2011 03:33 AM, Adam Young wrote:
After talking with the PKI developer that is fixing this, I found out 
that one other file needs to be modified:



/var/lib/pki-ca/conf/CS.cfg

http.port=8080
https.port=8443





On 09/27/2011 07:55 PM, Adam Young wrote:


Siggi,

This is my comment in the ticket: 
https://fedorahosted.org/freeipa/ticket/1889


We are working on a tool in the PKI project that will perform these 
steps in an automated fashion.



There are three files that need to be addressed.

On the tomcat side, the files are in the Tomcat instance managed by 
IPA in /var/lib/pki-ca. The first is


/var/lib/pki-ca/conf/server.xml

It needs the addition:

+ Connector port=9447 protocol=AJP/1.3 redirectPort=9444 /

You can place it around line 281, above the comment for the line 
Engine name=Catalina defaultHost=localhost


Second is: /var/lib/pki-ca/webapps/ca/WEB-INF/web.xml

For each of the filter entries it needs the code addition below:

init-param

param-nameproxy_port/param-name
param-value443/param-value

/init-param

+ init-param + param-nameproxy_port/param-name + 
param-value443/param-value + /init-param


init-param

param-nameactive/param-name param-valuetrue/param-value

/init-param

/filter

The third change is creating a symlink to /etc/pki-ca/proxy.conf in 
the directory /etc/httpd/conf.d






Sorry for the late reply.

I have performed the modifications you've suggested to 
/var/lib/pki-ca/conf/server.xml, and  
/var/lib/pki-ca/webapps/ca/WEB-INF/web.xml.


In the file /var/lib/pki-ca/conf/CS.cfg, the settings we're already 
http.port=8080 and https.port=8443.


I could not find the file /etc/pki-ca/proxy.conf. I did find 
/usr/share/pki/ca/conf/proxy.conf, I copied this into 
/etc/httpd/conf.d and replaced [PKI_MACHINE_NAME]:[PKI_AJP_PORT] with 
localhost:9447.


Then I restarted ipa: $ ipactl restart

I get a different error now, same error msg both in webui and cli:
ipa: ERROR: Certificate format error: [Errno -8192] (SEC_ERROR_IO) An 
I/O error occurred during security authorization.


What do you suggest doing next? :)


/etc/httpd/conf.d/nss.conf:

oot@vm-077 conf.d]# diff nss.conf.orig nss.conf
74c74
 NSSRenegotiation off
---
 NSSRenegotiation on
78c78
 NSSRequireSafeNegotiation off
---
 NSSRequireSafeNegotiation on


As I said, we are scripting this.  I should have had you hold out for 
the script.






___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users


___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

[Freeipa-users] [Fwd: [Freeipa-devel] script to proxy-ize a dogtag instance]

2011-09-28 Thread Ade Lee
Cross-posting to freeipa-users.

In addition, Adam determined that the following dirctives need to be
enabled in  /etc/httpd/conf.d/nss.conf :
 
NSSRenegotiation on
NSSRequireSafeNegotiation on

Ade

---BeginMessage---
Hi, 

With recent changes, Dogtag instances in IPA now reside behind an Apache
proxy and are accessed using ports 80 and 443.  This is the default
configuration for any newly created instances.

Older instances that have been recently upgraded will need to run a
script to upgrade the Dogtag configuration to use the Apache proxy.

A script (pki_setup_proxy) is attached.  It is essentially complete -
only needing things like usage() and some cleanup.  It has been through
some minimal testing.  I am posting it now to help users who are stuck
to fix their existing instances.  It will be delivered as part of
pki-setup in the very near future.

The script will modify the following files (making a backup of each as
$filename.pre-proxy beforehand).
/var/lib/pki-ca/conf/proxy.conf
/var/lib/pki-ca/conf/CS.cfg
/var/lib/pki-ca/conf/server.xml
/var/lib/pki-ca/webapps/ca/WEB_INF/web.xml
/var/lib/pki-ca/webappas/ca/ee/ca/ProfileSubmit.template

And will log all actions in /var/log/pki-ca-proxy-setup.log

*
Instructions for IPA:

1. Run the script as follows (as root):
chmod +x pki-setup-proxy
./pki-setup-proxy -pki_instance_root=/var/lib -pki_instance_name=pki-ca 
-subsystem_type=ca

2. Copy the proxy.conf file: 

cp /var/lib/pki-ca/conf/proxy.conf /etc/httpd/conf.d/ipa-pki-proxy.conf

3. Restart IPA.



Please send me feedback if things don't work!

Thanks, 
Ade




pki-setup-proxy
Description: Perl program
___
Freeipa-devel mailing list
freeipa-de...@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel---End Message---
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Certificate error when modifying/deleting a host

2011-09-28 Thread Sigbjorn Lie

On 09/28/2011 11:35 PM, Adam Young wrote:

On 09/28/2011 05:03 PM, Sigbjorn Lie wrote:

On 09/28/2011 03:33 AM, Adam Young wrote:
After talking with the PKI developer that is fixing this, I found 
out that one other file needs to be modified:



/var/lib/pki-ca/conf/CS.cfg

http.port=8080
https.port=8443





On 09/27/2011 07:55 PM, Adam Young wrote:


Siggi,

This is my comment in the ticket: 
https://fedorahosted.org/freeipa/ticket/1889


We are working on a tool in the PKI project that will perform these 
steps in an automated fashion.



There are three files that need to be addressed.

On the tomcat side, the files are in the Tomcat instance managed by 
IPA in /var/lib/pki-ca. The first is


/var/lib/pki-ca/conf/server.xml

It needs the addition:

+ Connector port=9447 protocol=AJP/1.3 redirectPort=9444 /

You can place it around line 281, above the comment for the line 
Engine name=Catalina defaultHost=localhost


Second is: /var/lib/pki-ca/webapps/ca/WEB-INF/web.xml

For each of the filter entries it needs the code addition below:

init-param

param-nameproxy_port/param-name
param-value443/param-value

/init-param

+ init-param + param-nameproxy_port/param-name + 
param-value443/param-value + /init-param


init-param

param-nameactive/param-name
param-valuetrue/param-value

/init-param

/filter

The third change is creating a symlink to /etc/pki-ca/proxy.conf in 
the directory /etc/httpd/conf.d






Sorry for the late reply.

I have performed the modifications you've suggested to 
/var/lib/pki-ca/conf/server.xml, and  
/var/lib/pki-ca/webapps/ca/WEB-INF/web.xml.


In the file /var/lib/pki-ca/conf/CS.cfg, the settings we're already 
http.port=8080 and https.port=8443.


I could not find the file /etc/pki-ca/proxy.conf. I did find 
/usr/share/pki/ca/conf/proxy.conf, I copied this into 
/etc/httpd/conf.d and replaced [PKI_MACHINE_NAME]:[PKI_AJP_PORT] with 
localhost:9447.


Then I restarted ipa: $ ipactl restart

I get a different error now, same error msg both in webui and cli:
ipa: ERROR: Certificate format error: [Errno -8192] (SEC_ERROR_IO) An 
I/O error occurred during security authorization.


What do you suggest doing next? :)


/etc/httpd/conf.d/nss.conf:

oot@vm-077 conf.d]# diff nss.conf.orig nss.conf
74c74
 NSSRenegotiation off
---
 NSSRenegotiation on
78c78
 NSSRequireSafeNegotiation off
---
 NSSRequireSafeNegotiation on


As I said, we are scripting this.  I should have had you hold out for 
the script.


:)

I see Ade Lee has posted the script now. I'll have a go at the script 
tomorrow.


Rgds,
Siggi


___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Certificate error when modifying/deleting a host

2011-09-28 Thread Adam Young

On 09/28/2011 05:59 PM, Sigbjorn Lie wrote:

On 09/28/2011 11:35 PM, Adam Young wrote:

On 09/28/2011 05:03 PM, Sigbjorn Lie wrote:

On 09/28/2011 03:33 AM, Adam Young wrote:
After talking with the PKI developer that is fixing this, I found 
out that one other file needs to be modified:



/var/lib/pki-ca/conf/CS.cfg

http.port=8080
https.port=8443





On 09/27/2011 07:55 PM, Adam Young wrote:


Siggi,

This is my comment in the ticket: 
https://fedorahosted.org/freeipa/ticket/1889


We are working on a tool in the PKI project that will perform 
these steps in an automated fashion.



There are three files that need to be addressed.

On the tomcat side, the files are in the Tomcat instance managed 
by IPA in /var/lib/pki-ca. The first is


/var/lib/pki-ca/conf/server.xml

It needs the addition:

+ Connector port=9447 protocol=AJP/1.3 redirectPort=9444 /

You can place it around line 281, above the comment for the line 
Engine name=Catalina defaultHost=localhost


Second is: /var/lib/pki-ca/webapps/ca/WEB-INF/web.xml

For each of the filter entries it needs the code addition below:

init-param

param-nameproxy_port/param-name
param-value443/param-value

/init-param

+ init-param + param-nameproxy_port/param-name + 
param-value443/param-value + /init-param


init-param

param-nameactive/param-name
param-valuetrue/param-value

/init-param

/filter

The third change is creating a symlink to /etc/pki-ca/proxy.conf 
in the directory /etc/httpd/conf.d






Sorry for the late reply.

I have performed the modifications you've suggested to 
/var/lib/pki-ca/conf/server.xml, and  
/var/lib/pki-ca/webapps/ca/WEB-INF/web.xml.


In the file /var/lib/pki-ca/conf/CS.cfg, the settings we're already 
http.port=8080 and https.port=8443.


I could not find the file /etc/pki-ca/proxy.conf. I did find 
/usr/share/pki/ca/conf/proxy.conf, I copied this into 
/etc/httpd/conf.d and replaced [PKI_MACHINE_NAME]:[PKI_AJP_PORT] 
with localhost:9447.


Then I restarted ipa: $ ipactl restart

I get a different error now, same error msg both in webui and cli:
ipa: ERROR: Certificate format error: [Errno -8192] (SEC_ERROR_IO) 
An I/O error occurred during security authorization.


What do you suggest doing next? :)


/etc/httpd/conf.d/nss.conf:

oot@vm-077 conf.d]# diff nss.conf.orig nss.conf
74c74
 NSSRenegotiation off
---
 NSSRenegotiation on
78c78
 NSSRequireSafeNegotiation off
---
 NSSRequireSafeNegotiation on


As I said, we are scripting this.  I should have had you hold out for 
the script.


:)

I see Ade Lee has posted the script now. I'll have a go at the script 
tomorrow.


Rgds,
Siggi




___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Well, that script assumes the machine is in a certain state.  I am not 
sure if you machine now qualifies.  You shold only need the nss.conf  
change, as that seems to match the error you are seeing.


Before you make any changes, try pointing  a browser at

https://hostname/ca/ee/ca/getCertChain

And you should get a valid response:  XML with a tag ChainBase64

This shows that Dogtag is being proxied correctly.  The error you are 
seeing is due to the need to renegotiate the SSL handshake for the  
authed sections of the PKI-CA.





___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] user login exposes all users in UI

2011-09-28 Thread Adam Young

On 09/28/2011 01:13 PM, Stephen Ingram wrote:

When logging into the FreeIPA UI as a user, most everything is removed
with the exception of the Identity tab and the Users list. Although
I'm guessing that LDAP needs to expose the users list to all users
just as anyone can view the passwd file on any one system, is there a
technical need to expose all of the users to any user logging into the
UI?

Steve

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users



The UI does not remove any privs. That same user can run the command 
line  ipa user-find and get the same results.  Additionally, the user 
has the ability to query the LDAP server directly.   Thus, we decided to 
leave the ability to enumerate all users, but not to advertise it.  We 
did remove tabs for other things that the user can do, mainly because 
some of them  pointed at operations that the user was not allowed to see 
(Roles, for example, and Sudo commands for another).  We had to draw the 
line somewhere, and that is where we decided.  It has the added benefit 
of letting IPA work as a company directory.


___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users