date:20150319


On 03/19/2015 05:04 PM, Roberto Cornacchia wrote:

Yes.

[root@meson ~]# cat /etc/resolv.conf
search hq.example.com http://hq.example.com
nameserver 192.168.0.72

Sorry from the short log I posted it's not visible, but that ip 
address is the address of the ipa server (ipa.hq.example.com 
http://ipa.hq.example.com)


[root@meson ~]# dig ipa.hq.spinque.com http://ipa.hq.spinque.com

;  DiG 9.9.6-P1-RedHat-9.9.6-8.P1.fc21  ipa.hq.example.com 
http://ipa.hq.example.com

;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 53238
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ipa.hq.example.com.INA

;; ANSWER SECTION:
ipa.hq.example.com. 1200INA192.168.0.72

;; AUTHORITY SECTION:
hq.example.com.86400INNSipa.hq.example.com.

;; Query time: 1 msec
;; SERVER: 192.168.0.72#53(192.168.0.72)
;; WHEN: do mrt 19 22:02:04 CET 2015
;; MSG SIZE  rcvd: 83



OK so you can in fact lookup the server.
Have you opened all required ports for ldap and kerberos and other 
protocols in the firewall both UDP and TCP?





On 19 March 2015 at 21:55, Dmitri Pal d...@redhat.com 
mailto:d...@redhat.com wrote:


On 03/19/2015 04:46 PM, Roberto Cornacchia wrote:

Hi,

This should really work like a charm, and I'm sure it is a stupid
mistake of mine if it doesn't, but I really can't find out what
goes wrong.

Both IPA server and client are on FC21, very up to date.
Server installation (standard, with dns) worked well. Required
ports open in the firewall. Everything seems to work.

I did try to use the IPA server as a DNS (with forwarders) and
NTP server from non-ipa clients, no problem.
I also tried to use it as LDAP server, from a non-fedora machine
(a synology). It worked well and I could see users.

When trying to enroll a client, the enrollment itself seems to
succeed, but:
- Unable to sync time with NTP server
- Unable to update DNS
- Unable to find users

I include below the short installation log (I changed the real
domain into hq.example.com http://hq.example.com), and in
attachment, the full log with debug on.

From the debug log, about the DNS update failure, I can see this:

  ; Communication with 192.168.0.72#53 failed: operation canceled
  could not reach any name server

I'm not sure what communication problem this could be, as the
server (which is both the IPA and the DNS servers), clearly can
be reached.

Any idea where to look at?


Do you have the IPA DNS server in the resolv.conf of the client?





Thanks,
Roberto


[root@meson ~]# ipa-client-install --mkhomedir --ssh-trust-dns
--force-ntpd --hostname=meson.hq.example.com
http://meson.hq.example.com
Discovery was successful!
Hostname: meson.hq.example.com http://meson.hq.example.com
Realm: HQ.EXAMPLE.COM http://HQ.EXAMPLE.COM
DNS Domain: hq.example.com http://hq.example.com
IPA Server: ipa.hq.example.com http://ipa.hq.example.com
BaseDN: dc=hq,dc=example,dc=com

Continue to configure the system with these values? [no]: yes
Synchronizing time with KDC...
*Unable to sync time with IPA NTP server, assuming the time is in
sync. Please check that 123 UDP port is opened.*
User authorized to enroll computers: admin
Password for ad...@hq.example.com mailto:ad...@hq.example.com:
Successfully retrieved CA cert
Subject: CN=Certificate Authority,O=HQ.EXAMPLE.COM
http://HQ.EXAMPLE.COM
Issuer:  CN=Certificate Authority,O=HQ.EXAMPLE.COM
http://HQ.EXAMPLE.COM
Valid From:  Mon Mar 16 18:44:35 2015 UTC
Valid Until: Fri Mar 16 18:44:35 2035 UTC

Enrolled in IPA realm HQ.EXAMPLE.COM http://HQ.EXAMPLE.COM
Created /etc/ipa/default.conf
New SSSD config will be created
Configured sudoers in /etc/nsswitch.conf
Configured /etc/sssd/sssd.conf
Configured /etc/krb5.conf for IPA realm HQ.EXAMPLE.COM
http://HQ.EXAMPLE.COM
trying https://ipa.hq.example.com/ipa/json
Forwarding 'ping' to json server
'https://ipa.hq.example.com/ipa/json'
Forwarding 'ca_is_enabled' to json server
'https://ipa.hq.example.com/ipa/json'
Systemwide CA database updated.
Added CA certificates to the default NSS database.
Hostname (meson.hq.example.com http://meson.hq.example.com) not
found in DNS
*Failed to update DNS records.*
Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub
Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub
Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub
Forwarding 'host_mod' to json server
'https://ipa.hq.example.com/ipa/json'
*Could not update DNS SSHFP records.*
SSSD enabled
Configured /etc/openldap/ldap.conf
*Unable to find 'admin' user with 'getent passwd
ad...@hq.example.com

Re: [Freeipa-users] Problems with ssh and install-uninstall-install sequence on the server

2015-03-19 Thread Prasun Gera

It's just that /var/lib/sss/db is not cleared between subsequent server
installs and uninstall, and that seems to be creating problems on the
server since the server is also a client. If you do
install-uninstall-install on the server with the same domain name for both
the installs, you cannot authenticate using sssd after the second install.
A simple command like 'ssh admin@localhost' on the server gives permission
denied. I don't know if this is a regression, but it would help if someone
could reproduce this error.

On Thu, Mar 19, 2015 at 4:19 PM, Jakub Hrozek jhro...@redhat.com wrote:


  On 19 Mar 2015, at 20:09, Prasun Gera prasun.g...@gmail.com wrote:
 
  I thought a bit more about the issue of conflicts in /var/lib/sss/db,
 and I think it's a pretty significant problem, probably from a security
 standpoint too. The fact that it's trying to authenticate against something
 stale and incorrect would imply that it might erroneously authenticate
 against something it should not. Also, this problem would lock out all
 clients and be a nightmare to deal with if the master server needs to be
 replaced/migrated.
 

 I'm sorry to come late into this thread, but from the subject it wasn't
 clear it's also about SSSD.

 Can you describe the problem better? How did you manage to create
 conflicts in sssd database?

  On Thu, Mar 19, 2015 at 11:57 AM, Nalin Dahyabhai na...@redhat.com
 wrote:
  On Wed, Mar 18, 2015 at 05:55:52PM -0400, Rob Crittenden wrote:
getcert status
process 31282: arguments to dbus_message_new_method_call() were
incorrect, assertion path != NULL failed in file dbus-message.c
 line 1262.
This is normally a bug in some application using the D-Bus library.
  D-Bus not built with -rdynamic so unable to print a backtrace
Aborted (core dumped)
  
   Please open a bug against certmonger.
 
  I'm pretty sure this one's already being tracked as #1148001.
 
  Cheers,
 
  Nalin
 
  --
  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] AD users not getting single sign on (Solaris)


On 03/19/2015 07:55 PM, nat...@nathanpeters.com wrote:

I have finally gotten all of my Solaris servers to accept AD users but the
behavior is inconsistent.

In my FreeIPA domain, I can login to a Linux server and then ssh to the
Solaris server and I am automatically logged in because of my Kerberos
ticket (I assume).

But when I ssh from the first Solaris machine to the 2nd I am prompted for
a password instead of being automatically signed in.  The strange thing is
that it doesn't matter which machine I login to first, it's only the 2nd
hop that asks for a password.

Below are my console recording.  ipaclient1 is Linux, ipaclient5 and
ipaclient6 are Solaris.
Login from Linux - Solaris 1 works without password
Login from Linux - Solaris 2 works without password
Login from Solaris 1 - Solaris 2 prompts
Login from Solaris 2 - Solaris 1 prompts.


Assuming that you have:
IPA and AD in trust and Solaris boxes are configured against the IPA 
compat tree then it would be the expected behavior.


SSO is possible only with Kerberos.
You authentication on Linux is against AD (through trust) so you get a 
Kerberos ticket.
If you issued keytabs for your Solaris systems and configured SSH to use 
GSSAPI then SSH would provide SSO as you describe from Linux to Solaris.
But once you login into Solaris box you do not have a Kerberos ticket 
because it is an LDAP authentication.


You would ask what can be done about it?
Not much. To have SSO you would need to have one of the latest Kerberos 
versions and something like SSSD on Solaris. It does not exist and 
Oracle is not eager to create one.


Bottom line... move to Linux :-)



Any ideas?

 snip 
login as: nathan.peters
nathan.peters@10.21.19.12's password:
Last login: Thu Mar 19 16:42:27 2015 from 10.5.5.57
[nathan.pet...@datacenter.mydomain.net@ipaclient1-sandbox-atdev-van ~]$ klist
Ticket cache: FILE:/tmp/krb5cc_1539201103_L8tfu1
Default principal: nathan.pet...@datacenter.mydomain.net

Valid starting ExpiresService principal
03/19/15 16:44:27  03/20/15 02:44:16
krbtgt/datacenter.mydomain@datacenter.mydomain.net
 renew until 03/20/15 16:44:27
[nathan.pet...@datacenter.mydomain.net@ipaclient1-sandbox-atdev-van ~]$
ssh ipaclient5-sandbox-atdev-van
Last login: Thu Mar 19 23:43:24 2015 from 10.21.19.12
Oracle Corporation  SunOS 5.10  Generic Patch   January 2005
[11:45 PM] ipaclient5-sandbox-atdev-van:~$ klist
Ticket cache: FILE:/tmp/krb5cc_1539201103
Default principal: nathan.pet...@datacenter.mydomain.net

Valid startingExpiresService principal
03/19/15 23:40:06  03/20/15 09:39:23
krbtgt/datacenter.mydomain@datacenter.mydomain.net
 renew until 03/26/15 23:40:06
[11:45 PM] ipaclient5-sandbox-atdev-van:~$ ssh ipaclient6-sandbox-atdev-van
Password:
Last login: Thu Mar 19 16:40:49 2015 from ipaclient5-sand
Oracle Corporation  SunOS 5.10  Generic Patch   January 2005
-bash-3.00$ klist
klist: No credentials cache file found (ticket cache
FILE:/tmp/krb5cc_1539201103)
-bash-3.00$ exit
logout
Connection to ipaclient6-sandbox-atdev-van closed.
[11:48 PM] ipaclient5-sandbox-atdev-van:~$ exit
logout
Connection to ipaclient5-sandbox-atdev-van closed.
[nathan.pet...@datacenter.mydomain.net@ipaclient1-sandbox-atdev-van ~]$
ssh ipaclient6-sandbox-atdev-van
Last login: Thu Mar 19 16:45:50 2015 from ipaclient5-sand
Oracle Corporation  SunOS 5.10  Generic Patch   January 2005
-bash-3.00$ klist
klist: No credentials cache file found (ticket cache
FILE:/tmp/krb5cc_1539201103)
-bash-3.00$ ssh ipaclient5-sandbox-atdev-van
The authenticity of host 'ipaclient5-sandbox-atdev-van (10.21.19.16)'
can't be established.
RSA key fingerprint is b0:65:8d:c6:82:78:c2:7f:60:16:d0:6a:30:c0:09:a1.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'ipaclient5-sandbox-atdev-van,10.21.19.16'
(RSA) to the list of known hosts.
Password:
Last login: Thu Mar 19 23:45:19 2015 from 10.21.19.12
Oracle Corporation  SunOS 5.10  Generic Patch   January 2005
[11:49 PM] ipaclient5-sandbox-atdev-van:~$






--
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

--
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] Fwd: Re: AD -- FreeIPA Password Sync --- Peer reports incompatible or unsupported protocol

2015-03-19 Thread Gonzalo Fernandez Ordas

I have completed changed the scenario and I managed to install
freeipa-server 4.1 (Somebody publish the right repo for Centos and it
worked really well)

--Let me double check a couple of things. You wrote you installed
PassSync on Windows 2013 (which could be a typo?) We support Windows
Server 2008 R2 and 2012 R2. We also confirmed it works on Windows
Server 2003 R2.

Yes, sorry, that was a typo.

So, starting again from scratch, new machine, the whole installation
process went well, not issues there but:

* FreeIPA is supposed to generate a PassSync user by running
ipa-replica-manage *--winsync **--passsync*=/PASSSYNC_PWD. (See also man
ipa-replica-manage).

I tried 5 times, the user was never created on the ipa server, I had to
create it manually (I gave it admin permissions so it could
create/delete/update users).
Doing that, the password sync worked all right. We submit a password
reset in AD and that propagated all right, tested and it worked fine.

/
* In one scenario I uninstalled freeipa (still kept the packages),
installed again and something went wrong with the kerberos keys.
After creating the AD -- LDAP certs and successfully syncing the
passwords, I could read in the /var/log/messages a password decryption
issue (kerberos related) everytime I tried to log as any user.
I have tried uninstalling freeipa and also uninstalling removing the
product completely and re-installing. it did not matter if I tried to
rebuild the kerberos keys, the issue was always there, so I have to
start afresh with a new box.

So.. that has been all so far

Thanks

Gonzalo

On 16/03/2015 20:05, Noriko Hosoi wrote:

Hello, Gonzalo,

Any progress on your Password Synchronization?

Let me double check a couple of things. You wrote you installed
PassSync on Windows 2013 (which could be a typo?) We support Windows
Server 2008 R2 and 2012 R2. We also confirmed it works on Windows
Server 2003 R2.

On 03/13/2015 12:45 PM,g.fer.or...@unicyber.co.uk wrote:
I got the Password Sync Tool installed in the Windows2013 box
You can find the doc on PassSync here.
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/pass-sync.html#windows-pass-sync
The doc is on PassSync 1.1.5, but 1.1.6 remains intact except the
default SSL version to connect to the 389 Directory Server (as we
discussed before).

We had a dicussion regarding the PassSync user you had to create:
uid=passsync,cn=users,cn=accounts,dc=corp,dc=company,dc=com
FreeIPA is supposed to generate a PassSync user by running
ipa-replica-manage *--winsync **--passsync*=/PASSSYNC_PWD. (See also
man ipa-replica-manage)./

there must some problem as FreeIPA
creates own Passsync user in cn=sysaccounts,cn=etc,SUFFIX also sets it's
DN
as passSyncManagersDNs in ipa_pwd_extop plugin to avoid it creating expired
passwords. So there is no need to create
uid=passsync,cn=users,cn=accounts,dc=corp,dc=company,dc=com manually.
Please see the above doc regarding the user creation.

*
The username of the system user which Active Directory uses to
connect to the IdM machine. This account is configured
automatically when sync is configured on the IdM server. The
default account is
|uid=passsync,cn=sysaccounts,cn=etc,dc=example,dc=com|.
*
The password set in the |--passsync| option when the sync
agreement was created.

I'm sending this response to freeipa-users to share the info and
request for more suggestions.

Thanks,
--noriko

On 03/13/2015 02:48 PM, g.fer.or...@unicyber.co.uk wrote:

I forgot to attach the search command now:
# passsync, users, accounts, corp.company.com
dn: uid=passsync,cn=users,cn=accounts,dc=corp,dc=company,dc=com
cn: passsync
displayName: passsync
krbLastFailedAuth: 20150313211546Z
krbLoginFailedCount: 1
krbExtraData:: AALUUQNVcm9vdC9hZG1pbkBDT1JQLkhPT1RTVUlURU1FRElBLkNPTQA=
memberOf: cn=ipausers,cn=groups,cn=accounts,dc=corp,dc=company,dc=com
krbLastPwdChange: 20150313210836Z
krbPasswordExpiration: 20150611210836Z
mepManagedEntry: cn=passsync,cn=groups,cn=accounts,dc=corp,dc=company,d
c=com
objectClass: top
objectClass: person
objectClass: organizationalperson
objectClass: inetorgperson
objectClass: inetuser
objectClass: posixaccount
objectClass: krbprincipalaux
objectClass: krbticketpolicyaux
objectClass: ipaobject
objectClass: ipasshuser
objectClass: ipaSshGroupOfPubKeys
objectClass: mepOriginEntry
loginShell: /bin/bash
gecos: pass sync
sn: sync
homeDirectory: /home/passsync
uid: passsync
mail: passs...@corp.company.com
krbPrincipalName: passs...@corp.company.com
givenName: pass
initials: ps
userPassword:: z=
=
ipaUniqueID: 1d76b14a-c9c5-11e4-93f4-12d2e19d1e3c
uidNumber: 1481000829
gidNumber: 1481000829
krbPrincipalKey:: dfrerererer

# search result
search: 2

On 2015-03-13 21:39, g.fer.or...@unicyber.co.uk wrote:

I had to manually create the user!! For some reason I thought the sync
Agreement task was also creating that entry

[Freeipa-users] SSSD in redundant configuration

Cool stuff. Thanks.

I had a look at our SRV records and found the following:
_kerberos-master._tcp
_kerberos-master._udp
_kerberos._tcp
_kerberos._udp
_kpasswd._tcp
_kpasswd._udp
_ldap._tcp
_ntp._udp

No mention of and ipa srv records. Does sssd use _ldap._tcp?

Thanks,

Andrew

On 18 March 2015 at 18:11, Rob Crittenden rcrit...@redhat.com
javascript:_e(%7B%7D,'cvml','rcrit...@redhat.com'); wrote:

 Craig White wrote:
  *From:*freeipa-users-boun...@redhat.com
 javascript:_e(%7B%7D,'cvml','freeipa-users-boun...@redhat.com');
  [mailto:freeipa-users-boun...@redhat.com
 javascript:_e(%7B%7D,'cvml','freeipa-users-boun...@redhat.com');] *On
 Behalf Of *Andrew Holway
  *Sent:* Wednesday, March 18, 2015 9:40 AM
  *To:* freeipa-users@redhat.com
 javascript:_e(%7B%7D,'cvml','freeipa-users@redhat.com');
  *Subject:* [Freeipa-users] SSSD in redundant configuration
 
 
 
  Hello,
 
 
 
  Im wondering how we should be handing SSSD for redundant configurations
  on our freeipa clients. We have three freeipa servers; how can we make
  SSSD check another freeipa in the event that one goes down?
 
 
 
  It appears we can do something like the following:
 
 
 
  ipa_hostname = test-freeipa-client-1.cloud.domain.de
  http://test-freeipa-client-1.cloud.domain.de,
  test-freeipa-client-2.cloud.domain.de
  http://test-freeipa-client-2.cloud.domain.de,
  test-freeipa-client-3.cloud.domain.de
  http://test-freeipa-client-3.cloud.domain.de
 
 
 
  However I thought SRV records were meant to supply the magic here?
 
 
 
  Thanks,
 
 
 
  Andrew
 
 
 
 
 
  /etc/sssd/sssd.conf
 
  [domain/cloud.domain.de http://cloud.domain.de]
 
  cache_credentials = True
 
  krb5_store_password_if_offline = True
 
  ipa_domain = cloud.domain.de http://cloud.domain.de
 
  id_provider = ipa
 
  auth_provider = ipa
 
  access_provider = ipa
 
  ipa_hostname = test-freeipa-client-2.cloud.domain.de
  http://test-freeipa-client-2.cloud.domain.de
 
  chpass_provider = ipa
 
  ipa_dyndns_update = True
 
  ipa_server = _srv_, test-freeipa-2.cloud.domain.de
  http://test-freeipa-2.cloud.domain.de
 
  ldap_tls_cacert = /etc/ipa/ca.crt
 
  # For the SUDO integration
 
  sudo_provider = ldap
 
  ldap_uri = ldap://test-freeipa-1.cloud.domain.de
  http://test-freeipa-1.cloud.domain.de
 
  ldap_sudo_search_base = ou=sudoers,dc=cloud,dc=domain,dc=de
 
  ldap_sasl_mech = GSSAPI
 
  ldap_sasl_authid = host/test-freeipa-client-2.cloud.domain.de
  http://test-freeipa-client-2.cloud.domain.de
 
  ldap_sasl_realm = CLOUD.DOMAIN.DE http://CLOUD.DOMAIN.DE
 
  krb5_server = test-freeipa-2.cloud.domain.de
  http://test-freeipa-2.cloud.domain.de
 
  [sssd]
 
  services = nss, pam, ssh, sudo
 
  config_file_version = 2
 
  domains = cloud.domain.de http://cloud.domain.de
 
  [nss]
 
  [pam]
 
  [sudo]
 
  [autofs]
 
  [ssh]
 
  [pac]
 
  I think the magic you are looking for is in /etc/sssd/sssd.conf where
  you have…
 
  ipa_server = _srv_, test-freeipa-2.cloud.domain.de
  http://test-freeipa-2.cloud.domain.de
 
  and all you need is…
 
  ipa_server = _srv_

 _srv_ tells SSSD to check DNS for SRV records. The trailing server gives
 it a hardcoded fallback in case DNS fails for some reason. Their current
 configuration is correct.

 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] SSSD in redundant configuration

On Thu, Mar 19, 2015 at 08:42:42AM +0100, Andrew Holway wrote:
 Cool stuff. Thanks.
 
 I had a look at our SRV records and found the following:
 _kerberos-master._tcp
 _kerberos-master._udp
 _kerberos._tcp
 _kerberos._udp
 _kpasswd._tcp
 _kpasswd._udp
 _ldap._tcp
 _ntp._udp
 
 No mention of and ipa srv records. Does sssd use _ldap._tcp?

Yes, for the IPA back end it does.

For the AD back end we use the special MS records for looking up sites
or Global Catalog servers, but for IPA we stick to the standard
services.

-- 
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] Synology DSM5 and freeIPA

On 6 March 2015 at 11:15, Martin Kosek mko...@redhat.com wrote:

On 03/06/2015 10:56 AM, Roberto Cornacchia wrote:

Hi there,

I'm planning to deploy freeIPA on our lan.
It's small-ish and completely based on FC21, so I expect everything to
work
like a charm.

Except one detail. We have Synology NAS station, which uses DSM 5.0.
The ideal plan is to use it as host for shared NFS home dirs once we
switch our
desktops to freeIPA.

Great!

Hello,

The first thing I'm struggling with is to find the correct approach about
NFS home dirs.
The ideal setting would be:
- home dirs on the NAS
- IPA manages automount maps
- home dirs are created automatically at first login

The documentation I could find on these topics includes only not-so-recent
pages (anything I missed?):

http://wiki.linux-nfs.org/wiki/index.php/NFS_and_FreeIPA
http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/automount.html
http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/users.html#home-directories
http://adam.younglogic.com/2011/06/automount-and-home-directory-creation/

Now, I admit I don't have much experience with setting up NFS homes, with
or without freeIPA, so trying to get this done correctly in the context of
freeIPA and without clear howtos isn't very easy, but I'm willing to get my
hands dirty.

The first problem I struggle with is on the correct approach.
From the documentation above, I understand that there is a bit of a
chicken-egg problem about the creation of home dirs.
On the one hand, it would be optimal to have automount maps to load only
single home dirs on demand, rather than the entire /home tree.
On the other hand, if the /home tree is not available, then creating
/home/user1 dir automatically isn't really possible.

Just mounting the whole /home tree would make things easier, but I don't
have a feeling of when it starts to become a performance issue (assuming
recent hardware and up to date software). 10 users? 50? 100? 500? No idea.
The realm I'm dealing with at the moment is in the range of 5-10 users and
probably won't be larger than 50 in the next few years (and if it will, it
means things are going well, so what the heck ;)
Also true that, with such few users, I could just create the homedirs
manually when needed (this is not an organisation where many users come and
go) and just mount the individually.
Any tips about this?

Best, Roberto
--
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 remove nsTombstone objects

2015-03-19 Thread thierry bordaz


On 03/18/2015 07:21 PM, Rich Megginson wrote:

On 03/18/2015 11:07 AM, Kim Perrin wrote:

ah, good question. Relevant errors around trying to use the ldif I
included to remove replica ID 97 --

[18/Mar/2015:04:01:51 +] NSMMReplicationPlugin - CleanAllRUV Task:
Waiting for all the replicas to receive all the deleted replica
updates...
[18/Mar/2015:04:01:51 +] NSMMReplicationPlugin - CleanAllRUV Task:
Sending cleanAllRUV task to all the replicas...
[18/Mar/2015:04:01:51 +] NSMMReplicationPlugin - CleanAllRUV Task:
Cleaning local ruv's...
[18/Mar/2015:04:01:51 +] NSMMReplicationPlugin - CleanAllRUV Task:
Waiting for all the replicas to be cleaned...
[18/Mar/2015:04:01:52 +] NSMMReplicationPlugin - CleanAllRUV Task:
Waiting for all the replicas to finish cleaning...
[18/Mar/2015:04:01:52 +] NSMMReplicationPlugin - CleanAllRUV Task:
Successfully cleaned rid(14).
[18/Mar/2015:04:20:18 +] - WARNING: can't modify task entry
'cn=clean 97,cn=cleanallruv,cn=tasks,cn=config'; No such object (32)
[18/Mar/2015:04:20:21 +] - WARNING: can't modify task entry
'cn=clean 97,cn=cleanallruv,cn=tasks,cn=config'; No such object (32)
[18/Mar/2015:04:20:23 +] - WARNING: can't modify task entry
'cn=clean 97,cn=cleanallruv,cn=tasks,cn=config'; No such object (32)
[18/Mar/2015:04:20:23 +] NSMMReplicationPlugin - CleanAllRUV Task:
Replica id (97) is already being cleaned
[18/Mar/2015:04:20:25 +] - WARNING: can't modify task entry
'cn=clean 97,cn=cleanallruv,cn=tasks,cn=config'; No such object (32)
[18/Mar/2015:04:20:27 +] - WARNING: can't modify task entry
'cn=clean 97,cn=cleanallruv,cn=tasks,cn=config'; No such object (32)
[18/Mar/2015:04:20:29 +] - WARNING: can't modify task entry
'cn=clean 97,cn=cleanallruv,cn=tasks,cn=config'; No such object (32)
[18/Mar/2015:04:20:29 +] NSMMReplicationPlugin - CleanAllRUV Task:
Task failed...(-1)
[18/Mar/2015:04:20:31 +] - WARNING: can't modify task entry
'cn=clean 97,cn=cleanallruv,cn=tasks,cn=config'; No such object (32)
[18/Mar/2015:04:20:31 +] - WARNING: can't find task entry
'cn=clean 97,cn=cleanallruv,cn=tasks,cn=config'
[18/Mar/2015:04:24:46 +] ipa_range_check_pre_op - [file
ipa_range_check.c, line 235]: Missing entry to modify.


Not sure what this means.  Anyone?
This is related to a direct MOD operation where the target entry is not 
found. This is logged by ipa-range-check but I am not sure if it reveal 
a real problem.
Would you check that at the same time (2015:04:24:46) there is a MOD 
that returns err=32.


The error reported by CleanAllRUV (Task failed) is strange, would you 
dump the RUV entry 
(nsuniqueid=---,o=ipaca) to see if the 
clean up 97 occured ?


thanks
thierry






On Wed, Mar 18, 2015 at 9:52 AM, Rich Megginson rmegg...@redhat.com 
wrote:

On 03/18/2015 10:50 AM, Kim Perrin wrote:

Hi all,
yesterday I cleared up replication problems on my last standing IPA
server. So I somewhat feel like I'm coming out of the tunnel. Today I
want to turn up a replica again. However before doing so I'd like to
clean out the last remnants of data about all previous replicas.
I can't figure out the properly formatted ldif to use to remove the
nsds50ruv and the nsruvReplicaLastModified records in these entries.
Any guidance on the proper ldif to use would be much appreciated --
Here is are the tombstone entries -

dn: nsuniqueid=---,o=ipaca
objectClass: top
objectClass: nsTombstone
objectClass: extensibleobject
nsds50ruv: {replicageneration} 5317a4490060
nsds50ruv: {replica 96 ldap://noc1-prd.companyz.com:7389} 
5317a45500

60 550878b90060
nsds50ruv: {replica 71 ldap://noc2-prd.companyz.com:7389} 
531ce01800

47 531ce06900030047
nsds50ruv: {replica 76 ldap://noc4-prd.companyz.com:7389} 
531cdde800

4c 53f65954004c
nsds50ruv: {replica 81 ldap://noc2-prd.companyz.com:7389} 
531bf21600

51 531bf26500010051
nsds50ruv: {replica 86 ldap://noc3-prd.companyz.com:7389} 
531a322200

56 531a325600040056
nsds50ruv: {replica 91 ldap://noc2-prd.companyz.com:7389} 
5317f7cf00

5b 53194992005b
nsds50ruv: {replica 97 ldap://util1-prd.companyz.com:7389} 
5317a4500

061 5317a48a00010061
o: ipaca
nsruvReplicaLastModified: {replica 96 
ldap://noc1-prd.companyz.com:7389}

   550878ab
nsruvReplicaLastModified: {replica 71 
ldap://noc2-prd.companyz.com:7389}

   
nsruvReplicaLastModified: {replica 76 
ldap://noc4-prd.companyz.com:7389}

   
nsruvReplicaLastModified: {replica 81 
ldap://noc2-prd.companyz.com:7389}

   
nsruvReplicaLastModified: {replica 86 
ldap://noc3-prd.companyz.com:7389}

   
nsruvReplicaLastModified: {replica 91 
ldap://noc2-prd.companyz.com:7389}

   
nsruvReplicaLastModified: {replica 97 
ldap://util1prd.companyz.com:7389}

   



Using the following to clean these did NOT work -

dn: cn=clean

Re: [Freeipa-users] subjectAlternitiveName for webservice

2015-03-19 Thread Matt .

Isn't this documented well (yet) ?

The RH docs are always very detailed about it, but I'm not sure
here... I see solutions but not 100% from A to Z to make sure we do it
the proper way.

2015-03-12 16:59 GMT+01:00 Matt . yamakasi@gmail.com:
 Not worried, I need to try.

 I think it's not an issue as we use persistance for the connection. We
 only do some user adding/chaging stuff, nothing really fancy but it
 needs to be decent. As persistence comes in I think we don't have to
 worry about it, we discussed that here earlier as I remember.

 Or do I ?

 Something else; did you had a nice PTO ?

 2015-03-12 15:54 GMT+01:00 Rob Crittenden rcrit...@redhat.com:
 Matt . wrote:
 Hi,

 Security wise I can understand that.

 Yes I have read about that... but that would let me use the
 loadbalancer to connect ? I was not sure if the SAN would connect as
 other host.

 Kerberos through a load balancer can be a problem. Is this what you're
 worried about?

 rob


 2015-03-12 15:07 GMT+01:00 Rob Crittenden rcrit...@redhat.com:
 Matt . wrote:
 Hi Guys,

 Is Rob able to look at this ? I hope he has some sparetime as I'm
 kinda stuck with this issue.

 Wildcard certs are not supported.

 You can request a SAN with certmonger using -D FQDN. That will work
 with IPA 4.x for sure, maybe 3.3.5.

 rob


 Thanks!



 2015-03-08 12:30 GMT+01:00 Matt . yamakasi@gmail.com:
 I'm reviewing some things.

 When I'm using a loadbalancer, which I prefer in this setup I need to
 have the same certificates on both servers. Maybe a wildcard for my
 domain could do instead of having only both fqdn's of the servers
 including the loadbalancer's fqdn.

 But the question remains, how?



 2015-03-07 10:37 GMT+01:00 Matt . yamakasi@gmail.com:
 Hi,

 I will balance with IP persistance so I think there won't be any
 mixing as long as that used server is online.

 2015-03-06 19:16 GMT+01:00 Dmitri Pal d...@redhat.com:
 On 03/06/2015 11:05 AM, Matt . wrote:

 OK, understood.

 But when a webservice does execute a command (from scripting) to a SVR
 record and the first is not reacable, would it try to do it again or
 will handle DNS this in front of it ?

 I do a kinit against an IPA server using a keytab after I first
 checked if the user was able to auth himself using his ldap
 credentials, if so, this kinit exec is fired and I do some CURL stuff
 to the IPA server.

 That's why I wanted a loadbalancer, the loadbalancer sees if a server
 is down and doesn't even try to direct any of the commands to it...
 I'm not sure if the SRV will handle this well when doing these command
 from PHP for an example. Building in extra checks in front could be
 done but it not ideal as a loadbalancer can handle such things much
 better.


 OK, this makes things much more clear. Thanks for the explanation.
 Rob. What is our failover logic for API?

 For CLI we use a negotiation and then we store a cookie so as long as 
 the
 whole conversation goes to the same server you should be fine. I do not
 think you need to re-encrypt the traffic at load balancer and thus 
 have a
 cert there then if you can enforce the use of the same server in this 
 case.

 The issue I anticipate is with Kerberos. I think you should not load 
 balance
 the Kerberos traffic, only the API commands starting with the 
 negotiation.

 Rob does that make sense for you?



 Thanks!

 Cheers,

 Matt

 2015-03-06 16:41 GMT+01:00 Dmitri Pal d...@redhat.com:

 On 03/06/2015 10:24 AM, Matt . wrote:

 Hi,

 I'm really bound to a loadbalancer, as it's HA setup of 
 loadbalancers,
 SRV won't fit here sorry to say.

 I auth users, so their keytab should be the same between two 
 masters I
 believe ?


 Each entity in Kerberos exchange has its own identity and key.
 If you send a ticket that is destined to service A instead to 
 service B
 it
 would not work unless they share the same keys and identity. Sharinf 
 same
 keys and identities between the servers just would not work with IPA.
 Keep in mind that IPA clients and server need to work and fail over 
 if
 you
 do not have any load balancers and this is the common case. You are
 trying
 to add one where it is really not needed creating overhead for 
 yourself.



 In that case... I need to add the altnames to the certs, but I'm not
 100% there in step 6

 Thanks again!

 Cheers,

 Matthijs

 2015-03-06 16:16 GMT+01:00 Petr Spacek pspa...@redhat.com:

 On 6.3.2015 15:39, Matt . wrote:

 I have 2 IPA servers where I kinit to and post to the api using
 curl/json.

 If we are talking purely about scripting, you can use IPA Python 
 API.
 It
 will
 handle fail over for you even without any load balancer. That 
 would be
 easiest
 way.

 As I need redundancy and don't want to have it script managed, 
 but one
 central point where I can tal to I use a loadbalancer.

 Well, if you can control clients then the easiest and most 
 universal
 way
 is to
 use DNS SRV records and add failover logic to clients. That 
 solution
 works
 even when servers

Re: [Freeipa-users] AD users not getting single sign on (Solaris)

nat...@nathanpeters.com wrote:
 I have finally gotten all of my Solaris servers to accept AD users but the
 behavior is inconsistent.
 
 In my FreeIPA domain, I can login to a Linux server and then ssh to the
 Solaris server and I am automatically logged in because of my Kerberos
 ticket (I assume).
 
 But when I ssh from the first Solaris machine to the 2nd I am prompted for
 a password instead of being automatically signed in.  The strange thing is
 that it doesn't matter which machine I login to first, it's only the 2nd
 hop that asks for a password.
 
 Below are my console recording.  ipaclient1 is Linux, ipaclient5 and
 ipaclient6 are Solaris.
 Login from Linux - Solaris 1 works without password
 Login from Linux - Solaris 2 works without password
 Login from Solaris 1 - Solaris 2 prompts
 Login from Solaris 2 - Solaris 1 prompts.
 
 Any ideas?

You log into Linux and get a TGT . Using that TGT you can log into any
other box (Solaris or otherwise). Unless you are delegating that TGT
with each ssh login you won't have one after the first login to another
system, it will be used for authentication only.

See the -K option of ssh, or SSAPIDelegateCredentials yes in sshd.

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] subjectAlternitiveName for webservice

2015-03-19 Thread Matt .

The right way to sequest a SAN, this seems to need some extra config file ?

2015-03-19 15:04 GMT+01:00 Rob Crittenden rcrit...@redhat.com:
 Matt . wrote:
 Isn't this documented well (yet) ?

 Is what documented yet?

 rob


 The RH docs are always very detailed about it, but I'm not sure
 here... I see solutions but not 100% from A to Z to make sure we do it
 the proper way.

 2015-03-12 16:59 GMT+01:00 Matt . yamakasi@gmail.com:
 Not worried, I need to try.

 I think it's not an issue as we use persistance for the connection. We
 only do some user adding/chaging stuff, nothing really fancy but it
 needs to be decent. As persistence comes in I think we don't have to
 worry about it, we discussed that here earlier as I remember.

 Or do I ?

 Something else; did you had a nice PTO ?

 2015-03-12 15:54 GMT+01:00 Rob Crittenden rcrit...@redhat.com:
 Matt . wrote:
 Hi,

 Security wise I can understand that.

 Yes I have read about that... but that would let me use the
 loadbalancer to connect ? I was not sure if the SAN would connect as
 other host.

 Kerberos through a load balancer can be a problem. Is this what you're
 worried about?

 rob


 2015-03-12 15:07 GMT+01:00 Rob Crittenden rcrit...@redhat.com:
 Matt . wrote:
 Hi Guys,

 Is Rob able to look at this ? I hope he has some sparetime as I'm
 kinda stuck with this issue.

 Wildcard certs are not supported.

 You can request a SAN with certmonger using -D FQDN. That will work
 with IPA 4.x for sure, maybe 3.3.5.

 rob


 Thanks!



 2015-03-08 12:30 GMT+01:00 Matt . yamakasi@gmail.com:
 I'm reviewing some things.

 When I'm using a loadbalancer, which I prefer in this setup I need to
 have the same certificates on both servers. Maybe a wildcard for my
 domain could do instead of having only both fqdn's of the servers
 including the loadbalancer's fqdn.

 But the question remains, how?



 2015-03-07 10:37 GMT+01:00 Matt . yamakasi@gmail.com:
 Hi,

 I will balance with IP persistance so I think there won't be any
 mixing as long as that used server is online.

 2015-03-06 19:16 GMT+01:00 Dmitri Pal d...@redhat.com:
 On 03/06/2015 11:05 AM, Matt . wrote:

 OK, understood.

 But when a webservice does execute a command (from scripting) to a 
 SVR
 record and the first is not reacable, would it try to do it again or
 will handle DNS this in front of it ?

 I do a kinit against an IPA server using a keytab after I first
 checked if the user was able to auth himself using his ldap
 credentials, if so, this kinit exec is fired and I do some CURL 
 stuff
 to the IPA server.

 That's why I wanted a loadbalancer, the loadbalancer sees if a 
 server
 is down and doesn't even try to direct any of the commands to it...
 I'm not sure if the SRV will handle this well when doing these 
 command
 from PHP for an example. Building in extra checks in front could be
 done but it not ideal as a loadbalancer can handle such things much
 better.


 OK, this makes things much more clear. Thanks for the explanation.
 Rob. What is our failover logic for API?

 For CLI we use a negotiation and then we store a cookie so as long 
 as the
 whole conversation goes to the same server you should be fine. I do 
 not
 think you need to re-encrypt the traffic at load balancer and thus 
 have a
 cert there then if you can enforce the use of the same server in 
 this case.

 The issue I anticipate is with Kerberos. I think you should not load 
 balance
 the Kerberos traffic, only the API commands starting with the 
 negotiation.

 Rob does that make sense for you?



 Thanks!

 Cheers,

 Matt

 2015-03-06 16:41 GMT+01:00 Dmitri Pal d...@redhat.com:

 On 03/06/2015 10:24 AM, Matt . wrote:

 Hi,

 I'm really bound to a loadbalancer, as it's HA setup of 
 loadbalancers,
 SRV won't fit here sorry to say.

 I auth users, so their keytab should be the same between two 
 masters I
 believe ?


 Each entity in Kerberos exchange has its own identity and key.
 If you send a ticket that is destined to service A instead to 
 service B
 it
 would not work unless they share the same keys and identity. 
 Sharinf same
 keys and identities between the servers just would not work with 
 IPA.
 Keep in mind that IPA clients and server need to work and fail 
 over if
 you
 do not have any load balancers and this is the common case. You are
 trying
 to add one where it is really not needed creating overhead for 
 yourself.



 In that case... I need to add the altnames to the certs, but I'm 
 not
 100% there in step 6

 Thanks again!

 Cheers,

 Matthijs

 2015-03-06 16:16 GMT+01:00 Petr Spacek pspa...@redhat.com:

 On 6.3.2015 15:39, Matt . wrote:

 I have 2 IPA servers where I kinit to and post to the api using
 curl/json.

 If we are talking purely about scripting, you can use IPA Python 
 API.
 It
 will
 handle fail over for you even without any load balancer. That 
 would be
 easiest
 way.

 As I need redundancy and don't want to have it script managed, 
 but one
 central point where I can tal

Re: [Freeipa-users] Synology DSM5 and freeIPA

On 03/19/2015 02:46 PM, Roberto Cornacchia wrote:

Hi Dmitri,

I do realise my question is borderline and I accept that it is
considered off-topic.

I did post it here because I believe it's not *only* about NFS, but
also about its interaction with freeIPA. The issue of NFS home and in
particular about their creation is touched in all the links I posted
(all about freeIPA) and never really answered.

This is what documented and recommended:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#kerb-nfs

RHEL6 has a similar chapter in its doc set though books have changed
significantly between 6 and 7.

I do not see any chicken and egg problem there.
The instructions show how to create home dirs on the first login.

It mounts the volume and then creates dirs on it as users log in if they
are not already there.

It is unclear what problem you see with doing it the way it is recommended.

Best,
Roberto

On 19 March 2015 at 19:36, Dmitri Pal d...@redhat.com
mailto:d...@redhat.com wrote:

On 03/19/2015 05:29 AM, Roberto Cornacchia wrote:

On 6 March 2015 at 11:15, Martin Kosek mko...@redhat.com
mailto:mko...@redhat.com wrote:

On 03/06/2015 10:56 AM, Roberto Cornacchia wrote:

Hi there,

I'm planning to deploy freeIPA on our lan.
It's small-ish and completely based on FC21, so I expect
everything to work
like a charm.

Except one detail. We have Synology NAS station, which
uses DSM 5.0.
The ideal plan is to use it as host for shared NFS home
dirs once we switch our
desktops to freeIPA.

Great!

Hello,

The first thing I'm struggling with is to find the correct
approach about NFS home dirs.
The ideal setting would be:
- home dirs on the NAS
- IPA manages automount maps
- home dirs are created automatically at first login

The documentation I could find on these topics includes only
not-so-recent pages (anything I missed?):

http://wiki.linux-nfs.org/wiki/index.php/NFS_and_FreeIPA

http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/automount.html

http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/users.html#home-directories
http://adam.younglogic.com/2011/06/automount-and-home-directory-creation/

Now, I admit I don't have much experience with setting up NFS
homes, with or without freeIPA, so trying to get this done
correctly in the context of freeIPA and without clear howtos
isn't very easy, but I'm willing to get my hands dirty.

The first problem I struggle with is on the correct approach.
From the documentation above, I understand that there is a bit of
a chicken-egg problem about the creation of home dirs.
On the one hand, it would be optimal to have automount maps to
load only single home dirs on demand, rather than the entire
/home tree.
On the other hand, if the /home tree is not available, then
creating /home/user1 dir automatically isn't really possible.

Just mounting the whole /home tree would make things easier, but
I don't have a feeling of when it starts to become a performance
issue (assuming recent hardware and up to date software). 10
users? 50? 100? 500? No idea.
The realm I'm dealing with at the moment is in the range of 5-10
users and probably won't be larger than 50 in the next few years
(and if it will, it means things are going well, so what the heck ;)
Also true that, with such few users, I could just create the
homedirs manually when needed (this is not an organisation where
many users come and go) and just mount the individually.
Any tips about this?

Best, Roberto

Some of these questions are really outside the scope of this list.
You might consider asking them on the NFS list.

--
Thank you,

Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

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

--
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

--
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] Really slow logins with AD SID Mapping vs. POSIX

I'm running a bit out of time today, but I'll be doing some 7.1 builds tomorrow 
anyway, so I'll spin up the test package for you.

 On 19 Mar 2015, at 16:31, Gould, Joshua joshua.go...@osumc.edu wrote:
 
 RHEL 7.0 fully up to date.
 
 sssd-krb5-common-1.12.2-58.el7.x86_64
 sssd-ipa-1.12.2-58.el7.x86_64
 sssd-1.12.2-58.el7.x86_64
 sssd-tools-1.12.2-58.el7.x86_64
 sssd-common-1.12.2-58.el7.x86_64
 sssd-ad-1.12.2-58.el7.x86_64
 sssd-krb5-1.12.2-58.el7.x86_64
 sssd-ldap-1.12.2-58.el7.x86_64
 sssd-client-1.12.2-58.el7.x86_64
 sssd-common-pac-1.12.2-58.el7.x86_64
 sssd-proxy-1.12.2-58.el7.x86_64
 
 
 
 On 3/19/15, 11:23 AM, Jakub Hrozek jhro...@redhat.com wrote:
 
 On Thu, Mar 19, 2015 at 11:05:45AM -0400, Gould, Joshua wrote:
 I¹m seeing ssh logins for AD users take MUCH longer when using SID
 mapping
 vs. POSIX attributes. Both myself and our AD admin would prefer to use
 SID
 mapping. It appears tied to the group lookup at login. There seem to be
 many posts about it, but I haven¹t found anything to help much. sssd
 pegs
 the CPU for the 15 or so seconds the login takes.
 
 You haven't said what OS or release are you running, but for 7.0 I have
 test packages with a proposed enhancement Sumit wrote:
 
 https://urldefense.proofpoint.com/v2/url?u=https-3A__jhrozek.fedorapeople.
 org_sssd-2Dtest-2Dbuilds_sssd-2D7.0-2Dlogin-2Dspeedup_d=AwIFAwc=k9MF1d71
 ITtkuJx-PdWme51dKbmfPEvxwt8SFEkBfs4r=C8H0y1Bn8C6Mf5i9qrqkUDy3xSk8zPbIs_Sv
 JwojC24m=YA1l-b8irE5VE9qVc1q4PY8RVJA2iLwWLK_U7aXS1gss=bYcFLFGsd6BT_1ozcn
 1r1WaYFWJ4_5xT5ddR7d45Z08e=
 
 Please include the versions of the problematic packages in the future
 requests for troubleshooting.
 
 -- 
 Manage your subscription for the Freeipa-users mailing list:
 https://urldefense.proofpoint.com/v2/url?u=https-3A__www.redhat.com_mailma
 n_listinfo_freeipa-2Dusersd=AwIFAwc=k9MF1d71ITtkuJx-PdWme51dKbmfPEvxwt8S
 FEkBfs4r=C8H0y1Bn8C6Mf5i9qrqkUDy3xSk8zPbIs_SvJwojC24m=YA1l-b8irE5VE9qVc1
 q4PY8RVJA2iLwWLK_U7aXS1gss=uJUobRCfTZ-jS6M4XSLW8ScMXv_1sIQ-OSoy54M7b2ke=
 
 Go to 
 https://urldefense.proofpoint.com/v2/url?u=http-3A__freeipa.orgd=AwIFAwc
 =k9MF1d71ITtkuJx-PdWme51dKbmfPEvxwt8SFEkBfs4r=C8H0y1Bn8C6Mf5i9qrqkUDy3xSk
 8zPbIs_SvJwojC24m=YA1l-b8irE5VE9qVc1q4PY8RVJA2iLwWLK_U7aXS1gss=F_LQz74bb
 hG6_BKutjgbdRMTvIBRYggIgNj1QZoEznwe=  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] revocation of a ssl certificate

2015-03-19 Thread Nicolas Zin

Hi,

let say that I created a SSL certificate:
ipa service-add HTTP/www.test.lan
ipa service-add-host --hosts=ipa-server.test.lan HTTP/www.test.lan
ipa-getcert request -r -f /etc/pki/tls/certs/www.test.lan.crt -k 
/etc/pki/tls/private/www.test.lan.key -N CN=www.test.lan -D www.test.lan -K 
HTTP/www.test.lan

and I installed it.

If the machine is compromised I would like to revoke it. What shall I do?

I saw you can stop renewing it via 
ipa-getcert stop-tracking -i 20150319132153

and seems to be that I can revoke it via

ipa cert-find
ipa cert-revoke --revocation-reason=1 0xC

is it sufficient?

I didn't see the /var/lib/ipa/pki-ca/publish/MasterCRL.bin changed. I though I 
should find the revocated certificate inside this binary file?
Also, how can I print the content of MasterCRL.bin in a readable output?



Regards,

Nicolas Zin



PS: I have to confess that I don't master CRL and OCSP.

-- 
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] Replica install fails at client install

2015-03-19 Thread Janelle


On 3/18/15 10:10 PM, Kim Perrin wrote:

This is about the 6th time of tried installing this replica. Each time
I run the ipa-replica-manage del and ipa-csreplica-manage del command
before trying. I also build new replica install files each time.
Obviously I can't figure out what the problem is. I've tried a variety
of things. I'm hoping someone in this community has been this before
and solved the issue.
At the end of the install I see the client install failure messages,
though it appeared as though the server install went well. However it
is clear it has not gone well because when I run 'service ipa status'
I get this

root@noc5-prd:/var/log# service ipa status
Directory Service: RUNNING
Unknown error when retrieving list of services from LDAP: {'info':
'SASL(-4): no mechanism available: ', 'desc': 'Unknown authentication
method'}


I've attached the ipareplica-install.log file.  Here are some relevant
entries from the end of the log -

2015-03-19T04:33:02Z DEBUG args=/usr/sbin/ipa-client-install
--on-master --unattended --domain companyz.com --server
noc5-prd.companyz.com --realm COMPANYZ.COM
2015-03-19T04:33:02Z DEBUG stdout=
2015-03-19T04:33:02Z DEBUG stderr=Hostname: noc5prd.companyz.com
Realm: COMPANYZ.COM
DNS Domain: companyz.com
IPA Server: noc5-prd.companyz.com
BaseDN: dc=companyz,dc=com
New SSSD config will be created
Configured sudoers in /etc/nsswitch.conf
Configured /etc/sssd/sssd.conf
trying https://noc5-prd.companyz.com/ipa/xml
trying https://noc1-prd.companyz.com/ipa/xml
Connection to https://noc1-prd.companyz.com/ipa/xml failed with [Errno
-8053] (SEC_ERROR_BUSY) NSS could not shutdown. Objects are still in
use.
Cannot connect to the server due to generic error: cannot connect to
Gettext('any of the configured servers', domain='ipa',
localedir=None): https://noc5-prd.companyz.com/ipa/xml,
https://noc1-prd.companyz.com/ipa/xml
Installation failed. Rolling back changes.
Removing Kerberos service principals from /etc/krb5.keytab
Disabling client Kerberos and LDAP configurations
Redundant SSSD configuration file /etc/sssd/sssd.conf was moved to
/etc/sssd/sssd.conf.deleted
nscd daemon is not installed, skip configuration
nslcd daemon is not installed, skip configuration
Client uninstall complete.
2015-03-19T04:33:02Z INFO   File
/usr/lib/python2.6/site-packages/ipaserver/install/installutils.py,
line 614, in run_script
 return_value = main_function()
   File /usr/sbin/ipa-replica-install, line 536, in main
 raise RuntimeError(Failed to configure the client)
2015-03-19T04:33:02Z INFO The ipa-replica-install command failed,
exception: RuntimeError: Failed to configure the client

Anyone have any advice?


There are 2 possibilities here. One is you have the old python package 
scripts which have a bug in these files:


/usr/lib/python2.7/site-packages/ipaplatform/fedora/services.py
/usr/lib/python2.7/site-packages/ipaplatform/services.py

They most likely have fedora-domain in them and it needs to be changed 
to rhel-domain.  The other option is to re-install the OS and freeipa 
environment, which gets you to clean packages.  Deleting and 
re-installing all the python packages is painful at best.


The other possibility is stale certs:

certutil -d /etc/pki/nssdb -L

You will probably see a stale cert. Remove it.

certutil -d /etc/pki/nssdb -D -n IPA CA

I have run into both of these issues about 1 million times so far.

~J
-- 
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] subjectAlternitiveName for webservice

Matt . wrote:
 Isn't this documented well (yet) ?

Is what documented yet?

rob

 
 The RH docs are always very detailed about it, but I'm not sure
 here... I see solutions but not 100% from A to Z to make sure we do it
 the proper way.
 
 2015-03-12 16:59 GMT+01:00 Matt . yamakasi@gmail.com:
 Not worried, I need to try.

 I think it's not an issue as we use persistance for the connection. We
 only do some user adding/chaging stuff, nothing really fancy but it
 needs to be decent. As persistence comes in I think we don't have to
 worry about it, we discussed that here earlier as I remember.

 Or do I ?

 Something else; did you had a nice PTO ?

 2015-03-12 15:54 GMT+01:00 Rob Crittenden rcrit...@redhat.com:
 Matt . wrote:
 Hi,

 Security wise I can understand that.

 Yes I have read about that... but that would let me use the
 loadbalancer to connect ? I was not sure if the SAN would connect as
 other host.

 Kerberos through a load balancer can be a problem. Is this what you're
 worried about?

 rob


 2015-03-12 15:07 GMT+01:00 Rob Crittenden rcrit...@redhat.com:
 Matt . wrote:
 Hi Guys,

 Is Rob able to look at this ? I hope he has some sparetime as I'm
 kinda stuck with this issue.

 Wildcard certs are not supported.

 You can request a SAN with certmonger using -D FQDN. That will work
 with IPA 4.x for sure, maybe 3.3.5.

 rob


 Thanks!



 2015-03-08 12:30 GMT+01:00 Matt . yamakasi@gmail.com:
 I'm reviewing some things.

 When I'm using a loadbalancer, which I prefer in this setup I need to
 have the same certificates on both servers. Maybe a wildcard for my
 domain could do instead of having only both fqdn's of the servers
 including the loadbalancer's fqdn.

 But the question remains, how?



 2015-03-07 10:37 GMT+01:00 Matt . yamakasi@gmail.com:
 Hi,

 I will balance with IP persistance so I think there won't be any
 mixing as long as that used server is online.

 2015-03-06 19:16 GMT+01:00 Dmitri Pal d...@redhat.com:
 On 03/06/2015 11:05 AM, Matt . wrote:

 OK, understood.

 But when a webservice does execute a command (from scripting) to a 
 SVR
 record and the first is not reacable, would it try to do it again or
 will handle DNS this in front of it ?

 I do a kinit against an IPA server using a keytab after I first
 checked if the user was able to auth himself using his ldap
 credentials, if so, this kinit exec is fired and I do some CURL stuff
 to the IPA server.

 That's why I wanted a loadbalancer, the loadbalancer sees if a server
 is down and doesn't even try to direct any of the commands to it...
 I'm not sure if the SRV will handle this well when doing these 
 command
 from PHP for an example. Building in extra checks in front could be
 done but it not ideal as a loadbalancer can handle such things much
 better.


 OK, this makes things much more clear. Thanks for the explanation.
 Rob. What is our failover logic for API?

 For CLI we use a negotiation and then we store a cookie so as long as 
 the
 whole conversation goes to the same server you should be fine. I do 
 not
 think you need to re-encrypt the traffic at load balancer and thus 
 have a
 cert there then if you can enforce the use of the same server in this 
 case.

 The issue I anticipate is with Kerberos. I think you should not load 
 balance
 the Kerberos traffic, only the API commands starting with the 
 negotiation.

 Rob does that make sense for you?



 Thanks!

 Cheers,

 Matt

 2015-03-06 16:41 GMT+01:00 Dmitri Pal d...@redhat.com:

 On 03/06/2015 10:24 AM, Matt . wrote:

 Hi,

 I'm really bound to a loadbalancer, as it's HA setup of 
 loadbalancers,
 SRV won't fit here sorry to say.

 I auth users, so their keytab should be the same between two 
 masters I
 believe ?


 Each entity in Kerberos exchange has its own identity and key.
 If you send a ticket that is destined to service A instead to 
 service B
 it
 would not work unless they share the same keys and identity. 
 Sharinf same
 keys and identities between the servers just would not work with 
 IPA.
 Keep in mind that IPA clients and server need to work and fail over 
 if
 you
 do not have any load balancers and this is the common case. You are
 trying
 to add one where it is really not needed creating overhead for 
 yourself.



 In that case... I need to add the altnames to the certs, but I'm 
 not
 100% there in step 6

 Thanks again!

 Cheers,

 Matthijs

 2015-03-06 16:16 GMT+01:00 Petr Spacek pspa...@redhat.com:

 On 6.3.2015 15:39, Matt . wrote:

 I have 2 IPA servers where I kinit to and post to the api using
 curl/json.

 If we are talking purely about scripting, you can use IPA Python 
 API.
 It
 will
 handle fail over for you even without any load balancer. That 
 would be
 easiest
 way.

 As I need redundancy and don't want to have it script managed, 
 but one
 central point where I can tal to I use a loadbalancer.

 Well, if you can control clients then the easiest and most 
 universal
 way
 is to
 use DNS SRV records and add

Re: [Freeipa-users] revocation of a ssl certificate

Nicolas Zin wrote:
 Hi,
 
 let say that I created a SSL certificate:
 ipa service-add HTTP/www.test.lan
 ipa service-add-host --hosts=ipa-server.test.lan HTTP/www.test.lan
 ipa-getcert request -r -f /etc/pki/tls/certs/www.test.lan.crt -k 
 /etc/pki/tls/private/www.test.lan.key -N CN=www.test.lan -D www.test.lan -K 
 HTTP/www.test.lan
 
 and I installed it.
 
 If the machine is compromised I would like to revoke it. What shall I do?
 
 I saw you can stop renewing it via 
 ipa-getcert stop-tracking -i 20150319132153

That just stops tracking the certificate on the machine. It doesn't
touch the certificate or key or whatever server is using it at all. In
other words, you'd want to stop using this certificate as well.

 and seems to be that I can revoke it via
 
 ipa cert-find
 ipa cert-revoke --revocation-reason=1 0xC

You shouldn't need the cert-find as you can get the serial number from
the certificate on the server and revoke it directly.

 is it sufficient?

Only if revocation is actually verified by clients using either CRL or OCSP.

 I didn't see the /var/lib/ipa/pki-ca/publish/MasterCRL.bin changed. I though 
 I should find the revocated certificate inside this binary file?
 Also, how can I print the content of MasterCRL.bin in a readable output?
 

The CRL is generated every 4 hours by default.

# openssl crl -inform der -in /var/lib/ipa/pki-ca/publish/MasterCRL.bin
-text

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

[Freeipa-users] Email address for directory admin

2015-03-19 Thread Giedrius Tuminauskas

 Hi,

I am curious, Is there a possibility to add email address for the
admin user in the IPA web UI?
In my current configuration admin user is a Linux system user and
also used by IPA.
I think there should be possibility to enter an email address for that
user, but UI has no button/link (add) 

Is it expected behavior? 
Can you please suggest some tweaks, how to add it?

Cheers

Giedrius Tuminauskas


-- 
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] Email address for directory admin

Giedrius Tuminauskas wrote:
 Hi,
 
 I am curious, Is there a possibility to add email address for the
 admin user in the IPA web UI?
 In my current configuration admin user is a Linux system user and also
 used by IPA.
 I think there should be possibility to enter an email address for that
 user, but UI has no button/link (add)
 
 Is it expected behavior?
 Can you please suggest some tweaks, how to add it?

Not easily from the UI but possible from the cli. The admin user lacks
the inetOrgPerson objectclass which provides the mail attribute.

I haven't given this a great deal of thought so can't guarantee that
there won't be any subtle issues now or in the future, but given that
this objectclass only has MAY attributes is should be ok.

$ kinit admin
$ ipa user-mod --email ad...@example.com --addattr
objectclass=inetorgperson admin

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] Email address for directory admin

2015-03-19 Thread Martin Kosek

On 03/19/2015 02:36 PM, Rob Crittenden wrote:
 Giedrius Tuminauskas wrote:
 Hi,

 I am curious, Is there a possibility to add email address for the
 admin user in the IPA web UI?
 In my current configuration admin user is a Linux system user and also
 used by IPA.
 I think there should be possibility to enter an email address for that
 user, but UI has no button/link (add)

 Is it expected behavior?
 Can you please suggest some tweaks, how to add it?
 
 Not easily from the UI but possible from the cli. The admin user lacks
 the inetOrgPerson objectclass which provides the mail attribute.
 
 I haven't given this a great deal of thought so can't guarantee that
 there won't be any subtle issues now or in the future, but given that
 this objectclass only has MAY attributes is should be ok.
 
 $ kinit admin
 $ ipa user-mod --email ad...@example.com --addattr
 objectclass=inetorgperson admin
 
 rob

Related closed tickets with reasoning why this is not done by default:

https://fedorahosted.org/freeipa/ticket/4941
https://fedorahosted.org/freeipa/ticket/1162

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] 'Preauthentication failed' with SSSD in ipa_server_mode

2015-03-19 Thread Sumit Bose

On Thu, Mar 19, 2015 at 04:46:44PM +0100, Bobby Prins wrote:
 Hi there,
 
 I'm currently trying to use the 'AD Trust for Legacy Clients' freeIPA setup 
 (described here: 
 http://www.freeipa.org/images/0/0d/FreeIPA33-legacy-clients.pdf) to be able 
 to autenticate AIX 7.1 clients against an AD domain using LDAP. After the 
 trust was created all seems to work well on the freeIPA server. I can also do 
 a lookup of AD users and groups on an AIX test server.
 
 But as soon as I want to log in on the AIX system I get an SSSD error on the 
 freeIPA server in krb5_child.log (debug_level = 10):
 (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
 [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590260: AS key 
 obtained for encrypted timestamp: aes256-cts/2F5D
 (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
 [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590326: Encrypted 
 timestamp (for 1426778442.525165): plain 
 301AA011180F32303135303331393135323034325AA105020308036D, encrypted 
 9B3299264F09E50D63D84B385A09A4C64D44116A02B58FFF12830B39F88722CD9B792F5ABA0653578DE9138B91D29C17C197453D8B8A5E7A
 (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
 [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590349: Preauth module 
 encrypted_timestamp (2) (flags=1) returned: 0/Success
 (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
 [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590360: Produced 
 preauth for next request: 2
 (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
 [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590384: Sending 
 request (238 bytes) to EXAMPLE.CORP
 (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
 [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.591325: Resolving 
 hostname dct020.example.corp.
 (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
 [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.591889: Sending 
 initial UDP request to dgram 192.168.143.1:88
 (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
 [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636127: Received 
 answer from dgram 192.168.143.1:88
 (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
 [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636626: Response was 
 not from master KDC
 (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
 [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636667: Received error 
 from KDC: -1765328360/Preauthentication failed
 (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
 [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636698: Preauth 
 tryagain input types: 16, 14, 19, 2
 (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
 [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636728: Retrying AS 
 request with master KDC
 (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
 [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636741: Getting 
 initial credentials for bpr...@example.corp
 (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
 [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636787: Sending 
 request (160 bytes) to EXAMPLE.CORP (master)
 (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 [get_and_save_tgt] 
 (0x0020): 979: [-1765328360][Preauthentication failed]
 (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 [map_krb5_error] 
 (0x0020): 1040: [-1765328360][Preauthentication failed]
 (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 [k5c_send_data] 
 (0x0200): Received error code 1432158214
 
 If I do the same with 'KRB5_TRACE=/dev/stderr kinit bpr...@example.corp':
 [12299] 1426773524.361785: AS key obtained for encrypted timestamp: 
 aes256-cts/B997
 [12299] 1426773524.361850: Encrypted timestamp (for 1426773524.277583): plain 
 301AA011180F32303135303331393133353834345AA1050203043C4F, encrypted 
 ED9CF995617740C4B14DB9CC84187E3505B664FE5C0AD16D19477E912F5400FB2C4665A090E3A37CD749535B3C80595809E14D15CB3527C0
 [12299] 1426773524.361876: Preauth module encrypted_timestamp (2) (flags=1) 
 returned: 0/Success
 [12299] 1426773524.361880: Produced preauth for next request: 2
 [12299] 1426773524.361901: Sending request (238 bytes) to EXAMPLE.CORP
 [12299] 1426773524.363002: Resolving hostname dct020.EXAMPLE.corp.
 [12299] 1426773524.363841: Sending initial UDP request to dgram 
 192.168.141.1:88
 [12299] 1426773524.368089: Received answer from dgram 192.168.141.1:88
 [12299] 1426773524.368482: Response was not from master KDC
 [12299] 1426773524.368500: Received error from KDC: -1765328332/Response too 
 big for UDP, retry with TCP
 [12299] 1426773524.368506: Request or response is too big for UDP; retrying 
 with TCP
 [12299] 1426773524.368511: Sending request (238 bytes) to EXAMPLE.CORP (tcp 
 only)
 [12299] 1426773524.368953: Resolving hostname dct030.EXAMPLE.corp.
 [12299] 1426773524.370056: Initiating TCP connection to stream 
 192.168.143.5:88
 [12299] 1426773524.375140: Sending TCP request to stream

Re: [Freeipa-users] Replica install fails at client install

Janelle wrote:
 On 3/18/15 10:10 PM, Kim Perrin wrote:
 This is about the 6th time of tried installing this replica. Each time
 I run the ipa-replica-manage del and ipa-csreplica-manage del command
 before trying. I also build new replica install files each time.
 Obviously I can't figure out what the problem is. I've tried a variety
 of things. I'm hoping someone in this community has been this before
 and solved the issue.
 At the end of the install I see the client install failure messages,
 though it appeared as though the server install went well. However it
 is clear it has not gone well because when I run 'service ipa status'
 I get this

 root@noc5-prd:/var/log# service ipa status
 Directory Service: RUNNING
 Unknown error when retrieving list of services from LDAP: {'info':
 'SASL(-4): no mechanism available: ', 'desc': 'Unknown authentication
 method'}


 I've attached the ipareplica-install.log file.  Here are some relevant
 entries from the end of the log -

 2015-03-19T04:33:02Z DEBUG args=/usr/sbin/ipa-client-install
 --on-master --unattended --domain companyz.com --server
 noc5-prd.companyz.com --realm COMPANYZ.COM
 2015-03-19T04:33:02Z DEBUG stdout=
 2015-03-19T04:33:02Z DEBUG stderr=Hostname: noc5prd.companyz.com
 Realm: COMPANYZ.COM
 DNS Domain: companyz.com
 IPA Server: noc5-prd.companyz.com
 BaseDN: dc=companyz,dc=com
 New SSSD config will be created
 Configured sudoers in /etc/nsswitch.conf
 Configured /etc/sssd/sssd.conf
 trying https://noc5-prd.companyz.com/ipa/xml
 trying https://noc1-prd.companyz.com/ipa/xml
 Connection to https://noc1-prd.companyz.com/ipa/xml failed with [Errno
 -8053] (SEC_ERROR_BUSY) NSS could not shutdown. Objects are still in
 use.
 Cannot connect to the server due to generic error: cannot connect to
 Gettext('any of the configured servers', domain='ipa',
 localedir=None): https://noc5-prd.companyz.com/ipa/xml,
 https://noc1-prd.companyz.com/ipa/xml
 Installation failed. Rolling back changes.
 Removing Kerberos service principals from /etc/krb5.keytab
 Disabling client Kerberos and LDAP configurations
 Redundant SSSD configuration file /etc/sssd/sssd.conf was moved to
 /etc/sssd/sssd.conf.deleted
 nscd daemon is not installed, skip configuration
 nslcd daemon is not installed, skip configuration
 Client uninstall complete.
 2015-03-19T04:33:02Z INFO   File
 /usr/lib/python2.6/site-packages/ipaserver/install/installutils.py,
 line 614, in run_script
 return_value = main_function()
   File /usr/sbin/ipa-replica-install, line 536, in main
 raise RuntimeError(Failed to configure the client)
 2015-03-19T04:33:02Z INFO The ipa-replica-install command failed,
 exception: RuntimeError: Failed to configure the client

 Anyone have any advice?



I think the issue is related to this:

trying https://noc5-prd.companyz.com/ipa/xml
trying https://noc1-prd.companyz.com/ipa/xml

It would seem that the client NSS database isn't being properly shutdown
between connection attempts.

Is noc5 operational? If not then removing it from the SRV records would
probably be the fastest way to work around this.

What version of IPA is this?

 There are 2 possibilities here. One is you have the old python package
 scripts which have a bug in these files:
 
 /usr/lib/python2.7/site-packages/ipaplatform/fedora/services.py
 /usr/lib/python2.7/site-packages/ipaplatform/services.py
 
 They most likely have fedora-domain in them and it needs to be changed
 to rhel-domain.  The other option is to re-install the OS and freeipa
 environment, which gets you to clean packages.  Deleting and
 re-installing all the python packages is painful at best.

I think that was only a problem when trying to install 4.x in RHEL using
the upstream COPR repositories.

 
 The other possibility is stale certs:
 
 certutil -d /etc/pki/nssdb -L
 
 You will probably see a stale cert. Remove it.
 
 certutil -d /etc/pki/nssdb -D -n IPA CA
 
 I have run into both of these issues about 1 million times so far.

On a replica install it is always adding the same cert which shouldn't
be a problem:

# certutil -L -d /etc/pki/nssdb/

Certificate Nickname Trust
Attributes

SSL,S/MIME,JAR/XPI

IPA CA   CT,C,C
# certutil -A -n 'IPA CA' -t CT,C,C -a -i /etc/ipa/ca.crt  -d
/etc/pki/nssdb/
# echo $?
0

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] stupid question - 389-ds

Janelle wrote:
 Hello again,
 
 Ok, probably a stupid question. If you increase cache sizes and tune
 389-ds on the backend, do those changes replicate or do you need to make
 them across the other servers as well?
 
 For example:
 
 dn: cn=config,cn=ldbm database,cn=plugins,cn=config
 changetype: modify
 replace: nsslapd-dbcachesize
 nsslapd-dbcachesize: 2147483648

Changes to cn=config do not replicate so you'd need to make the same
change on other current masters (and future ones too).

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

[Freeipa-users] stupid question - 389-ds

2015-03-19 Thread Janelle


Hello again,

Ok, probably a stupid question. If you increase cache sizes and tune 
389-ds on the backend, do those changes replicate or do you need to make 
them across the other servers as well?


For example:

dn: cn=config,cn=ldbm database,cn=plugins,cn=config
changetype: modify
replace: nsslapd-dbcachesize
nsslapd-dbcachesize: 2147483648

~J


--
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] SSSD in redundant configuration

I am having problems with sudo and using _srv_ in the sssd config.

This works:

# For the SUDO integration

sudo_provider = ldap

ldap_uri = ldap://test-freeipa-1.cloud.domain.de

ldap_sudo_search_base = ou=sudoers,dc=cloud,dc=native-instruments,dc=de

ldap_sasl_mech = GSSAPI

ldap_sasl_authid = host/test-freeipa-client-3.cloud.domain.de

ldap_sasl_realm = CLOUD.DOMAIN.DE

krb5_server = test-freeipa-2.cloud.domain.de


This does not work:

# For the SUDO integration

sudo_provider = ldap

ldap_uri = _srv_

ldap_sudo_search_base = ou=sudoers,dc=cloud,dc=domain,dc=de

ldap_sasl_mech = GSSAPI

ldap_sasl_authid = host/test-freeipa-client-3.cloud.domain.de

ldap_sasl_realm = CLOUD.DOMAIN.DE

krb5_server = _srv_


Thanks,

Andrew


On 19 March 2015 at 10:29, Jakub Hrozek jhro...@redhat.com wrote:

 On Thu, Mar 19, 2015 at 08:42:42AM +0100, Andrew Holway wrote:
  Cool stuff. Thanks.
 
  I had a look at our SRV records and found the following:
  _kerberos-master._tcp
  _kerberos-master._udp
  _kerberos._tcp
  _kerberos._udp
  _kpasswd._tcp
  _kpasswd._udp
  _ldap._tcp
  _ntp._udp
 
  No mention of and ipa srv records. Does sssd use _ldap._tcp?

 Yes, for the IPA back end it does.

 For the AD back end we use the special MS records for looking up sites
 or Global Catalog servers, but for IPA we stick to the standard
 services.

 --
 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] Fwd: Re: AD -- FreeIPA Password Sync --- Peer reports incompatible or unsupported protocol

On 03/19/2015 05:10 AM, Gonzalo Fernandez Ordas wrote:

I have completed changed the scenario and I managed to install
freeipa-server 4.1 (Somebody publish the right repo for Centos and it
worked really well)

Yes, sorry, that was a typo.

So, starting again from scratch, new machine, the whole installation
process went well, not issues there but:

* FreeIPA is supposed to generate a PassSync user by running
ipa-replica-manage *--winsync **--passsync*=/PASSSYNC_PWD. (See also
man ipa-replica-manage).

I tried 5 times, the user was never created on the ipa server, I had
to create it manually (I gave it admin permissions so it could
create/delete/update users).
Doing that, the password sync worked all right. We submit a password
reset in AD and that propagated all right, tested and it worked fine.

Something is really messed up with the system.
Do you have some kind of backup and restore running in the background?
It seems that for some reason a kerberos (probably master) key was
rewritten in some way.

So.. that has been all so far

Thanks

Gonzalo

On 16/03/2015 20:05, Noriko Hosoi wrote:

Hello, Gonzalo,

Any progress on your Password Synchronization?

I'm sending this response to freeipa-users to share the info and
request for more suggestions.

Thanks,
--noriko

On 03/13/2015 02:48 PM, g.fer.or...@unicyber.co.uk wrote:

Re: [Freeipa-users] Synology DSM5 and freeIPA

On 03/19/2015 05:29 AM, Roberto Cornacchia wrote:
On 6 March 2015 at 11:15, Martin Kosek mko...@redhat.com
mailto:mko...@redhat.com wrote:

On 03/06/2015 10:56 AM, Roberto Cornacchia wrote:

Hi there,

I'm planning to deploy freeIPA on our lan.
It's small-ish and completely based on FC21, so I expect
everything to work
like a charm.

Except one detail. We have Synology NAS station, which uses
DSM 5.0.
The ideal plan is to use it as host for shared NFS home dirs
once we switch our
desktops to freeIPA.

Great!

Hello,

The first thing I'm struggling with is to find the correct approach
about NFS home dirs.

The ideal setting would be:
- home dirs on the NAS
- IPA manages automount maps
- home dirs are created automatically at first login

The documentation I could find on these topics includes only
not-so-recent pages (anything I missed?):

Now, I admit I don't have much experience with setting up NFS homes,
with or without freeIPA, so trying to get this done correctly in the
context of freeIPA and without clear howtos isn't very easy, but I'm
willing to get my hands dirty.

The first problem I struggle with is on the correct approach.
From the documentation above, I understand that there is a bit of a
chicken-egg problem about the creation of home dirs.
On the one hand, it would be optimal to have automount maps to load
only single home dirs on demand, rather than the entire /home tree.
On the other hand, if the /home tree is not available, then creating
/home/user1 dir automatically isn't really possible.

Just mounting the whole /home tree would make things easier, but I
don't have a feeling of when it starts to become a performance issue
(assuming recent hardware and up to date software). 10 users? 50? 100?
500? No idea.
The realm I'm dealing with at the moment is in the range of 5-10 users
and probably won't be larger than 50 in the next few years (and if it
will, it means things are going well, so what the heck ;)
Also true that, with such few users, I could just create the homedirs
manually when needed (this is not an organisation where many users
come and go) and just mount the individually.

Any tips about this?

Best, Roberto

Some of these questions are really outside the scope of this list.
You might consider asking them on the NFS list.

--
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

--
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] Problems with ssh and install-uninstall-install sequence on the server

2015-03-19 Thread Prasun Gera

I thought a bit more about the issue of conflicts in /var/lib/sss/db, and I
think it's a pretty significant problem, probably from a security
standpoint too. The fact that it's trying to authenticate against something
stale and incorrect would imply that it might erroneously authenticate
against something it should not. Also, this problem would lock out all
clients and be a nightmare to deal with if the master server needs to be
replaced/migrated.

On Thu, Mar 19, 2015 at 11:57 AM, Nalin Dahyabhai na...@redhat.com wrote:

 On Wed, Mar 18, 2015 at 05:55:52PM -0400, Rob Crittenden wrote:
   getcert status
   process 31282: arguments to dbus_message_new_method_call() were
   incorrect, assertion path != NULL failed in file dbus-message.c line
 1262.
   This is normally a bug in some application using the D-Bus library.
 D-Bus not built with -rdynamic so unable to print a backtrace
   Aborted (core dumped)
 
  Please open a bug against certmonger.

 I'm pretty sure this one's already being tracked as #1148001.

 Cheers,

 Nalin

-- 
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] Synology DSM5 and freeIPA

Hi Dmitri,

I do realise my question is borderline and I accept that it is considered
off-topic.

I did post it here because I believe it's not *only* about NFS, but also
about its interaction with freeIPA. The issue of NFS home and in particular
about their creation is touched in all the links I posted (all about
freeIPA) and never really answered.

Best,
Roberto

On 19 March 2015 at 19:36, Dmitri Pal d...@redhat.com wrote:

On 03/19/2015 05:29 AM, Roberto Cornacchia wrote:

On 6 March 2015 at 11:15, Martin Kosek mko...@redhat.com wrote:

On 03/06/2015 10:56 AM, Roberto Cornacchia wrote:

Hi there,

I'm planning to deploy freeIPA on our lan.
It's small-ish and completely based on FC21, so I expect everything to
work
like a charm.

Except one detail. We have Synology NAS station, which uses DSM 5.0.
The ideal plan is to use it as host for shared NFS home dirs once we
switch our
desktops to freeIPA.

Great!

Hello,

The first thing I'm struggling with is to find the correct approach
about NFS home dirs.
The ideal setting would be:
- home dirs on the NAS
- IPA manages automount maps
- home dirs are created automatically at first login

The documentation I could find on these topics includes only
not-so-recent pages (anything I missed?):

http://wiki.linux-nfs.org/wiki/index.php/NFS_and_FreeIPA

http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/automount.html

http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/users.html#home-directories
http://adam.younglogic.com/2011/06/automount-and-home-directory-creation/

Now, I admit I don't have much experience with setting up NFS homes,
with or without freeIPA, so trying to get this done correctly in the
context of freeIPA and without clear howtos isn't very easy, but I'm
willing to get my hands dirty.

Best, Roberto

Some of these questions are really outside the scope of this list.
You might consider asking them on the NFS list.

--
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

--
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] Problems with ssh and install-uninstall-install sequence on the server


 On 19 Mar 2015, at 20:09, Prasun Gera prasun.g...@gmail.com wrote:
 
 I thought a bit more about the issue of conflicts in /var/lib/sss/db, and I 
 think it's a pretty significant problem, probably from a security standpoint 
 too. The fact that it's trying to authenticate against something stale and 
 incorrect would imply that it might erroneously authenticate against 
 something it should not. Also, this problem would lock out all clients and be 
 a nightmare to deal with if the master server needs to be replaced/migrated. 
 

I'm sorry to come late into this thread, but from the subject it wasn't clear 
it's also about SSSD.

Can you describe the problem better? How did you manage to create conflicts in 
sssd database?

 On Thu, Mar 19, 2015 at 11:57 AM, Nalin Dahyabhai na...@redhat.com wrote:
 On Wed, Mar 18, 2015 at 05:55:52PM -0400, Rob Crittenden wrote:
   getcert status
   process 31282: arguments to dbus_message_new_method_call() were
   incorrect, assertion path != NULL failed in file dbus-message.c line 
   1262.
   This is normally a bug in some application using the D-Bus library.
 D-Bus not built with -rdynamic so unable to print a backtrace
   Aborted (core dumped)
 
  Please open a bug against certmonger.
 
 I'm pretty sure this one's already being tracked as #1148001.
 
 Cheers,
 
 Nalin
 
 -- 
 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] Synology DSM5 and freeIPA

On 19 Mar 2015, at 21:18, Roberto Cornacchia roberto.cornacc...@gmail.com
wrote:

It's possible that I'm simply not getting the point, or that I don't
understand the documentation correctly, but this is what I don't find clear:

I had seen the instructions you pointed me at. These are not specifically
about home directories.

However, this section is:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#homedir-reqs

It first suggests that automatic creation of home directories over NFS shares
is possible: just automount /home and then use pam_oddjob_mkhomedir or
pam_mkhomedir to create homedirs at first login.

But then it also suggests that mounting the whole /home tree could be an
issue, and says: Use automount to mount only the user's home directory and
only when the user logs in, rather than loading the entire /home tree.

That means that automatic homedir creation is out of the game, doesn't it?

That's what I find confusing. What's the recommended way?

It really depends on your environment. For your size, it's perfectly fine to
NFS mount the whole /home tree and be done with it. Don't optimize prematurely
:-)

On 19 March 2015 at 20:49, Dmitri Pal d...@redhat.com wrote:
On 03/19/2015 02:46 PM, Roberto Cornacchia wrote:
Hi Dmitri,

I do realise my question is borderline and I accept that it is considered
off-topic.

I did post it here because I believe it's not *only* about NFS, but also
about its interaction with freeIPA. The issue of NFS home and in particular
about their creation is touched in all the links I posted (all about
freeIPA) and never really answered.

This is what documented and recommended:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#kerb-nfs

RHEL6 has a similar chapter in its doc set though books have changed
significantly between 6 and 7.

I do not see any chicken and egg problem there.
The instructions show how to create home dirs on the first login.

It mounts the volume and then creates dirs on it as users log in if they are
not already there.

It is unclear what problem you see with doing it the way it is recommended.

Best,
Roberto

On 19 March 2015 at 19:36, Dmitri Pal d...@redhat.com wrote:
On 03/19/2015 05:29 AM, Roberto Cornacchia wrote:
On 6 March 2015 at 11:15, Martin Kosek mko...@redhat.com wrote:
On 03/06/2015 10:56 AM, Roberto Cornacchia wrote:
Hi there,

I'm planning to deploy freeIPA on our lan.
It's small-ish and completely based on FC21, so I expect everything to work
like a charm.

Except one detail. We have Synology NAS station, which uses DSM 5.0.
The ideal plan is to use it as host for shared NFS home dirs once we switch
our
desktops to freeIPA.

Great!

Hello,

The documentation I could find on these topics includes only not-so-recent
pages (anything I missed?):

Best, Roberto

Some of these

Re: [Freeipa-users] ipa-client-install failure


On 03/19/2015 04:46 PM, Roberto Cornacchia wrote:

Hi,

This should really work like a charm, and I'm sure it is a stupid 
mistake of mine if it doesn't, but I really can't find out what goes 
wrong.


Both IPA server and client are on FC21, very up to date.
Server installation (standard, with dns) worked well. Required ports 
open in the firewall. Everything seems to work.


I did try to use the IPA server as a DNS (with forwarders) and NTP 
server from non-ipa clients, no problem.
I also tried to use it as LDAP server, from a non-fedora machine (a 
synology). It worked well and I could see users.


When trying to enroll a client, the enrollment itself seems to 
succeed, but:

- Unable to sync time with NTP server
- Unable to update DNS
- Unable to find users

I include below the short installation log (I changed the real domain 
into hq.example.com http://hq.example.com), and in attachment, the 
full log with debug on.


From the debug log, about the DNS update failure, I can see this:

  ; Communication with 192.168.0.72#53 failed: operation canceled
  could not reach any name server

I'm not sure what communication problem this could be, as the server 
(which is both the IPA and the DNS servers), clearly can be reached.


Any idea where to look at?


Do you have the IPA DNS server in the resolv.conf of the client?




Thanks,
Roberto


[root@meson ~]# ipa-client-install --mkhomedir --ssh-trust-dns 
--force-ntpd --hostname=meson.hq.example.com 
http://meson.hq.example.com

Discovery was successful!
Hostname: meson.hq.example.com http://meson.hq.example.com
Realm: HQ.EXAMPLE.COM http://HQ.EXAMPLE.COM
DNS Domain: hq.example.com http://hq.example.com
IPA Server: ipa.hq.example.com http://ipa.hq.example.com
BaseDN: dc=hq,dc=example,dc=com

Continue to configure the system with these values? [no]: yes
Synchronizing time with KDC...
*Unable to sync time with IPA NTP server, assuming the time is in 
sync. Please check that 123 UDP port is opened.*

User authorized to enroll computers: admin
Password for ad...@hq.example.com mailto:ad...@hq.example.com:
Successfully retrieved CA cert
Subject: CN=Certificate Authority,O=HQ.EXAMPLE.COM 
http://HQ.EXAMPLE.COM
Issuer:  CN=Certificate Authority,O=HQ.EXAMPLE.COM 
http://HQ.EXAMPLE.COM

Valid From:  Mon Mar 16 18:44:35 2015 UTC
Valid Until: Fri Mar 16 18:44:35 2035 UTC

Enrolled in IPA realm HQ.EXAMPLE.COM http://HQ.EXAMPLE.COM
Created /etc/ipa/default.conf
New SSSD config will be created
Configured sudoers in /etc/nsswitch.conf
Configured /etc/sssd/sssd.conf
Configured /etc/krb5.conf for IPA realm HQ.EXAMPLE.COM 
http://HQ.EXAMPLE.COM

trying https://ipa.hq.example.com/ipa/json
Forwarding 'ping' to json server 'https://ipa.hq.example.com/ipa/json'
Forwarding 'ca_is_enabled' to json server 
'https://ipa.hq.example.com/ipa/json'

Systemwide CA database updated.
Added CA certificates to the default NSS database.
Hostname (meson.hq.example.com http://meson.hq.example.com) not 
found in DNS

*Failed to update DNS records.*
Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub
Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub
Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub
Forwarding 'host_mod' to json server 'https://ipa.hq.example.com/ipa/json'
*Could not update DNS SSHFP records.*
SSSD enabled
Configured /etc/openldap/ldap.conf
*Unable to find 'admin' user with 'getent passwd ad...@hq.example.com 
mailto:ad...@hq.example.com'!*

*Unable to reliably detect configuration. Check NSS setup manually.*
NTP enabled
Configured /etc/ssh/ssh_config
Configured /etc/ssh/sshd_config
Configuring hq.example.com http://hq.example.com as NIS domain.
Client configuration complete.






--
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

-- 
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] Synology DSM5 and freeIPA

It's possible that I'm simply not getting the point, or that I don't
understand the documentation correctly, but this is what I don't find clear:

I had seen the instructions you pointed me at. These are not specifically
about home directories.

However, this section is:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#homedir-reqs

It first suggests that automatic creation of home directories over NFS
shares is possible: just automount /home and then use pam_oddjob_mkhomedir
or pam_mkhomedir to create homedirs at first login.

But then it also suggests that mounting the whole /home tree could be an
issue, and says: *Use automount to mount only the user's home directory
and only when the user logs in, rather than loading the entire /home tree.*

That means that automatic homedir creation is out of the game, doesn't it?

That's what I find confusing. What's the recommended way?

On 19 March 2015 at 20:49, Dmitri Pal d...@redhat.com wrote:

On 03/19/2015 02:46 PM, Roberto Cornacchia wrote:

Hi Dmitri,

I do realise my question is borderline and I accept that it is
considered off-topic.

I did post it here because I believe it's not *only* about NFS, but also
about its interaction with freeIPA. The issue of NFS home and in particular
about their creation is touched in all the links I posted (all about
freeIPA) and never really answered.

This is what documented and recommended:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#kerb-nfs

RHEL6 has a similar chapter in its doc set though books have changed
significantly between 6 and 7.

I do not see any chicken and egg problem there.
The instructions show how to create home dirs on the first login.

It mounts the volume and then creates dirs on it as users log in if they
are not already there.

It is unclear what problem you see with doing it the way it is recommended.

Best,
Roberto

On 19 March 2015 at 19:36, Dmitri Pal d...@redhat.com wrote:

On 03/19/2015 05:29 AM, Roberto Cornacchia wrote:

On 6 March 2015 at 11:15, Martin Kosek mko...@redhat.com wrote:

On 03/06/2015 10:56 AM, Roberto Cornacchia wrote:

Hi there,

I'm planning to deploy freeIPA on our lan.
It's small-ish and completely based on FC21, so I expect everything to
work
like a charm.

Except one detail. We have Synology NAS station, which uses DSM 5.0.
The ideal plan is to use it as host for shared NFS home dirs once we
switch our
desktops to freeIPA.

Great!

Hello,

The first thing I'm struggling with is to find the correct approach
about NFS home dirs.
The ideal setting would be:
- home dirs on the NAS
- IPA manages automount maps
- home dirs are created automatically at first login

The documentation I could find on these topics includes only
not-so-recent pages (anything I missed?):

http://wiki.linux-nfs.org/wiki/index.php/NFS_and_FreeIPA

http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/automount.html

http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/users.html#home-directories

http://adam.younglogic.com/2011/06/automount-and-home-directory-creation/

Now, I admit I don't have much experience with setting up NFS homes,
with or without freeIPA, so trying to get this done correctly in the
context of freeIPA and without clear howtos isn't very easy, but I'm
willing to get my hands dirty.

Just mounting the whole /home tree would make things easier, but I
don't have a feeling of when it starts to become a performance issue
(assuming recent hardware and up to date software). 10 users? 50? 100? 500?
No idea.
The realm I'm dealing with at the moment is in the range of 5-10 users
and probably won't be larger than 50 in the next few years (and if it will,
it means things are going well, so what the heck ;)
Also true that, with such few users, I could just create the homedirs
manually when needed (this is not an organisation where many users come and
go) and just mount the individually.
Any tips about this?

Best, Roberto

Some of these questions are really outside the scope of this list.
You might consider asking them on the NFS list.

--
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

--
Manage your subscription for the Freeipa-users mailing list:

[Freeipa-users] ipa-client-install failure

Hi,

This should really work like a charm, and I'm sure it is a stupid mistake
of mine if it doesn't, but I really can't find out what goes wrong.

Both IPA server and client are on FC21, very up to date.
Server installation (standard, with dns) worked well. Required ports open
in the firewall. Everything seems to work.

I did try to use the IPA server as a DNS (with forwarders) and NTP server
from non-ipa clients, no problem.
I also tried to use it as LDAP server, from a non-fedora machine (a
synology). It worked well and I could see users.

When trying to enroll a client, the enrollment itself seems to succeed, but:
- Unable to sync time with NTP server
- Unable to update DNS
- Unable to find users

I include below the short installation log (I changed the real domain into
hq.example.com), and in attachment, the full log with debug on.

From the debug log, about the DNS update failure, I can see this:

  ; Communication with 192.168.0.72#53 failed: operation canceled
  could not reach any name server

I'm not sure what communication problem this could be, as the server (which
is both the IPA and the DNS servers), clearly can be reached.

Any idea where to look at?

Thanks,
Roberto


[root@meson ~]# ipa-client-install --mkhomedir --ssh-trust-dns --force-ntpd
--hostname=meson.hq.example.com
Discovery was successful!
Hostname: meson.hq.example.com
Realm: HQ.EXAMPLE.COM
DNS Domain: hq.example.com
IPA Server: ipa.hq.example.com
BaseDN: dc=hq,dc=example,dc=com

Continue to configure the system with these values? [no]: yes
Synchronizing time with KDC...
*Unable to sync time with IPA NTP server, assuming the time is in sync.
Please check that 123 UDP port is opened.*
User authorized to enroll computers: admin
Password for ad...@hq.example.com:
Successfully retrieved CA cert
Subject: CN=Certificate Authority,O=HQ.EXAMPLE.COM
Issuer:  CN=Certificate Authority,O=HQ.EXAMPLE.COM
Valid From:  Mon Mar 16 18:44:35 2015 UTC
Valid Until: Fri Mar 16 18:44:35 2035 UTC

Enrolled in IPA realm HQ.EXAMPLE.COM
Created /etc/ipa/default.conf
New SSSD config will be created
Configured sudoers in /etc/nsswitch.conf
Configured /etc/sssd/sssd.conf
Configured /etc/krb5.conf for IPA realm HQ.EXAMPLE.COM
trying https://ipa.hq.example.com/ipa/json
Forwarding 'ping' to json server 'https://ipa.hq.example.com/ipa/json'
Forwarding 'ca_is_enabled' to json server '
https://ipa.hq.example.com/ipa/json'
Systemwide CA database updated.
Added CA certificates to the default NSS database.
Hostname (meson.hq.example.com) not found in DNS
*Failed to update DNS records.*
Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub
Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub
Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub
Forwarding 'host_mod' to json server 'https://ipa.hq.example.com/ipa/json'
*Could not update DNS SSHFP records.*
SSSD enabled
Configured /etc/openldap/ldap.conf
*Unable to find 'admin' user with 'getent passwd ad...@hq.example.com
ad...@hq.example.com'!*
*Unable to reliably detect configuration. Check NSS setup manually.*
NTP enabled
Configured /etc/ssh/ssh_config
Configured /etc/ssh/sshd_config
Configuring hq.example.com as NIS domain.
Client configuration complete.
/usr/sbin/ipa-client-install was invoked with options: {'domain': None, 'force': False, 'krb5_offline_passwords': True, 'configure_firefox': False, 'primary': False, 'conf_sudo': True, 'force_ntpd': True, 'create_sshfp': True, 'conf_sshd': True, 'conf_ntp': True, 'on_master': False, 'no_nisdomain': False, 'nisdomain': None, 'ntp_server': None, 'principal': None, 'keytab': None, 'hostname': 'meson.hq.example.com', 'request_cert': False, 'no_ac': False, 'unattended': None, 'location': None, 'sssd': True, 'trust_sshfp': True, 'dns_updates': True, 'realm_name': None, 'conf_ssh': True, 'force_join': False, 'firefox_dir': None, 'ca_cert_file': None, 'server': None, 'prompt_password': False, 'permit': False, 'debug': True, 'preserve_sssd': False, 'mkhomedir': True, 'uninstall': False}
missing options might be asked for interactively later
IPA version 4.1.3-2.fc21
Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index'
Loading StateFile from '/var/lib/ipa-client/sysrestore/sysrestore.state'
[IPA Discovery]
Starting IPA discovery with domain=None, servers=None, hostname=meson.hq.example.com
Start searching for LDAP SRV record in hq.example.com (domain of the hostname) and its sub-domains
Search DNS for SRV record of _ldap._tcp.hq.example.com
DNS record found: 0 100 389 ipa.hq.example.com.
[Kerberos realm search]
Search DNS for TXT record of _kerberos.hq.example.com
DNS record found: HQ.EXAMPLE.COM
Search DNS for SRV record of _kerberos._udp.hq.example.com
DNS record found: 0 100 88 ipa.hq.example.com.
[LDAP server check]
Verifying that ipa.hq.example.com (realm HQ.EXAMPLE.COM) is an IPA server
Init LDAP connection to: ipa.hq.example.com
Search LDAP server for IPA base DN
Check if naming context

Re: [Freeipa-users] Synology DSM5 and freeIPA

Thanks, Jakub.

On 19 March 2015 at 21:23, Jakub Hrozek jhro...@redhat.com wrote:

On 19 Mar 2015, at 21:18, Roberto Cornacchia
roberto.cornacc...@gmail.com wrote:

It's possible that I'm simply not getting the point, or that I don't
understand the documentation correctly, but this is what I don't find clear:

I had seen the instructions you pointed me at. These are not
specifically about home directories.

However, this section is:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#homedir-reqs

It first suggests that automatic creation of home directories over NFS
shares is possible: just automount /home and then use pam_oddjob_mkhomedir
or pam_mkhomedir to create homedirs at first login.

That means that automatic homedir creation is out of the game, doesn't
it?

That's what I find confusing. What's the recommended way?

It really depends on your environment. For your size, it's perfectly fine
to NFS mount the whole /home tree and be done with it. Don't optimize
prematurely :-)

On 19 March 2015 at 20:49, Dmitri Pal d...@redhat.com wrote:
On 03/19/2015 02:46 PM, Roberto Cornacchia wrote:
Hi Dmitri,

I do realise my question is borderline and I accept that it is
considered off-topic.

This is what documented and recommended:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#kerb-nfs

RHEL6 has a similar chapter in its doc set though books have changed
significantly between 6 and 7.

I do not see any chicken and egg problem there.
The instructions show how to create home dirs on the first login.

It mounts the volume and then creates dirs on it as users log in if they
are not already there.

It is unclear what problem you see with doing it the way it is
recommended.

Best,
Roberto

I'm planning to deploy freeIPA on our lan.
It's small-ish and completely based on FC21, so I expect everything to
work
like a charm.

Except one detail. We have Synology NAS station, which uses DSM 5.0.
The ideal plan is to use it as host for shared NFS home dirs once we
switch our
desktops to freeIPA.

Great!

Hello,

The first thing I'm struggling with is to find the correct approach
about NFS home dirs.
The ideal setting would be:
- home dirs on the NAS
- IPA manages automount maps
- home dirs are created automatically at first login

The documentation I could find on these topics includes only
not-so-recent pages (anything I missed?):

http://wiki.linux-nfs.org/wiki/index.php/NFS_and_FreeIPA

http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/automount.html

http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/users.html#home-directories

http://adam.younglogic.com/2011/06/automount-and-home-directory-creation/

Now, I admit I don't have much experience with setting up NFS homes,
with or without freeIPA, so trying to get this done correctly in the
context of freeIPA and without clear howtos isn't very easy, but I'm
willing to get my hands dirty.

The first problem I struggle with is on the correct approach.
From the documentation above, I understand that there is a bit of a
chicken-egg problem about the creation of home dirs.
On the one hand, it would be optimal to have automount maps to load
only single home dirs on demand, rather than the entire /home tree.
On the other hand, if the /home tree is not available, then creating
/home/user1 dir automatically isn't really possible.

Just mounting the whole /home tree would make things easier, but I
don't have a feeling of when it starts to become a performance issue
(assuming recent hardware and up to date software). 10 users? 50? 100? 500?
No idea.
The realm I'm dealing with at the moment is in the range of 5-10 users
and probably won't be larger than 50 in the next few years (and if it will,
it means things are going well, so what the heck ;)
Also true that, with such few users, I could just create the homedirs
manually when needed (this is not an organisation where many

Re: [Freeipa-users] ipa-client-install failure


 [root@meson ~]# dig ipa.hq.spinque.com


 humph, sorry about the confusion, I missed one in my anonymisation step..
that would be dig ipa.hq.example.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] ipa-client-install failure

Yes.

[root@meson ~]# cat /etc/resolv.conf
search hq.example.com
nameserver 192.168.0.72

Sorry from the short log I posted it's not visible, but that ip address is
the address of the ipa server (ipa.hq.example.com)

[root@meson ~]# dig ipa.hq.spinque.com

;  DiG 9.9.6-P1-RedHat-9.9.6-8.P1.fc21  ipa.hq.example.com
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 53238
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ipa.hq.example.com. IN A

;; ANSWER SECTION:
ipa.hq.example.com. 1200 IN A 192.168.0.72

;; AUTHORITY SECTION:
hq.example.com. 86400 IN NS ipa.hq.example.com.

;; Query time: 1 msec
;; SERVER: 192.168.0.72#53(192.168.0.72)
;; WHEN: do mrt 19 22:02:04 CET 2015
;; MSG SIZE  rcvd: 83


On 19 March 2015 at 21:55, Dmitri Pal d...@redhat.com wrote:

  On 03/19/2015 04:46 PM, Roberto Cornacchia wrote:

  Hi,

  This should really work like a charm, and I'm sure it is a stupid
 mistake of mine if it doesn't, but I really can't find out what goes wrong.

  Both IPA server and client are on FC21, very up to date.
 Server installation (standard, with dns) worked well. Required ports open
 in the firewall. Everything seems to work.

  I did try to use the IPA server as a DNS (with forwarders) and NTP
 server from non-ipa clients, no problem.
 I also tried to use it as LDAP server, from a non-fedora machine (a
 synology). It worked well and I could see users.

  When trying to enroll a client, the enrollment itself seems to succeed,
 but:
 - Unable to sync time with NTP server
 - Unable to update DNS
 - Unable to find users

  I include below the short installation log (I changed the real domain
 into hq.example.com), and in attachment, the full log with debug on.

  From the debug log, about the DNS update failure, I can see this:

; Communication with 192.168.0.72#53 failed: operation canceled
   could not reach any name server

  I'm not sure what communication problem this could be, as the server
 (which is both the IPA and the DNS servers), clearly can be reached.

  Any idea where to look at?


 Do you have the IPA DNS server in the resolv.conf of the client?




  Thanks,
 Roberto


  [root@meson ~]# ipa-client-install --mkhomedir --ssh-trust-dns
 --force-ntpd --hostname=meson.hq.example.com
 Discovery was successful!
 Hostname: meson.hq.example.com
 Realm: HQ.EXAMPLE.COM
 DNS Domain: hq.example.com
 IPA Server: ipa.hq.example.com
 BaseDN: dc=hq,dc=example,dc=com

  Continue to configure the system with these values? [no]: yes
 Synchronizing time with KDC...
 *Unable to sync time with IPA NTP server, assuming the time is in sync.
 Please check that 123 UDP port is opened.*
 User authorized to enroll computers: admin
 Password for ad...@hq.example.com:
 Successfully retrieved CA cert
 Subject: CN=Certificate Authority,O=HQ.EXAMPLE.COM
 Issuer:  CN=Certificate Authority,O=HQ.EXAMPLE.COM
 Valid From:  Mon Mar 16 18:44:35 2015 UTC
 Valid Until: Fri Mar 16 18:44:35 2035 UTC

  Enrolled in IPA realm HQ.EXAMPLE.COM
 Created /etc/ipa/default.conf
 New SSSD config will be created
 Configured sudoers in /etc/nsswitch.conf
 Configured /etc/sssd/sssd.conf
 Configured /etc/krb5.conf for IPA realm HQ.EXAMPLE.COM
 trying https://ipa.hq.example.com/ipa/json
 Forwarding 'ping' to json server 'https://ipa.hq.example.com/ipa/json'
 Forwarding 'ca_is_enabled' to json server '
 https://ipa.hq.example.com/ipa/json'
 Systemwide CA database updated.
 Added CA certificates to the default NSS database.
 Hostname (meson.hq.example.com) not found in DNS
 *Failed to update DNS records.*
 Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub
 Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub
 Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub
 Forwarding 'host_mod' to json server 'https://ipa.hq.example.com/ipa/json'
 *Could not update DNS SSHFP records.*
 SSSD enabled
 Configured /etc/openldap/ldap.conf
 *Unable to find 'admin' user with 'getent passwd ad...@hq.example.com
 ad...@hq.example.com'!*
 *Unable to reliably detect configuration. Check NSS setup manually.*
 NTP enabled
 Configured /etc/ssh/ssh_config
 Configured /etc/ssh/sshd_config
 Configuring hq.example.com as NIS domain.
 Client configuration complete.





 --
 Thank you,
 Dmitri Pal

 Sr. Engineering Manager IdM portfolio
 Red Hat, Inc.


 --
 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] SSSD in redundant configuration



 I wasn't precise enough, I meant the sssd version, sorry. But given that
 you're on RHEL-7, I think you can switch to:
 sudo_provider=ipa


That does indeed seem to work. Thanks!



 and remove all the ldap_ config parameters as well as krb5_server.

-- 
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] Email address for directory admin

2015-03-19 Thread Giedrius Tuminauskas

Thank you Rob, it worked like a charm.


Giedrius 

At Thursday, 19-03-2015 on 13:41 Martin Kosek wrote:


On 03/19/2015 02:36 PM, Rob Crittenden wrote:
 Giedrius Tuminauskas wrote:
 Hi,

 I am curious, Is there a possibility to add email address for the
 admin user in the IPA web UI?
 In my current configuration admin user is a Linux system user and
also
 used by IPA.
 I think there should be possibility to enter an email address for
that
 user, but UI has no button/link (add)

 Is it expected behavior?
 Can you please suggest some tweaks, how to add it?
 
 Not easily from the UI but possible from the cli. The admin user
lacks
 the inetOrgPerson objectclass which provides the mail attribute.
 
 I haven't given this a great deal of thought so can't guarantee that
 there won't be any subtle issues now or in the future, but given
that
 this objectclass only has MAY attributes is should be ok.
 
 $ kinit admin
 $ ipa user-mod --email ad...@example.com --addattr
 objectclass=inetorgperson admin
 
 rob

Related closed tickets with reasoning why this is not done by default:

https://fedorahosted.org/freeipa/ticket/4941
https://fedorahosted.org/freeipa/ticket/1162

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] 'Preauthentication failed' with SSSD in ipa_server_mode

2015-03-19 Thread Bobby Prins

On Thu, Mar 19, 2015 at 04:46:44PM +0100, Bobby Prins wrote:
 Hi there,
 
 I'm currently trying to use the 'AD Trust for Legacy Clients' freeIPA setup 
 (described here: 
 http://www.freeipa.org/images/0/0d/FreeIPA33-legacy-clients.pdf) to be able 
 to autenticate AIX 7.1 clients against an AD domain using LDAP. After the 
 trust was created all seems to work well on the freeIPA server. I can also 
 do a lookup of AD users and groups on an AIX test server.
 
 But as soon as I want to log in on the AIX system I get an SSSD error on the 
 freeIPA server in krb5_child.log (debug_level = 10):
 (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
 [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590260: AS key 
 obtained for encrypted timestamp: aes256-cts/2F5D
 (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
 [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590326: Encrypted 
 timestamp (for 1426778442.525165): plain 
 301AA011180F32303135303331393135323034325AA105020308036D, encrypted 
 9B3299264F09E50D63D84B385A09A4C64D44116A02B58FFF12830B39F88722CD9B792F5ABA0653578DE9138B91D29C17C197453D8B8A5E7A
 (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
 [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590349: Preauth 
 module encrypted_timestamp (2) (flags=1) returned: 0/Success
 (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
 [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590360: Produced 
 preauth for next request: 2
 (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
 [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590384: Sending 
 request (238 bytes) to EXAMPLE.CORP
 (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
 [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.591325: Resolving 
 hostname dct020.example.corp.
 (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
 [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.591889: Sending 
 initial UDP request to dgram 192.168.143.1:88
 (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
 [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636127: Received 
 answer from dgram 192.168.143.1:88
 (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
 [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636626: Response was 
 not from master KDC
 (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
 [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636667: Received 
 error from KDC: -1765328360/Preauthentication failed
 (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
 [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636698: Preauth 
 tryagain input types: 16, 14, 19, 2
 (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
 [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636728: Retrying AS 
 request with master KDC
 (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
 [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636741: Getting 
 initial credentials for bpr...@example.corp
 (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
 [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636787: Sending 
 request (160 bytes) to EXAMPLE.CORP (master)
 (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 [get_and_save_tgt] 
 (0x0020): 979: [-1765328360][Preauthentication failed]
 (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 [map_krb5_error] 
 (0x0020): 1040: [-1765328360][Preauthentication failed]
 (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 [k5c_send_data] 
 (0x0200): Received error code 1432158214
 
 If I do the same with 'KRB5_TRACE=/dev/stderr kinit bpr...@example.corp':

Can you test if kinit -C -E makes any difference?

KRB5_TRACE=/dev/stderr kinit -C -E bpr...@example.corp output:
[12994] 1426781014.22372: Resolving unique ccache of type KEYRING
[12994] 1426781014.22420: Getting initial credentials for 
BPrins\@example.c...@unix.example.corp
[12994] 1426781014.24809: Sending request (182 bytes) to UNIX.EXAMPLE.CORP
[12994] 1426781014.25036: Sending initial UDP request to dgram 
192.168.140.133:88
[12994] 1426781014.26345: Received answer from dgram 192.168.140.133:88
[12994] 1426781014.26381: Response was from master KDC
[12994] 1426781014.26402: Received error from KDC: -1765328378/Client not found 
in Kerberos database
kinit: Client 'BPrins\@example.c...@unix.example.corp' not found in Kerberos 
database while getting initial credentials


 [12299] 1426773524.361785: AS key obtained for encrypted timestamp: 
 aes256-cts/B997
 [12299] 1426773524.361850: Encrypted timestamp (for 1426773524.277583): 
 plain 301AA011180F32303135303331393133353834345AA1050203043C4F, encrypted 
 ED9CF995617740C4B14DB9CC84187E3505B664FE5C0AD16D19477E912F5400FB2C4665A090E3A37CD749535B3C80595809E14D15CB3527C0
 [12299] 1426773524.361876: Preauth module encrypted_timestamp (2) (flags=1) 
 returned: 0/Success
 [12299] 1426773524.361880: Produced preauth for next request: 2
 [12299] 1426773524.361901: Sending request (238 bytes) to

Re: [Freeipa-users] Problems with ssh and install-uninstall-install sequence on the server

2015-03-19 Thread Nalin Dahyabhai

On Wed, Mar 18, 2015 at 05:55:52PM -0400, Rob Crittenden wrote:
  getcert status
  process 31282: arguments to dbus_message_new_method_call() were
  incorrect, assertion path != NULL failed in file dbus-message.c line 1262.
  This is normally a bug in some application using the D-Bus library.
D-Bus not built with -rdynamic so unable to print a backtrace
  Aborted (core dumped)
 
 Please open a bug against certmonger.

I'm pretty sure this one's already being tracked as #1148001.

Cheers,

Nalin

-- 
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] Really slow logins with AD SID Mapping vs. POSIX

2015-03-19 Thread Gould, Joshua

I¹m seeing ssh logins for AD users take MUCH longer when using SID mapping
vs. POSIX attributes. Both myself and our AD admin would prefer to use SID
mapping. It appears tied to the group lookup at login. There seem to be
many posts about it, but I haven¹t found anything to help much. sssd pegs
the CPU for the 15 or so seconds the login takes.

Ex w/ SID mapping AD trust:
Mar 19 10:48:25 mid-ipa-vp01 sshd[16198]: pam_unix(sshd:auth):
authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
rhost=10.134.49.32  user=gould@test.osuwmc
Mar 19 10:48:28 mid-ipa-vp01 sshd[16198]: pam_sss(sshd:auth):
authentication success; logname= uid=0 euid=0 tty=ssh ruser=
rhost=10.134.49.32 user=gould@test.osuwmc
Mar 19 10:48:34 mid-ipa-vp01 sshd[16198]: Accepted password for
goul09@test.osuwmc from 10.134.49.32 port 56844 ssh2
Mar 19 10:48:38 mid-ipa-vp01 sshd[16198]: pam_unix(sshd:session): session
opened for user goul09@test.osuwmc by (uid=0)


Ex w/ POSIX AD trust
Mar 16 14:27:52 mid-ipa-vp01 sshd[13723]: pam_unix(sshd:auth):
authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
rhost=10.134.49.96  user=gould@test.osuwmc
Mar 16 14:27:55 mid-ipa-vp01 sshd[13723]: pam_sss(sshd:auth):
authentication success; logname= uid=0 euid=0 tty=ssh ruser=
rhost=10.134.49.96 user=gould@test.osuwmc
Mar 16 14:28:01 mid-ipa-vp01 sshd[13723]: Accepted password for
gould@test.osuwmc from 10.134.49.96 port 61401 ssh2
Mar 16 14:28:05 mid-ipa-vp01 sshd[13723]: pam_unix(sshd:session): session
opened for user goul09@test.osuwmc by (uid=0)


Exact same sssd.conf file for both configs.

[domain/unix.test.osuwmc]
debug_level = 9
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = unix.test.osuwmc
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = mid-ipa-vp01.unix.test.osuwmc
chpass_provider = ipa
ipa_server = mid-ipa-vp01.unix.test.osuwmc
ipa_server_mode = True
ldap_tls_cacert = /etc/ipa/ca.crt
ldap_referrals = false

#[domain/test.osuwmc]

[sssd]
services = nss, sudo, pam, ssh, pac
config_file_version = 2

domains = unix.test.osuwmc
[nss]
homedir_substring = /home

[pam]

[sudo]

[autofs]

[ssh]

[pac]

[ifp]








-- 
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] Really slow logins with AD SID Mapping vs. POSIX

2015-03-19 Thread Gould, Joshua

RHEL 7.0 fully up to date.

sssd-krb5-common-1.12.2-58.el7.x86_64
sssd-ipa-1.12.2-58.el7.x86_64
sssd-1.12.2-58.el7.x86_64
sssd-tools-1.12.2-58.el7.x86_64
sssd-common-1.12.2-58.el7.x86_64
sssd-ad-1.12.2-58.el7.x86_64
sssd-krb5-1.12.2-58.el7.x86_64
sssd-ldap-1.12.2-58.el7.x86_64
sssd-client-1.12.2-58.el7.x86_64
sssd-common-pac-1.12.2-58.el7.x86_64
sssd-proxy-1.12.2-58.el7.x86_64



On 3/19/15, 11:23 AM, Jakub Hrozek jhro...@redhat.com wrote:

On Thu, Mar 19, 2015 at 11:05:45AM -0400, Gould, Joshua wrote:
 I¹m seeing ssh logins for AD users take MUCH longer when using SID
mapping
 vs. POSIX attributes. Both myself and our AD admin would prefer to use
SID
 mapping. It appears tied to the group lookup at login. There seem to be
 many posts about it, but I haven¹t found anything to help much. sssd
pegs
 the CPU for the 15 or so seconds the login takes.

You haven't said what OS or release are you running, but for 7.0 I have
test packages with a proposed enhancement Sumit wrote:

https://urldefense.proofpoint.com/v2/url?u=https-3A__jhrozek.fedorapeople.
org_sssd-2Dtest-2Dbuilds_sssd-2D7.0-2Dlogin-2Dspeedup_d=AwIFAwc=k9MF1d71
ITtkuJx-PdWme51dKbmfPEvxwt8SFEkBfs4r=C8H0y1Bn8C6Mf5i9qrqkUDy3xSk8zPbIs_Sv
JwojC24m=YA1l-b8irE5VE9qVc1q4PY8RVJA2iLwWLK_U7aXS1gss=bYcFLFGsd6BT_1ozcn
1r1WaYFWJ4_5xT5ddR7d45Z08e=

Please include the versions of the problematic packages in the future
requests for troubleshooting.

-- 
Manage your subscription for the Freeipa-users mailing list:
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.redhat.com_mailma
n_listinfo_freeipa-2Dusersd=AwIFAwc=k9MF1d71ITtkuJx-PdWme51dKbmfPEvxwt8S
FEkBfs4r=C8H0y1Bn8C6Mf5i9qrqkUDy3xSk8zPbIs_SvJwojC24m=YA1l-b8irE5VE9qVc1
q4PY8RVJA2iLwWLK_U7aXS1gss=uJUobRCfTZ-jS6M4XSLW8ScMXv_1sIQ-OSoy54M7b2ke=
 
Go to 
https://urldefense.proofpoint.com/v2/url?u=http-3A__freeipa.orgd=AwIFAwc
=k9MF1d71ITtkuJx-PdWme51dKbmfPEvxwt8SFEkBfs4r=C8H0y1Bn8C6Mf5i9qrqkUDy3xSk
8zPbIs_SvJwojC24m=YA1l-b8irE5VE9qVc1q4PY8RVJA2iLwWLK_U7aXS1gss=F_LQz74bb
hG6_BKutjgbdRMTvIBRYggIgNj1QZoEznwe=  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] Really slow logins with AD SID Mapping vs. POSIX

On Thu, Mar 19, 2015 at 11:31:16AM -0400, Gould, Joshua wrote:
 RHEL 7.0 fully up to date.

Are you sure? Looks like 7.1 to me based on the NVRs.

 
 sssd-krb5-common-1.12.2-58.el7.x86_64
 sssd-ipa-1.12.2-58.el7.x86_64
 sssd-1.12.2-58.el7.x86_64
 sssd-tools-1.12.2-58.el7.x86_64
 sssd-common-1.12.2-58.el7.x86_64
 sssd-ad-1.12.2-58.el7.x86_64
 sssd-krb5-1.12.2-58.el7.x86_64
 sssd-ldap-1.12.2-58.el7.x86_64
 sssd-client-1.12.2-58.el7.x86_64
 sssd-common-pac-1.12.2-58.el7.x86_64
 sssd-proxy-1.12.2-58.el7.x86_64
 
 
 
 On 3/19/15, 11:23 AM, Jakub Hrozek jhro...@redhat.com wrote:
 
 On Thu, Mar 19, 2015 at 11:05:45AM -0400, Gould, Joshua wrote:
  I¹m seeing ssh logins for AD users take MUCH longer when using SID
 mapping
  vs. POSIX attributes. Both myself and our AD admin would prefer to use
 SID
  mapping. It appears tied to the group lookup at login. There seem to be
  many posts about it, but I haven¹t found anything to help much. sssd
 pegs
  the CPU for the 15 or so seconds the login takes.
 
 You haven't said what OS or release are you running, but for 7.0 I have
 test packages with a proposed enhancement Sumit wrote:
 
 https://urldefense.proofpoint.com/v2/url?u=https-3A__jhrozek.fedorapeople.
 org_sssd-2Dtest-2Dbuilds_sssd-2D7.0-2Dlogin-2Dspeedup_d=AwIFAwc=k9MF1d71
 ITtkuJx-PdWme51dKbmfPEvxwt8SFEkBfs4r=C8H0y1Bn8C6Mf5i9qrqkUDy3xSk8zPbIs_Sv
 JwojC24m=YA1l-b8irE5VE9qVc1q4PY8RVJA2iLwWLK_U7aXS1gss=bYcFLFGsd6BT_1ozcn
 1r1WaYFWJ4_5xT5ddR7d45Z08e=
 
 Please include the versions of the problematic packages in the future
 requests for troubleshooting.
 
 -- 
 Manage your subscription for the Freeipa-users mailing list:
 https://urldefense.proofpoint.com/v2/url?u=https-3A__www.redhat.com_mailma
 n_listinfo_freeipa-2Dusersd=AwIFAwc=k9MF1d71ITtkuJx-PdWme51dKbmfPEvxwt8S
 FEkBfs4r=C8H0y1Bn8C6Mf5i9qrqkUDy3xSk8zPbIs_SvJwojC24m=YA1l-b8irE5VE9qVc1
 q4PY8RVJA2iLwWLK_U7aXS1gss=uJUobRCfTZ-jS6M4XSLW8ScMXv_1sIQ-OSoy54M7b2ke=
  
 Go to 
 https://urldefense.proofpoint.com/v2/url?u=http-3A__freeipa.orgd=AwIFAwc
 =k9MF1d71ITtkuJx-PdWme51dKbmfPEvxwt8SFEkBfs4r=C8H0y1Bn8C6Mf5i9qrqkUDy3xSk
 8zPbIs_SvJwojC24m=YA1l-b8irE5VE9qVc1q4PY8RVJA2iLwWLK_U7aXS1gss=F_LQz74bb
 hG6_BKutjgbdRMTvIBRYggIgNj1QZoEznwe=  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] Really slow logins with AD SID Mapping vs. POSIX

On Thu, Mar 19, 2015 at 11:05:45AM -0400, Gould, Joshua wrote:
 I¹m seeing ssh logins for AD users take MUCH longer when using SID mapping
 vs. POSIX attributes. Both myself and our AD admin would prefer to use SID
 mapping. It appears tied to the group lookup at login. There seem to be
 many posts about it, but I haven¹t found anything to help much. sssd pegs
 the CPU for the 15 or so seconds the login takes.

You haven't said what OS or release are you running, but for 7.0 I have
test packages with a proposed enhancement Sumit wrote:
https://jhrozek.fedorapeople.org/sssd-test-builds/sssd-7.0-login-speedup/

Please include the versions of the problematic packages in the future
requests for troubleshooting.

-- 
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] 'Preauthentication failed' with SSSD in ipa_server_mode

2015-03-19 Thread Bobby Prins

Hi there,

I'm currently trying to use the 'AD Trust for Legacy Clients' freeIPA setup 
(described here: 
http://www.freeipa.org/images/0/0d/FreeIPA33-legacy-clients.pdf) to be able to 
autenticate AIX 7.1 clients against an AD domain using LDAP. After the trust 
was created all seems to work well on the freeIPA server. I can also do a 
lookup of AD users and groups on an AIX test server.

But as soon as I want to log in on the AIX system I get an SSSD error on the 
freeIPA server in krb5_child.log (debug_level = 10):
(Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
[sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590260: AS key obtained 
for encrypted timestamp: aes256-cts/2F5D
(Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
[sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590326: Encrypted 
timestamp (for 1426778442.525165): plain 
301AA011180F32303135303331393135323034325AA105020308036D, encrypted 
9B3299264F09E50D63D84B385A09A4C64D44116A02B58FFF12830B39F88722CD9B792F5ABA0653578DE9138B91D29C17C197453D8B8A5E7A
(Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
[sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590349: Preauth module 
encrypted_timestamp (2) (flags=1) returned: 0/Success
(Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
[sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590360: Produced preauth 
for next request: 2
(Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
[sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590384: Sending request 
(238 bytes) to EXAMPLE.CORP
(Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
[sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.591325: Resolving 
hostname dct020.example.corp.
(Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
[sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.591889: Sending initial 
UDP request to dgram 192.168.143.1:88
(Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
[sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636127: Received answer 
from dgram 192.168.143.1:88
(Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
[sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636626: Response was not 
from master KDC
(Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
[sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636667: Received error 
from KDC: -1765328360/Preauthentication failed
(Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
[sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636698: Preauth tryagain 
input types: 16, 14, 19, 2
(Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
[sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636728: Retrying AS 
request with master KDC
(Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
[sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636741: Getting initial 
credentials for bpr...@example.corp
(Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 
[sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636787: Sending request 
(160 bytes) to EXAMPLE.CORP (master)
(Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 [get_and_save_tgt] 
(0x0020): 979: [-1765328360][Preauthentication failed]
(Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 [map_krb5_error] 
(0x0020): 1040: [-1765328360][Preauthentication failed]
(Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 [k5c_send_data] 
(0x0200): Received error code 1432158214

If I do the same with 'KRB5_TRACE=/dev/stderr kinit bpr...@example.corp':
[12299] 1426773524.361785: AS key obtained for encrypted timestamp: 
aes256-cts/B997
[12299] 1426773524.361850: Encrypted timestamp (for 1426773524.277583): plain 
301AA011180F32303135303331393133353834345AA1050203043C4F, encrypted 
ED9CF995617740C4B14DB9CC84187E3505B664FE5C0AD16D19477E912F5400FB2C4665A090E3A37CD749535B3C80595809E14D15CB3527C0
[12299] 1426773524.361876: Preauth module encrypted_timestamp (2) (flags=1) 
returned: 0/Success
[12299] 1426773524.361880: Produced preauth for next request: 2
[12299] 1426773524.361901: Sending request (238 bytes) to EXAMPLE.CORP
[12299] 1426773524.363002: Resolving hostname dct020.EXAMPLE.corp.
[12299] 1426773524.363841: Sending initial UDP request to dgram 192.168.141.1:88
[12299] 1426773524.368089: Received answer from dgram 192.168.141.1:88
[12299] 1426773524.368482: Response was not from master KDC
[12299] 1426773524.368500: Received error from KDC: -1765328332/Response too 
big for UDP, retry with TCP
[12299] 1426773524.368506: Request or response is too big for UDP; retrying 
with TCP
[12299] 1426773524.368511: Sending request (238 bytes) to EXAMPLE.CORP (tcp 
only)
[12299] 1426773524.368953: Resolving hostname dct030.EXAMPLE.corp.
[12299] 1426773524.370056: Initiating TCP connection to stream 192.168.143.5:88
[12299] 1426773524.375140: Sending TCP request to stream 192.168.143.5:88
[12299] 1426773524.383801: Received answer from stream 192.168.143.5:88
[12299] 1426773524.384237: Response was not from master KDC

Re: [Freeipa-users] Really slow logins with AD SID Mapping vs. POSIX

2015-03-19 Thread Gould, Joshua

You are correct. 7.1.



Sent with Good (www.good.com)


-Original Message-
From: Jakub Hrozek [jhro...@redhat.commailto:jhro...@redhat.com]
Sent: Thursday, March 19, 2015 11:37 AM Eastern Standard Time
To: Gould, Joshua
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Really slow logins with AD SID Mapping vs. POSIX


On Thu, Mar 19, 2015 at 11:31:16AM -0400, Gould, Joshua wrote:
 RHEL 7.0 fully up to date.

Are you sure? Looks like 7.1 to me based on the NVRs.


 sssd-krb5-common-1.12.2-58.el7.x86_64
 sssd-ipa-1.12.2-58.el7.x86_64
 sssd-1.12.2-58.el7.x86_64
 sssd-tools-1.12.2-58.el7.x86_64
 sssd-common-1.12.2-58.el7.x86_64
 sssd-ad-1.12.2-58.el7.x86_64
 sssd-krb5-1.12.2-58.el7.x86_64
 sssd-ldap-1.12.2-58.el7.x86_64
 sssd-client-1.12.2-58.el7.x86_64
 sssd-common-pac-1.12.2-58.el7.x86_64
 sssd-proxy-1.12.2-58.el7.x86_64



 On 3/19/15, 11:23 AM, Jakub Hrozek jhro...@redhat.com wrote:

 On Thu, Mar 19, 2015 at 11:05:45AM -0400, Gould, Joshua wrote:
  I¹m seeing ssh logins for AD users take MUCH longer when using SID
 mapping
  vs. POSIX attributes. Both myself and our AD admin would prefer to use
 SID
  mapping. It appears tied to the group lookup at login. There seem to be
  many posts about it, but I haven¹t found anything to help much. sssd
 pegs
  the CPU for the 15 or so seconds the login takes.
 
 You haven't said what OS or release are you running, but for 7.0 I have
 test packages with a proposed enhancement Sumit wrote:
 
 https://urldefense.proofpoint.com/v2/url?u=https-3A__jhrozek.fedorapeople.
 org_sssd-2Dtest-2Dbuilds_sssd-2D7.0-2Dlogin-2Dspeedup_d=AwIFAwc=k9MF1d71
 ITtkuJx-PdWme51dKbmfPEvxwt8SFEkBfs4r=C8H0y1Bn8C6Mf5i9qrqkUDy3xSk8zPbIs_Sv
 JwojC24m=YA1l-b8irE5VE9qVc1q4PY8RVJA2iLwWLK_U7aXS1gss=bYcFLFGsd6BT_1ozcn
 1r1WaYFWJ4_5xT5ddR7d45Z08e=
 
 Please include the versions of the problematic packages in the future
 requests for troubleshooting.
 
 --
 Manage your subscription for the Freeipa-users mailing list:
 https://urldefense.proofpoint.com/v2/url?u=https-3A__www.redhat.com_mailma
 n_listinfo_freeipa-2Dusersd=AwIFAwc=k9MF1d71ITtkuJx-PdWme51dKbmfPEvxwt8S
 FEkBfs4r=C8H0y1Bn8C6Mf5i9qrqkUDy3xSk8zPbIs_SvJwojC24m=YA1l-b8irE5VE9qVc1
 q4PY8RVJA2iLwWLK_U7aXS1gss=uJUobRCfTZ-jS6M4XSLW8ScMXv_1sIQ-OSoy54M7b2ke=
 
 Go to
 https://urldefense.proofpoint.com/v2/url?u=http-3A__freeipa.orgd=AwIFAwc
 =k9MF1d71ITtkuJx-PdWme51dKbmfPEvxwt8SFEkBfs4r=C8H0y1Bn8C6Mf5i9qrqkUDy3xSk
 8zPbIs_SvJwojC24m=YA1l-b8irE5VE9qVc1q4PY8RVJA2iLwWLK_U7aXS1gss=F_LQz74bb
 hG6_BKutjgbdRMTvIBRYggIgNj1QZoEznwe=  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] SSSD in redundant configuration

On Thu, Mar 19, 2015 at 03:51:48PM +0100, Andrew Holway wrote:
 I am having problems with sudo and using _srv_ in the sssd config.
 
 This works:
 
 # For the SUDO integration
 
 sudo_provider = ldap
 
 ldap_uri = ldap://test-freeipa-1.cloud.domain.de
 
 ldap_sudo_search_base = ou=sudoers,dc=cloud,dc=native-instruments,dc=de
 
 ldap_sasl_mech = GSSAPI
 
 ldap_sasl_authid = host/test-freeipa-client-3.cloud.domain.de
 
 ldap_sasl_realm = CLOUD.DOMAIN.DE
 
 krb5_server = test-freeipa-2.cloud.domain.de
 
 
 This does not work:
 
 # For the SUDO integration
 
 sudo_provider = ldap
 
 ldap_uri = _srv_
 
 ldap_sudo_search_base = ou=sudoers,dc=cloud,dc=domain,dc=de
 
 ldap_sasl_mech = GSSAPI
 
 ldap_sasl_authid = host/test-freeipa-client-3.cloud.domain.de
 
 ldap_sasl_realm = CLOUD.DOMAIN.DE
 
 krb5_server = _srv_

What is the client version?

-- 
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] SSSD in redundant configuration

Hi Jakub,

Name: ipa-client
Arch: x86_64
Version : 3.3.3
Release : 28.0.1.el7.centos.3

On 19 March 2015 at 17:33, Jakub Hrozek jhro...@redhat.com wrote:

 On Thu, Mar 19, 2015 at 03:51:48PM +0100, Andrew Holway wrote:
  I am having problems with sudo and using _srv_ in the sssd config.
 
  This works:
 
  # For the SUDO integration
 
  sudo_provider = ldap
 
  ldap_uri = ldap://test-freeipa-1.cloud.domain.de
 
  ldap_sudo_search_base = ou=sudoers,dc=cloud,dc=native-instruments,dc=de
 
  ldap_sasl_mech = GSSAPI
 
  ldap_sasl_authid = host/test-freeipa-client-3.cloud.domain.de
 
  ldap_sasl_realm = CLOUD.DOMAIN.DE
 
  krb5_server = test-freeipa-2.cloud.domain.de
 
 
  This does not work:
 
  # For the SUDO integration
 
  sudo_provider = ldap
 
  ldap_uri = _srv_
 
  ldap_sudo_search_base = ou=sudoers,dc=cloud,dc=domain,dc=de
 
  ldap_sasl_mech = GSSAPI
 
  ldap_sasl_authid = host/test-freeipa-client-3.cloud.domain.de
 
  ldap_sasl_realm = CLOUD.DOMAIN.DE
 
  krb5_server = _srv_

 What is the client version?

-- 
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] SSSD in redundant configuration