Re: [Freeipa-users] Unable to communicate with CMS (Service Unavailable)

[Terry John]

>On Thu, Nov 12, 2015 at 08:55:25PM +0100, Martin Kosek wrote:
>> On 11/12/2015 04:51 PM, Terry John wrote:
>> >
>> >I got a core dump of certmonger failing user abrt but it's huge. Is there 
>> >any particular part that would be useful.
>>
>> CCing Nalin and David for the core dump. More below.

>My initial guess is that it's the same as the one reported in bug #1260871.  
>There's a fix for a problem that might be the cause in 0.77.6 and 0.78.5.  If 
>you can try a 0.77.6 build from the COPR system >[1], it'll help us figure out 
>if we've correctly identified the cause, or if the problem you're running into 
>is a different one.
>Nalin

>[1] https://copr.fedoraproject.org/coprs/nalin/certmonger/build/139854/

I'm not sure updating certmonger would help us in this case. The problem was 
that the CMS service was not running which was a Java version issue. The Java 
installation in /usr/java/default/bin was version 1.6.

Currently certmonger is and everything else is running fine.
# yum list installed certmonger
Installed Packages
certmonger.x86_64  0.77.5-1.el6 
  @base

# service certmonger status
certmonger (pid  2288) is running...

# ls -l /usr/java/default/bin/java
lrwxrwxrwx. 1 root root 22 Nov 13 14:14 /usr/java/default/bin/java -> 
/etc/alternatives/java
# ls -l  /etc/alternatives/java
lrwxrwxrwx. 1 root root 46 Nov 13 14:13 /etc/alternatives/java -> 
/usr/lib/jvm/jre-1.7.0-openjdk.x86_64/bin/java


The Manheim group of companies within the UK comprises: Manheim Europe Limited 
(registered number: 03183918), Manheim Auctions Limited (registered number: 
00448761), Manheim Retail Services Limited (registered number: 02838588), 
Motors.co.uk Limited (registered number: 05975777), Real Time Communications 
Limited (registered number: 04277845) and Complete Automotive Solutions Limited 
(registered number: 05302535). Each of these companies is registered in England 
and Wales with the registered office address of Central House, Leeds Road, 
Rothwell, Leeds LS26 0JE. The Manheim group of companies operates under various 
brand/trading names including Manheim Inspection Services, Manheim Auctions, 
Manheim Direct, Manheim De-fleet and Manheim Aftersales Solutions.

V:0CF72C13B2AC



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

Re: [Freeipa-users] Oracle Linux 5.5 - Legacy Question

[Rob Crittenden]

Jeffrey Stormshak wrote:

Thank you for the response.  If I may, can you expand more on the sudoers 
response?

More details from my configuration ...
The current setup for me is that all my sudoers rules/commands and groups are 
defined and stored in the RHEL 7.1 IDM LDAP.  When I create the 
/etc/sudo-ldap.conf (snippet below), I'm still not able to get it working on 
these 5.5 Linux clients.

uri ldap://ldap-server-name/
sudoers_base ou=SUDOers,dc=EXAMPLE,dc=COM
binddn uid=sudo,cn=sysaccounts,cn=etc,dc=EXAMPLE,dc=COM
bindpw secret_pass
bind_timelimit 5
timelimit 15

In your experience, am I missing some other component?  PAM Modules?  Reference 
in the /etc/nsswitch.conf?


It's hard to know what to recommend since you haven't said what isn't 
working.


Your nssswitch.conf should have:

sudoers: files ldap

You probably want to add sudoers_debug 2 to your sudo-ldap.conf file too 
while debugging.


You almost certainly want to use TLS here:

ssl start_tls
tls_cacertfile /etc/ipa/ca.crt
tls_checkpeer yes

You also need your nisdomainname set to your domain to do group or 
host-based sudo.


You also need to add this to your sssd.conf:

ldap_netgroup_search_base = cn=ng,cn=compat,dc=example,dc=com

Stick it after ipa_server in the config file.

Use sudo -l to test.

rob


-Original Message-
From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Jakub Hrozek
Sent: Tuesday, November 17, 2015 2:56 AM
To: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Oracle Linux 5.5 - Legacy Question

On Mon, Nov 16, 2015 at 08:58:37PM +, Jeffrey Stormshak wrote:

Greetings ---
I'm in the process of deploying the RHEL 7.1 IDM into my enterprise and we have a great 
number of Oracle Linux 5.5 servers.  Upon research from Oracle (ULN Channels) the Linux 
"ipa-client" was only released for 5.6 and then upstream.  I went ahead and 
configured the PAM/LDAP authentication method for 5.5 and so far its working as expected. 
 With that history being said ...

I'm having difficulty getting TLS and "sudoers" to be managed by the RHEL IDM 
to these 5.5 clients.  Can anyone share some insight or documentation details on how to 
solve these two problems prior to my mass deployment?  Any insight is greatly 
appreciated.  Thanks!


Not sure about TLS but sudoers should be managed with their ldap config 
(there's no sssd, hence to sssd sudo integration..)

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



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

Re: [Freeipa-users] Oracle Linux 5.5 - Legacy Question

[Jeffrey Stormshak]

Thank you for the response.  If I may, can you expand more on the sudoers 
response?  

More details from my configuration ...
The current setup for me is that all my sudoers rules/commands and groups are 
defined and stored in the RHEL 7.1 IDM LDAP.  When I create the 
/etc/sudo-ldap.conf (snippet below), I'm still not able to get it working on 
these 5.5 Linux clients.  

uri ldap://ldap-server-name/
sudoers_base ou=SUDOers,dc=EXAMPLE,dc=COM
binddn uid=sudo,cn=sysaccounts,cn=etc,dc=EXAMPLE,dc=COM
bindpw secret_pass
bind_timelimit 5
timelimit 15

In your experience, am I missing some other component?  PAM Modules?  Reference 
in the /etc/nsswitch.conf?

-Original Message-
From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Jakub Hrozek
Sent: Tuesday, November 17, 2015 2:56 AM
To: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Oracle Linux 5.5 - Legacy Question

On Mon, Nov 16, 2015 at 08:58:37PM +, Jeffrey Stormshak wrote:
> Greetings ---
> I'm in the process of deploying the RHEL 7.1 IDM into my enterprise and we 
> have a great number of Oracle Linux 5.5 servers.  Upon research from Oracle 
> (ULN Channels) the Linux "ipa-client" was only released for 5.6 and then 
> upstream.  I went ahead and configured the PAM/LDAP authentication method for 
> 5.5 and so far its working as expected.  With that history being said ...
> 
> I'm having difficulty getting TLS and "sudoers" to be managed by the RHEL IDM 
> to these 5.5 clients.  Can anyone share some insight or documentation details 
> on how to solve these two problems prior to my mass deployment?  Any insight 
> is greatly appreciated.  Thanks!

Not sure about TLS but sudoers should be managed with their ldap config 
(there's no sssd, hence to sssd sudo integration..)

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

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

Re: [Freeipa-users] Oracle Linux 5.5 - Legacy Question

[Jeffrey Stormshak]

Thanks Rob!  Sorry, I didn't forget to mention what was the message.  It 
basically stated the message listed below.

Sorry, user plmoss may not run sudo on client_server

Let me try your suggestions and see if that helps lead me down the right path.  
Once again, thanks for this feedback.  Oh how I miss using the "ipa-client" I 
used on all of my higher Linux versions.  Talk about saving time cycles and 
deployment timeframes.  Oh well.  

-Original Message-
From: Rob Crittenden [mailto:rcrit...@redhat.com] 
Sent: Tuesday, November 17, 2015 9:51 AM
To: Jeffrey Stormshak; Jakub Hrozek; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Oracle Linux 5.5 - Legacy Question

Jeffrey Stormshak wrote:
> Thank you for the response.  If I may, can you expand more on the sudoers 
> response?
>
> More details from my configuration ...
> The current setup for me is that all my sudoers rules/commands and groups are 
> defined and stored in the RHEL 7.1 IDM LDAP.  When I create the 
> /etc/sudo-ldap.conf (snippet below), I'm still not able to get it working on 
> these 5.5 Linux clients.
>
> uri ldap://ldap-server-name/
> sudoers_base ou=SUDOers,dc=EXAMPLE,dc=COM binddn 
> uid=sudo,cn=sysaccounts,cn=etc,dc=EXAMPLE,dc=COM
> bindpw secret_pass
> bind_timelimit 5
> timelimit 15
>
> In your experience, am I missing some other component?  PAM Modules?  
> Reference in the /etc/nsswitch.conf?

It's hard to know what to recommend since you haven't said what isn't working.

Your nssswitch.conf should have:

sudoers: files ldap

You probably want to add sudoers_debug 2 to your sudo-ldap.conf file too while 
debugging.

You almost certainly want to use TLS here:

ssl start_tls
tls_cacertfile /etc/ipa/ca.crt
tls_checkpeer yes

You also need your nisdomainname set to your domain to do group or host-based 
sudo.

You also need to add this to your sssd.conf:

ldap_netgroup_search_base = cn=ng,cn=compat,dc=example,dc=com

Stick it after ipa_server in the config file.

Use sudo -l to test.

rob
>
> -Original Message-
> From: freeipa-users-boun...@redhat.com 
> [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Jakub Hrozek
> Sent: Tuesday, November 17, 2015 2:56 AM
> To: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] Oracle Linux 5.5 - Legacy Question
>
> On Mon, Nov 16, 2015 at 08:58:37PM +, Jeffrey Stormshak wrote:
>> Greetings ---
>> I'm in the process of deploying the RHEL 7.1 IDM into my enterprise and we 
>> have a great number of Oracle Linux 5.5 servers.  Upon research from Oracle 
>> (ULN Channels) the Linux "ipa-client" was only released for 5.6 and then 
>> upstream.  I went ahead and configured the PAM/LDAP authentication method 
>> for 5.5 and so far its working as expected.  With that history being said ...
>>
>> I'm having difficulty getting TLS and "sudoers" to be managed by the RHEL 
>> IDM to these 5.5 clients.  Can anyone share some insight or documentation 
>> details on how to solve these two problems prior to my mass deployment?  Any 
>> insight is greatly appreciated.  Thanks!
>
> Not sure about TLS but sudoers should be managed with their ldap 
> config (there's no sssd, hence to sssd sudo integration..)
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>


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

Re: [Freeipa-users] Oracle Linux 5.5 - Legacy Question

[Jeffrey Stormshak]

I meant "did" forget.  Silly typo on my behalf...

-Original Message-
From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Jeffrey Stormshak
Sent: Tuesday, November 17, 2015 10:44 AM
To: Rob Crittenden; Jakub Hrozek; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Oracle Linux 5.5 - Legacy Question

Thanks Rob!  Sorry, I didn't forget to mention what was the message.  It 
basically stated the message listed below.

Sorry, user plmoss may not run sudo on client_server

Let me try your suggestions and see if that helps lead me down the right path.  
Once again, thanks for this feedback.  Oh how I miss using the "ipa-client" I 
used on all of my higher Linux versions.  Talk about saving time cycles and 
deployment timeframes.  Oh well.  

-Original Message-
From: Rob Crittenden [mailto:rcrit...@redhat.com]
Sent: Tuesday, November 17, 2015 9:51 AM
To: Jeffrey Stormshak; Jakub Hrozek; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Oracle Linux 5.5 - Legacy Question

Jeffrey Stormshak wrote:
> Thank you for the response.  If I may, can you expand more on the sudoers 
> response?
>
> More details from my configuration ...
> The current setup for me is that all my sudoers rules/commands and groups are 
> defined and stored in the RHEL 7.1 IDM LDAP.  When I create the 
> /etc/sudo-ldap.conf (snippet below), I'm still not able to get it working on 
> these 5.5 Linux clients.
>
> uri ldap://ldap-server-name/
> sudoers_base ou=SUDOers,dc=EXAMPLE,dc=COM binddn 
> uid=sudo,cn=sysaccounts,cn=etc,dc=EXAMPLE,dc=COM
> bindpw secret_pass
> bind_timelimit 5
> timelimit 15
>
> In your experience, am I missing some other component?  PAM Modules?  
> Reference in the /etc/nsswitch.conf?

It's hard to know what to recommend since you haven't said what isn't working.

Your nssswitch.conf should have:

sudoers: files ldap

You probably want to add sudoers_debug 2 to your sudo-ldap.conf file too while 
debugging.

You almost certainly want to use TLS here:

ssl start_tls
tls_cacertfile /etc/ipa/ca.crt
tls_checkpeer yes

You also need your nisdomainname set to your domain to do group or host-based 
sudo.

You also need to add this to your sssd.conf:

ldap_netgroup_search_base = cn=ng,cn=compat,dc=example,dc=com

Stick it after ipa_server in the config file.

Use sudo -l to test.

rob
>
> -Original Message-
> From: freeipa-users-boun...@redhat.com 
> [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Jakub Hrozek
> Sent: Tuesday, November 17, 2015 2:56 AM
> To: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] Oracle Linux 5.5 - Legacy Question
>
> On Mon, Nov 16, 2015 at 08:58:37PM +, Jeffrey Stormshak wrote:
>> Greetings ---
>> I'm in the process of deploying the RHEL 7.1 IDM into my enterprise and we 
>> have a great number of Oracle Linux 5.5 servers.  Upon research from Oracle 
>> (ULN Channels) the Linux "ipa-client" was only released for 5.6 and then 
>> upstream.  I went ahead and configured the PAM/LDAP authentication method 
>> for 5.5 and so far its working as expected.  With that history being said ...
>>
>> I'm having difficulty getting TLS and "sudoers" to be managed by the RHEL 
>> IDM to these 5.5 clients.  Can anyone share some insight or documentation 
>> details on how to solve these two problems prior to my mass deployment?  Any 
>> insight is greatly appreciated.  Thanks!
>
> Not sure about TLS but sudoers should be managed with their ldap 
> config (there's no sssd, hence to sssd sudo integration..)
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>


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

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

[Freeipa-users] SOLVED Fwd: Re: ipa user-add slows down as more users are added

[Daryl Fonseca-Holt]

Hi all,

Splitting ipausers helped ipa user-add speed a lot. Two other things helped:

1) Setting nsslapd-cachememsize much larger than the size of the 
id2entry file

2) Increasing the size of the DN cache size, nsslapd-ndn-cache-max-size

I've got 60,000+ users now and user-add only takes slightly over three 
seconds.


Because we will continue to add large number of users at the start of 
the University's fall term and the new userids will be sequential I 
chose to use a prime number,  211, of ipauser groups and hash the 
userid. Thus the new ones will spread evenly over the groups and we 
should end up with less than 1,000 users per group.


Thanks again for your help,
Daryl

 Forwarded Message 
Subject: 	Re: [Freeipa-users] ipa user-add slows down as more users are 
added

Date:   Thu, 5 Nov 2015 16:37:29 -0600
From:   Daryl Fonseca-Holt 
To: Rich Megginson 



On 11/04/15 17:25, Rich Megginson wrote:

On 11/04/2015 04:07 PM, Rob Crittenden wrote:

Daryl Fonseca-Holt wrote:

Hi All,

I am testing migration from NIS with a custom MySQL backend to IPA. In
our testing ipa user-add starts out at around 12 seconds per user but
slows down as more users are add. By 5000+ users it is taking 90+
seconds. We have 120,000+ users. I'm looking at 155 days to load all
the
users :(

Per some performance tuning documentation I've increased
nsslapd-cachememsize to 35,651,584 and am currently getting pretty high
hit ratios (see below).


Use dbmon.sh instead of db_stat - it will give you the entry cache
information as well as a summary of the db cache information (instead
of the quite verbose db_stat output).


Thanks for the tip. I've got some tuning to do. My dbcachefree is
negative and the roevicts are high.

However, one thread of ns-slapd pegs out core at
100% and I can't get get it to add users any faster. I'm not seeing any
I/O or memory swapping.

The problem is most likely the default IPA users group. As it gets
humongous adding new members slows it down.


So could he disable the automember and memberof plugins?  Then have
those work offline, after the users are added?




Suggestions would be appreciated. Multi-master will probably help but
with that many accounts it would take a lot of masters to get additions
done to a resonable (45 seconds or less?) time. Is there any guideline
for number of users per master?

IPA is multi-master. All users are on all masters.

If anything I'd expect that running imports on different masters would
slow things down as changes on multiple masters would need to get merged
together, particularly the default group.


Right.



Certainly bumping up the caches to match what the final expected sizes
is probably a good idea but I don't see it influencing import speed all
that much.


Right.



One idea I've had is to add the users in batches of 1000. What you'd do
is create 120 non-POSIX user groups, ipausers1..ipausers120, and add
them as members of ipausers.

Then for each batch change the default ipausers group with:

  $ ipa config-mod --defaultgroup=

This should keep the user-add command fairly peppy and keep the ipausers
group somewhat in check via the nesting.


I'm doing this but with a twist. I have an existing user base so I'm
going to use
the existing UID to hash to one of the ipauser groups. Will do
round-robin
for future adds. Being an education institution we get a lot of new
accounts each fall.



I imagine that the UI would blow up if you tried to view the ipausers
group as it tried to dereference 120k users.

You'll probably also want to disable the compat module for the import.


I'll give this a try too.

I assume you've already done some amount of testing with a smaller batch
of users to ensure they migrate ok, passwords work, etc?

rob





Thanks to both of you. It will be a while before I can report the fruits
of this
exercise. I'm reluctant to give up the 5000+ that I've already added so I'm
deleting them from ipauser and adding them to the appropriate ipauser.

Meantime I've got a bunch of other scripts to write for some of the
custom stuff
we did with PAM and the old MySQL backend.

Regards,
Daryl

--
 --
 Daryl Fonseca-Holt
 IST/CNS/Unix Server Team
 University of Manitoba
 204.480.1079



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

[Freeipa-users] "ASN.1 structure is missing a required field" - what is missing?

[Marc Boorshtein]

I'm putting together a java kerberos client and am having an issue
getting a SGT form IPA.  I get a TGT without issue, but when I submit
the TGS-REQ I get the following errors in the ipa log:

Nov 17 20:53:15 freeipa.rhelent.lan krb5kdc[7507](info): AS_REQ (1
etypes {17}) 192.168.2.129: ISSUE: authtime 1447811595, etypes {rep=17
tkt=18 ses=17}, HTTP/s4u.rhelent@rhelent.lan for
krbtgt/rhelent@rhelent.lan

Nov 17 20:53:15 freeipa.rhelent.lan krb5kdc[7507](info): TGS_REQ (1
etypes {17}) 192.168.2.129: PROCESS_TGS: authtime 0,  
for HTTP/ipa.rhelent@rhelent.lan, ASN.1 structure is missing a
required field

Here's the TGS request:

Kerberos
tgs-req
pvno: 5
msg-type: krb-tgs-req (12)
padata: 1 item
PA-DATA PA-TGS-REQ
padata-type: kRB5-PADATA-TGS-REQ (1)
padata-value:
6e8201f8308201f4a003020105a10302010ea2070305...
ap-req
pvno: 5
msg-type: krb-ap-req (14)
Padding: 0
ap-options: 
0...  = reserved: False
.0..  = use-session-key: False
..0.  = mutual-required: False
ticket
tkt-vno: 5
realm: RHELENT.LAN
sname
name-type: kRB5-NT-PRINCIPAL (1)
name-string: 2 items
KerberosString: krbtgt
KerberosString: RHELENT.LAN
enc-part
etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
kvno: 1
cipher:
0efd7452dafeb94323bcf7f6adc373aab78ce179f42c4c11...
authenticator
etype: eTYPE-AES128-CTS-HMAC-SHA1-96 (17)
kvno: 255
cipher:
f40e91b920c6ae6bdc30a69d5f348bf106355a92da74ba74...
req-body
Padding: 0
kdc-options: 
0...  = reserved: False
.0..  = forwardable: False
..0.  = forwarded: False
...0  = proxiable: False
 0... = proxy: False
 .0.. = allow-postdate: False
 ..0. = postdated: False
 ...0 = unused7: False
0...  = renewable: False
.0..  = unused9: False
..0.  = unused10: False
...0  = opt-hardware-auth: False
 ..0. = request-anonymous: False
 ...0 = canonicalize: False
0...  = constrained-delegation: False
..0.  = disable-transited-check: False
...0  = renewable-ok: False
 0... = enc-tkt-in-skey: False
 ..0. = renew: False
 ...0 = validate: False
cname
name-type: kRB5-NT-PRINCIPAL (1)
name-string: 2 items
KerberosString: HTTP
KerberosString: s4u.rhelent.lan
realm: RHELENT.LAN
sname
name-type: kRB5-NT-PRINCIPAL (1)
name-string: 2 items
KerberosString: HTTP
KerberosString: ipa.rhelent.lan
from: 2015-11-18 02:17:44 (UTC)
till: 2015-11-18 10:17:44 (UTC)
nonce: 604310537
etype: 1 item
ENCTYPE: eTYPE-AES128-CTS-HMAC-SHA1-96 (17)


Is there a field missing?

Thanks


Marc Boorshtein
CTO Tremolo Security
marc.boorsht...@tremolosecurity.com

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

Re: [Freeipa-users] Unable to communicate with CMS (Service Unavailable) (Solved)

[Fraser Tweedale]

On Fri, Nov 13, 2015 at 12:00:16PM +0100, Martin Kosek wrote:
> On 11/13/2015 11:14 AM, Terry John wrote:
> >>On 11/12/2015 04:51 PM, Terry John wrote:
> >>>I got a core dump of certmonger failing user abrt but it's huge. Is there 
> >>>any particular part that would be useful.
> >
> >>CCing Nalin and David for the core dump. More below.
> >
> >>On 11/12/2015 02:17 PM, Terry John wrote:
> I had a working freeipa setup on a CentOS release 6.7 machine.  All was 
> well until I did a yum update. Now I have multiple issue apparently based 
> around the CMS (Service Unavailable) issue.
> My current version of ipa-server is 3.0.0-47 Certmonger crashes with
> a segmentation fault at boot time and crashes every time I try to restart 
> it when ipa is running.
> >>
> >
> >
> ># ipa cert-status
> >Request id: 20140417164153
> >ipa: ERROR: Certificate operation cannot be completed: Unable to
> >communicate with CMS (Service Unavailable) # service certmonger
> >status certmonger (pid  3030) is running...
> >>>
> It looks like PKI cannot be contacted. I would recommend checking 
> /var/log/httpd/error_log, it may have more details. I would also 
> recommend checking "ipa cert-show 1", it will probably fail with the same 
> bug.
> >>>Yes ipa cert-show 1 does show the same thing # ipa cert-show 1
> >>>ipa: ERROR: Certificate operation cannot be completed: Unable to
> >>>communicate with CMS (Service Unavailable)
> >>>
> Next steps may include checking that dogtag service really runs, there is 
> no SELinux AVC. If neither of this helps, you can check PKI logs 
> /var/log/pki... to see what went wrong.
> >>>I'm pretty certain the dogtag service is not running
> >
> >Then you have your lucky winner! :-)
> >
> Some pointers to logs are for example here:
> http://www.freeipa.org/page/Troubleshooting#Server_Installation
> >>
> >>>/var/log/pki-ca/catalina.out contains the lines at boot time:
> >
> >
> >>>SEVERE: Error deploying web application directory ca
> >>>java.lang.UnsupportedClassVersionError: 
> >>>com/netscape/cms/servlet/filter/AgentRequestFilter : Unsupported 
> >>>major.minor version 51.0 (unable to load class 
> >>>com.netscape.cms.servlet.filter.AgentRequestFilter)   at  
> >>>org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappC> 
> >>>lassLoader.java:2334) lots of traceback
> >>>
> >>>/var/log/pki-ca/system is empty
> >>>/var/log/pki-ca/debug has nothing new for 2 days
> >
> >>CCing Fraser. This is a wild guess, but maybe you updated your java to 
> >>java-1.8.0-openjdk? PKI does not work on it on RHEL/CentOS:
> >
> >>https://bugzilla.redhat.com/show_bug.cgi?id=1262516
> >
> >>java would need to be switched with "alternate" to pre-1.8.0 version if 
> >>this is the case.
> >
> >The java version was the problem.
> 
> Good! Fraser, can we improve anything in pki-core, so that wrong java
> version issue like this one does not occur? IIRC, pki-core in RHEL-6.x was
> updated to somehow deal with java 1.8.0 (conflict), not sure if lower
> versions are also covered.
> 
AFAICT there is no such protection.  It seems to be more of an
unspoken "don't do that".

I guess the right approach when an unsupported alternative is
selected is to explicitly use a supported one.  I'm not sure what's
involved in making that change or whether it is worth the effort.

Adding pki-devel for comment from those with packaging experience.

Cheers,
Fraser

> >Luckily I have a java expert to hand and explained that major.minor version 
> >51.0 corresponds to java 7
> >http://stackoverflow.com/questions/9170832/list-of-java-class-file-format-major-version-numbers
> >When I did
> ># ps ax | grep java I got"
> >1460 ? Sl   1:21 /usr/java/default/bin/java -Djavax.sql.Da...
> ># /usr/java/default/bin/java -version
> >java version "1.6.0_31"
> >Java(TM) SE Runtime Environment (build 1.6.0_31-b04)
> >Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01, mixed mode)
> >
> >I have both java-1.6.0-openjdk and java-1.7.0-openjdk installed but the 
> >/usr/java/default/bin is all from java-1.6.0-openjdk
> >
> >I have renamed /usr/java/default/bin/java to javaold and done
> ># ln -s /usr/bin/java /usr/java/default/bin/java
> ># /usr/java/default/bin/java -version
> >java version "1.7.0_91"
> >OpenJDK Runtime Environment (rhel-2.6.2.2.el6_7-x86_64 u91-b00)
> >OpenJDK 64-Bit Server VM (build 24.91-b01, mixed mode)
> 
> This may work, but looks a bit hacky. I think the right way is to use
> "alternate" program I mentioned earlier to let you choose the right version
> of the java executable and/or libraries.
> 
> >After a reboot FreeIPA works properly which is great but I'm wondering if 
> >there is a better fix though since all the other executables in are from the 
> >1.6 version. I can't find a corresponding location for 1.7 executables.
> 
> The "alternate" approach should "just work". I am glad you made the instance
> working again!
> 
> >
> >Thanks 

Re: [Freeipa-users] Cannot add or delete ssh user keys

[Jens Dieskau]

I found the problem and opened a new ticket at 
https://fedorahosted.org/freeipa/ticket/5456


Am 17.11.2015 um 03:56 schrieb Jens Dieskau:

Hello everybody,

Since the last version of FreeIPA I cannot add or delete any ssh user
keys for synced users. Neither on commandline nor web ui.

It works flawless with local created users. But it does not work with
users created by winsync. See error message below.

If I add the ntUser objectClass manually to a local user, it also
doesn't work any more. Maybe this is somehow the origin of the bug?
Are there any other logs I could check out?


Thanks,
Jens


ipa -vv user-mod name --sshpubkey="ssh-rsa foobar name@host"
ipa: INFO: trying https://ipa.cs.ucc.md/ipa/session/json
ipa: INFO: Request: {
 "id": 0,
 "method": "ping",
 "params": [
 [],
 {}
 ]
}
ipa: INFO: Response: {
 "error": null,
 "id": 0,
 "principal": "ad...@cs.ucc.md",
 "result": {
 "messages": [
 {
 "code": 13001,
 "message": "API Version number was not sent, forward
compatibility not guaranteed. Assuming server's API version, 2.156",
 "name": "VersionMissing",
 "type": "warning"
 }
 ],
 "summary": "IPA server version 4.2.3. API version 2.156"
 },
 "version": "4.2.3"
}
ipa: INFO: Forwarding 'user_mod' to json server
'https://ipa.cs.ucc.md/ipa/session/json'
ipa: INFO: Request: {
 "id": 0,Since the last version of FreeIPA I cannot add or delete any ssh 
user keys for synced users. Neither on commandline nor web ui.
 "method": "user_mod",
 "params": [
 [
 "name"
 ],
 {
 "all": false,
 "ipasshpubkey": [
 "ssh-rsa foobar name@host"
 ],
 "no_members": false,
 "random": false,
 "raw": false,
 "rights": false,
 "version": "2.156"
 }
 ]
}
ipa: INFO: Response: {
 "error": {
 "code": 4203,
 "message": "Type or value exists: ",
 "name": "DatabaseError"
 },
 "id": 0,
 "principal": "ad...@cs.ucc.md",
 "result": null,
 "version": "4.2.3"
}
ipa: ERROR: Type or value exists:



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

Re: [Freeipa-users] Oracle Linux 5.5 - Legacy Question

[Jakub Hrozek]

On Mon, Nov 16, 2015 at 08:58:37PM +, Jeffrey Stormshak wrote:
> Greetings ---
> I'm in the process of deploying the RHEL 7.1 IDM into my enterprise and we 
> have a great number of Oracle Linux 5.5 servers.  Upon research from Oracle 
> (ULN Channels) the Linux "ipa-client" was only released for 5.6 and then 
> upstream.  I went ahead and configured the PAM/LDAP authentication method for 
> 5.5 and so far its working as expected.  With that history being said ...
> 
> I'm having difficulty getting TLS and "sudoers" to be managed by the RHEL IDM 
> to these 5.5 clients.  Can anyone share some insight or documentation details 
> on how to solve these two problems prior to my mass deployment?  Any insight 
> is greatly appreciated.  Thanks!

Not sure about TLS but sudoers should be managed with their ldap config
(there's no sssd, hence to sssd sudo integration..)

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

Re: [Freeipa-users] Restricting access to unencrypted LDAP connections

[Ludwig Krispenz]

you could set minssf:
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/SecureConnections.html#requiring-secure-connections

On 11/18/2015 07:24 AM, Prashant Bapat wrote:

Hi,

We have a pair of freeipa servers (4.1.4) and a bunch of Linux clients 
configured to talk to them thru pam-nss-ldapd (no sssd). I want to 
ensure that these clients only talk to freeipa's LDAP server either 
via ldaps or ldap+starttls. Plain ldap should not be allowed.


I can always switch to ldaps only and close the tcp/389 port on the 
firewall. But is there a way to achieve this using tcp/389 port.?


Any suggestions appreciated.

Thanks.
--Prashant




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

[Freeipa-users] Restricting access to unencrypted LDAP connections

[Prashant Bapat]

Hi,

We have a pair of freeipa servers (4.1.4) and a bunch of Linux clients
configured to talk to them thru pam-nss-ldapd (no sssd). I want to ensure
that these clients only talk to freeipa's LDAP server either via ldaps or
ldap+starttls. Plain ldap should not be allowed.

I can always switch to ldaps only and close the tcp/389 port on the
firewall. But is there a way to achieve this using tcp/389 port.?

Any suggestions appreciated.

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