Re: [Freeipa-users] vsftpd PAM setup problem

2014-10-31 Thread Thomas Lau
Thanks, all good now.

On Fri, Oct 31, 2014 at 1:40 PM, Alexander Bokovoy aboko...@redhat.com
wrote:

 On Fri, 31 Oct 2014, Thomas Lau wrote:

 Hi All,

 I am using vsftpd and auth against PAM (eventually to sss), but I can't
 login even using admin account, anyone could provide some hints on how to
 make it work? here is the detail log on sssd_us.domain.com.log:


 You need to fix permissions of /tmp:

 [krb5_auth_prepare_ccache_name] (0x4000): Recreating  ccache file.
 [check_parent_stat] (0x0020): Private directory can only be created below
 a directory belonging to root or to [121843][121843].
 [create_ccache_dir] (0x0080): check_parent_stat failed for directory
 [/tmp].
 [krb5_auth_prepare_ccache_name] (0x0040): ccache creation failed.
 [ipa_auth_handler_done] (0x0040): krb5_auth_recv request failed.
 [be_pam_handler_callback] (0x0100): Backend returned: (0, 4, NULL)
 [Success]



 --
 / Alexander Bokovoy




-- 
Thomas Lau
Director of Infrastructure
Tetrion Capital Limited

Mobile: +852-9323-9670
Address: 20/F, IFC 1, Central district, Hong Kong
-- 
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] Errors upgrading 4.0.1 to 4.1

2014-10-31 Thread Ludwig Krispenz


On 10/30/2014 07:36 PM, Martin Basti wrote:

On 30/10/14 19:18, Michael Lasevich wrote:

Makes sense. What is the solution here?

I have the latest 389-ds installed but still getting 
allowWeakCipher error - how to I get around that?


-M


Sorry I don't know, I CCied Ludwig, he is DS guru.

I already asked to verify the schema files:
can you check your schema files for the definition of the 
nsEncryptionConfig objectclass, it should be only in 01core389.ldif and 
contain allowWeakCipher, but it could have been added also to 
99user.ldif during replication when schema changes have been consolidated


and what is the latest ds version you are using: rpm -q 389-ds-base



Martin^2



On 10/30/14, 11:12 AM, Martin Basti wrote:

On 24/10/14 05:17, Michael Lasevich wrote:
While upgrading from 4.0.1. to 4.1 on fedora 20 got following on 
one of the two boxes:


Upgrade failed with attribute allowWeakCipher not allowed
IPA upgrade failed.
Unexpected error
DuplicateEntry: This entry already exists



Named errors are caused by cascade effect, if ldap schema and entry 
updates failed, there is misconfigured DS plugin which is 
responsible to keep DNSSEC keys DN unique, what causes duplication 
errors. DuplicateEntry exception is fatal, so dnskeysyncd 
installation will not continue,
what causes there are not appropriate permissions for token 
database, and named-pkcs11 can't read tokens.



It seems the ipa no longer starts up after this. The replica server 
seems to have had same error,but it runs just fine.


From digging around, it appears that there are a number of GSS 
errors in dirsrv and bind fails with something like:


named-pkcs11[2212]: ObjectStore.cpp(74): Failed to open token 
e919db16-6329-406c-6ae4-120ad68508c4

named-pkcs11[2212]: sha1.c:92: fatal error:
named-pkcs11[2212]: RUNTIME_CHECK(pk11_get_session(ctx, OP_DIGEST, 
isc_boolean_true, isc_boolean_false, isc_boolean_false, ((void 
*)0), 0) == 0) failed


Any help would be appreciated


-M






--
Martin Basti





--
Martin Basti


-- 
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] Centos IPA Client fails after upgrade to 6.6

2014-10-31 Thread Jakub Hrozek

 On 31 Oct 2014, at 02:23, David Taylor david.tay...@speedcast.com wrote:
 
 I just recently updated one of our test servers from CentOS 6.5 to CentOS 
 6.6, after which I noticed that IPA logons were no longer available. From 
 what I can see the upgrade includes quite a few changes with regard to sssd.
  
 -  NTP is up and synced on the Auth servers and the client.
 -  DNS is working to the IPA servers
 -  I can do a kinit for users with no problem
 -  I have uninstalled the ipa client, deleted the host profile on the 
 IPA server and one a rejoin. The rejoin worked but the problem is the same.
  
 Software versions using 
 -  rpm -qa | grep -i ipa
 -  rpm -qa | grep -i sssd
  
 Software versions before:
 libipa_hbac-1.9.2-129.el6_5.4.x86_64
 device-mapper-multipath-0.4.9-72.el6_5.4.x86_64
 libipa_hbac-python-1.9.2-129.el6_5.4.x86_64
 ipa-python-3.0.0-37.el6.x86_64
 ipa-client-3.0.0-37.el6.x86_64
 device-mapper-multipath-libs-0.4.9-72.el6_5.4.x86_64
 sssd-1.9.2-129.el6_5.4.x86_64
 sssd-client-1.9.2-129.el6_5.4.x86_64
  
 Software version after:
 sssd-ipa-1.11.6-30.el6.x86_64
 libipa_hbac-1.11.6-30.el6.x86_64
 device-mapper-multipath-libs-0.4.9-80.el6.x86_64
 ipa-client-3.0.0-42.el6.centos.x86_64
 libipa_hbac-python-1.11.6-30.el6.x86_64
 ipa-python-3.0.0-42.el6.centos.x86_64
 device-mapper-multipath-0.4.9-80.el6.x86_64
 sssd-ldap-1.11.6-30.el6.x86_64
 sssd-ad-1.11.6-30.el6.x86_64
 python-sssdconfig-1.11.6-30.el6.noarch
 sssd-client-1.11.6-30.el6.x86_64
 sssd-krb5-common-1.11.6-30.el6.x86_64
 sssd-ipa-1.11.6-30.el6.x86_64
 sssd-common-1.11.6-30.el6.x86_64
 sssd-proxy-1.11.6-30.el6.x86_64
 sssd-common-pac-1.11.6-30.el6.x86_64
 sssd-krb5-1.11.6-30.el6.x86_64
 sssd-1.11.6-30.el6.x86_64
 The /var/log/secure logs show the following
  
 Oct 31 10:38:30 test01 sshd[2790]: Invalid user dtaylor from ip removed
 Oct 31 10:38:30 test01 sshd[2791]: input_userauth_request: invalid user 
 dtaylor
 Oct 31 10:38:30 test01 sshd[2790]: pam_unix(sshd:auth): check pass; user 
 unknown
 Oct 31 10:38:30 test01 sshd[2790]: pam_unix(sshd:auth): authentication 
 failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=host removed
 Oct 31 10:38:30 test01 sshd[2790]: pam_succeed_if(sshd:auth): error 
 retrieving information about user dtaylor
  

Do you also see pam_sss being mentioned at all in your /var/log/secure at all? 
Can you paste your PAM configuration? It’s expected that pam_unix fails to find 
the IPA user, but I would also expect the PAM stack to ask pam_sss next...

 The /var/log/audit/audit.log logs show the following
  
 type=CRYPTO_KEY_USER msg=audit(1414715857.270:107): user pid=5831 uid=0 
 auid=0 ses=1 msg='op=destroy kind=server 
 fp=5e:ee:58:a2:25:ec:16:3e:8c:61:01:e6:de:76:3d:32 direction=? spid=5831 
 suid=0  exe=/usr/sbin/sshd hostname=? addr=ip removed terminal=? 
 res=success'
 type=CRYPTO_KEY_USER msg=audit(1414715857.270:108): user pid=5831 uid=0 
 auid=0 ses=1 msg='op=destroy kind=server 
 fp=d0:6f:2f:5f:49:44:94:f2:b2:4e:15:43:69:89:9c:1d direction=? spid=5831 
 suid=0  exe=/usr/sbin/sshd hostname=? addr=ip removed terminal=? 
 res=success'
 type=CRYPTO_SESSION msg=audit(1414715857.272:109): user pid=5830 uid=0 auid=0 
 ses=1 msg='op=start direction=from-client cipher=aes256-ctr ksize=256 
 spid=5831 suid=74 rport=44361 laddr=Client ip removed lport=22  
 exe=/usr/sbin/sshd hostname=? addr=ip removed terminal=? res=success'
 type=CRYPTO_SESSION msg=audit(1414715857.272:110): user pid=5830 uid=0 auid=0 
 ses=1 msg='op=start direction=from-server cipher=aes256-ctr ksize=256 
 spid=5831 suid=74 rport=44361 laddr=Client ip removed lport=22  
 exe=/usr/sbin/sshd hostname=? addr=ip removed terminal=? res=success'
 type=USER_LOGIN msg=audit(1414715857.310:111): user pid=5830 uid=0 auid=0 
 ses=1 msg='op=login acct=28756E6B6E6F776E207573657229 exe=/usr/sbin/sshd 
 hostname=? addr=ip removed terminal=ssh res=failed'
 type=USER_AUTH msg=audit(1414715859.211:112): user pid=5830 uid=0 auid=0 
 ses=1 msg='op=PAM:authentication acct=? exe=/usr/sbin/sshd 
 hostname=hostname removed addr=ip removed terminal=ssh res=failed'
 type=USER_AUTH msg=audit(1414715859.212:113): user pid=5830 uid=0 auid=0 
 ses=1 msg='op=password acct=28696E76616C6964207573657229 exe=/usr/sbin/sshd 
 hostname=? addr=ip removed terminal=ssh res=failed'
 type=CRYPTO_KEY_USER msg=audit(1414715862.076:114): user pid=5830 uid=0 
 auid=0 ses=1 msg='op=destroy kind=session fp=? direction=both spid=5831 
 suid=74 rport=44361 laddr=Client ip removed lport=22  exe=/usr/sbin/sshd 
 hostname=? addr=ip removed terminal=? res=success'
 type=CRYPTO_KEY_USER msg=audit(1414715862.078:115): user pid=5830 uid=0 
 auid=0 ses=1 msg='op=destroy kind=server 
 fp=5e:ee:58:a2:25:ec:16:3e:8c:61:01:e6:de:76:3d:32 direction=? spid=5830 
 suid=0  exe=/usr/sbin/sshd hostname=? addr=ip removed terminal=? 
 res=success'
 type=CRYPTO_KEY_USER msg=audit(1414715862.079:116): user pid=5830 uid=0 
 auid=0 ses=1 msg='op=destroy 

Re: [Freeipa-users] [SOLVED] IPA DNS response issue

2014-10-31 Thread Petr Spacek

On 19.3.2014 15:12, David wrote:

On Wed, Mar 19, 2014 at 01:57:24PM +0100, Petr Spacek wrote:

On 18.3.2014 15:26, David wrote:

We have an installation of FreeIPA (through CentOS 6.5) that's exhibiting some
odd behavior with respect to serving DNS.  Periodically (interval at random)
named running on a replica will stop serving requests from the LDAP server but
continue to respond with recursive requests.  This type of failure causes us
problems, as you could imagine.  (It doesn't fail cleanly so it won't request
from another server.)  We've adjusted the amount of connections each named
makes to 389, but it doesn't seem to make a difference.  We're not seeing
anything in the logs so troubleshooting this is becoming a bit of a
(high-visibility) puzzle to us.

I do happen to have a core file that I grabbed last night before sending a
SIGKILL to named and restarting.  (A SIGTERM has no effect.)

Hopefully there's an easy answer here that we can get rolled into the
environment quickly.  FreeIPA has treated us extraordinarily well so far!


snip


Note that David (I guess :-) added logs to the ticket
https://fedorahosted.org/bind-dyndb-ldap/ticket/131
and I'm looking into it.


Actually, that's not me!  I don't have anywhere near as much logging...
At least I'm not alone...

Our failures also seem to happen around log rotation time.

The Kerberos ticket expiring is interesting.  I'll poke around on my
installation and see what I see on this side.

If you need any other information, please let me know.


FYI the problem was discovered  fixed a while ago but I did not sent reply to 
you. It was fixed in all maintained branches (v2+) of bind-dyndb-ldap.


All supported versions of Fedora were patched so it should not happen again.

You can watch RHEL status on:

RHEL 6.y:
https://bugzilla.redhat.com/show_bug.cgi?id=1142176
https://bugzilla.redhat.com/show_bug.cgi?id=1142152

RHEL 7.y:
https://bugzilla.redhat.com/show_bug.cgi?id=1142150

Have a nice day!

--
Petr^2 Spacek

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


[Freeipa-users] DNS forwarders in 4.1.0

2014-10-31 Thread Rolf Nufable
Hello , 

I've been trying to install freeipa server v 4.1.0 on my fedora 20 machine and 
I can't complete the installation because of hte DNS forwarders 

my machine's IP is 192.168.254.7 and I'm using the same IP for DNS forwarders, 
this is what I did when I was installing 4.0.3 and 3.3.5 and it installed 
smoothly ,  so my question is why won't it work in 4.1.0 ? is there something 
new when configuring DNS forwarders? -- 
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 forwarders in 4.1.0

2014-10-31 Thread Petr Spacek

On 31.10.2014 04:38, Rolf Nufable wrote:

Hello ,

I've been trying to install freeipa server v 4.1.0 on my fedora 20 machine and 
I can't complete the installation because of hte DNS forwarders


What exactly is the problem/symptom? Are you receiving an error? Or something 
else?


We need to see exact package versions, parameters you have used, messages, 
logs etc.



my machine's IP is 192.168.254.7 and I'm using the same IP for DNS forwarders, 
this is what I did when I was installing 4.0.3 and 3.3.5 and it installed 
smoothly ,  so my question is why won't it work in 4.1.0 ? is there something 
new when configuring DNS forwarders?


I'm not sure I understand you.

What do you mean with 'my machine'? Is it the (to-be-installed) IPA server? Or 
some other machine?


Are you installing IPA with or without DNS?

There is no point in configuring IPA to use itself as forwarder.

Please tell us what exactly doesn't work for you :-)

--
Petr^2 Spacek

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


[Freeipa-users] Extra attributes for sync agreement AD to FreeIPA

2014-10-31 Thread Edouard Guigné

Hello freeipa Users,

I am working on a sync agreement between AD server - FreeIPA server 
(fedora 20)


I follow the documentation, my sync works beetwen AD - FreeIPA with 
ipa-replica-manage connect --winsync ...


However, I would like to extract attributes from my AD like :
- uidNumber
- gidNumber
- unixHomeDirectory
- loginShell
- msSFU30NisDomain
My AD server is 2008 R2 with with Subsystem for UNIX-based Applications.

I would like rerieve these attributes in my freeipa server after sync.

I had a look on google, and find informations like this :
https://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/managing-sync-agmt.html#tab.sync-agmt-attrs
But I did not succeed with it.

May someone help me ?




--
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] Extra attributes for sync agreement AD to FreeIPA

2014-10-31 Thread Rob Crittenden
Edouard Guigné wrote:
 Hello freeipa Users,
 
 I am working on a sync agreement between AD server - FreeIPA server
 (fedora 20)
 
 I follow the documentation, my sync works beetwen AD - FreeIPA with
 ipa-replica-manage connect --winsync ...
 
 However, I would like to extract attributes from my AD like :
 - uidNumber
 - gidNumber
 - unixHomeDirectory
 - loginShell
 - msSFU30NisDomain
 My AD server is 2008 R2 with with Subsystem for UNIX-based Applications.
 
 I would like rerieve these attributes in my freeipa server after sync.
 
 I had a look on google, and find informations like this :
 https://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/managing-sync-agmt.html#tab.sync-agmt-attrs
 
 But I did not succeed with it.
 
 May someone help me ?
 

It should already work:

http://www.port389.org/docs/389ds/design/winsync-posix.html

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] Replication fails after CentOS 6.5 - 6.6 Upgrade - sasl_io_recv failed to decode packet for connection xxxx

2014-10-31 Thread Michael Mercier
Hello,

I just did a 'yum update' from CentOS 6.5 - 6.6 on my freeipa system
(master and 2 replicas) and I seen to have run into the following bug,

https://bugzilla.redhat.com/show_bug.cgi?id=953653

On Master:

[root@srv-1 slapd-CN-LOCAL]# rpm -qa|grep ipa
ipa-client-3.0.0-42.el6.centos.x86_64
libipa_hbac-python-1.11.6-30.el6.x86_64
python-iniparse-0.3.1-2.1.el6.noarch
ipa-python-3.0.0-42.el6.centos.x86_64
sssd-ipa-1.11.6-30.el6.x86_64
ipa-server-3.0.0-42.el6.centos.x86_64
ipa-server-selinux-3.0.0-42.el6.centos.x86_64
libipa_hbac-1.11.6-30.el6.x86_64
ipa-admintools-3.0.0-42.el6.centos.x86_64
ipa-pki-common-theme-9.0.3-7.el6.noarch
ipa-pki-ca-theme-9.0.3-7.el6.noarch
[root@srv-1 slapd-CN-LOCAL]# rpm -qa|grep 389
389-ds-base-1.2.11.15-47.el6.x86_64
389-ds-base-libs-1.2.11.15-47.el6.x86_64

ldapsearch -b cn=config -D cn=Directory Manager -W | grep
nsslapd-sasl-max-buffer-size
nsslapd-sasl-max-buffer-size: 65536

[root@srv-1]tail /etc/dirsrv/slapd-/errors
[31/Oct/2014:10:59:51 -0400] - sasl_io_recv failed to decode packet for
connection 2313
[31/Oct/2014:10:59:55 -0400] - sasl_io_recv failed to decode packet for
connection 2314
[31/Oct/2014:11:00:00 -0400] - sasl_io_recv failed to decode packet for
connection 2316
[31/Oct/2014:11:00:01 -0400] - sasl_io_recv failed to decode packet for
connection 2315

On Replica:
[root@srv-2 slapd-CN-LOCAL]# rpm -qa|grep ipa
ipa-server-selinux-3.0.0-42.el6.centos.x86_64
libipa_hbac-1.11.6-30.el6.x86_64
ipa-admintools-3.0.0-42.el6.centos.x86_64
python-iniparse-0.3.1-2.1.el6.noarch
ipa-pki-common-theme-9.0.3-7.el6.noarch
ipa-server-3.0.0-42.el6.centos.x86_64
ipa-client-3.0.0-42.el6.centos.x86_64
ipa-pki-ca-theme-9.0.3-7.el6.noarch
libipa_hbac-python-1.11.6-30.el6.x86_64
ipa-python-3.0.0-42.el6.centos.x86_64
sssd-ipa-1.11.6-30.el6.x86_64
[root@srv-2 slapd-CN-LOCAL]# rpm -qa|grep 389
389-ds-base-1.2.11.15-47.el6.x86_64
389-ds-base-libs-1.2.11.15-47.el6.x86_64
[root@srv-2 slapd-CN-LOCAL]# ldapsearch -b cn=config -D cn=Directory
Manager -W | grep nsslapd-sasl-max-buffer-size
Enter LDAP Password:
nsslapd-sasl-max-buffer-size: 65536

[root@svr-2]tail -f /etc/dirsrv/slapd-/errors
[31/Oct/2014:11:01:11 -0400] NSMMReplicationPlugin -
agmt=cn=meTosrv-1. (srv-1:389): Replication bind with GSSAPI auth
resumed
[31/Oct/2014:11:01:18 -0400] NSMMReplicationPlugin -
agmt=cn=meTosrv-1. (srv-1:389): Warning: unable to replicate
schema: rc=2
[31/Oct/2014:11:01:18 -0400] NSMMReplicationPlugin -
agmt=cn=meTosrv-1. (srv-1:389): Consumer failed to replay change
(uniqueid (null), CSN (null)): Can't contact LDAP server(-1). Will retry
later.
[31/Oct/2014:11:01:18 -0400] NSMMReplicationPlugin -
agmt=cn=meTosrv-1. (srv-1:389): Failed to send update operation to
consumer (uniqueid 515cdb0f-24fa11e2-816add07-a91dabe7, CSN
5453fc2600090003): Can't contact LDAP server. Will retry later.
[31/Oct/2014:11:01:18 -0400] NSMMReplicationPlugin -
agmt=cn=meTosrv-1. (srv-1:389): Warning: unable to send
endReplication extended operation (Can't contact LDAP server)

In the ticket, Scott Poore says he increased the
nsslapd-sasl-max-buffer-size to work around the problem.  Is this the
correct course of action, or should I be trying something else?

Thanks,
Mike

-- 
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] strange error from EL 7 install?

2014-10-31 Thread Christoph Maser
On Mon, Oct 13, 2014 at 10:08:55PM -0700, Janelle wrote:
 Actually, I did find a fix and forgot to post.
 
 I was able to mirror the COPR repo, and after reviewing it, found that
 simply removing the pki-base...fc21 directory, and regenning the repo data
 with createrepo, fixed the problem. It drops the version of PKI back to the
 10.1 branch and that resolved the dependencies.
 
 Hope this helps,
 Janelle
 

You don't need to mirror the repo for that simply using
yum-plugin-versionlock would be sufficient, unfortunatly now that
solution does not work any more since the freeipa-server package
depends on pki-ca = 10.2.0-3 wich in turn depends on the 10.2.x
pki-server and pki-base packages.

I checked out what it would take to backport
jackson-jaxrs-json-provider to CentOS 7 and this is quite a task. The
fedora 21 packages build up a dependency chain wich
includes aspectjweaver, eclipselink, springframework and some more stuff

Does mkosek offer a repo with older builds wich are considered working?

Chris

-- 
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] Extra attributes for sync agreement AD to FreeIPA

2014-10-31 Thread Rob Crittenden
Edouard Guigné wrote:
 Hello Rob,
 
 Thank you for your answer.
 Do you mean it should already work ?
 Or I have to do this on the FreeIPA server :
 
 |rm /etc/dirsrv/slapd-INSTNAME/schema/10rfc2307.ldif
 cp /usr/share/dirsrv/data/10rfc2307bis.ldif /etc/dirsrv/slapd-INSTNAME/schema

Sorry, I guess I was a little terse.

The nisDomain is already defined for IPA so you can skip that bit.

The Posix Winsync Plugin is disabled by default. You'll need to enable
it and configure it to match your environment. See the wiki page for
configuration details.

You can either enable and configure it online by using ldapmodify and
binding as the Directory Manager or by shutting down 389-ds and
modifying dse.ldif, then restarting it (or use a tool like Apache
Directory Studio).

rob

 
 
 |
 
 Best Regards, have a nice we.
 Ed
 
 Le 31/10/2014 16:04, Rob Crittenden a écrit :
 Edouard Guigné wrote:
 Hello freeipa Users,

 I am working on a sync agreement between AD server - FreeIPA server
 (fedora 20)

 I follow the documentation, my sync works beetwen AD - FreeIPA with
 ipa-replica-manage connect --winsync ...

 However, I would like to extract attributes from my AD like :
 - uidNumber
 - gidNumber
 - unixHomeDirectory
 - loginShell
 - msSFU30NisDomain
 My AD server is 2008 R2 with with Subsystem for UNIX-based Applications.

 I would like rerieve these attributes in my freeipa server after sync.

 I had a look on google, and find informations like this :
 https://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/managing-sync-agmt.html#tab.sync-agmt-attrs

 But I did not succeed with it.

 May someone help me ?

 It should already work:

 http://www.port389.org/docs/389ds/design/winsync-posix.html

 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] Replication fails after CentOS 6.5 - 6.6 Upgrade - sasl_io_recv failed to decode packet for connection xxxx

2014-10-31 Thread Craig White


Craig White
System Administrator
O 623-201-8179   M 602-377-9752



SkyTouch Technology 4225 E. Windrose Dr. Phoenix, AZ 85032


-Original Message-
From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Michael Mercier
Sent: Friday, October 31, 2014 8:12 AM
To: freeipa-users@redhat.com
Subject: [Freeipa-users] Replication fails after CentOS 6.5 - 6.6 Upgrade - 
sasl_io_recv failed to decode packet for connection 

Hello,

I just did a 'yum update' from CentOS 6.5 - 6.6 on my freeipa system (master 
and 2 replicas) and I seen to have run into the following bug,

https://bugzilla.redhat.com/show_bug.cgi?id=953653

On Master:

[root@srv-1 slapd-CN-LOCAL]# rpm -qa|grep ipa
ipa-client-3.0.0-42.el6.centos.x86_64
libipa_hbac-python-1.11.6-30.el6.x86_64
python-iniparse-0.3.1-2.1.el6.noarch
ipa-python-3.0.0-42.el6.centos.x86_64
sssd-ipa-1.11.6-30.el6.x86_64
ipa-server-3.0.0-42.el6.centos.x86_64
ipa-server-selinux-3.0.0-42.el6.centos.x86_64
libipa_hbac-1.11.6-30.el6.x86_64
ipa-admintools-3.0.0-42.el6.centos.x86_64
ipa-pki-common-theme-9.0.3-7.el6.noarch
ipa-pki-ca-theme-9.0.3-7.el6.noarch
[root@srv-1 slapd-CN-LOCAL]# rpm -qa|grep 389
389-ds-base-1.2.11.15-47.el6.x86_64
389-ds-base-libs-1.2.11.15-47.el6.x86_64

ldapsearch -b cn=config -D cn=Directory Manager -W | grep 
nsslapd-sasl-max-buffer-size
nsslapd-sasl-max-buffer-size: 65536

[root@srv-1]tail /etc/dirsrv/slapd-/errors
[31/Oct/2014:10:59:51 -0400] - sasl_io_recv failed to decode packet for 
connection 2313
[31/Oct/2014:10:59:55 -0400] - sasl_io_recv failed to decode packet for 
connection 2314
[31/Oct/2014:11:00:00 -0400] - sasl_io_recv failed to decode packet for 
connection 2316
[31/Oct/2014:11:00:01 -0400] - sasl_io_recv failed to decode packet for 
connection 2315

On Replica:
[root@srv-2 slapd-CN-LOCAL]# rpm -qa|grep ipa
ipa-server-selinux-3.0.0-42.el6.centos.x86_64
libipa_hbac-1.11.6-30.el6.x86_64
ipa-admintools-3.0.0-42.el6.centos.x86_64
python-iniparse-0.3.1-2.1.el6.noarch
ipa-pki-common-theme-9.0.3-7.el6.noarch
ipa-server-3.0.0-42.el6.centos.x86_64
ipa-client-3.0.0-42.el6.centos.x86_64
ipa-pki-ca-theme-9.0.3-7.el6.noarch
libipa_hbac-python-1.11.6-30.el6.x86_64
ipa-python-3.0.0-42.el6.centos.x86_64
sssd-ipa-1.11.6-30.el6.x86_64
[root@srv-2 slapd-CN-LOCAL]# rpm -qa|grep 389
389-ds-base-1.2.11.15-47.el6.x86_64
389-ds-base-libs-1.2.11.15-47.el6.x86_64
[root@srv-2 slapd-CN-LOCAL]# ldapsearch -b cn=config -D cn=Directory Manager 
-W | grep nsslapd-sasl-max-buffer-size Enter LDAP Password:
nsslapd-sasl-max-buffer-size: 65536

[root@svr-2]tail -f /etc/dirsrv/slapd-/errors
[31/Oct/2014:11:01:11 -0400] NSMMReplicationPlugin - agmt=cn=meTosrv-1. 
(srv-1:389): Replication bind with GSSAPI auth resumed
[31/Oct/2014:11:01:18 -0400] NSMMReplicationPlugin - agmt=cn=meTosrv-1. 
(srv-1:389): Warning: unable to replicate
schema: rc=2
[31/Oct/2014:11:01:18 -0400] NSMMReplicationPlugin - agmt=cn=meTosrv-1. 
(srv-1:389): Consumer failed to replay change (uniqueid (null), CSN (null)): 
Can't contact LDAP server(-1). Will retry later.
[31/Oct/2014:11:01:18 -0400] NSMMReplicationPlugin - agmt=cn=meTosrv-1. 
(srv-1:389): Failed to send update operation to consumer (uniqueid 
515cdb0f-24fa11e2-816add07-a91dabe7, CSN
5453fc2600090003): Can't contact LDAP server. Will retry later.
[31/Oct/2014:11:01:18 -0400] NSMMReplicationPlugin - agmt=cn=meTosrv-1. 
(srv-1:389): Warning: unable to send endReplication extended operation (Can't 
contact LDAP server)

In the ticket, Scott Poore says he increased the nsslapd-sasl-max-buffer-size 
to work around the problem.  Is this the correct course of action, or should I 
be trying something else?

I can't speak with certainty but I can tell you that increasing the buffer 
solved my replication problem immediately.

Craig

-- 
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 forwarders in 4.1.0

2014-10-31 Thread Dmitri Pal

On 10/31/2014 10:42 AM, Petr Spacek wrote:

On 31.10.2014 04:38, Rolf Nufable wrote:

Hello ,

I've been trying to install freeipa server v 4.1.0 on my fedora 20 
machine and I can't complete the installation because of hte DNS 
forwarders


What exactly is the problem/symptom? Are you receiving an error? Or 
something else?


We need to see exact package versions, parameters you have used, 
messages, logs etc.


my machine's IP is 192.168.254.7 and I'm using the same IP for DNS 
forwarders, this is what I did when I was installing 4.0.3 and 3.3.5 
and it installed smoothly ,  so my question is why won't it work in 
4.1.0 ? is there something new when configuring DNS forwarders?


I'm not sure I understand you.

What do you mean with 'my machine'? Is it the (to-be-installed) IPA 
server? Or some other machine?


Are you installing IPA with or without DNS?

There is no point in configuring IPA to use itself as forwarder.

Please tell us what exactly doesn't work for you :-)

And back to your original question: 4.1 has a lot of changes related to 
DNSSEC work so something might be broken and we like to understand what 
and why.


--
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] Extra attributes for sync agreement AD to FreeIPA

2014-10-31 Thread Dmitri Pal

On 10/31/2014 11:49 AM, Rob Crittenden wrote:

Edouard Guigné wrote:

Hello Rob,

Thank you for your answer.
Do you mean it should already work ?
Or I have to do this on the FreeIPA server :

|rm /etc/dirsrv/slapd-INSTNAME/schema/10rfc2307.ldif
cp /usr/share/dirsrv/data/10rfc2307bis.ldif /etc/dirsrv/slapd-INSTNAME/schema

Sorry, I guess I was a little terse.

The nisDomain is already defined for IPA so you can skip that bit.

The Posix Winsync Plugin is disabled by default. You'll need to enable
it and configure it to match your environment. See the wiki page for
configuration details.

You can either enable and configure it online by using ldapmodify and
binding as the Directory Manager or by shutting down 389-ds and
modifying dse.ldif, then restarting it (or use a tool like Apache
Directory Studio).

rob



|

Best Regards, have a nice we.
Ed

Le 31/10/2014 16:04, Rob Crittenden a écrit :

Edouard Guigné wrote:

Hello freeipa Users,

I am working on a sync agreement between AD server - FreeIPA server
(fedora 20)

I follow the documentation, my sync works beetwen AD - FreeIPA with
ipa-replica-manage connect --winsync ...

However, I would like to extract attributes from my AD like :
- uidNumber
- gidNumber
- unixHomeDirectory
- loginShell
- msSFU30NisDomain
My AD server is 2008 R2 with with Subsystem for UNIX-based Applications.

I would like rerieve these attributes in my freeipa server after sync.

I had a look on google, and find informations like this :
https://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/managing-sync-agmt.html#tab.sync-agmt-attrs

But I did not succeed with it.

May someone help me ?


It should already work:

http://www.port389.org/docs/389ds/design/winsync-posix.html

rob




I just want to mention that this is not a recommended approach.
While the plugin exists in DS it is not enabled or supported for IPA.
The supported way to deal with POSIX attribute in AD is to use trust 
with AD rather than sync.
Is this a one time move of the accounts from AD to IPA and you plan to 
turn the plugin off after initial sync?

If not it will be a configuration we would recommend.
If you just want to copy attributes using ipa migrate-ds or dumping 
accounts into LDIF and then loading LDIF would be a better option.



--
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] Errors upgrading 4.0.1 to 4.1

2014-10-31 Thread Michael Lasevich
Thank you!!! That was exactly it.

* Removed the nsEncryptionConfig entry from 99user.ldif
* Re-run the ipa-ldap-update --upgrade
* Then ipa-dns-install and things are looking much better - both
servers are now back up and running.

What is the lesson here (besides have good backups)?

Should we be turning off ALL servers before upgrading to prevent
replication? I did notice that the 99user entry was made it to BOTH
servers, which makes me think that replication is not exactly the culprit.

-M

On 10/31/14, 1:30 AM, Ludwig Krispenz wrote:

 On 10/30/2014 07:36 PM, Martin Basti wrote:
 On 30/10/14 19:18, Michael Lasevich wrote:
 Makes sense. What is the solution here?

 I have the latest 389-ds installed but still getting
 allowWeakCipher error - how to I get around that?

 -M

 Sorry I don't know, I CCied Ludwig, he is DS guru.
 I already asked to verify the schema files:
 can you check your schema files for the definition of the
 nsEncryptionConfig objectclass, it should be only in 01core389.ldif
 and contain allowWeakCipher, but it could have been added also to
 99user.ldif during replication when schema changes have been consolidated

 and what is the latest ds version you are using: rpm -q 389-ds-base


 Martin^2


 On 10/30/14, 11:12 AM, Martin Basti wrote:
 On 24/10/14 05:17, Michael Lasevich wrote:
 While upgrading from 4.0.1. to 4.1 on fedora 20 got following on
 one of the two boxes:

 Upgrade failed with attribute allowWeakCipher not allowed
 IPA upgrade failed.
 Unexpected error
 DuplicateEntry: This entry already exists


 Named errors are caused by cascade effect, if ldap schema and entry
 updates failed, there is misconfigured DS plugin which is
 responsible to keep DNSSEC keys DN unique, what causes duplication
 errors. DuplicateEntry exception is fatal, so dnskeysyncd
 installation will not continue,
 what causes there are not appropriate permissions for token
 database, and named-pkcs11 can't read tokens.


 It seems the ipa no longer starts up after this. The replica
 server seems to have had same error,but it runs just fine.

 From digging around, it appears that there are a number of GSS
 errors in dirsrv and bind fails with something like:

 named-pkcs11[2212]: ObjectStore.cpp(74): Failed to open token
 e919db16-6329-406c-6ae4-120ad68508c4
 named-pkcs11[2212]: sha1.c:92: fatal error:
 named-pkcs11[2212]: RUNTIME_CHECK(pk11_get_session(ctx, OP_DIGEST,
 isc_boolean_true, isc_boolean_false, isc_boolean_false, ((void
 *)0), 0) == 0) failed

 Any help would be appreciated


 -M





 -- 
 Martin Basti



 -- 
 Martin Basti


-- 
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] IPA Backup in AWS - best practices?

2014-10-31 Thread Michael Lasevich
What is the current best practice for backing up IPA servers? Especially
in AWS?

Given AWS strengths and weaknesses, I would love to be able to move all
of IPA data/state onto a separate drive and just snapshot it on regular
basis - but it seems that IPA data is all over the place, so it is hard
to separate it from the rest of the OS. Snapshotting entire root drive
is another option, but restoring from that is a bit of a pain, so it may
not be optimal. There is always also the plain old tar it all up
approach.

What do people use? What works, what does not?

Thanks,

-M


-- 
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 Backup in AWS - best practices?

2014-10-31 Thread Dmitri Pal

On 10/31/2014 05:42 PM, Michael Lasevich wrote:

What is the current best practice for backing up IPA servers? Especially
in AWS?

Given AWS strengths and weaknesses, I would love to be able to move all
of IPA data/state onto a separate drive and just snapshot it on regular
basis - but it seems that IPA data is all over the place, so it is hard
to separate it from the rest of the OS. Snapshotting entire root drive
is another option, but restoring from that is a bit of a pain, so it may
not be optimal. There is always also the plain old tar it all up

http://www.freeipa.org/page/Backup_and_Restore
This is pretty much what we recommended for some time until we built:
http://www.freeipa.org/page/V3/Backup_and_Restore

approach.

What do people use? What works, what does not?

Thanks,

-M





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