[Freeipa-users] Cannot start freeipa after reboot of server

2016-02-05 Thread Fujisan
Hello,

I have a big problem here
I have rebooted my freeipa server and noticed that no login screen appeared
after the reboot making it impossible to log in, even through an ssh
session from my desktop.
I also rebooted the replica and got the same problem.

I rebooted again the replica in rescue mode and tried to start freeipa
manually:

# systemctl restart ipa.service
Error getting authority: Error initializing authority: could not connect:
No such file or directory
Welcome to emergency mode! After logging in, type 'journalctl -xb' to view
system logs. ...
Try again to boot into default mode.
Give root password for maintenance
(or press Control-D to continue)

# systemctl status ipa.service
...
... active: Inactive (dead)
... Stopped Identity, Policy, Audit.

freeipa version is 4.2.3-2 .

What can I do to fix this?

Thank you

Fuji
-- 
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 4.2: pki-tomcatd in terrible shape

2016-02-05 Thread Rob Crittenden

Timothy Geier wrote:

Greetings all,

For the record,this is a CentOS 7.2 box with all current patches. 
(ipa-server-4.2.0-15.el7.centos.3.x86_64, etc.)

The situation is that pki-tomcatd on the lone CA server in our IPA cluster 
refuses to start cleanly.  The issues started earlier this week after the certs
subsystemCert, ocspSigningCert, and auditSigningCert all simultaneously expired 
without warning; apparently, certmonger failed to renew them automatically.  We
attempted timeshifting and following instructions for what appeared to be 
similar issues, but nothing at all has worked.

Today, we attempted removing the certificates in question (of course, the files in 
/etc/pki/pki-tomcat/alias were backed up beforehand) and using certutil to issue new  
certificates.   This process worked but pki-tomcatd is still refusing to start.  We can 
get IPA to run on this server by manually starting pki-tomcatd, running ipactl start, and 
then ctrl-c’ing it when it gets to "Starting pki-tomcatd" but this is not a 
tenable long-term solution.

Relevant log entries/information:

/var/log/pki/pki-tomcat/ca/debug:
Could not connect to LDAP server host ipa01.X.net port 636 Error 
netscape.ldap.LDAPException: IO Error creating JSS SSL Socket (-1)
Internal Database Error encountered: Could not connect to LDAP server host 
ipa01.X.net port 636 Error netscape.ldap.LDAPException: IO Error 
creating JSS SSL Socket (-1)
Internal Database Error encountered: Could not connect to LDAP server host 
ipa01.X.net port 636 Error netscape.ldap.LDAPException: Authentication 
failed (49)

/var/log/pki/pki-tomcat/localhost.2016-02-04.log:
org.apache.catalina.core.StandardContext loadOnStartup
SEVERE: Servlet /ca threw load() exception
java.lang.NullPointerException

# getcert list:

Number of certificates and requests being tracked: 8.
Request ID '20151015022737':
status: MONITORING
ca-error: Error setting up ccache for "host" service on client using 
default keytab: Generic error (see e-text).
stuck: no
key pair storage: 
type=NSSDB,location='/etc/dirsrv/slapd-X-NET',nickname='Server-Cert',token='NSS
 Certificate DB',pinfile='/etc/dirsrv/slapd-X-NET/pwdfile.txt'
expires: 2017-10-15 02:09:06 UTC
track: yes
auto-renew: yes
Request ID '20151015022949':
status: MONITORING
ca-error: Error setting up ccache for "host" service on client using 
default keytab: Generic error (see e-text).
stuck: no
key pair storage: 
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS 
Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
certificate: 
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS 
Certificate DB'
expires: 2017-10-15 02:09:10 UTC
track: yes
auto-renew: yes
Request ID '20160127202548':
status: MONITORING
stuck: no
key pair storage: 
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert 
cert-pki-ca',token='NSS Certificate DB',pin set
certificate: 
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert 
cert-pki-ca',token='NSS Certificate DB'
expires: 2034-02-11 19:46:43 UTC
track: yes
auto-renew: yes
Request ID '20160127202549':
status: MONITORING
stuck: no
key pair storage: 
type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS 
Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
certificate: 
type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS 
Certificate DB'
expires: 2017-12-25 04:27:49 UTC
key usage: 
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
track: yes
auto-renew: yes
Request ID '20160127202550':
status: MONITORING
ca-error: Server at 
"http://ipa01.X.net:8080/ca/ee/ca/profileSubmit; replied: Profile 
caServerCert Not Found
stuck: no
key pair storage: 
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert 
cert-pki-ca',token='NSS Certificate DB',pin set
certificate: 
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert 
cert-pki-ca',token='NSS Certificate DB'
expires: 2017-10-04 02:28:53 UTC
track: yes
auto-renew: yes
Request ID '20160204165453':
status: MONITORING
stuck: no
key pair storage: 
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert 
cert-pki-ca',token='NSS Certificate DB',pin set
certificate: 
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert 
cert-pki-ca',token='NSS Certificate DB'
expires: 2016-05-04 16:40:23 UTC
track: yes
auto-renew: yes
Request ID '20160204170246':
status: MONITORING
stuck: no
key pair storage: 

Re: [Freeipa-users] Sudo privilege inheritance in FreeIPA (3.0.x branch)

2016-02-05 Thread Jakub Hrozek
On Thu, Feb 04, 2016 at 11:39:07AM -0700, sysadmin ofdoom wrote:
> Note: sudo rule "testSudo" fails when using user group. But succeeds
> when using a directly defined user.
> sudo rule "sudo-1" fails when user defined directly, but hosts are
> defined with host group.
> 
> The behaviour that I'm observing is: sudo rules are not functioning any
> time the user or host are not defined directly in the sudo rule. And yes I
> have set the nisdomainname.

Please follow:
https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO

Especially the sudo log would be helpful in this case I guess.

-- 
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-users] Configuring Automount on Ubuntu Clients

2016-02-05 Thread Rob Crittenden

Jon wrote:

Hello,

How do I configure automount for Ubuntu 14.04 clients?  My procedure on
CentOS has been: install free-ipa client, run ipa-client-install (auto
configures with dns discovery), run ipa-client-automount.  However, when
I run this on the ubuntu client, I receive the following errors:

 >> root@ubuntu-1404-x8664:~# ipa-client-automount -U
 >> Searching for IPA server...
 >> IPA server: DNS discovery
 >> Location: default
 >> Configured /etc/nsswitch.conf
 >> Configured /etc/default/nfs-common
 >> Configured /etc/idmapd.conf
 >> rpcidmapd failed to restart: Command '/usr/sbin/service rpcidmapd
restart ' returned non-zero exit status 1
 >> rpcgssd failed to restart: Command '/usr/sbin/service rpcgssd
restart ' returned non-zero exit status 1

As these are not the names of these services on Ubuntu, this will never
work.

 >> root@ubuntu-1404-x8664:~# service idmapd restart
 >> idmapd stop/waiting
 >> idmapd start/running, process 428
 >> root@ubuntu-1404-x8664:~# service gssd restart
 >> stop: Unknown instance:
 >> gssd start/running, process 567

Unfortunately, this appears to be hardcoded values in the install script:

 >> 290 if statestore.has_state('rpcidmapd'):
 >> 291 enabled = statestore.restore_state('rpcidmapd',
'enabled')
 >> 292 running = statestore.restore_state('rpcidmapd',
'running')
 >> 293 rpcidmapd = ipaservices.knownservices.rpcidmapd
 >> 294 if not enabled:
 >> 295 rpcidmapd.disable()
 >> 296 if not running:
 >> 297 rpcidmapd.stop()
 >> 298 if statestore.has_state('rpcgssd'):
 >> 299 enabled = statestore.restore_state('rpcgssd', 'enabled')
 >> 300 running = statestore.restore_state('rpcgssd', 'running')
 >> 301 rpcgssd = ipaservices.knownservices.rpcgssd

Is Ubuntu not supported with FreeIPA?  Is there an updated install
script?  I installed the freeipa-client from public repos.


One guy volunteers his time porting IPA to Ubuntu. He has invested a 
fair bit of time in generalizing other hardcoded elements in IPA. It's 
possible he hasn't gotten to ipa-client-automount yet or it hasn't been 
pushed out in a build yet.


rob

--
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] OS migration from Fedora to CentOS?

2016-02-05 Thread Petr Vobornik

On 02/04/2016 06:14 PM, Christophe TREFOIS wrote:

Hi all,

We are currently running a 3-replica (all are setup with the —setup-ca flag) 
cluster on Fedora 21, with FreeIPA 4.1.4.

We would like to slowly upgrade to the new version and move away from Fedora to 
CentOS 7.2.

We were thinking of the following:

- Create 3 CentOS machines with —setup-ca flag so that our current cluster is 6.
The first CentOS VM would then probably update the DB schema to the new FreeIPA 
version.
- Remove the Fedora VMs 1 by 1 from the cluster using ipa-replica-manage del 

- Be happy?


1. Could you please advise if this is considered the safest practise?


More or less yes:

1. create First IPA 4.2 against some FreeIPA 4.1.4 with CA
2. create the other two against the newly Created CentOS - will verify 
if it is in a good shape
3. set new renewal CRL master: 
http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master

4. Migrate DNA ranges using ipa-replica-manage tool

if all works well, remove all servers:

5. remove CA repl. agreements for old servers using ipa-csreplica-manage del
6. remove old servers data and repl. agreements using ipa-replica-manage del
7. uninstall old servers using ipa-server-install --uninstall


2. Do we have to update to intermediate versions and if so how?


Should not be necessary.



Could we do anything else?

Thank you for any hints,

Kind regards,

—
Christophe






--
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] [freeipa-users] How to manage Linux attributes for AD users (e.g. how do I set a shell for an AD User)

2016-02-05 Thread Jakub Hrozek
On Thu, Feb 04, 2016 at 01:57:20PM -0600, Jon wrote:
> Hi Josh,
> 
> I think that's exactly the problem though, how does one set POSIX
> attributes in AD from Linux guests?
> 
> The RedHat documentation has a big warning that the Microsoft IDMU has been
> deprecated.

IIRC the UI is, the schema is not.

> 
> >>
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/ex.sssd-ad-posix.html
> 
> Surely you're not suggesting manually editing the AD Schema...?
> 
> Also, another use case is ssh keys.  I'm not even sure that IDMU has an
> option for "authorized_keys"  (and FreeIPA doesn't seem to honor what's in
> .ssh/authorized keys...  when that file exists I always get prompted for a
> password then access denied).

For per-AD-user ssh pubkeys, you can use the idviews feature:
ipa idoverrideuser-add --sshpubkey=STR
see:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/id-views.html
same for shells, although as Josh said, shells can be set globally for
all users in sssd.conf

> 
> I'm sure there are other per-user level attributes that are required, home
> directory perhaps?, but the two big ones are shell and ssh keys.  I can't
> be the only one who has a use case for managing these attributes for Active
> Directory users.
> 
> Thanks,
> Jon A
> 
> On Thu, Feb 4, 2016 at 1:30 PM, Baird, Josh  wrote:
> 
> > For AD users, I believe you have two options.
> >
> >
> >
> > 1) Set the POSIX value on the user in AD for the shell
> >
> > 2) Set the following in your client's sssd.conf:
> >
> >
> >
> > [nss]
> >
> > override_shell = /bin/bash
> >
> >
> >
> > This would obviously be global per IPA client.
> >
> >
> >
> > Josh
> >
> >
> >
> > *From:* freeipa-users-boun...@redhat.com [mailto:
> > freeipa-users-boun...@redhat.com] *On Behalf Of *Jon
> > *Sent:* Thursday, February 04, 2016 2:25 PM
> > *To:* freeipa-users@redhat.com
> > *Subject:* [Freeipa-users] [freeipa-users] How to manage Linux attributes
> > for AD users (e.g. how do I set a shell for an AD User)
> >
> >
> >
> > Hello,
> >
> >
> >
> > How does one manage linux attributes for AD users.  Primarily in my case,
> > I'm looking to change the default shell to either Bash or KSH depending on
> > the user.
> >
> >
> >
> > I can create a .profile that either sources bash or ksh rcs... e.g.:
> >
> >
> >
> > >> $ cat ~/.profile
> >
> > >> bash ./.bashrc
> >
> >
> >
> > This is really less than ideal and just seems like the wrong way to do it,
> > especially considering we have a tool like FreeIPA.
> >
> >
> >
> > According to Microsoft
> > ,
> > they are no longer supporting Identity Management for Unix.  Does FreeIPA
> > honor the attributes set by IDMU?  Even if it's deprecated, I suppose we
> > could continue to use it...
> >
> > This previous FreeIPA thread
> >  
> > seems
> > to indicate you can force the shell for anyone in the domain logging into
> > that machine, but we have some users who prefer one shell over the other.
> >
> >
> >
> > I did what I believe to be standard, I created a security group in AD,
> > added that group to a group an external group in FreeIPA, then made an
> > internal group and added the external group as a member to the internal
> > group.  Unfortunately, this doesn't seem to expose any of the AD attributes
> > for management.  Or maybe I'm just misunderstanding...
> >
> >
> >
> > Any thoughts?  How are you managing individual AD user settings?
> >
> >
> >
> > Thanks,
> >
> > Jon A
> >
> >
> >

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

2016-02-05 Thread Alan P
Thanks jhrozek, I have already seen it and applied to my IPA server, but it 
didn't have any significant impact, at least for AD users. In krb5kdc log, when 
I try to login with an IPA user in Windows, I can see the next:

Feb 05 17:52:12 master.ipa.ad.example.com krb5kdc[14081](info): AS_REQ (6 
etypes {18 17 23 24 -135 3}) 172.19.21.37: NEEDED_PREAUTH: 
ipa.u...@ipa.ad.example.com for krbtgt/ipa.ad.example@ipa.ad.example.com, 
Additional pre-authentication required
Feb 05 17:52:12 master.ipa.ad.example.com krb5kdc[14081](info): closing down fd 
12
Feb 05 17:52:12 master.ipa.ad.example.com krb5kdc[14081](info): AS_REQ (6 
etypes {18 17 23 24 -135 3}) 172.19.21.37: ISSUE: authtime 1454716332, etypes 
{rep=18 tkt=18 ses=18}, ipa.u...@ipa.ad.example.com for 
krbtgt/ipa.ad.example@ipa.ad.example.com
Feb 05 17:52:12 master.ipa.ad.example.com krb5kdc[14081](info): closing down fd 
12
Feb 05 17:52:12 master.ipa.ad.example.com krb5kdc[14081](info): TGS_REQ (5 
etypes {18 17 23 24 -135}) 172.19.21.37: ISSUE: authtime 1454716332, etypes 
{rep=18 tkt=18 ses=18}, ipa.u...@ipa.ad.example.com for 
krbtgt/ad.example@ipa.ad.example.com
Feb 05 17:52:12 master.ipa.ad.example.com krb5kdc[14081](info): closing down fd 
12
Feb 05 17:58:45 master.ipa.ad.example.com krb5kdc[14081](info): TGS_REQ (5 
etypes {18 17 23 24 -135}) 172.19.21.37: ISSUE: authtime 1454716332, etypes 
{rep=18 tkt=18 ses=18}, ipa.u...@ipa.ad.example.com for 
cifs/master.ipa.ad.example@ipa.ad.example.com
Feb 05 17:58:45 master.ipa.ad.example.com krb5kdc[14081](info): closing down fd 
12
Feb 05 17:58:47 master.ipa.ad.example.com krb5kdc[14081](info): TGS_REQ (5 
etypes {18 17 23 24 -135}) 172.19.21.37: LOOKING_UP_SERVER: authtime 0,  
ipa.u...@ipa.ad.example.com for 
ProtectedStorage/master.ipa.ad.example@ipa.ad.example.com, Server not found 
in Kerberos database
Feb 05 17:58:47 master.ipa.ad.example.com krb5kdc[14081](info): closing down fd 
12


In Windows, I can't find something related.

Any other suggestion?


> Date: Fri, 5 Feb 2016 09:33:25 +0100
> From: jhro...@redhat.com
> To: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] IPA-AD Login
> 
> On Thu, Feb 04, 2016 at 01:15:17PM -0600, Alan P wrote:
> > Hi, 
> > 
> > I just configured a trust between an IPA and an Active Directory to 
> > authenticate IPA users in Windows machines joined in AD domain. The login 
> > is successfull, but only after several minutes (nearly 25 minutes) in the 
> > first attempt; in the next attempts, the required time goes from 5 to 10 
> > min. So, what can I do to reduce the time to something more acceptable? 
> > (For reference, when an AD user authenticates it only takes 10 seconds or 
> > less).
> > 
> > My environment is:
> > 
> > IPA server 4.2.0-15 in a RHEL 7.2
> > IPA domain is a subdomain of AD (like ad.example.com and ipa.ad.example.com)
> > There are, right now, a few users but is planed to manage more than 10,000
> > The trust was configured as "two way"
> > 
> > AD is in a Windows Server 2012
> > It has the root domain
> > I  made a domain delegation, so AD is authoritative for ad.example.com and 
> > IPA, for ipa.ad.example.com
> > All windows client machines are joined here
> > There are a few users, but they are only for test purposes
> > 
> > The authentication in a windows client is:
> > user: IPA.AD.EXAMPLE.COM\ipa.user
> > pass: ipa user pass
> > 
> > >From IPA console I can make kinit user...@ad.example.com with no problem.
> 
> Please see:
> 
> https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-ipa-ad-trust-deployments/
> 
> We're working on sssd performance fixes for the next version (1.14, will
> be in RHEL-7.3)
> 
> -- 
> 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