Hey Rob,
The passwd section of nsswitch.conf is the following;
Passwd: files nis
Matt
-Original Message-
From: Rob Crittenden [mailto:rcrit...@redhat.com]
Sent: Thursday, April 04, 2013 3:05 PM
To: Joseph, Matthew (EXP); freeipa-users@redhat.com
Subject: EXTERNAL: Re: [Freeipa-users]
My old NIS server we used shadow passwords.
When I migrated my passwd nis file to IPA I'm assuming it also imported the
part of the file that contains the x to point it towards a shadow file.
Would I need to remove the x from the nis passwd file and re-migrate it to
IPA?
Is there a better way
It looks like I missed a step in setting up my IPA server for NIS compatability.
[root@server ~]# ldapmodify -D cn=directory server -w secret -p 389 -h
ipaserver.example.com
dn: cn=config
changetype: modify
replace: passwordStorageScheme
passwordStorageScheme: crypt
When I try to run that
On Fri, Mar 22, 2013 at 06:43:07PM +0100, Jan-Frode Myklebust wrote:
Does the problem go away if you set:
selinux_provider = none
Sorry, no. Also the No SELinux user maps found! didn't go away.
At Apr 5 13:46:22 I was denied access again by pam_access, and then
seconds later I could
On 04/05/2013 08:00 AM, Jan-Frode Myklebust wrote:
On Fri, Mar 22, 2013 at 06:43:07PM +0100, Jan-Frode Myklebust wrote:
Does the problem go away if you set:
selinux_provider = none
Sorry, no. Also the No SELinux user maps found! didn't go away.
At Apr 5 13:46:22 I was denied access again by
On Fri, Apr 05, 2013 at 02:00:58PM +0200, Jan-Frode Myklebust wrote:
On Fri, Mar 22, 2013 at 06:43:07PM +0100, Jan-Frode Myklebust wrote:
Does the problem go away if you set:
selinux_provider = none
Sorry, no. Also the No SELinux user maps found! didn't go away.
At Apr 5
On Fri, Apr 05, 2013 at 08:19:21AM -0400, Dmitri Pal wrote:
SELinux seems to be OK but the log definitely showing that not all users
are successfully stored in a group.
Hmm.. I've noticed that in cn=$groupname,cn=groups,cn=accounts we have
both member and memberUid, but member often contains
On Fri, Apr 05, 2013 at 02:42:33PM +0200, Jan-Frode Myklebust wrote:
On Fri, Apr 05, 2013 at 08:19:21AM -0400, Dmitri Pal wrote:
SELinux seems to be OK but the log definitely showing that not all users
are successfully stored in a group.
Hmm.. I've noticed that in
On Fri, Apr 05, 2013 at 03:02:53PM +0200, Jakub Hrozek wrote:
Hmm.. I've noticed that in cn=$groupname,cn=groups,cn=accounts we have
both member and memberUid, but member often contains more entries
than memberUid. I've assumed that the memberUid was a legacy thing,
and just not maintained
Joseph, Matthew (EXP) wrote:
My old NIS server we used shadow passwords.
When I migrated my passwd nis file to IPA I'm assuming it also imported the part of the
file that contains the x to point it towards a shadow file.
Would I need to remove the x from the nis passwd file and re-migrate it
Hey Rob,
The NIS Clients that I am adding are Solaris 2.7, and Solaris 8. So I believe
looking at the IPA document they would need to be Solaris 9 or above for it to
communicate with IPA natively using LDAP.
These Servers aren't going to be around much longer (Probably another year at
the
Joseph, Matthew (EXP) wrote:
Hey Rob,
The NIS Clients that I am adding are Solaris 2.7, and Solaris 8. So I believe
looking at the IPA document they would need to be Solaris 9 or above for it to
communicate with IPA natively using LDAP.
These Servers aren't going to be around much longer
You were correct, my reverse DNS entries for the master and replica were
missing. Odd, since they both existed at one point.
Running the same commands again results in the following
On the Replica system
ipa-replica-manage list replica.example.com -v
master.example.com: replica
last init
On Fri, 2013-04-05 at 08:30 -0600, Brent Clark wrote:
You were correct, my reverse DNS entries for the master and replica
were missing. Odd, since they both existed at one point.
Rob,
I think we should open a ticket against 389ds, we should never depend on
PTR records.
In this case I believe
Hello,
I imagine this is a common issue/question when trying to implement the password
sync between AD and IPA.
We have two Windows 2003 domain controllers (for redundancy) so when a user
issues a password change on the Windows side there is no primary domain
controller that it will always
On 04/05/2013 10:52 AM, Joseph, Matthew (EXP) wrote:
Hello,
I imagine this is a common issue/question when trying to implement the
password sync between AD and IPA.
We have two Windows 2003 domain controllers (for redundancy) so when a
user issues a password change on the Windows
Thank you very much for that. Works like a charm.
How does this work though? You setup the winsync agreement between your IPA
Server and AD server using the hostname.
How does IPA know that it can trust a second DC?
Matt
From: freeipa-users-boun...@redhat.com
Joseph, Matthew (EXP) wrote:
Thank you very much for that. Works like a charm.
How does this work though? You setup the winsync agreement between your
IPA Server and AD server using the hostname.
How does IPA know that it can trust a second DC?
Via the passsync user that you config on the
On 04/05/2013 08:41 AM, Simo Sorce wrote:
On Fri, 2013-04-05 at 08:30 -0600, Brent Clark wrote:
You were correct, my reverse DNS entries for the master and replica
were missing. Odd, since they both existed at one point.
Rob,
I think we should open a ticket against 389ds, we should never
Hey Rob,
I was able to get NIS passwords working.
I had a space at the end of dn: cn=config (stupid me).
Thanks for the help!
Matt
-Original Message-
From: Rob Crittenden [mailto:rcrit...@redhat.com]
Sent: Friday, April 05, 2013 11:07 AM
To: Joseph, Matthew (EXP);
Thanks for all the help!
After fixing the DNS issues, I then solved the LDAP error by rebooting the
master and replica. Something I hadnt done since installing IPA on both of
them and setting them up.
On Fri, Apr 5, 2013 at 9:51 AM, Rich Megginson rmegg...@redhat.com wrote:
On 04/05/2013
Hey Rob,
I modified the command but now I am getting the following;
Ldapmodify: wrong attributeType at line 4, entry cn=config
Looking at the command I don't see any entry in my dse.ldif for
passwordStorageScheme.
I'm assuming it should be a changetype: add instead of modify.
But it's not
On 04/05/2013 11:49 AM, Simo Sorce wrote:
On Fri, 2013-04-05 at 09:51 -0600, Rich Megginson wrote:
On 04/05/2013 08:41 AM, Simo Sorce wrote:
On Fri, 2013-04-05 at 08:30 -0600, Brent Clark wrote:
You were correct, my reverse DNS entries for the master and replica
were missing. Odd, since they
On Fri, 2013-04-05 at 09:51 -0600, Rich Megginson wrote:
On 04/05/2013 08:41 AM, Simo Sorce wrote:
On Fri, 2013-04-05 at 08:30 -0600, Brent Clark wrote:
You were correct, my reverse DNS entries for the master and replica
were missing. Odd, since they both existed at one point.
Rob,
I
On 04/05/2013 01:50 PM, Rich Megginson wrote:
On 04/05/2013 11:49 AM, Simo Sorce wrote:
On Fri, 2013-04-05 at 09:51 -0600, Rich Megginson wrote:
On 04/05/2013 08:41 AM, Simo Sorce wrote:
On Fri, 2013-04-05 at 08:30 -0600, Brent Clark wrote:
You were correct, my reverse DNS entries for the
On 04/05/2013 12:40 PM, Dmitri Pal wrote:
On 04/05/2013 01:50 PM, Rich Megginson wrote:
On 04/05/2013 11:49 AM, Simo Sorce wrote:
On Fri, 2013-04-05 at 09:51 -0600, Rich Megginson wrote:
On 04/05/2013 08:41 AM, Simo Sorce wrote:
On Fri, 2013-04-05 at 08:30 -0600, Brent Clark wrote:
You were
On Fri, 05 Apr 2013, Dmitri Pal wrote:
On 04/05/2013 01:50 PM, Rich Megginson wrote:
On 04/05/2013 11:49 AM, Simo Sorce wrote:
On Fri, 2013-04-05 at 09:51 -0600, Rich Megginson wrote:
On 04/05/2013 08:41 AM, Simo Sorce wrote:
On Fri, 2013-04-05 at 08:30 -0600, Brent Clark wrote:
You were
On Fri, 05 Apr 2013, Rich Megginson wrote:
Rich do you set LDAP_OPT_X_SASL_NOCANON in 389ds code at all ?
Yes.
ldap/servers/slapd/ldaputil.c:ldap_set_option(ld,
LDAP_OPT_X_SASL_NOCANON, LDAP_OPT_ON);
Should this be off by default? Should this be configurable?
On by default (meaning no
On Fri, 2013-04-05 at 09:51 -0600, Rich Megginson wrote:
On 04/05/2013 08:41 AM, Simo Sorce wrote:
On Fri, 2013-04-05 at 08:30 -0600, Brent Clark wrote:
You were correct, my reverse DNS entries for the master and replica
were missing. Odd, since they both existed at one point.
Rob,
I
29 matches
Mail list logo
