Re: [Freeipa-users] sudo made a bit easier to configure
On Thu, Dec 20, 2012 at 04:43:08PM +0100, Han Boetes wrote: I discovered that using this recipe makes setting up sudo-ldap very simple. Even when anonymous binds is disabled. TLS_CACERT /etc/ipa/ca.crt TLS_REQCERT demand SASL_MECH GSSAPI BASE dc=domain,dc=com URI ldap://auth-ipa.domain.com ROOTUSE_SASL on SUDOERS_BASE ou=SUDOers,dc=domain,dc=com SUDOERS_DEBUG 2 I really liked that this configuration didn't need a binddn/bindpw in sudo-ldap.conf, but it only works for me if I do password login and is issued a kerberos ticket on the host, and not if I do ssh pubkey/GSS-API login to the host. Do you have a pam config that issues kerberos ticket on sudo auth so that it always works? An even better config would be if we could use the host's keytab to bind to LDAP here.. -jf ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Slow ipa performance -- why so many ldap lookups ?
On Mon, Apr 08, 2013 at 12:26:43PM +0200, Jakub Hrozek wrote: I tried a similar case locally and everything worked for me. In the domain log I saw: [sssd[be[idm.lab.bos.redhat.com]]] [be_pam_handler_callback] (0x0400): SELinux provider doesn't exist, not sending the request to it when I set selinux_provider=none. What exact SSSD version is this? sssd-1.8.0-32.el6.x86_64 Can you paste the domain section of the sssd.conf? [domain/example.net] cache_credentials = True krb5_store_password_if_offline = True krb5_realm = EXAMPLE.NET ipa_domain = example.net id_provider = ipa auth_provider = ipa access_provider = ipa chpass_provider = ipa #ipa_server = ipa1.example.net ipa_server = _srv_, ipa1.example.net #ipa_server = ipa2.example.net, ipa1.example.net ldap_tls_cacert = /etc/ipa/ca.crt enumerate = false selinux_provider = none debug_level = 6 I know fixed the schema problem we had in 60ipaconfig.ldif. We were missing ipaSELinuxUserMapDefault and ipaSELinuxUserMapOrder in the ipaGuiConfig object class. But after fixing this I still see No SELinux user maps found! messages..: (Mon Apr 8 12:23:08 2013) [sssd[be[example.net]]] [dp_copy_options] (0x0400): Option ipa_selinux_search_base has value cn=selinux,dc=example,dc=net (Mon Apr 8 12:23:08 2013) [sssd[be[example.net]]] [dp_copy_options] (0x0400): Option ipa_selinux_search_base has value cn=selinux,dc=example,dc=net (Mon Apr 8 12:23:27 2013) [sssd[be[example.net]]] [ipa_get_selinux_send] (0x0400): Retrieving SELinux user mapping (Mon Apr 8 12:23:27 2013) [sssd[be[example.net]]] [ipa_selinux_get_maps_next] (0x0400): Trying to fetch SELinux maps with following parameters: [2][(null)][cn=selinux,dc=example,dc=net] (Mon Apr 8 12:23:27 2013) [sssd[be[example.net]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [((objectclass=ipaselinuxusermap)(ipaEnabledFlag=TRUE))][cn=selinux,dc=example,dc=net]. (Mon Apr 8 12:23:27 2013) [sssd[be[example.net]]] [ipa_selinux_get_maps_done] (0x0400): No SELinux user maps found! Should this be the full cn=selinux,dc=example,dc=net ? --- dn: cn=selinux,dc=example,dc=net objectClass: top objectClass: nsContainer cn: selinux dn: cn=usermap,cn=selinux,dc=example,dc=net objectClass: top objectClass: nsContainer cn: usermap --- -jf ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Slow ipa performance -- why so many ldap lookups ?
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 log in: Apr 5 13:46:22 ipa2 sshd[15417]: pam_access(sshd:account): access denied for user `janfrode' from `login2.example.com' Apr 5 13:46:29 ipa2 sshd[15423]: pam_unix(sshd:session): session opened for user janfrode by (uid=0) Apr 5 13:46:33 ipa2 su: pam_unix(su-l:session): session opened for user root by janfrode(uid=15019) debug=6 logs attached. Any other suggestions? -jf sssd-logs.tar.bz2 Description: BZip2 compressed data ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Slow ipa performance -- why so many ldap lookups ?
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 more entries than memberUid. I've assumed that the memberUid was a legacy thing, and just not maintained anymore.. Is this what you're referring to ? Or is it the storing of groups in the sssd-database that isn't successful ? Is this the intereseting entries? : (Fri Apr 5 13:46:09 2013) [sssd[be[example]]] [sdap_save_group] (0x0400): Storing info for group sos (Fri Apr 5 13:46:09 2013) [sssd[be[example]]] [sysdb_search_group_by_name] (0x0400): No such entry (Fri Apr 5 13:46:09 2013) [sssd[be[example]]] [sysdb_search_group_by_gid] (0x0400): No such entry -jf ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Slow ipa performance -- why so many ldap lookups ?
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 anymore.. Is this what you're referring to ? Are you referring to the entries in LDAP or the cache on disk? LDAP. -jf ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ldap-filter, LDAP_MATCHING_RULE_IN_CHAIN, apache 2.2
This works: Require ldap-attribute memberof=cn=cactiaccess,cn=groups,cn=accounts,dc=example,dc=net but only if I also provide a username/password for apache to bind as. Doesn't work with unauthenticated binds. -jf ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ldap-filter, LDAP_MATCHING_RULE_IN_CHAIN, apache 2.2
On Fri, Mar 22, 2013 at 09:59:14AM -0400, Dmitri Pal wrote: Because anonymous binds are rightly turned off by default, They are? I don't think I've ever explicitly turned on anonymous binds, and my directories are open to anonymous searches. The confusing thing is that not all attributes are available when doing anonymous binds. Are there any way to configure how open we want the directory to be? The best would have been for apache to support GSSAPI for that matter but based on the link you sent this is not the case. IMO you should file and RFE for them to support GSSAPI bind and not only bind with the password. Newer apache supports nested groups, and all the needed attributes for that seems to be available trough anonymous binds.. so no GSSAPI is needed (for us) there. IMHO it's seems inconsistent that memberOf attribute is hidden for anonymous searches on the user, but member attribute on groups is not. Same information, different places in the tree. -jf ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Slow ipa performance -- why so many ldap lookups ?
On Fri, Mar 22, 2013 at 04:19:39PM +0100, Jakub Hrozek wrote: Then maybe SSSD is tripping over the absence of the SELinux map order. At least that's the way I read the SSSD code, it relies on the presence of the ipaSELinuxUserMapOrder attribute. What does: $ ipa config-show --all --raw | grep -i selinux say? Nada: [janfrode@ipa1 ~]$ ipa config-show --all --raw | grep -i selinux [janfrode@ipa1 ~]$ Does the problem go away if you set: selinux_provider = none In the config file in the domain section? I have added this to one of my clients. Will report back if the problem is gone or happens again. -jf ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] ldap-filter, LDAP_MATCHING_RULE_IN_CHAIN, apache 2.2
Serverdefault has a hack for supporting nested groups on RHEL5/apache-2.2 involving a ldap filter using LDAP_MATCHING_RULE_IN_CHAIN on Active Directory, ref: http://serverfault.com/a/424706 Does anybody know if a similar filter can be created for an with IPA/389ds backend ? -jf ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Slow ipa performance -- why so many ldap lookups ?
On Thu, Mar 21, 2013 at 03:29:38PM +0100, Jakub Hrozek wrote: I see several failures related to the SELinux processing: --- (Thu Mar 21 08:23:57 2013) [sssd[be[example.net]]] [ipa_selinux_get_maps_done] (0x0400): No SELinux user maps found! (Thu Mar 21 08:23:57 2013) [sssd[be[example.net]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, Success) [Success] (Thu Mar 21 08:23:57 2013) [sssd[be[example.net]]] [be_pam_handler_callback] (0x0100): Sending result [4][example.net] (Thu Mar 21 08:23:57 2013) [sssd[be[example.net]]] [be_pam_handler_callback] (0x0100): Sent result [4][example.net] --- 4 is an internal error code, it would manifest in your /var/log/secure as System Error. No system errors are logged to /var/log/secure: Mar 21 11:30:01 ipa1 CROND[1161]: pam_unix(crond:session): session closed for user root Mar 21 11:33:27 ipa1 sshd[1204]: pam_access(sshd:account): access denied for user `janfrode' from `login2.example.net' Mar 21 11:33:33 ipa1 sshd[1216]: pam_unix(sshd:session): session opened for user janfrode by (uid=0) Mar 21 11:33:39 ipa1 su: pam_unix(su-l:session): session opened for user root by janfrode(uid=15019) What state is SELinux on the client machine? Are there any AVC denials? Selinux is in enforcing mode. No denials logged. When upgrading to v2.2, and also when initializing a v2.2 replica we got the following error: Applying LDAP updates ipa : ERRORUpdate failed: Object class violation: attribute ipaSELinuxUserMapOrder not allowed so I suspect there are some problem with our LDAP schema. That might be related to the No SELinux user maps found message.. I have a support ticket open on this ipaSELinuxUserMapOrder-schema problem (00800931), but not much progress there yet.. -jf ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Slow ipa performance -- why so many ldap lookups ?
On Thu, Mar 21, 2013 at 05:25:57PM -0400, Rob Crittenden wrote: ipa : ERRORUpdate failed: Object class violation: attribute ipaSELinuxUserMapOrder not allowed so I suspect there are some problem with our LDAP schema. That might be related to the No SELinux user maps found message.. I have a support ticket open on this ipaSELinuxUserMapOrder-schema problem (00800931), but not much progress there yet.. Upgrading to 2.2 from what version? v2.1.3 on RHEL-6.2. I still have the old disk-image from before the upgrade, so I verified this using guestfish.. If there are no maps it may just mean that there are no maps, which is fine. SELinux user maps didn't work well in 6.3 anyway. You might try: ipa-ldap-updater --ldapi /usr/share/ipa/updates/10-selinuxusermap.update Thanks, I'll mention you suggested this in the ticket -- but prefer to work on this issue trough the normal support channel. -jf ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Slow ipa performance -- why so many ldap lookups ?
On Wed, Mar 20, 2013 at 10:44:10AM +0100, Jakub Hrozek wrote: This really sounds like a bug. If you encounter a situation like this, where a group does not show all its members, feel free to open a bug. I have been experiencing this for quite some time, but I'm struggeling with how to give useful bugreports. Right now I tested a ssh-login to one of my ipa servers and failed to log in: Mar 20 12:55:13 ipa1 sshd[16112]: pam_access(sshd:account): access denied for user `janfrode' from `login2.example.net' then I immediatelty try again, and can successfully log in. The reason for pam_access denying access is most likely that my groups isn't populated on the first try, but on the second it works. I don't seem able to re-produce this issue by stopping/clearing/starting sssd, so I suspect it might be the connection between sssd and 389ds that has been broken by firewalls between them maybe. We have an evil firewall that breaks connections that's been idle for more than 30 minutes. Are there hearbeat or keepalive settings in IPA or 389ds that we should enable to keep connections alive ? Bottom line, if you are seeing inconsistent results with ipa backend, please open a bug. This is something that would need fixing right away. Don't know if I can call it inconsistent results with ipa backend, or just bad broken connection handling within sssd. Any hints for how I can provide better bugreports would be appreciated.. -jf ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Slow ipa performance -- why so many ldap lookups ?
We're struggeling with the performance of IPA, and have tried switching to the ldap backend for sssd to be able to see what's happening. The attached trace is from a RHEL6.4 client running id janfrode with the following sssd backend: --- [domain/IPALDAP] id_provider = ldap auth_provider = ldap ldap_schema = rfc2307bis ldap_uri = ldap://ipa2.example.net, ldap://ipa1.example.net ldap_search_base = dc=example,dc=net ldap_user_search_base = cn=users,cn=accounts,dc=example,dc=net ldap_group_search_base = cn=groups,cn=accounts,dc=example,dc=net ldap_netgroup_search_base = cn=ng,cn=compat,dc=example,dc=net ldap_tls_cacert = /etc/ipa/ca.crt ldap_tls_reqcert = never cache_credentials = True enumerate = false debug_level = 1 krb5_server = ipa1.example.net --- Please ignore the timings in the trace, as the ldap-server had too high debug level when it was collected. What we find very strange in the trace is: - how many ldap searches are done (144!) - that nesting is handled by the client, instead of using memberOf. - that all group members are searched individually, and multiple times if they're members of multiple groups Ldap-searches are probably (without this high debug level) taking 0.02-0.03s, so 144 of these is causing us 3-4s to resolve all my groups. I can get the time id janfrode takes down to less than 1s if I use ldap_schema=rfc2307, turn of nesting and use the cn=compat tree for group lookups... but ideally I'd want to use the ipa-backend so that we can use the IPA HBAC stuff.. -jf trace.bz2 Description: BZip2 compressed data ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Solaris 10 problem using netgroups
On Fri, Mar 01, 2013 at 01:19:36PM -0500, Eli J. Elliott wrote: I have a problem with Solaris 10 and netgroups with IPA. Does your host's domainname match the domainname entry in the netgroup triplet? -jf ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Cannot obtain CA Certificate
On Wed, Feb 27, 2013 at 11:52:42AM +0100, Petr Spacek wrote: On 27.2.2013 11:34, Jan-Frode Myklebust wrote: I have a similar problem getting a couple of RHEL 6.4 clients working with a 6.3 server (ipa-server-2.2.0-17.el6_3.1.x86_64). When doing the ipa-client-install I get: * gss_init_sec_context() failed: : Request is a replay WWW-Authenticate: Negotiate This is very suspicious. Could you double check time on all servers and the client? The cause of this problem was that the router ACL was dropping the kerberos return traffic from the ipa server. We had opening from client to ipa-server port 88/udp, but not from ipa-server 88/udp to client high port. -jf ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] meaning of several domains in sssd.conf
On Wed, Feb 27, 2013 at 09:31:43AM +0100, Jakub Hrozek wrote: Are there any issues you are seeing with IPA's sssd_be? It would definitely be better to fix those first rather than attempting a workaround like this. I've earlier been hit by a bug in nested groups (or netgroups) where the ipa backend would segfault, leaving sssd running but unable to authenticate. I believe it was this problem: https://fedorahosted.org/sssd/changeset/db90c1b60c729995f34af2431ede61ea7493e540/ And therefore wonder if it makes sense, or even is advisable to have backup backends to make sure to never lose the user database. -jf ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Cannot obtain CA Certificate
On Wed, Feb 27, 2013 at 10:42:49AM +0100, Petr Spacek wrote: HTTP/1.1 401 Authorization Required Date: Tue, 26 Feb 2013 16:54:21 GMT Server: Apache/2.2.15 (CentOS) * gss_init_sec_context() failed: : Server krbtgt/c...@example.com not found in Kerberos database WWW-Authenticate: Negotiate I have a similar problem getting a couple of RHEL 6.4 clients working with a 6.3 server (ipa-server-2.2.0-17.el6_3.1.x86_64). When doing the ipa-client-install I get: * gss_init_sec_context() failed: : Request is a replay WWW-Authenticate: Negotiate I have a ticket opened with RH-support for this (00796525), so I hope to get it fixed that way soonish.. but -- one strange thing about my problem is that I can't even get sssd working if I do a manual enrollment. I've tried doing ipa host-add, ipa host-add-managedby, ipa-getkeytab on the ipa-server, transferred the keytab, but still sssd fails to work. To get sssd working on this machine I had to configure an LDAP backend against the ipa-servers, without ldap_sasl_mech=GSSAPI. Is there a simple way to verify that the hosts keytab is OK? klist -k -t -K FILE:/etc/krb5.keytab works fine, but I'd like to test it against the ipa-server. -jf ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] meaning of several domains in sssd.conf
What does it mean to have several domains listed in sssd.conf ? Will they all be queried on each login, or will only the first domain be queried if the user/groups is found there? Does having an IPA domain, and an LDAP domain pointing at the same servers give any protection against failures in the sssd_BE process allowing sssd to fail over to the next sssd_BE ? -jf ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Netgroup domain entry
We have all our servers in two domains, example.com and lab.example.com. But unfortunately it seems IPA (ipa-server-2.2.0-17.el6_3.1.x86_64) populates the automatic host netgroups in the example.com domain both for hostname1.example.com and hostname2.lab.example.com. I.e.: (machinename.lab.example.com, -, example.com) Where is it picking up the domain from? This breaks all netgroup lookups for our lab-servers.. -jf ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Netgroup domain entry
On Mon, Feb 18, 2013 at 01:33:08PM -0500, Rob Crittenden wrote: nisDomainName is defined in the dc=example,dc=com entry. Currently only one nis domain is supported. It is probably possible to support multiple but it would require hacking on the nis schema compat configuration. Will it be OK to use - for nisdomain ? Or is this used any other places than in the netgroups where - might be problematic? -jf ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] missing member in group
I have the following sssd backend: domains = IPALDAP [domain/IPALDAP] id_provider = ldap auth_provider = ldap ldap_schema = IPA ldap_uri = ldap://ipa1.example.net, ldap://ipa2.example.net ldap_search_base = dc=example,dc=net ldap_user_search_base = cn=users,cn=accounts,dc=example,dc=net ldap_netgroup_search_base = cn=ng,cn=compat,dc=example,dc=net ldap_tls_cacert = /etc/ipa/ca.crt ldap_tls_reqcert = demand cache_credentials = false enumerate = true debug_level = 5 Why isn't emilb a member of the systemagic group??? # getent group|grep systema systemagic:*:10031:johanl,martinh # ldapsearch -x -h ipa1.example.net -b cn=accounts,dc=example,dc=net # cn=systemagic # extended LDIF # # LDAPv3 # base cn=accounts,dc=example,dc=net with scope subtree # filter: cn=systemagic # requesting: ALL # # systemagic, groups, accounts, example.net dn: cn=systemagic,cn=groups,cn=accounts,dc=example,dc=net objectClass: ipaobject objectClass: top objectClass: groupofuniquenames objectClass: ipausergroup objectClass: posixgroup objectClass: groupofnames objectClass: nestedgroup memberUid: susannek memberUid: martinh memberUid: johanl gidNumber: 10031 cn: systemagic ipaUniqueID: 329e0b6e-9ec5-11e1-8777-525400b94ff0 member: uid=johanl,cn=users,cn=accounts,dc=example,dc=net member: uid=martinh,cn=users,cn=accounts,dc=example,dc=net member: uid=emilb,cn=users,cn=accounts,dc=example,dc=net # search result search: 2 result: 0 Success -jf ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] missing member in group
On Sun, Feb 17, 2013 at 03:23:22PM -0500, Dmitri Pal wrote: 1) What versions you have? Running RHEL 6.3 server (ipa-server-2.2.0-17.el6_3.1.x86_64) and various RHEL4, 5, 6 clients. 2) Do you need enumeration to be turned on? We recommend it off unless very specific use cases. Maybe not. Am just used to having it on with the previous LDAP backend. Turned it off now, and that hides the problem, as now getent group $groupname lists no member :-) 3) Can you turn on debug level on SSSD to 9 and search debug logs /var/log/sssd and see what happens to this group? I suspect it is either bug that might have been fixed or the group is filtered for some reason. Whoha.. loglevel=9 gave quite a bit of output. This one looks interesting: (Sun Feb 17 21:40:07 2013) [sssd[be[IPALDAP]]] [sdap_fill_memberships] (7): member #2 (uid=emilb,cn=users,cn=accounts,dc=example,dc=net): not found! But why it can't find him I don't understand: [root@ldapm1 sssd]# ldapsearch -x -h ipa1.example.net -b uid=emilb,cn=users,cn=accounts,dc=example,dc=net # extended LDIF # # LDAPv3 # base uid=emilb,cn=users,cn=accounts,dc=example,dc=net with scope subtree # filter: (objectclass=*) # requesting: ALL # # emilb, users, accounts, example.net dn: uid=emilb,cn=users,cn=accounts,dc=example,dc=net krbLoginFailedCount: 1 krbLastFailedAuth: 20130217201648Z cn: emilb objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: organizationalperson objectClass: top objectClass: inetorgperson objectClass: person objectClass: inetuser objectClass: krbprincipalaux objectClass: posixgroup objectClass: posixaccount loginShell: /bin/bash uidNumber: 15567 gidNumber: 15567 gecos:: RW1pbCBCb3N0csO2bQ== sn:: Qm9zdHLDtm0= homeDirectory: /home/emilb mail: emil.bost...@example.no krbPrincipalName: em...@example.net givenName: Emil uid: emilb ipaUniqueID: b340ce78-784a-11e2-9ee1-525400b94ff0 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 This user was migrated saturday, using: ipa migrate-ds --user-ignore-objectclass=ldapPublic Key --user-ignore-attribute=sshPublicKey --user-container=ou=People --group-cont ou=Groups ldap://sim1.example.net:389 --with-compat I don't know what --with-compat does, but it migrate-ds seemed to require it this time. Earlier migrations hasn't needed it.. -jf ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] missing member in group
On Sun, Feb 17, 2013 at 09:48:10PM +0100, Jan-Frode Myklebust wrote: (Sun Feb 17 21:40:07 2013) [sssd[be[IPALDAP]]] [sdap_fill_memberships] (7): member #2 (uid=emilb,cn=users,cn=accounts,dc=example,dc=net): not found! snip This user was migrated saturday, using: ipa migrate-ds --user-ignore-objectclass=ldapPublic Key --user-ignore-attribute=sshPublicKey --user-container=ou=People --group-cont ou=Groups ldap://sim1.example.net:389 --with-compat I don't know what --with-compat does, but it migrate-ds seemed to require it this time. Earlier migrations hasn't needed it.. I see now that all the users I migrated saturday are logged as not found!. Maybe they need to log in and get fully migrated before they show up in the groups? (We're running IPA in migration mode). -jf ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] re-sync passwords after migration from LDAP to IPA ?
Too long ago I ran ipa migrate-ds to migrate my users into IPA, but unfortunately haven't been able to roll out IPA as our main identity platform yet. Now many users has probably changed passwords in the old directory, and switching to an IPA with their old password will be confusing. Is there any way to tell ipa migrate-ds to re-sync/re-migrate LDAP passwords ? -jf ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] re-sync passwords after migration from LDAP to IPA ?
On Wed, Jan 2, 2013 at 4:11 PM, Dmitri Pal d...@redhat.com wrote: Would it be simpler and cleaner to start with a fresh install? Unfortunately some systems are already using IPA so I can't easily start fresh.. but yes, I can probably just delete the accounts with different LDAP password in IPA and OLD-system, and then do a new migration of these few. But... where do I find the LDAP passwords in IPA ? I see there's no userPassword attribute on each user as I was expecting.., so where is this hidden? And can it be compared against the SSHA from the old directory ? -jf ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] re-sync passwords after migration from LDAP to IPA ?
Ok, thanks all! I'll compare the userPassword attributes between old directory and IPA, and either delete the account from IPA and re-run ds-migrate, or contact the individual users to let them know how to handle this. -jf ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa ports
On Thu, May 24, 2012 at 10:50:23AM +0200, Martin Kosek wrote: I suppose you don't need to open 7389/tcp for all clients unless you want them to be able to run LDAP search against dogtag backend LDAP database. I don't see why I would want that, so I'll just open it between the ipa-servers for now. The ipa-replica-conncheck utility looks great, thanks! -jf ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] ipa ports
We have quite strict firewalls, so I need to specify the IPA network ports accurately. So, we have now opening for: 80/tcp, 88/tcp, 389/tcp, 443/tcp, 464/tcp, 636/tcp 88/udp, 464/udp in to our first IPA server. Now I'm in the process of configuring the first replica. Is there any other ports that needs to be opened between ipa master and replica? We don't serve NTP or DNS from IPA, so I guess these shouldn't be relevant, but I think we want dogtag replicated, so there's maybe some ports for that that needs opening ? Or, to put it another way, which of these ports: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/Preparing_for_an_IPA_Installation.html#prereq-ports needs to be opened between ipa server, which for all clients, which for replica and which for administrative clients ? HTTP/HTTPS -- open for all LDAP/LDAPS -- open for all Kerberos-- open for all OCSP responder -- open for all if we use certs dogtag 9443 (agents)-- ? dogtag 9444 (users, SSL)-- ? dogtag 9445 (administrators)-- ? dogtag 9446 (users, client authentication) -- ? dogtag 9701 (Tomcat)-- ? dogtag 7389 (internal LDAP database) -- ? -jf ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] IPA dogtag as CA for puppet ?
If joining a machine to IPA automatically gives it a SSL keyset, it seems silly to also join the puppetca for config management. Has anybody looked into using IPA-dogtag as CA for puppet and func? -jf ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] FreeIPA and others
On Mon, May 14, 2012 at 03:53:34AM +, JR Aquino wrote: I currently run over 21 (soon to be 42) Production FreeIPA servers. These are globally dispersed in every major continent. They support over 5,000 servers (Mostly RHEL with some Fedora, and Ubuntu mixed in), 1,000 Networking devices (Cisco and Juniper) and around 2,000 users. Could you please say something about how you're connecting the Cisco's and Juniper's to IPA ? LDAP backend for radius/ACS, or something else ? -jf ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Different automount for different locations
We have two datacenters, site-A and site-B, and would like to server the users' home directories from a local NFS-server at each location to avoid cross site mounts. Is this something the automount maps in IPA can help us with ? Or do we need to do tricks like having the users' home directory under /Home/$username and symlink /Home - /srv/site-A/ on site-A and vice versa ? -jf ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Different automount for different locations
On Mon, May 14, 2012 at 10:10:47AM +0200, Jakub Hrozek wrote: IPA has a concept of automount locations. See ipa help automount for more info..here is a basic example, cut-n-pasted from a test setup of mine, except for obfuscated host names. This setup creates two locations exporting the same tree /share/mirror from different servers: Perfect, thanks for the location explanation! -jf ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] DogTag PKI uses ?
We're finally implementing IPA in our company (migrating from Sun Identity Manager populated LDAP + manually maintained netgroups and sudoers also in LDAP). I think I understand how to migrate these parts to IPA, but the dogtag part is quite foreign currently.. We already has two private PKI infrastructures implemented. One for managing user certificates for about 250 openvpn users, and another for managing certificates for a few internal web services. Should we look into re-using one of these CA's in IPA? I think it would be marvelous if IPA/dogtag could create certs/keys for the users, and keep a copy of the users csr's so that it could automatically send the user an updated certificate with an expiry matching the password lifetime. Is this something that's possible currently, or on the roadmap maybe? -jf ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] password migration
On Tue, Sep 20, 2011 at 09:59:16AM -0400, Dmitri Pal wrote: Password Hash Algorithm - Indicates the algorithm that the system should use to hash the password. Currently supported values are SSHA, SHA, SMD5, and MD5. A value of NONE or no value indicates that the system will not hash passwords. This will cause cleartext passwords to be stored in LDAP unless the LDAP server performs the hash (Netscape Directory Server and iPlanet Directory Server do). Will the ipa-migration handle any of these formats ? Which would be the preferred ? I am not sure it keeps it in clear internally anywhere. Password is always hashed unless you explicitly set it to be cleartext in the setting above. Are you stating that based on knowledge of Sun Identity Manager? As far as I understand SIM, I should be able to add new managed resources (directories, databases, servers, etc) at a later point and push my userdatabase to. For that to work, SIM will have to either hash to all supported hashing methods (including cleartext??) or just keep a cleartext version hidden somewhere. -jf ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] password migration
On Tue, Sep 20, 2011 at 10:18:13AM -0400, Stephen Gallagher wrote: Specifically, the way SSSD behaves is as follows: 1) Try to authenticate with Kerberos. If Kerberos responds that there's no hash for this user, 2) Ask FreeIPA if migration mode is enabled, if it is, 3) Try to bind to FreeIPA LDAP using the same password. If this succeeds, we know that the password is valid 4) Initiate a kerberos password-change to set the kerberos password equal to the LDAP password. Is it supported to run a mixed ldap bind / kerberos environment? I'm thinking of letting all old RHEL4 and RHEL5 systems keep running ldap bind authentication, and only enable kerberos/sssd on RHEL6 initially. After 3 months, or so, all users should have been forced to change their passwords trough the password expiry policy. Will then the RHEL4/5 klients also update kerberos password when they're forced to change their LDAP password ? -jf ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] password migration
We have an existing user database managed by Sun Identity Manager, which populates a centos-directory-server. The users in the directory server have all passwords hassed with SSHA, and ipa migrate-ds told me that the passwords has been migrated in pre-hashed format. Luckily Sun Identity Manager has the plain text passwords hidden away somewhere, and should let me change hash algorithm. For the selection of password hash algorithm, it says: Password Hash Algorithm - Indicates the algorithm that the system should use to hash the password. Currently supported values are SSHA, SHA, SMD5, and MD5. A value of NONE or no value indicates that the system will not hash passwords. This will cause cleartext passwords to be stored in LDAP unless the LDAP server performs the hash (Netscape Directory Server and iPlanet Directory Server do). Will the ipa-migration handle any of these formats ? Which would be the preferred ? -jf ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] migrate from LDAP to FreeIPA ?
On Fri, Mar 25, 2011 at 05:14:02PM -0400, Rob Crittenden wrote: Shouldn't be too bad. Here is our beta documentation on migration: http://obriend.fedorapeople.org/freeIPA2.0/Identity_and_Policy_Management_Guide/html-single/#chap-Enterprise_Identity_Management_Guide-Migrating_from_a_Directory_Server_to_IPA Ok, good, that looks like it should cover the bulk of our migration. The other problems I'm looking at are probably more of design issues. Are there a deployment guide somewhere as well ? Currently we use netgroups for servers and users, mainly to manage who can log in to which server trough pam_access/access.conf plus for sudo rules. Should we continue using netgroups, or will the user groups and host groups in IPA cover this ? Does the user groups allow nesting of posix groups ? I.e. user1 is member of group1 which automatically make him member of group2 and group3? Some guides for configuring roles/privileges would be very interesting. We want to have group admins who are allowed to add/remove members of the groups this admin admins... Also we might want to allow team leaders to add new users.. Oh.. and are there any training available/planned for IPA (v2)? -jf ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] migrate from LDAP to FreeIPA ?
We run a quite pure RHEL server environment, with users, groups, authentication (ldap bind), sudorules and netgroups all in two master-master replicating 389ds´. The users and groups are managed by Sun Identity Manager (SIM), which pushes them to the directory servers -- but we´re not really using it and might as well have managed these directly in an LDAP editor. So, it´s time to drop SIM, and I´m a bit torn between implementing some simple shell scripts to manage the users/groups in LDAP and take advantage of the new password policy features of 386ds etc.. , or if we should deploy IPAv2 and get kerberos, nice UIs, machine/service identity and lots more. So, to my question -- are there any migration guides that can help us move from LDAP to IPA ? Is it a complicated procedure ? -jf ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
