Re: [Freeipa-users] Sudo rule implementation

[Ben .T.George]

HI,

thanks for your information. I have validated logs.

i destroyed the current kerberos ticket and re-initiated, then the issue
solved.

Regards,
Ben

On Tue, Dec 20, 2016 at 2:24 PM, Jakub Hrozek  wrote:

> On Tue, Dec 20, 2016 at 01:19:15PM +0300, Ben .T.George wrote:
> > Hi List,
> >
> > please help me to implement sudo rules.
> >
> > i have did below steps and still not working for me.
> >
> > 1. created "Sudo Command Groups"
> > 2. Added some command (/bin/yum) and included in sudo group
> > 3. created "sudo Rule" on that
> > * added sudo Option as "!authenticate"
> >   * Added User Group.
> >   * Added one Host
> >   * And under Run command, selected the Sudo Rule Group.
> > 4. entry on nsswitch.conf : sudoers: files sss
> > 5. entry on sssd.conf : services = nss, sudo, pam, ssh
> >
> > and i tried removing "!authenticate" and changed to Anyone, Any Host and
> Any
> > Command,
> > Also under As Whom to Anyone and Any Group
> > - I tried logout and login again on client with IPA user which is member
> of
> > user group.
> >
> > When i am running yum, getting error that user is not allowed to execute
> > command.
> >
> >
> > Please anyone help to correct my steps.
> >
> > Regards
> > Ben
>
> Please follow:
> https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO
> especially the sudo logs are often helpful to see what rules is sssd
> returning to sudo.
>
> --
> 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] ipa-dnskeysyncd ipa : ERROR Login to LDAP server failed: {'desc': 'Invalid credentials'}

[Petr Spacek]

On 20.12.2016 12:41, Brian J. Murrell wrote:
> On Tue, 2016-12-20 at 11:55 +0100, Martin Basti wrote:
>>
>> So there are actually no issues with credentials, it needs more 
>> debugging, in past we have similar case but we haven't found the
>> root 
>> cause why it doesn't have the right credentials after kinit.
> 
> So, to be clear, all I did was kinit.  I didn't do anything after that
> once the credentials were acquired. Should I have or did you just want
> me to test that credential file was usable?  I did that as root. 
> Here's the permissions on that keytab just in case there is a problem
> there:
> 
> # ls -lZ /etc/ipa/dnssec/ipa-dnskeysyncd.keytab
> -r--r-. root ods unconfined_u:object_r:etc_t:s0   
> /etc/ipa/dnssec/ipa-dnskeysyncd.keytab
> 
> restorecon says that the selinux labels are ok.  The file is not in the
> RPM (i.e. as a config file) so I have no reference for the permissions
> of it.
> 
>> Are you 
>> willing to do more basic level code debugging?
> 
> Absolutely.
> 
>> BTW this is used only with DNSSEC feature. I you don't use DNSSEC 
>> signing you can ignore this failing service (ipactl start 
>> --ignore-service-failures)
> 
> Let's also not lose sight of the other problem that occurred at the
> same upgrade and that's the having to fall back to simple
> authentication of bind with:
> 
> arg "auth_method simple";
> arg "bind_dn uid=admin,cn=users,cn=accounts,dc=example.com";
> arg "password my_password";
> 
> in /etc/named.conf due to:
> 
> 21:12:19 LDAP error: Invalid credentials: bind to LDAP server failed
> 
> trying to start bind via systemctl start ipa.
> 
> Is it most likely that these two problems are in fact not related?

I guess that they are related because it is basically the very same problem.
The keytab does not work when used from the server application.

The question is: Why is that?

You can try to add line
KRB5_TRACE=/dev/stdout
to
/etc/sysconfig/ipa-dnskeysyncd

and see if there will be some additional information in the the journal.

Maybe you will have to use path like /var/lib/ipa/dnssec/debug.log instead of
/dev/stderr and then look into the new file.

-- 
Petr^2 Spacek

-- 
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] freeipa 4.1 replication conflict resolve issue

[Ian Chen]

hello list,

I tried to search for answer, but not solution come up yet. please help.

the setup with multiple nodes has IPA version:
ipa-server-4.1.0-18.el7.centos.4.x86_64


after adding a replication with an old node, replicaiton conflict occured.

 node104
dn:
nsuniqueid=5820a804-af9211e6-bbce8d9c-0794b841+uid=test2,cn=users,cn=acco
 unts,dc=...
uid: test2
nsds5ReplConflict: namingConflict uid=test2,cn=users,cn=accounts,dc=...
krbPrincipalName: test2@...
krbLastPwdChange: 20161220054653Z
krbPasswordExpiration: 20170320054653Z
ipaUniqueID: 606b2260-af92-11e6-a928-0050568faf9d


 node203
dn: uid=test2,cn=users,cn=accounts,dc=...
uid: test2
krbPrincipalName: test2@...
krbLastPwdChange: 20161220054653Z
krbPasswordExpiration: 20170320054653Z
ipaUniqueID: 606b2260-af92-11e6-a928-0050568faf9d


I tried rename RDN following this
https://mkosek.fedorapeople.org/publican_site/en-US/FreeIPA/3.4/html/FreeIPA_Guide/ipa-replica-manage.html

but when trying to delete uid, then change RDN back to uid, there is this
error

modifying entry "cn=TempValue,cn=users,cn=accounts,dc=..."
ldap_modify: Object class violation (65)
additional info: missing attribute "uid" required by object class
"posixAccount"

I cannot delete object class posixAccount then add it back
-- 
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] Valid Sender ? - Re: ipa-otpd: timeout from kerberos when talking to an external 'slow' RADIUS server

[Jochen Hein]

Alexander Bokovoy  writes:

>>* sssd has a default kerberos timeout of six seconds.
>>  Can be changed in /etc/sssd/sssd.conf: krb5_auth_timeout,
>>  which also seems to work for auth_provider = ipa, but is not
>>  documented in sssd-ipa(5).
> sssd-ipa(5) says:
> 
>   The IPA provider accepts the same options used by the
>   sssd-ldap(5) identity provider and the sssd-krb5(5)
>   authentication provider with some exceptions described
>   below.
> 
>
> I'm not sure how much we could improve here.

I just scanned the option list and did not read the complete text.

> It would be good to write an article on the wiki that covers privacyidea
> integration and explains the workflow.

Cornelius from Privacyidea already asked me for this, but I first wanted
to get something stable and useful running. Now it looks like that is
done I'll try to write something up.

> Technically, we have most of
> Kerberos client (SSS) -> KDC -> IPA-OTPD -> FreeRADIUS covered in
> http://www.freeipa.org/page/V4/OTP and
> http://www.freeipa.org/page/V4/OTP/Detail, but they lack timeouts
> description.

Yes, these pages helped my a lot.

Jochen

-- 
The only problem with troubleshooting is that the trouble shoots back.

-- 
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] Valid Sender ? - Re: ipa-otpd: timeout from kerberos when talking to an external 'slow' RADIUS server

[Alexander Bokovoy]

On ti, 20 joulu 2016, Jochen Hein wrote:

Alexander Bokovoy  writes:


1. KDC to ipa-otd: this can be changed in
/var/kerberos/krb5kdc/kdc.conf. I think the timeout should be larger
then the (largest) second timeout - and I think retries=0 is best.
This is for communication between KDC and ipa-otd.

2. There is a timeout in each RADIUS server config in IPA for the
communication from ipa-otp to external RADIUS servers:
`
Again I think that for OTPs we are probably best with retries=0.

On older clients it might be helpful to add "udp_preference_limit = 0"
to /etc/krb5.conf - at least on my Debian/Ubuntu machines.



Ok. It would probably make sense to file a ticket to FreeIPA tracker to
get these changes in FreeIPA 4.5.


I think I've won my fight...  Here's what I've learned.  The short story is
that probably no timeout should be changed. Shall I still file a ticket
concerning retry counts?

Authentication of IPA users against RADIUS were mostly failing, but
not always. There were hints about timeouts almost everywhere.
Multiple authentication requests from kerberos, timeouts from sssd,
but that should have sent me on the right track from the start:

Dec 19 22:11:51 freeipa1 ipa-otpd: LDAP: 
ldapi://%2Fvar%2Frun%2Fslapd-JOCHEN-ORG.socket
Dec 19 22:11:51 freeipa1 ipa-otpd: jkell...@jochen.org: request received
Dec 19 22:11:51 freeipa1 ipa-otpd: jkell...@jochen.org: user query start
Dec 19 22:11:51 freeipa1 ipa-otpd: jkell...@jochen.org: user query end: 
uid=jkellner,cn=users,cn=accounts,dc=jochen,dc=org
Dec 19 22:11:51 freeipa1 ipa-otpd: jkell...@jochen.org: radius query start: 
cn=athene,cn=radiusproxy,dc=jochen,dc=org
Dec 19 22:11:51 freeipa1 ipa-otpd: jkell...@jochen.org: radius query end: 
athene.jochen.org
Dec 19 22:11:51 freeipa1 ipa-otpd: jkell...@jochen.org: forward start: 
jkell...@jochen.org / athene.jochen.org
Dec 19 22:12:01 freeipa1 ipa-otpd: jkell...@jochen.org: forward end: Connection 
timed out
Dec 19 22:12:01 freeipa1 ipa-otpd: jkell...@jochen.org: response sent: 
Access-Reject

or:

Dec 20 22:40:23 freeipa1 ipa-otpd: jkell...@jochen.org: request received
Dec 20 22:40:23 freeipa1 ipa-otpd: jkell...@jochen.org: user query start
Dec 20 22:40:23 freeipa1 ipa-otpd: jkell...@jochen.org: user query end: 
uid=jkellner,cn=users,cn=accounts,dc=jochen,dc=org
Dec 20 22:40:23 freeipa1 ipa-otpd: jkell...@jochen.org: radius query start: 
cn=athene,cn=radiusproxy,dc=jochen,dc=org
Dec 20 22:40:23 freeipa1 ipa-otpd: jkell...@jochen.org: radius query end: 
athene.jochen.org
Dec 20 22:40:23 freeipa1 ipa-otpd: jkell...@jochen.org: forward start: 
jkell...@jochen.org / athene.jochen.org
Dec 20 22:40:31 freeipa1 ipa-otpd: jkell...@jochen.org: forward end: 
Access-Accept
Dec 20 22:40:31 freeipa1 ipa-otpd: jkell...@jochen.org: response sent: 
Access-Accept

Why is there such a long delay?  The Log of the RADIUS server has:

Tue Dec 20 22:40:30 2016 : Info: rlm_perl: Config File 
/opt/privacyIDEA/rlm_perl.ini found!
Tue Dec 20 22:40:30 2016 : Info: rlm_perl: Debugging config: true
Tue Dec 20 22:40:30 2016 : Info: rlm_perl: Default URL 
https://athene.jochen.org/validate/check
Tue Dec 20 22:40:30 2016 : Info: rlm_perl: Looking for config for auth-type Perl
Tue Dec 20 22:40:30 2016 : Info: rlm_perl: Auth-Type: Perl
Tue Dec 20 22:40:30 2016 : Info: rlm_perl: url: 
https://athene.jochen.org/validate/check
Tue Dec 20 22:40:30 2016 : Info: rlm_perl: user sent to privacyidea: 
jkell...@jochen.org
Tue Dec 20 22:40:30 2016 : Info: rlm_perl: realm sent to privacyidea: jochen.org
Tue Dec 20 22:40:30 2016 : Info: rlm_perl: resolver sent to privacyidea:
Tue Dec 20 22:40:30 2016 : Info: rlm_perl: client sent to privacyidea: 
192.168.30.121
Tue Dec 20 22:40:30 2016 : Info: rlm_perl: state sent to privacyidea:
Tue Dec 20 22:40:31 2016 : Info: rlm_perl: privacyIDEA access granted
Tue Dec 20 22:40:31 2016 : Info: rlm_perl: return RLM_MODULE_OK

So RADIUS thinks, it got a request a 30 seconds, but why did we wait so long?
I took a tcpdump and saw:

22:40:23.364355 IP6 freeipa1.jochen.org.41198 > athene.jochen.org.radius: 
RADIUS, Access-Request (1), id: 0x10 length: 134
22:40:30.872136 IP freeipa1.jochen.org.44314 > athene.jochen.org.radius: 
RADIUS, Access-Request (1), id: 0x9c length: 134
22:40:31.572217 IP athene.jochen.org.radius > freeipa1.jochen.org.44314: 
RADIUS, Access-Accept (2), id: 0x9c length: 48

So, we received an IPv6 packet, but didn't react. Some seconds later IPA-OTP
retried with IPv4 and succeeded.  A quick check showed that freeradius
did not listen on IPv6. After fixing that, a request looks like this:

Dec 20 22:54:57 freeipa2 ipa-otpd: jkell...@jochen.org: request received
Dec 20 22:54:57 freeipa2 ipa-otpd: jkell...@jochen.org: user query start
Dec 20 22:54:57 freeipa2 ipa-otpd: jkell...@jochen.org: user query end: 
uid=jkellner,cn=users,cn=accounts,dc=jochen,dc=org
Dec 20 22:54:57 freeipa2 ipa-otpd: jkell...@jochen.org: radius query start: 
cn=athene,cn=radiusproxy,dc=jochen,dc=org

Re: [Freeipa-users] Valid Sender ? - Re: ipa-otpd: timeout from kerberos when talking to an external 'slow' RADIUS server

[Jochen Hein]

Alexander Bokovoy  writes:

>>1. KDC to ipa-otd: this can be changed in
>>/var/kerberos/krb5kdc/kdc.conf. I think the timeout should be larger
>>then the (largest) second timeout - and I think retries=0 is best.
>>This is for communication between KDC and ipa-otd.
>>
>>2. There is a timeout in each RADIUS server config in IPA for the
>>communication from ipa-otp to external RADIUS servers:
>>`
>>Again I think that for OTPs we are probably best with retries=0.
>>
>>On older clients it might be helpful to add "udp_preference_limit = 0"
>>to /etc/krb5.conf - at least on my Debian/Ubuntu machines.

> Ok. It would probably make sense to file a ticket to FreeIPA tracker to
> get these changes in FreeIPA 4.5.

I think I've won my fight...  Here's what I've learned.  The short story is
that probably no timeout should be changed. Shall I still file a ticket
concerning retry counts?

Authentication of IPA users against RADIUS were mostly failing, but
not always. There were hints about timeouts almost everywhere.
Multiple authentication requests from kerberos, timeouts from sssd,
but that should have sent me on the right track from the start:

Dec 19 22:11:51 freeipa1 ipa-otpd: LDAP: 
ldapi://%2Fvar%2Frun%2Fslapd-JOCHEN-ORG.socket
Dec 19 22:11:51 freeipa1 ipa-otpd: jkell...@jochen.org: request received
Dec 19 22:11:51 freeipa1 ipa-otpd: jkell...@jochen.org: user query start
Dec 19 22:11:51 freeipa1 ipa-otpd: jkell...@jochen.org: user query end: 
uid=jkellner,cn=users,cn=accounts,dc=jochen,dc=org
Dec 19 22:11:51 freeipa1 ipa-otpd: jkell...@jochen.org: radius query start: 
cn=athene,cn=radiusproxy,dc=jochen,dc=org
Dec 19 22:11:51 freeipa1 ipa-otpd: jkell...@jochen.org: radius query end: 
athene.jochen.org
Dec 19 22:11:51 freeipa1 ipa-otpd: jkell...@jochen.org: forward start: 
jkell...@jochen.org / athene.jochen.org
Dec 19 22:12:01 freeipa1 ipa-otpd: jkell...@jochen.org: forward end: Connection 
timed out
Dec 19 22:12:01 freeipa1 ipa-otpd: jkell...@jochen.org: response sent: 
Access-Reject

or:

Dec 20 22:40:23 freeipa1 ipa-otpd: jkell...@jochen.org: request received
Dec 20 22:40:23 freeipa1 ipa-otpd: jkell...@jochen.org: user query start
Dec 20 22:40:23 freeipa1 ipa-otpd: jkell...@jochen.org: user query end: 
uid=jkellner,cn=users,cn=accounts,dc=jochen,dc=org
Dec 20 22:40:23 freeipa1 ipa-otpd: jkell...@jochen.org: radius query start: 
cn=athene,cn=radiusproxy,dc=jochen,dc=org
Dec 20 22:40:23 freeipa1 ipa-otpd: jkell...@jochen.org: radius query end: 
athene.jochen.org
Dec 20 22:40:23 freeipa1 ipa-otpd: jkell...@jochen.org: forward start: 
jkell...@jochen.org / athene.jochen.org
Dec 20 22:40:31 freeipa1 ipa-otpd: jkell...@jochen.org: forward end: 
Access-Accept
Dec 20 22:40:31 freeipa1 ipa-otpd: jkell...@jochen.org: response sent: 
Access-Accept

Why is there such a long delay?  The Log of the RADIUS server has:

Tue Dec 20 22:40:30 2016 : Info: rlm_perl: Config File 
/opt/privacyIDEA/rlm_perl.ini found!
Tue Dec 20 22:40:30 2016 : Info: rlm_perl: Debugging config: true
Tue Dec 20 22:40:30 2016 : Info: rlm_perl: Default URL 
https://athene.jochen.org/validate/check 
Tue Dec 20 22:40:30 2016 : Info: rlm_perl: Looking for config for auth-type Perl
Tue Dec 20 22:40:30 2016 : Info: rlm_perl: Auth-Type: Perl
Tue Dec 20 22:40:30 2016 : Info: rlm_perl: url: 
https://athene.jochen.org/validate/check
Tue Dec 20 22:40:30 2016 : Info: rlm_perl: user sent to privacyidea: 
jkell...@jochen.org
Tue Dec 20 22:40:30 2016 : Info: rlm_perl: realm sent to privacyidea: jochen.org
Tue Dec 20 22:40:30 2016 : Info: rlm_perl: resolver sent to privacyidea: 
Tue Dec 20 22:40:30 2016 : Info: rlm_perl: client sent to privacyidea: 
192.168.30.121
Tue Dec 20 22:40:30 2016 : Info: rlm_perl: state sent to privacyidea: 
Tue Dec 20 22:40:31 2016 : Info: rlm_perl: privacyIDEA access granted
Tue Dec 20 22:40:31 2016 : Info: rlm_perl: return RLM_MODULE_OK

So RADIUS thinks, it got a request a 30 seconds, but why did we wait so long?
I took a tcpdump and saw:

22:40:23.364355 IP6 freeipa1.jochen.org.41198 > athene.jochen.org.radius: 
RADIUS, Access-Request (1), id: 0x10 length: 134
22:40:30.872136 IP freeipa1.jochen.org.44314 > athene.jochen.org.radius: 
RADIUS, Access-Request (1), id: 0x9c length: 134
22:40:31.572217 IP athene.jochen.org.radius > freeipa1.jochen.org.44314: 
RADIUS, Access-Accept (2), id: 0x9c length: 48

So, we received an IPv6 packet, but didn't react. Some seconds later IPA-OTP
retried with IPv4 and succeeded.  A quick check showed that freeradius
did not listen on IPv6. After fixing that, a request looks like this:

Dec 20 22:54:57 freeipa2 ipa-otpd: jkell...@jochen.org: request received
Dec 20 22:54:57 freeipa2 ipa-otpd: jkell...@jochen.org: user query start
Dec 20 22:54:57 freeipa2 ipa-otpd: jkell...@jochen.org: user query end: 
uid=jkellner,cn=users,cn=accounts,dc=jochen,dc=org
Dec 20 22:54:57 freeipa2 ipa-otpd: jkell...@jochen.org: radius query start: 
cn=athene,cn=radiusproxy,dc=jochen,dc=org
Dec 20 22:54:57 

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

[Gady Notrica]

Hello,

Need some help installing replica - FREEIPA on Centos 7. My networking is run, 
DNS is up on the master IPA all ports are opened. But I can't isolate the 
problem. Any help?

-- Error:
The ipa-replica-install command failed, exception: SystemExit: Connection check 
failed!
Please fix your network settings according to error messages above.
If the check results are not valid it can be skipped with --skip-conncheck 
parameter.

-- Command

# ipa-replica-install --setup-dns --setup-ca --no-forwarder 
--ip-address=172.20.10.100 
/var/lib/ipa/replica-info-sys-sec-repl.ipa.domain.com.gpg
Directory Manager (existing master) password:

Run connection check to master
ad...@ipa.domain.com password:
ipa.ipapython.install.cli.install_tool(Replica): ERRORConnection check 
failed!
Please fix your network settings according to error messages above.
If the check results are not valid it can be skipped with --skip-conncheck 
parameter.
ipa.ipapython.install.cli.install_tool(Replica): ERRORThe 
ipa-replica-install command failed. See /var/log/ipareplica-install.log for 
more information


- LOG at /var/log/ipareplica-install.log

2016-12-20T19:14:50Z DEBUG stdout=Check connection from replica to remote 
master ' sys-pri-repl.ipa.domain.com':
   Directory Service: Unsecure port (389): OK
   Directory Service: Secure port (636): OK
   Kerberos KDC: TCP (88): OK
   Kerberos Kpasswd: TCP (464): OK
   HTTP Server: Unsecure port (80): OK
   HTTP Server: Secure port (443): OK

The following list of ports use UDP protocol and would need to be
checked manually:
   Kerberos KDC: UDP (88): SKIPPED
   Kerberos Kpasswd: UDP (464): SKIPPED

Connection from replica to master is OK.
Start listening on required ports for remote master check
Get credentials to log in to remote master

Check RPC connection to remote master
Retrying using SSH...
Check SSH connection to remote master
Could not SSH into remote host. Error output:
OpenSSH_6.6.1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 56: Applying options for *
debug1: Connecting to sys-pri-repl.ipa.domain.com [172.20.10.99] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1
debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x0400
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5-...@openssh.com none
debug1: kex: client->server aes128-ctr hmac-md5-...@openssh.com none
debug1: kex: curve25519-sha...@libssh.org need=16 dh_need=16
debug1: kex: curve25519-sha...@libssh.org need=16 dh_need=16
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 
6r:0e:15:55:dk:17:86:27:53:02:02:89:c7:98:20:11
Warning: Permanently added 'sys-pri-repl.ipa.domain.com,172.20.10.99' 
(ECDSA) to the list of known hosts.
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: 
publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
Connection closed by 172.20.10.99

2016-12-20T19:14:50Z DEBUG stderr=Could not SSH to remote host.

2016-12-20T19:14:50Z DEBUG   File 
"/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in execute
return_value = self.run()
  File "/usr/lib/python2.7/site-packages/ipapython/install/cli.py", line 318, 
in run
cfgr.run()
  File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 308, 
in run
self.validate()
  File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 317, 
in validate
for nothing in self._validator():
  File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 372, 
in __runner
self._handle_exception(exc_info)
  File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 394, 
in _handle_exception
six.reraise(*exc_info)
  File 

Re: [Freeipa-users] Asking for help with crashed freeIPA istance

[Daniel Schimpfoessl]

Thanks for getting back to me.

getcert list | grep expires shows dates years in the future for all
certificates
[image: Inline-Bild 1]

ipactl start --force

Eventually the system started with:
 Forced start, ignoring pki-tomcatd Service, continuing normal
operations.

systemctl status ipa shows: failed

ldapsearch -H ldaps://localhost:636 -D "cn=directory manager" -w password
-b "" -s base
ldapsearch -H ldaps://localhost:636 -D "cn=directory manager" -w
*** -b "" -s base
[image: Inline-Bild 2]

The logs have thousands of lines like it, what am I looking for
specifically?

Daniel


2016-12-20 4:18 GMT-06:00 Florence Blanc-Renaud :

> On 12/19/2016 07:15 PM, Daniel Schimpfoessl wrote:
>
>> Good day and happy holidays,
>>
>> I have been running a freeIPA instance for a few years and been very
>> happy. Recently the certificate expired and I updated it using the
>> documented methods. At first all seemed fine. Added a Nagios monitor for
>> the certificate expiration and restarted the server (single server). I
>> have weekly snapshots, daily backups (using Amanda on the entire disk).
>>
>> One day the services relying on IPA failed to authenticate. Looking at
>> the server the ipa service had stopped. Restarting the service fails.
>> Restoring a few weeks old snapshot does not start either. Resetting the
>> date to a few month back does not work either as httpd fails to start .
>>
>> I am at a loss.
>>
>> Here a few details:
>> # ipa --version
>> VERSION: 4.4.0, API_VERSION: 2.213
>>
>>
>> # /usr/sbin/ipactl start
>> ...
>> out -> Failed to start pki-tomcatd Service
>> /var/log/pki/pki-tomcat/ca/debug -> Could not connect to LDAP server
>> host ipa.myorg.com  port 636 Error
>> netscape.ldap.LDAPException: Authentication failed (48)
>> 2016-12-19T03:02:16Z DEBUG The CA status is: check interrupted due to
>> error: Retrieving CA status failed with status 500
>>
>> Any help would be appreciated as all connected services are now down.
>>
>> Thanks,
>>
>> Daniel
>>
>>
>>
>>
>> Hi Daniel,
>
> more information would be required to understand what is going on. First
> of all, which certificate did you renew? Can you check with
> $ getcert list
> if other certificates also expired?
>
> PKI fails to start and the error seems linked to the SSL connection with
> the LDAP server. You may want to check if the LDAP server is listening on
> the LDAPs port:
> - start the stack with
> $ ipactl start --force
> - check the LDAPs port with
> $ ldapsearch -H ldaps://localhost:636 -D "cn=directory manager" -w
> password -b "" -s base
>
> The communication between PKI and the LDAP server is authenticated with
> the certificate 'subsystemCert cert-pki-ca' located in
> /etc/pki/pki-tomcat/alias, so you may also want to check if it is still
> valid.
> The directory server access logs (in /var/log/dirsrv/slapd-DOMAIN-COM/access)
> would also show the connection with logs similar to:
>
> [...] conn=47 fd=84 slot=84 SSL connection from 10.34.58.150 to
> 10.34.58.150
> [...] conn=47 TLS1.2 128-bit AES; client CN=CA Subsystem,O=DOMAIN.COM;
> issuer CN=Certificate Authority,O=DOMAIN.COM
> [...] conn=47 TLS1.2 client bound as uid=pkidbuser,ou=people,o=ipaca
> [...] conn=47 op=0 BIND dn="" method=sasl version=3 mech=EXTERNAL
> [...] conn=47 op=0 RESULT err=0 tag=97 nentries=0 etime=0
> dn="uid=pkidbuser,ou=people,o=ipaca"
>
>
>
> HTH,
> Flo
>
-- 
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] Failed ipa-client-install with IPA Replica

[Florence Blanc-Renaud]

On 12/16/2016 03:54 PM, Florence Blanc-Renaud wrote:

On 12/15/2016 08:01 PM, beeth beeth wrote:

Hi Flo,

That's a good point! I checked the dirsrv certificate and confirmed
valid(good until later next year).
Since I had no problem to enroll another new IPA client(RHEL7 box
instead of RHEL6) to such replica server, I thought it might not be a
server end issue. However, when I tried to restart the DIRSRV service on
the replica server, I found these messages in the log
file /var/log/dirsrv/slapd-IPA-EXAMPLE-COM/errors:

[15/Dec/2016:13:38:15.891301246 -0500] 389-Directory/1.3.5.10
 B2016.257.1817 starting up
[15/Dec/2016:13:38:15.911777373 -0500] default_mr_indexer_create:
warning - plugin [caseIgnoreIA5Match] does not handle caseExactIA5Match
[15/Dec/2016:13:38:15.926320306 -0500] WARNING: changelog: entry cache
size 2097152 B is less than db size 5488640 B; We recommend to increase
the entry cache size nsslapd-cachememsize.
[15/Dec/2016:13:38:16.132155534 -0500] schema-compat-plugin - scheduled
schema-compat-plugin tree scan in about 5 seconds after the server
startup!
[15/Dec/2016:13:38:16.167896279 -0500] NSACLPlugin - The ACL target
cn=dns,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.173317345 -0500] NSACLPlugin - The ACL target
cn=dns,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.178354342 -0500] NSACLPlugin - The ACL target
cn=keys,cn=sec,cn=dns,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.183579322 -0500] NSACLPlugin - The ACL target
cn=dns,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.188786976 -0500] NSACLPlugin - The ACL target
cn=dns,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.193275650 -0500] NSACLPlugin - The ACL target
cn=groups,cn=compat,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.197580407 -0500] NSACLPlugin - The ACL target
cn=computers,cn=compat,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.201863256 -0500] NSACLPlugin - The ACL target
cn=ng,cn=compat,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.206318629 -0500] NSACLPlugin - The ACL target
ou=sudoers,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.211559100 -0500] NSACLPlugin - The ACL target
cn=users,cn=compat,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.216146819 -0500] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.220786596 -0500] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.225594942 -0500] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.229986749 -0500] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.234518367 -0500] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.238763121 -0500] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.243031116 -0500] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.247507984 -0500] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.252327210 -0500] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.259046910 -0500] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.263856581 -0500] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.269301704 -0500] NSACLPlugin - The ACL target
cn=ad,cn=etc,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.283511408 -0500] NSACLPlugin - The ACL target
cn=casigningcert
cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=ipa,dc=example,dc=com does
not exist
[15/Dec/2016:13:38:16.287853825 -0500] NSACLPlugin - The ACL target
cn=casigningcert
cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=ipa,dc=example,dc=com does
not exist
[15/Dec/2016:13:38:16.395872649 -0500] NSACLPlugin - The ACL target
cn=automember rebuild membership,cn=tasks,cn=config does not exist
[15/Dec/2016:13:38:16.405404114 -0500] Skipping CoS Definition
cn=Password Policy,cn=accounts,dc=ipa,dc=example,dc=com--no CoS
Templates found, which should be added before the CoS Definition.
[15/Dec/2016:13:38:16.463117873 -0500] set_krb5_creds - Could not get
initial credentials for principal
[ldap/ipaprd2.example@ipa.example.com
] in keytab
[FILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error (see e-text))
[15/Dec/2016:13:38:16.471256279 -0500] schema-compat-plugin -
schema-compat-plugin tree scan will start in about 5 seconds!
[15/Dec/2016:13:38:16.479213976 -0500] slapd started.  Listening on All
Interfaces port 389 for LDAP requests

Re: [Freeipa-users] ipa-dnskeysyncd ipa : ERROR Login to LDAP server failed: {'desc': 'Invalid credentials'}

[Brian J. Murrell]

On Tue, 2016-12-20 at 11:55 +0100, Martin Basti wrote:
> 
> So there are actually no issues with credentials, it needs more 
> debugging, in past we have similar case but we haven't found the
> root 
> cause why it doesn't have the right credentials after kinit.

So, to be clear, all I did was kinit.  I didn't do anything after that
once the credentials were acquired. Should I have or did you just want
me to test that credential file was usable?  I did that as root. 
Here's the permissions on that keytab just in case there is a problem
there:

# ls -lZ /etc/ipa/dnssec/ipa-dnskeysyncd.keytab
-r--r-. root ods unconfined_u:object_r:etc_t:s0   
/etc/ipa/dnssec/ipa-dnskeysyncd.keytab

restorecon says that the selinux labels are ok.  The file is not in the
RPM (i.e. as a config file) so I have no reference for the permissions
of it.

> Are you 
> willing to do more basic level code debugging?

Absolutely.

> BTW this is used only with DNSSEC feature. I you don't use DNSSEC 
> signing you can ignore this failing service (ipactl start 
> --ignore-service-failures)

Let's also not lose sight of the other problem that occurred at the
same upgrade and that's the having to fall back to simple
authentication of bind with:

    arg "auth_method simple";
    arg "bind_dn uid=admin,cn=users,cn=accounts,dc=example.com";
    arg "password my_password";

in /etc/named.conf due to:

21:12:19 LDAP error: Invalid credentials: bind to LDAP server failed

trying to start bind via systemctl start ipa.

Is it most likely that these two problems are in fact not related?

Cheers,
b.


signature.asc
Description: This is a digitally signed message part
-- 
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] Sudo rule implementation

[Jakub Hrozek]

On Tue, Dec 20, 2016 at 01:19:15PM +0300, Ben .T.George wrote:
> Hi List,
> 
> please help me to implement sudo rules.
> 
> i have did below steps and still not working for me.
> 
> 1. created "Sudo Command Groups"
> 2. Added some command (/bin/yum) and included in sudo group
> 3. created "sudo Rule" on that
> * added sudo Option as "!authenticate"
>   * Added User Group.
>   * Added one Host
>   * And under Run command, selected the Sudo Rule Group.
> 4. entry on nsswitch.conf : sudoers: files sss
> 5. entry on sssd.conf : services = nss, sudo, pam, ssh
> 
> and i tried removing "!authenticate" and changed to Anyone, Any Host and Any
> Command,
> Also under As Whom to Anyone and Any Group
> - I tried logout and login again on client with IPA user which is member of
> user group.
> 
> When i am running yum, getting error that user is not allowed to execute
> command.
> 
> 
> Please anyone help to correct my steps.
> 
> Regards
> Ben

Please follow:
https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO
especially the sudo logs are often helpful to see what rules is sssd
returning to sudo.

-- 
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] FreeIPA User Authorization Guidelines Required

[Petr Vobornik]

On 12/20/2016 10:58 AM, nirajkumar.si...@accenture.com wrote:
> Hi FreeIPA Team,
> 
> We have performed installation of FreeIPA Master Server and Client Server. We 
> are successful with user creation with home directory and sudo configuration.
> 
> Regarding Authentication we have some questions:
> 
> 1.Can we implement authorized key authentication for these servers. Is there 
> any 
> way in FreeIPA we can automate the ppk key generation for each individual 
> user?

FreeIPA/IdM supports central management of public SSH keys:
 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/user-keys.html

> 
> 2.If Not Automated key generation what are the possible ways for more secured 
> authentication other than password authentication?

It supports Two Factor Authentication via integrated OTP support or
third party RADIUS server:

OTP:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/otp.html

RADIUS proxy:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/otp.html#migrating-proprietary-otp

> 
> Thanks and Regards,
> 
> Niraj Kumar Singh
> 
> Mobile: +91-9663212985
> 
> Email: nirajkumar.si...@accenture.com 
> 
> 
> 
> 
> This message is for the designated recipient only and may contain privileged, 
> proprietary, or otherwise confidential information. If you have received it 
> in 
> error, please notify the sender immediately and delete the original. Any 
> other 
> use of the e-mail by you is prohibited. Where allowed by local law, 
> electronic 
> communications with Accenture and its affiliates, including e-mail and 
> instant 
> messaging (including content), may be scanned by our systems for the purposes 
> of 
> information security and assessment of internal compliance with Accenture 
> policy.
> __
> 
> www.accenture.com
> 
> 
> 


-- 
Petr Vobornik

-- 
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] ipa-dnskeysyncd ipa : ERROR Login to LDAP server failed: {'desc': 'Invalid credentials'}

[Martin Basti]

On 19.12.2016 21:24, Brian J. Murrell wrote:

On Mon, 2016-12-19 at 17:26 +0100, Martin Basti wrote:

On 19.12.2016 13:19, Brian J. Murrell wrote:

On Mon, 2016-12-19 at 09:42 +0100, Martin Basti wrote:

Hello,

could you recheck with SElinux in permissive mode?

Yeah, still happens even after doing:

# setenforce 0

Cheers,
b.

could you please kinit as service?


kinit -kt /etc/ipa/dnssec/ipa-dnskeysyncd.keytab ipa-
dnskeysyncd/$(hostname)

# kinit -kt /etc/ipa/dnssec/ipa-dnskeysyncd.keytab 
ipa-dnskeysyncd/server.example.com
# klist
Ticket cache: KEYRING:persistent:0:0
Default principal: ipa-dnskeysyncd/server.example@example.com

Valid starting ExpiresService principal
19/12/16 15:20:20  20/12/16 15:20:20  krbtgt/example@example.com

Seems to have worked.  FWIW, I was not asked for any password.

Cheers,
b.




The password is the keytab file

So there are actually no issues with credentials, it needs more 
debugging, in past we have similar case but we haven't found the root 
cause why it doesn't have the right credentials after kinit. Are you 
willing to do more basic level code debugging?


BTW this is used only with DNSSEC feature. I you don't use DNSSEC 
signing you can ignore this failing service (ipactl start 
--ignore-service-failures)


Martin
-- 
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] Asking for help with crashed freeIPA istance

[Florence Blanc-Renaud]

On 12/19/2016 07:15 PM, Daniel Schimpfoessl wrote:

Good day and happy holidays,

I have been running a freeIPA instance for a few years and been very
happy. Recently the certificate expired and I updated it using the
documented methods. At first all seemed fine. Added a Nagios monitor for
the certificate expiration and restarted the server (single server). I
have weekly snapshots, daily backups (using Amanda on the entire disk).

One day the services relying on IPA failed to authenticate. Looking at
the server the ipa service had stopped. Restarting the service fails.
Restoring a few weeks old snapshot does not start either. Resetting the
date to a few month back does not work either as httpd fails to start .

I am at a loss.

Here a few details:
# ipa --version
VERSION: 4.4.0, API_VERSION: 2.213


# /usr/sbin/ipactl start
...
out -> Failed to start pki-tomcatd Service
/var/log/pki/pki-tomcat/ca/debug -> Could not connect to LDAP server
host ipa.myorg.com  port 636 Error
netscape.ldap.LDAPException: Authentication failed (48)
2016-12-19T03:02:16Z DEBUG The CA status is: check interrupted due to
error: Retrieving CA status failed with status 500

Any help would be appreciated as all connected services are now down.

Thanks,

Daniel





Hi Daniel,

more information would be required to understand what is going on. First 
of all, which certificate did you renew? Can you check with

$ getcert list
if other certificates also expired?

PKI fails to start and the error seems linked to the SSL connection with 
the LDAP server. You may want to check if the LDAP server is listening 
on the LDAPs port:

- start the stack with
$ ipactl start --force
- check the LDAPs port with
$ ldapsearch -H ldaps://localhost:636 -D "cn=directory manager" -w 
password -b "" -s base


The communication between PKI and the LDAP server is authenticated with 
the certificate 'subsystemCert cert-pki-ca' located in 
/etc/pki/pki-tomcat/alias, so you may also want to check if it is still 
valid.
The directory server access logs (in 
/var/log/dirsrv/slapd-DOMAIN-COM/access) would also show the connection 
with logs similar to:


[...] conn=47 fd=84 slot=84 SSL connection from 10.34.58.150 to 10.34.58.150
[...] conn=47 TLS1.2 128-bit AES; client CN=CA Subsystem,O=DOMAIN.COM; 
issuer CN=Certificate Authority,O=DOMAIN.COM

[...] conn=47 TLS1.2 client bound as uid=pkidbuser,ou=people,o=ipaca
[...] conn=47 op=0 BIND dn="" method=sasl version=3 mech=EXTERNAL
[...] conn=47 op=0 RESULT err=0 tag=97 nentries=0 etime=0 
dn="uid=pkidbuser,ou=people,o=ipaca"




HTH,
Flo

--
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] Sudo rule implementation

[Ben .T.George]

Hi List,

please help me to implement sudo rules.

i have did below steps and still not working for me.

1. created "Sudo Command Groups"
2. Added some command (/bin/yum) and included in sudo group
3. created "sudo Rule" on that
* added sudo Option as "!authenticate"
  * Added User Group.
  * Added one Host
  * And under Run command, selected the Sudo Rule Group.
4. entry on nsswitch.conf : sudoers: files sss
5. entry on sssd.conf : services = nss, sudo, pam, ssh

and i tried removing "!authenticate" and changed to Anyone, Any Host and Any
Command,
Also under As Whom to Anyone and Any Group
- I tried logout and login again on client with IPA user which is member of
user group.

When i am running yum, getting error that user is not allowed to execute
command.


Please anyone help to correct my steps.

Regards
Ben
-- 
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] FreeIPA User Authorization Guidelines Required

[nirajkumar.singh]

Hi FreeIPA Team,

We have performed installation of FreeIPA Master Server and Client Server. We 
are successful with user creation with home directory and sudo configuration.

Regarding Authentication we have some questions:


1.   Can we implement authorized key authentication for these servers. Is 
there any way in FreeIPA we can automate the ppk key generation for each 
individual user?

2.   If Not Automated key generation what are the possible ways for more 
secured authentication other than password authentication?



Thanks and Regards,
Niraj Kumar Singh
Mobile: +91-9663212985
Email: nirajkumar.si...@accenture.com






This message is for the designated recipient only and may contain privileged, 
proprietary, or otherwise confidential information. If you have received it in 
error, please notify the sender immediately and delete the original. Any other 
use of the e-mail by you is prohibited. Where allowed by local law, electronic 
communications with Accenture and its affiliates, including e-mail and instant 
messaging (including content), may be scanned by our systems for the purposes 
of information security and assessment of internal compliance with Accenture 
policy.
__

www.accenture.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] Add text to web login page

[Pavel Vomacka]

Hello Mike,

the safest way is to create a WebUI plugin.

Several examples of plugins can be found here: 
https://pvoborni.fedorapeople.org/plugins/ . I recommend to look at 
loginauth. And here is documentation about plugins: 
https://pvoborni.fedorapeople.org/doc/#!/guide/Plugins



On 12/16/2016 07:54 PM, Mike Waite wrote:

I need to add a login banner to the login page for freeIPA, is there a
setting that I could easily change for this?

Thanks,
--
Mike Waite




--
Pavel^3 Vomacka

-- 
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] Asking for help with crashed freeIPA istance

[Daniel Schimpfoessl]

Good day and happy holidays,

I have been running a freeIPA instance for a few years and been very happy.
Recently the certificate expired and I updated it using the documented
methods. At first all seemed fine. Added a Nagios monitor for the
certificate expiration and restarted the server (single server). I have
weekly snapshots, daily backups (using Amanda on the entire disk).

One day the services relying on IPA failed to authenticate. Looking at the
server the ipa service had stopped. Restarting the service fails. Restoring
a few weeks old snapshot does not start either. Resetting the date to a few
month back does not work either as httpd fails to start .

I am at a loss.

Here a few details:
# ipa --version
VERSION: 4.4.0, API_VERSION: 2.213


# /usr/sbin/ipactl start
...
out -> Failed to start pki-tomcatd Service
/var/log/pki/pki-tomcat/ca/debug -> Could not connect to LDAP server host
ipa.myorg.com port 636 Error netscape.ldap.LDAPException: Authentication
failed (48)
2016-12-19T03:02:16Z DEBUG The CA status is: check interrupted due to
error: Retrieving CA status failed with status 500

Any help would be appreciated as all connected services are now down.

Thanks,

Daniel
-- 
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] Still unclear about relation between IPA DNS domain and company DNS domain.

[Petr Spacek]

On 8.12.2016 10:12, Pieter Nagel wrote:
> On Thu, Dec 8, 2016 at 10:59 AM, Alexander Bokovoy 
> wrote:
> 
>> It is really simply: your DNS domain named as your Kerberos realm must
>> be under your control, one way or another, to allow automatic discovery
>> of resources to work.
>>
> 
> Thanks, this explanation makes it crystal clear. This exact phrasing would
> have made the docs much clearer too, IMO.
> 
> Setting the realm to the DNS domain that the FreeIPA internal DNS server
> serves is just one simple out-of-the box way to get DNS domain named as
> your Kerberos realm that is under your control, in other words.

I've tried to clarify things in man pages and on web as well. Please have a
look to changes and let us know if it is better or not, and preferably what
can be improved and in which way

The modified deployment page is here:
http://www.freeipa.org/page/Deployment_Recommendations

Man page changes and changes in description of installer options are here:
https://github.com/freeipa/freeipa/pull/352

-- 
Petr^2 Spacek

-- 
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