Re: [Freeipa-users] Sudo denied on first attempt, allowed on second attempt
Hi Jakub, id info from earlier response: Very interesting, my IPA group membership in ad_admins isn't shown by that command on first run (new login) sdainard-ad...@miovision.corp@__ubu1310:~$ id sdainard-admin uid=799002462(sdainard-admin@__miovision.corp) gid=799002462(sdainard-admin@__miovision.corp) groups=799002462(sdainard-__ad...@miovision.corp),__ 799001380(accounting-share-__acc...@miovision.corp),__ 799001417(protected-share-__acc...@miovision.corp),__799000519(enterprise adm...@miovision.corp),__799001416(hr-share-access@__ miovision.corp),799000512(__domain adm...@miovision.corp),__799000513(domain us...@miovision.corp),__799002464(it - adm...@miovision.corp),__799002469(kloperators@__ miovision.corp),799002468(__kladm...@miovision.corp) sdainard-ad...@miovision.corp@__ubu1310:~$ sudo su [sudo] password for sdainard-ad...@miovision.corp: sdainard-ad...@miovision.corp is not allowed to run sudo on ubu1310. This incident will be reported. But after attempting the sudo command my groups do contain the IPA groups admins,ad_admins: sdainard-ad...@miovision.corp@__ubu1310:~$ id sdainard-admin uid=799002462(sdainard-admin@__miovision.corp) gid=799002462(sdainard-admin@__miovision.corp) groups=799002462(sdainard-__ad...@miovision.corp),__ 799001380(accounting-share-__acc...@miovision.corp),__ 799001417(protected-share-__acc...@miovision.corp),__799000519(enterprise adm...@miovision.corp),__799001416(hr-share-access@__ miovision.corp),799000512(__domain adm...@miovision.corp),__799000513(domain us...@miovision.corp),__799002464(it - adm...@miovision.corp),__799002469(kloperators@__ miovision.corp),799002468(__kladm...@miovision.corp),*__ 176820(admins),176824(__ad_admins)* *Steve Dainard * IT Infrastructure Manager Miovision http://miovision.com/ | *Rethink Traffic* *Blog http://miovision.com/blog | **LinkedIn https://www.linkedin.com/company/miovision-technologies | Twitter https://twitter.com/miovision | Facebook https://www.facebook.com/miovision* -- Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, ON, Canada | N2C 1L3 This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. On Mon, Feb 24, 2014 at 10:55 AM, Jakub Hrozek jhro...@redhat.com wrote: On Mon, Feb 24, 2014 at 10:46:19AM -0500, Pavel Brezina wrote: Hi, I wasn't able to reproduce with membership setup exactly like this. I have already seen similar problem once, unfortunately the user stopped responding before we could reach the root cause. I think it is correct from the sudo point of view, what is problematic here is missing group membership. It seems that membership of trusted user is not resolved correctly. Sumit, Jakub, do you have any ideas? Did you verify if id prints the expected groups for the user in question after he logs in? I think we need to first verify if the memberships are stored correctly to the cache.. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Sudo denied on first attempt, allowed on second attempt
Sumit, Unfortunately 1.11.1 is the only version available for Ubuntu 13.10. I've also had the same problem with an updated version of Fedora 20, so I don't think its specific to this package version. *Steve Dainard * IT Infrastructure Manager Miovision http://miovision.com/ | *Rethink Traffic* *Blog http://miovision.com/blog | **LinkedIn https://www.linkedin.com/company/miovision-technologies | Twitter https://twitter.com/miovision | Facebook https://www.facebook.com/miovision* -- Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, ON, Canada | N2C 1L3 This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. On Mon, Mar 3, 2014 at 2:01 PM, Steve Dainard sdain...@miovision.comwrote: Hi Jakub, id info from earlier response: Very interesting, my IPA group membership in ad_admins isn't shown by that command on first run (new login) sdainard-ad...@miovision.corp@__ubu1310:~$ id sdainard-admin uid=799002462(sdainard-admin@__miovision.corp) gid=799002462(sdainard-admin@__miovision.corp) groups=799002462(sdainard-__ad...@miovision.corp),__ 799001380(accounting-share-__acc...@miovision.corp),__ 799001417(protected-share-__acc...@miovision.corp),__799000519(enterprise adm...@miovision.corp),__799001416(hr-share-access@__ miovision.corp),799000512(__domain adm...@miovision.corp),__799000513(domain us...@miovision.corp),__799002464(it - adm...@miovision.corp),__799002469(kloperators@__ miovision.corp),799002468(__kladm...@miovision.corp) sdainard-ad...@miovision.corp@__ubu1310:~$ sudo su [sudo] password for sdainard-ad...@miovision.corp: sdainard-ad...@miovision.corp is not allowed to run sudo on ubu1310. This incident will be reported. But after attempting the sudo command my groups do contain the IPA groups admins,ad_admins: sdainard-ad...@miovision.corp@__ubu1310:~$ id sdainard-admin uid=799002462(sdainard-admin@__miovision.corp) gid=799002462(sdainard-admin@__miovision.corp) groups=799002462(sdainard-__ad...@miovision.corp),__ 799001380(accounting-share-__acc...@miovision.corp),__ 799001417(protected-share-__acc...@miovision.corp),__799000519(enterprise adm...@miovision.corp),__799001416(hr-share-access@__ miovision.corp),799000512(__domain adm...@miovision.corp),__799000513(domain us...@miovision.corp),__799002464(it - adm...@miovision.corp),__799002469(kloperators@__ miovision.corp),799002468(__kladm...@miovision.corp),*__ 176820(admins),176824(__ad_admins)* *Steve Dainard * IT Infrastructure Manager Miovision http://miovision.com/ | *Rethink Traffic* *Blog http://miovision.com/blog | **LinkedIn https://www.linkedin.com/company/miovision-technologies | Twitter https://twitter.com/miovision | Facebook https://www.facebook.com/miovision* -- Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, ON, Canada | N2C 1L3 This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. On Mon, Feb 24, 2014 at 10:55 AM, Jakub Hrozek jhro...@redhat.com wrote: On Mon, Feb 24, 2014 at 10:46:19AM -0500, Pavel Brezina wrote: Hi, I wasn't able to reproduce with membership setup exactly like this. I have already seen similar problem once, unfortunately the user stopped responding before we could reach the root cause. I think it is correct from the sudo point of view, what is problematic here is missing group membership. It seems that membership of trusted user is not resolved correctly. Sumit, Jakub, do you have any ideas? Did you verify if id prints the expected groups for the user in question after he logs in? I think we need to first verify if the memberships are stored correctly to the cache.. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] local root can su to any IPA user
Would it not be possible for root to disable selinux enforcement? A user could maybe even use a livecd if root couldn't be gained directly. I'm looking at joining workstations to an idm realm, but some users will need sudo permissions on their machines. Is there any documentation on best practices here? Has there been any further discussion on the best way to approach this problem? Thanks, *Steve Dainard * IT Infrastructure Manager Miovision http://miovision.com/ | *Rethink Traffic* *Blog http://miovision.com/blog | **LinkedIn https://www.linkedin.com/company/miovision-technologies | Twitter https://twitter.com/miovision | Facebook https://www.facebook.com/miovision* -- Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, ON, Canada | N2C 1L3 This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. On Fri, Nov 29, 2013 at 9:41 AM, Martin Kosek mko...@redhat.com wrote: On 11/29/2013 03:17 PM, Jakub Hrozek wrote: On Fri, Nov 29, 2013 at 03:08:44PM +0100, Fred van Zwieten wrote: Jakub, Yes, I could do this. But then the local root account cannot su to local users (without password). But that is actually a normal use-case. I just think local root should not be allowed to transition to a domain user, by default. Fred Ah, in that case I'm not sure if there's an easy solution, at least I don't know any off hand. I think Alexander is right that SELinux would be a good choice. Right. Root could uncomment the pam_rootok.so line anyway if he wanted to access other user's account again. Martin ___ 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] Sudo denied on first attempt, allowed on second attempt
Hi Pavel, sdainard-admin is a Windows domain user, part of an external group 'ad_admins_external' which is a member of 'ad_admins', an ipa posix group. 'admins' groups is the built-in ipa admin group. ipa group-show admins Group name: admins Description: Account administrators group GID: 176820 Member users: admin Member groups: ad_admins Member of Sudo rule: ad_admins Indirect Member groups: ad_admins_external ipa group-show ad_admins Group name: ad_admins Description: miovision.corp admins GID: 176824 Member users: admin Member groups: ad_admins_external Member of groups: admins Member of Sudo rule: ad_admins, All Thanks, *Steve Dainard * IT Infrastructure Manager Miovision http://miovision.com/ | *Rethink Traffic* *Blog http://miovision.com/blog | **LinkedIn https://www.linkedin.com/company/miovision-technologies | Twitter https://twitter.com/miovision | Facebook https://www.facebook.com/miovision* -- Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, ON, Canada | N2C 1L3 This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. On Wed, Feb 19, 2014 at 8:48 AM, Pavel Březina pbrez...@redhat.com wrote: On 02/18/2014 10:32 PM, Steve Dainard wrote: Hi Pavel, Very interesting, my IPA group membership in ad_admins isn't shown by that command on first run (new login) sdainard-ad...@miovision.corp@ubu1310:~$ id sdainard-admin uid=799002462(sdainard-ad...@miovision.corp) gid=799002462(sdainard-ad...@miovision.corp) groups=799002462(sdainard-ad...@miovision.corp), 799001380(accounting-share-acc...@miovision.corp), 799001417(protected-share-acc...@miovision.corp),799000519(enterprise adm...@miovision.corp),799001416(hr-share-access@ miovision.corp),799000512(domain adm...@miovision.corp),799000513(domain us...@miovision.corp),799002464(it - adm...@miovision.corp),799002469(kloperat...@miovision.corp),799002468( kladm...@miovision.corp) sdainard-ad...@miovision.corp@ubu1310:~$ sudo su [sudo] password for sdainard-ad...@miovision.corp: sdainard-ad...@miovision.corp is not allowed to run sudo on ubu1310. This incident will be reported. But after attempting the sudo command my groups do contain the IPA groups admins,ad_admins: sdainard-ad...@miovision.corp@ubu1310:~$ id sdainard-admin uid=799002462(sdainard-ad...@miovision.corp) gid=799002462(sdainard-ad...@miovision.corp) groups=799002462(sdainard-ad...@miovision.corp), 799001380(accounting-share-acc...@miovision.corp), 799001417(protected-share-acc...@miovision.corp),799000519(enterprise adm...@miovision.corp),799001416(hr-share-access@ miovision.corp),799000512(domain adm...@miovision.corp),799000513(domain us...@miovision.corp),799002464(it - adm...@miovision.corp),799002469(kloperat...@miovision.corp),799002468( kladm...@miovision.corp),*176820(admins),176824(ad_admins)* sdainard-ad...@miovision.corp@ubu1310:~$ sudo su [sudo] password for sdainard-ad...@miovision.corp: root@ubu1310:/home/miovision.corp/sdainard-admin# Sudo rule (I had to create this, apparently its a default rule, but didn't exist in my install on RHEL7 beta): Rule name: All Enabled: TRUE Host category: all Command category: all RunAs User category: all RunAs Group category: all User Groups: ad_admins Can you tell me more information about admins and ad_admins groups and sdainard-admin? I would like to know how the membership is configured and what is their relation to AD. Dump of ipa user-show and ipa group-show should be enough, I think. I saw the new dns update option (and refresh timers!), thanks. *Steve Dainard * IT Infrastructure Manager Miovision http://miovision.com/ | /Rethink Traffic/ *Blog http://miovision.com/blog | **LinkedIn https://www.linkedin.com/company/miovision-technologies | Twitter https://twitter.com/miovision | Facebook https://www.facebook.com/miovision* Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, ON, Canada | N2C 1L3 This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. On Tue, Feb 18, 2014 at 5:27 AM, Pavel Březina pbrez...@redhat.com mailto:pbrez...@redhat.com wrote: On 02/17/2014 10:29 PM, Steve Dainard wrote: I can't reproduce consistently on any OS including Fedora 20, but I was able to trigger the issue on a Ubuntu 13.10 client. sssd: 1.11.1 sudo: 1.8.6p3-0ubuntu3 I have only just enabled the sudo logging so it should only contain the events below: sdainard-ad...@miovision.corp@__ubu1310:~$ sudo su
Re: [Freeipa-users] Sudo denied on first attempt, allowed on second attempt
I can't reproduce consistently on any OS including Fedora 20, but I was able to trigger the issue on a Ubuntu 13.10 client. sssd: 1.11.1 sudo: 1.8.6p3-0ubuntu3 I have only just enabled the sudo logging so it should only contain the events below: sdainard-ad...@miovision.corp@ubu1310:~$ sudo su [sudo] password for sdainard-ad...@miovision.corp: sdainard-ad...@miovision.corp is not allowed to run sudo on ubu1310. This incident will be reported. sdainard-ad...@miovision.corp@ubu1310:~$ sudo su [sudo] password for sdainard-ad...@miovision.corp: root@ubu1310:/home/miovision.corp/sdainard-admin# Files attached outside of list. Thanks, *Steve Dainard * IT Infrastructure Manager Miovision http://miovision.com/ | *Rethink Traffic* *Blog http://miovision.com/blog | **LinkedIn https://www.linkedin.com/company/miovision-technologies | Twitter https://twitter.com/miovision | Facebook https://www.facebook.com/miovision* -- Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, ON, Canada | N2C 1L3 This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. On Mon, Feb 17, 2014 at 3:46 AM, Pavel Březina pbrez...@redhat.com wrote: On 02/16/2014 01:19 AM, Steve Dainard wrote: Just experienced the same issue on Fedora 20: [sdainard-ad...@miovision.corp@fed20 ~]$ sudo systemctl stop firewalld [sudo] password for sdainard-ad...@miovision.corp: sdainard-ad...@miovision.corp is not allowed to run sudo on fed20. This incident will be reported. [sdainard-ad...@miovision.corp@fed20 ~]$ sudo systemctl stop firewalld [sudo] password for sdainard-ad...@miovision.corp: [sdainard-ad...@miovision.corp@fed20 ~]$ Sat Feb 15 19:10:30 2014 is the 2nd attempt in the logs (attached). /var/log/messages: Feb 15 19:10:31 fed20 systemd: Stopping firewalld - dynamic firewall daemon... Feb 15 19:10:31 fed20 systemd: Stopped firewalld - dynamic firewall daemon. *Steve Dainard * IT Infrastructure Manager Miovision http://miovision.com/ | /Rethink Traffic/ *Blog http://miovision.com/blog | **LinkedIn https://www.linkedin.com/company/miovision-technologies | Twitter https://twitter.com/miovision | Facebook https://www.facebook.com/miovision* Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, ON, Canada | N2C 1L3 This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. On Fri, Feb 14, 2014 at 4:33 PM, Steve Dainard sdain...@miovision.com mailto:sdain...@miovision.com wrote: On a Ubuntu 13.10 client after configuring sssd to provide sudo service I left the client idle for a few hours. On returning, I unlocked the screensaver and did the following: sdainard-ad...@miovision.corp@ubu1310:~$ sudo su [sudo] password for sdainard-ad...@miovision.corp: sdainard-ad...@miovision.corp is not allowed to run sudo on ubu1310. This incident will be reported. sdainard-ad...@miovision.corp@ubu1310:~$ sudo su [sudo] password for sdainard-ad...@miovision.corp: root@ubu1310:/home/miovision.corp/sdainard-admin# I haven't experienced this on a Fedora 20 or EL client so I'm guessing this is something specific to Ubuntu. I've attached the client sssd log if anyone can point me in the right direction. Thanks, *Steve Dainard * IT Infrastructure Manager Miovision http://miovision.com/ | /Rethink Traffic/ *Blog http://miovision.com/blog | **LinkedIn https://www.linkedin.com/company/miovision-technologies | Twitter https://twitter.com/miovision | Facebook https://www.facebook.com/miovision* Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, ON, Canada | N2C 1L3 This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. Hi, provided logs did not reveal anything bad. Can you also attach sssd_sudo.log, sssd_nss.log and sssd.conf please? Also what sssd and sudo version do you run? Is this always reproducible or it happens only sporadically? Thanks. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] authentication against compat
Is this server or client side where sudo_provider=ipa is included in ver 1.11.x? My fedora 20 client doesn't have this option listed, or is it baked in? *Steve Dainard * IT Infrastructure Manager Miovision http://miovision.com/ | *Rethink Traffic* *Blog http://miovision.com/blog | **LinkedIn https://www.linkedin.com/company/miovision-technologies | Twitter https://twitter.com/miovision | Facebook https://www.facebook.com/miovision* -- Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, ON, Canada | N2C 1L3 This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. On Thu, Feb 13, 2014 at 3:46 AM, Jakub Hrozek jhro...@redhat.com wrote: On Wed, Feb 12, 2014 at 03:35:58PM -0800, Will Sheldon wrote: Is SSSD working for IPA sudo now? It was working even before, just with a bit of manual config, as I said in the reply you quoted, you just had to configure 'sudo_provider=ldap' I saw this From Jakub Horozek in this list a little while back: Unfortunately with 6.5 there is still no sudo ipa provider, there might be with one in 6.6. So in order to download the sudo rules you need to configure the LDAP sudo provider manually. sudo_provider=ipa is included in 1.9.6 and also all recent versions (1.11.x) We're thinking about including a newer version in RHEL-6.6, where the sudo_provider=ipa would be included as well. ___ 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] authentication against compat
I don't think this is an issue of bugs or documentation, more of design. Perhaps there's someplace other than a users list this belongs in but: If IPA is a centrally managed identity and access control system, should these configurations not be passed to clients, rather than every client needing configuration changes post join? Obviously I can automate config changes, but why would I want to? I don't think sudoers priv is a fringe case, its pretty much THE case for access/admin control. I cringe to compare to a Windows domain, but I don't have to manually tell a domain client that it should respect the rules I set on a domain controller, I joined it to the domain for this reason. Maybe you're working towards this, but in the meantime it would be great if the options existed in the config files so we immediately know what options are available and can comment/uncomment them rather than searching around man pages for options that might exist. I believe you were looking for a documentation bug: # man sssd-sudo To enable SSSD as a source for sudo rules, *add sss to the sudoers entry* in nsswitch.conf(5). For example, to configure sudo to first lookup rules in the standard sudoers(5) file (which should contain rules that apply to local users) and then in SSSD, the nsswitch.conf file should contain the following line: * sudoers: files sss* # /etc/nsswitch.conf # # An example Name Service Switch config file. This file should be # sorted with the most-used services at the beginning. # # The entry '[NOTFOUND=return]' means that the search for an # entry should stop if the search in the previous entry turned # up nothing. Note that if the search failed due to some other reason # (like no NIS server responding) then the search continues with the # next entry. # # Valid entries include: # # nisplus Use NIS+ (NIS version 3) # nis Use NIS (NIS version 2), also called YP # dns Use DNS (Domain Name Service) # files Use the local files # db Use the local database (.db) files # compat Use NIS on compat mode # hesiod Use Hesiod for user lookups # [NOTFOUND=return] Stop searching if not found so far # # To use db, put the db in front of files for entries you want to be # looked up first in the databases # # Example: #passwd:db files nisplus nis #shadow:db files nisplus nis #group: db files nisplus nis passwd: files sss shadow: files sss group: files sss #initgroups: files #hosts: db files nisplus nis dns hosts: files mdns4_minimal [NOTFOUND=return] dns # Example - obey only what nisplus tells us... #services: nisplus [NOTFOUND=return] files #networks: nisplus [NOTFOUND=return] files #protocols: nisplus [NOTFOUND=return] files #rpc:nisplus [NOTFOUND=return] files #ethers: nisplus [NOTFOUND=return] files #netmasks: nisplus [NOTFOUND=return] files bootparams: nisplus [NOTFOUND=return] files ethers: files netmasks: files networks: files protocols: files rpc:files services: files sss netgroup: files sss publickey: nisplus automount: files sss aliases:files nisplus Entry does not exist. *Steve Dainard * IT Infrastructure Manager Miovision http://miovision.com/ | *Rethink Traffic* *Blog http://miovision.com/blog | **LinkedIn https://www.linkedin.com/company/miovision-technologies | Twitter https://twitter.com/miovision | Facebook https://www.facebook.com/miovision* -- Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, ON, Canada | N2C 1L3 This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. On Thu, Feb 13, 2014 at 5:15 PM, Jakub Hrozek jhro...@redhat.com wrote: On Thu, Feb 13, 2014 at 03:05:07PM -0500, Steve Dainard wrote: Is this server or client side where sudo_provider=ipa is included in ver 1.11.x? Client side (sssd) My fedora 20 client doesn't have this option listed, or is it baked in? Where exactly do you see the documentation lacking, perhaps the sssd-ipa man page, or the sssd-sudo man page? I agree that docs are important, but my view might be skewed because I know the internals.. All that should be required with 1.9.6 or 1.11.x is: sudo_provider=ipa And enabling the 'sss' module in /etc/nsswitch.conf: sudoers: files sss That's it. Please let us know if you find any bugs in code or docs. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] RHEL 7 beta trust - slow domain user authentication to Linux hosts
2014) [[sssd[krb5_child[9960 [krb5_child_setup] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Mon Feb 10 10:16:57 2014) [[sssd[krb5_child[9960 [krb5_child_setup] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Mon Feb 10 10:16:57 2014) [[sssd[krb5_child[9960 [krb5_set_canonicalize] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Mon Feb 10 10:16:57 2014) [[sssd[krb5_child[9960 [krb5_child_setup] (0x0100): Not using FAST. (Mon Feb 10 10:16:57 2014) [[sssd[krb5_child[9960 [tgt_req_child] (0x1000): Attempting to get a TGT (Mon Feb 10 10:16:57 2014) [[sssd[krb5_child[9960 [get_and_save_tgt] (0x0400): Attempting kinit for realm [MIOVISION.CORP] (Mon Feb 10 10:16:57 2014) [[sssd[krb5_child[9960 [validate_tgt] (0x0400): TGT verified using key for [host/snapshot-test.miolinux.c...@miolinux.corp]. (Mon Feb 10 10:17:01 2014) [[sssd[krb5_child[9960 [become_user] (0x0200): Trying to become user [799001323][799001323]. (Mon Feb 10 10:17:01 2014) [[sssd[krb5_child[9960 [create_ccache_file] (0x0200): Creating ccache at [FILE:/tmp/krb5cc_799001323_zWaW2Z] (Mon Feb 10 10:17:01 2014) [[sssd[krb5_child[9960 [create_ccache_file] (0x1000): Created ccache file: [FILE:/tmp/krb5cc_799001323_zWaW2Z] (Mon Feb 10 10:17:01 2014) [[sssd[krb5_child[9960 [prepare_response_message] (0x0400): Building response for result [0] (Mon Feb 10 10:17:01 2014) [[sssd[krb5_child[9960 [main] (0x0400): krb5_child completed successfully (Mon Feb 10 10:17:29 2014) [[sssd[krb5_child[10018 [main] (0x0400): krb5_child started. (Mon Feb 10 10:17:29 2014) [[sssd[krb5_child[10018 [unpack_buffer] (0x1000): total buffer size: [125] (Mon Feb 10 10:17:29 2014) [[sssd[krb5_child[10018 [unpack_buffer] (0x0100): cmd [241] uid [799001323] gid [799001323] validate [true] offline [false] UPN [sdain...@miovision.corp] (Mon Feb 10 10:17:29 2014) [[sssd[krb5_child[10018 [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_799001323_zWaW2Z] keytab: [/etc/krb5.keytab] (Mon Feb 10 10:17:29 2014) [[sssd[krb5_child[10018 [krb5_child_setup] (0x0400): Will perform online auth (Mon Feb 10 10:17:29 2014) [[sssd[krb5_child[10018 [krb5_child_setup] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Mon Feb 10 10:17:29 2014) [[sssd[krb5_child[10018 [krb5_child_setup] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Mon Feb 10 10:17:29 2014) [[sssd[krb5_child[10018 [krb5_set_canonicalize] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Mon Feb 10 10:17:29 2014) [[sssd[krb5_child[10018 [krb5_child_setup] (0x0100): Not using FAST. (Mon Feb 10 10:17:29 2014) [[sssd[krb5_child[10018 [tgt_req_child] (0x1000): Attempting to get a TGT (Mon Feb 10 10:17:29 2014) [[sssd[krb5_child[10018 [get_and_save_tgt] (0x0400): Attempting kinit for realm [MIOVISION.CORP] (Mon Feb 10 10:17:30 2014) [[sssd[krb5_child[10018 [validate_tgt] (0x0400): TGT verified using key for [host/snapshot-test.miolinux.c...@miolinux.corp]. (Mon Feb 10 10:17:34 2014) [[sssd[krb5_child[10018 [become_user] (0x0200): Trying to become user [799001323][799001323]. (Mon Feb 10 10:17:34 2014) [[sssd[krb5_child[10018 [create_ccache_file] (0x0200): Creating ccache at [FILE:/tmp/krb5cc_799001323_zWaW2Z] (Mon Feb 10 10:17:35 2014) [[sssd[krb5_child[10018 [create_ccache_file] (0x1000): Created ccache file: [FILE:/tmp/krb5cc_799001323_zWaW2Z] (Mon Feb 10 10:17:35 2014) [[sssd[krb5_child[10018 [prepare_response_message] (0x0400): Building response for result [0] (Mon Feb 10 10:17:35 2014) [[sssd[krb5_child[10018 [main] (0x0400): krb5_child completed successfully *Steve Dainard * IT Infrastructure Manager Miovision http://miovision.com/ | *Rethink Traffic* 519-513-2407 ex.250 877-646-8476 (toll-free) *Blog http://miovision.com/blog | **LinkedIn https://www.linkedin.com/company/miovision-technologies | Twitter https://twitter.com/miovision | Facebook https://www.facebook.com/miovision* -- Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, ON, Canada | N2C 1L3 This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. On Mon, Feb 10, 2014 at 11:09 AM, Sumit Bose sb...@redhat.com wrote: On Mon, Feb 10, 2014 at 10:55:33AM -0500, Steve Dainard wrote: I've setup RHEL 7 beta IPA with a trust to an AD domain. When I use an AD domain login it takes roughly 9-14 seconds to get to a shell after entering a password. Is there any way to speed this process up? I thought supplemental logins would be quicker, but the login time is the same. This is either via console, or via ssh@localhost or ssh over the network. at a first glace I would say that the delay is in krb5_child. Can you send this log file as well? bye, Sumit IPA realm = miolinux.corp DC domain
Re: [Freeipa-users] Cross domain trust
{18 17 16 23}) 10.0.6.239: ISSUE: authtime 1391699614, etypes {rep=18
tkt=18 ses=18}, host/rhel6-client.miolinux.c...@miolinux.corp for
ldap/ipa1.miolinux.c...@miolinux.corp
Feb 06 10:13:35 ipa1.miolinux.corp krb5kdc[7688](info): AS_REQ (4 etypes
{18 17 16 23}) 10.0.6.239: NEEDED_PREAUTH:
host/rhel6-client.miolinux.c...@miolinux.corp for
krbtgt/miolinux.c...@miolinux.corp, Additional pre-authentication required
Feb 06 10:13:35 ipa1.miolinux.corp krb5kdc[7688](info): AS_REQ (4 etypes
{18 17 16 23}) 10.0.6.239: ISSUE: authtime 1391699615, etypes {rep=18
tkt=18 ses=18}, host/rhel6-client.miolinux.c...@miolinux.corp for
krbtgt/miolinux.c...@miolinux.corp
Feb 06 10:13:36 ipa1.miolinux.corp krb5kdc[7689](info): TGS_REQ (4 etypes
{18 17 16 23}) 10.0.6.239: ISSUE: authtime 1391699615, etypes {rep=18
tkt=18 ses=18}, host/rhel6-client.miolinux.c...@miolinux.corp for
ldap/ipa1.miolinux.c...@miolinux.corp
Feb 06 10:13:36 ipa1.miolinux.corp krb5kdc[7689](info): AS_REQ (4 etypes
{18 17 16 23}) 10.0.6.239: NEEDED_PREAUTH:
host/rhel6-client.miolinux.c...@miolinux.corp for
krbtgt/miolinux.c...@miolinux.corp, Additional pre-authentication required
Feb 06 10:13:36 ipa1.miolinux.corp krb5kdc[7687](info): AS_REQ (4 etypes
{18 17 16 23}) 10.0.6.239: ISSUE: authtime 1391699616, etypes {rep=18
tkt=18 ses=18}, host/rhel6-client.miolinux.c...@miolinux.corp for
krbtgt/miolinux.c...@miolinux.corp
Feb 06 10:13:36 ipa1.miolinux.corp krb5kdc[7688](info): TGS_REQ (4 etypes
{18 17 16 23}) 10.0.6.239: ISSUE: authtime 1391699616, etypes {rep=18
tkt=18 ses=18}, host/rhel6-client.miolinux.c...@miolinux.corp for
ldap/ipa1.miolinux.c...@miolinux.corp
Feb 06 10:13:36 ipa1.miolinux.corp krb5kdc[7687](info): AS_REQ (4 etypes
{18 17 16 23}) 10.0.6.239: NEEDED_PREAUTH:
host/rhel6-client.miolinux.c...@miolinux.corp for
krbtgt/miolinux.c...@miolinux.corp, Additional pre-authentication required
Feb 06 10:13:36 ipa1.miolinux.corp krb5kdc[7690](info): AS_REQ (4 etypes
{18 17 16 23}) 10.0.6.239: ISSUE: authtime 1391699616, etypes {rep=18
tkt=18 ses=18}, host/rhel6-client.miolinux.c...@miolinux.corp for
krbtgt/miolinux.c...@miolinux.corp
Feb 06 10:13:37 ipa1.miolinux.corp krb5kdc[7687](info): TGS_REQ (4 etypes
{18 17 16 23}) 10.0.6.239: ISSUE: authtime 1391699616, etypes {rep=18
tkt=18 ses=18}, host/rhel6-client.miolinux.c...@miolinux.corp for
ldap/ipa1.miolinux.c...@miolinux.corp
Feb 06 10:13:37 ipa1.miolinux.corp krb5kdc[7690](info): AS_REQ (4 etypes
{18 17 16 23}) 10.0.6.239: NEEDED_PREAUTH:
host/rhel6-client.miolinux.c...@miolinux.corp for
krbtgt/miolinux.c...@miolinux.corp, Additional pre-authentication required
Feb 06 10:13:37 ipa1.miolinux.corp krb5kdc[7689](info): AS_REQ (4 etypes
{18 17 16 23}) 10.0.6.239: ISSUE: authtime 1391699617, etypes {rep=18
tkt=18 ses=18}, host/rhel6-client.miolinux.c...@miolinux.corp for
krbtgt/miolinux.c...@miolinux.corp
Feb 06 10:13:38 ipa1.miolinux.corp krb5kdc[7690](info): TGS_REQ (4 etypes
{18 17 16 23}) 10.0.6.239: ISSUE: authtime 1391699617, etypes {rep=18
tkt=18 ses=18}, host/rhel6-client.miolinux.c...@miolinux.corp for
ldap/ipa1.miolinux.c...@miolinux.corp
Feb 06 10:13:38 ipa1.miolinux.corp krb5kdc[7689](info): AS_REQ (4 etypes
{18 17 16 23}) 10.0.6.239: NEEDED_PREAUTH:
host/rhel6-client.miolinux.c...@miolinux.corp for
krbtgt/miolinux.c...@miolinux.corp, Additional pre-authentication required
Feb 06 10:13:38 ipa1.miolinux.corp krb5kdc[7688](info): AS_REQ (4 etypes
{18 17 16 23}) 10.0.6.239: ISSUE: authtime 1391699618, etypes {rep=18
tkt=18 ses=18}, host/rhel6-client.miolinux.c...@miolinux.corp for
krbtgt/miolinux.c...@miolinux.corp
Feb 06 10:13:38 ipa1.miolinux.corp krb5kdc[7687](info): TGS_REQ (4 etypes
{18 17 16 23}) 10.0.6.239: ISSUE: authtime 1391699618, etypes {rep=18
tkt=18 ses=18}, host/rhel6-client.miolinux.c...@miolinux.corp for
ldap/ipa1.miolinux.c...@miolinux.corp
*Steve Dainard *
IT Infrastructure Manager
Miovision http://miovision.com/ | *Rethink Traffic*
519-513-2407 ex.250
877-646-8476 (toll-free)
*Blog http://miovision.com/blog | **LinkedIn
https://www.linkedin.com/company/miovision-technologies | Twitter
https://twitter.com/miovision | Facebook
https://www.facebook.com/miovision*
--
Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, ON,
Canada | N2C 1L3
This e-mail may contain information that is privileged or confidential. If
you are not the intended recipient, please delete the e-mail and any
attachments and notify us immediately.
On Wed, Feb 5, 2014 at 5:30 PM, Steve Dainard sdain...@miovision.comwrote:
I didn't have the firewall on my IPA server down while forming the trust.
All seems to be working now.
Thanks for your help.
Steve
--
/ Alexander Bokovoy
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Cross domain trust
On Thu, Feb 6, 2014 at 11:14 AM, Alexander Bokovoy aboko...@redhat.comwrote:
On Thu, 06 Feb 2014, Steve Dainard wrote:
So I've completed the setup, and can see the trust on the Windows side.
I've joined a client to the IPA realm, and can login with a IPA user. When
I try to login (console, ssh, su -) as a domain user I get:
CLIENT SIDE
[root@rhel6-client ~]# su - sdainard@miovision
su: user sdainard@miovision does not exist
[root@rhel6-client ~]# su - sdain...@miovision.corp
su: user sdain...@miovision.corp does not exist
[root@rhel6-client ~]# su - sdain...@miovision.corp
su: user sdain...@miovision.corp does not exist
[root@rhel6-client ~]# ssh sdainard@miovision@localhost
sdainard@miovision@localhost's password:
Permission denied, please try again.
/var/log/secure:
Feb 6 10:13:06 rhel6 sshd[2435]: pam_unix(sshd:auth): check pass; user
unknown
Feb 6 10:13:06 rhel6 sshd[2435]: pam_unix(sshd:auth): authentication
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=localhost
Feb 6 10:13:09 rhel6 sshd[2435]: pam_succeed_if(sshd:auth): error
retrieving information about user sdainard@miovision
Feb 6 10:13:10 rhel6 sshd[2435]: Failed password for invalid user
sdainard@miovision from ::1 port 47391 ssh2
Feb 6 10:13:20 rhel6 sshd[2436]: Connection closed by ::1
Feb 6 10:13:25 rhel6 sshd[2709]: Invalid user sdainard@miovision from
::1
Feb 6 10:13:25 rhel6 sshd[2710]: input_userauth_request: invalid user
sdainard@miovision
Feb 6 10:13:36 rhel6 sshd[2709]: pam_unix(sshd:auth): check pass; user
unknown
Feb 6 10:13:36 rhel6 sshd[2709]: pam_unix(sshd:auth): authentication
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=localhost
Feb 6 10:13:38 rhel6 sshd[2709]: pam_succeed_if(sshd:auth): error
retrieving information about user sdainard@miovision
Feb 6 10:13:40 rhel6 sshd[2709]: Failed password for invalid user
sdainard@miovision from ::1 port 47417 ssh2
Note that there are no logs from sssd above which means sssd never
consulted.
No logs for sssd;
# pwd
/var/log/sssd
[root@snapshot-test sssd]# ll
total 0
-rw---. 1 root root 0 Feb 5 17:38 krb5_child.log
-rw---. 1 root root 0 Feb 5 17:38 ldap_child.log
-rw---. 1 root root 0 Feb 5 17:37 sssd.log
-rw---. 1 root root 0 Feb 5 17:38 sssd_miolinux.corp.log
-rw---. 1 root root 0 Feb 5 17:38 sssd_nss.log
-rw---. 1 root root 0 Feb 5 17:38 sssd_pac.log
-rw---. 1 root root 0 Feb 5 17:38 sssd_pam.log
-rw---. 1 root root 0 Feb 5 17:38 sssd_ssh.log
sssd doesn't log if not asked. Each section of /etc/sssd/sssd.conf can
have debug_level = value
line. For more details see sssd.conf(5).
/etc/sssd/sssd.conf:
[domain/miolinux.corp]
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = miolinux.corp
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = rhel6-client.miolinux.corp
chpass_provider = ipa
ipa_server = _srv_, ipa1.miolinux.corp
ldap_tls_cacert = /etc/ipa/ca.crt
you are missing SSSD configuration for trusts:
subdomains_provider = ipa
[sssd]
services = nss, pam, ssh
and here also service 'pac' has to be referenced in the 'services = '
line
config_file_version = 2
domains = miolinux.corp
[nss]
[pam]
[sudo]
[autofs]
[ssh]
[pac]
Basically, situation should look like this:
1. IPA master server configured to talk to AD DC, by means of using
winbindd in
background (on RHEL 6.x, in current Fedora it is done by directly
talking to AD LDAP services by SSSD). SSSD on IPA master uses it to
resolve IDs for AD users
and groups. This requires special setup of SSSD on IPA master, with
[domain/...]
subdomains_provider = ipa
and
[sssd]
services = ..., pac
Server side looks right:
[domain/miolinux.corp]
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = miolinux.corp
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = ipa1.miolinux.corp
chpass_provider = ipa
ipa_server = ipa1.miolinux.corp
ldap_tls_cacert = /etc/ipa/ca.crt
subdomains_provider = ipa
[sssd]
services = nss, pam, ssh, pac
config_file_version = 2
domains = miolinux.corp
[nss]
[pam]
[sudo]
[autofs]
[ssh]
[pac]
In newer versions (FreeIPA 3.3+, SSSD 1.11+) this is done on IPA master
automatically by setting ipa_master_mode = True
On RHEL 6.x one needs to add the parameters manually.
2. /etc/krb5.conf has to contain auth_to_local rules that map AD
principals to lower-cased versions because some applications (SSH)
are very picky about user/principal name mapping. This has to be done
on both IPA masters and IPA clients.
This was done on the IPA server, but the RHEL 6.5 client doesn't have this
file.
On the IPA server:
[realms]
MIOLINUX.CORP = {
kdc = ipa1.miolinux.corp:88
master_kdc = ipa1.miolinux.corp:88
admin_server = ipa1.miolinux.corp:749
default_domain
Re: [Freeipa-users] Cross domain trust
On Thu, Feb 6, 2014 at 12:42 PM, Alexander Bokovoy aboko...@redhat.comwrote:
On Thu, 06 Feb 2014, Steve Dainard wrote:
In newer versions (FreeIPA 3.3+, SSSD 1.11+) this is done on IPA master
automatically by setting ipa_master_mode = True
On RHEL 6.x one needs to add the parameters manually.
2. /etc/krb5.conf has to contain auth_to_local rules that map AD
principals to lower-cased versions because some applications (SSH)
are very picky about user/principal name mapping. This has to be done
on both IPA masters and IPA clients.
This was done on the IPA server, but the RHEL 6.5 client doesn't have this
file.
On the IPA server:
[realms]
MIOLINUX.CORP = {
kdc = ipa1.miolinux.corp:88
master_kdc = ipa1.miolinux.corp:88
admin_server = ipa1.miolinux.corp:749
default_domain = miolinux.corp
pkinit_anchors = FILE:/etc/ipa/ca.crt
auth_to_local = RULE:[1:$1@$0](^.*@MIOVISION$)s/@MIOVISION/@miovision/
auth_to_local = DEFAULT
[root@ipa1 ~]# kinit sdain...@miovision.corp
Password for sdain...@miovision.corp:
kinit: KDC reply did not match expectations while getting initial
credentials
MIT Kerberos is case-sensitive for the realm, so it should always be
kinit sdain...@miovision.corp
make also sure that your rule above has proper realm. If your realm is
MIOVISION.CORP, then auth_to_local rule is
auth_to_local = RULE:[1:$1@$0](^.*@MIOVISION.CORP$)s/@MIOVISION.CORP/@
miovision.corp/
OK that makes sense. I wasn't sure if it was NETBIOS or not. Changed.
In MIT Kerberos 1.13 we'll have an interface that will allow SSSD to
automatically generate (and supply) these rules. Prior to that we have
to have explicit configuration on all clients and servers.
Excellent, do you work with whomever is maintaining the Ubuntu PPA on this
as well? One of our dev teams is exclusively on Ubuntu 12.04 and I've had
some serious issues with the joining clients from distro.
A CentOS 6.5 client has this file. The docs didn't mention the manual
client config, I just assumed the IPA server would proxy the request.
After
adding, no change.
A request to IPA server needs to come from a client and a client needs
to know about that. We changed SSSD 1.11+ to discover IPA capabilities
and self-configure but for older clients (1.9..1.10) you need to perform
it through explicit config.
With these changes SSSD on IPA client will recognize AD users and
request IPA master to perform name/SID/etc resolution, and also will
make an attempt to parse special part of the Kerberos ticket
generated by AD DC (MS-PAC) that contains signed cached copy of group
ownership for AD users.
SSSD needs restart after each config change.
You can do checks step by step to see whether things are working:
1. Ensure that SSSD on IPA master resolves AD user properly:
getent passwd user@ad.domain
Should return non-empty entry.
Returns no values.
[root@ipa1 ~]# getent passwd sdain...@miovision.corp
[root@ipa1 ~]#
Can you add debug_level=9 to [domain/...] section in
/etc/sssd/sssd.conf, restart sssd and try again?
In /var/log/sssd/sssd_domain.log there will be a lot of debug
information that I'd like to see (send it privately).
If sssd properly tries to talk to winbindd to resolve id, I'd like to
see winbind logs then:
# smbcontrol all debug 100
# getent passwd sdain...@miovision.corp
# smbcontrol all debug 1
and send me logs from /var/log/samba.
Done, sending logs outside of list.
There are some communications errors. I dropped the firewall on the IPA
server to test the last couple runs at 'getent passwd
sdain...@miovision.corp'.
2. Ensure that SSSD on IPA client resolves AD user properly:
getent passwd user@ad.domain
Should return non-empty entry.
[root@snapshot-test ~]# getent passwd sdain...@miovision.corp
[root@snapshot-test ~]#
Once we solve it for IPA master, we can continue with this part.
3. Ensure that Kerberos infrastructure works:
kinit user@ad.domain
kvno -S host ipa.client.domain
[root@ipa1 ~]# kinit sdain...@miovision.corp
Password for sdain...@miovision.corp:
kinit: KDC reply did not match expectations while getting initial
credentials
Expected (realm is case-sensitive).
[root@ipa1 ~]# kinit sdain...@miovision.corp
Password for sdain...@miovision.corp:
[root@ipa1 ~]# kvno cifs/dc1.miovision.c...@miovision.corp
cifs/dc1.miovision.c...@miovision.corp: kvno = 41
[root@ipa1 ~]# kvno -S host ipa1.miolinux.corp
host/ipa1.miolinux.c...@miolinux.corp: kvno = 2
[root@ipa1 ~]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: sdain...@miovision.corp
Valid starting ExpiresService principal
02/06/14 11:54:55 02/06/14 21:54:57 krbtgt/MIOVISION.CORP@
MIOVISION.CORP
renew until 02/07/14 11:54:55
02/06/14 11:55:38 02/06/14 21:54:57 cifs/dc1.miovision.corp@
MIOVISION.CORP
renew until 02/07/14 11:54:55
02/06/14 11:56:50 02/06/14 21:54:57
Re: [Freeipa-users] ipa-server-install fails (RHEL 6.5)
: no entries set up under cn=computers, cn=compat,dc=miovision,dc=linux [04/Feb/2014:15:44:52 -0500] schema-compat-plugin - warning: no entries set up under cn=ng, cn=compat,dc=miovision,dc=linux [04/Feb/2014:15:44:52 -0500] schema-compat-plugin - warning: no entries set up under ou=sudoers,dc=miovision,dc=linux [04/Feb/2014:15:44:52 -0500] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=miovision,dc=linux--no CoS Templates found, which should be added before the CoS Definition. [04/Feb/2014:15:44:52 -0500] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=miovision,dc=linux--no CoS Templates found, which should be added before the CoS Definition. [04/Feb/2014:15:44:53 -0500] - slapd started. Listening on All Interfaces port 389 for LDAP requests [04/Feb/2014:15:44:53 -0500] - Listening on All Interfaces port 636 for LDAPS requests [04/Feb/2014:15:44:53 -0500] - Listening on /var/run/slapd-MIOVISION-LINUX.socket for LDAPI requests [04/Feb/2014:15:44:53 -0500] - The change of nsslapd-maxdescriptors will not take effect until the server is restarted [05/Feb/2014:09:51:59 -0500] - slapd shutting down - signaling operation threads [05/Feb/2014:09:51:59 -0500] - slapd shutting down - waiting for 26 threads to terminate [05/Feb/2014:09:52:00 -0500] - slapd shutting down - closing down internal subsystems and plugins [05/Feb/2014:09:52:00 -0500] - Waiting for 4 database threads to stop [05/Feb/2014:09:52:00 -0500] - All database threads now stopped [05/Feb/2014:09:52:00 -0500] - slapd stopped. Thanks, *Steve Dainard * IT Infrastructure Manager Miovision http://miovision.com/ | *Rethink Traffic* 519-513-2407 ex.250 877-646-8476 (toll-free) *Blog http://miovision.com/blog | **LinkedIn https://www.linkedin.com/company/miovision-technologies | Twitter https://twitter.com/miovision | Facebook https://www.facebook.com/miovision* -- Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, ON, Canada | N2C 1L3 This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. On Wed, Feb 5, 2014 at 11:50 AM, Rob Crittenden rcrit...@redhat.com wrote: Steve Dainard wrote: Following this guide: https://access.redhat.com/site/documentation/en-US/Red_ Hat_Enterprise_Linux/6/html/Identity_Management_Guide/ trust-diff-dns-domains.html STEP 4: ipa-server-install --setup-dns -p 'password' -a 'password' -r MIOVISION.LINUX -n miovision.linux --hostname ipa1.miovision.linux --forwarder=10.0.0.2 --forwarder=10.0.0.5 Server host name [ipa1.miovision.linux]: Warning: skipping DNS resolution of host ipa1.miovision.linux Unable to resolve IP address for host name Please provide the IP address to be used for this host name: 10.0.6.3 Adding [10.0.6.3 ipa1.miovision.linux] to your /etc/hosts file Do you want to configure the reverse zone? [yes]: Please specify the reverse zone name [6.0.10.in-addr.arpa.]: Using reverse zone 6.0.10.in-addr.arpa. The IPA Master Server will be configured with: Hostname: ipa1.miovision.linux IP address:10.0.6.3 Domain name: miovision.linux Realm name:MIOVISION.LINUX BIND DNS server will be configured to serve IPA domain with: Forwarders:10.0.0.2, 10.0.0.5 Reverse zone: 6.0.10.in-addr.arpa. Continue to configure the system with these values? [no]: yes The following operations may take some minutes to complete. Please wait until the prompt is returned. Configuring NTP daemon (ntpd) [1/4]: stopping ntpd ... Done configuring directory server (dirsrv). Configuring Kerberos KDC (krb5kdc): Estimated time 30 seconds [1/10]: adding sasl mappings to the directory [2/10]: adding kerberos container to the directory [3/10]: configuring KDC [4/10]: initialize kerberos container Failed to initialize the realm container [5/10]: adding default ACIs [6/10]: creating a keytab for the directory Unexpected error - see /var/log/ipaserver-install.log for details: CalledProcessError: Command 'kadmin.local -q addprinc -randkey ldap/ipa1.miovision.linux@MIOVISION.LINUX -x ipa-setup-override-restrictions' returned non-zero exit status 1 */var/log/ipaserver-install.log* add aci: (target=ldap:///cn=*,cn=ca_renewal,cn=ipa,cn=etc,dc= miovision,dc=linux)(targetattr=userCertificate)(version 3.0; acl Modify CA Certificates for renewals; allow(write) userdn = ldap:///fqdn=ipa1.miovision.linux,cn=computers,cn= accounts,dc=miovision,dc=linux;) modifying entry cn=ipa,cn=etc,dc=miovision,dc=linux modify complete 2014-02-04T20:45:51Z DEBUG stderr=ldap_initialize( ldapi://%2Fvar%2Frun%2Fslapd-MIOVISION-LINUX.socket/??base ) 2014-02-04T20:45:51Z DEBUG duration: 6 seconds 2014-02-04T20:45:51Z DEBUG [6/10]: creating a keytab for the directory 2014-02-04T20:45:51Z DEBUG args=kadmin.local -q addprinc -randkey ldap/ipa1.miovision.linux@MIOVISION.LINUX -x ipa
[Freeipa-users] Cross domain trust
After the initial setup of a trust I'm attempting to get kerberos tickets against the AD domain. Step 12 in this document: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/trust-diff-dns-domains.htmlsays: Then, request service tickets for services within the Active Directory domain. [root@ipaserver ]# kvno cifs/adserver.adexample.com@AD.DOMAIN If the Active Directory service ticket is succcessfully granted, then there will be a cross-realm TGT listed with all of the other requested tickets. This will have the name krbtgt/AD.DOMAIN@IPA.DOMAIN. I get an error back: # kvno cifs/dc1.miovision.c...@miovision.corp kvno: Server not found in Kerberos database while getting credentials for cifs/dc1.miovision.c...@miovision.corp But I do have a krbtgt ticket/AD domain: # klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: sdainard-r...@miolinux.corp Valid starting ExpiresService principal 02/05/14 14:21:06 02/06/14 14:21:06 krbtgt/miolinux.c...@miolinux.corp 02/05/14 14:21:17 02/06/14 14:21:06 host/ipa1.miolinux.c...@miolinux.corp 02/05/14 14:21:20 02/06/14 14:21:06 krbtgt/miovision.c...@miolinux.corp Also, is it normal to not find the Linux realm listed in the domain trust list on the AD DC? *Steve Dainard * IT Infrastructure Manager Miovision http://miovision.com/ | *Rethink Traffic* 519-513-2407 ex.250 877-646-8476 (toll-free) *Blog http://miovision.com/blog | **LinkedIn https://www.linkedin.com/company/miovision-technologies | Twitter https://twitter.com/miovision | Facebook https://www.facebook.com/miovision* -- Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, ON, Canada | N2C 1L3 This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa AD trust issue
https://bugzilla.redhat.com/show_bug.cgi?id=1061897 *Steve Dainard * IT Infrastructure Manager Miovision http://miovision.com/ | *Rethink Traffic* 519-513-2407 ex.250 877-646-8476 (toll-free) *Blog http://miovision.com/blog | **LinkedIn https://www.linkedin.com/company/miovision-technologies | Twitter https://twitter.com/miovision | Facebook https://www.facebook.com/miovision* -- Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, ON, Canada | N2C 1L3 This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. On Wed, Feb 5, 2014 at 12:34 PM, Dmitri Pal d...@redhat.com wrote: On 02/04/2014 03:28 PM, Steve Dainard wrote: has anyone worked it out. Secondly cifs-utils has dependency on samba3 packages and ipa-ad-trust needs samba4 but samba3 and samba4 don't like each other , so this is the story of my experience with ipa. Any suggestions ? Why do you need cifs-utils on the same server? cifs-utils to make a system a client to MSFT file server, AFAIU you cant make IPA server to be a cifs client. https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/trust-diff-dns-domains.html Step 3 mentions that cifs-utils is required, but: yum install cifs-utils Loaded plugins: product-id, security, subscription-manager This system is receiving updates from Red Hat Subscription Management. rhel-6-server-cf-tools-1-rpms | 2.8 kB 00:00 rhel-6-server-rhev-agent-rpms | 3.1 kB 00:00 rhel-6-server-rpms| 3.7 kB 00:00 Setting up Install Process Resolving Dependencies -- Running transaction check --- Package cifs-utils.x86_64 0:4.8.1-19.el6 will be installed -- Processing Dependency: libwbclient.so.0()(64bit) for package: cifs-utils-4.8.1-19.el6.x86_64 -- Running transaction check --- Package samba-winbind-clients.x86_64 0:3.6.9-167.el6_5 will be installed -- Processing Dependency: samba-winbind = 3.6.9-167.el6_5 for package: samba-winbind-clients-3.6.9-167.el6_5.x86_64 -- Running transaction check --- Package samba-winbind.x86_64 0:3.6.9-167.el6_5 will be installed -- Processing Dependency: samba-common = 3.6.9-167.el6_5 for package: samba-winbind-3.6.9-167.el6_5.x86_64 -- Running transaction check --- Package samba-common.x86_64 0:3.6.9-167.el6_5 will be installed -- Processing Conflict: samba4-common-4.0.0-60.el6_5.rc4.x86_64 conflicts samba-common 3.9.9 -- Processing Conflict: samba4-winbind-4.0.0-60.el6_5.rc4.x86_64 conflicts samba-winbind 3.9.9 -- Processing Conflict: samba4-winbind-clients-4.0.0-60.el6_5.rc4.x86_64 conflicts samba-winbind-clients 3.9.9 -- Finished Dependency Resolution Error: samba4-common conflicts with samba-common-3.6.9-167.el6_5.x86_64 Error: samba4-winbind-clients conflicts with samba-winbind-clients-3.6.9-167.el6_5.x86_64 Error: samba4-winbind conflicts with samba-winbind-3.6.9-167.el6_5.x86_64 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest Is this no longer a requirement? Can this documentation be updated? Steve Can you please file a BZ? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs?www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Cross domain trust
I didn't have the firewall on my IPA server down while forming the trust. All seems to be working now. Thanks for your help. Steve -- / Alexander Bokovoy ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa AD trust issue
has anyone worked it out. Secondly cifs-utils has dependency on samba3 packages and ipa-ad-trust needs samba4 but samba3 and samba4 don't like each other , so this is the story of my experience with ipa. Any suggestions ? Why do you need cifs-utils on the same server? cifs-utils to make a system a client to MSFT file server, AFAIU you cant make IPA server to be a cifs client. https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/trust-diff-dns-domains.html Step 3 mentions that cifs-utils is required, but: yum install cifs-utils Loaded plugins: product-id, security, subscription-manager This system is receiving updates from Red Hat Subscription Management. rhel-6-server-cf-tools-1-rpms | 2.8 kB 00:00 rhel-6-server-rhev-agent-rpms | 3.1 kB 00:00 rhel-6-server-rpms| 3.7 kB 00:00 Setting up Install Process Resolving Dependencies -- Running transaction check --- Package cifs-utils.x86_64 0:4.8.1-19.el6 will be installed -- Processing Dependency: libwbclient.so.0()(64bit) for package: cifs-utils-4.8.1-19.el6.x86_64 -- Running transaction check --- Package samba-winbind-clients.x86_64 0:3.6.9-167.el6_5 will be installed -- Processing Dependency: samba-winbind = 3.6.9-167.el6_5 for package: samba-winbind-clients-3.6.9-167.el6_5.x86_64 -- Running transaction check --- Package samba-winbind.x86_64 0:3.6.9-167.el6_5 will be installed -- Processing Dependency: samba-common = 3.6.9-167.el6_5 for package: samba-winbind-3.6.9-167.el6_5.x86_64 -- Running transaction check --- Package samba-common.x86_64 0:3.6.9-167.el6_5 will be installed -- Processing Conflict: samba4-common-4.0.0-60.el6_5.rc4.x86_64 conflicts samba-common 3.9.9 -- Processing Conflict: samba4-winbind-4.0.0-60.el6_5.rc4.x86_64 conflicts samba-winbind 3.9.9 -- Processing Conflict: samba4-winbind-clients-4.0.0-60.el6_5.rc4.x86_64 conflicts samba-winbind-clients 3.9.9 -- Finished Dependency Resolution Error: samba4-common conflicts with samba-common-3.6.9-167.el6_5.x86_64 Error: samba4-winbind-clients conflicts with samba-winbind-clients-3.6.9-167.el6_5.x86_64 Error: samba4-winbind conflicts with samba-winbind-3.6.9-167.el6_5.x86_64 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest Is this no longer a requirement? Can this documentation be updated? Steve ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] ipa-server-install fails (RHEL 6.5)
Following this guide: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/trust-diff-dns-domains.html STEP 4: ipa-server-install --setup-dns -p 'password' -a 'password' -r MIOVISION.LINUX -n miovision.linux --hostname ipa1.miovision.linux --forwarder=10.0.0.2 --forwarder=10.0.0.5 Server host name [ipa1.miovision.linux]: Warning: skipping DNS resolution of host ipa1.miovision.linux Unable to resolve IP address for host name Please provide the IP address to be used for this host name: 10.0.6.3 Adding [10.0.6.3 ipa1.miovision.linux] to your /etc/hosts file Do you want to configure the reverse zone? [yes]: Please specify the reverse zone name [6.0.10.in-addr.arpa.]: Using reverse zone 6.0.10.in-addr.arpa. The IPA Master Server will be configured with: Hostname: ipa1.miovision.linux IP address:10.0.6.3 Domain name: miovision.linux Realm name:MIOVISION.LINUX BIND DNS server will be configured to serve IPA domain with: Forwarders:10.0.0.2, 10.0.0.5 Reverse zone: 6.0.10.in-addr.arpa. Continue to configure the system with these values? [no]: yes The following operations may take some minutes to complete. Please wait until the prompt is returned. Configuring NTP daemon (ntpd) [1/4]: stopping ntpd ... Done configuring directory server (dirsrv). Configuring Kerberos KDC (krb5kdc): Estimated time 30 seconds [1/10]: adding sasl mappings to the directory [2/10]: adding kerberos container to the directory [3/10]: configuring KDC [4/10]: initialize kerberos container Failed to initialize the realm container [5/10]: adding default ACIs [6/10]: creating a keytab for the directory Unexpected error - see /var/log/ipaserver-install.log for details: CalledProcessError: Command 'kadmin.local -q addprinc -randkey ldap/ipa1.miovision.linux@MIOVISION.LINUX -x ipa-setup-override-restrictions' returned non-zero exit status 1 */var/log/ipaserver-install.log* add aci: (target=ldap:///cn=*,cn=ca_renewal,cn=ipa,cn=etc,dc=miovision,dc=linux;)(targetattr=userCertificate)(version 3.0; acl Modify CA Certificates for renewals; allow(write) userdn = ldap:///fqdn=ipa1.miovision.linux,cn=computers,cn=accounts,dc=miovision,dc=linux;;) modifying entry cn=ipa,cn=etc,dc=miovision,dc=linux modify complete 2014-02-04T20:45:51Z DEBUG stderr=ldap_initialize( ldapi://%2Fvar%2Frun%2Fslapd-MIOVISION-LINUX.socket/??base ) 2014-02-04T20:45:51Z DEBUG duration: 6 seconds 2014-02-04T20:45:51Z DEBUG [6/10]: creating a keytab for the directory 2014-02-04T20:45:51Z DEBUG args=kadmin.local -q addprinc -randkey ldap/ipa1.miovision.linux@MIOVISION.LINUX -x ipa-setup-override-restrictions 2014-02-04T20:45:51Z DEBUG stdout=Authenticating as principal root/admin@MIOVISION.LINUX with password. 2014-02-04T20:45:51Z DEBUG stderr=kadmin.local: No such entry in the database while initializing kadmin.local interface 2014-02-04T20:45:51Z INFO File /usr/lib/python2.6/site-packages/ipaserver/install/installutils.py, line 614, in run_script return_value = main_function() File /usr/sbin/ipa-server-install, line 1024, in main subject_base=options.subject) File /usr/lib/python2.6/site-packages/ipaserver/install/krbinstance.py, line 183, in create_instance self.start_creation(runtime=30) File /usr/lib/python2.6/site-packages/ipaserver/install/service.py, line 358, in start_creation method() File /usr/lib/python2.6/site-packages/ipaserver/install/krbinstance.py, line 386, in __create_ds_keytab installutils.kadmin_addprinc(ldap_principal) File /usr/lib/python2.6/site-packages/ipaserver/install/installutils.py, line 369, in kadmin_addprinc kadmin(addprinc -randkey + principal) File /usr/lib/python2.6/site-packages/ipaserver/install/installutils.py, line 366, in kadmin -x, ipa-setup-override-restrictions]) File /usr/lib/python2.6/site-packages/ipapython/ipautil.py, line 316, in run raise CalledProcessError(p.returncode, args) 2014-02-04T20:45:51Z INFO The ipa-server-install command failed, exception: CalledProcessError: Command 'kadmin.local -q addprinc -randkey ldap/ipa1.miovision.linux@MIOVISION.LINUX -x ipa-setup-override-restrictions' returned non-zero exit status 1 *Steve Dainard * IT Infrastructure Manager Miovision http://miovision.com/ | *Rethink Traffic* 519-513-2407 ex.250 877-646-8476 (toll-free) *Blog http://miovision.com/blog | **LinkedIn https://www.linkedin.com/company/miovision-technologies | Twitter https://twitter.com/miovision | Facebook https://www.facebook.com/miovision* -- Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, ON, Canada | N2C 1L3 This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. ___ Freeipa-users mailing list Freeipa-users@redhat.com https
[Freeipa-users] FreeIPA password sync one direction only (Windows DC - IPA)
Hello, We're running a single IPA server (CentOS 6) on our network as a side project for some testing before we implement. It had been a significant period of time since I had last logged into the web interface, so I had to kinit from a client machine (of which I had logged into successfully with my domain password), at which point I was requested to change my password. After the password change I RDP'd into a Windows machine on our domain and realized the password had not been updated on the domain controller. Is the password sync feature with an external source such as Active Directory supposed to be two-way? If so where can I start troubleshooting this issue? Thanks, Steve Dainard Infrastructure Manager Miovision Technologies Inc. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] FreeIPA password sync one direction only (Windows DC - IPA)
for database /var/lib/dirsrv/slapd-MIOVISION-LINUX/cldb/854fd282-193811e2-9177aa0d-17c9983f_508020360003.db4 [17/May/2013:13:53:48 -0400] NSMMReplicationPlugin - ruv_update_ruv: successfully committed csn 51966eac00020003 [17/May/2013:13:53:48 -0400] NSMMReplicationPlugin - agmt=cn=meTodc1.miovision.corp (dc1:389): State: backoff - backoff Perhaps whatever is causing the sync error with user jkeller is holding up the queued transactions? Steve Dainard Infrastructure Manager Miovision Technologies Inc. On Fri, May 17, 2013 at 11:39 AM, Rich Megginson rmegg...@redhat.comwrote: On 05/17/2013 09:26 AM, Steve Dainard wrote: Hello, We're running a single IPA server (CentOS 6) on our network as a side project for some testing before we implement. It had been a significant period of time since I had last logged into the web interface, so I had to kinit from a client machine (of which I had logged into successfully with my domain password), at which point I was requested to change my password. After the password change I RDP'd into a Windows machine on our domain and realized the password had not been updated on the domain controller. Is the password sync feature with an external source such as Active Directory supposed to be two-way? If so where can I start troubleshooting this issue? Are you talking about a windows sync agreement you set up with ipa-replica-manage? If so, yes, the password sync is supposed to be two-way. Try this: turn on the replication log level http://port389.org/wiki/FAQ#Troubleshooting change your IPA password turn off the replication log level http://port389.org/wiki/FAQ#Troubleshooting see if you can use your new password in AD The 389 errors log in /var/log/dirsrv/slapd-YOUR-DOMAIN/errors may contain a clue. Thanks, Steve Dainard Infrastructure Manager Miovision Technologies Inc. ___ Freeipa-users mailing listFreeipa-users@redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
