Re: [Freeipa-users] Getting Samba3 and FreeIPAv3 working together
On Tue, May 20, 2014 at 02:00:18PM +0100, Dylan Evans wrote: Hello, I need some help with getting Samba and FreeIPA working together. I’ve been following the guide at http://techslaves.org/2011/08/24/freeipa-and-samba-3-integration but that seems quite out of date for IPAv3 and I need some help: yes, it is a bit outdated but still useful. Please note that we are currently working on making the integration of samba more easy. Recently I send a patch to the samba-technical mailing list with a library which would allow samba to use SSSD instead of winbind to look up users and SID-to-name mapping. Alexander is planning to go through the ipasam modules to see how to make integration with Samba file-servers more easy. But coming back to your questions. 1. The guide deals with setting a Samba server SID for one Samba server, but as we have multiple stand-alone Samba3 servers, which SID do I use to create the DNA plugin? Can I enter more than 1 SID? Can I have more than 1 plugin (seems unlikely)? 'net getlocalsid' returns the domain SID and since all you Samba file-servers are member of the IPA domain you can use a common SID here. With IPAv3 SID generation for users and groups is even more easy because you can get it for free by running ipa-adtrust-install (please use the option --add-sids) if you already have users and groups in your IPA server. This prepares the IPA server to be able to create trust relationships to Active Directory and one requirement here is that all users and groups have SID. 'ipa-adtrust-install' will also create a domain SID. 'ipa trustconfig-show' will show the domain SID together with the DNS domain name and the NetBIOS domain name. On your Samba server you should set 'workgroup' to the NetBIOS domain name (see 'net conf list' on the IPA server after running ipa-adtrust-install for a config example). Additionally on your Samba servers you have to set the domain SID in /var/lib/samba/private/secrets.tdb with tdbtool. You will need 3 keys with the same SID SECRETS/SID/DOMNETBIOS - NetBIOS domain name, workgroup in smb.conf SECRETS/SID/DNS.DOMAIN.NAME - DNS domain name, will match realm in smb.conf SECRETS/SID/CLINETBIOS - NetBIOS name of the client, 'netbios name' in smb.conf The SID has to be given in a special binary format. The easiest way to get it is to call 'tdbdump /var/lib/samba/private/secrets.tdb' on the IPA server after running ipa-adtrust-install. The domain SID will always start with \01\04\00\00\00\00\00\05\15\... . You can use this sequence as data for the insert command of tdbtool. Now everything should be done with respect to SID handling. 2. There’s no “/usr/share/ipa/ui/group.js” file to patch in IPAv3. What do I need to patch instead? I’ve seen ticket https://fedorahosted.org/freeipa/ticket/3999 , which shows the need is there but I could do with getting it working ASAP. group.js is compliend with the other UI files in /usr/share/ipa/ui/js/freeipa/app.js (see install/ui/doc/guides/debugging_web_ui/README.md in the FreeIPA sources for details). For your convenience I copied some section here: The compiled Web UI layer is located in `/usr/share/ipa/ui/js/freeipa/app.js` file. One can copy files from source git repository in `install/ui/src/freeipa/` directory to the `/usr/share/ipa/ui/js/freeipa/` directory (in will replace the `app.js` file). By doing that, next reload of Web UI will use source files (clearing browser cache may be required). After that all JavaScript errors will contain proper source code name and line number. I may be missing something obvious but some help would be greatly appreciated! I hope my comments will help you. Feel free to ask for more help if needed. It would be nice to hear from any success as well. bye, Sumit Thanks, Dylan. Background: Brief: Need to expand from the current single-office-ish NIS/YP scheme to a multi-location/multi-national auth scheme which FreeIPA seems ideally suited for. Requirement: To continue to provide console/SSH and GUI/X logins to Linux hosts, access to home and project directories via NFS from the Linux machines using autofs/automount and access to Samba file-shares from Windows machines but not using AD creds as this is a totally separate environment. Several locations will each have a FreeIPA replica server, NFS/Samba fileserver and “application” server. Currently use 2 passwords for each user – one for NIS, one for Samba – and need to consolidate to one password for everything. Progress: Linux-based NFS stuff working fine – automount of home and project directories all OK. Currently using Fedora 20 CentOS 6.5 VMs as a prototyping environment but will probably use RHEL/CentOS 7 when available for production. FreeIPA versions 3.0.0 on CentOS 6.5 and 3.3.5 on Fedora 20. ___ Freeipa-users mailing list
Re: [Freeipa-users] Getting Samba3 and FreeIPAv3 working together
On 22.5.2014 14:19, Sumit Bose wrote: On Tue, May 20, 2014 at 02:00:18PM +0100, Dylan Evans wrote: Hello, I need some help with getting Samba and FreeIPA working together. I’ve been following the guide at http://techslaves.org/2011/08/24/freeipa-and-samba-3-integration but that seems quite out of date for IPAv3 and I need some help: yes, it is a bit outdated but still useful. Please note that we are currently working on making the integration of samba more easy. Recently I send a patch to the samba-technical mailing list with a library which would allow samba to use SSSD instead of winbind to look up users and SID-to-name mapping. Alexander is planning to go through the ipasam modules to see how to make integration with Samba file-servers more easy. But coming back to your questions. 1. The guide deals with setting a Samba server SID for one Samba server, but as we have multiple stand-alone Samba3 servers, which SID do I use to create the DNA plugin? Can I enter more than 1 SID? Can I have more than 1 plugin (seems unlikely)? 'net getlocalsid' returns the domain SID and since all you Samba file-servers are member of the IPA domain you can use a common SID here. With IPAv3 SID generation for users and groups is even more easy because you can get it for free by running ipa-adtrust-install (please use the option --add-sids) if you already have users and groups in your IPA server. This prepares the IPA server to be able to create trust relationships to Active Directory and one requirement here is that all users and groups have SID. 'ipa-adtrust-install' will also create a domain SID. 'ipa trustconfig-show' will show the domain SID together with the DNS domain name and the NetBIOS domain name. On your Samba server you should set 'workgroup' to the NetBIOS domain name (see 'net conf list' on the IPA server after running ipa-adtrust-install for a config example). Additionally on your Samba servers you have to set the domain SID in /var/lib/samba/private/secrets.tdb with tdbtool. You will need 3 keys with the same SID SECRETS/SID/DOMNETBIOS - NetBIOS domain name, workgroup in smb.conf SECRETS/SID/DNS.DOMAIN.NAME - DNS domain name, will match realm in smb.conf SECRETS/SID/CLINETBIOS - NetBIOS name of the client, 'netbios name' in smb.conf The SID has to be given in a special binary format. The easiest way to get it is to call 'tdbdump /var/lib/samba/private/secrets.tdb' on the IPA server after running ipa-adtrust-install. The domain SID will always start with \01\04\00\00\00\00\00\05\15\... . You can use this sequence as data for the insert command of tdbtool. Now everything should be done with respect to SID handling. 2. There’s no “/usr/share/ipa/ui/group.js” file to patch in IPAv3. What do I need to patch instead? I’ve seen ticket https://fedorahosted.org/freeipa/ticket/3999 , which shows the need is there but I could do with getting it working ASAP. group.js is compliend with the other UI files in /usr/share/ipa/ui/js/freeipa/app.js (see install/ui/doc/guides/debugging_web_ui/README.md in the FreeIPA sources for details). For your convenience I copied some section here: The compiled Web UI layer is located in `/usr/share/ipa/ui/js/freeipa/app.js` file. One can copy files from source git repository in `install/ui/src/freeipa/` directory to the `/usr/share/ipa/ui/js/freeipa/` directory (in will replace the `app.js` file). By doing that, next reload of Web UI will use source files (clearing browser cache may be required). After that all JavaScript errors will contain proper source code name and line number. Better approach is to create a custom UI plugin which would add those fields. Since it's only 3 fields, I create an example which works on FreeIPA 4.0 and theoretically it should work on 3.2 as well: http://pvoborni.fedorapeople.org/plugins/samba/samba.js put the file into `/usr/share/ipa/ui/js/plugins/samba` directory. I did not test it with backend (no labels + doesn't do anything). More about plugin development: * http://www.freeipa.org/images/5/5b/FreeIPA33-extending-freeipa.pdf * http://pvoborni.fedorapeople.org/doc/#!/guide/Plugins Creating CLI plugin is IMO also better approach. I may be missing something obvious but some help would be greatly appreciated! I hope my comments will help you. Feel free to ask for more help if needed. It would be nice to hear from any success as well. bye, Sumit Thanks, Dylan. Background: Brief: Need to expand from the current single-office-ish NIS/YP scheme to a multi-location/multi-national auth scheme which FreeIPA seems ideally suited for. Requirement: To continue to provide console/SSH and GUI/X logins to Linux hosts, access to home and project directories via NFS from the Linux machines using autofs/automount and access to Samba file-shares from Windows machines but not using AD creds as this is a totally separate environment. Several
[Freeipa-users] openldap certs?
Where should my clients be getting the contents of /etc/openldap/certs from? I've got one network where my IPA authentications are blazing fast and one where they're ... not. On the slower one, clients' /etc/openldap/certs directories are either missing or empty; on the faster network, clients have certs in these directories. Is this important, and if so what could be going wrong on my slower network that might cause the certs to not get distributed or created properly? -- *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret smime.p7s Description: S/MIME Cryptographic Signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] openldap certs?
Bret Wortman wrote: Where should my clients be getting the contents of /etc/openldap/certs from? I've got one network where my IPA authentications are blazing fast and one where they're ... not. On the slower one, clients' /etc/openldap/certs directories are either missing or empty; on the faster network, clients have certs in these directories. Is this important, and if so what could be going wrong on my slower network that might cause the certs to not get distributed or created properly? These are not the droids you are looking for... Can you clarify what you mean by IPA authentications? sssd should be handling that, and while a first auth over a slow link might be slow subsequent usage should be quite fast. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] openldap certs?
What we're seeing is slow GDM logins, ssh authentications, and sudo -i responses on this network. On our other, these things are all blazing fast. Here, they're on the order of 5-10 seconds. And it doesn't seem to improve (much) with age or time, except perhaps anecdotally. At best, a second connection might be a second faster, but will revert within an hour or so. On 05/22/2014 09:36 AM, Rob Crittenden wrote: Bret Wortman wrote: Where should my clients be getting the contents of /etc/openldap/certs from? I've got one network where my IPA authentications are blazing fast and one where they're ... not. On the slower one, clients' /etc/openldap/certs directories are either missing or empty; on the faster network, clients have certs in these directories. Is this important, and if so what could be going wrong on my slower network that might cause the certs to not get distributed or created properly? These are not the droids you are looking for... Can you clarify what you mean by IPA authentications? sssd should be handling that, and while a first auth over a slow link might be slow subsequent usage should be quite fast. rob smime.p7s Description: S/MIME Cryptographic Signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] openldap certs?
On 05/22/2014 09:43 AM, Bret Wortman wrote: What we're seeing is slow GDM logins, ssh authentications, and sudo -i responses on this network. On our other, these things are all blazing fast. Here, they're on the order of 5-10 seconds. And it doesn't seem to improve (much) with age or time, except perhaps anecdotally. At best, a second connection might be a second faster, but will revert within an hour or so. Have you compared sssd.conf from clients in these two networks? Do you use enumeration? Increasing debug level and looking at the logs will help you to understand what part takes most time. These logs will be helpful for you/us to see if/what the problem is/are. On 05/22/2014 09:36 AM, Rob Crittenden wrote: Bret Wortman wrote: Where should my clients be getting the contents of /etc/openldap/certs from? I've got one network where my IPA authentications are blazing fast and one where they're ... not. On the slower one, clients' /etc/openldap/certs directories are either missing or empty; on the faster network, clients have certs in these directories. Is this important, and if so what could be going wrong on my slower network that might cause the certs to not get distributed or created properly? These are not the droids you are looking for... Can you clarify what you mean by IPA authentications? sssd should be handling that, and while a first auth over a slow link might be slow subsequent usage should be quite fast. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] openldap certs?
I found that our slower system was using FQDNs for the list of IPA servers; our faster system was using IPs. I'm switching now, letting Puppet distribute the update and will see if it helps. By enumeration, do you mean are we spelling out our IPA servers? Yes. We only have 3 and they look something like this: [domain/foo.net] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = foo.net id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = rm266ws-a.foo.net chpass_provider = ipa ipa_dyndns_update = True ipa_server = _srv_, 192.168.2.61, 192.168.2.62, 192.168.2.63 ldap_netgroup_search_base = cn=ng,cn=compat,dc=foo,dc=net ldap_tls_cacert = /etc/ipa/ca.crt [sssd] services = nss, pam, ssh config_file_version = 2 domains = foo.net [nss] [pam] [sudo] [autofs] [ssh] [pac] On the other hand, if you meant something else, then I hope the answer's in the file. ;-) On 05/22/2014 10:15 AM, Dmitri Pal wrote: On 05/22/2014 09:43 AM, Bret Wortman wrote: What we're seeing is slow GDM logins, ssh authentications, and sudo -i responses on this network. On our other, these things are all blazing fast. Here, they're on the order of 5-10 seconds. And it doesn't seem to improve (much) with age or time, except perhaps anecdotally. At best, a second connection might be a second faster, but will revert within an hour or so. Have you compared sssd.conf from clients in these two networks? Do you use enumeration? Increasing debug level and looking at the logs will help you to understand what part takes most time. These logs will be helpful for you/us to see if/what the problem is/are. On 05/22/2014 09:36 AM, Rob Crittenden wrote: Bret Wortman wrote: Where should my clients be getting the contents of /etc/openldap/certs from? I've got one network where my IPA authentications are blazing fast and one where they're ... not. On the slower one, clients' /etc/openldap/certs directories are either missing or empty; on the faster network, clients have certs in these directories. Is this important, and if so what could be going wrong on my slower network that might cause the certs to not get distributed or created properly? These are not the droids you are looking for... Can you clarify what you mean by IPA authentications? sssd should be handling that, and while a first auth over a slow link might be slow subsequent usage should be quite fast. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users smime.p7s Description: S/MIME Cryptographic Signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] New replica won't accept replication
Go figure. I rebuilt it (again) cleanly, and after starting replication again, while I was madly trying to change the debug level on the new replica...it completed replication this time. Heisenbugs. Gotta love them. (I think this one was in my network somewhere, not your code -- I just couldn't observe it enough and someone must've changed something while I wasn't looking). Bret On 05/21/2014 10:19 PM, Rob Crittenden wrote: Bret Wortman wrote: It takes about 2 minutes. How would you like me to turn debugging on? http://directory.fedoraproject.org/wiki/FAQ#Troubleshooting I'm not sure if you should enable this on both sides of the agreement or not. If you have the ability and don't mind potentially slowing down the working master it might be useful to the 389-ds guys. rob Bret Wortman http://bretwortman.com/ http://twitter.com/BretWortman On May 21, 2014, at 4:26 PM, Rob Crittenden rcrit...@redhat.com wrote: Bret Wortman wrote: On the new replica (asipa) I see in the access log almost 5000 entries like this: [21/May/2014:10:30:58 -0400] conn=4 op=4923 EXT oid=2.16.840.113730.3.5.6 name=Netscape Replication Total update Entry [21/May/2014:10:30:58 -0400] conn=4 op=4923 RESULT err=0 tag=120 nentries=0 etime=0 And these just repeat, increasing the op value until they terminate with this one. The rest of it just looks like informational messages. How long does this take? Is there time to enable replication debugging? That may provide more output. Over on zsipa (the CA master), errors contains: [21/May/2014:14:31:06 +] NSMMReplciationPlugin - Schema agmt=cn=meToasipa.foo.net (asipa:389) must not be overwritten(set replication log for additional info) [21/May/2014:14:31:06 +] NSMMReplicationPlugin - agmt=cn=meToasipa.foo.net (asipa:389) Warning: unable to replicate schema: rc=1 I don't think this is related. I'd run ipa-replica-manage list -v `hostname` and ipa-csreplica-manage list -v `hostname` on the master you generated the replica install file on to see what agreements it has or thinks it has. rob These two lines repeat at intervals for a while. Nothing else leapt out at me. On 05/21/2014 11:04 AM, Rob Crittenden wrote: Bret Wortman wrote: This occurs on our first attempt to join as a replica. I've erased this box and rebaselined it but the same thing happens. No network ports being blocked that we know of, and another replica I created at the same time installed its replica file without issue. asipa is the new replica, zsipa is the ca and original master on which the replica file was created. [24/34]: setting up initial replication Starting replication, please wait until this has completed Update in progress, 130 seconds elapsed Update in progress yet not in progress [ipamaster.foo.net] reports: Update failed! Status: [10 Total update abortedLDAP error: Referral] Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Failed to start replication # /var/log/ipareplica-install.log contains this: 2014-05-21T145:28:56Z DEBUG retrieving schema for SchemaCache url=ldaps://asipa.fopo.net:636 conn=ldap.ldapobject.SimpleLDAPObject instance at 0x4faf170 2014-05-21T14:31:08Z DEBUG File /usr/lib/python2.7/site-packages/ipaserver/install/installutils.py, line 638, in run_script return_value = main_function() File /usr/sbin/ipa-replica-install, line 663, in main ds = install_replica_ds(config) File /usr/sbin/ipa-replica-install, line 188, in install_replica_ds ca_file=config.dir + /ca.crt, File /usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py, line 360 in create_replica self.start_creation(runtime=60) File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 364, in start_creation method() File /usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py, line 373, in __setup_replica r_bindpw=self.dm_password() File /usr/lib/python2.7/site-packages/ipaserver/install/replication.py, line 961, in setup_replication raise RuntimeError(Failed to start replication) 2014-0521T14:31:08Z DEBUG The ipa-replica-install command failed, exception: RuntimeError: Failed to start replication Any guidance on where to start looking? Check the 389-ds access and error logs on both masters. rob smime.p7s Description: S/MIME Cryptographic Signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] openldap certs?
On Thu, May 22, 2014 at 10:36:45AM -0400, Bret Wortman wrote: I found that our slower system was using FQDNs for the list of IPA servers; our faster system was using IPs. I'm switching now, letting Puppet distribute the update and will see if it helps. By enumeration, do you mean are we spelling out our IPA servers? Yes. We only have 3 and they look something like this: I suspect there are some DNS issues or failover issues on the 'slow' network. Can you post the domain logs? If you are concerned about some private data in the logs, feel free to send them to me directly. [domain/foo.net] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = foo.net id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = rm266ws-a.foo.net chpass_provider = ipa ipa_dyndns_update = True ipa_server = _srv_, 192.168.2.61, 192.168.2.62, 192.168.2.63 Even with the IP addresses, the first server instance is _srv_ which means the SSSD would try to get the server list from the DNS. ldap_netgroup_search_base = cn=ng,cn=compat,dc=foo,dc=net ldap_tls_cacert = /etc/ipa/ca.crt [sssd] services = nss, pam, ssh config_file_version = 2 domains = foo.net [nss] [pam] [sudo] [autofs] [ssh] [pac] On the other hand, if you meant something else, then I hope the answer's in the file. ;-) ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] openldap certs?
On 05/22/2014 10:36 AM, Bret Wortman wrote: I found that our slower system was using FQDNs for the list of IPA servers; our faster system was using IPs. I'm switching now, letting Puppet distribute the update and will see if it helps. That means you have problems with DNS that are worth looking into. By enumeration, do you mean are we spelling out our IPA servers? Yes. We only have 3 and they look something like this: No. I mean the ability of sssd to download everything when enumerate = true This causes a lot of traffic and overhead and a usual reason for low performance. We were unfortunate to include this setting into one of the early sssd.conf examples and people have been copying it around ever since though we strongly recommend against enabling it. [domain/foo.net] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = foo.net id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = rm266ws-a.foo.net chpass_provider = ipa ipa_dyndns_update = True ipa_server = _srv_, 192.168.2.61, 192.168.2.62, 192.168.2.63 ldap_netgroup_search_base = cn=ng,cn=compat,dc=foo,dc=net ldap_tls_cacert = /etc/ipa/ca.crt [sssd] services = nss, pam, ssh config_file_version = 2 domains = foo.net [nss] [pam] [sudo] [autofs] [ssh] [pac] On the other hand, if you meant something else, then I hope the answer's in the file. ;-) On 05/22/2014 10:15 AM, Dmitri Pal wrote: On 05/22/2014 09:43 AM, Bret Wortman wrote: What we're seeing is slow GDM logins, ssh authentications, and sudo -i responses on this network. On our other, these things are all blazing fast. Here, they're on the order of 5-10 seconds. And it doesn't seem to improve (much) with age or time, except perhaps anecdotally. At best, a second connection might be a second faster, but will revert within an hour or so. Have you compared sssd.conf from clients in these two networks? Do you use enumeration? Increasing debug level and looking at the logs will help you to understand what part takes most time. These logs will be helpful for you/us to see if/what the problem is/are. On 05/22/2014 09:36 AM, Rob Crittenden wrote: Bret Wortman wrote: Where should my clients be getting the contents of /etc/openldap/certs from? I've got one network where my IPA authentications are blazing fast and one where they're ... not. On the slower one, clients' /etc/openldap/certs directories are either missing or empty; on the faster network, clients have certs in these directories. Is this important, and if so what could be going wrong on my slower network that might cause the certs to not get distributed or created properly? These are not the droids you are looking for... Can you clarify what you mean by IPA authentications? sssd should be handling that, and while a first auth over a slow link might be slow subsequent usage should be quite fast. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] openldap certs?
It doesn't seem to have helped -- we're still pretty slow even with IP addresses in sssd.conf. On 05/22/2014 11:07 AM, Dmitri Pal wrote: On 05/22/2014 10:36 AM, Bret Wortman wrote: I found that our slower system was using FQDNs for the list of IPA servers; our faster system was using IPs. I'm switching now, letting Puppet distribute the update and will see if it helps. That means you have problems with DNS that are worth looking into. By enumeration, do you mean are we spelling out our IPA servers? Yes. We only have 3 and they look something like this: No. I mean the ability of sssd to download everything when enumerate = true This causes a lot of traffic and overhead and a usual reason for low performance. We were unfortunate to include this setting into one of the early sssd.conf examples and people have been copying it around ever since though we strongly recommend against enabling it. [domain/foo.net] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = foo.net id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = rm266ws-a.foo.net chpass_provider = ipa ipa_dyndns_update = True ipa_server = _srv_, 192.168.2.61, 192.168.2.62, 192.168.2.63 ldap_netgroup_search_base = cn=ng,cn=compat,dc=foo,dc=net ldap_tls_cacert = /etc/ipa/ca.crt [sssd] services = nss, pam, ssh config_file_version = 2 domains = foo.net [nss] [pam] [sudo] [autofs] [ssh] [pac] On the other hand, if you meant something else, then I hope the answer's in the file. ;-) On 05/22/2014 10:15 AM, Dmitri Pal wrote: On 05/22/2014 09:43 AM, Bret Wortman wrote: What we're seeing is slow GDM logins, ssh authentications, and sudo -i responses on this network. On our other, these things are all blazing fast. Here, they're on the order of 5-10 seconds. And it doesn't seem to improve (much) with age or time, except perhaps anecdotally. At best, a second connection might be a second faster, but will revert within an hour or so. Have you compared sssd.conf from clients in these two networks? Do you use enumeration? Increasing debug level and looking at the logs will help you to understand what part takes most time. These logs will be helpful for you/us to see if/what the problem is/are. On 05/22/2014 09:36 AM, Rob Crittenden wrote: Bret Wortman wrote: Where should my clients be getting the contents of /etc/openldap/certs from? I've got one network where my IPA authentications are blazing fast and one where they're ... not. On the slower one, clients' /etc/openldap/certs directories are either missing or empty; on the faster network, clients have certs in these directories. Is this important, and if so what could be going wrong on my slower network that might cause the certs to not get distributed or created properly? These are not the droids you are looking for... Can you clarify what you mean by IPA authentications? sssd should be handling that, and while a first auth over a slow link might be slow subsequent usage should be quite fast. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users smime.p7s Description: S/MIME Cryptographic Signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Why would /etc/passwd get skipped?
If this line is in /etc/nsswitch.conf: passwd: files sss Why would the user account from IPA get used when an identical one exists in /etc/passwd? We can tell because of some additional groups granted when authentication comes from IPA. If I shut down sssd, then login proceeds through /etc/passwd as expected, but as soon as I restart sssd, this behavior starts again. It's almost as if nsswitch.conf is being ignored or read right-to-left. Just another oddity I uncovered on one system as I was troubleshooting a particularly long ssh localhost and trying to rule things out. -- *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret smime.p7s Description: S/MIME Cryptographic Signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Why would /etc/passwd get skipped?
On Thu, 2014-05-22 at 12:47 -0400, Bret Wortman wrote: If this line is in /etc/nsswitch.conf: passwd: files sss Why would the user account from IPA get used when an identical one exists in /etc/passwd? We can tell because of some additional groups granted when authentication comes from IPA. If I shut down sssd, then login proceeds through /etc/passwd as expected, but as soon as I restart sssd, this behavior starts again. It's almost as if nsswitch.conf is being ignored or read right-to-left. Just another oddity I uncovered on one system as I was troubleshooting a particularly long ssh localhost and trying to rule things out. The initgroups call (done at authentication to find what groups a user is member of) by default traverses all databases, so if the same username is found in multiple databases the groups are added as well. There is actually a way to change this behavior, although it usually causes more issue than it resolves. You could try with: initgroups: files sss Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Why would /etc/passwd get skipped?
A. Then it's probably not the source of my performance problem. I know when I shut down SSSD, that user's ssh times speed up incredibly. Bret On 05/22/2014 01:06 PM, Simo Sorce wrote: On Thu, 2014-05-22 at 12:47 -0400, Bret Wortman wrote: If this line is in /etc/nsswitch.conf: passwd: files sss Why would the user account from IPA get used when an identical one exists in /etc/passwd? We can tell because of some additional groups granted when authentication comes from IPA. If I shut down sssd, then login proceeds through /etc/passwd as expected, but as soon as I restart sssd, this behavior starts again. It's almost as if nsswitch.conf is being ignored or read right-to-left. Just another oddity I uncovered on one system as I was troubleshooting a particularly long ssh localhost and trying to rule things out. The initgroups call (done at authentication to find what groups a user is member of) by default traverses all databases, so if the same username is found in multiple databases the groups are added as well. There is actually a way to change this behavior, although it usually causes more issue than it resolves. You could try with: initgroups: files sss Simo. smime.p7s Description: S/MIME Cryptographic Signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Why would /etc/passwd get skipped?
On Thu, 2014-05-22 at 13:12 -0400, Bret Wortman wrote: A. Then it's probably not the source of my performance problem. I know when I shut down SSSD, that user's ssh times speed up incredibly. This makes me think it *is* initgroups, as it normally will hit sssd even for non-sssd owned users. But the issue here clearly is that sssd is slow for you, bad network ? Simo. Bret On 05/22/2014 01:06 PM, Simo Sorce wrote: On Thu, 2014-05-22 at 12:47 -0400, Bret Wortman wrote: If this line is in /etc/nsswitch.conf: passwd: files sss Why would the user account from IPA get used when an identical one exists in /etc/passwd? We can tell because of some additional groups granted when authentication comes from IPA. If I shut down sssd, then login proceeds through /etc/passwd as expected, but as soon as I restart sssd, this behavior starts again. It's almost as if nsswitch.conf is being ignored or read right-to-left. Just another oddity I uncovered on one system as I was troubleshooting a particularly long ssh localhost and trying to rule things out. The initgroups call (done at authentication to find what groups a user is member of) by default traverses all databases, so if the same username is found in multiple databases the groups are added as well. There is actually a way to change this behavior, although it usually causes more issue than it resolves. You could try with: initgroups: files sss Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Why would /etc/passwd get skipped?
Yep, that initgroups change had the same effect as shutting down sssd, but without inconveniencing all the IPA-only users. The problem in this particular case was made worse by a lot of network latency, but even on network segments local to the ipa masters, it's taking seconds to authenticate. This will help out the local accounts, at least. Now to keep working on those that aren't local. Thanks for that tip, Simo! On 05/22/2014 01:15 PM, Simo Sorce wrote: On Thu, 2014-05-22 at 13:12 -0400, Bret Wortman wrote: A. Then it's probably not the source of my performance problem. I know when I shut down SSSD, that user's ssh times speed up incredibly. This makes me think it *is* initgroups, as it normally will hit sssd even for non-sssd owned users. But the issue here clearly is that sssd is slow for you, bad network ? Simo. Bret On 05/22/2014 01:06 PM, Simo Sorce wrote: On Thu, 2014-05-22 at 12:47 -0400, Bret Wortman wrote: If this line is in /etc/nsswitch.conf: passwd: files sss Why would the user account from IPA get used when an identical one exists in /etc/passwd? We can tell because of some additional groups granted when authentication comes from IPA. If I shut down sssd, then login proceeds through /etc/passwd as expected, but as soon as I restart sssd, this behavior starts again. It's almost as if nsswitch.conf is being ignored or read right-to-left. Just another oddity I uncovered on one system as I was troubleshooting a particularly long ssh localhost and trying to rule things out. The initgroups call (done at authentication to find what groups a user is member of) by default traverses all databases, so if the same username is found in multiple databases the groups are added as well. There is actually a way to change this behavior, although it usually causes more issue than it resolves. You could try with: initgroups: files sss Simo. smime.p7s Description: S/MIME Cryptographic Signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] openldap certs?
On Thu, May 22, 2014 at 11:16:57AM -0400, Bret Wortman wrote: It doesn't seem to have helped -- we're still pretty slow even with IP addresses in sssd.conf. Yes, I would expect the performance to be still slow, because when you perform authentication, the user information is always refreshed from the server, even with enumeration. This is to ensure correct and precise group membership at login time. On 05/22/2014 11:07 AM, Dmitri Pal wrote: On 05/22/2014 10:36 AM, Bret Wortman wrote: I found that our slower system was using FQDNs for the list of IPA servers; our faster system was using IPs. I'm switching now, letting Puppet distribute the update and will see if it helps. That means you have problems with DNS that are worth looking into. By enumeration, do you mean are we spelling out our IPA servers? Yes. We only have 3 and they look something like this: No. I mean the ability of sssd to download everything when enumerate = true This causes a lot of traffic and overhead and a usual reason for low performance. We were unfortunate to include this setting into one of the early sssd.conf examples and people have been copying it around ever since though we strongly recommend against enabling it. [domain/foo.net] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = foo.net id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = rm266ws-a.foo.net chpass_provider = ipa ipa_dyndns_update = True ipa_server = _srv_, 192.168.2.61, 192.168.2.62, 192.168.2.63 ldap_netgroup_search_base = cn=ng,cn=compat,dc=foo,dc=net ldap_tls_cacert = /etc/ipa/ca.crt [sssd] services = nss, pam, ssh config_file_version = 2 domains = foo.net [nss] [pam] [sudo] [autofs] [ssh] [pac] On the other hand, if you meant something else, then I hope the answer's in the file. ;-) On 05/22/2014 10:15 AM, Dmitri Pal wrote: On 05/22/2014 09:43 AM, Bret Wortman wrote: What we're seeing is slow GDM logins, ssh authentications, and sudo -i responses on this network. On our other, these things are all blazing fast. Here, they're on the order of 5-10 seconds. And it doesn't seem to improve (much) with age or time, except perhaps anecdotally. At best, a second connection might be a second faster, but will revert within an hour or so. Have you compared sssd.conf from clients in these two networks? Do you use enumeration? Increasing debug level and looking at the logs will help you to understand what part takes most time. These logs will be helpful for you/us to see if/what the problem is/are. On 05/22/2014 09:36 AM, Rob Crittenden wrote: Bret Wortman wrote: Where should my clients be getting the contents of /etc/openldap/certs from? I've got one network where my IPA authentications are blazing fast and one where they're ... not. On the slower one, clients' /etc/openldap/certs directories are either missing or empty; on the faster network, clients have certs in these directories. Is this important, and if so what could be going wrong on my slower network that might cause the certs to not get distributed or created properly? These are not the droids you are looking for... Can you clarify what you mean by IPA authentications? sssd should be handling that, and while a first auth over a slow link might be slow subsequent usage should be quite fast. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Why would /etc/passwd get skipped?
On Thu, May 22, 2014 at 01:22:28PM -0400, Bret Wortman wrote: Yep, that initgroups change had the same effect as shutting down sssd, but without inconveniencing all the IPA-only users. The problem in this particular case was made worse by a lot of network latency, but even on network segments local to the ipa masters, it's taking seconds to authenticate. This will help out the local accounts, at least. Now to keep working on those that aren't local. Thanks for that tip, Simo! Just as an additional tip for anyone else following this thread -- if you want to ignore certain local users from being queried in the SSSD backends, you can use the filter_users/filter_groups options. Their value defaults to 'root' so that we never fetch the root account from LDAP, but for example on my system I also include the 'pulse-rt' user.. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] openldap certs?
On 05/22/2014 02:25 PM, Jakub Hrozek wrote: On Thu, May 22, 2014 at 11:16:57AM -0400, Bret Wortman wrote: It doesn't seem to have helped -- we're still pretty slow even with IP addresses in sssd.conf. Yes, I would expect the performance to be still slow, because when you perform authentication, the user information is always refreshed from the server, even with enumeration. I do not think they have enumeration this is why this seems irrelevant. This is to ensure correct and precise group membership at login time. On 05/22/2014 11:07 AM, Dmitri Pal wrote: On 05/22/2014 10:36 AM, Bret Wortman wrote: I found that our slower system was using FQDNs for the list of IPA servers; our faster system was using IPs. I'm switching now, letting Puppet distribute the update and will see if it helps. That means you have problems with DNS that are worth looking into. By enumeration, do you mean are we spelling out our IPA servers? Yes. We only have 3 and they look something like this: No. I mean the ability of sssd to download everything when enumerate = true This causes a lot of traffic and overhead and a usual reason for low performance. We were unfortunate to include this setting into one of the early sssd.conf examples and people have been copying it around ever since though we strongly recommend against enabling it. [domain/foo.net] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = foo.net id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = rm266ws-a.foo.net chpass_provider = ipa ipa_dyndns_update = True ipa_server = _srv_, 192.168.2.61, 192.168.2.62, 192.168.2.63 ldap_netgroup_search_base = cn=ng,cn=compat,dc=foo,dc=net ldap_tls_cacert = /etc/ipa/ca.crt [sssd] services = nss, pam, ssh config_file_version = 2 domains = foo.net [nss] [pam] [sudo] [autofs] [ssh] [pac] On the other hand, if you meant something else, then I hope the answer's in the file. ;-) On 05/22/2014 10:15 AM, Dmitri Pal wrote: On 05/22/2014 09:43 AM, Bret Wortman wrote: What we're seeing is slow GDM logins, ssh authentications, and sudo -i responses on this network. On our other, these things are all blazing fast. Here, they're on the order of 5-10 seconds. And it doesn't seem to improve (much) with age or time, except perhaps anecdotally. At best, a second connection might be a second faster, but will revert within an hour or so. Have you compared sssd.conf from clients in these two networks? Do you use enumeration? Increasing debug level and looking at the logs will help you to understand what part takes most time. These logs will be helpful for you/us to see if/what the problem is/are. On 05/22/2014 09:36 AM, Rob Crittenden wrote: Bret Wortman wrote: Where should my clients be getting the contents of /etc/openldap/certs from? I've got one network where my IPA authentications are blazing fast and one where they're ... not. On the slower one, clients' /etc/openldap/certs directories are either missing or empty; on the faster network, clients have certs in these directories. Is this important, and if so what could be going wrong on my slower network that might cause the certs to not get distributed or created properly? These are not the droids you are looking for... Can you clarify what you mean by IPA authentications? sssd should be handling that, and while a first auth over a slow link might be slow subsequent usage should be quite fast. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] openldap certs?
On 05/22/2014 11:16 AM, Bret Wortman wrote: It doesn't seem to have helped -- we're still pretty slow even with IP addresses in sssd.conf. Then we need debug logs to see where the delays are. Put high debug level and zip the logs somewhere we can take a look at. Jakub is your guy. On 05/22/2014 11:07 AM, Dmitri Pal wrote: On 05/22/2014 10:36 AM, Bret Wortman wrote: I found that our slower system was using FQDNs for the list of IPA servers; our faster system was using IPs. I'm switching now, letting Puppet distribute the update and will see if it helps. That means you have problems with DNS that are worth looking into. By enumeration, do you mean are we spelling out our IPA servers? Yes. We only have 3 and they look something like this: No. I mean the ability of sssd to download everything when enumerate = true This causes a lot of traffic and overhead and a usual reason for low performance. We were unfortunate to include this setting into one of the early sssd.conf examples and people have been copying it around ever since though we strongly recommend against enabling it. [domain/foo.net] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = foo.net id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = rm266ws-a.foo.net chpass_provider = ipa ipa_dyndns_update = True ipa_server = _srv_, 192.168.2.61, 192.168.2.62, 192.168.2.63 ldap_netgroup_search_base = cn=ng,cn=compat,dc=foo,dc=net ldap_tls_cacert = /etc/ipa/ca.crt [sssd] services = nss, pam, ssh config_file_version = 2 domains = foo.net [nss] [pam] [sudo] [autofs] [ssh] [pac] On the other hand, if you meant something else, then I hope the answer's in the file. ;-) On 05/22/2014 10:15 AM, Dmitri Pal wrote: On 05/22/2014 09:43 AM, Bret Wortman wrote: What we're seeing is slow GDM logins, ssh authentications, and sudo -i responses on this network. On our other, these things are all blazing fast. Here, they're on the order of 5-10 seconds. And it doesn't seem to improve (much) with age or time, except perhaps anecdotally. At best, a second connection might be a second faster, but will revert within an hour or so. Have you compared sssd.conf from clients in these two networks? Do you use enumeration? Increasing debug level and looking at the logs will help you to understand what part takes most time. These logs will be helpful for you/us to see if/what the problem is/are. On 05/22/2014 09:36 AM, Rob Crittenden wrote: Bret Wortman wrote: Where should my clients be getting the contents of /etc/openldap/certs from? I've got one network where my IPA authentications are blazing fast and one where they're ... not. On the slower one, clients' /etc/openldap/certs directories are either missing or empty; on the faster network, clients have certs in these directories. Is this important, and if so what could be going wrong on my slower network that might cause the certs to not get distributed or created properly? These are not the droids you are looking for... Can you clarify what you mean by IPA authentications? sssd should be handling that, and while a first auth over a slow link might be slow subsequent usage should be quite fast. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Export user and host list to a csv or text file
Dear All, Is there any command to export the user and host list to a csv or text format Regards Sanju Abraham ___ =-=-= Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
