Re: [Freeipa-users] Screensaver unlock with expired password

[Dmitri Pal]

On 04/14/2012 08:20 AM, Sigbjorn Lie wrote:
> Hi,
>
> I ran into a issue with unlocking the screensaver when an users
> password has expired. These results are from RHEL 5.
>
> When running KDE and unlocking a screensaver with an expired password,
> an error message is displayed advising that the password subsystem has
> failed with instructions to kill the PID of the screensaver manually.
>
> When running GNOME and unlocking the screensaver with an expired
> password, an unlock is allowed, but no message is displayed, and the
> kerberos ticket is not renewed.
>
> Neither of these situations are ideal.
>
> A workaround for KDE is to switch to a console login window with
> CTRL-ALT-F2,  and log in where you will be prompted for changing your
> password. Switch back to KDE, and unlock the screensaver with the new
> password. Not really user friendly.
>
> We did have the krb5-auth-dialog running, but it turned out that after
> being away over the weekend there many of these appearing on the
> screen on monday morning, and once you typed in your password a new
> kerberos ticket was aquired with start date of when the
> krb5-auth-dialog appeared!!
>
> So if I left the office on Friday, and the krb5-auth-dialog appeared
> on Saturday, I would get a ticket expiring on the Sunday that's
> already passed, even though I typed in the password on Monday,
> rendering the ticket useless for authenticating anywhere... so we
> removed this package from our workstations.
>
> Has anyone else run into these sort of issues? I would like to know
> how you chose to work around these issues.
>
> Thanks.
>

It can also be a client configuration or software problem. What do you
use on the client? SSSD? nss_ldap+pam_krb5?
I assume you use IPA as a server. You can check the logs on the server
to see whether the new password is requested.
The client logs would really show what is going on.

Best would be if you provide a clear reproduction steps and file a
ticket attaching logs and configuration to it.
If it is a bug in SSSD we would need to fix it ASAP though we have not
seen this behavior in SSSD ever.

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


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



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

Re: [Freeipa-users] routing requests to local servers - DNS SRV + view?

[Dmitri Pal]

On 04/13/2012 11:00 PM, Brian Cook wrote:
> Yes, this is exactly what I am trying to accomplish.  I've already
> been looking in to the BIND views clause and would like to hear if
> anyone has any feedback as to how well this works in the real world.
>
> In this case the implementation of IPA is using an external standard
> BIND implementation loading from text files.  However, views would be
> very useful for IPA to be able to do internally, so figuring out how
> to  get this option in to BIND using 389ds backend would be a useful step.
>

AFAIK there is an SSSD RFE that allows you to define a group of primary
servers for a client that the client would use to fail over between and
only when they all are not available it will fail over to DNS. At least
I remember a discussion about it. It seems that such feature would
accomplish the same but with less work. Would it be sufficient?

See comment 6 in the https://fedorahosted.org/sssd/ticket/1128

> Thanks,
> Brian
>
> ---
> Brian Cook
> Solutions Architect, Red Hat, Inc.
> 407-212-7079
>
>
>
>
> On Apr 13, 2012, at 2:41 PM, Petr Spacek wrote:
>
>> On 04/13/2012 10:28 PM, Jakub Hrozek wrote:
>>> On Fri, Apr 13, 2012 at 01:04:55PM -0700, Brian Cook wrote:
Ideally I would rely on a -group- of servers, and then rely on
 DNS if it
is down.  I don't want to hammer one server.  We're talking
 about 500-1000
servers running virtual machines, so potentially a lot of
 traffic.  Got
any suggestions for that?
>>>
>>> Hello Brian,
>>>
>>> I'm not sure I understand what you are trying to achieve. Are you trying
>>> to spread the client load among replicas? If so, then I think the SRV
>>> records in DNS are really the best answer. You can organize the servers
>>> in "tiers" by using the priority field and then spread the load in a
>>> tier by using the "weight" field.
>>
>> Greetings,
>>
>> if I understand correctly, you need to set different priority for SRV
>> records and this new priority has to be dependent on client's IP address.
>>
>> AFAIK only way how to accomplish this is BIND "view" clause. You have to:
>> - create copy of original zone for each location and modify SRV
>> record priorities
>> - then you have to set "views" and create mapping between IP address
>> <-> new zone
>>
>>
>> This way requires multiple copies of original zone, each with little
>> differences.
>> In case of classical zone files is not a big problem: You can keep
>> SRV records separated in small files and "$INCLUDE" normal records to
>> them from single place.
>>
>> In cases with LDAP database it's a much harder, because there is no
>> simple $INCLUDE clause, I think.
>> We have to consult this problem with 389 guys ... It can be task for
>> some kind of directory server plugin.
>>
>>
>> Some examples and documentation:
>> http://wiki.sipfoundry.org/display/sipXecs/Location+based+DNS+views+for+sipXecs+using+BIND
>> (It belongs to some SIP solution, but it's exactly what you want.)
>>
>> http://www.zytrax.com/books/dns/ch7/view.html
>>
>> http://ftp.isc.org/isc/bind9/cur/9.7/doc/arm/Bv9ARM.ch06.html#view_statement_grammar
>>
>>
>> I'm adding BIND maintainer to this discussion.
>>
>> Petr^2 Spacek
>>
>> ___
>> 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


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



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

Re: [Freeipa-users] routing requests to local servers - DNS SRV + view?

[Jakub Hrozek]

On Mon, Apr 16, 2012 at 09:40:16AM -0400, Dmitri Pal wrote:
>On 04/13/2012 11:00 PM, Brian Cook wrote:
> 
>  Yes, this is exactly what I am trying to accomplish.  I've already been
>  looking in to the BIND views clause and would like to hear if anyone has
>  any feedback as to how well this works in the real world.
>  In this case the implementation of IPA is using an external standard
>  BIND implementation loading from text files.  However, views would be
>  very useful for IPA to be able to do internally, so figuring out how to
>   get this option in to BIND using 389ds backend would be a useful step.
> 
>AFAIK there is an SSSD RFE that allows you to define a group of primary
>servers for a client that the client would use to fail over between and
>only when they all are not available it will fail over to DNS. At least I
>remember a discussion about it. It seems that such feature would
>accomplish the same but with less work. Would it be sufficient?
> 
>See comment 6 in the https://fedorahosted.org/sssd/ticket/1128

Yes, except with the feature that Petr Spacek is proposing, the
configuration would be performed purely on server side, as I understood.

The SSSD fix would work, but would require that clients in different
"sites" have different primary servers configured. Still, doable with
puppet or something, just not as convenient.

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

Re: [Freeipa-users] multiple domains/realms?

[Dmitri Pal]

On 04/13/2012 03:23 AM, Christoph Kaminski wrote:
> Hi
>
> I have multiple domains her but I want to use one user/group etc.
> database. How can I do it? Options:
> 1. Different realm for each domain, but how to share the user/group
> etc infos betwen different ipa servers?
> 2. One realm for al domains. Possible? (it is possible to change the
> realm after install/config?)
> 3. ?
>
> Does someone have experience with multiple domains and ipa and can
> give some tips?
> TiA
>

IPA currently supports just a single domain.
Can you please provide more information about what you are trying to
accomplish?
If you want to have same user/group name space across multiple realms
then why do you need multiple realms?
You can have one realm and many replicas that serve many offices if this
is the use case you are trying to solve.

Thanks
Dmitri

> MfG
> Christoph Kaminski
>
>
>
> www.biotronik.com 
> 
>
> BIOTRONIK SE & Co. KG
> Woermannkehre 1, 12359 Berlin, Germany
> Sitz der Gesellschaft: Berlin, Registergericht: Berlin HRA 6501
>
> Vertreten durch ihre Komplementärin:
> BIOTRONIK MT SE
> Sitz der Gesellschaft: Berlin, Registergericht: Berlin HRB 118866 B
> Geschäftsführende Direktoren: Christoph Böhmer, Dr. Werner Braun, Dr.
> Lothar Krings, Dr. Torsten Wolf
> 
>
> *BIOTRONIK* - A global manufacturer of advanced Cardiac Rhythm
> Management systems and Vascular Intervention devices. Quality,
> innovation, and reliability define BIOTRONIK and our growing success.
> We are innovators of technologies like the first wireless remote
> monitoring system - Home Monitoring®, Closed Loop Stimulation and
> coveted lead solutions as well as state-of-the-art stents, balloons
> and guide wires for coronary and peripheral indications. We highly
> invest in the development of drug eluting devices and are leading the
> industry with our drug eluting absorbable metal scaffold program.
> 
>
> This e-mail and the information it contains including attachments are
> confidential and meant only for use by the intended recipient(s);
> disclosure or copying is strictly prohibited. If you are not
> addressed, but in the possession of this e-mail, please notify the
> sender immediately and delete the document.
>
>
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



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

Re: [Freeipa-users] routing requests to local servers - DNS SRV + view?

[Dmitri Pal]

On 04/16/2012 09:46 AM, Jakub Hrozek wrote:
> On Mon, Apr 16, 2012 at 09:40:16AM -0400, Dmitri Pal wrote:
>>On 04/13/2012 11:00 PM, Brian Cook wrote:
>>
>>  Yes, this is exactly what I am trying to accomplish.  I've already been
>>  looking in to the BIND views clause and would like to hear if anyone has
>>  any feedback as to how well this works in the real world.
>>  In this case the implementation of IPA is using an external standard
>>  BIND implementation loading from text files.  However, views would be
>>  very useful for IPA to be able to do internally, so figuring out how to
>>   get this option in to BIND using 389ds backend would be a useful step.
>>
>>AFAIK there is an SSSD RFE that allows you to define a group of primary
>>servers for a client that the client would use to fail over between and
>>only when they all are not available it will fail over to DNS. At least I
>>remember a discussion about it. It seems that such feature would
>>accomplish the same but with less work. Would it be sufficient?
>>
>>See comment 6 in the https://fedorahosted.org/sssd/ticket/1128
> Yes, except with the feature that Petr Spacek is proposing, the
> configuration would be performed purely on server side, as I understood.
>
> The SSSD fix would work, but would require that clients in different
> "sites" have different primary servers configured. Still, doable with
> puppet or something, just not as convenient.

Sure but it is a minor feature for SSSD while would be a major feature
for IPA.
On SSSD side it is already scheduled on the IPA side we might not have
enough time to do it soon.

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


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



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

Re: [Freeipa-users] Unable to login where previously OK

[Jakub Hrozek]

On Thu, Apr 12, 2012 at 09:23:03PM +, Steven Jones wrote:
> sssd log at lvl6
> 
> regards
> 
> Steven Jones
> 
> Technical Specialist - Linux RHCE
> 
> Victoria University, Wellington, NZ
> 
> 0064 4 463 6272
> 

Which SSSD version is this?

Are the clients that work OK the same version?

Can you also attach /var/log/sssd/sssd_pam.log ?

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

[Freeipa-users] Disaster Recovery Best Practices?

[KodaK]

Hi,

I have googled around a bit, but I still have a couple of questions:

1) is it possible to get "getent shadow" to return shadow entries from
the ipa server?  This is so we can do a DR test on some server or set
of servers without also having to restore the IPA server first.  I can
do a "getent passwd" easily enough, and I could rebuild the shadow
file for local users, so it's not critical, but it would be a "nice to
have" in the case of a DR.

2) What is everyone else doing to prepare IPA for a DR?  I've read
that the best way to do it is to turn off the IPA services on a
replica and then back that replica up.  I also read that this will
miss some important files that only exist on the master.  I don't want
to turn off the master server services for a DR due to failover lag.
Would it be safe to take a backup of the master while "hot", then
restore a replica, and promote it to master using the "hot" backup of
the master (just the specific CA files needed)?

Thanks,

--Jason

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

Re: [Freeipa-users] Disaster Recovery Best Practices?

[Dmitri Pal]

On 04/16/2012 03:13 PM, KodaK wrote:
> Hi,
>
> I have googled around a bit, but I still have a couple of questions:
>
> 1) is it possible to get "getent shadow" to return shadow entries from
> the ipa server?  This is so we can do a DR test on some server or set
> of servers without also having to restore the IPA server first.  I can
> do a "getent passwd" easily enough, and I could rebuild the shadow
> file for local users, so it's not critical, but it would be a "nice to
> have" in the case of a DR.
Please use SSSD on the client. It will do all the caching for you. If
the connection is lost to the central server the client will continue to
operate and authenticate users that logged in previously at least once.
There is no need to create shadow files on the client in this case.
Shadow is a mistake of the past that should not be used when there are
are other much more secure technologies available now.

> 2) What is everyone else doing to prepare IPA for a DR?  I've read
> that the best way to do it is to turn off the IPA services on a
> replica and then back that replica up.  I also read that this will
> miss some important files that only exist on the master. 

That is the case when you use selfsigned cert but the preferred and
default configuration is not with the self-signed certs. It was in the
past but not any more. Currently when you install IPA and then replicas
there is no difference between master and replicas (if you installed CA
on the replica) so picking any one and recycling is possible. You won't
loose anything. 

>  I don't want
> to turn off the master server services for a DR due to failover lag.
> Would it be safe to take a backup of the master while "hot", then
> restore a replica, and promote it to master using the "hot" backup of
> the master (just the specific CA files needed)?

So turning off any server of your choice backing it up (taking a
snapshot) and then re-starting it again is the simplest way of dealing
with DR.
But to do this make sure that the server that you plan to use for taking
backup snapshots has a CA.


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


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



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

Re: [Freeipa-users] Disaster Recovery Best Practices?

[Simo Sorce]

On Mon, 2012-04-16 at 14:13 -0500, KodaK wrote:
> Hi,
> 
> I have googled around a bit, but I still have a couple of questions:
> 
> 1) is it possible to get "getent shadow" to return shadow entries from
> the ipa server? 

No, we do not have any shadow map in ipa, enforcement of password and
account expiration is done by the server, not deferred to the clients.

>  This is so we can do a DR test on some server or set
> of servers without also having to restore the IPA server first.  I can
> do a "getent passwd" easily enough, and I could rebuild the shadow
> file for local users, so it's not critical, but it would be a "nice to
> have" in the case of a DR.

What are you looking for in the shadow map ?

> 2) What is everyone else doing to prepare IPA for a DR?  I've read
> that the best way to do it is to turn off the IPA services on a
> replica and then back that replica up.  I also read that this will
> miss some important files that only exist on the master.

This was true for ipa v1 only where we used a selfsigned CA available
only in the first master, since v2 you are supposed to use the dogtag
PKI, so if you clone the PKI as well (you need to explicitly set it up,
by default replicas do not replicate the CA) you have full redundancy
with regard to network facing data.

>   I don't want
> to turn off the master server services for a DR due to failover lag.
> Would it be safe to take a backup of the master while "hot", then
> restore a replica, and promote it to master using the "hot" backup of
> the master (just the specific CA files needed)?

If you are using the dogtag CA it wouldn't as it uses a DS instance as
well. If you are using the selfsigned CA well, I guess you have no other
option.

Simo.


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

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

Re: [Freeipa-users] Screensaver unlock with expired password

[Sigbjorn Lie]

On 04/16/2012 03:33 PM, Dmitri Pal wrote:

On 04/14/2012 08:20 AM, Sigbjorn Lie wrote:

Hi,

I ran into a issue with unlocking the screensaver when an users
password has expired. These results are from RHEL 5.

When running KDE and unlocking a screensaver with an expired password,
an error message is displayed advising that the password subsystem has
failed with instructions to kill the PID of the screensaver manually.

When running GNOME and unlocking the screensaver with an expired
password, an unlock is allowed, but no message is displayed, and the
kerberos ticket is not renewed.

Neither of these situations are ideal.

A workaround for KDE is to switch to a console login window with
CTRL-ALT-F2,  and log in where you will be prompted for changing your
password. Switch back to KDE, and unlock the screensaver with the new
password. Not really user friendly.

We did have the krb5-auth-dialog running, but it turned out that after
being away over the weekend there many of these appearing on the
screen on monday morning, and once you typed in your password a new
kerberos ticket was aquired with start date of when the
krb5-auth-dialog appeared!!

So if I left the office on Friday, and the krb5-auth-dialog appeared
on Saturday, I would get a ticket expiring on the Sunday that's
already passed, even though I typed in the password on Monday,
rendering the ticket useless for authenticating anywhere... so we
removed this package from our workstations.

Has anyone else run into these sort of issues? I would like to know
how you chose to work around these issues.

Thanks.


It can also be a client configuration or software problem. What do you
use on the client? SSSD? nss_ldap+pam_krb5?
I assume you use IPA as a server. You can check the logs on the server
to see whether the new password is requested.
The client logs would really show what is going on.


The clients use nss_ldap+pam_krb5, SSSD was crashing for us on RHEL 5.

The server is the IPA server provided in RHEL 6.2.

When I check the logs on the client it states that authentication 
succeeded, and that the password has expired.  And that's where the 
screensaver fails. It show an info message that the password has 
expired, and then an error message advising that "The password subsystem 
has failed..."



Best would be if you provide a clear reproduction steps and file a
ticket attaching logs and configuration to it.
If it is a bug in SSSD we would need to fix it ASAP though we have not
seen this behavior in SSSD ever.



This is not SSSD, I believe it either comes down to lack of support in 
the KDE screensaver or a requirement for change in the PAM 
configuration. The current PAM configuration is set by the 
system-config-auth script with the" --enable-ldap --enable-krb5" options.


I was hoping for a change in the PAM configuration and that someone had 
an example that works to advise me about.




Regards,
Siggi

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

Re: [Freeipa-users] Screensaver unlock with expired password

[Dmitri Pal]

On 04/16/2012 05:17 PM, Sigbjorn Lie wrote:
> On 04/16/2012 03:33 PM, Dmitri Pal wrote:
>> On 04/14/2012 08:20 AM, Sigbjorn Lie wrote:
>>> Hi,
>>>
>>> I ran into a issue with unlocking the screensaver when an users
>>> password has expired. These results are from RHEL 5.
>>>
>>> When running KDE and unlocking a screensaver with an expired password,
>>> an error message is displayed advising that the password subsystem has
>>> failed with instructions to kill the PID of the screensaver manually.
>>>
>>> When running GNOME and unlocking the screensaver with an expired
>>> password, an unlock is allowed, but no message is displayed, and the
>>> kerberos ticket is not renewed.
>>>
>>> Neither of these situations are ideal.
>>>
>>> A workaround for KDE is to switch to a console login window with
>>> CTRL-ALT-F2,  and log in where you will be prompted for changing your
>>> password. Switch back to KDE, and unlock the screensaver with the new
>>> password. Not really user friendly.
>>>
>>> We did have the krb5-auth-dialog running, but it turned out that after
>>> being away over the weekend there many of these appearing on the
>>> screen on monday morning, and once you typed in your password a new
>>> kerberos ticket was aquired with start date of when the
>>> krb5-auth-dialog appeared!!
>>>
>>> So if I left the office on Friday, and the krb5-auth-dialog appeared
>>> on Saturday, I would get a ticket expiring on the Sunday that's
>>> already passed, even though I typed in the password on Monday,
>>> rendering the ticket useless for authenticating anywhere... so we
>>> removed this package from our workstations.
>>>
>>> Has anyone else run into these sort of issues? I would like to know
>>> how you chose to work around these issues.
>>>
>>> Thanks.
>>>
>> It can also be a client configuration or software problem. What do you
>> use on the client? SSSD? nss_ldap+pam_krb5?
>> I assume you use IPA as a server. You can check the logs on the server
>> to see whether the new password is requested.
>> The client logs would really show what is going on.
>>
> The clients use nss_ldap+pam_krb5, SSSD was crashing for us on RHEL 5.
>
> The server is the IPA server provided in RHEL 6.2.
>
> When I check the logs on the client it states that authentication
> succeeded, and that the password has expired.  And that's where the
> screensaver fails. It show an info message that the password has
> expired, and then an error message advising that "The password
> subsystem has failed..."
>
>> Best would be if you provide a clear reproduction steps and file a
>> ticket attaching logs and configuration to it.
>> If it is a bug in SSSD we would need to fix it ASAP though we have not
>> seen this behavior in SSSD ever.
>>
>
> This is not SSSD, I believe it either comes down to lack of support in
> the KDE screensaver or a requirement for change in the PAM
> configuration. The current PAM configuration is set by the
> system-config-auth script with the" --enable-ldap --enable-krb5" options.
>
> I was hoping for a change in the PAM configuration and that someone
> had an example that works to advise me about.
>

I do not think we know enough about KDE to be able help you here. Sorry.

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


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



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

Re: [Freeipa-users] Screensaver unlock with expired password

[Nalin Dahyabhai]

On Mon, Apr 16, 2012 at 11:17:35PM +0200, Sigbjorn Lie wrote:
> The clients use nss_ldap+pam_krb5, SSSD was crashing for us on RHEL 5.
> 
> The server is the IPA server provided in RHEL 6.2.
> 
> When I check the logs on the client it states that authentication
> succeeded, and that the password has expired.  And that's where the
> screensaver fails. It show an info message that the password has
> expired, and then an error message advising that "The password
> subsystem has failed..."
> 
> >Best would be if you provide a clear reproduction steps and file a
> >ticket attaching logs and configuration to it.
> >If it is a bug in SSSD we would need to fix it ASAP though we have not
> >seen this behavior in SSSD ever.
> 
> This is not SSSD, I believe it either comes down to lack of support
> in the KDE screensaver or a requirement for change in the PAM
> configuration. The current PAM configuration is set by the
> system-config-auth script with the" --enable-ldap --enable-krb5"
> options.
> 
> I was hoping for a change in the PAM configuration and that someone
> had an example that works to advise me about.

Short version: try turning on the "chpw_prompt" option for pam_krb5, by
setting something like this in /etc/krb5.conf:

 [appdefaults]
  pam = {
   chpw_prompt = kscreensaver gnome-screensaver
  }

Long version: as you've noticed, some applications don't quite do what
PAM expects of them when the user's password has expired.  When the user
needs to set a new password, PAM is supposed to succeed in the
authentication phase, and then return an specific status, indicating
that a password change is needed, in the account management phase.

Based on that second result, the application can either start a password
change through PAM (and then allow access only if that change operation
succeeds), or reject the user if it can't handle a password change
(think of FTP servers, where the protocol keeps a server from being able
to ask for a new password).  Some applications don't know to do either,
so the password-expired status is treated as a fatal error, and that
appears to be what's going on here.

Turning on the "chpw_prompt" option causes pam_krb5 to let libkrb5
attempt to change the password, during authentication, if a password
change is needed.  Depending on the application, that might be enough to
fix things.  It depends on the application to not just reply with the
same password without relaying the question to the user, and you don't
get the chance to add any client-side password quality checking via PAM,
but it might work if the application can handle multiple prompts
correctly.

If that change allows users to log in (or unlock their screens, in this
case), then you've found a bug in the PAM-enabled application, which is
unfortunately not unheard of.  The need to provide this option was first
reported [1] after we fixed pam_krb5 to do the right thing [2].

HTH,

Nalin

[1] https://bugzilla.redhat.com/show_bug.cgi?id=509092
[2] https://bugzilla.redhat.com/show_bug.cgi?id=402721

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

[Freeipa-users] Problem creating replica file

[Jorge Argibay Molina]

Hi,

I'm in the testing phase of the deployment of FreeIPA in my network.

So far I've been able to configure the server, and several clients.

What I've been unable to do, and seems very easy going thru the documentation, 
is generate the replica.

Whenever I do:

ipa-replica-prepare hades.watea.com.ar --ip-address 192.168.1.180

I get

Directory Manager (existing master) password: 

Warning: Hostname (hades.watea.com.ar) not found in DNS
Preparing replica for hades.watea.com.ar from ares.watea.com.ar
Creating SSL certificate for the Directory Server
Certificate issuance failed

I'm attaching the pki-ca debug log, where I get an error.


I'm out of ideas, Can anyone suggest what maybe broken or any documentation 
that has a suggestion about fixing this issue?
[16/Apr/2012:17:59:15][http-9444-1]: CMSServlet:service() uri = 
/ca/ee/ca/profileSubmitSSLClient
[16/Apr/2012:17:59:15][http-9444-1]: CMSServlet::service() param 
name='cert_request_type' value='pkcs10'
[16/Apr/2012:17:59:15][http-9444-1]: CMSServlet::service() param 
name='cert_request' 
value='MIICeTCCAWECAQAwNDEVMBMGA1UEChMMV0FURUEuQ09NLkFSMRswGQYDVQQDExJo
YWRlcy53YXRlYS5jb20uYXIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDOMU0ArlCel4hSh4vWRyrLNuTEHSCGuOwc4haf+8OxlQLzkEPLtcfAJGqHIa2I
j8Ux5zzfvLOIaElDgUE7n4CbQc/XqgmA4ofn0c8JwR5aVqtcTfuclTEQxkWjoSO5
DiUH006RbBRx3aPeXxT7SwbMLiBJp3FClnxZcai63TMUTq6j0x6KlGPglN7QDr6/
iH6QAG0C58HzR2emNtySV6TjCHVC6hNjbUk+hy9rsT0jUnffGqElxvgAF//uDlhX
efF0/sVynx+XTeHTrMkxBH/2WfPE15Ho//ZePl2Oi+GMwYXhUcuW4U707NdyG0Dx
yVsQRk7LyxkbAAEAIRJGzhQdAgMBAAGgADANBgkqhkiG9w0BAQUFAAOCAQEAXXOs
o0Fpg8N3wfaeUic2ksqxmBhWfgoGS7qYLUrgrZQ7j7hO6B0jFK9eQ8smK9DtbXes
K8/vfzT5YipeCoxD8TCFqEEYxuuPaLxA8in1UvjYFDO0ZOb9yxYx4ZxHxNIQZqDY
ZzCV5sTIlqmJJ6j+2HhThclyt+LcSea1LgUcH7T10haEwOCkHgVeFyTrBRjqFKqE
mK0rZo9FpP3N6R5Wy1/KWH4tAh18XDAbcdI9dZ5fp1O1cPeCJOTOtTNne33BORtg
p1n4ZpAwX0qoI8pmPUORyKzCVm8Oknkgz50Pf912ePHUaX1vdZ0gW0jX9P/PWpmz
FA7kP9YYf+e62p+KHg==
'
[16/Apr/2012:17:59:15][http-9444-1]: CMSServlet::service() param 
name='requestor_name' value='IPA Installer'
[16/Apr/2012:17:59:15][http-9444-1]: CMSServlet::service() param 
name='xmlOutput' value='true'
[16/Apr/2012:17:59:15][http-9444-1]: CMSServlet::service() param 
name='profileId' value='caIPAserviceCert'
[16/Apr/2012:17:59:15][http-9444-1]: CMSServlet: caProfileSubmitSSLClient start 
to service.
[16/Apr/2012:17:59:15][http-9444-1]: xmlOutput true
[16/Apr/2012:17:59:15][http-9444-1]: Start of ProfileSubmitServlet Input 
Parameters
[16/Apr/2012:17:59:15][http-9444-1]: ProfileSubmitServlet Input Parameter 
cert_request_type='pkcs10'
[16/Apr/2012:17:59:15][http-9444-1]: ProfileSubmitServlet Input Parameter 
cert_request='MIICeTCCAWECAQAwNDEVMBMGA1UEChMMV0FURUEuQ09NLkFSMRswGQYDVQQDExJo
YWRlcy53YXRlYS5jb20uYXIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDOMU0ArlCel4hSh4vWRyrLNuTEHSCGuOwc4haf+8OxlQLzkEPLtcfAJGqHIa2I
j8Ux5zzfvLOIaElDgUE7n4CbQc/XqgmA4ofn0c8JwR5aVqtcTfuclTEQxkWjoSO5
DiUH006RbBRx3aPeXxT7SwbMLiBJp3FClnxZcai63TMUTq6j0x6KlGPglN7QDr6/
iH6QAG0C58HzR2emNtySV6TjCHVC6hNjbUk+hy9rsT0jUnffGqElxvgAF//uDlhX
efF0/sVynx+XTeHTrMkxBH/2WfPE15Ho//ZePl2Oi+GMwYXhUcuW4U707NdyG0Dx
yVsQRk7LyxkbAAEAIRJGzhQdAgMBAAGgADANBgkqhkiG9w0BAQUFAAOCAQEAXXOs
o0Fpg8N3wfaeUic2ksqxmBhWfgoGS7qYLUrgrZQ7j7hO6B0jFK9eQ8smK9DtbXes
K8/vfzT5YipeCoxD8TCFqEEYxuuPaLxA8in1UvjYFDO0ZOb9yxYx4ZxHxNIQZqDY
ZzCV5sTIlqmJJ6j+2HhThclyt+LcSea1LgUcH7T10haEwOCkHgVeFyTrBRjqFKqE
mK0rZo9FpP3N6R5Wy1/KWH4tAh18XDAbcdI9dZ5fp1O1cPeCJOTOtTNne33BORtg
p1n4ZpAwX0qoI8pmPUORyKzCVm8Oknkgz50Pf912ePHUaX1vdZ0gW0jX9P/PWpmz
FA7kP9YYf+e62p+KHg==
'
[16/Apr/2012:17:59:15][http-9444-1]: ProfileSubmitServlet Input Parameter 
requestor_name='IPA Installer'
[16/Apr/2012:17:59:15][http-9444-1]: ProfileSubmitServlet Input Parameter 
xmlOutput='true'
[16/Apr/2012:17:59:15][http-9444-1]: ProfileSubmitServlet Input Parameter 
profileId='caIPAserviceCert'
[16/Apr/2012:17:59:15][http-9444-1]: End of ProfileSubmitServlet Input 
Parameters
[16/Apr/2012:17:59:15][http-9444-1]: ProfileSubmitServlet: start serving
[16/Apr/2012:17:59:15][http-9444-1]: ProfileSubmitServlet: SubId=profile
[16/Apr/2012:17:59:15][http-9444-1]: ProfileSubmitServlet: isRenewal false
[16/Apr/2012:17:59:15][http-9444-1]: ProfileSubmitServlet: profileId 
caIPAserviceCert
[16/Apr/2012:17:59:15][http-9444-1]: ProfileSubmitServlet: authenticator 
raCertAuth found
[16/Apr/2012:17:59:15][http-9444-1]: 
ProfileSubmitServlet:setCredentialsIntoContext() authIds` null
[16/Apr/2012:17:59:15][http-9444-1]: ProfileSubmistServlet: set Inputs into 
profile Context
[16/Apr/2012:17:59:15][http-9444-1]: ProfileSubmitServlet: set 
sslClientCertProvider
[16/Apr/2012:17:59:15][http-9444-1]: ProfileSubmitServlet: authentication 
required.
[16/Apr/2012:17:59:15][http-9444-1]: CMSServlet: in auditSubjectID
[16/Apr/2012:17:59:15][http-9444-1]: CMSServlet: auditSubjectID auditContext 
{sslClientCertProvider=com.netscape.cms.servlet.profile.SSLClientCertProvider@1d6dba0a,
 profileContext=com.netscape.cms.profile.common.EnrollProfileContext@ed0f59e}

Re: [Freeipa-users] Problem creating replica file

[Dmitri Pal]

On 04/16/2012 05:14 PM, Jorge Argibay Molina wrote:
> Hi,
>
> I'm in the testing phase of the deployment of FreeIPA in my network.
>
> So far I've been able to configure the server, and several clients.
>
> What I've been unable to do, and seems very easy going thru the 
> documentation, is generate the replica.
>
> Whenever I do:
>
> ipa-replica-prepare hades.watea.com.ar --ip-address 192.168.1.180
>
> I get
>
> Directory Manager (existing master) password: 
>
> Warning: Hostname (hades.watea.com.ar) not found in DNS
> Preparing replica for hades.watea.com.ar from ares.watea.com.ar
> Creating SSL certificate for the Directory Server
> Certificate issuance failed
>
> I'm attaching the pki-ca debug log, where I get an error.
>
>
> I'm out of ideas, Can anyone suggest what maybe broken or any documentation 
> that has a suggestion about fixing this issue?

Please provide package versions for the ipa, 389 and dogtag.
Did you use any specific certificate related option when installed the
first IPA master? 

>
>
>
> Thanks
>
>
>
>
>
>   
> Jorge Argibay
> jorge.argi...@watea.com.ar
>
> Tel.: (+54) 11 5277 0305 Int.: 4900
> Cel: (+549) 11 4028 4900
>
> USA: (+1) 786 866 7837 Int.: 4900
> C. Rica: (+506) 4000 1650 Int.: 4900
>
>
>
>
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



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

[Freeipa-users] client without certmonger/dbus

[Christoph Kaminski]

hi

It is possible to use the ipa-client without certmonger/dbus? Have an 
openvz environemnt where I cant start dbus...

-
MfG
Christoph Kaminski



www.biotronik.com

BIOTRONIK SE & Co. KG
Woermannkehre 1, 12359 Berlin, Germany
Sitz der Gesellschaft: Berlin, Registergericht: Berlin HRA 6501

Vertreten durch ihre Komplementärin:
BIOTRONIK MT SE
Sitz der Gesellschaft: Berlin, Registergericht: Berlin HRB 118866 B
Geschäftsführende Direktoren: Christoph Böhmer, Dr. Werner Braun, Dr. 
Lothar Krings, Dr. Torsten Wolf

BIOTRONIK - A global manufacturer of advanced Cardiac Rhythm Management 
systems and Vascular Intervention devices. Quality, innovation, and 
reliability define BIOTRONIK and our growing success. We are innovators of 
technologies like the first wireless remote monitoring system - Home 
Monitoring®, Closed Loop Stimulation and coveted lead solutions as well as 
state-of-the-art stents, balloons and guide wires for coronary and 
peripheral indications. We highly invest in the development of drug 
eluting devices and are leading the industry with our drug eluting 
absorbable metal scaffold program.

This e-mail and the information it contains including attachments are 
confidential and meant only for use by the intended recipient(s); 
disclosure or copying is strictly prohibited. If you are not addressed, 
but in the possession of this e-mail, please notify the sender immediately 
and delete the document.
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users