[Freeipa-users] Problem with replica

2015-09-24 Thread Nicola Canepa 
Hello, I'm trying to setup a partial replica of the LDAP tree stored in 
389-ds by FreeIPA 4.1 (under CentOS 7), so that legacy systems have a 
local copy of the data needed to authenticate.
Those systems have already OpenLDAP installed, so I 'm trying to enable 
syncrepl from DS to OL.
I followed this ticket: https://fedorahosted.org/freeipa/ticket/3967 and 
I enabled the 2 plugins as indicated.
When the slave starts and tries to sync, the ns-slapd process on FreeIPA 
server dies, with this in syslog:
kernel: ns-slapd[4801]: segfault at 0 ip 7f0f041f2db6 sp 
7f0ecc7f0f38 error 4 in libc-2.17.so[7f0f0416e000+1b6000]

immediately (same second) followed by:
named[1974]: LDAP error: Can't contact LDAP server: ldap_sync_poll() 
failed

named[1974]: ldap_syncrepl will reconnect in 60 seconds
systemd: dirsrv@XXX.service: main process exited, code=killed, 
status=11/SEGV


There is nothing in access or error log (found in 
/var/log/dirsrv/INSTANCE) at that second (last log is 30 seconds before 
the problem).


Even if replica doesn't work, I think it shoundn't kill the daemon.


The ldif used on the slave:

dn: olcDatabase={1}bdb,cn=config
changetype: modify
replace:olcSyncrepl
olcSyncrepl: rid=0001
  provider=ldap://AAA.TLD
  type=refreshOnly
  interval=00:1:00:00
  retry="5 5 300 +"
  searchbase="YYY"
  attrs="*,+"
  bindmethod=simple
  binddn="uid=XXX,cn=users,cn=accounts,dc=YYY"
  credentials=ZZZ



Nicola

--

Nicola Canepa
Tel: +39-0522-399-3474
canep...@mmfg.it
---
Il contenuto della presente comunicazione è riservato e destinato 
esclusivamente ai destinatari indicati. Nel caso in cui sia ricevuto da persona 
diversa dal destinatario sono proibite la diffusione, la distribuzione e la 
copia. Nel caso riceveste la presente per errore, Vi preghiamo di informarci e 
di distruggerlo e/o cancellarlo dal Vostro computer, senza utilizzare i dati 
contenuti. La presente comunicazione (comprensiva dei documenti allegati) non 
avrà valore di proposta contrattuale e/o accettazione di proposte provenienti 
dal destinatario, nè rinuncia o riconoscimento di diritti, debiti e/o crediti, 
nè sarà impegnativa, qualora non sia sottoscritto successivo accordo da chi può 
validamente obbligarci. Non deriverà alcuna responsabilità precontrattuale a 
ns. carico, se la presente non sia seguita da contratto sottoscritto dalle 
parti.

The content of the above communication is strictly confidential and reserved 
solely for the referred addressees. In the event of receipt by persons 
different from the addressee, copying, alteration and distribution are 
forbidden. If received by mistake we ask you to inform us and to destroy and/or 
delete from your computer without using the data herein contained. The present 
message (eventual annexes inclusive) shall not be considered a contractual 
proposal and/or acceptance of offer from the addressee, nor waiver recognizance 
of rights, debts  and/or credits, nor shall it be binding when not executed as 
a subsequent agreement by persons who could lawfully represent us. No 
pre-contractual liability shall apply to us when the present communication is 
not followed by any binding agreement between the parties.

--
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] How to turn off RC4 in 389ds???

2015-09-24 Thread Martin Kosek 
Hello Michael,

It is possible that this problem comes from obsolete package in the
mkosek/freeipa COPR repo, which was fixed in Fedora/RHEL, but not there.

Can you please try to update the 389-ds-base from

https://copr.fedoraproject.org/coprs/mkosek/freeipa/

? I rebuilt the latest F21 389-ds-base to the repo, there were some related 
fixes.

Thanks,
Martin

On 09/23/2015 05:50 PM, Michael Lasevich wrote:
> No difference. It is as if this setting is being overwritten somewhere deep
> in 389ds, because the "error" log correctly reflects the changes, but the
> actual process does not. (and yes, I verified that the process actually
> shuts down and start up again when I restart it)
> 
> ldapsearch -x -D "cn=directory manager" -W -b "cn=encryption,cn=config"
> # encryption, config
> dn: cn=encryption,cn=config
> objectClass: top
> objectClass: nsEncryptionConfig
> cn: encryption
> nsSSLSessionTimeout: 0
> nsSSLClientAuth: allowed
> sslVersionMin: TLS1.0
> nsSSL3Ciphers: +all
> allowWeakCipher: off
> nsSSL3: off
> nsSSL2: off
> ... (skipping nssslenabledciphers's) ...
> nsTLS1: on
> sslVersionMax: TLS1.2
> 
> SLAPD error log got longer:
> 
> SSL Initialization - Configured SSL version range: min: TLS1.0, max: TLS1.2
> [23/Sep/2015:09:37:28 -0600] - SSL alert: Configured NSS Ciphers
> [23/Sep/2015:09:37:28 -0600] - SSL alert:
> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: enabled
> [23/Sep/2015:09:37:28 -0600] - SSL alert:
> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384: enabled
> [23/Sep/2015:09:37:28 -0600] - SSL alert:
> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: enabled
> [23/Sep/2015:09:37:28 -0600] - SSL alert:
> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384: enabled
> [23/Sep/2015:09:37:28 -0600] - SSL alert:
> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384: enabled
> [23/Sep/2015:09:37:28 -0600] - SSL alert:
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384: enabled
> [23/Sep/2015:09:37:28 -0600] - SSL alert:
> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: enabled
> [23/Sep/2015:09:37:28 -0600] - SSL alert:
> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: enabled
> [23/Sep/2015:09:37:28 -0600] - SSL alert:
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled
> [23/Sep/2015:09:37:28 -0600] - SSL alert:
> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256: enabled
> [23/Sep/2015:09:37:28 -0600] - SSL alert:
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256: enabled
> [23/Sep/2015:09:37:28 -0600] - SSL alert:
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled
> [23/Sep/2015:09:37:28 -0600] - SSL alert:
> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: enabled
> [23/Sep/2015:09:37:28 -0600] - SSL alert:
> TLS_DHE_DSS_WITH_AES_128_GCM_SHA256: enabled
> [23/Sep/2015:09:37:28 -0600] - SSL alert:
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled
> [23/Sep/2015:09:37:28 -0600] - SSL alert:
> TLS_DHE_DSS_WITH_AES_128_CBC_SHA: enabled
> [23/Sep/2015:09:37:28 -0600] - SSL alert:
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA256: enabled
> [23/Sep/2015:09:37:29 -0600] - SSL alert:
> TLS_DHE_DSS_WITH_AES_128_CBC_SHA256: enabled
> [23/Sep/2015:09:37:29 -0600] - SSL alert:
> TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled
> [23/Sep/2015:09:37:29 -0600] - SSL alert:
> TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA: enabled
> [23/Sep/2015:09:37:29 -0600] - SSL alert:
> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384: enabled
> [23/Sep/2015:09:37:29 -0600] - SSL alert:
> TLS_DHE_DSS_WITH_AES_256_GCM_SHA384: enabled
> [23/Sep/2015:09:37:29 -0600] - SSL alert:
> TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled
> [23/Sep/2015:09:37:29 -0600] - SSL alert:
> TLS_DHE_DSS_WITH_AES_256_CBC_SHA: enabled
> [23/Sep/2015:09:37:29 -0600] - SSL alert:
> TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: enabled
> [23/Sep/2015:09:37:29 -0600] - SSL alert:
> TLS_DHE_DSS_WITH_AES_256_CBC_SHA256: enabled
> [23/Sep/2015:09:37:29 -0600] - SSL alert:
> TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled
> [23/Sep/2015:09:37:29 -0600] - SSL alert:
> TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA: enabled
> [23/Sep/2015:09:37:29 -0600] - SSL alert:
> TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA: enabled
> [23/Sep/2015:09:37:29 -0600] - SSL alert:
> TLS_ECDH_RSA_WITH_AES_128_CBC_SHA: enabled
> [23/Sep/2015:09:37:29 -0600] - SSL alert:
> TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA: enabled
> [23/Sep/2015:09:37:29 -0600] - SSL alert:
> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA: enabled
> [23/Sep/2015:09:37:29 -0600] - SSL alert:
> TLS_RSA_WITH_AES_256_GCM_SHA384: enabled
> [23/Sep/2015:09:37:29 -0600] - SSL alert:
> TLS_RSA_WITH_AES_128_GCM_SHA256: enabled
> [23/Sep/2015:09:37:29 -0600] - SSL alert:
> TLS_RSA_WITH_AES_128_CBC_SHA: enabled
> [23/Sep/2015:09:37:29 -0600] - SSL alert:
> TLS_RSA_WITH_AES_128_CBC_SHA256: enabled
> [23/Sep/2015:09:37:29 -0600] - SSL alert:
> TLS_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled
> [23/Sep/2015:09:37:29 -0600] - SSL alert:
> TLS_RSA_WITH_AES_256_CBC_SHA: enabled
> [23/Sep/2015:09:37:29 -0600] - SSL alert:
> TLS_RSA_WITH_AES_256_CBC_SHA256: enabled
> [23/Sep/2015:09:37:29 -0600] - SSL alert:
> TLS_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled
> [23/Sep/2015:09:37:29 -0600] - SSL alert:

Re: [Freeipa-users] SSSD client (amazon linux) + IPA server (Redhat)

2015-09-24 Thread Pawel Fiuto 
Unfortunately sudo package included in amzn linux does not work with sudo rules 
provided via SSS however it is in the feature requests list.
To workaround this you can replace it with the CentOS one: 
http://mirror.centos.org/centos/6.7/os/x86_64/Packages/sudo-1.8.6p3-19.el6.x86_64.rpm



From: freeipa-users-boun...@redhat.com  on 
behalf of Alexander Bokovoy 
Sent: 21 September 2015 20:40
To: Gustavo Mateus
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] SSSD client (amazon linux) + IPA server (Redhat)

On Mon, 21 Sep 2015, Gustavo Mateus wrote:
>Hi Alexander,
>
>Thank you very much for your help.
>Would it be possible for you to point me in the right direction on how to
>integrate this with sudo rules?
Please don't send emails personally unless asked to do that.

Your problem can be tracked with public mailing list.

>my sssd.conf looks like this:
>
>[sssd]
>services = nss, pam, ssh, sudo
>config_file_version = 2
>domains = default
>re_expression = (?P.+)
>
>[domain/default]
>cache_credentials = True
>id_provider = ldap
>auth_provider = ldap
>ldap_uri = ldap://ipaserver.my.domain.com
>ldap_search_base = cn=accounts,dc=my,dc=domain,dc=com
>ldap_tls_cacert = /etc/openldap/cacerts/ipa.crt
>ldap_user_ssh_public_key = ipaSshPubKey
>sudo_provider = ldap
>ldap_sudo_search_base = ou=sudoers,dc=my,dc=domain,dc=com
>ldap_sudo_full_refresh_interval=86400
>ldap_sudo_smart_refresh_interval=3600
>debug_level=8
>
>[ssh]
>
>[sudo]
>debug_level=8
>
>
>and nsswitch.conf has this:
>
>sudoers:files sss
>
>
>
>My goal is to have freeipa as a replacement for the current openldap and
>hope that amazon linux supports it fully in the future. While they don't
>support it, I want to use as much as I can of centralized management that
>freeipa+sssd provides.
SSSD has own plugin for sudo integration that makes possible to cache
sudo rules via SSSD itself as opposed to use of sudo's LDAP plugin which
tries to talk to LDAP server directly.

You need to understand what features are provided by Amazon Linux's sudo
package. It may well be missing support for sudo plugins. I don't have
access to Amazon Linux source code, thus I cannot check whether their
sudo package supports external plugins.

So even if your sssd version includes sudo plugin, it may probably be
simply unused by your sssd version. Again, I have no idea how Amazon's
Linux AMI is built, thus it may miss this capability.

At this point I'd suggest you to investigate yourself and contact Amazon
support for finding out exactly what is happening there.

--
/ Alexander Bokovoy

--
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] Problem with replica

2015-09-24 Thread Ludwig Krispenz 

Hi,

can you try to get a core dump:

http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#debug_crashes

and open a ticket for 389 DS: https://fedorahosted.org/389/newticket

Ludwig

On 09/24/2015 09:08 AM, Nicola Canepa wrote:
Hello, I'm trying to setup a partial replica of the LDAP tree stored 
in 389-ds by FreeIPA 4.1 (under CentOS 7), so that legacy systems have 
a local copy of the data needed to authenticate.
Those systems have already OpenLDAP installed, so I 'm trying to 
enable syncrepl from DS to OL.
I followed this ticket: https://fedorahosted.org/freeipa/ticket/3967 
and I enabled the 2 plugins as indicated.
When the slave starts and tries to sync, the ns-slapd process on 
FreeIPA server dies, with this in syslog:
kernel: ns-slapd[4801]: segfault at 0 ip 7f0f041f2db6 sp 
7f0ecc7f0f38 error 4 in libc-2.17.so[7f0f0416e000+1b6000]

immediately (same second) followed by:
named[1974]: LDAP error: Can't contact LDAP server: ldap_sync_poll() 
failed

named[1974]: ldap_syncrepl will reconnect in 60 seconds
systemd: dirsrv@XXX.service: main process exited, code=killed, 
status=11/SEGV


There is nothing in access or error log (found in 
/var/log/dirsrv/INSTANCE) at that second (last log is 30 seconds 
before the problem).


Even if replica doesn't work, I think it shoundn't kill the daemon.


The ldif used on the slave:

dn: olcDatabase={1}bdb,cn=config
changetype: modify
replace:olcSyncrepl
olcSyncrepl: rid=0001
  provider=ldap://AAA.TLD
  type=refreshOnly
  interval=00:1:00:00
  retry="5 5 300 +"
  searchbase="YYY"
  attrs="*,+"
  bindmethod=simple
  binddn="uid=XXX,cn=users,cn=accounts,dc=YYY"
  credentials=ZZZ



Nicola



--
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] V6 and v4

2015-09-24 Thread Martin Kosek 
On 09/23/2015 10:05 PM, Janelle wrote:
> On 9/13/15 11:46 PM, Alexander Bokovoy wrote:
>> On Sun, 13 Sep 2015, Janelle wrote:
>>> Hello,
>>>
>>> I read something recently that if ip v6 is disable on a server this
>>> hurts performance in some way? Is there more info on this or did I
>>> misread it?
>> Do not disable IPv6 stack on your machines. By disabling IPv6 you are
>> not doing good. On contrary, many contemporary software projects are
>> using IPv6-enabled network calls by default because both IPv6 and IPv4
>> share the same name space on the machine so you only need to listen on a
>> IPv6 port to accept both IPv4 and IPv6. This is a recommended approach
>> for networking applications' developers for years already.
>>
>> Note that this means only that support for IPv6 stack is enabled in the
>> kernel. You are not required to go with IPv6 networking addresses, this
>> is not really needed if you don't want to. But allowing applications to
>> be IPv6 aware is required.
>>
>> FreeIPA has several components which are programmed in such way that
>> they expect IPv6 stack to be enabled for reasons outlined above. If you
>> disable IPv6 stack, FreeIPA will partially malfunction and will not
>> really be in a supported state, especially when we are talking about
>> trusts to Active Directory (and, in future, IPA to IPA trust).
>>
> BTW - I did re-enable IPv6 and was able to "clean ruv" all the "dead" entries,
> which I had not been able to do before. Thank you for this.

Hello Janelle,

Thanks for confirmation! I added this knowledge to

http://www.freeipa.org/page/Troubleshooting#Obsolete_RUV_records

as it is definitely not an obvious fix to resolve the RUV issue.

Please feel very welcome to extend Troubleshooting guide if you have other
advise that could help others speed up their RUV investigation - you have
definitely a lot of experience with them.

Thanks!
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] When changing passwords gui displays Login screen is showing

2015-09-24 Thread Martin Kosek 
On 09/23/2015 05:27 PM, Andrew Holway wrote:
> Hi,
> 
> When a user changes their password the ipa gui briefly redirects to a login
> page. The user often has an impulse to click on the login button which, on
> occasion, can seem to cause a mess with the password change.
> 
> Anyone else aware of this behaviour?
> 
> ta
> 
> Andrew

Hi Andrew,

I can see it too - good catch. I would suggest filing a new ticket at

https://fedorahosted.org/freeipa/newticket

if you would like to propose this UX improvement.

-- 
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] rhel 6.7 upgrade - sssd/sudo

2015-09-24 Thread Pavel Reichl 

Hello Andy,

I understand that you run sssd-1.12.4-47.el6.x86_64 on ipa client, right?

What version of SSSD do you run on ipa 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] User, keytab, password and ldap

2015-09-24 Thread Martin Kosek 
On 09/23/2015 04:32 PM, bahan w wrote:
> Hello !
> 
> I'm using IPA 3.0.0 and I have a problem with one of the user I created.
> user3
> 
> I created this user with the command ipa user-add without specifying any
> password.
> Then I performed an ipa-getkeytab command with the -P option to have a
> keytab and a password.
> 
> When I check the ldap server with the following command, I cannot find any
> "userpassword" field for this user.
> ldapsearch -v -x -D 'cn=Directory Manager' -W -h  -p 
> 
> ###
> # user3, users, accounts, myrealm
> dn: uid=user3,cn=users,cn=accounts,dc=myrealm
> displayName: user3 user3
> cn: user3 user3
> 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/sh
> sn: user3
> gecos: user3 user3
> homeDirectory: /home/user3
> krbPwdPolicyReference: cn=pwp_users,cn=MYREALM,cn=kerberos,dc=myrealm
> krbPrincipalName: user3@MYREALM
> givenName: user3
> uid: user3
> initials: uu
> ipaUniqueID: 5dbc0e78-5884-11e5-a8a0-00505695d2c7
> uidNumber: 
> gidNumber: 
> memberOf: cn=defaultgroup,cn=groups,cn=accounts,dc=myrealm
> memberOf: cn=pwp_users,cn=groups,cn=accounts,dc=myrealm
> mepManagedEntry: cn=user3,cn=groups,cn=accounts,dc=myrealm
> krbLastPwdChange: 20150923134438Z
> krbPrincipalKey:: 
> krbExtraData:: AALGrAJWYV9hcHBfcmpkbUBCREZJTlQxAA==
> krbLastSuccessfulAuth: 20150923120752Z
> krbLastFailedAuth: 20150923132257Z
> krbLoginFailedCount: 1
> ###
> 
> Then, with an admin ticket, I performed an ipa passwd user3 and I set a one
> time password.
> Then I connected with user3 and he was able to change its one time password
> into something else.
> And when I retried the ldapsearch command, the field userpassword was there.
> But the keytab is not working anymore.
> 
> So here is my question :
> How can I generate a user with a keytab, a password and the userpassword
> field in the ldap ?

I do not think you can do that - by design. FreeIPA synchronizes Kerberos keys
and the user password. So if you change password, existing keytab is
invalidated. If you get a keytab, password is invalidated as random key is
generated.

> The ipa-getkeytab -P option allows me to have both keytab and the password,
> but as the field userpassword is missing in the ldap, some other tools
> using ldapbackend authentication does not work for this user.

I assume this is not expected to work this way, but please let me CC Simo here,
if there is a problem in processing the -P option.

-- 
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] Generic preauthentication failure while getting initial credentials using kinit -k -t

2015-09-24 Thread Brian J. Murrell 
On Thu, 2015-09-24 at 08:23 +0300, Alexander Bokovoy wrote:
> You need to explain what are you trying to achieve first.

Sure.  It is entirely likely that I am misunderstanding what I should
be doing.

A system service needs to be able to authenticate to the service
imap/linux.example.com as a given user, so clearly that system service
cannot kinit and provide a password as a user would normally (I guess
this is what GSS-Proxy is for, FWIW).

> The sequence above:
> 
>  - Sets a random Kerberos key for a principal named 
> aster...@example.com

OK.

>on IPA KDC and stores it to the local keytab file asterisk.keytab

Right.

>  - tries to use a key for 
> aster...@example.com to obtain ticket
> granting
>ticket as 
> imap/linux.example@exampe.com

So maybe this is where I am going wrong.

> Unless imap/linux.example@example.com
>  has exactly same Kerberos key
> as aster...@example.com, the above should
> fail and it does.

So I want to put the imap/linux.example.com kerberos key into the
 asterisk.keytab file such as:

ipa-getkeytab -s server.example.com -p imap/linux.example.com -k 
/tmp/asterisk-krb5.keytab -e aes256-cts

I probably need to brush up on my kerberos here but is that what a user
effectively does?  When I, as a user do a "kinit brian" and then do a
klist (after having used my imap client) and I see:

24/09/15 09:00:28  25/09/15 06:19:42  imap/linux.example@example.com

Does that mean that I actually have the Kerberos key for that imap/linu
x.example@example.com
in my key cache -- the exact same key that I am going to put into the
asterisk.keytab above?

Cheers,
b.


signature.asc
Description: This is a digitally signed message part
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] rhel 6.7 upgrade - sssd/sudo

2015-09-24 Thread Pavel Reichl 

On 09/24/2015 02:50 PM, Andy Thompson wrote:

-Original Message-
From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
boun...@redhat.com] On Behalf Of Pavel Reichl
Sent: Thursday, September 24, 2015 5:18 AM
To: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] rhel 6.7 upgrade - sssd/sudo

Hello Andy,

I understand that you run sssd-1.12.4-47.el6.x86_64 on ipa client, right?

What version of SSSD do you run on ipa server?



The servers are running

sssd-1.12.2-58.el7_1.14.x86_64

-andy


Thanks, I prepared a scratch build containing patches for 
https://fedorahosted.org/sssd/ticket/2633 that could be fix your problems. 
Please consider installing the build on you ipa server but please avoid using 
it in production environment. Thanks!

https://copr.fedoraproject.org/coprs/preichl/fix_ext_grp/

--
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] V6 and v4

2015-09-24 Thread Alexander Bokovoy 

On Thu, 24 Sep 2015, Janelle wrote:

On 9/24/15 12:57 AM, Martin Kosek wrote:

On 09/23/2015 10:05 PM, Janelle wrote:

On 9/13/15 11:46 PM, Alexander Bokovoy wrote:

On Sun, 13 Sep 2015, Janelle wrote:

Hello,

I read something recently that if ip v6 is disable on a server this
hurts performance in some way? Is there more info on this or did I
misread it?

Do not disable IPv6 stack on your machines. By disabling IPv6 you are
not doing good. On contrary, many contemporary software projects are
using IPv6-enabled network calls by default because both IPv6 and IPv4
share the same name space on the machine so you only need to listen on a
IPv6 port to accept both IPv4 and IPv6. This is a recommended approach
for networking applications' developers for years already.

Note that this means only that support for IPv6 stack is enabled in the
kernel. You are not required to go with IPv6 networking addresses, this
is not really needed if you don't want to. But allowing applications to
be IPv6 aware is required.

FreeIPA has several components which are programmed in such way that
they expect IPv6 stack to be enabled for reasons outlined above. If you
disable IPv6 stack, FreeIPA will partially malfunction and will not
really be in a supported state, especially when we are talking about
trusts to Active Directory (and, in future, IPA to IPA trust).


BTW - I did re-enable IPv6 and was able to "clean ruv" all the "dead" entries,
which I had not been able to do before. Thank you for this.

Hello Janelle,

Thanks for confirmation! I added this knowledge to

http://www.freeipa.org/page/Troubleshooting#Obsolete_RUV_records

as it is definitely not an obvious fix to resolve the RUV issue.

Please feel very welcome to extend Troubleshooting guide if you have other
advise that could help others speed up their RUV investigation - you have
definitely a lot of experience with them.

Thanks!
Martin
Final - Final  confirmation now. I now deleted a replica and re-added. 
No "ghost" entries at all. Everything is perfect. Yeah, this was crazy 
that it was the fix on all the problems I had for a few months. It 
definitely was not an obvious one.  I had wondered if it was DNS at 
one point, but every server/master has a /etc/hosts file with all 
hostnames and IPs (I never trust DNS).


Thank you for sticking with all my issues and helping with this. This 
one was a huge help.  At one point I had 9 of these ghost RUVs that 
would not go away. Even if I deleted them off a server, they would 
magically re-appear. It was so frustrating.  Having a clean 
environment is a wonderful thing. I love IPA!!


I will check the DOCs and if there is anything I can add I will.

It looks like 389-ds internally uses IPv6 stack functions as that allows
to support both IPv4 and IPv6 addresses. This means that 389-ds always
listens on tcp6 (netstat -nltp will show that) and if IPv6 stack is
disabled in the kernel, it could cause some issues as not all
functionality would be available to the user space. Again, you don't
need to have IPv6 network addresses, just IPv6 namespace enabled in the
kernel.
--
/ Alexander Bokovoy

--
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] rhel 6.7 upgrade - sssd/sudo

2015-09-24 Thread Andy Thompson 
> -Original Message-
> From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
> boun...@redhat.com] On Behalf Of Pavel Reichl
> Sent: Thursday, September 24, 2015 5:18 AM
> To: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] rhel 6.7 upgrade - sssd/sudo
> 
> Hello Andy,
> 
> I understand that you run sssd-1.12.4-47.el6.x86_64 on ipa client, right?
> 
> What version of SSSD do you run on ipa server?
> 

The servers are running

sssd-1.12.2-58.el7_1.14.x86_64

-andy

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

2015-09-24 Thread Alexander Bokovoy 

On Thu, 24 Sep 2015, Andy Thompson wrote:

-Original Message-
From: Alexander Bokovoy [mailto:aboko...@redhat.com]
Sent: Thursday, September 24, 2015 1:17 AM
To: Andy Thompson 
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] IPA server failover

On Wed, 23 Sep 2015, Andy Thompson wrote:
>I've got all of my environments setup with two IPA servers.  I'm
>fighting intermittent problems with krb5kdc crashing on them in all of
>my environments and I've opened a ticket with Redhat on that.  What I
>can't figure out though is why the clients will not fail over to the
>second functioning server in the domain
>
>My sssd.conf files are all pretty generic from the install with minimal
>modification to add a couple settings.
>
>[domain/mhbe.lin]
>
>cache_credentials = True
>krb5_store_password_if_offline = True
>ipa_domain = mhbe.lin
>id_provider = ipa
>auth_provider = ipa
>access_provider = ipa
>ipa_hostname = mdhixproddb01.mhbe.lin
>chpass_provider = ipa
>ipa_server = _srv_, mdhixprodipa01.mhbe.lin ldap_tls_cacert =
>/etc/ipa/ca.crt [sssd] default_domain_suffix = mhbe.local services =
>nss, sudo, pam, ssh config_file_version = 2
>
>domains = mhbe.lin
>[nss]
>default_shell = /bin/bash
>homedir_substring = /home
>debug_level = 7
>[pam]
>
>[sudo]
>
>[autofs]
>
>[ssh]
>
>[pac]
>
>[ifp]
>
>I thought the _srv_  would force it to use dns and both servers are
>round robined when digging the _kerberos records from DNS.  So I don't
>understand why it's not working
ipa_server is for SSSD tasks using LDAP server. Kerberos libraries are using
/etc/krb5.conf for hints where to find KDCs.

A combination of 'dns_lookup_kdc = true' in [libdefaults] and missing 'kdc = '
for specific realm would cause Kerberos clients to do DNS discovery using
SRV records.



Here are the contents of my krb conf with everything set to lookup and it 
doesn't appear to be working.

includedir /var/lib/sss/pubconf/krb5.include.d/

[libdefaults]
 default_realm = MHBE.LIN
 dns_lookup_realm = true
 dns_lookup_kdc = true
 rdns = false
 ticket_lifetime = 24h
 forwardable = yes
 udp_preference_limit = 0


[realms]
 MHBE.LIN = {
   pkinit_anchors = FILE:/etc/ipa/ca.crt

 }


[domain_realm]
 .mhbe.lin = MHBE.LIN
 mhbe.lin = MHBE.LIN

I bet you have SSSD supplying you KDC info in
/var/lib/sss/pubconf/kdcinfo.MHBE.LIN via
/usr/lib64/krb5/plugins/libkrb5/sssd_krb5_locator_plugin.so

You can add 'krb5_use_kdcinfo = false' to sssd.conf (domain section),
see details in sssd-krb5(5).
--
/ Alexander Bokovoy

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

2015-09-24 Thread Petr Spacek 
On 24.9.2015 15:29, Alexander Bokovoy wrote:
> On Thu, 24 Sep 2015, Andy Thompson wrote:
>>> -Original Message-
>>> From: Alexander Bokovoy [mailto:aboko...@redhat.com]
>>> Sent: Thursday, September 24, 2015 1:17 AM
>>> To: Andy Thompson 
>>> Cc: freeipa-users@redhat.com
>>> Subject: Re: [Freeipa-users] IPA server failover
>>>
>>> On Wed, 23 Sep 2015, Andy Thompson wrote:
>>> >I've got all of my environments setup with two IPA servers.  I'm
>>> >fighting intermittent problems with krb5kdc crashing on them in all of
>>> >my environments and I've opened a ticket with Redhat on that.  What I
>>> >can't figure out though is why the clients will not fail over to the
>>> >second functioning server in the domain
>>> >
>>> >My sssd.conf files are all pretty generic from the install with minimal
>>> >modification to add a couple settings.
>>> >
>>> >[domain/mhbe.lin]
>>> >
>>> >cache_credentials = True
>>> >krb5_store_password_if_offline = True
>>> >ipa_domain = mhbe.lin
>>> >id_provider = ipa
>>> >auth_provider = ipa
>>> >access_provider = ipa
>>> >ipa_hostname = mdhixproddb01.mhbe.lin
>>> >chpass_provider = ipa
>>> >ipa_server = _srv_, mdhixprodipa01.mhbe.lin ldap_tls_cacert =
>>> >/etc/ipa/ca.crt [sssd] default_domain_suffix = mhbe.local services =
>>> >nss, sudo, pam, ssh config_file_version = 2
>>> >
>>> >domains = mhbe.lin
>>> >[nss]
>>> >default_shell = /bin/bash
>>> >homedir_substring = /home
>>> >debug_level = 7
>>> >[pam]
>>> >
>>> >[sudo]
>>> >
>>> >[autofs]
>>> >
>>> >[ssh]
>>> >
>>> >[pac]
>>> >
>>> >[ifp]
>>> >
>>> >I thought the _srv_  would force it to use dns and both servers are
>>> >round robined when digging the _kerberos records from DNS.  So I don't
>>> >understand why it's not working
>>> ipa_server is for SSSD tasks using LDAP server. Kerberos libraries are using
>>> /etc/krb5.conf for hints where to find KDCs.
>>>
>>> A combination of 'dns_lookup_kdc = true' in [libdefaults] and missing 'kdc 
>>> = '
>>> for specific realm would cause Kerberos clients to do DNS discovery using
>>> SRV records.
>>>
>>
>> Here are the contents of my krb conf with everything set to lookup and it
>> doesn't appear to be working.
>>
>> includedir /var/lib/sss/pubconf/krb5.include.d/
>>
>> [libdefaults]
>>  default_realm = MHBE.LIN
>>  dns_lookup_realm = true
>>  dns_lookup_kdc = true
>>  rdns = false
>>  ticket_lifetime = 24h
>>  forwardable = yes
>>  udp_preference_limit = 0
>>
>>
>> [realms]
>>  MHBE.LIN = {
>>pkinit_anchors = FILE:/etc/ipa/ca.crt
>>
>>  }
>>
>>
>> [domain_realm]
>>  .mhbe.lin = MHBE.LIN
>>  mhbe.lin = MHBE.LIN
> I bet you have SSSD supplying you KDC info in
> /var/lib/sss/pubconf/kdcinfo.MHBE.LIN via
> /usr/lib64/krb5/plugins/libkrb5/sssd_krb5_locator_plugin.so
> 
> You can add 'krb5_use_kdcinfo = false' to sssd.conf (domain section),
> see details in sssd-krb5(5).

Also, I would recommend you to check SRV records in DNS:

$ dig _kerberos._udp.mhbe.lin SRV

It should list both servers (with non-zero priority).

-- 
Petr^2 Spacek

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

Re: [Freeipa-users] sssd public socket error

2015-09-24 Thread Andy Thompson 


> -Original Message-
> From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
> boun...@redhat.com] On Behalf Of Jakub Hrozek
> Sent: Wednesday, September 23, 2015 4:54 PM
> To: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] sssd public socket error
> 
> On Wed, Sep 23, 2015 at 06:03:45PM +, Andy Thompson wrote:
> > On one of my servers I'm getting
> >
> > Sep 23 13:35:07 mdhixuatisamw03 sshd[8136]: pam_unix(sshd:session):
> > session opened for user user by (uid=0) Sep 23 13:35:07 mdhixuatisamw03
> sshd[8164]: pam_sss(sshd:setcred): Request to sssd failed. Public socket has
> wrong ownership or permissions.
> >
> > Authentication still works but group name lookups fail on the server.
> >
> > Haven't been able to track down yet what config is different on this server
> and I can't find any information on this, anyone have any thoughts?
> 
> The code is:
> 860 statret = stat(SSS_PAM_SOCKET_NAME, _buf);
> 861 if (statret != 0) {
> 862 ret = PAM_SERVICE_ERR;
> 863 goto out;
> 864 }
> 865 if ( ! (stat_buf.st_uid == 0 &&
> 866 stat_buf.st_gid == 0 &&
> 867 S_ISSOCK(stat_buf.st_mode) &&
> 868 (stat_buf.st_mode & ~S_IFMT) == 0666 )) {
> 869 *errnop = ESSS_BAD_PUB_SOCKET;
> 870 ret = PAM_SERVICE_ERR;
> 871 goto out;
> 872 }
> 873
> 
> I would compare:
> ls -lR /var/lib/sss/pipes/
> 
> on a working or a non-working server. The public PAM socket
> (/var/lib/sss/pipes/pam) should be there and should have permission 0666.
> 
> Also check AVC denials.
> 

It was file perms on those files.  Thanks for the pointer.

-andy

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

2015-09-24 Thread Andy Thompson 
> -Original Message-
> From: Alexander Bokovoy [mailto:aboko...@redhat.com]
> Sent: Thursday, September 24, 2015 1:17 AM
> To: Andy Thompson 
> Cc: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] IPA server failover
> 
> On Wed, 23 Sep 2015, Andy Thompson wrote:
> >I've got all of my environments setup with two IPA servers.  I'm
> >fighting intermittent problems with krb5kdc crashing on them in all of
> >my environments and I've opened a ticket with Redhat on that.  What I
> >can't figure out though is why the clients will not fail over to the
> >second functioning server in the domain
> >
> >My sssd.conf files are all pretty generic from the install with minimal
> >modification to add a couple settings.
> >
> >[domain/mhbe.lin]
> >
> >cache_credentials = True
> >krb5_store_password_if_offline = True
> >ipa_domain = mhbe.lin
> >id_provider = ipa
> >auth_provider = ipa
> >access_provider = ipa
> >ipa_hostname = mdhixproddb01.mhbe.lin
> >chpass_provider = ipa
> >ipa_server = _srv_, mdhixprodipa01.mhbe.lin ldap_tls_cacert =
> >/etc/ipa/ca.crt [sssd] default_domain_suffix = mhbe.local services =
> >nss, sudo, pam, ssh config_file_version = 2
> >
> >domains = mhbe.lin
> >[nss]
> >default_shell = /bin/bash
> >homedir_substring = /home
> >debug_level = 7
> >[pam]
> >
> >[sudo]
> >
> >[autofs]
> >
> >[ssh]
> >
> >[pac]
> >
> >[ifp]
> >
> >I thought the _srv_  would force it to use dns and both servers are
> >round robined when digging the _kerberos records from DNS.  So I don't
> >understand why it's not working
> ipa_server is for SSSD tasks using LDAP server. Kerberos libraries are using
> /etc/krb5.conf for hints where to find KDCs.
> 
> A combination of 'dns_lookup_kdc = true' in [libdefaults] and missing 'kdc = '
> for specific realm would cause Kerberos clients to do DNS discovery using
> SRV records.
> 

Here are the contents of my krb conf with everything set to lookup and it 
doesn't appear to be working.

includedir /var/lib/sss/pubconf/krb5.include.d/

[libdefaults]
  default_realm = MHBE.LIN
  dns_lookup_realm = true
  dns_lookup_kdc = true
  rdns = false
  ticket_lifetime = 24h
  forwardable = yes
  udp_preference_limit = 0


[realms]
  MHBE.LIN = {
pkinit_anchors = FILE:/etc/ipa/ca.crt

  }


[domain_realm]
  .mhbe.lin = MHBE.LIN
  mhbe.lin = MHBE.LIN



> If multiple 'kdc = ...' values are specified in the realm definition, Kerberos
> clients will fall over to the next one in the list in case of a failure.
> 
> When ipa-client-install is run, we configure krb5.conf without explicit KDCs 
> if
> DNS discovery of Kerberos was successful which should take care of SRV
> record-based discovery of KDCs.
> --
> / Alexander Bokovoy

-- 
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] V6 and v4

2015-09-24 Thread Janelle 

On 9/24/15 12:57 AM, Martin Kosek wrote:

On 09/23/2015 10:05 PM, Janelle wrote:

On 9/13/15 11:46 PM, Alexander Bokovoy wrote:

On Sun, 13 Sep 2015, Janelle wrote:

Hello,

I read something recently that if ip v6 is disable on a server this
hurts performance in some way? Is there more info on this or did I
misread it?

Do not disable IPv6 stack on your machines. By disabling IPv6 you are
not doing good. On contrary, many contemporary software projects are
using IPv6-enabled network calls by default because both IPv6 and IPv4
share the same name space on the machine so you only need to listen on a
IPv6 port to accept both IPv4 and IPv6. This is a recommended approach
for networking applications' developers for years already.

Note that this means only that support for IPv6 stack is enabled in the
kernel. You are not required to go with IPv6 networking addresses, this
is not really needed if you don't want to. But allowing applications to
be IPv6 aware is required.

FreeIPA has several components which are programmed in such way that
they expect IPv6 stack to be enabled for reasons outlined above. If you
disable IPv6 stack, FreeIPA will partially malfunction and will not
really be in a supported state, especially when we are talking about
trusts to Active Directory (and, in future, IPA to IPA trust).


BTW - I did re-enable IPv6 and was able to "clean ruv" all the "dead" entries,
which I had not been able to do before. Thank you for this.

Hello Janelle,

Thanks for confirmation! I added this knowledge to

http://www.freeipa.org/page/Troubleshooting#Obsolete_RUV_records

as it is definitely not an obvious fix to resolve the RUV issue.

Please feel very welcome to extend Troubleshooting guide if you have other
advise that could help others speed up their RUV investigation - you have
definitely a lot of experience with them.

Thanks!
Martin
Final - Final  confirmation now. I now deleted a replica and re-added. 
No "ghost" entries at all. Everything is perfect. Yeah, this was crazy 
that it was the fix on all the problems I had for a few months. It 
definitely was not an obvious one.  I had wondered if it was DNS at one 
point, but every server/master has a /etc/hosts file with all hostnames 
and IPs (I never trust DNS).


Thank you for sticking with all my issues and helping with this. This 
one was a huge help.  At one point I had 9 of these ghost RUVs that 
would not go away. Even if I deleted them off a server, they would 
magically re-appear. It was so frustrating.  Having a clean environment 
is a wonderful thing. I love IPA!!


I will check the DOCs and if there is anything I can add I will.
~Janelle

--
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] rhel 6.7 upgrade - sssd/sudo

2015-09-24 Thread Andy Thompson 
Ok it will take me a while to get my test environment setup to match what I 
have in prod currently and I can do some testing at that point in time.

-andy


From: Pavel Reichl 
Sent: Thursday, September 24, 2015 9:43 AM
To: Andy Thompson; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] rhel 6.7 upgrade - sssd/sudo

On 09/24/2015 02:50 PM, Andy Thompson wrote:
>> -Original Message-
>> From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
>> boun...@redhat.com] On Behalf Of Pavel Reichl
>> Sent: Thursday, September 24, 2015 5:18 AM
>> To: freeipa-users@redhat.com
>> Subject: Re: [Freeipa-users] rhel 6.7 upgrade - sssd/sudo
>>
>> Hello Andy,
>>
>> I understand that you run sssd-1.12.4-47.el6.x86_64 on ipa client, right?
>>
>> What version of SSSD do you run on ipa server?
>>
>
> The servers are running
>
> sssd-1.12.2-58.el7_1.14.x86_64
>
> -andy
>
Thanks, I prepared a scratch build containing patches for 
https://fedorahosted.org/sssd/ticket/2633 that could be fix your problems. 
Please consider installing the build on you ipa server but please avoid using 
it in production environment. Thanks!

https://copr.fedoraproject.org/coprs/preichl/fix_ext_grp/

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

[Freeipa-users] sudo options/sss_cache

2015-09-24 Thread Christoph Kaminski 
Hi

I have 3 problems/questions with ipa and sudo...

1. How to make a GLOBAL sudo rule with all the options what I want to 
have? (e.g. !authenticate). I have tried to make a sudo rule for all users 
on all hosts whom all users but without command and it doesnt work... Do I 
need to set it for each rule separately?

2. How can I with sss_cache invalidate sudo rules? Do I need ever to kill 
all files inside /var/lib/sssd/db? I dont see an option in sss_cache for 
this :/

3. How long is the time where sssd invalidates the sudo rules and make a 
new look into ipa? Can I set this time?

MfG
Christoph Kaminski




-- 
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] DNS Replication Validation

2015-09-24 Thread Rich Megginson 

On 09/24/2015 08:32 AM, Aric Wilisch wrote:

I need a way to validate that both the primary and the redundant FreeIPA 
server’s DNS zones are in sync. What’s the simplest way for me to do this?


Do a DNS query to confirm that the SOA record for the primary is 
identical to the SOA for the secondary.




My boss won’t let me continue with an upgrade until he’s sure the primary and 
redundant servers have the same DNS records and are in sync. I’ve tried finding 
documentation on this but keep coming up blank.

Thanks in advance.



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

2015-09-24 Thread Andy Thompson 


> -Original Message-
> From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
> boun...@redhat.com] On Behalf Of Petr Spacek
> Sent: Thursday, September 24, 2015 9:50 AM
> To: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] IPA server failover
> 
> On 24.9.2015 15:29, Alexander Bokovoy wrote:
> > On Thu, 24 Sep 2015, Andy Thompson wrote:
> >>> -Original Message-
> >>> From: Alexander Bokovoy [mailto:aboko...@redhat.com]
> >>> Sent: Thursday, September 24, 2015 1:17 AM
> >>> To: Andy Thompson 
> >>> Cc: freeipa-users@redhat.com
> >>> Subject: Re: [Freeipa-users] IPA server failover
> >>>
> >>> On Wed, 23 Sep 2015, Andy Thompson wrote:
> >>> >I've got all of my environments setup with two IPA servers.  I'm
> >>> >fighting intermittent problems with krb5kdc crashing on them in all
> >>> >of my environments and I've opened a ticket with Redhat on that.
> >>> >What I can't figure out though is why the clients will not fail
> >>> >over to the second functioning server in the domain
> >>> >
> >>> >My sssd.conf files are all pretty generic from the install with
> >>> >minimal modification to add a couple settings.
> >>> >
> >>> >[domain/mhbe.lin]
> >>> >
> >>> >cache_credentials = True
> >>> >krb5_store_password_if_offline = True ipa_domain = mhbe.lin
> >>> >id_provider = ipa auth_provider = ipa access_provider = ipa
> >>> >ipa_hostname = mdhixproddb01.mhbe.lin chpass_provider = ipa
> >>> >ipa_server = _srv_, mdhixprodipa01.mhbe.lin ldap_tls_cacert =
> >>> >/etc/ipa/ca.crt [sssd] default_domain_suffix = mhbe.local services
> >>> >= nss, sudo, pam, ssh config_file_version = 2
> >>> >
> >>> >domains = mhbe.lin
> >>> >[nss]
> >>> >default_shell = /bin/bash
> >>> >homedir_substring = /home
> >>> >debug_level = 7
> >>> >[pam]
> >>> >
> >>> >[sudo]
> >>> >
> >>> >[autofs]
> >>> >
> >>> >[ssh]
> >>> >
> >>> >[pac]
> >>> >
> >>> >[ifp]
> >>> >
> >>> >I thought the _srv_  would force it to use dns and both servers are
> >>> >round robined when digging the _kerberos records from DNS.  So I
> >>> >don't understand why it's not working
> >>> ipa_server is for SSSD tasks using LDAP server. Kerberos libraries
> >>> are using /etc/krb5.conf for hints where to find KDCs.
> >>>
> >>> A combination of 'dns_lookup_kdc = true' in [libdefaults] and missing
> 'kdc = '
> >>> for specific realm would cause Kerberos clients to do DNS discovery
> >>> using SRV records.
> >>>
> >>
> >> Here are the contents of my krb conf with everything set to lookup
> >> and it doesn't appear to be working.
> >>
> >> includedir /var/lib/sss/pubconf/krb5.include.d/
> >>
> >> [libdefaults]
> >>  default_realm = MHBE.LIN
> >>  dns_lookup_realm = true
> >>  dns_lookup_kdc = true
> >>  rdns = false
> >>  ticket_lifetime = 24h
> >>  forwardable = yes
> >>  udp_preference_limit = 0
> >>
> >>
> >> [realms]
> >>  MHBE.LIN = {
> >>pkinit_anchors = FILE:/etc/ipa/ca.crt
> >>
> >>  }
> >>
> >>
> >> [domain_realm]
> >>  .mhbe.lin = MHBE.LIN
> >>  mhbe.lin = MHBE.LIN
> > I bet you have SSSD supplying you KDC info in
> > /var/lib/sss/pubconf/kdcinfo.MHBE.LIN via
> > /usr/lib64/krb5/plugins/libkrb5/sssd_krb5_locator_plugin.so
> >
> > You can add 'krb5_use_kdcinfo = false' to sssd.conf (domain section),
> > see details in sssd-krb5(5).
> 

I will look into adding this setting.  Why is this not the default 
configuration by the client install?

> Also, I would recommend you to check SRV records in DNS:
> 
> $ dig _kerberos._udp.mhbe.lin SRV
> 
> It should list both servers (with non-zero priority).
> 

Ok both servers are in there but they have a zero priority.  Those are the 
default records added by the install.

-andy

-- 
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] DNS Replication Validation

2015-09-24 Thread Martin Basti 



On 09/24/2015 04:43 PM, Rich Megginson wrote:

On 09/24/2015 08:32 AM, Aric Wilisch wrote:
I need a way to validate that both the primary and the redundant 
FreeIPA server’s DNS zones are in sync. What’s the simplest way for 
me to do this?


Do a DNS query to confirm that the SOA record for the primary is 
identical to the SOA for the secondary.


SOA serials are not replicated.

You can get all  records via AXFR, and compare them per zone.

Maybe you can use python-dns to do comparation

http://www.dnspython.org/examples.html

HTH
Martin




My boss won’t let me continue with an upgrade until he’s sure the 
primary and redundant servers have the same DNS records and are in 
sync. I’ve tried finding documentation on this but keep coming up blank.


Thanks in advance.





--
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] DNS Replication Validation

2015-09-24 Thread Aric Wilisch 
I need a way to validate that both the primary and the redundant FreeIPA 
server’s DNS zones are in sync. What’s the simplest way for me to do this?

My boss won’t let me continue with an upgrade until he’s sure the primary and 
redundant servers have the same DNS records and are in sync. I’ve tried finding 
documentation on this but keep coming up blank. 

Thanks in advance. 

-- 
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] DNS Replication Validation

2015-09-24 Thread Rich Megginson 

On 09/24/2015 08:53 AM, Martin Basti wrote:



On 09/24/2015 04:43 PM, Rich Megginson wrote:

On 09/24/2015 08:32 AM, Aric Wilisch wrote:
I need a way to validate that both the primary and the redundant 
FreeIPA server’s DNS zones are in sync. What’s the simplest way for 
me to do this?


Do a DNS query to confirm that the SOA record for the primary is 
identical to the SOA for the secondary.


SOA serials are not replicated.


So with IPA you can have a master DNS and a replica DNS that have 
different SOA?


Then the records are replicated using the standard IPA dirsrv 
replication protocol?


In that case, doesn't ipa-replica-manage have a way to ask if the 
replicas are in sync?




You can get all  records via AXFR, and compare them per zone.

Maybe you can use python-dns to do comparation

http://www.dnspython.org/examples.html


That seems pretty heavyweight if there are a lot records.



HTH
Martin




My boss won’t let me continue with an upgrade until he’s sure the 
primary and redundant servers have the same DNS records and are in 
sync. I’ve tried finding documentation on this but keep coming up 
blank.


Thanks in advance.







--
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] DNS Replication Validation

2015-09-24 Thread Rich Megginson 

On 09/24/2015 09:24 AM, Aric Wilisch wrote:

Is there a way of exporting the DNS information out of Freeipa? Then I could 
just do a diff on the export from master and replica.


That's what Martin was suggesting you use dnspython to do.




On Sep 24, 2015, at 11:13 AM, Martin Basti  wrote:



On 09/24/2015 05:02 PM, Rich Megginson wrote:

On 09/24/2015 08:53 AM, Martin Basti wrote:


On 09/24/2015 04:43 PM, Rich Megginson wrote:

On 09/24/2015 08:32 AM, Aric Wilisch wrote:

I need a way to validate that both the primary and the redundant FreeIPA 
server’s DNS zones are in sync. What’s the simplest way for me to do this?

Do a DNS query to confirm that the SOA record for the primary is identical to 
the SOA for the secondary.

SOA serials are not replicated.

So with IPA you can have a master DNS and a replica DNS that have different SOA?

Just SOA serial, other records are replicated.


Then the records are replicated using the standard IPA dirsrv replication 
protocol?

In that case, doesn't ipa-replica-manage have a way to ask if the replicas are 
in sync?

I don't think that ipa-replica-manage is capable to detect if replicas are in 
sync.
AFAIK this feature is planned for future IPA versions.
Inspecting DS error log may help to find replication issues if any.

Martin


You can get all  records via AXFR, and compare them per zone.

Maybe you can use python-dns to do comparation

http://www.dnspython.org/examples.html

That seems pretty heavyweight if there are a lot records.


HTH
Martin

My boss won’t let me continue with an upgrade until he’s sure the primary and 
redundant servers have the same DNS records and are in sync. I’ve tried finding 
documentation on this but keep coming up blank.

Thanks in advance.


--
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] DNS Replication Validation

2015-09-24 Thread Martin Basti 



On 09/24/2015 05:02 PM, Rich Megginson wrote:

On 09/24/2015 08:53 AM, Martin Basti wrote:



On 09/24/2015 04:43 PM, Rich Megginson wrote:

On 09/24/2015 08:32 AM, Aric Wilisch wrote:
I need a way to validate that both the primary and the redundant 
FreeIPA server’s DNS zones are in sync. What’s the simplest way for 
me to do this?


Do a DNS query to confirm that the SOA record for the primary is 
identical to the SOA for the secondary.


SOA serials are not replicated.


So with IPA you can have a master DNS and a replica DNS that have 
different SOA?

Just SOA serial, other records are replicated.



Then the records are replicated using the standard IPA dirsrv 
replication protocol?


In that case, doesn't ipa-replica-manage have a way to ask if the 
replicas are in sync?
I don't think that ipa-replica-manage is capable to detect if replicas 
are in sync.

AFAIK this feature is planned for future IPA versions.
Inspecting DS error log may help to find replication issues if any.

Martin





You can get all  records via AXFR, and compare them per zone.

Maybe you can use python-dns to do comparation

http://www.dnspython.org/examples.html


That seems pretty heavyweight if there are a lot records.



HTH
Martin




My boss won’t let me continue with an upgrade until he’s sure the 
primary and redundant servers have the same DNS records and are in 
sync. I’ve tried finding documentation on this but keep coming up 
blank.


Thanks in advance.









--
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] DNS Replication Validation

2015-09-24 Thread Aric Wilisch 
Is there a way of exporting the DNS information out of Freeipa? Then I could 
just do a diff on the export from master and replica. 

> On Sep 24, 2015, at 11:13 AM, Martin Basti  wrote:
> 
> 
> 
> On 09/24/2015 05:02 PM, Rich Megginson wrote:
>> On 09/24/2015 08:53 AM, Martin Basti wrote:
>>> 
>>> 
>>> On 09/24/2015 04:43 PM, Rich Megginson wrote:
 On 09/24/2015 08:32 AM, Aric Wilisch wrote:
> I need a way to validate that both the primary and the redundant FreeIPA 
> server’s DNS zones are in sync. What’s the simplest way for me to do this?
 
 Do a DNS query to confirm that the SOA record for the primary is identical 
 to the SOA for the secondary.
>>> 
>>> SOA serials are not replicated.
>> 
>> So with IPA you can have a master DNS and a replica DNS that have different 
>> SOA?
> Just SOA serial, other records are replicated.
> 
>> 
>> Then the records are replicated using the standard IPA dirsrv replication 
>> protocol?
>> 
>> In that case, doesn't ipa-replica-manage have a way to ask if the replicas 
>> are in sync?
> I don't think that ipa-replica-manage is capable to detect if replicas are in 
> sync.
> AFAIK this feature is planned for future IPA versions.
> Inspecting DS error log may help to find replication issues if any.
> 
> Martin
> 
>> 
>>> 
>>> You can get all  records via AXFR, and compare them per zone.
>>> 
>>> Maybe you can use python-dns to do comparation
>>> 
>>> http://www.dnspython.org/examples.html
>> 
>> That seems pretty heavyweight if there are a lot records.
>> 
>>> 
>>> HTH
>>> Martin
 
> 
> My boss won’t let me continue with an upgrade until he’s sure the primary 
> and redundant servers have the same DNS records and are in sync. I’ve 
> tried finding documentation on this but keep coming up blank.
> 
> Thanks in advance.
> 
 
>>> 
>> 
> 
> -- 
> 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