[Freeipa-users] meaning of several domains in sssd.conf

[Jan-Frode Myklebust]

What does it mean to have several domains listed in sssd.conf ? Will
they all be queried on each login, or will only the first domain be
queried if the user/groups is found there?

Does having an IPA domain, and an LDAP domain pointing at the same
servers give any protection against failures in the sssd_BE process
allowing sssd to fail over to the next sssd_BE ?


  -jf

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

Re: [Freeipa-users] Transferring "mastership" to a new server

[Rajnesh Kumar Siwal]

Is is still required if the replica is created using the following command:-
# ipa-replica-install --setup-ca --setup-dns

-- 
Regards,
Rajnesh Kumar Siwal

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

Re: [Freeipa-users] FreeIPA for AMM users management

[Артур Файзуллин]

Ok! I will try :) but would you give me some advice :) what configs to
put. should I use:
* "Use LDAP Servers for Authentication and Authorization"
* "Use DNS to find LDAP Servers"
and put here domain name if IPA-server?
* should in "Active Directory Settings" Enhanced role-based security be
enabled? And what means AMM Target Name?
* root dn = something like this dc=example,dc=com ?
* Binding method which one to choose?
w/ Configured Credentials
w/ Login Credentials

Some questions may be stupid, but I want to be sure in them :)

В Вт., 26/02/2013 в 12:41 +0100, Petr Spacek пишет:
> On 26.2.2013 11:49, Артур Файзуллин wrote:
> > And what?
> > Is there any result? I try same thing with my AMM and IPA
> 
> Unfortunately, we don't have sufficient information to give you any advice.
> 
> Please, try to provide output from a sniffer as I asked in last reply. Then 
> we 
> will try to help you. (You can send the data to me privately, if you want.)
> 
> Petr^2 Spacek
> 
> > В Пн., 05/11/2012 в 09:32 +0100, Petr Spacek пишет:
> >> On 11/03/2012 01:12 PM, Pavel Zhukov wrote:
>  Can you do NS lookup of the IPA server from the AMM box?
> >>> yes
>  Can you do kinit from the AMM box against IPA?
>  Can you do ldapsearch from the AMM box against IPA?
> >>> no, AMM has restricted shell and web GUI.
> >>
> >> Hmm, that is unfortunate. Can you run tcpdump (or sniffer provided on AMM) 
> >> on
> >> the link between AMM and IPA server? Because there are no records in access
> >> log I will bet on some name resolution or firewall problem.
> >>
> >> Do AMM get right DNS responses (i.e. name and IP address of the IPA 
> >> server)?
> >>
> >> Do AMM established TCP connection with the IPA server?
> >>
> >> --
> >> Petr^2 Spacek
> >>
>  Do you see anything in the logs from such activity?
> 
> ___
> 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] FQDN Hostname Requirement

[freeipa]

Hi All,

Spec:
Red Hat Enterprise Linux Server release 6.3 (Santiago)
ipa-server-2.2.0-16.el6.x86_64

Issue:
I made a post a while back regarding IPA and the forcing of the hostname
to be a FQDN entry, rather than utilising `hostname --fqdn`

ref: https://www.redhat.com/archives/freeipa-users/2012-March/msg00012.html

Has this issue ever been addressed? As I've now bumped into an issue
with RSA Securid Auth Manager 6.1, which will not work on a server with
more than 27 characters in the hostname. Sadly our hostname does break
this is some cases.

cya

Craig

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

Re: [Freeipa-users] ipa: ERROR: attribute 'idnsAllowTransfer' not allowed

[Sigbjorn Lie]

Hi.

This is ipa 2.2 on rhel 6.3. Upgraded from rhel 6.2. Initial install on 6.2.


Rgds
Siggi


Martin Kosek  wrote:

>On 02/25/2013 03:38 PM, Sigbjorn Lie wrote:
>> On Mon, February 25, 2013 12:59, Christian Horn wrote:
>>> Hi,
>>>
>>>
>>> On Mon, Feb 25, 2013 at 09:46:49AM +0100, Sigbjorn Lie wrote:
>>>

 $ ipa dnszone-add example.com --name-server=ns01.example.com
 --admin-email=hostmaster.example.com
 ipa: ERROR: attribute "idnsAllowTransfer" not allowed


 [..]


 Is this a known error?

>>>
>>> Yes,
>>> the idnsZone objectClass entry was not updated properly during
>ipa-server update process. To fix
>>> this the schema has to be modified,
>https://access.redhat.com/knowledge/solutions/301213 has
>>> the details.
>>>
>> 
>> Thank you. That worked just fine. :)
>> 
>> 
>> Regards,
>> Siggi
>> 
>
>Hi guys, I am glad you resolved the issue. I am just curious - from
>what
>version to what version did you upgrade? Is this is a bug in IPA in
>RHEL 6.4?
>
>Thank you,
>Martin

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] proper way to clear sssd cache without sss_cache?

[Jakub Hrozek]

On Tue, Feb 26, 2013 at 02:36:42PM -0500, Dmitri Pal wrote:
> On 02/26/2013 02:29 PM, KodaK wrote:
> > I know that at some point the sssd package (or maybe the tools
> > package) started including sss_cache for managing the sssd cache.  I
> > have some RHEL5 boxes that don't have this utility.
> >
> > I've been stopping the sssd service, deleting the contents of
> > /var/lib/sss/db/ and then restarting and things seem to be working OK,
> > but I wanted to find out if there was a proper procedure?
> >
> > Thanks!
> >
> Yes it was the proper procedure until we added a tool.

The only thing to keep in mind is that by wiping out the whole cache
removes all cached passwords. Depending on whether you use
cache_credentials=True or whether your clients need to cache credentials
at all you do or don't care :-)

If you care, you might want to use the ldbmodify utility to instead
set the dataExpire timestamp to a timestamp from the past (this is what
sss_cache does internally btw)

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

Re: [Freeipa-users] Non-Prod instance

[Guy Matz]

Thanks!  Is it a matter of isolating the networks?  Or just making sure 
clients are pointing to the correct server?


Thanks again,
Guy

On 02/26/2013 02:45 PM, Dmitri Pal wrote:

On 02/25/2013 09:58 AM, Guy Matz wrote:

Hello!  Does anyone out there run two instances of freeipa, prod &
non-prod instances?  Are there any issues to be wary of in this
scenario?  Any gotchas?  Do you use the same realms & domain names
between instances?

As long as you completely isolate one from another network wise you can
use whatever names you want.


Perhaps the fellow who upgraded his prod server to 6.4 might
appreciate this . . .

Thanks a lot,
Guy

___
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

Re: [Freeipa-users] Non-Prod instance

[Dmitri Pal]

On 02/25/2013 09:58 AM, Guy Matz wrote:
> Hello!  Does anyone out there run two instances of freeipa, prod &
> non-prod instances?  Are there any issues to be wary of in this
> scenario?  Any gotchas?  Do you use the same realms & domain names
> between instances?

As long as you completely isolate one from another network wise you can
use whatever names you want.

>
> Perhaps the fellow who upgraded his prod server to 6.4 might
> appreciate this . . .
>
> Thanks a lot,
> Guy
>
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
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] proper way to clear sssd cache without sss_cache?

[Steven Jones]

Hi,

Its what I have to do on most client side issues and what RH support advise. I 
was told that the sssd daemon would be upgraded in 6.4, its certainly seems to 
be my main pain point right now.

regards

Steven Jones

Technical Specialist - Linux RHCE

Victoria University, Wellington, NZ

0064 4 463 6272


From: freeipa-users-boun...@redhat.com [freeipa-users-boun...@redhat.com] on 
behalf of KodaK [sako...@gmail.com]
Sent: Wednesday, 27 February 2013 8:29 a.m.
To: freeipa-users@redhat.com
Subject: [Freeipa-users] proper way to clear sssd cache without sss_cache?

I know that at some point the sssd package (or maybe the tools
package) started including sss_cache for managing the sssd cache.  I
have some RHEL5 boxes that don't have this utility.

I've been stopping the sssd service, deleting the contents of
/var/lib/sss/db/ and then restarting and things seem to be working OK,
but I wanted to find out if there was a proper procedure?

Thanks!

--
The government is going to read our mail anyway, might as well make it
tough for them.  GPG Public key ID:  B6A1A7C6

___
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

Re: [Freeipa-users] proper way to clear sssd cache without sss_cache?

[Dmitri Pal]

On 02/26/2013 02:29 PM, KodaK wrote:
> I know that at some point the sssd package (or maybe the tools
> package) started including sss_cache for managing the sssd cache.  I
> have some RHEL5 boxes that don't have this utility.
>
> I've been stopping the sssd service, deleting the contents of
> /var/lib/sss/db/ and then restarting and things seem to be working OK,
> but I wanted to find out if there was a proper procedure?
>
> Thanks!
>
Yes it was the proper procedure until we added a tool.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
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] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC

[Dmitri Pal]

On 02/25/2013 02:29 PM, Mercer, Rodney wrote:
> I think that this is a good explanation or the solaris rbac model.
>
> http://www.softpanorama.org/Solaris/Security/solaris_rbac.shtml
>
> Regards,
> Rodney.
I will definitely read it. But assume I did.
What are the next steps?
The schema is the right one so do you plan to start the design work?
Would you start with the server side or with SSSD side?

Adding schema to IPA and populating it with ldap modify or my loading
ldif might give you enough to start designing and developing the SSSD
component. The management interface for the server side can be added
after the SSSD side is done.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
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] IPA,NFS4,krb5p Ticket expired error

[Dmitri Pal]

On 02/26/2013 02:03 PM, Johan Petersson wrote:
> Hi,
>
> I have a IPA server, NFS4 Server sharing home directories with autofs
> and krb5p as only valid authentication.
> Mail Postfix/Dovecot both with startTLS and GSSAPI.
> All servers and clients are Red Hat 6.3 and updated with latest kernel
> and everything else.
>
> If i start and log in locally as user1 on a IPA Client machine
> everything works perfect including mail and home directory initially.
> I then start experience errors when trying to ssh other servers as ssh
> us...@mail.example.com.
> Nothing happens, no password question, nothing until i have to ctrl-c
> (tried leaving it overnight - still same).
> Mail stops working, thunderbird complain about expired credentials.
> If i use ssh as root to the server and then try either: su user1 or su
> - user1 both get same result as ssh user1.
> Sometimes a su have actually worked and i can browse to my
> mounted home directory but get permission denied when trying to access.
> id works and permissions on home directory shows ok but can't access
> anyway.
>
> The only thing i have found helping is to logout user1 on the client,
> login root and then ssh as user1.
> In that case i get password question and it works with home directory.
> If i logout root then, login user1 then mail, ssh and su works again
> for some time.
>
> I guess the credential renewal works in that case.
>
> Firewalls turned off, tried setenforce=0 and autofs on debug log mode
> but find nothing.
>
> Even sshd logging on and verbose ssh shows nothing wrong.
> It is like everything works but a expired ticket or something similar
> generate the error, tickets are new though and should be valid.
>
> Only error messages i have been able to find is:
>
> IPA server /var/log/messages show:
> rpc.gssd[1116]: Error doing stat on file '/tmp/krb5cc_48' 
>
> automount[1197]: sasl_log_func:98: GSSAPI Error: Unspecified GSS
> failure. Minor code may provide more information (Ticket expired)
>
> Anyone have a idea what this could be and how to solve it?
>
> I am really thankful for any help.
>
> Regards,
> Johan.
>

This looks very much as if when you ssh into the remote system the home
directory NFS mount fails.
Can you try to configure a local directory and see if the problem goes
away? If this helps then I would see what is going on with the NFS
client on the system.

Also I do not know how your SSH is configured. Does it actually delegate
the ticket?
AFAIU the system you SSH into needs to have a TGT to be able to mount an
NFS share on behalf of the user.
This is as far as I can go with what I know and what can be done without
actually looking at the logs on the system.

HTH


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


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
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] proper way to clear sssd cache without sss_cache?

[KodaK]

I know that at some point the sssd package (or maybe the tools
package) started including sss_cache for managing the sssd cache.  I
have some RHEL5 boxes that don't have this utility.

I've been stopping the sssd service, deleting the contents of
/var/lib/sss/db/ and then restarting and things seem to be working OK,
but I wanted to find out if there was a proper procedure?

Thanks!

-- 
The government is going to read our mail anyway, might as well make it
tough for them.  GPG Public key ID:  B6A1A7C6

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

Re: [Freeipa-users] New User - Possible to point authentication to external KDC

[Dmitri Pal]

On 02/26/2013 01:31 AM, Trey Dockendorf wrote:
>
>
> On Feb 25, 2013 1:23 AM, "Dmitri Pal"  > wrote:
> >
> > On 02/23/2013 10:33 PM, Trey Dockendorf wrote:
> > > I just begun evaluating FreeIPA, after having successfully used 389ds
> > > for a few months.  The move from 389 ds to FreeIPA is to leverage the
> > > authorization for host logins and also for simpler management.  The
> > > University I am deploying at has a campus wide KDC and for security
> > > and audit reasons I prefer to point my authentication services at that
> > > Kerberos realm rather than storing passwords.  I have successfully
> > > implemented this using the 389 ds pam pass through authentication
> > > plug-in , but have not found any documentation on how to do this same
> > > thing with FreeIPA.
> > >
> > > The complication with doing this is I do not have even a 1 way trust
> > > with the KDC.  Getting a trust (even 1-way) is very difficult if not
> > > impossible, but so far I've been able to make PAM work with that
> > > situation both using local authentication and now 389 ds, both through
> > > PAM.  Is it possible to have FreeIPA query a remote KDC while still
> > > being able to fallback to the local password store (ie external users
> > > not in campus domain).
> >
> > IPA uses the 389 DS so it might be possible to configure PAM pass
> > through but there might be implications because if users are not in IPA
> > you would not get a ticket and since you cant get a ticket you can't use
> > UI and CLI. You can still bind using LDAP though as you do with the 389.
> > So to manage IPA you would still have to have a user in IPA. However you
> > will have two KDCs and I do not know what implications there would be
> > for the clients, they might be confused.
> > Frankly you are better off with 389 now untill we make setting up trusts
> > with other IPAs or MIT KDCs simple. We did that for AD but it requires a
> > clean DNS setup. I suspect DNS setup will be an issue in any case.
> >
> > >
> > > Thanks
> > > - Trey
> > >
> > > ___
> > > Freeipa-users mailing list
> > > Freeipa-users@redhat.com 
> > > https://www.redhat.com/mailman/listinfo/freeipa-users
> >
> >
> > --
> > Thank you,
> > Dmitri Pal
> >
> > Sr. Engineering Manager for IdM portfolio
> > 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
>
> Thanks for the response!  I do plan to have all my users in freeIPA. 
> My goal is to have my freeIPA install just attempt a password
> authentication against external KDC via pam on the IPA server before
> trying the local password store.  With my current 389 setup, clients
> are unaware of our campus KDC, the authentication is handled my 389
> server and currently users in my LDAP who have campus accounts get
> their password verified via PAM and others in my LDAP use the local
> password stored in 389.
>
> The aspects of IPA aside from 389 are where my uncertainty lies.  For
> example, if I have LDAP authenticate against an external KDC via PAM,
> can the user still get a ticket from my IPA?
>
> Also getting a trust may not be possible even if freeipa makes the
> process easier.  This is a politics issue with our campus' main IT
> group and something I've worked around thus far.
>
> Is there anything in changes of the stock 389 that would prevent this
> from working in IPA?  Also is there a preferred method for enabling
> plugins in IPA?  Also how could I test this?  Would a client machine
> joined to my IPA install be the best method?
>
> Thanks
> - Trey
>
If you hit IPA with a kerberos authentication to the best of my
knowledge KDC will read the data from LDAP and use it for
authentication. It would not do PAM proxy in this case. The pam proxy
would be possible only for the LDAP binds so I am not sure whether
things would work for you.

I see that you try to augment the existing infrastructure but I am not
sure I have a clear picture in my mind of the architecture you envision.
Is there any chance that you can put together a diagram?  

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
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] IPA,NFS4,krb5p Ticket expired error

[Johan Petersson]

Hi,

I have a IPA server, NFS4 Server sharing home directories with autofs and krb5p 
as only valid authentication.
Mail Postfix/Dovecot both with startTLS and GSSAPI.
All servers and clients are Red Hat 6.3 and updated with latest kernel and 
everything else.

If i start and log in locally as user1 on a IPA Client machine everything works 
perfect including mail and home directory initially.
I then start experience errors when trying to ssh other servers as ssh 
us...@mail.example.com.
Nothing happens, no password question, nothing until i have to ctrl-c (tried 
leaving it overnight - still same).
Mail stops working, thunderbird complain about expired credentials.
If i use ssh as root to the server and then try either: su user1 or su - user1 
both get same result as ssh user1.
Sometimes a su have actually worked and i can browse to my mounted home 
directory but get permission denied when trying to access.
id works and permissions on home directory shows ok but can't access anyway.

The only thing i have found helping is to logout user1 on the client, login 
root and then ssh as user1.
In that case i get password question and it works with home directory.
If i logout root then, login user1 then mail, ssh and su works again for some 
time.

I guess the credential renewal works in that case.

Firewalls turned off, tried setenforce=0 and autofs on debug log mode but find 
nothing.

Even sshd logging on and verbose ssh shows nothing wrong.
It is like everything works but a expired ticket or something similar generate 
the error, tickets are new though and should be valid.

Only error messages i have been able to find is:

IPA server /var/log/messages show:
rpc.gssd[1116]: Error doing stat on file '/tmp/krb5cc_48'

automount[1197]: sasl_log_func:98: GSSAPI Error: Unspecified GSS failure. Minor 
code may provide more information (Ticket expired)

Anyone have a idea what this could be and how to solve it?

I am really thankful for any help.

Regards,
Johan.




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

Re: [Freeipa-users] Upgrading to 6.4 - additional information

[Erinn Looney-Triggs]

On 02/26/2013 01:05 PM, Martin Kosek wrote:
> On 02/26/2013 06:10 PM, Erinn Looney-Triggs wrote:
>> On 02/26/2013 12:08 PM, Martin Kosek wrote:
>>> On 02/26/2013 06:05 PM, Erinn Looney-Triggs wrote:
 On 02/26/2013 10:29 AM, Dmitri Pal wrote:
> On 02/21/2013 12:31 PM, Dmitri Pal wrote:
>> On 02/21/2013 11:44 AM, Erinn Looney-Triggs wrote:
>>> On 02/21/2013 09:40 AM, Rob Crittenden wrote:
 Erinn Looney-Triggs wrote:
> On 02/21/2013 09:34 AM, Rob Crittenden wrote:
>> Erinn Looney-Triggs wrote:
>>> On 02/21/2013 09:07 AM, Rob Crittenden wrote:
 add:attributeTypes: (2.16.840.1.113730.3.8.11.1 NAME
 'ipaExternalMember' DESC 'External Group Member
 Identifier' EQUALITY caseIgnoreMatch ORDERING
 caseIgnoreOrderingMatch SYNTAX
 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v3' )
 add:objectClasses: (2.16.840.1.113730.3.8.12.1 NAME
 'ipaExternalGroup' SUP top STRUCTURAL MUST ( cn ) MAY (
 ipaExternalMember $$ memberOf $$ description $$ owner)
 X-ORIGIN 'IPA v3' )
>>> Well that fails as well, though in sort of a self inflicted
>>> way:
>>>
>>> 2013-02-21T16:24:30Z INFO The ipa-ldap-updater command
>>> failed, exception: DatabaseError: Server is unwilling to
>>> perform: Minimum SSF not met. arguments:
>>> base="cn=config,cn=ldbm database,cn=plugins,cn=config",
>>> scope=0, filterstr="(objectclass=*)" 2013-02-21T16:24:30Z
>>> ERROR Unexpected error - see /var/log/ipaupgrade.log for
>>> details: DatabaseError: Server is unwilling to perform:
>>> Minimum SSF not met. arguments: base="cn=config,cn=ldbm
>>> database,cn=plugins,cn=config", scope=0,
>>> filterstr="(objectclass=*)"
>>>
>>>
>>> Now this probably comes about because I set: nsslapd-minssf:
>>> 56 For security.
>>>
>>> I can cange that back to the default and probably move past
>>> this, but is that a known issue? Is there another way
>>> around?
>> As root try the --ldapi flag:
>>
>> # ipa-ldap-updater --ldapi /path/to/scheme.update
>>
>> rob
>>
> ERROR: LDAPUpdate: syntax error: dn is not defined in the
> update, data source=schema.update
>
> -Erinn
>
 Sorry, add this to the top of your update file:

 dn: cn=schema

 rob
>>> No worries! Thanks for the help, after a restart of IPA the web UI
>>> is working again. I reckon this is something that needs to be fixed,
>>> does opening a support case and pointing them to that bug help you
>>> folks out with this in any way?
>>
>> This is a know defect. We just did not realize it would have such a
>> bad impact on upgrade. Sorry, the errata is on the way.
>>
>> I would recommend everyone to not upgrade to 6.4 until the errata is
>> shipped. We will notify you as soon as it goes out.
>>
>> Sorry again.
>>
>
> We did some research of this issue: 1) The upgrade works fine from 6.3
> to 6.4 and the issue does not exhibit itself 2) We have been able to
> reproduce it with the direct upgrade from 6.2 to 6.4 3) Since the
> expected upgrade part is 6.2 -> 6.3 -> 6.4 the question comes up
> whether
> this fix is actually that urgent. 4) In the presence of the simple
> workaround we feel that it is not that important to include this fix
> into the errata that we are working on.
>
> Please let us know if you think that there is a problem with the plan
> above.
>
>

 Well all I can tell you on this, is that mine was an upgrade from
 6.3 to
 6.4, so there is a case where it will fail going from 6.3 to 6.4,
 but how
 applicable it is I can't say.
>>>
>>> Hi Erinn,
>>>
>>> Is 6.3 the original RHEL version where IPA server was installed? Or
>>> was IPA
>>> installed on RHEL-6.2 and then you upgraded RHEL to 6.3?
>>>
>>> Thank you,
>>> Martin
>>>
>>
>> These systems have gone through all the point releases from 6 on up I
>> believe.
>>
>> -Erinn
>>
> 
> Ok, then this use case is also covered by the upcoming 6.4 fix. I just
> wanted to check that.
> 
> Thanks,
> Martin

Sounds good, and thanks for fixing that.

-Erinn



signature.asc
Description: OpenPGP digital signature
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Upgrading to 6.4 - additional information

[Martin Kosek]

On 02/26/2013 06:10 PM, Erinn Looney-Triggs wrote:

On 02/26/2013 12:08 PM, Martin Kosek wrote:

On 02/26/2013 06:05 PM, Erinn Looney-Triggs wrote:

On 02/26/2013 10:29 AM, Dmitri Pal wrote:

On 02/21/2013 12:31 PM, Dmitri Pal wrote:

On 02/21/2013 11:44 AM, Erinn Looney-Triggs wrote:

On 02/21/2013 09:40 AM, Rob Crittenden wrote:

Erinn Looney-Triggs wrote:

On 02/21/2013 09:34 AM, Rob Crittenden wrote:

Erinn Looney-Triggs wrote:

On 02/21/2013 09:07 AM, Rob Crittenden wrote:

add:attributeTypes: (2.16.840.1.113730.3.8.11.1 NAME
'ipaExternalMember' DESC 'External Group Member
Identifier' EQUALITY caseIgnoreMatch ORDERING
caseIgnoreOrderingMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v3' )
add:objectClasses: (2.16.840.1.113730.3.8.12.1 NAME
'ipaExternalGroup' SUP top STRUCTURAL MUST ( cn ) MAY (
ipaExternalMember $$ memberOf $$ description $$ owner)
X-ORIGIN 'IPA v3' )

Well that fails as well, though in sort of a self inflicted
way:

2013-02-21T16:24:30Z INFO The ipa-ldap-updater command
failed, exception: DatabaseError: Server is unwilling to
perform: Minimum SSF not met. arguments:
base="cn=config,cn=ldbm database,cn=plugins,cn=config",
scope=0, filterstr="(objectclass=*)" 2013-02-21T16:24:30Z
ERROR Unexpected error - see /var/log/ipaupgrade.log for
details: DatabaseError: Server is unwilling to perform:
Minimum SSF not met. arguments: base="cn=config,cn=ldbm
database,cn=plugins,cn=config", scope=0,
filterstr="(objectclass=*)"


Now this probably comes about because I set: nsslapd-minssf:
56 For security.

I can cange that back to the default and probably move past
this, but is that a known issue? Is there another way
around?

As root try the --ldapi flag:

# ipa-ldap-updater --ldapi /path/to/scheme.update

rob


ERROR: LDAPUpdate: syntax error: dn is not defined in the
update, data source=schema.update

-Erinn


Sorry, add this to the top of your update file:

dn: cn=schema

rob

No worries! Thanks for the help, after a restart of IPA the web UI
is working again. I reckon this is something that needs to be fixed,
does opening a support case and pointing them to that bug help you
folks out with this in any way?


This is a know defect. We just did not realize it would have such a
bad impact on upgrade. Sorry, the errata is on the way.

I would recommend everyone to not upgrade to 6.4 until the errata is
shipped. We will notify you as soon as it goes out.

Sorry again.



We did some research of this issue: 1) The upgrade works fine from 6.3
to 6.4 and the issue does not exhibit itself 2) We have been able to
reproduce it with the direct upgrade from 6.2 to 6.4 3) Since the
expected upgrade part is 6.2 -> 6.3 -> 6.4 the question comes up whether
this fix is actually that urgent. 4) In the presence of the simple
workaround we feel that it is not that important to include this fix
into the errata that we are working on.

Please let us know if you think that there is a problem with the plan
above.




Well all I can tell you on this, is that mine was an upgrade from 6.3 to
6.4, so there is a case where it will fail going from 6.3 to 6.4, but how
applicable it is I can't say.


Hi Erinn,

Is 6.3 the original RHEL version where IPA server was installed? Or was IPA
installed on RHEL-6.2 and then you upgraded RHEL to 6.3?

Thank you,
Martin



These systems have gone through all the point releases from 6 on up I
believe.

-Erinn



Ok, then this use case is also covered by the upcoming 6.4 fix. I just wanted 
to check that.


Thanks,
Martin

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

Re: [Freeipa-users] Upgrading to 6.4 - additional information

[Erinn Looney-Triggs]

On 02/26/2013 12:08 PM, Martin Kosek wrote:
> On 02/26/2013 06:05 PM, Erinn Looney-Triggs wrote:
>> On 02/26/2013 10:29 AM, Dmitri Pal wrote:
>>> On 02/21/2013 12:31 PM, Dmitri Pal wrote:
 On 02/21/2013 11:44 AM, Erinn Looney-Triggs wrote:
> On 02/21/2013 09:40 AM, Rob Crittenden wrote:
>> Erinn Looney-Triggs wrote:
>>> On 02/21/2013 09:34 AM, Rob Crittenden wrote:
 Erinn Looney-Triggs wrote:
> On 02/21/2013 09:07 AM, Rob Crittenden wrote:
>> add:attributeTypes: (2.16.840.1.113730.3.8.11.1 NAME 
>> 'ipaExternalMember' DESC 'External Group Member
>> Identifier' EQUALITY caseIgnoreMatch ORDERING
>> caseIgnoreOrderingMatch SYNTAX
>> 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v3' ) 
>> add:objectClasses: (2.16.840.1.113730.3.8.12.1 NAME
>> 'ipaExternalGroup' SUP top STRUCTURAL MUST ( cn ) MAY (
>> ipaExternalMember $$ memberOf $$ description $$ owner)
>> X-ORIGIN 'IPA v3' )
> Well that fails as well, though in sort of a self inflicted
> way:
>
> 2013-02-21T16:24:30Z INFO The ipa-ldap-updater command
> failed, exception: DatabaseError: Server is unwilling to
> perform: Minimum SSF not met. arguments:
> base="cn=config,cn=ldbm database,cn=plugins,cn=config",
> scope=0, filterstr="(objectclass=*)" 2013-02-21T16:24:30Z
> ERROR Unexpected error - see /var/log/ipaupgrade.log for
> details: DatabaseError: Server is unwilling to perform:
> Minimum SSF not met. arguments: base="cn=config,cn=ldbm
> database,cn=plugins,cn=config", scope=0,
> filterstr="(objectclass=*)"
>
>
> Now this probably comes about because I set: nsslapd-minssf:
> 56 For security.
>
> I can cange that back to the default and probably move past
> this, but is that a known issue? Is there another way
> around?
 As root try the --ldapi flag:

 # ipa-ldap-updater --ldapi /path/to/scheme.update

 rob

>>> ERROR: LDAPUpdate: syntax error: dn is not defined in the
>>> update, data source=schema.update
>>>
>>> -Erinn
>>>
>> Sorry, add this to the top of your update file:
>>
>> dn: cn=schema
>>
>> rob
> No worries! Thanks for the help, after a restart of IPA the web UI
> is working again. I reckon this is something that needs to be fixed,
> does opening a support case and pointing them to that bug help you
> folks out with this in any way?

 This is a know defect. We just did not realize it would have such a 
 bad impact on upgrade. Sorry, the errata is on the way.

 I would recommend everyone to not upgrade to 6.4 until the errata is 
 shipped. We will notify you as soon as it goes out.

 Sorry again.

>>>
>>> We did some research of this issue: 1) The upgrade works fine from 6.3
>>> to 6.4 and the issue does not exhibit itself 2) We have been able to
>>> reproduce it with the direct upgrade from 6.2 to 6.4 3) Since the
>>> expected upgrade part is 6.2 -> 6.3 -> 6.4 the question comes up whether
>>> this fix is actually that urgent. 4) In the presence of the simple
>>> workaround we feel that it is not that important to include this fix
>>> into the errata that we are working on.
>>>
>>> Please let us know if you think that there is a problem with the plan
>>> above.
>>>
>>>
>>
>> Well all I can tell you on this, is that mine was an upgrade from 6.3 to 
>> 6.4, so there is a case where it will fail going from 6.3 to 6.4, but how
>> applicable it is I can't say.
> 
> Hi Erinn,
> 
> Is 6.3 the original RHEL version where IPA server was installed? Or was IPA
> installed on RHEL-6.2 and then you upgraded RHEL to 6.3?
> 
> Thank you,
> Martin
> 

These systems have gone through all the point releases from 6 on up I
believe.

-Erinn



signature.asc
Description: OpenPGP digital signature
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Upgrading to 6.4 - additional information

[Martin Kosek]

On 02/26/2013 06:05 PM, Erinn Looney-Triggs wrote:
> On 02/26/2013 10:29 AM, Dmitri Pal wrote:
>> On 02/21/2013 12:31 PM, Dmitri Pal wrote:
>>> On 02/21/2013 11:44 AM, Erinn Looney-Triggs wrote:
 On 02/21/2013 09:40 AM, Rob Crittenden wrote:
> Erinn Looney-Triggs wrote:
>> On 02/21/2013 09:34 AM, Rob Crittenden wrote:
>>> Erinn Looney-Triggs wrote:
 On 02/21/2013 09:07 AM, Rob Crittenden wrote:
> add:attributeTypes: (2.16.840.1.113730.3.8.11.1 NAME 
> 'ipaExternalMember' DESC 'External Group Member
> Identifier' EQUALITY caseIgnoreMatch ORDERING
> caseIgnoreOrderingMatch SYNTAX
> 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v3' ) 
> add:objectClasses: (2.16.840.1.113730.3.8.12.1 NAME
> 'ipaExternalGroup' SUP top STRUCTURAL MUST ( cn ) MAY (
> ipaExternalMember $$ memberOf $$ description $$ owner)
> X-ORIGIN 'IPA v3' )
 Well that fails as well, though in sort of a self inflicted
 way:
 
 2013-02-21T16:24:30Z INFO The ipa-ldap-updater command
 failed, exception: DatabaseError: Server is unwilling to
 perform: Minimum SSF not met. arguments:
 base="cn=config,cn=ldbm database,cn=plugins,cn=config",
 scope=0, filterstr="(objectclass=*)" 2013-02-21T16:24:30Z
 ERROR Unexpected error - see /var/log/ipaupgrade.log for
 details: DatabaseError: Server is unwilling to perform:
 Minimum SSF not met. arguments: base="cn=config,cn=ldbm
 database,cn=plugins,cn=config", scope=0,
 filterstr="(objectclass=*)"
 
 
 Now this probably comes about because I set: nsslapd-minssf:
 56 For security.
 
 I can cange that back to the default and probably move past
 this, but is that a known issue? Is there another way
 around?
>>> As root try the --ldapi flag:
>>> 
>>> # ipa-ldap-updater --ldapi /path/to/scheme.update
>>> 
>>> rob
>>> 
>> ERROR: LDAPUpdate: syntax error: dn is not defined in the
>> update, data source=schema.update
>> 
>> -Erinn
>> 
> Sorry, add this to the top of your update file:
> 
> dn: cn=schema
> 
> rob
 No worries! Thanks for the help, after a restart of IPA the web UI
 is working again. I reckon this is something that needs to be fixed,
 does opening a support case and pointing them to that bug help you
 folks out with this in any way?
>>> 
>>> This is a know defect. We just did not realize it would have such a 
>>> bad impact on upgrade. Sorry, the errata is on the way.
>>> 
>>> I would recommend everyone to not upgrade to 6.4 until the errata is 
>>> shipped. We will notify you as soon as it goes out.
>>> 
>>> Sorry again.
>>> 
>> 
>> We did some research of this issue: 1) The upgrade works fine from 6.3
>> to 6.4 and the issue does not exhibit itself 2) We have been able to
>> reproduce it with the direct upgrade from 6.2 to 6.4 3) Since the
>> expected upgrade part is 6.2 -> 6.3 -> 6.4 the question comes up whether
>> this fix is actually that urgent. 4) In the presence of the simple
>> workaround we feel that it is not that important to include this fix
>> into the errata that we are working on.
>> 
>> Please let us know if you think that there is a problem with the plan
>> above.
>> 
>> 
> 
> Well all I can tell you on this, is that mine was an upgrade from 6.3 to 
> 6.4, so there is a case where it will fail going from 6.3 to 6.4, but how
> applicable it is I can't say.

Hi Erinn,

Is 6.3 the original RHEL version where IPA server was installed? Or was IPA
installed on RHEL-6.2 and then you upgraded RHEL to 6.3?

Thank you,
Martin

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

Re: [Freeipa-users] Upgrading to 6.4 - additional information

[Erinn Looney-Triggs]

On 02/26/2013 10:29 AM, Dmitri Pal wrote:
> On 02/21/2013 12:31 PM, Dmitri Pal wrote:
>> On 02/21/2013 11:44 AM, Erinn Looney-Triggs wrote:
>>> On 02/21/2013 09:40 AM, Rob Crittenden wrote:
 Erinn Looney-Triggs wrote:
> On 02/21/2013 09:34 AM, Rob Crittenden wrote:
>> Erinn Looney-Triggs wrote:
>>> On 02/21/2013 09:07 AM, Rob Crittenden wrote:
 add:attributeTypes: (2.16.840.1.113730.3.8.11.1 NAME
 'ipaExternalMember'
 DESC 'External Group Member Identifier' EQUALITY caseIgnoreMatch
 ORDERING caseIgnoreOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
 X-ORIGIN 'IPA v3' )
 add:objectClasses: (2.16.840.1.113730.3.8.12.1 NAME 'ipaExternalGroup'
 SUP top STRUCTURAL MUST ( cn ) MAY ( ipaExternalMember $$ memberOf $$
 description $$ owner) X-ORIGIN 'IPA v3' )
>>> Well that fails as well, though in sort of a self inflicted way:
>>>
>>> 2013-02-21T16:24:30Z INFO The ipa-ldap-updater command failed,
>>> exception: DatabaseError: Server is unwilling to perform: Minimum SSF
>>> not met. arguments: base="cn=config,cn=ldbm
>>> database,cn=plugins,cn=config", scope=0, filterstr="(objectclass=*)"
>>> 2013-02-21T16:24:30Z ERROR Unexpected error - see
>>> /var/log/ipaupgrade.log for details:
>>> DatabaseError: Server is unwilling to perform: Minimum SSF not met.
>>> arguments: base="cn=config,cn=ldbm database,cn=plugins,cn=config",
>>> scope=0, filterstr="(objectclass=*)"
>>>
>>>
>>> Now this probably comes about because I set:
>>> nsslapd-minssf: 56
>>> For security.
>>>
>>> I can cange that back to the default and probably move past this,
>>> but is
>>> that a known issue? Is there another way around?
>> As root try the --ldapi flag:
>>
>> # ipa-ldap-updater --ldapi /path/to/scheme.update
>>
>> rob
>>
> ERROR: LDAPUpdate: syntax error:
>dn is not defined in the update, data source=schema.update
>
> -Erinn
>
 Sorry, add this to the top of your update file:

 dn: cn=schema

 rob
>>> No worries! Thanks for the help, after a restart of IPA the web UI is
>>> working again. I reckon this is something that needs to be fixed, does
>>> opening a support case and pointing them to that bug help you folks out
>>> with this in any way?
>>
>> This is a know defect. We just did not realize it would have such a
>> bad impact on upgrade.
>> Sorry, the errata is on the way.
>>
>> I would recommend everyone to not upgrade to 6.4 until the errata is
>> shipped.
>> We will notify you as soon as it goes out.
>>
>> Sorry again.
>>
> 
> We did some research of this issue:
> 1) The upgrade works fine from 6.3 to 6.4 and the issue does not exhibit
> itself
> 2) We have been able to reproduce it with the direct upgrade from 6.2 to 6.4
> 3) Since the expected upgrade part is 6.2 -> 6.3 -> 6.4 the question
> comes up whether this fix is actually that urgent.
> 4) In the presence of the simple workaround we feel that it is not that
> important to include this fix into the errata that we are working on.
> 
> Please let us know if you think that there is a problem with the plan above.
> 
> 

Well all I can tell you on this, is that mine was an upgrade from 6.3 to
6.4, so there is a case where it will fail going from 6.3 to 6.4, but
how applicable it is I can't say.

Otherwise, sure, sounds great to me.

-Erin




signature.asc
Description: OpenPGP digital signature
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Cannot obtain CA Certificate

[John Moyer]

Sorry for the late response, so I tried this, and it changed the error to the 
following: 

Synchronizing time with KDC...

Joining realm failed: HTTP response code is 401, not 200
Installation failed. Rolling back changes.



Looking at debug this is what I see: 

< HTTP/1.1 401 Authorization Required
< Date: Tue, 26 Feb 2013 16:54:21 GMT
< Server: Apache/2.2.15 (CentOS)
* gss_init_sec_context() failed: : Server krbtgt/c...@example.com not found in 
Kerberos database< WWW-Authenticate: Negotiate
< Last-Modified: Wed, 23 Jan 2013 22:16:50 GMT
< ETag: "4627-740-4d3fc0cfd7880"
< Accept-Ranges: bytes
< Content-Length: 1856
< Connection: close
< Content-Type: text/html; charset=UTF-8





Thanks, 
_
John Moyer




On Feb 19, 2013, at 6:35 AM, Jan-Frode Myklebust  wrote:

>> ipa : ERRORCannot obtain CA certificate
>> 'ldap://ipa1.example.com' doesn't have a certificate.
>> Installation failed. Rolling back changes.
>> IPA client is not configured on this system.
> 
> FYI, I have this same issue when enrolling RHEL5 clients. Have been
> doing this as a workaround:
> 
>   wget -O /etc/ipa/ca.crt http://ipa1.example.com/ipa/config/ca.crt
>   ipa-client-install --no-ntp --mkhomedir --ca-cert-file=/etc/ipa/ca.crt
> 
> 
> 
>  -jf


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

Re: [Freeipa-users] Upgrading to 6.4 - additional information

[Martin Kosek]

On 02/26/2013 04:29 PM, Dmitri Pal wrote:
> On 02/21/2013 12:31 PM, Dmitri Pal wrote:
>> On 02/21/2013 11:44 AM, Erinn Looney-Triggs wrote:
>>> On 02/21/2013 09:40 AM, Rob Crittenden wrote:
 Erinn Looney-Triggs wrote:
> On 02/21/2013 09:34 AM, Rob Crittenden wrote:
>> Erinn Looney-Triggs wrote:
>>> On 02/21/2013 09:07 AM, Rob Crittenden wrote:
 add:attributeTypes: (2.16.840.1.113730.3.8.11.1 NAME
 'ipaExternalMember'
 DESC 'External Group Member Identifier' EQUALITY caseIgnoreMatch
 ORDERING caseIgnoreOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
 X-ORIGIN 'IPA v3' )
 add:objectClasses: (2.16.840.1.113730.3.8.12.1 NAME 'ipaExternalGroup'
 SUP top STRUCTURAL MUST ( cn ) MAY ( ipaExternalMember $$ memberOf $$
 description $$ owner) X-ORIGIN 'IPA v3' )
>>> Well that fails as well, though in sort of a self inflicted way:
>>>
>>> 2013-02-21T16:24:30Z INFO The ipa-ldap-updater command failed,
>>> exception: DatabaseError: Server is unwilling to perform: Minimum SSF
>>> not met. arguments: base="cn=config,cn=ldbm
>>> database,cn=plugins,cn=config", scope=0, filterstr="(objectclass=*)"
>>> 2013-02-21T16:24:30Z ERROR Unexpected error - see
>>> /var/log/ipaupgrade.log for details:
>>> DatabaseError: Server is unwilling to perform: Minimum SSF not met.
>>> arguments: base="cn=config,cn=ldbm database,cn=plugins,cn=config",
>>> scope=0, filterstr="(objectclass=*)"
>>>
>>>
>>> Now this probably comes about because I set:
>>> nsslapd-minssf: 56
>>> For security.
>>>
>>> I can cange that back to the default and probably move past this,
>>> but is
>>> that a known issue? Is there another way around?
>> As root try the --ldapi flag:
>>
>> # ipa-ldap-updater --ldapi /path/to/scheme.update
>>
>> rob
>>
> ERROR: LDAPUpdate: syntax error:
>dn is not defined in the update, data source=schema.update
>
> -Erinn
>
 Sorry, add this to the top of your update file:

 dn: cn=schema

 rob
>>> No worries! Thanks for the help, after a restart of IPA the web UI is
>>> working again. I reckon this is something that needs to be fixed, does
>>> opening a support case and pointing them to that bug help you folks out
>>> with this in any way?
>>
>> This is a know defect. We just did not realize it would have such a bad
>> impact on upgrade.
>> Sorry, the errata is on the way.
>>
>> I would recommend everyone to not upgrade to 6.4 until the errata is shipped.
>> We will notify you as soon as it goes out.
>>
>> Sorry again.
>>
> 

I would like to clarify the impact, we have found out it is broader than
currently stated:

> We did some research of this issue:
> 1) The upgrade works fine from 6.3 to 6.4 and the issue does not exhibit 
> itself
> 2) We have been able to reproduce it with the direct upgrade from 6.2 to 6.4
> 3) Since the expected upgrade part is 6.2 -> 6.3 -> 6.4 the question comes up
> whether this fix is actually that urgent.

This issue also affects both upgrade paths (6.2 -> 6.4 and 6.2 -> 6.3 -> 6.4).
This makes the fix urgent and it should be fixed in 6.4 too.

Martin

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

Re: [Freeipa-users] Upgrading to 6.4 - additional information

[Dmitri Pal]

On 02/21/2013 12:31 PM, Dmitri Pal wrote:
> On 02/21/2013 11:44 AM, Erinn Looney-Triggs wrote:
>> On 02/21/2013 09:40 AM, Rob Crittenden wrote:
>>> Erinn Looney-Triggs wrote:
 On 02/21/2013 09:34 AM, Rob Crittenden wrote:
> Erinn Looney-Triggs wrote:
>> On 02/21/2013 09:07 AM, Rob Crittenden wrote:
>>> add:attributeTypes: (2.16.840.1.113730.3.8.11.1 NAME
>>> 'ipaExternalMember'
>>> DESC 'External Group Member Identifier' EQUALITY caseIgnoreMatch
>>> ORDERING caseIgnoreOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
>>> X-ORIGIN 'IPA v3' )
>>> add:objectClasses: (2.16.840.1.113730.3.8.12.1 NAME 'ipaExternalGroup'
>>> SUP top STRUCTURAL MUST ( cn ) MAY ( ipaExternalMember $$ memberOf $$
>>> description $$ owner) X-ORIGIN 'IPA v3' )
>> Well that fails as well, though in sort of a self inflicted way:
>>
>> 2013-02-21T16:24:30Z INFO The ipa-ldap-updater command failed,
>> exception: DatabaseError: Server is unwilling to perform: Minimum SSF
>> not met. arguments: base="cn=config,cn=ldbm
>> database,cn=plugins,cn=config", scope=0, filterstr="(objectclass=*)"
>> 2013-02-21T16:24:30Z ERROR Unexpected error - see
>> /var/log/ipaupgrade.log for details:
>> DatabaseError: Server is unwilling to perform: Minimum SSF not met.
>> arguments: base="cn=config,cn=ldbm database,cn=plugins,cn=config",
>> scope=0, filterstr="(objectclass=*)"
>>
>>
>> Now this probably comes about because I set:
>> nsslapd-minssf: 56
>> For security.
>>
>> I can cange that back to the default and probably move past this,
>> but is
>> that a known issue? Is there another way around?
> As root try the --ldapi flag:
>
> # ipa-ldap-updater --ldapi /path/to/scheme.update
>
> rob
>
 ERROR: LDAPUpdate: syntax error:
dn is not defined in the update, data source=schema.update

 -Erinn

>>> Sorry, add this to the top of your update file:
>>>
>>> dn: cn=schema
>>>
>>> rob
>> No worries! Thanks for the help, after a restart of IPA the web UI is
>> working again. I reckon this is something that needs to be fixed, does
>> opening a support case and pointing them to that bug help you folks out
>> with this in any way?
>
> This is a know defect. We just did not realize it would have such a
> bad impact on upgrade.
> Sorry, the errata is on the way.
>
> I would recommend everyone to not upgrade to 6.4 until the errata is
> shipped.
> We will notify you as soon as it goes out.
>
> Sorry again.
>

We did some research of this issue:
1) The upgrade works fine from 6.3 to 6.4 and the issue does not exhibit
itself
2) We have been able to reproduce it with the direct upgrade from 6.2 to 6.4
3) Since the expected upgrade part is 6.2 -> 6.3 -> 6.4 the question
comes up whether this fix is actually that urgent.
4) In the presence of the simple workaround we feel that it is not that
important to include this fix into the errata that we are working on.

Please let us know if you think that there is a problem with the plan above.


>> -Erinn
>>
>>
>>
>> ___
>> Freeipa-users mailing list
>> Freeipa-users@redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>
>
> -- 
> Thank you,
> Dmitri Pal
>
> Sr. Engineering Manager for IdM portfolio
> 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


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
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] nsslapd-changelogmaxage

[Rich Megginson]

On 02/26/2013 04:00 AM, Kriss Von Prosst wrote:
ok, but setting nsslapd-changelogmaxage parameter doesnt automatically 
shrink changelog. The file size dosent change. Other idea how to trim 
changelog file?


I don't know.  Looks like you have found a bug.




2013/2/25 Rich Megginson >


On 02/25/2013 11:33 AM, Kriss Von Prosst wrote:

Hi,

I have multimaster replication enviroment, IPA v2.2 on Fedora 17.
On each replica, folder /var/lib/dirsrv/slapd-cosp/cldb/ has big
size (~7GB). This is half of all available space  for '/'. I
found that changelog file can be trim using
'nsslapd-changelogmaxage' parameter. By default, this parameter
is not set in dse.ldif (is this correct?). My questions are:

a) where should I put 'nsslapd-changelogmaxage' parameter, into
tree: cn=Retro Changelog Plugin, cn=config or
cn=changelog5,cn=config.

Not Retro Changelog


https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Configuring-Replication-cmd.html#Configuring-Replication-Suppliers-cmd





b) what are the consequences when I set this parameter to
nsslapd-changelogmaxage: 10d?
c) Is any other possibility to limit increase of this file?

There is also the nsslapd-changelogmaxentries parameter

https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Core_Server_Configuration_Reference.html#cnchangelog5


Kriss


___
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

Re: [Freeipa-users] RHEL 6.4 , IPA 3.0 and bind-chroot

[Petr Spacek]

On 23.2.2013 23:01, Dale Macartney wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On 02/23/2013 09:47 PM, Dmitri Pal wrote:

On 02/23/2013 12:48 PM, Dale  Macartney wrote:

 > >
 >> Hi all
 >>
 >> I've just performed a clean IPA installation and noticed that if you're
 >> using integrated DNS, you are still unable to use bind in a chrooted
 >> environment with a default IPA install.
 >>
 >> Basically if its a chrooted environment, named will fail to start.
 >>
 >> To replicate what I've done, do the following.
 >>
 >> # yum install ipa-server bind bind-chroot bind-dyndb-ldap -y
 >> # ipa-server-install --setup-dns (do your usual thing here)
 >>
 >> - From what I've been testing, there needs to be quite a few libraries
 >> located in the chroot environment.
 >>
 >> I've done the below to get a little further (I should probably use
 >> symbolic links, but for now copying the files is a start).
 >>
 >> mkdir /var/named/chroot/lib64/
 >> cp /lib64/libldap-2.4.so.2 /var/named/chroot/lib64/
 >> cp /lib64/liblber-2.4.so.2 /var/named/chroot/lib64/
 >> cp /lib64/libplds4.so /var/named/chroot/lib64/
 >> cp /lib64/libplc4.so /var/named/chroot/lib64/
 >> cp /lib64/libnspr4.so /var/named/chroot/lib64/
 >> cp /lib64/libcrypt.so.1 /var/named/chroot/lib64/
 >> cp /lib64/libfreebl3.so /var/named/chroot/lib64/
 >>
 >> mkdir /var/named/chroot/usr/lib64/
 >> cp /usr/lib64/libssl3.so /var/named/chroot/usr/lib64/
 >> cp /usr/lib64/libsmime3.so /var/named/chroot/usr/lib64/
 >> cp /usr/lib64/libnss3.so /var/named/chroot/usr/lib64/
 >> cp /usr/lib64/libnssutil3.so /var/named/chroot/usr/lib64/
 >> cp /usr/lib64/libsasl2.so.2 /var/named/chroot/usr/lib64/
 >>
 >>
 >>
 >> Now when I restart named, I get the below error in /var/log/messages.
 >>
 >> Does anyone have any ideas of the best way to get around this error?
 >>
 >> Feb 23 17:35:29 ds01 named[2425]: Failed to parse the principal name
 >> DNS/ds01.example.com (Configuration file does not specify default realm)
 >
 > It should be
 > DNS/ds01.example.com@YOURREALMNAME.SOMETHING
oh of course.. what a face palm moment.

Where does the default ipa installation put the DNS keytab file? I did notice
an /etc/named.keytab was present, but placing that in /var/named/chroot/etc
didn't seem to improve matters.


I wrote short how-to:
http://freeipa.org/page/Howto/FreeIPA_with_integrated_BIND_inside_chroot

In my RHEL 6.4 test environment it worked, but it is a bit "hackish". Any 
improvements are welcome!



 > I do not know the exact reason but it might be that bind ldap driver can't
locate its kerberos configuration.
 > I hope it will give you a hint and unblock you before the real masters of
DNS chime in. i
I know this has been a rather long lasting rfe/bug/how ever you want to label 
it.
https://fedorahosted.org/freeipa/ticket/126

If I make any progress I'll let the team know.


--
Petr^2 Spacek

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

Re: [Freeipa-users] FreeIPA for AMM users management

[Petr Spacek]

On 26.2.2013 11:49, Артур Файзуллин wrote:

And what?
Is there any result? I try same thing with my AMM and IPA


Unfortunately, we don't have sufficient information to give you any advice.

Please, try to provide output from a sniffer as I asked in last reply. Then we 
will try to help you. (You can send the data to me privately, if you want.)


Petr^2 Spacek


В Пн., 05/11/2012 в 09:32 +0100, Petr Spacek пишет:

On 11/03/2012 01:12 PM, Pavel Zhukov wrote:

Can you do NS lookup of the IPA server from the AMM box?

yes

Can you do kinit from the AMM box against IPA?
Can you do ldapsearch from the AMM box against IPA?

no, AMM has restricted shell and web GUI.


Hmm, that is unfortunate. Can you run tcpdump (or sniffer provided on AMM) on
the link between AMM and IPA server? Because there are no records in access
log I will bet on some name resolution or firewall problem.

Do AMM get right DNS responses (i.e. name and IP address of the IPA server)?

Do AMM established TCP connection with the IPA server?

--
Petr^2 Spacek


Do you see anything in the logs from such activity?


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

Re: [Freeipa-users] nsslapd-changelogmaxage

[Kriss Von Prosst]

ok, but setting nsslapd-changelogmaxage parameter doesnt automatically
shrink changelog. The file size dosent change. Other idea how to trim
changelog file?


2013/2/25 Rich Megginson 

>  On 02/25/2013 11:33 AM, Kriss Von Prosst wrote:
>
>  Hi,
>
>  I have multimaster replication enviroment, IPA v2.2 on Fedora 17. On
> each replica, folder /var/lib/dirsrv/slapd-cosp/cldb/ has big size (~7GB).
> This is half of all available space  for '/'. I found that changelog file
> can be trim using 'nsslapd-changelogmaxage' parameter. By default, this
> parameter is not set in dse.ldif (is this correct?). My questions are:
>
>  a) where should I put 'nsslapd-changelogmaxage' parameter, into tree:
> cn=Retro Changelog Plugin, cn=config or cn=changelog5,cn=config.
>
> Not Retro Changelog
>
>
> https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Configuring-Replication-cmd.html#Configuring-Replication-Suppliers-cmd
>
>
>
>  b) what are the consequences when I set this parameter to
> nsslapd-changelogmaxage: 10d?
> c) Is any other possibility to limit increase of this file?
>
> There is also the nsslapd-changelogmaxentries parameter
>
> https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Core_Server_Configuration_Reference.html#cnchangelog5
>
>
>  Kriss
>
>
> ___
> Freeipa-users mailing 
> listFreeipa-users@redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users
>
>
>
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] FreeIPA for AMM users management

[Артур Файзуллин]

And what?
Is there any result? I try same thing with my AMM and IPA

В Пн., 05/11/2012 в 09:32 +0100, Petr Spacek пишет:
> On 11/03/2012 01:12 PM, Pavel Zhukov wrote:
> >> Can you do NS lookup of the IPA server from the AMM box?
> > yes
> >> Can you do kinit from the AMM box against IPA?
> >> Can you do ldapsearch from the AMM box against IPA?
> > no, AMM has restricted shell and web GUI.
> 
> Hmm, that is unfortunate. Can you run tcpdump (or sniffer provided on AMM) on 
> the link between AMM and IPA server? Because there are no records in access 
> log I will bet on some name resolution or firewall problem.
> 
> Do AMM get right DNS responses (i.e. name and IP address of the IPA server)?
> 
> Do AMM established TCP connection with the IPA server?
> 
> --
> Petr^2 Spacek
> 
> >> Do you see anything in the logs from such activity?
> 
> ___
> 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

Re: [Freeipa-users] ipa-replica-install command failed

[Martin Kosek]

Hm, all these are usually benign, when we are just setting up a replication.
Can you please send me the whole ipareplica-install.log and dirsrv's errors log
so I can see these errors in a broader context? You can do it in private
message if you want.

Btw I assume that you are running on the current Fedora 18 389-ds-base version
(389-ds-base-0:1.3.0.2-1.fc18)

Thanks,
Martin

On 02/26/2013 09:36 AM, Umarzuki Mochlis wrote:
> 2013/2/26 Martin Kosek :
> 
> Hi Martin,
> 
> I found below on errors file
> 
> [26/Feb/2013:00:16:14 +0800] - 389-Directory/1.3.0.3 B2013.045.10 starting up
> [26/Feb/2013:00:16:14 +0800] - Db home directory is not set. Possibly
> nsslapd-directory (optionally nsslapd-db-home-directory) is missin
> g in the config file.
> .
> .
> [26/Feb/2013:00:16:32 +0800] - 389-Directory/1.3.0.3 B2013.045.10 starting up
> [26/Feb/2013:00:16:32 +0800] ipaenrollment_start - [file
> ipa_enrollment.c, line 390]: Failed to get default realm?!
> .
> .
> [26/Feb/2013:00:16:33 +0800] NSMMReplicationPlugin -
> agmt="cn=meToipa.domain.com" (ipa:389): Replica has a different
> generation ID than the local data.
> [26/Feb/2013:00:16:33 +0800] NSMMReplicationPlugin -
> multimaster_be_state_change: replica dc=domain,dc=com is going
> offline; disabling replication
> 
>> Hello Umarzuki,
>>
>> I am not aware of this bug. Can you please check 389-ds-base logs on the
>> replica and see if there is any bug? The log should be in
>> /var/log/dirsrv/slapd-YOUR-IPA-INSTANCE/errors.
>>
>> Martin
> 
> 
> 

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

Re: [Freeipa-users] ipa-replica-install command failed

[Umarzuki Mochlis]

2013/2/26 Martin Kosek :

Hi Martin,

I found below on errors file

[26/Feb/2013:00:16:14 +0800] - 389-Directory/1.3.0.3 B2013.045.10 starting up
[26/Feb/2013:00:16:14 +0800] - Db home directory is not set. Possibly
nsslapd-directory (optionally nsslapd-db-home-directory) is missin
g in the config file.
.
.
[26/Feb/2013:00:16:32 +0800] - 389-Directory/1.3.0.3 B2013.045.10 starting up
[26/Feb/2013:00:16:32 +0800] ipaenrollment_start - [file
ipa_enrollment.c, line 390]: Failed to get default realm?!
.
.
[26/Feb/2013:00:16:33 +0800] NSMMReplicationPlugin -
agmt="cn=meToipa.domain.com" (ipa:389): Replica has a different
generation ID than the local data.
[26/Feb/2013:00:16:33 +0800] NSMMReplicationPlugin -
multimaster_be_state_change: replica dc=domain,dc=com is going
offline; disabling replication

> Hello Umarzuki,
>
> I am not aware of this bug. Can you please check 389-ds-base logs on the
> replica and see if there is any bug? The log should be in
> /var/log/dirsrv/slapd-YOUR-IPA-INSTANCE/errors.
>
> Martin



-- 
Regards,

Umarzuki Mochlis
http://debmal.my

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

Re: [Freeipa-users] Password expiry when account provisioned/updated via JSON RPC

[Martin Kosek]

On 02/25/2013 04:38 PM, Brian Smith wrote:
> It seems that regardless of the global password expiry setting, that setting a
> password via the methods
> 
> user-add
> passwd
> 
> i will always have a password that expires in 90 days.  I followed the
> instructions here http://freeipa.org/page/PasswordSynchronization
> 
> to avoid the immediate expiry, but I need at least 180 days for my
> configuration to work.
> 
> Any help would be appreciated!
> 
> -- 
> Brian Smith
> Assistant Director
> Research Computing, University of South Florida
> 4202 E. Fowler Ave. SVC4010
> Office Phone: +1 813 974-1467
> Organization URL: http://rc.usf.edu
> 

Hello Brian,

Updating maximum password expiration time with "ipa pwpolicy-mod" affects only
new passwords, i.e. password that you already changed will have the old 
lifetime.

When I tested this on Fedora 18, password change worked for me:

# ipa pwpolicy-mod --maxlife 180
  Group: global_policy
  Max lifetime (days): 180
  Min lifetime (hours): 1
  History size: 0
  Character classes: 0
  Min length: 8
  Max failures: 6
  Failure reset interval: 60
  Lockout duration: 600

# ipa user-add --first=Foo --last=Bar fbar
-
Added user "fbar"
-
  User login: fbar
  First name: Foo
  Last name: Bar
  Full name: Foo Bar
  Display name: Foo Bar
  Initials: FB
  Home directory: /home/fbar
  GECOS field: Foo Bar
  Login shell: /bin/sh
  Kerberos principal: f...@example.com
  Email address: f...@example.com
  UID: 175821
  GID: 175821
  Password: False
  Member of groups: ipausers
  Kerberos keys available: False
# ipa passwd fbar
New Password:
Enter New Password again to verify:
---
Changed password for "f...@example.com"
---

$ ssh f...@ipa.client.fqdn
f...@ipa.client.fqdn's password:
Password expired. Change your password now.
Last login: Tue Feb 26 09:16:39 2013 from 10.0.0.1
WARNING: Your password has expired.
You must change your password now and login again!
Changing password for user fbar.
Current Password:
New password:
Retype new password:
Your password will expire in 180 day(s).<<<
passwd: all authentication tokens updated successfully.
Connection to ipa.client.fqdn closed.

Does this usecase work for you or are you hitting a bug?


As for the warning about expiring password, this is a bug in sssd component
which was already fixed upstream:

https://fedorahosted.org/sssd/ticket/1808

Martin

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

Re: [Freeipa-users] ipa-replica-install command failed

[Martin Kosek]

On 02/26/2013 09:01 AM, Umarzuki Mochlis wrote:
> hi,
> 
> on tried to create a free-ipa replica on fedora 18 with
> freeipa-server-3.1.2-1.fc18.x86_64
> 
> below is last few lines of /var/log/ipareplica-install.log
> 
> 2013-02-25T16:16:33Z DEBUG retrieving schema for SchemaCache
> url=ldap://ipa.domain.com:389 conn= instance at 0x3b77758>
> 2013-02-25T16:18:42Z INFO   File
> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py",
> line 617, in run_script
> return_value = main_function()
> 
>   File "/usr/sbin/ipa-replica-install", line 633, in main
> ds = install_replica_ds(config)
> 
>   File "/usr/sbin/ipa-replica-install", line 161, in install_replica_ds
> pkcs12_info)
> 
>   File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py",
> line 303, in create_replica
> self.start_creation(runtime=60)
> 
>   File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
> line 358, in start_creation
> method()
> 
>   File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py",
> line 316, in __setup_replica
> r_bindpw=self.dm_password)
> 
>   File "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py",
> line 864, in setup_replication
> raise RuntimeError("Failed to start replication")
> 
> 2013-02-25T16:18:42Z INFO The ipa-replica-install command failed,
> exception: RuntimeError: Failed to start replication
> 
> is this a known issue/bug or simply errors on my part?
> 

Hello Umarzuki,

I am not aware of this bug. Can you please check 389-ds-base logs on the
replica and see if there is any bug? The log should be in
/var/log/dirsrv/slapd-YOUR-IPA-INSTANCE/errors.

Martin

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

Re: [Freeipa-users] ipa: ERROR: attribute 'idnsAllowTransfer' not allowed

[Martin Kosek]

On 02/25/2013 03:38 PM, Sigbjorn Lie wrote:
> On Mon, February 25, 2013 12:59, Christian Horn wrote:
>> Hi,
>>
>>
>> On Mon, Feb 25, 2013 at 09:46:49AM +0100, Sigbjorn Lie wrote:
>>
>>>
>>> $ ipa dnszone-add example.com --name-server=ns01.example.com
>>> --admin-email=hostmaster.example.com
>>> ipa: ERROR: attribute "idnsAllowTransfer" not allowed
>>>
>>>
>>> [..]
>>>
>>>
>>> Is this a known error?
>>>
>>
>> Yes,
>> the idnsZone objectClass entry was not updated properly during ipa-server 
>> update process. To fix
>> this the schema has to be modified, 
>> https://access.redhat.com/knowledge/solutions/301213 has
>> the details.
>>
> 
> Thank you. That worked just fine. :)
> 
> 
> Regards,
> Siggi
> 

Hi guys, I am glad you resolved the issue. I am just curious - from what
version to what version did you upgrade? Is this is a bug in IPA in RHEL 6.4?

Thank you,
Martin

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