From dpal at redhat.com Mon Sep 1 05:50:39 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 01 Sep 2014 07:50:39 +0200 Subject: [Freeipa-users] FreeIPA bind also-notify behavior. In-Reply-To: References: Message-ID: <5404092F.2090604@redhat.com> On 08/29/2014 09:32 PM, Matthew Sellers wrote: > Hi Everyone! > > I am using FreeIPA 3.3.5 on Fedora 20 and attempting to configure > FreeIPA to send notifies to non-IPA slaves, but it seems broken on IPA > ( notify packets are never sent to to slaves ). > > I have configured also-notify { nameserverip; }; in named.conf on my > FreeIPA test host in the options section and watched for notify > traffic with tcpdump. > > This document suggests that this is supported, and this is something I > have used in non-IPA bind servers with no issues. > > https://fedoraproject.org/wiki/QA:Testcase_freeipav3_dns_zone_transfer > > I wanted to ask the list before I file a bug with more details. Is > anyone using this bind feature on IPA with any success? > > Thanks! > Matt > > The DNS level change propagation is not supported between IPA replicas instead it uses LDAP replication to propagate the changes. If you want another non IPA DNS server to be a slave then you can do it. See http://www.freeipa.org/page/V3/DNS_SOA_serial_auto-incrementation for more information. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Mon Sep 1 06:07:30 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 1 Sep 2014 08:07:30 +0200 Subject: [Freeipa-users] IPuser can't authenticated with sssd In-Reply-To: <5400C0DC.5050306@redhat.com> References: <1406493413.17348.YahooMailNeo@web161504.mail.bf1.yahoo.com> <1409328408.25274.YahooMailNeo@web161505.mail.bf1.yahoo.com> <5400C0DC.5050306@redhat.com> Message-ID: <20140901060730.GE3139@hendrix.brq.redhat.com> On Fri, Aug 29, 2014 at 08:05:16PM +0200, Dmitri Pal wrote: > On 08/29/2014 06:06 PM, mohammad sereshki wrote: > >Hi > >I have configured IPA(ipa-client-2.1.3-7.el5) but the problem is that Ican > >connect with kerberos from another client but I can't login to client > >directly and I chet below error > > pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh > >ruser= rhost=192.168.211.166 user= > > > >Please help me if you can ,I'm under pressure to fix it :( > > > > > >my os is centos 5.8 and kernel is ^^^^^^^^^^ very old, you should also upgrade > > 2.6.18-348.16.1 > > > > > > Put debug_level=6 or higher into sssd.conf into your pam, nss and domain > sections, restart sssd and send us the sanitized logs of your login try. > Also sssd.conf and pam.conf as well as ssh configuration would be helpful. > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project From baghery.jone at gmail.com Mon Sep 1 06:29:15 2014 From: baghery.jone at gmail.com (alireza baghery) Date: Mon, 1 Sep 2014 10:59:15 +0430 Subject: [Freeipa-users] log activity users ipa Message-ID: hi i have configured ipa (ipa on centos 6.5) but the problesm is i dont know where the logs activity users stored? i meens logs activity users must stored in ipa server, but where? thanks every body -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Mon Sep 1 06:42:26 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 01 Sep 2014 08:42:26 +0200 Subject: [Freeipa-users] log activity users ipa In-Reply-To: References: Message-ID: <54041552.8080807@redhat.com> On 09/01/2014 08:29 AM, alireza baghery wrote: > hi > i have configured ipa (ipa on centos 6.5) but the problesm is i dont > know where the logs activity users stored? > i meens logs activity users must stored in ipa server, but where? > thanks every body > > > Which activity you are looking for? The administrating activity will be stored in the apache httpd logs, authentication activity will be stored in Kerberos logs, DS binds and changes will be stored in the DS logs, etc.. There is no consolidated logging yet. There are plans to normalize components to start logging into journald but this will take some time to materialize. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tevfik.ceydeliler at astron.yasar.com.tr Mon Sep 1 06:59:47 2014 From: tevfik.ceydeliler at astron.yasar.com.tr (Tevfik Ceydeliler) Date: Mon, 1 Sep 2014 09:59:47 +0300 Subject: [Freeipa-users] How to use sudo rules on ubuntu In-Reply-To: <20140829131445.GD3139@hendrix.brq.redhat.com> References: <53FF0F5F.5000904@astron.yasar.com.tr> <20140828112034.GA3139@hendrix.brq.redhat.com> <53FF183F.9050801@astron.yasar.com.tr> <20140828142103.GD3139@hendrix.brq.redhat.com> <54001E1F.1090304@astron.yasar.com.tr> <20140829082719.GS3139@hendrix.brq.redhat.com> <540052C0.2000202@astron.yasar.com.tr> <20140829112330.GA3139@hendrix.brq.redhat.com> <540075F2.8010906@astron.yasar.com.tr> <20140829130708.GC3139@hendrix.brq.redhat.com> <20140829131445.GD3139@hendrix.brq.redhat.com> Message-ID: <54041963.1090402@astron.yasar.com.tr> Hi sssd_sudo.log is attached But there is no log about sssd_domain_name.log (In my case sssd_ipa.grp.log) On 29-08-2014 16:14, Jakub Hrozek wrote: > On Fri, Aug 29, 2014 at 03:07:08PM +0200, Jakub Hrozek wrote: >> On Fri, Aug 29, 2014 at 03:45:38PM +0300, Tevfik Ceydeliler wrote: >>> this package is installed >>> >>> root at clnt:/home/awtadm# apt-get install libsss-sudo >>> Reading package lists... Done >>> Building dependency tree >>> Reading state information... Done >>> libsss-sudo is already the newest version. >>> libsss-sudo set to manually installed. >>> 0 upgraded, 0 newly installed, 0 to remove and 15 not upgraded. >>> >>> sssd_sudo and sssd_domain logs are empty under /var/log/sssd >> You need to put debug_level=N into the [sssd] and [domain] sections, > Sorry I meant to say [sudo] and [domain] sections. > >> restart sssd, then you'll have some logs. We only log critical failures >> by default. >> >> 6 is a good start for the log level usually. >> >>> On 29-08-2014 14:23, Jakub Hrozek wrote: >>>> On Fri, Aug 29, 2014 at 01:15:28PM +0300, Tevfik Ceydeliler wrote: >>>>> I moved these configuration lines under [domain] section. Then reboot the >>>>> client. But same result.. >>>> Please make sure libsss_sudo is installed. If it is, then we need to see >>>> the logs from the [sudo] and [domain] sections of sssd.conf >>> -- >>> >>> >>>
>>> >>>

>>> Bu elektronik postada bulunan tum fikir ve gorusler ve ekindeki dosyalar sadece adres sahip/sahiplerine ait olup, Yasar Toplulugu Sirketleri bu mesajin icerigi ile ilgili olarak hic bir hukuksal sorumlulugu kabul etmez. Eger gonderilmesi dusunulen kisi veya kurulus degilseniz, lutfen gonderen kisiyi derhal haberdar ediniz ve mesaji sisteminizden siliniz.The information contained in this e-mail and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and Yasar Group Companies do not accept legal responsibility for the contents. If you are not the intended recipient, please immediately notify the sender and delete it from your system. >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go Tohttp://freeipa.org for more info on the project --


Bu elektronik postada bulunan tum fikir ve gorusler ve ekindeki dosyalar sadece adres sahip/sahiplerine ait olup, Yasar Toplulugu Sirketleri bu mesajin icerigi ile ilgili olarak hic bir hukuksal sorumlulugu kabul etmez. Eger gonderilmesi dusunulen kisi veya kurulus degilseniz, lutfen gonderen kisiyi derhal haberdar ediniz ve mesaji sisteminizden siliniz.The information contained in this e-mail and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and Yasar Group Companies do not accept legal responsibility for the contents. If you are not the intended recipient, please immediately notify the sender and delete it from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 15216 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sssd_sudo.log Type: text/x-log Size: 3929 bytes Desc: not available URL: From tevfik.ceydeliler at astron.yasar.com.tr Mon Sep 1 06:59:52 2014 From: tevfik.ceydeliler at astron.yasar.com.tr (Tevfik Ceydeliler) Date: Mon, 1 Sep 2014 09:59:52 +0300 Subject: [Freeipa-users] How to use sudo rules on ubuntu In-Reply-To: <20140829145354.GB11446@mail.corp.redhat.com> References: <53FF0F5F.5000904@astron.yasar.com.tr> <20140829134442.GA11446@mail.corp.redhat.com> <54009012.10903@astron.yasar.com.tr> <20140829145354.GB11446@mail.corp.redhat.com> Message-ID: <54041968.1000908@astron.yasar.com.tr> Client side: sssd --> 1.11.5 sudo --> 1.8.9p5-1ubuntu1 (sudo-ldap package conflicts) OS --> Ubuntu 14.04.1 LTS On 29-08-2014 17:53, Lukas Slebodnik wrote: > On (29/08/14 17:37), Tevfik Ceydeliler wrote: >> Thnx for document. I know this. >> I think there is no problem abot configuration generally. Maybe some nish >> details. >> Problem is why dont work in my test env. >> > Could you write more details about version of sssd, sudo? > Which ubuntu release do you use? > ... > > LS --


Bu elektronik postada bulunan tum fikir ve gorusler ve ekindeki dosyalar sadece adres sahip/sahiplerine ait olup, Yasar Toplulugu Sirketleri bu mesajin icerigi ile ilgili olarak hic bir hukuksal sorumlulugu kabul etmez. Eger gonderilmesi dusunulen kisi veya kurulus degilseniz, lutfen gonderen kisiyi derhal haberdar ediniz ve mesaji sisteminizden siliniz.The information contained in this e-mail and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and Yasar Group Companies do not accept legal responsibility for the contents. If you are not the intended recipient, please immediately notify the sender and delete it from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 15216 bytes Desc: not available URL: From baghery.jone at gmail.com Mon Sep 1 07:08:47 2014 From: baghery.jone at gmail.com (alireza baghery) Date: Mon, 1 Sep 2014 11:38:47 +0430 Subject: [Freeipa-users] log activity users ipa In-Reply-To: <54041552.8080807@redhat.com> References: <54041552.8080807@redhat.com> Message-ID: activity that users perform on client (ipa client) On Mon, Sep 1, 2014 at 11:12 AM, Dmitri Pal wrote: > On 09/01/2014 08:29 AM, alireza baghery wrote: > > hi > i have configured ipa (ipa on centos 6.5) but the problesm is i dont know > where the logs activity users stored? > i meens logs activity users must stored in ipa server, but where? > thanks every body > > > > Which activity you are looking for? > The administrating activity will be stored in the apache httpd logs, > authentication activity will be stored in Kerberos logs, DS binds and > changes will be stored in the DS logs, etc.. There is no consolidated > logging yet. There are plans to normalize components to start logging into > journald but this will take some time to materialize. > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lslebodn at redhat.com Mon Sep 1 07:12:18 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Mon, 1 Sep 2014 09:12:18 +0200 Subject: [Freeipa-users] How to use sudo rules on ubuntu In-Reply-To: <54041968.1000908@astron.yasar.com.tr> References: <53FF0F5F.5000904@astron.yasar.com.tr> <20140829134442.GA11446@mail.corp.redhat.com> <54009012.10903@astron.yasar.com.tr> <20140829145354.GB11446@mail.corp.redhat.com> <54041968.1000908@astron.yasar.com.tr> Message-ID: <20140901071217.GC8008@mail.corp.redhat.com> On (01/09/14 09:59), Tevfik Ceydeliler wrote: > >Client side: >sssd --> 1.11.5 >sudo --> 1.8.9p5-1ubuntu1 (sudo-ldap package conflicts) Thats good. The package sudo-ldap is not compiled with sssd support. >OS --> Ubuntu 14.04.1 LTS Do you have installed package libsss-sudo. Could you show us your sssd.conf file? BTW: Instructions for confugurations sudo with the SSSD back end are in man page sssd-sudo. LS From dpal at redhat.com Mon Sep 1 08:21:46 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 01 Sep 2014 10:21:46 +0200 Subject: [Freeipa-users] log activity users ipa In-Reply-To: References: <54041552.8080807@redhat.com> Message-ID: <54042C9A.8060303@redhat.com> On 09/01/2014 09:08 AM, alireza baghery wrote: > activity that users perform on client (ipa client) There are several parts: 1) Authentication. If the authentication happens using kerberos which is the default ipa-client configuration then you will see the authentication attempts in the KDC logs on the server. If the system is offline and you enabled offline authentication the authentication will happen on the client side without contacting the server so the sssd logs will reflect this activity. 2) Identity lookups are trickier. SSSD will fetch and cache information about different identity objects and serve and refresh them following different configuration rules and timeouts. So SSSD logs will give you the full picture of the local activity. 3) SUDO - look at the sudo logs on the client as the client just fetches data to make a policy decision but the actual decision is made on the client based on what the user wants to do and what central policies say about it. 4) If you want to capture what the user is actually typing you need to use something like a keystroke logger. Then you would know what the user actually did. To get then a consolidated and correlated picture you need to aggregate logs from different systems and process them. There are good open source solutions like Logstash or commertial like Splunk to process logs centrally. HTH Thanks Dmitri > > > On Mon, Sep 1, 2014 at 11:12 AM, Dmitri Pal > wrote: > > On 09/01/2014 08:29 AM, alireza baghery wrote: >> hi >> i have configured ipa (ipa on centos 6.5) but the problesm is i >> dont know where the logs activity users stored? >> i meens logs activity users must stored in ipa server, but where? >> thanks every body >> >> >> > Which activity you are looking for? > The administrating activity will be stored in the apache httpd > logs, authentication activity will be stored in Kerberos logs, DS > binds and changes will be stored in the DS logs, etc.. There is no > consolidated logging yet. There are plans to normalize components > to start logging into journald but this will take some time to > materialize. > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tevfik.ceydeliler at astron.yasar.com.tr Mon Sep 1 08:58:22 2014 From: tevfik.ceydeliler at astron.yasar.com.tr (Tevfik Ceydeliler) Date: Mon, 1 Sep 2014 11:58:22 +0300 Subject: [Freeipa-users] How to use sudo rules on ubuntu In-Reply-To: <20140901071217.GC8008@mail.corp.redhat.com> References: <53FF0F5F.5000904@astron.yasar.com.tr> <20140829134442.GA11446@mail.corp.redhat.com> <54009012.10903@astron.yasar.com.tr> <20140829145354.GB11446@mail.corp.redhat.com> <54041968.1000908@astron.yasar.com.tr> <20140901071217.GC8008@mail.corp.redhat.com> Message-ID: <5404352E.4060906@astron.yasar.com.tr> libsss-sudo already installed. Here is my sssd.conf: [domain/ipa.grp] krb5_realm = IPA.GRP cache_credentials = True krb5_store_password_if_offline = True ipa_domain = ipa.grp id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = clnt.ipa.grp chpass_provider = ipa ipa_dyndns_update = True ipa_server = _srv_, srv.ipa.grp ldap_tls_cacert = /etc/ipa/ca.crt [sssd] services = nss, pam, ssh, sudo config_file_version = 2 domains = ipa.grp ldap_sudo_search_base = ou=sudoers,ou=ipa,dc=grp ldap_sasl_mech = GSSAPI ldap=sasl_authid = host/cnlt2.ipa.grp ldap_sasl_realm = IPA.GRP ldap_netgroup_search_base = ou=SUDOers,dc=ipa,dc=grp sudo_provider = ldap ldap_uri = ldap://srv.ipa.grp krb5_server = srv.ipa.grp debulg_level = 6 [nss] homedir_substring = /home [pam] [sudo] debug_level = 6 [autofs] [ssh] [pac On 01-09-2014 10:12, Lukas Slebodnik wrote: > On (01/09/14 09:59), Tevfik Ceydeliler wrote: >> Client side: >> sssd --> 1.11.5 >> sudo --> 1.8.9p5-1ubuntu1 (sudo-ldap package conflicts) > Thats good. The package sudo-ldap is not compiled with sssd support. > >> OS --> Ubuntu 14.04.1 LTS > Do you have installed package libsss-sudo. > > Could you show us your sssd.conf file? > > BTW: Instructions for confugurations sudo with the SSSD back end > are in man page sssd-sudo. > > LS --


Bu elektronik postada bulunan tum fikir ve gorusler ve ekindeki dosyalar sadece adres sahip/sahiplerine ait olup, Yasar Toplulugu Sirketleri bu mesajin icerigi ile ilgili olarak hic bir hukuksal sorumlulugu kabul etmez. Eger gonderilmesi dusunulen kisi veya kurulus degilseniz, lutfen gonderen kisiyi derhal haberdar ediniz ve mesaji sisteminizden siliniz.The information contained in this e-mail and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and Yasar Group Companies do not accept legal responsibility for the contents. If you are not the intended recipient, please immediately notify the sender and delete it from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.png Type: image/png Size: 15216 bytes Desc: not available URL: From abokovoy at redhat.com Mon Sep 1 09:20:21 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 1 Sep 2014 12:20:21 +0300 Subject: [Freeipa-users] How to use sudo rules on ubuntu In-Reply-To: <5404352E.4060906@astron.yasar.com.tr> References: <53FF0F5F.5000904@astron.yasar.com.tr> <20140829134442.GA11446@mail.corp.redhat.com> <54009012.10903@astron.yasar.com.tr> <20140829145354.GB11446@mail.corp.redhat.com> <54041968.1000908@astron.yasar.com.tr> <20140901071217.GC8008@mail.corp.redhat.com> <5404352E.4060906@astron.yasar.com.tr> Message-ID: <20140901092021.GB3593@redhat.com> On Mon, 01 Sep 2014, Tevfik Ceydeliler wrote: > >libsss-sudo already installed. >Here is my sssd.conf: >[domain/ipa.grp] >krb5_realm = IPA.GRP >cache_credentials = True >krb5_store_password_if_offline = True >ipa_domain = ipa.grp >id_provider = ipa >auth_provider = ipa >access_provider = ipa >ipa_hostname = clnt.ipa.grp >chpass_provider = ipa >ipa_dyndns_update = True >ipa_server = _srv_, srv.ipa.grp >ldap_tls_cacert = /etc/ipa/ca.crt >[sssd] >services = nss, pam, ssh, sudo >config_file_version = 2 >domains = ipa.grp The options below have to be in [domain/...] section: >ldap_sudo_search_base = ou=sudoers,ou=ipa,dc=grp >ldap_sasl_mech = GSSAPI >ldap=sasl_authid = host/cnlt2.ipa.grp >ldap_sasl_realm = IPA.GRP >ldap_netgroup_search_base = ou=SUDOers,dc=ipa,dc=grp >sudo_provider = ldap >ldap_uri = ldap://srv.ipa.grp >krb5_server = srv.ipa.grp -- / Alexander Bokovoy From mkosek at redhat.com Mon Sep 1 10:05:46 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 01 Sep 2014 12:05:46 +0200 Subject: [Freeipa-users] FreeIPA bind also-notify behavior. In-Reply-To: <5404092F.2090604@redhat.com> References: <5404092F.2090604@redhat.com> Message-ID: <540444FA.5090800@redhat.com> On 09/01/2014 07:50 AM, Dmitri Pal wrote: > On 08/29/2014 09:32 PM, Matthew Sellers wrote: >> Hi Everyone! >> >> I am using FreeIPA 3.3.5 on Fedora 20 and attempting to configure FreeIPA to >> send notifies to non-IPA slaves, but it seems broken on IPA ( notify packets >> are never sent to to slaves ). >> >> I have configured also-notify { nameserverip; }; in named.conf on my FreeIPA >> test host in the options section and watched for notify traffic with tcpdump. >> >> This document suggests that this is supported, and this is something I have >> used in non-IPA bind servers with no issues. >> >> https://fedoraproject.org/wiki/QA:Testcase_freeipav3_dns_zone_transfer >> >> I wanted to ask the list before I file a bug with more details. Is anyone >> using this bind feature on IPA with any success? >> >> Thanks! >> Matt >> >> > > The DNS level change propagation is not supported between IPA replicas instead > it uses LDAP replication to propagate the changes. > If you want another non IPA DNS server to be a slave then you can do it. See > http://www.freeipa.org/page/V3/DNS_SOA_serial_auto-incrementation for more > information. I thought that from F20, bind-dyndb-ldap was capable of native DNS operations like AXFR/IXFR which can be used to actually deploy slave DNS servers. I wonder if also-notify is something different. CCing Petr Spacek to advise. From dpal at redhat.com Mon Sep 1 10:16:37 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 01 Sep 2014 12:16:37 +0200 Subject: [Freeipa-users] FreeIPA bind also-notify behavior. In-Reply-To: <540444FA.5090800@redhat.com> References: <5404092F.2090604@redhat.com> <540444FA.5090800@redhat.com> Message-ID: <54044785.4010302@redhat.com> On 09/01/2014 12:05 PM, Martin Kosek wrote: > On 09/01/2014 07:50 AM, Dmitri Pal wrote: >> On 08/29/2014 09:32 PM, Matthew Sellers wrote: >>> Hi Everyone! >>> >>> I am using FreeIPA 3.3.5 on Fedora 20 and attempting to configure FreeIPA to >>> send notifies to non-IPA slaves, but it seems broken on IPA ( notify packets >>> are never sent to to slaves ). >>> >>> I have configured also-notify { nameserverip; }; in named.conf on my FreeIPA >>> test host in the options section and watched for notify traffic with tcpdump. >>> >>> This document suggests that this is supported, and this is something I have >>> used in non-IPA bind servers with no issues. >>> >>> https://fedoraproject.org/wiki/QA:Testcase_freeipav3_dns_zone_transfer >>> >>> I wanted to ask the list before I file a bug with more details. Is anyone >>> using this bind feature on IPA with any success? >>> >>> Thanks! >>> Matt >>> >>> >> The DNS level change propagation is not supported between IPA replicas instead >> it uses LDAP replication to propagate the changes. >> If you want another non IPA DNS server to be a slave then you can do it. See >> http://www.freeipa.org/page/V3/DNS_SOA_serial_auto-incrementation for more >> information. > I thought that from F20, bind-dyndb-ldap was capable of native DNS operations > like AXFR/IXFR which can be used to actually deploy slave DNS servers. I wonder > if also-notify is something different. CCing Petr Spacek to advise. AFAIU slave DNS servers not controlled by IPA yes, replicas as slaves - no. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From jhrozek at redhat.com Mon Sep 1 10:51:16 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 1 Sep 2014 12:51:16 +0200 Subject: [Freeipa-users] How to use sudo rules on ubuntu In-Reply-To: <20140901092021.GB3593@redhat.com> References: <53FF0F5F.5000904@astron.yasar.com.tr> <20140829134442.GA11446@mail.corp.redhat.com> <54009012.10903@astron.yasar.com.tr> <20140829145354.GB11446@mail.corp.redhat.com> <54041968.1000908@astron.yasar.com.tr> <20140901071217.GC8008@mail.corp.redhat.com> <5404352E.4060906@astron.yasar.com.tr> <20140901092021.GB3593@redhat.com> Message-ID: <20140901105116.GG3139@hendrix.brq.redhat.com> On Mon, Sep 01, 2014 at 12:20:21PM +0300, Alexander Bokovoy wrote: > On Mon, 01 Sep 2014, Tevfik Ceydeliler wrote: > > > >libsss-sudo already installed. > >Here is my sssd.conf: > >[domain/ipa.grp] > >krb5_realm = IPA.GRP > >cache_credentials = True > >krb5_store_password_if_offline = True > >ipa_domain = ipa.grp > >id_provider = ipa > >auth_provider = ipa > >access_provider = ipa > >ipa_hostname = clnt.ipa.grp > >chpass_provider = ipa > >ipa_dyndns_update = True > >ipa_server = _srv_, srv.ipa.grp > >ldap_tls_cacert = /etc/ipa/ca.crt > >[sssd] > >services = nss, pam, ssh, sudo > >config_file_version = 2 > >domains = ipa.grp > > The options below have to be in [domain/...] section: > >ldap_sudo_search_base = ou=sudoers,ou=ipa,dc=grp > >ldap_sasl_mech = GSSAPI > >ldap=sasl_authid = host/cnlt2.ipa.grp Moreover this seems to be a typo. (ldap=sasl_authid insteat of ldap_sasl_authid) > >ldap_sasl_realm = IPA.GRP > >ldap_netgroup_search_base = ou=SUDOers,dc=ipa,dc=grp > >sudo_provider = ldap > >ldap_uri = ldap://srv.ipa.grp > >krb5_server = srv.ipa.grp > > -- > / Alexander Bokovoy > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project From tevfik.ceydeliler at astron.yasar.com.tr Mon Sep 1 10:54:18 2014 From: tevfik.ceydeliler at astron.yasar.com.tr (Tevfik Ceydeliler) Date: Mon, 1 Sep 2014 13:54:18 +0300 Subject: [Freeipa-users] How to use sudo rules on ubuntu In-Reply-To: <20140901092021.GB3593@redhat.com> References: <53FF0F5F.5000904@astron.yasar.com.tr> <20140829134442.GA11446@mail.corp.redhat.com> <54009012.10903@astron.yasar.com.tr> <20140829145354.GB11446@mail.corp.redhat.com> <54041968.1000908@astron.yasar.com.tr> <20140901071217.GC8008@mail.corp.redhat.com> <5404352E.4060906@astron.yasar.com.tr> <20140901092021.GB3593@redhat.com> Message-ID: <5404505A.5090409@astron.yasar.com.tr> I moved those lines. But still same. On 01-09-2014 12:20, Alexander Bokovoy wrote: > On Mon, 01 Sep 2014, Tevfik Ceydeliler wrote: >> >> libsss-sudo already installed. >> Here is my sssd.conf: >> [domain/ipa.grp] >> krb5_realm = IPA.GRP >> cache_credentials = True >> krb5_store_password_if_offline = True >> ipa_domain = ipa.grp >> id_provider = ipa >> auth_provider = ipa >> access_provider = ipa >> ipa_hostname = clnt.ipa.grp >> chpass_provider = ipa >> ipa_dyndns_update = True >> ipa_server = _srv_, srv.ipa.grp >> ldap_tls_cacert = /etc/ipa/ca.crt >> [sssd] >> services = nss, pam, ssh, sudo >> config_file_version = 2 >> domains = ipa.grp > > The options below have to be in [domain/...] section: >> ldap_sudo_search_base = ou=sudoers,ou=ipa,dc=grp >> ldap_sasl_mech = GSSAPI >> ldap=sasl_authid = host/cnlt2.ipa.grp >> ldap_sasl_realm = IPA.GRP >> ldap_netgroup_search_base = ou=SUDOers,dc=ipa,dc=grp >> sudo_provider = ldap >> ldap_uri = ldap://srv.ipa.grp >> krb5_server = srv.ipa.grp > --


Bu elektronik postada bulunan tum fikir ve gorusler ve ekindeki dosyalar sadece adres sahip/sahiplerine ait olup, Yasar Toplulugu Sirketleri bu mesajin icerigi ile ilgili olarak hic bir hukuksal sorumlulugu kabul etmez. Eger gonderilmesi dusunulen kisi veya kurulus degilseniz, lutfen gonderen kisiyi derhal haberdar ediniz ve mesaji sisteminizden siliniz.The information contained in this e-mail and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and Yasar Group Companies do not accept legal responsibility for the contents. If you are not the intended recipient, please immediately notify the sender and delete it from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.png Type: image/png Size: 15216 bytes Desc: not available URL: From mkosek at redhat.com Mon Sep 1 11:06:27 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 01 Sep 2014 13:06:27 +0200 Subject: [Freeipa-users] Password expiration dates are different when being resetted by the (primary) admin and a different admin In-Reply-To: References: <53FF5665.9010403@redhat.com> Message-ID: <54045333.5080102@redhat.com> On 08/29/2014 10:21 AM, Zip Ly wrote: > @Martin > 1) Yes, I did executed 8.5.3 from the wiki. Is this is reason for the > systems behaviour? Yes. > if so why doesnt't it applies for both admins? Because only a DN of the first admin was added. It applies only to objects bound with this DN then. > And it > doesn't explain the 90 days, because it is not set in the tutorial. 90 days is the password policy defined password maximum life. You can check with "ipa pwpolicy-show [group]". This value is not defined in "cn=ipa_pwd_extop,cn=plugins,cn=config", thus not present in the docs. > Unless > some params are left out of the wiki for some reason. I'm using windows > LDAP admin tool to browse the LDAP tree, but couln't find this param/value > so I wasn't sure if the new setting is being used. I did get a confirmation > while executing the change. To set the the max password life, use "ipa pwpolicy-mod --maxlife $LIFE" command (or Web UI). > > @Dimitri > 1) Yes, there are no problems with changing your own password. There is > only something strange with the expiration lifetime when you are changing > other users (admin or non-admin) password. The expiration lifetime of a > password reset should be equal to BOTH admins like expired immediately, 90 > days or the value that is set in the password policy. I prefer the value in > a password policy, because this way I have it more under control. > > @Martin & @Will > 1b) Ok, I'm afraid you may say that. Most free clients like gmail, hotmail, > ebay, paypal doesn't require a password reset from time to time (yes they > may have set a very high value). So I was wondering why it isn't possible. > I know it's bad for security, but still. I think the solution is to: 1) Change the password policy to a very high value (even in years), as Will suggested in this thread. 2) Use service accounts (service-add) with keytabs for services which do not need to change their passwords, given they authenticate with keytab which does not suffer from password complexity issues. 3) Contribute to FreeIPA and make --maxlife 0 or similar mean unlimited validity (https://fedorahosted.org/freeipa/ticket/2795) :-) > On Thu, Aug 28, 2014 at 6:18 PM, Dmitri Pal wrote: > >> On 08/28/2014 04:18 PM, Zip Ly wrote: >> >> Hi, >> >> >> I'm trying to change a user password without reset. >> If I use the (primary) admin to change the password then it doesn't need a >> password reset, because the expire lifetime is 90 days. >> >> But if I create a second admin, then every password change made by the >> second admin needs a password reset, because the password is expired >> immediately. >> >> 1a) Does anyone knows how I can change the policy/privilege of the >> second admin so every password change doesn't require a reset? 1b) and is >> it possible to set a different expire lifetime like zero for unlimited >> lifetime? >> >> >> You are probably changing password for the admin himself. >> Isn't there a different flow when admin changes his own password? >> >> >> >> It's almost the same bugreport as >> https://fedorahosted.org/freeipa/ticket/2795 but the difference is there >> should be 2 policies: one for changing your own password and another for >> resetting other users password. >> >> >> 2) Are there more differences in policies between the first (primary) >> admin and the second admin you just created? >> >> >> Kind regards, >> >> Zip >> >> >> >> >> >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go To http://freeipa.org for more info on the project >> > > > From abokovoy at redhat.com Mon Sep 1 11:18:58 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 1 Sep 2014 14:18:58 +0300 Subject: [Freeipa-users] How to use sudo rules on ubuntu In-Reply-To: <5404505A.5090409@astron.yasar.com.tr> References: <53FF0F5F.5000904@astron.yasar.com.tr> <20140829134442.GA11446@mail.corp.redhat.com> <54009012.10903@astron.yasar.com.tr> <20140829145354.GB11446@mail.corp.redhat.com> <54041968.1000908@astron.yasar.com.tr> <20140901071217.GC8008@mail.corp.redhat.com> <5404352E.4060906@astron.yasar.com.tr> <20140901092021.GB3593@redhat.com> <5404505A.5090409@astron.yasar.com.tr> Message-ID: <20140901111858.GE3593@redhat.com> On Mon, 01 Sep 2014, Tevfik Ceydeliler wrote: > >I moved those lines. But still same. As Jakub pointed out, following option also is wrong: ldap=sasl_authid = host/cnlt2.ipa.grp it should be ldap_sasl_authid = host/cnlt2.ipa.grp note _ instead of = between ldap and sasl. >On 01-09-2014 12:20, Alexander Bokovoy wrote: >>On Mon, 01 Sep 2014, Tevfik Ceydeliler wrote: >>> >>>libsss-sudo already installed. >>>Here is my sssd.conf: >>>[domain/ipa.grp] >>>krb5_realm = IPA.GRP >>>cache_credentials = True >>>krb5_store_password_if_offline = True >>>ipa_domain = ipa.grp >>>id_provider = ipa >>>auth_provider = ipa >>>access_provider = ipa >>>ipa_hostname = clnt.ipa.grp >>>chpass_provider = ipa >>>ipa_dyndns_update = True >>>ipa_server = _srv_, srv.ipa.grp >>>ldap_tls_cacert = /etc/ipa/ca.crt >>>[sssd] >>>services = nss, pam, ssh, sudo >>>config_file_version = 2 >>>domains = ipa.grp >> >>The options below have to be in [domain/...] section: >>>ldap_sudo_search_base = ou=sudoers,ou=ipa,dc=grp >>>ldap_sasl_mech = GSSAPI >>>ldap=sasl_authid = host/cnlt2.ipa.grp >>>ldap_sasl_realm = IPA.GRP >>>ldap_netgroup_search_base = ou=SUDOers,dc=ipa,dc=grp >>>sudo_provider = ldap >>>ldap_uri = ldap://srv.ipa.grp >>>krb5_server = srv.ipa.grp >> > >-- > > >
> >

>Bu elektronik postada bulunan tum fikir ve gorusler ve ekindeki dosyalar sadece adres sahip/sahiplerine ait olup, Yasar Toplulugu Sirketleri bu mesajin icerigi ile ilgili olarak hic bir hukuksal sorumlulugu kabul etmez. Eger gonderilmesi dusunulen kisi veya kurulus degilseniz, lutfen gonderen kisiyi derhal haberdar ediniz ve mesaji sisteminizden siliniz.The information contained in this e-mail and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and Yasar Group Companies do not accept legal responsibility for the contents. If you are not the intended recipient, please immediately notify the sender and delete it from your system. -- / Alexander Bokovoy From lslebodn at redhat.com Mon Sep 1 11:27:12 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Mon, 1 Sep 2014 13:27:12 +0200 Subject: [Freeipa-users] How to use sudo rules on ubuntu In-Reply-To: <20140901092021.GB3593@redhat.com> References: <53FF0F5F.5000904@astron.yasar.com.tr> <20140829134442.GA11446@mail.corp.redhat.com> <54009012.10903@astron.yasar.com.tr> <20140829145354.GB11446@mail.corp.redhat.com> <54041968.1000908@astron.yasar.com.tr> <20140901071217.GC8008@mail.corp.redhat.com> <5404352E.4060906@astron.yasar.com.tr> <20140901092021.GB3593@redhat.com> Message-ID: <20140901112711.GD8008@mail.corp.redhat.com> On (01/09/14 12:20), Alexander Bokovoy wrote: >On Mon, 01 Sep 2014, Tevfik Ceydeliler wrote: >> >>libsss-sudo already installed. >>Here is my sssd.conf: >>[domain/ipa.grp] >>krb5_realm = IPA.GRP >>cache_credentials = True >>krb5_store_password_if_offline = True >>ipa_domain = ipa.grp >>id_provider = ipa >>auth_provider = ipa >>access_provider = ipa >>ipa_hostname = clnt.ipa.grp >>chpass_provider = ipa >>ipa_dyndns_update = True >>ipa_server = _srv_, srv.ipa.grp >>ldap_tls_cacert = /etc/ipa/ca.crt >>[sssd] >>services = nss, pam, ssh, sudo >>config_file_version = 2 >>domains = ipa.grp > Alexander, just for you information. These options are not necessary. sssd-1-11 has sudo_provider ipa. It should work out of box. Tevfik, I wrote you that you should follow instructions for configurations of sudo from manual page sssd-sudo. If it does not help plesase send us log file. It will not help us to find problem if you wote "It still the same". Follow slide 18 from presentation[1]. There is described how to obtain debugging informations. LS [1] http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf From tevfik.ceydeliler at astron.yasar.com.tr Mon Sep 1 12:38:44 2014 From: tevfik.ceydeliler at astron.yasar.com.tr (Tevfik Ceydeliler) Date: Mon, 1 Sep 2014 15:38:44 +0300 Subject: [Freeipa-users] How to use sudo rules on ubuntu In-Reply-To: <20140901111858.GE3593@redhat.com> References: <53FF0F5F.5000904@astron.yasar.com.tr> <20140829134442.GA11446@mail.corp.redhat.com> <54009012.10903@astron.yasar.com.tr> <20140829145354.GB11446@mail.corp.redhat.com> <54041968.1000908@astron.yasar.com.tr> <20140901071217.GC8008@mail.corp.redhat.com> <5404352E.4060906@astron.yasar.com.tr> <20140901092021.GB3593@redhat.com> <5404505A.5090409@astron.yasar.com.tr> <20140901111858.GE3593@redhat.com> Message-ID: <540468D4.6020408@astron.yasar.com.tr> I correct that line. But still same: tevfik at Darktower ~ $ ssh user1 at 10.1.1.174 user1 at 10.1.1.174's password: Permission denied, please try again. user1 at 10.1.1.174's password: Welcome to Ubuntu 14.04.1 LTS (GNU/Linux 3.13.0-24-generic x86_64) * Documentation: https://help.ubuntu.com/ Last login: Mon Sep 1 13:47:08 2014 from 10.65.8.100 user1 at clnt:~$ su - user1 apt-get install Password: /usr/bin/apt-get: /usr/bin/apt-get: cannot execute binary file Does anyone have an article about ubuntu+ipa entegration? On 01-09-2014 14:18, Alexander Bokovoy wrote: > On Mon, 01 Sep 2014, Tevfik Ceydeliler wrote: >> >> I moved those lines. But still same. > As Jakub pointed out, following option also is wrong: > > ldap=sasl_authid = host/cnlt2.ipa.grp > > it should be > > ldap_sasl_authid = host/cnlt2.ipa.grp > > note _ instead of = between ldap and sasl. > >> On 01-09-2014 12:20, Alexander Bokovoy wrote: >>> On Mon, 01 Sep 2014, Tevfik Ceydeliler wrote: >>>> >>>> libsss-sudo already installed. >>>> Here is my sssd.conf: >>>> [domain/ipa.grp] >>>> krb5_realm = IPA.GRP >>>> cache_credentials = True >>>> krb5_store_password_if_offline = True >>>> ipa_domain = ipa.grp >>>> id_provider = ipa >>>> auth_provider = ipa >>>> access_provider = ipa >>>> ipa_hostname = clnt.ipa.grp >>>> chpass_provider = ipa >>>> ipa_dyndns_update = True >>>> ipa_server = _srv_, srv.ipa.grp >>>> ldap_tls_cacert = /etc/ipa/ca.crt >>>> [sssd] >>>> services = nss, pam, ssh, sudo >>>> config_file_version = 2 >>>> domains = ipa.grp >>> >>> The options below have to be in [domain/...] section: >>>> ldap_sudo_search_base = ou=sudoers,ou=ipa,dc=grp >>>> ldap_sasl_mech = GSSAPI >>>> ldap=sasl_authid = host/cnlt2.ipa.grp >>>> ldap_sasl_realm = IPA.GRP >>>> ldap_netgroup_search_base = ou=SUDOers,dc=ipa,dc=grp >>>> sudo_provider = ldap >>>> ldap_uri = ldap://srv.ipa.grp >>>> krb5_server = srv.ipa.grp >>> >> >> -- >> >> >>
>> >>

>> Bu elektronik postada bulunan tum fikir ve gorusler ve ekindeki >> dosyalar sadece adres sahip/sahiplerine ait olup, Yasar Toplulugu >> Sirketleri bu mesajin icerigi ile ilgili olarak hic bir hukuksal >> sorumlulugu kabul etmez. Eger gonderilmesi dusunulen kisi veya >> kurulus degilseniz, lutfen gonderen kisiyi derhal haberdar ediniz ve >> mesaji sisteminizden siliniz.The information contained in this e-mail >> and any files transmitted with it are intended solely for the use of >> the individual or entity to whom they are addressed and Yasar Group >> Companies do not accept legal responsibility for the contents. If you >> are not the intended recipient, please immediately notify the sender >> and delete it from your system. > --


Bu elektronik postada bulunan tum fikir ve gorusler ve ekindeki dosyalar sadece adres sahip/sahiplerine ait olup, Yasar Toplulugu Sirketleri bu mesajin icerigi ile ilgili olarak hic bir hukuksal sorumlulugu kabul etmez. Eger gonderilmesi dusunulen kisi veya kurulus degilseniz, lutfen gonderen kisiyi derhal haberdar ediniz ve mesaji sisteminizden siliniz.The information contained in this e-mail and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and Yasar Group Companies do not accept legal responsibility for the contents. If you are not the intended recipient, please immediately notify the sender and delete it from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.png Type: image/png Size: 15216 bytes Desc: not available URL: From lslebodn at redhat.com Mon Sep 1 12:42:31 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Mon, 1 Sep 2014 14:42:31 +0200 Subject: [Freeipa-users] How to use sudo rules on ubuntu In-Reply-To: <540468D4.6020408@astron.yasar.com.tr> References: <20140829134442.GA11446@mail.corp.redhat.com> <54009012.10903@astron.yasar.com.tr> <20140829145354.GB11446@mail.corp.redhat.com> <54041968.1000908@astron.yasar.com.tr> <20140901071217.GC8008@mail.corp.redhat.com> <5404352E.4060906@astron.yasar.com.tr> <20140901092021.GB3593@redhat.com> <5404505A.5090409@astron.yasar.com.tr> <20140901111858.GE3593@redhat.com> <540468D4.6020408@astron.yasar.com.tr> Message-ID: <20140901124231.GF8008@mail.corp.redhat.com> On (01/09/14 15:38), Tevfik Ceydeliler wrote: > >I correct that line. >But still same: >tevfik at Darktower ~ $ ssh user1 at 10.1.1.174 >user1 at 10.1.1.174's password: >Permission denied, please try again. >user1 at 10.1.1.174's password: >Welcome to Ubuntu 14.04.1 LTS (GNU/Linux 3.13.0-24-generic x86_64) > > * Documentation: https://help.ubuntu.com/ > >Last login: Mon Sep 1 13:47:08 2014 from 10.65.8.100 >user1 at clnt:~$ su - user1 apt-get install >Password: >/usr/bin/apt-get: /usr/bin/apt-get: cannot execute binary file > >Does anyone have an article about ubuntu+ipa entegration? And when(where) was sudo commandused? LS From tevfik.ceydeliler at astron.yasar.com.tr Mon Sep 1 12:48:03 2014 From: tevfik.ceydeliler at astron.yasar.com.tr (Tevfik Ceydeliler) Date: Mon, 1 Sep 2014 15:48:03 +0300 Subject: [Freeipa-users] How to use sudo rules on ubuntu In-Reply-To: <20140901124231.GF8008@mail.corp.redhat.com> References: <20140829134442.GA11446@mail.corp.redhat.com> <54009012.10903@astron.yasar.com.tr> <20140829145354.GB11446@mail.corp.redhat.com> <54041968.1000908@astron.yasar.com.tr> <20140901071217.GC8008@mail.corp.redhat.com> <5404352E.4060906@astron.yasar.com.tr> <20140901092021.GB3593@redhat.com> <5404505A.5090409@astron.yasar.com.tr> <20140901111858.GE3593@redhat.com> <540468D4.6020408@astron.yasar.com.tr> <20140901124231.GF8008@mail.corp.redhat.com> Message-ID: <54046B03.1030201@astron.yasar.com.tr> Actually All I wanna do is , give permission to user to use some commanf. for example apt-get or something else. I Think I can do it with IPA right? On 01-09-2014 15:42, Lukas Slebodnik wrote: > ogin: Mon Sep 1 13:47:08 2014 from 10.65.8.100 > >user1 at clnt:~$ su - user1 apt-get install > >Password: > >/usr/bin/apt-get: /usr/bin/apt-get: cannot execute binary file > > > >Does anyone have an article about ubuntu+ipa entegration? --


Bu elektronik postada bulunan tum fikir ve gorusler ve ekindeki dosyalar sadece adres sahip/sahiplerine ait olup, Yasar Toplulugu Sirketleri bu mesajin icerigi ile ilgili olarak hic bir hukuksal sorumlulugu kabul etmez. Eger gonderilmesi dusunulen kisi veya kurulus degilseniz, lutfen gonderen kisiyi derhal haberdar ediniz ve mesaji sisteminizden siliniz.The information contained in this e-mail and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and Yasar Group Companies do not accept legal responsibility for the contents. If you are not the intended recipient, please immediately notify the sender and delete it from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.png Type: image/png Size: 15216 bytes Desc: not available URL: From lslebodn at redhat.com Mon Sep 1 13:04:10 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Mon, 1 Sep 2014 15:04:10 +0200 Subject: [Freeipa-users] How to use sudo rules on ubuntu In-Reply-To: <54046B03.1030201@astron.yasar.com.tr> References: <20140829145354.GB11446@mail.corp.redhat.com> <54041968.1000908@astron.yasar.com.tr> <20140901071217.GC8008@mail.corp.redhat.com> <5404352E.4060906@astron.yasar.com.tr> <20140901092021.GB3593@redhat.com> <5404505A.5090409@astron.yasar.com.tr> <20140901111858.GE3593@redhat.com> <540468D4.6020408@astron.yasar.com.tr> <20140901124231.GF8008@mail.corp.redhat.com> <54046B03.1030201@astron.yasar.com.tr> Message-ID: <20140901130410.GG8008@mail.corp.redhat.com> On (01/09/14 15:48), Tevfik Ceydeliler wrote: > >Actually All I wanna do is , give permission to user to use some commanf. for >example apt-get or something else. >I Think I can do it with IPA >right? Yes, but you need to use sudo. Step 1: configure sudo rules for ordinary user Please follow the instructions from FreeIPA documentation. http://www.freeipa.org/docs/master/html-desktop/index.html#sudo Step 2: login to machine as ordinary user, which is allowed to use sudo. Step 3: run command sudo -l // this command should show you which commands can be executed as root // with sudo Step 4: If there weren't any problems then user will be able to run command. sudo some_command_listed_in_step3 LS From natxo.asenjo at gmail.com Mon Sep 1 13:05:55 2014 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Mon, 1 Sep 2014 15:05:55 +0200 Subject: [Freeipa-users] How to use sudo rules on ubuntu In-Reply-To: <54046B03.1030201@astron.yasar.com.tr> References: <20140829134442.GA11446@mail.corp.redhat.com> <54009012.10903@astron.yasar.com.tr> <20140829145354.GB11446@mail.corp.redhat.com> <54041968.1000908@astron.yasar.com.tr> <20140901071217.GC8008@mail.corp.redhat.com> <5404352E.4060906@astron.yasar.com.tr> <20140901092021.GB3593@redhat.com> <5404505A.5090409@astron.yasar.com.tr> <20140901111858.GE3593@redhat.com> <540468D4.6020408@astron.yasar.com.tr> <20140901124231.GF8008@mail.corp.redhat.com> <54046B03.1030201@astron.yasar.com.tr> Message-ID: On Mon, Sep 1, 2014 at 2:48 PM, Tevfik Ceydeliler < tevfik.ceydeliler at astron.yasar.com.tr> wrote: > Actually All I wanna do is , give permission to user to use some commanf. > for example apt-get or something else. > I Think I can do it with IPA > right? > > sure, I do it all the time. But Lukas was pointing to the fact that there are no sudo commands in the example you posted. there should be something like: sudo /usr/bin/apt-get (running as user1, so you need to login as that user first and then run the sudo command). instead of su - user1 apt-get install .. On 01-09-2014 15:42, Lukas Slebodnik wrote: > > ogin: Mon Sep 1 13:47:08 2014 from 10.65.8.100>user1 at clnt:~$ su - user1 apt-get install>Password:>/usr/bin/apt-get: /usr/bin/apt-get: cannot execute binary file>>Does anyone have an article about ubuntu+ipa entegration? > > > - > -- -- Groeten, natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From tevfik.ceydeliler at astron.yasar.com.tr Mon Sep 1 13:25:11 2014 From: tevfik.ceydeliler at astron.yasar.com.tr (Tevfik Ceydeliler) Date: Mon, 1 Sep 2014 16:25:11 +0300 Subject: [Freeipa-users] How to use sudo rules on ubuntu In-Reply-To: References: <20140829134442.GA11446@mail.corp.redhat.com> <54009012.10903@astron.yasar.com.tr> <20140829145354.GB11446@mail.corp.redhat.com> <54041968.1000908@astron.yasar.com.tr> <20140901071217.GC8008@mail.corp.redhat.com> <5404352E.4060906@astron.yasar.com.tr> <20140901092021.GB3593@redhat.com> <5404505A.5090409@astron.yasar.com.tr> <20140901111858.GE3593@redhat.com> <540468D4.6020408@astron.yasar.com.tr> <20140901124231.GF8008@mail.corp.redhat.com> <54046B03.1030201@astron.yasar.com.tr> Message-ID: <540473B7.5070606@astron.yasar.com.tr> I think something wrong or miss in ym configuration: user1 at clnt:~$ sudo /usr/bin/apt-get install [sudo] password for user1: user1 is not allowed to run sudo on clnt. This incident will be reported. On 01-09-2014 16:05, Natxo Asenjo wrote: > > > > On Mon, Sep 1, 2014 at 2:48 PM, Tevfik Ceydeliler > > wrote: > > Actually All I wanna do is , give permission to user to use some > commanf. for example apt-get or something else. > I Think I can do it with IPA > right? > > sure, I do it all the time. But Lukas was pointing to the fact that > there are no sudo commands in the example you posted. > > there should be something like: > > > sudo /usr/bin/apt-get (running as user1, so you need to login as that > user first and then run the sudo command). > > instead of su - user1 apt-get install .. > > > On 01-09-2014 15:42, Lukas Slebodnik wrote: >> ogin: Mon Sep 1 13:47:08 2014 from 10.65.8.100 >> >user1 at clnt:~$ su - user1 apt-get install >> >Password: >> >/usr/bin/apt-get: /usr/bin/apt-get: cannot execute binary file >> > >> >Does anyone have an article about ubuntu+ipa entegration? > > - > > > -- > -- > Groeten, > natxo --


Bu elektronik postada bulunan tum fikir ve gorusler ve ekindeki dosyalar sadece adres sahip/sahiplerine ait olup, Yasar Toplulugu Sirketleri bu mesajin icerigi ile ilgili olarak hic bir hukuksal sorumlulugu kabul etmez. Eger gonderilmesi dusunulen kisi veya kurulus degilseniz, lutfen gonderen kisiyi derhal haberdar ediniz ve mesaji sisteminizden siliniz.The information contained in this e-mail and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and Yasar Group Companies do not accept legal responsibility for the contents. If you are not the intended recipient, please immediately notify the sender and delete it from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.png Type: image/png Size: 15216 bytes Desc: not available URL: From tevfik.ceydeliler at astron.yasar.com.tr Mon Sep 1 14:52:14 2014 From: tevfik.ceydeliler at astron.yasar.com.tr (Tevfik Ceydeliler) Date: Mon, 1 Sep 2014 17:52:14 +0300 Subject: [Freeipa-users] How to use sudo rules on ubuntu In-Reply-To: <20140901130410.GG8008@mail.corp.redhat.com> References: <20140829145354.GB11446@mail.corp.redhat.com> <54041968.1000908@astron.yasar.com.tr> <20140901071217.GC8008@mail.corp.redhat.com> <5404352E.4060906@astron.yasar.com.tr> <20140901092021.GB3593@redhat.com> <5404505A.5090409@astron.yasar.com.tr> <20140901111858.GE3593@redhat.com> <540468D4.6020408@astron.yasar.com.tr> <20140901124231.GF8008@mail.corp.redhat.com> <54046B03.1030201@astron.yasar.com.tr> <20140901130410.GG8008@mail.corp.redhat.com> Message-ID: <5404881E.7050204@astron.yasar.com.tr> 1. I think I configure instead of this document 2. I can login with ordinary user 3. Irun the command: ssh user1 at 10.1.1.174 user1 at 10.1.1.174's password: Welcome to Ubuntu 14.04.1 LTS (GNU/Linux 3.13.0-24-generic x86_64) * Documentation: https://help.ubuntu.com/ Last login: Mon Sep 1 15:03:57 2014 from 10.65.8.100 user1 at clnt:~$ sudo -l [sudo] password for user1: User user1 is not allowed to run sudo on clnt. user1 at clnt:~$ 4. ?? On 01-09-2014 16:04, Lukas Slebodnik wrote: > On (01/09/14 15:48), Tevfik Ceydeliler wrote: >> Actually All I wanna do is , give permission to user to use some commanf. for >> example apt-get or something else. >> I Think I can do it with IPA >> right? > Yes, but you need to use sudo. > > Step 1: configure sudo rules for ordinary user > Please follow the instructions from FreeIPA documentation. > http://www.freeipa.org/docs/master/html-desktop/index.html#sudo > > Step 2: login to machine as ordinary user, which is allowed to use sudo. > Step 3: run command > sudo -l > // this command should show you which commands can be executed as root > // with sudo > Step 4: If there weren't any problems then user will be able to run command. > sudo some_command_listed_in_step3 > > LS --


Bu elektronik postada bulunan tum fikir ve gorusler ve ekindeki dosyalar sadece adres sahip/sahiplerine ait olup, Yasar Toplulugu Sirketleri bu mesajin icerigi ile ilgili olarak hic bir hukuksal sorumlulugu kabul etmez. Eger gonderilmesi dusunulen kisi veya kurulus degilseniz, lutfen gonderen kisiyi derhal haberdar ediniz ve mesaji sisteminizden siliniz.The information contained in this e-mail and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and Yasar Group Companies do not accept legal responsibility for the contents. If you are not the intended recipient, please immediately notify the sender and delete it from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.png Type: image/png Size: 15216 bytes Desc: not available URL: From lslebodn at redhat.com Mon Sep 1 16:05:39 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Mon, 1 Sep 2014 18:05:39 +0200 Subject: [Freeipa-users] How to use sudo rules on ubuntu In-Reply-To: <5404881E.7050204@astron.yasar.com.tr> References: <20140901071217.GC8008@mail.corp.redhat.com> <5404352E.4060906@astron.yasar.com.tr> <20140901092021.GB3593@redhat.com> <5404505A.5090409@astron.yasar.com.tr> <20140901111858.GE3593@redhat.com> <540468D4.6020408@astron.yasar.com.tr> <20140901124231.GF8008@mail.corp.redhat.com> <54046B03.1030201@astron.yasar.com.tr> <20140901130410.GG8008@mail.corp.redhat.com> <5404881E.7050204@astron.yasar.com.tr> Message-ID: <20140901160539.GJ8008@mail.corp.redhat.com> On (01/09/14 17:52), Tevfik Ceydeliler wrote: > >1. I think I configure instead of this document Sorry you didn't. >2. I can login with ordinary user login and sudo are not the same think. My FreeIPA server is alredy properly configured with sudo rules. I tried to install freipa-client on ubuntu 14.04 and it owrked without any problem. >>Step 0: Install freipa-client on ubuntu 14.04 and configure sudo integration root at ubuntu1404:/# ipa-client-install --no-ntp root at ubuntu1404:/# echo "sudoers: files sss" >> /etc/nsswitch.conf root at ubuntu1404:/# grep services /etc/sssd/sssd.conf services = nss, pam root at ubuntu1404:/# sed -i -e 's/\(services.*\)/\1, sudo/' /etc/sssd/sssd.conf root at ubuntu1404:/# grep services /etc/sssd/sssd.conf services = nss, pam, sudo >>Step 1: configure sudo rules for ordinary user >> Please follow the instructions from FreeIPA documentation. >> http://www.freeipa.org/docs/master/html-desktop/index.html#sudo >> This step was skipped, becuase it was already done few months ago :-) >>Step 2: login to machine as ordinary user, which is allowed to use sudo. $ su usersssd01 Password: $ id uid=325600011(usersssd01) gid=325600011(usersssd01) groups=325600011(usersssd01),30011(biggroup1) >>Step 3: run command >> sudo -l >> // this command should show you which commands can be executed as root >> // with sudo $ sudo -l sudo: unable to resolve host ubuntu1404.example.test [sudo] password for usersssd01: Matching Defaults entries for usersssd01 on ubuntu1404: env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin User usersssd01 may run the following commands on ubuntu1404: (root) /usr/bin/less, /usr/bin/vim >>Step 4: If there weren't any problems then user will be able to run command. >> sudo some_command_listed_in_step3 $ sudo /usr/bin/less /etc/shadow | wc -l 21 $ echo $? 0 $ sudo apt-get install mc Sorry, user usersssd01 is not allowed to execute '/usr/bin/apt-get install mc' as root on ubuntu.example.test. $ echo $? 1 LS From rob.verduijn at gmail.com Mon Sep 1 16:17:43 2014 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Mon, 1 Sep 2014 18:17:43 +0200 Subject: [Freeipa-users] sudo without the !authenticate Message-ID: Hello, I've a freeipa running on fedora 20 with fedora 20 clients. When I configure sudo with the !authenticate option, everything works fine. ie 'sudo journalctl' works fine, you get to see the logs However when I remove the !authenticate option the sudo command asks for a password but it always fails. In the logs it says that authentication succes but it is followed by the line access denied. What could be causing this ? Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Mon Sep 1 16:47:28 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 01 Sep 2014 18:47:28 +0200 Subject: [Freeipa-users] sudo without the !authenticate In-Reply-To: References: Message-ID: <5404A320.5040300@redhat.com> On 09/01/2014 06:17 PM, Rob Verduijn wrote: > Hello, > > I've a freeipa running on fedora 20 with fedora 20 clients. > > When I configure sudo with the !authenticate option, everything works > fine. > ie 'sudo journalctl' works fine, you get to see the logs > > However when I remove the !authenticate option the sudo command asks > for a password but it always fails. > > In the logs it says that authentication succes > but it is followed by the line access denied. > > What could be causing this ? > > Rob > > > Probably access control. Do you have HBAC rules defined? Do they allow user to do sudo operations? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob.verduijn at gmail.com Mon Sep 1 18:38:32 2014 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Mon, 1 Sep 2014 20:38:32 +0200 Subject: [Freeipa-users] sudo without the !authenticate In-Reply-To: <5404A320.5040300@redhat.com> References: <5404A320.5040300@redhat.com> Message-ID: 2014-09-01 18:47 GMT+02:00 Dmitri Pal : > On 09/01/2014 06:17 PM, Rob Verduijn wrote: > > Hello, > > I've a freeipa running on fedora 20 with fedora 20 clients. > > When I configure sudo with the !authenticate option, everything works > fine. > ie 'sudo journalctl' works fine, you get to see the logs > > However when I remove the !authenticate option the sudo command asks for > a password but it always fails. > > In the logs it says that authentication succes > but it is followed by the line access denied. > > What could be causing this ? > > Rob > > > > Probably access control. Do you have HBAC rules defined? Do they allow > user to do sudo operations? > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > Hello, That was indeed preventing the access without the !noathenticate. I've added sudo to the hbac and now it works. Thanx. Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From cwhittl at gmail.com Tue Sep 2 01:04:26 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Mon, 1 Sep 2014 20:04:26 -0500 Subject: [Freeipa-users] Search Base issues Message-ID: I am trying to limit who can login to my macs and I'm having to stick to what OSX will let me do. Currently I can only limit users using the searchbase and right now it's "cn=users,cn=accounts,dc=DOMAIN,dc=com" This works fine unless I wanted to create a user that I wanted in LDAP for other purposes but not to login. So my questions are, A)Can we create different OUs in FreeIPA like most LDAP servers? B)If not anyone have any idea on how I could do this with OSX's directory Utility? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From tevfik.ceydeliler at astron.yasar.com.tr Tue Sep 2 08:02:34 2014 From: tevfik.ceydeliler at astron.yasar.com.tr (Tevfik Ceydeliler) Date: Tue, 2 Sep 2014 11:02:34 +0300 Subject: [Freeipa-users] How to use sudo rules on ubuntu In-Reply-To: <20140901160539.GJ8008@mail.corp.redhat.com> References: <20140901071217.GC8008@mail.corp.redhat.com> <5404352E.4060906@astron.yasar.com.tr> <20140901092021.GB3593@redhat.com> <5404505A.5090409@astron.yasar.com.tr> <20140901111858.GE3593@redhat.com> <540468D4.6020408@astron.yasar.com.tr> <20140901124231.GF8008@mail.corp.redhat.com> <54046B03.1030201@astron.yasar.com.tr> <20140901130410.GG8008@mail.corp.redhat.com> <5404881E.7050204@astron.yasar.com.tr> <20140901160539.GJ8008@mail.corp.redhat.com> Message-ID: <5405799A.7080507@astron.yasar.com.tr> Step 0 root at clnt:/home/awtadm# grep sudoers /etc/nsswitch.conf sudoers_debug: 1 sudoers: files sss root at clnt:/home/awtadm# ipa-client-install --no-ntp IPA client is already configured on this system. root at clnt:/home/awtadm# grep services /etc/sssd/sssd.conf services = nss, pam, ssh, sudo Step1 (there is some problem when create rule on CLI. No problem prompt on Web-based) ... [root at srv ~]# ipa sudorule-add-option readfiles Sudo Option: !authenticate ipa: ERROR: no such entry ... Then: awtadm at clnt:~$ su user1 Password: user1 at clnt:/home/awtadm$ /usr/bin/less /etc/shadow |wc -l /etc/shadow: Permission denied 0 user1 at clnt:/home/awtadm$ sudo /usr/bin/less /etc/shadow |wc -l [sudo] password for user1: user1 is not in the sudoers file. This incident will be reported. 0 user1 at clnt:/home/awtadm$ id uid=1423400004(user1) gid=1423400004(user1) groups=1423400004(user1) user1 at clnt:/home/awtadm$ sudo -l [sudo] password for user1: Sorry, user user1 may not run sudo on clnt. user1 at clnt:/home/awtadm$ exit exit awtadm at clnt:~$ su user1 Password: user1 at clnt:/home/awtadm$ id uid=1423400004(user1) gid=1423400004(user1) groups=1423400004(user1) user1 at clnt:/home/awtadm$ sudo -l [sudo] password for user1: Sorry, user user1 may not run sudo on clnt. user1 at clnt:/home/awtadm$ /usr/bin/less /etc/shadow |wc -l /etc/shadow: Permission denied 0 user1 at clnt:/home/awtadm$ sudo /usr/bin/less /etc/shadow |wc -l [sudo] password for user1: user1 is not in the sudoers file. This incident will be reported. 0 --OR-- Darktower tevfik # ssh user1 at 10.1.1.174 The authenticity of host '10.1.1.174 (10.1.1.174)' can't be established. ECDSA key fingerprint is 37:32:fc:ca:34:ce:4c:07:e8:b6:f6:56:75:98:69:b8. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '10.1.1.174' (ECDSA) to the list of known hosts. user1 at 10.1.1.174's password: Welcome to Ubuntu 14.04.1 LTS (GNU/Linux 3.13.0-24-generic x86_64) * Documentation: https://help.ubuntu.com/ Last login: Mon Sep 1 17:50:02 2014 from 10.65.8.100 user1 at clnt:~$ sudo /usr/bin/less /etc/shadow |wc -l [sudo] password for user1: user1 is not allowed to run sudo on clnt. This incident will be reported. 0 user1 at clnt:~$ sudo -l [sudo] password for user1: User user1 is not allowed to run sudo on clnt. On 01-09-2014 19:05, Lukas Slebodnik wrote: > On (01/09/14 17:52), Tevfik Ceydeliler wrote: >> 1. I think I configure instead of this document > Sorry you didn't. > >> 2. I can login with ordinary user > login and sudo are not the same think. > > My FreeIPA server is alredy properly configured with sudo rules. > I tried to install freipa-client on ubuntu 14.04 and it owrked without any > problem. > >>> Step 0: Install freipa-client on ubuntu 14.04 and configure sudo integration > root at ubuntu1404:/# ipa-client-install --no-ntp > root at ubuntu1404:/# echo "sudoers: files sss" >> /etc/nsswitch.conf > > root at ubuntu1404:/# grep services /etc/sssd/sssd.conf > services = nss, pam > root at ubuntu1404:/# sed -i -e 's/\(services.*\)/\1, sudo/' /etc/sssd/sssd.conf > root at ubuntu1404:/# grep services /etc/sssd/sssd.conf > services = nss, pam, sudo > >>> Step 1: configure sudo rules for ordinary user >>> Please follow the instructions from FreeIPA documentation. >>> http://www.freeipa.org/docs/master/html-desktop/index.html#sudo >>> > This step was skipped, becuase it was already done few months ago :-) > >>> Step 2: login to machine as ordinary user, which is allowed to use sudo. > $ su usersssd01 > Password: > $ id > uid=325600011(usersssd01) gid=325600011(usersssd01) groups=325600011(usersssd01),30011(biggroup1) > >>> Step 3: run command >>> sudo -l >>> // this command should show you which commands can be executed as root >>> // with sudo > $ sudo -l > sudo: unable to resolve host ubuntu1404.example.test > [sudo] password for usersssd01: > Matching Defaults entries for usersssd01 on ubuntu1404: > env_reset, mail_badpass, > secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin > > User usersssd01 may run the following commands on ubuntu1404: > (root) /usr/bin/less, /usr/bin/vim > >>> Step 4: If there weren't any problems then user will be able to run command. >>> sudo some_command_listed_in_step3 > $ sudo /usr/bin/less /etc/shadow | wc -l > 21 > $ echo $? > 0 > > $ sudo apt-get install mc > Sorry, user usersssd01 is not allowed to execute '/usr/bin/apt-get install mc' as root on ubuntu.example.test. > $ echo $? > 1 > > LS --


Bu elektronik postada bulunan tum fikir ve gorusler ve ekindeki dosyalar sadece adres sahip/sahiplerine ait olup, Yasar Toplulugu Sirketleri bu mesajin icerigi ile ilgili olarak hic bir hukuksal sorumlulugu kabul etmez. Eger gonderilmesi dusunulen kisi veya kurulus degilseniz, lutfen gonderen kisiyi derhal haberdar ediniz ve mesaji sisteminizden siliniz.The information contained in this e-mail and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and Yasar Group Companies do not accept legal responsibility for the contents. If you are not the intended recipient, please immediately notify the sender and delete it from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 15216 bytes Desc: not available URL: From lslebodn at redhat.com Tue Sep 2 08:13:39 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Tue, 2 Sep 2014 10:13:39 +0200 Subject: [Freeipa-users] How to use sudo rules on ubuntu In-Reply-To: <5405799A.7080507@astron.yasar.com.tr> References: <20140901092021.GB3593@redhat.com> <5404505A.5090409@astron.yasar.com.tr> <20140901111858.GE3593@redhat.com> <540468D4.6020408@astron.yasar.com.tr> <20140901124231.GF8008@mail.corp.redhat.com> <54046B03.1030201@astron.yasar.com.tr> <20140901130410.GG8008@mail.corp.redhat.com> <5404881E.7050204@astron.yasar.com.tr> <20140901160539.GJ8008@mail.corp.redhat.com> <5405799A.7080507@astron.yasar.com.tr> Message-ID: <20140902081338.GA31435@mail.corp.redhat.com> On (02/09/14 11:02), Tevfik Ceydeliler wrote: > >Step 0 >root at clnt:/home/awtadm# grep sudoers /etc/nsswitch.conf >sudoers_debug: 1 >sudoers: files sss > >root at clnt:/home/awtadm# ipa-client-install --no-ntp >IPA client is already configured on this system. > >root at clnt:/home/awtadm# grep services /etc/sssd/sssd.conf >services = nss, pam, ssh, sudo > You need to restart sssd after modification of option "services" in /etc/sssd/sssd.conf. I forgot to mention it. > >Step1 (there is some problem when create rule on CLI. No problem prompt on >Web-based) >... >[root at srv ~]# ipa sudorule-add-option readfiles >Sudo Option: !authenticate >ipa: ERROR: no such entry > >... > Then: >awtadm at clnt:~$ su user1 >Password: >uid=1423400004(user1) gid=1423400004(user1) groups=1423400004(user1) >user1 at clnt:/home/awtadm$ sudo -l >[sudo] password for user1: >Sorry, user user1 may not run sudo on clnt. There is no reason to try sudo commands if "sudo -l" fails. It works for me on ubuntu 14.04. It is very likely you have problem on FreeIPA Server. Other people can help you with server part, I could help you just with client configuration. (From my point of view, problem is solved) One more time, please follow instructions: http://www.freeipa.org/docs/master/html-desktop/index.html#sudo LS From tevfik.ceydeliler at astron.yasar.com.tr Tue Sep 2 08:33:17 2014 From: tevfik.ceydeliler at astron.yasar.com.tr (Tevfik Ceydeliler) Date: Tue, 2 Sep 2014 11:33:17 +0300 Subject: [Freeipa-users] How to use sudo rules on ubuntu In-Reply-To: <20140902081338.GA31435@mail.corp.redhat.com> References: <20140901092021.GB3593@redhat.com> <5404505A.5090409@astron.yasar.com.tr> <20140901111858.GE3593@redhat.com> <540468D4.6020408@astron.yasar.com.tr> <20140901124231.GF8008@mail.corp.redhat.com> <54046B03.1030201@astron.yasar.com.tr> <20140901130410.GG8008@mail.corp.redhat.com> <5404881E.7050204@astron.yasar.com.tr> <20140901160539.GJ8008@mail.corp.redhat.com> <5405799A.7080507@astron.yasar.com.tr> <20140902081338.GA31435@mail.corp.redhat.com> Message-ID: <540580CD.3020200@astron.yasar.com.tr> I restart client after change sssd.conf. On 02-09-2014 11:13, Lukas Slebodnik wrote: > On (02/09/14 11:02), Tevfik Ceydeliler wrote: >> Step 0 >> root at clnt:/home/awtadm# grep sudoers /etc/nsswitch.conf >> sudoers_debug: 1 >> sudoers: files sss >> >> root at clnt:/home/awtadm# ipa-client-install --no-ntp >> IPA client is already configured on this system. >> >> root at clnt:/home/awtadm# grep services /etc/sssd/sssd.conf >> services = nss, pam, ssh, sudo >> > You need to restart sssd after modification of option "services" in > /etc/sssd/sssd.conf. I forgot to mention it. > >> Step1 (there is some problem when create rule on CLI. No problem prompt on >> Web-based) >> ... >> [root at srv ~]# ipa sudorule-add-option readfiles >> Sudo Option: !authenticate >> ipa: ERROR: no such entry >> >> ... >> Then: >> awtadm at clnt:~$ su user1 >> Password: >> uid=1423400004(user1) gid=1423400004(user1) groups=1423400004(user1) >> user1 at clnt:/home/awtadm$ sudo -l >> [sudo] password for user1: >> Sorry, user user1 may not run sudo on clnt. > There is no reason to try sudo commands if "sudo -l" fails. > > It works for me on ubuntu 14.04. It is very likely you have problem > on FreeIPA Server. Other people can help you with server part, > I could help you just with client configuration. > (From my point of view, problem is solved) > > One more time, please follow instructions: > http://www.freeipa.org/docs/master/html-desktop/index.html#sudo > > LS --


Bu elektronik postada bulunan tum fikir ve gorusler ve ekindeki dosyalar sadece adres sahip/sahiplerine ait olup, Yasar Toplulugu Sirketleri bu mesajin icerigi ile ilgili olarak hic bir hukuksal sorumlulugu kabul etmez. Eger gonderilmesi dusunulen kisi veya kurulus degilseniz, lutfen gonderen kisiyi derhal haberdar ediniz ve mesaji sisteminizden siliniz.The information contained in this e-mail and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and Yasar Group Companies do not accept legal responsibility for the contents. If you are not the intended recipient, please immediately notify the sender and delete it from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.png Type: image/png Size: 15216 bytes Desc: not available URL: From ziplyx at gmail.com Tue Sep 2 08:42:25 2014 From: ziplyx at gmail.com (Zip Ly) Date: Tue, 2 Sep 2014 10:42:25 +0200 Subject: [Freeipa-users] Password expiration dates are different when being resetted by the (primary) admin and a different admin In-Reply-To: <54045333.5080102@redhat.com> References: <53FF5665.9010403@redhat.com> <54045333.5080102@redhat.com> Message-ID: @Martin The second admin is my service account. I use this account to communicate with our webapplication (it uses keytab and post/curl json to ipa). I can add users without a problem. But when it comes to changing password, the password is expired immediately. I have only one password policy and that's the 'global_policy'. The --maxlife you mentioned only affect this policy. If I use this service account to change the user password, the policy is ignored just as stated in the ipa wiki. Even if I set the --maxlife to 200, if the password is being resetted by this first admin, then the expire date is set to 90 days or expired immediately by the second admin/service account. That's why I want to know how to change this 90 days and also apply it for the service account. On Mon, Sep 1, 2014 at 1:06 PM, Martin Kosek wrote: > On 08/29/2014 10:21 AM, Zip Ly wrote: > > @Martin > > 1) Yes, I did executed 8.5.3 from the wiki. Is this is reason for the > > systems behaviour? > > Yes. > > > if so why doesnt't it applies for both admins? > > Because only a DN of the first admin was added. It applies only to objects > bound with this DN then. > > > And it > > doesn't explain the 90 days, because it is not set in the tutorial. > > 90 days is the password policy defined password maximum life. You can check > with "ipa pwpolicy-show [group]". This value is not defined in > "cn=ipa_pwd_extop,cn=plugins,cn=config", thus not present in the docs. > > > Unless > > some params are left out of the wiki for some reason. I'm using windows > > LDAP admin tool to browse the LDAP tree, but couln't find this > param/value > > so I wasn't sure if the new setting is being used. I did get a > confirmation > > while executing the change. > > To set the the max password life, use "ipa pwpolicy-mod --maxlife $LIFE" > command (or Web UI). > > > > > @Dimitri > > 1) Yes, there are no problems with changing your own password. There is > > only something strange with the expiration lifetime when you are changing > > other users (admin or non-admin) password. The expiration lifetime of a > > password reset should be equal to BOTH admins like expired immediately, > 90 > > days or the value that is set in the password policy. I prefer the value > in > > a password policy, because this way I have it more under control. > > > > @Martin & @Will > > 1b) Ok, I'm afraid you may say that. Most free clients like gmail, > hotmail, > > ebay, paypal doesn't require a password reset from time to time (yes they > > may have set a very high value). So I was wondering why it isn't > possible. > > I know it's bad for security, but still. > > I think the solution is to: > > 1) Change the password policy to a very high value (even in years), as Will > suggested in this thread. > > 2) Use service accounts (service-add) with keytabs for services which do > not > need to change their passwords, given they authenticate with keytab which > does > not suffer from password complexity issues. > > 3) Contribute to FreeIPA and make --maxlife 0 or similar mean unlimited > validity (https://fedorahosted.org/freeipa/ticket/2795) :-) > > > > On Thu, Aug 28, 2014 at 6:18 PM, Dmitri Pal wrote: > > > >> On 08/28/2014 04:18 PM, Zip Ly wrote: > >> > >> Hi, > >> > >> > >> I'm trying to change a user password without reset. > >> If I use the (primary) admin to change the password then it doesn't > need a > >> password reset, because the expire lifetime is 90 days. > >> > >> But if I create a second admin, then every password change made by the > >> second admin needs a password reset, because the password is expired > >> immediately. > >> > >> 1a) Does anyone knows how I can change the policy/privilege of the > >> second admin so every password change doesn't require a reset? 1b) and > is > >> it possible to set a different expire lifetime like zero for unlimited > >> lifetime? > >> > >> > >> You are probably changing password for the admin himself. > >> Isn't there a different flow when admin changes his own password? > >> > >> > >> > >> It's almost the same bugreport as > >> https://fedorahosted.org/freeipa/ticket/2795 but the difference is > there > >> should be 2 policies: one for changing your own password and another for > >> resetting other users password. > >> > >> > >> 2) Are there more differences in policies between the first (primary) > >> admin and the second admin you just created? > >> > >> > >> Kind regards, > >> > >> Zip > >> > >> > >> > >> > >> > >> > >> > >> -- > >> Thank you, > >> Dmitri Pal > >> > >> Sr. Engineering Manager IdM portfolio > >> Red Hat, Inc. > >> > >> > >> -- > >> Manage your subscription for the Freeipa-users mailing list: > >> https://www.redhat.com/mailman/listinfo/freeipa-users > >> Go To http://freeipa.org for more info on the project > >> > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kfiresmith at gmail.com Tue Sep 2 12:02:41 2014 From: kfiresmith at gmail.com (Kodiak Firesmith) Date: Tue, 2 Sep 2014 08:02:41 -0400 Subject: [Freeipa-users] IRC channel dead? Message-ID: Hey Folks, New FreeIPA user here, but a long-time IRC user. I hopped on irc.freenode.net #freeipa as mentioned in the Contribute page of the FreeIPA website and found I was the only user. Did the channel move or is it dead? Thanks! - Kodiak From jpazdziora at redhat.com Tue Sep 2 12:17:00 2014 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Tue, 2 Sep 2014 14:17:00 +0200 Subject: [Freeipa-users] IRC channel dead? In-Reply-To: References: Message-ID: <20140902121700.GF1558@redhat.com> On Tue, Sep 02, 2014 at 08:02:41AM -0400, Kodiak Firesmith wrote: > Hey Folks, > New FreeIPA user here, but a long-time IRC user. I hopped on > irc.freenode.net #freeipa as mentioned in the Contribute page of the > FreeIPA website and found I was the only user. Did the channel move > or is it dead? There are currently 115 users there. Maybe some sort of network slip and you are connected to the wrong part of the network? -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From kfiresmith at gmail.com Tue Sep 2 12:19:08 2014 From: kfiresmith at gmail.com (Kodiak Firesmith) Date: Tue, 2 Sep 2014 08:19:08 -0400 Subject: [Freeipa-users] IRC channel dead? In-Reply-To: <20140902121700.GF1558@redhat.com> References: <20140902121700.GF1558@redhat.com> Message-ID: I should never post pre-coffee... I was still on oftc.net (which I'm never on) to check out cloud-init. Sorry folks On Tue, Sep 2, 2014 at 8:17 AM, Jan Pazdziora wrote: > On Tue, Sep 02, 2014 at 08:02:41AM -0400, Kodiak Firesmith wrote: >> Hey Folks, >> New FreeIPA user here, but a long-time IRC user. I hopped on >> irc.freenode.net #freeipa as mentioned in the Contribute page of the >> FreeIPA website and found I was the only user. Did the channel move >> or is it dead? > > There are currently 115 users there. Maybe some sort of network slip > and you are connected to the wrong part of the network? > > -- > Jan Pazdziora > Principal Software Engineer, Identity Management Engineering, Red Hat From mkosek at redhat.com Tue Sep 2 15:19:51 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 02 Sep 2014 17:19:51 +0200 Subject: [Freeipa-users] Password expiration dates are different when being resetted by the (primary) admin and a different admin In-Reply-To: References: <53FF5665.9010403@redhat.com> <54045333.5080102@redhat.com> Message-ID: <5405E017.60309@redhat.com> On 09/02/2014 10:42 AM, Zip Ly wrote: > @Martin > > The second admin is my service account. I use this account to communicate > with our webapplication (it uses keytab and post/curl json to ipa). I can > add users without a problem. But when it comes to changing password, the > password is expired immediately. > > I have only one password policy and that's the 'global_policy'. The > --maxlife you mentioned only affect this policy. If I use this service > account to change the user password, the policy is ignored just as stated > in the ipa wiki. Even if I set the --maxlife to 200, if the password is > being resetted by this first admin, then the expire date is set to 90 days > or expired immediately by the second admin/service account. > > That's why I want to know how to change this 90 days and also apply it for > the service account. What version of FreeIPA do you use? Maybe you are hitting https://fedorahosted.org/freeipa/ticket/3968 that we fixed in FreeIPA 3.3.3. Martin From cwhittl at gmail.com Tue Sep 2 19:34:02 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Tue, 2 Sep 2014 14:34:02 -0500 Subject: [Freeipa-users] Search Base issues In-Reply-To: References: <540585B3.9030606@redhat.com> Message-ID: Ok Dmitri, I got it added using what you sent and the following links https://git.fedorahosted.org/cgit/slapi-nis.git/tree/doc/sch-getting-started.txt and https://www.redhat.com/archives/freeipa-users/2009-August/msg00013.html I think i'm 90% there with the caveat that I can't seem to see what permissions I need to give a user to view my NIS "view". Right now Directory Manager can see it but that is it. Any ideas? On Tue, Sep 2, 2014 at 9:00 AM, Chris Whittle wrote: > Thanks Dimitri, before I get too far this rabbit hole (cause it looks a > little scary) let me make sure I get it. > > So using Slap-NIS I should be able to create a view into FreeIPA that > would show only a subset of user based on something like a group or an > attribute? > > Then using the built in MAC Directory Utility (or any LDAP client) I > should be able to use that Slap-NIS view as a searchbase and it would > return just people I wanted. This could be used keep anyone outside that > view from logging in? > > I'm sorry for the noob questions but there isn't a lot of good > documentation on SlapNIS from first glance and I don't want to spend 2 days > figuring it out if it's not going to work. > > As always extremely appreciated! > Whitt > > > > > > > > On Tue, Sep 2, 2014 at 3:54 AM, Dmitri Pal wrote: > >> On 09/02/2014 03:04 AM, Chris Whittle wrote: >> >> I am trying to limit who can login to my macs and I'm having to stick to >> what OSX will let me do. >> >> Currently I can only limit users using the searchbase and right now >> it's "cn=users,cn=accounts,dc=DOMAIN,dc=com" >> >> This works fine unless I wanted to create a user that I wanted in LDAP >> for other purposes but not to login. >> >> So my questions are, >> A)Can we create different OUs in FreeIPA like most LDAP servers? >> >> >> You can use slapi-nis to create an alternative view of the tree or trees >> and point your special client to that tree. >> There you might be able to expose a small subset of users that match your >> special criteria. >> The slapi-nis and compat docs are in the doc folder in the corresponding >> git repo. >> >> IPA uses compat tree for its own purposes but you can tweak it if you >> need or create a different view. >> >> HTH >> >> >> >> B)If not anyone have any idea on how I could do this with OSX's >> directory Utility? >> >> Thanks! >> >> >> >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Tue Sep 2 20:06:22 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 02 Sep 2014 22:06:22 +0200 Subject: [Freeipa-users] Search Base issues In-Reply-To: References: <540585B3.9030606@redhat.com> Message-ID: <5406233E.3040705@redhat.com> On 09/02/2014 09:34 PM, Chris Whittle wrote: > Ok Dmitri, I got it added using what you sent and the following links > https://git.fedorahosted.org/cgit/slapi-nis.git/tree/doc/sch-getting-started.txt > and > https://www.redhat.com/archives/freeipa-users/2009-August/msg00013.html > > I think i'm 90% there with the caveat that I can't seem to see what > permissions I need to give a user to view my NIS "view". Right now > Directory Manager can see it but that is it. > > Any ideas? > You got me :-) I would defer to specialist in this area to solve this problem. > > > On Tue, Sep 2, 2014 at 9:00 AM, Chris Whittle > wrote: > > Thanks Dimitri, before I get too far this rabbit hole (cause it > looks a little scary) let me make sure I get it. > > So using Slap-NIS I should be able to create a view into FreeIPA > that would show only a subset of user based on something like a > group or an attribute? > > Then using the built in MAC Directory Utility (or any LDAP client) > I should be able to use that Slap-NIS view as a searchbase and it > would return just people I wanted. This could be used keep anyone > outside that view from logging in? > > I'm sorry for the noob questions but there isn't a lot of good > documentation on SlapNIS from first glance and I don't want to > spend 2 days figuring it out if it's not going to work. > > As always extremely appreciated! > Whitt > > > > > > > > On Tue, Sep 2, 2014 at 3:54 AM, Dmitri Pal > wrote: > > On 09/02/2014 03:04 AM, Chris Whittle wrote: >> I am trying to limit who can login to my macs and I'm having >> to stick to what OSX will let me do. >> >> Currently I can only limit users using the searchbase and >> right now it's "cn=users,cn=accounts,dc=DOMAIN,dc=com" >> >> This works fine unless I wanted to create a user that I >> wanted in LDAP for other purposes but not to login. >> >> So my questions are, >> A)Can we create different OUs in FreeIPA like most LDAP servers? > > You can use slapi-nis to create an alternative view of the > tree or trees and point your special client to that tree. > There you might be able to expose a small subset of users that > match your special criteria. > The slapi-nis and compat docs are in the doc folder in the > corresponding git repo. > > IPA uses compat tree for its own purposes but you can tweak it > if you need or create a different view. > > HTH > > > >> B)If not anyone have any idea on how I could do this with >> OSX's directory Utility? >> >> Thanks! >> >> >> > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cwhittl at gmail.com Tue Sep 2 20:08:48 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Tue, 2 Sep 2014 15:08:48 -0500 Subject: [Freeipa-users] Search Base issues In-Reply-To: <5406233E.3040705@redhat.com> References: <540585B3.9030606@redhat.com> <5406233E.3040705@redhat.com> Message-ID: hmmm... Is there not a permission or role in freeIPA that I could give a group or role just to see everything in my CN "cn=canlogin,cn=compat,dc=DOMAIN,dc=com" On Tue, Sep 2, 2014 at 3:06 PM, Dmitri Pal wrote: > On 09/02/2014 09:34 PM, Chris Whittle wrote: > > Ok Dmitri, I got it added using what you sent and the following links > > https://git.fedorahosted.org/cgit/slapi-nis.git/tree/doc/sch-getting-started.txt > and > https://www.redhat.com/archives/freeipa-users/2009-August/msg00013.html > > I think i'm 90% there with the caveat that I can't seem to see what > permissions I need to give a user to view my NIS "view". Right now > Directory Manager can see it but that is it. > > Any ideas? > > You got me :-) > I would defer to specialist in this area to solve this problem. > > > > > On Tue, Sep 2, 2014 at 9:00 AM, Chris Whittle wrote: > >> Thanks Dimitri, before I get too far this rabbit hole (cause it looks a >> little scary) let me make sure I get it. >> >> So using Slap-NIS I should be able to create a view into FreeIPA that >> would show only a subset of user based on something like a group or an >> attribute? >> >> Then using the built in MAC Directory Utility (or any LDAP client) I >> should be able to use that Slap-NIS view as a searchbase and it would >> return just people I wanted. This could be used keep anyone outside that >> view from logging in? >> >> I'm sorry for the noob questions but there isn't a lot of good >> documentation on SlapNIS from first glance and I don't want to spend 2 days >> figuring it out if it's not going to work. >> >> As always extremely appreciated! >> Whitt >> >> >> >> >> >> >> >> On Tue, Sep 2, 2014 at 3:54 AM, Dmitri Pal wrote: >> >>> On 09/02/2014 03:04 AM, Chris Whittle wrote: >>> >>> I am trying to limit who can login to my macs and I'm having to stick to >>> what OSX will let me do. >>> >>> Currently I can only limit users using the searchbase and right now >>> it's "cn=users,cn=accounts,dc=DOMAIN,dc=com" >>> >>> This works fine unless I wanted to create a user that I wanted in LDAP >>> for other purposes but not to login. >>> >>> So my questions are, >>> A)Can we create different OUs in FreeIPA like most LDAP servers? >>> >>> >>> You can use slapi-nis to create an alternative view of the tree or >>> trees and point your special client to that tree. >>> There you might be able to expose a small subset of users that match >>> your special criteria. >>> The slapi-nis and compat docs are in the doc folder in the corresponding >>> git repo. >>> >>> IPA uses compat tree for its own purposes but you can tweak it if you >>> need or create a different view. >>> >>> HTH >>> >>> >>> >>> B)If not anyone have any idea on how I could do this with OSX's >>> directory Utility? >>> >>> Thanks! >>> >>> >>> >>> >>> >>> -- >>> Thank you, >>> Dmitri Pal >>> >>> Sr. Engineering Manager IdM portfolio >>> Red Hat, Inc. >>> >>> >> > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Tue Sep 2 20:24:22 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 02 Sep 2014 22:24:22 +0200 Subject: [Freeipa-users] Search Base issues In-Reply-To: References: <540585B3.9030606@redhat.com> <5406233E.3040705@redhat.com> Message-ID: <54062776.7040503@redhat.com> On 09/02/2014 10:08 PM, Chris Whittle wrote: > hmmm... > Is there not a permission or role in freeIPA that I could give a group > or role just to see everything in > my CN "cn=canlogin,cn=compat,dc=DOMAIN,dc=com" I thint it might be related to the new permission system that was released in 4.0. Stay tuned, the chivalry is on the way... > > > > On Tue, Sep 2, 2014 at 3:06 PM, Dmitri Pal > wrote: > > On 09/02/2014 09:34 PM, Chris Whittle wrote: >> Ok Dmitri, I got it added using what you sent and the following >> links >> https://git.fedorahosted.org/cgit/slapi-nis.git/tree/doc/sch-getting-started.txt >> and >> https://www.redhat.com/archives/freeipa-users/2009-August/msg00013.html >> >> I think i'm 90% there with the caveat that I can't seem to see >> what permissions I need to give a user to view my NIS "view". >> Right now Directory Manager can see it but that is it. >> >> Any ideas? >> > You got me :-) > I would defer to specialist in this area to solve this problem. > > >> >> >> On Tue, Sep 2, 2014 at 9:00 AM, Chris Whittle > > wrote: >> >> Thanks Dimitri, before I get too far this rabbit hole (cause >> it looks a little scary) let me make sure I get it. >> >> So using Slap-NIS I should be able to create a view into >> FreeIPA that would show only a subset of user based on >> something like a group or an attribute? >> >> Then using the built in MAC Directory Utility (or any LDAP >> client) I should be able to use that Slap-NIS view as a >> searchbase and it would return just people I wanted. This >> could be used keep anyone outside that view from logging in? >> >> I'm sorry for the noob questions but there isn't a lot of >> good documentation on SlapNIS from first glance and I don't >> want to spend 2 days figuring it out if it's not going to work. >> >> As always extremely appreciated! >> Whitt >> >> >> >> >> >> >> >> On Tue, Sep 2, 2014 at 3:54 AM, Dmitri Pal > > wrote: >> >> On 09/02/2014 03:04 AM, Chris Whittle wrote: >>> I am trying to limit who can login to my macs and I'm >>> having to stick to what OSX will let me do. >>> >>> Currently I can only limit users using the searchbase >>> and right now it's "cn=users,cn=accounts,dc=DOMAIN,dc=com" >>> >>> This works fine unless I wanted to create a user that I >>> wanted in LDAP for other purposes but not to login. >>> >>> So my questions are, >>> A)Can we create different OUs in FreeIPA like most LDAP >>> servers? >> >> You can use slapi-nis to create an alternative view of >> the tree or trees and point your special client to that tree. >> There you might be able to expose a small subset of users >> that match your special criteria. >> The slapi-nis and compat docs are in the doc folder in >> the corresponding git repo. >> >> IPA uses compat tree for its own purposes but you can >> tweak it if you need or create a different view. >> >> HTH >> >> >> >>> B)If not anyone have any idea on how I could do this >>> with OSX's directory Utility? >>> >>> Thanks! >>> >>> >>> >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> >> >> > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cwhittl at gmail.com Tue Sep 2 20:26:13 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Tue, 2 Sep 2014 15:26:13 -0500 Subject: [Freeipa-users] Search Base issues In-Reply-To: <54062776.7040503@redhat.com> References: <540585B3.9030606@redhat.com> <5406233E.3040705@redhat.com> <54062776.7040503@redhat.com> Message-ID: Thanks Dmitri, I'm so close I can almost see the end! On Tue, Sep 2, 2014 at 3:24 PM, Dmitri Pal wrote: > On 09/02/2014 10:08 PM, Chris Whittle wrote: > > hmmm... > Is there not a permission or role in freeIPA that I could give a group or > role just to see everything in > my CN "cn=canlogin,cn=compat,dc=DOMAIN,dc=com" > > > I thint it might be related to the new permission system that was released > in 4.0. > Stay tuned, the chivalry is on the way... > > > > > > On Tue, Sep 2, 2014 at 3:06 PM, Dmitri Pal wrote: > >> On 09/02/2014 09:34 PM, Chris Whittle wrote: >> >> Ok Dmitri, I got it added using what you sent and the following links >> >> https://git.fedorahosted.org/cgit/slapi-nis.git/tree/doc/sch-getting-started.txt >> and >> https://www.redhat.com/archives/freeipa-users/2009-August/msg00013.html >> >> I think i'm 90% there with the caveat that I can't seem to see what >> permissions I need to give a user to view my NIS "view". Right now >> Directory Manager can see it but that is it. >> >> Any ideas? >> >> You got me :-) >> I would defer to specialist in this area to solve this problem. >> >> >> >> >> On Tue, Sep 2, 2014 at 9:00 AM, Chris Whittle wrote: >> >>> Thanks Dimitri, before I get too far this rabbit hole (cause it looks a >>> little scary) let me make sure I get it. >>> >>> So using Slap-NIS I should be able to create a view into FreeIPA that >>> would show only a subset of user based on something like a group or an >>> attribute? >>> >>> Then using the built in MAC Directory Utility (or any LDAP client) I >>> should be able to use that Slap-NIS view as a searchbase and it would >>> return just people I wanted. This could be used keep anyone outside that >>> view from logging in? >>> >>> I'm sorry for the noob questions but there isn't a lot of good >>> documentation on SlapNIS from first glance and I don't want to spend 2 days >>> figuring it out if it's not going to work. >>> >>> As always extremely appreciated! >>> Whitt >>> >>> >>> >>> >>> >>> >>> >>> On Tue, Sep 2, 2014 at 3:54 AM, Dmitri Pal wrote: >>> >>>> On 09/02/2014 03:04 AM, Chris Whittle wrote: >>>> >>>> I am trying to limit who can login to my macs and I'm having to stick >>>> to what OSX will let me do. >>>> >>>> Currently I can only limit users using the searchbase and right now >>>> it's "cn=users,cn=accounts,dc=DOMAIN,dc=com" >>>> >>>> This works fine unless I wanted to create a user that I wanted in >>>> LDAP for other purposes but not to login. >>>> >>>> So my questions are, >>>> A)Can we create different OUs in FreeIPA like most LDAP servers? >>>> >>>> >>>> You can use slapi-nis to create an alternative view of the tree or >>>> trees and point your special client to that tree. >>>> There you might be able to expose a small subset of users that match >>>> your special criteria. >>>> The slapi-nis and compat docs are in the doc folder in the >>>> corresponding git repo. >>>> >>>> IPA uses compat tree for its own purposes but you can tweak it if you >>>> need or create a different view. >>>> >>>> HTH >>>> >>>> >>>> >>>> B)If not anyone have any idea on how I could do this with OSX's >>>> directory Utility? >>>> >>>> Thanks! >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Thank you, >>>> Dmitri Pal >>>> >>>> Sr. Engineering Manager IdM portfolio >>>> Red Hat, Inc. >>>> >>>> >>> >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> >> > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Sep 2 20:31:28 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 02 Sep 2014 16:31:28 -0400 Subject: [Freeipa-users] Search Base issues In-Reply-To: References: <540585B3.9030606@redhat.com> <5406233E.3040705@redhat.com> Message-ID: <54062920.4010605@redhat.com> Chris Whittle wrote: > hmmm... > Is there not a permission or role in freeIPA that I could give a group > or role just to see everything in > my CN "cn=canlogin,cn=compat,dc=DOMAIN,dc=com" Can you provide more details on what you're doing, and how you are binding? Can you search the cn=users,cn=compat,dc=DOMAIN,dc=com tree? AFAICT you should be able to read cn=compat as long as you bind as a user. rob > > > > On Tue, Sep 2, 2014 at 3:06 PM, Dmitri Pal > wrote: > > On 09/02/2014 09:34 PM, Chris Whittle wrote: >> Ok Dmitri, I got it added using what you sent and the following links >> https://git.fedorahosted.org/cgit/slapi-nis.git/tree/doc/sch-getting-started.txt >> and >> https://www.redhat.com/archives/freeipa-users/2009-August/msg00013.html >> >> I think i'm 90% there with the caveat that I can't seem to see >> what permissions I need to give a user to view my NIS "view". >> Right now Directory Manager can see it but that is it. >> >> Any ideas? >> > You got me :-) > I would defer to specialist in this area to solve this problem. > > >> >> >> On Tue, Sep 2, 2014 at 9:00 AM, Chris Whittle > > wrote: >> >> Thanks Dimitri, before I get too far this rabbit hole (cause >> it looks a little scary) let me make sure I get it. >> >> So using Slap-NIS I should be able to create a view into >> FreeIPA that would show only a subset of user based on >> something like a group or an attribute? >> >> Then using the built in MAC Directory Utility (or any LDAP >> client) I should be able to use that Slap-NIS view as a >> searchbase and it would return just people I wanted. This >> could be used keep anyone outside that view from logging in? >> >> I'm sorry for the noob questions but there isn't a lot of good >> documentation on SlapNIS from first glance and I don't want to >> spend 2 days figuring it out if it's not going to work. >> >> As always extremely appreciated! >> Whitt >> >> >> >> >> >> >> >> On Tue, Sep 2, 2014 at 3:54 AM, Dmitri Pal > > wrote: >> >> On 09/02/2014 03:04 AM, Chris Whittle wrote: >>> I am trying to limit who can login to my macs and I'm >>> having to stick to what OSX will let me do. >>> >>> Currently I can only limit users using the searchbase and >>> right now it's "cn=users,cn=accounts,dc=DOMAIN,dc=com" >>> >>> This works fine unless I wanted to create a user that I >>> wanted in LDAP for other purposes but not to login. >>> >>> So my questions are, >>> A)Can we create different OUs in FreeIPA like most LDAP >>> servers? >> >> You can use slapi-nis to create an alternative view of the >> tree or trees and point your special client to that tree. >> There you might be able to expose a small subset of users >> that match your special criteria. >> The slapi-nis and compat docs are in the doc folder in the >> corresponding git repo. >> >> IPA uses compat tree for its own purposes but you can >> tweak it if you need or create a different view. >> >> HTH >> >> >> >>> B)If not anyone have any idea on how I could do this with >>> OSX's directory Utility? >>> >>> Thanks! >>> >>> >>> >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> >> >> > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > > From cwhittl at gmail.com Tue Sep 2 20:40:22 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Tue, 2 Sep 2014 15:40:22 -0500 Subject: [Freeipa-users] Search Base issues In-Reply-To: <54062920.4010605@redhat.com> References: <540585B3.9030606@redhat.com> <5406233E.3040705@redhat.com> <54062920.4010605@redhat.com> Message-ID: For testing I'm using ldapsearch -LLL -H ldaps://DOMAIN636 -x -D "cn=directory manager" -w 'nachopassword' -b "cn=canlogin,cn=compat,dc=domain,dc=com" If I do it with directory manager it works fine, if I use my automation user (just a generic user with no extra permissions) it returns nothing, no error, just empty space if I add -v (verbose) i get ldap_initialize( ldaps://domain.com:636/??base ) filter: (objectclass=*) requesting: All userApplication attributes Thanks everyone! On Tue, Sep 2, 2014 at 3:31 PM, Rob Crittenden wrote: > Chris Whittle wrote: > > hmmm... > > Is there not a permission or role in freeIPA that I could give a group > > or role just to see everything in > > my CN "cn=canlogin,cn=compat,dc=DOMAIN,dc=com" > > Can you provide more details on what you're doing, and how you are > binding? Can you search the cn=users,cn=compat,dc=DOMAIN,dc=com tree? > > AFAICT you should be able to read cn=compat as long as you bind as a user. > > rob > > > > > > > > > On Tue, Sep 2, 2014 at 3:06 PM, Dmitri Pal > > wrote: > > > > On 09/02/2014 09:34 PM, Chris Whittle wrote: > >> Ok Dmitri, I got it added using what you sent and the following > links > >> > https://git.fedorahosted.org/cgit/slapi-nis.git/tree/doc/sch-getting-started.txt > >> and > >> > https://www.redhat.com/archives/freeipa-users/2009-August/msg00013.html > >> > >> I think i'm 90% there with the caveat that I can't seem to see > >> what permissions I need to give a user to view my NIS "view". > >> Right now Directory Manager can see it but that is it. > >> > >> Any ideas? > >> > > You got me :-) > > I would defer to specialist in this area to solve this problem. > > > > > >> > >> > >> On Tue, Sep 2, 2014 at 9:00 AM, Chris Whittle >> > wrote: > >> > >> Thanks Dimitri, before I get too far this rabbit hole (cause > >> it looks a little scary) let me make sure I get it. > >> > >> So using Slap-NIS I should be able to create a view into > >> FreeIPA that would show only a subset of user based on > >> something like a group or an attribute? > >> > >> Then using the built in MAC Directory Utility (or any LDAP > >> client) I should be able to use that Slap-NIS view as a > >> searchbase and it would return just people I wanted. This > >> could be used keep anyone outside that view from logging in? > >> > >> I'm sorry for the noob questions but there isn't a lot of good > >> documentation on SlapNIS from first glance and I don't want to > >> spend 2 days figuring it out if it's not going to work. > >> > >> As always extremely appreciated! > >> Whitt > >> > >> > >> > >> > >> > >> > >> > >> On Tue, Sep 2, 2014 at 3:54 AM, Dmitri Pal >> > wrote: > >> > >> On 09/02/2014 03:04 AM, Chris Whittle wrote: > >>> I am trying to limit who can login to my macs and I'm > >>> having to stick to what OSX will let me do. > >>> > >>> Currently I can only limit users using the searchbase and > >>> right now it's "cn=users,cn=accounts,dc=DOMAIN,dc=com" > >>> > >>> This works fine unless I wanted to create a user that I > >>> wanted in LDAP for other purposes but not to login. > >>> > >>> So my questions are, > >>> A)Can we create different OUs in FreeIPA like most LDAP > >>> servers? > >> > >> You can use slapi-nis to create an alternative view of the > >> tree or trees and point your special client to that tree. > >> There you might be able to expose a small subset of users > >> that match your special criteria. > >> The slapi-nis and compat docs are in the doc folder in the > >> corresponding git repo. > >> > >> IPA uses compat tree for its own purposes but you can > >> tweak it if you need or create a different view. > >> > >> HTH > >> > >> > >> > >>> B)If not anyone have any idea on how I could do this with > >>> OSX's directory Utility? > >>> > >>> Thanks! > >>> > >>> > >>> > >> > >> > >> -- > >> Thank you, > >> Dmitri Pal > >> > >> Sr. Engineering Manager IdM portfolio > >> Red Hat, Inc. > >> > >> > >> > > > > > > -- > > Thank you, > > Dmitri Pal > > > > Sr. Engineering Manager IdM portfolio > > Red Hat, Inc. > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cwhittl at gmail.com Tue Sep 2 20:43:24 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Tue, 2 Sep 2014 15:43:24 -0500 Subject: [Freeipa-users] Search Base issues In-Reply-To: References: <540585B3.9030606@redhat.com> <5406233E.3040705@redhat.com> <54062920.4010605@redhat.com> Message-ID: If I do this ldapsearch -LLL -H ldaps://DOMAIN:636 -x -D "uid=mac_slave,cn=users,cn=accounts,dc=domain,dc=com" -w 'nachopassword' -b "uid=awesomeuser,cn=users,cn=accounts,dc=domain,dc=com" It works fine **Mac_Slave is my automation user. On Tue, Sep 2, 2014 at 3:40 PM, Chris Whittle wrote: > For testing I'm using > > ldapsearch -LLL -H ldaps://DOMAIN636 -x -D "cn=directory manager" -w > 'nachopassword' -b "cn=canlogin,cn=compat,dc=domain,dc=com" > If I do it with directory manager it works fine, if I use my automation > user (just a generic user with no extra permissions) it returns nothing, no > error, just empty space > > if I add -v (verbose) i get > > ldap_initialize( ldaps://domain.com:636/??base ) > > filter: (objectclass=*) > > requesting: All userApplication attributes > > > Thanks everyone! > > On Tue, Sep 2, 2014 at 3:31 PM, Rob Crittenden > wrote: > >> Chris Whittle wrote: >> > hmmm... >> > Is there not a permission or role in freeIPA that I could give a group >> > or role just to see everything in >> > my CN "cn=canlogin,cn=compat,dc=DOMAIN,dc=com" >> >> Can you provide more details on what you're doing, and how you are >> binding? Can you search the cn=users,cn=compat,dc=DOMAIN,dc=com tree? >> >> AFAICT you should be able to read cn=compat as long as you bind as a user. >> >> rob >> >> > >> > >> > >> > On Tue, Sep 2, 2014 at 3:06 PM, Dmitri Pal > > > wrote: >> > >> > On 09/02/2014 09:34 PM, Chris Whittle wrote: >> >> Ok Dmitri, I got it added using what you sent and the following >> links >> >> >> https://git.fedorahosted.org/cgit/slapi-nis.git/tree/doc/sch-getting-started.txt >> >> and >> >> >> https://www.redhat.com/archives/freeipa-users/2009-August/msg00013.html >> >> >> >> I think i'm 90% there with the caveat that I can't seem to see >> >> what permissions I need to give a user to view my NIS "view". >> >> Right now Directory Manager can see it but that is it. >> >> >> >> Any ideas? >> >> >> > You got me :-) >> > I would defer to specialist in this area to solve this problem. >> > >> > >> >> >> >> >> >> On Tue, Sep 2, 2014 at 9:00 AM, Chris Whittle > >> > wrote: >> >> >> >> Thanks Dimitri, before I get too far this rabbit hole (cause >> >> it looks a little scary) let me make sure I get it. >> >> >> >> So using Slap-NIS I should be able to create a view into >> >> FreeIPA that would show only a subset of user based on >> >> something like a group or an attribute? >> >> >> >> Then using the built in MAC Directory Utility (or any LDAP >> >> client) I should be able to use that Slap-NIS view as a >> >> searchbase and it would return just people I wanted. This >> >> could be used keep anyone outside that view from logging in? >> >> >> >> I'm sorry for the noob questions but there isn't a lot of good >> >> documentation on SlapNIS from first glance and I don't want to >> >> spend 2 days figuring it out if it's not going to work. >> >> >> >> As always extremely appreciated! >> >> Whitt >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Tue, Sep 2, 2014 at 3:54 AM, Dmitri Pal > >> > wrote: >> >> >> >> On 09/02/2014 03:04 AM, Chris Whittle wrote: >> >>> I am trying to limit who can login to my macs and I'm >> >>> having to stick to what OSX will let me do. >> >>> >> >>> Currently I can only limit users using the searchbase and >> >>> right now it's "cn=users,cn=accounts,dc=DOMAIN,dc=com" >> >>> >> >>> This works fine unless I wanted to create a user that I >> >>> wanted in LDAP for other purposes but not to login. >> >>> >> >>> So my questions are, >> >>> A)Can we create different OUs in FreeIPA like most LDAP >> >>> servers? >> >> >> >> You can use slapi-nis to create an alternative view of the >> >> tree or trees and point your special client to that tree. >> >> There you might be able to expose a small subset of users >> >> that match your special criteria. >> >> The slapi-nis and compat docs are in the doc folder in the >> >> corresponding git repo. >> >> >> >> IPA uses compat tree for its own purposes but you can >> >> tweak it if you need or create a different view. >> >> >> >> HTH >> >> >> >> >> >> >> >>> B)If not anyone have any idea on how I could do this with >> >>> OSX's directory Utility? >> >>> >> >>> Thanks! >> >>> >> >>> >> >>> >> >> >> >> >> >> -- >> >> Thank you, >> >> Dmitri Pal >> >> >> >> Sr. Engineering Manager IdM portfolio >> >> Red Hat, Inc. >> >> >> >> >> >> >> > >> > >> > -- >> > Thank you, >> > Dmitri Pal >> > >> > Sr. Engineering Manager IdM portfolio >> > Red Hat, Inc. >> > >> > >> > >> > >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Sep 2 21:09:04 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 02 Sep 2014 17:09:04 -0400 Subject: [Freeipa-users] Search Base issues In-Reply-To: References: <540585B3.9030606@redhat.com> <5406233E.3040705@redhat.com> <54062920.4010605@redhat.com> Message-ID: <540631F0.1020805@redhat.com> Chris Whittle wrote: > If I do this > > ldapsearch -LLL -H ldaps://DOMAIN:636 -x -D > "uid=mac_slave,cn=users,cn=accounts,dc=domain,dc=com" -w 'nachopassword' > -b "uid=awesomeuser,cn=users,cn=accounts,dc=domain,dc=com" > > It works fine AFAICT there currently isn't a permission for the compat tree. The admin user can do it via 'Admin can manage any entry" and of course DM can do it because it can do anything. A temporary workaround would be to add an aci manually: dn: dc=example,dc=com changetype: modify add: aci aci: (targetattr = "*")(target = "ldap:///uid=*,cn=canlogin,cn=compat,dc=example,dc=com")(version 3.0;acl "Read canlogin compat tree";allow (compare,read,search) userdn = "ldap:///all";) This won't show up as a permission and will grant all authenticated users read access to the canlogin compat tree. I'm assuming here this contains entries keyed on uid. rob > > **Mac_Slave is my automation user. > > > > > On Tue, Sep 2, 2014 at 3:40 PM, Chris Whittle > wrote: > > For testing I'm using > > ldapsearch -LLL -H ldaps://DOMAIN636 -x -D "cn=directory manager" -w > 'nachopassword' -b "cn=canlogin,cn=compat,dc=domain,dc=com" > > If I do it with directory manager it works fine, if I use my > automation user (just a generic user with no extra permissions) it > returns nothing, no error, just empty space > > if I add -v (verbose) i get > > ldap_initialize( ldaps://domain.com:636/??base > ) > > filter: (objectclass=*) > > requesting: All userApplication attributes > > > Thanks everyone! > > > On Tue, Sep 2, 2014 at 3:31 PM, Rob Crittenden > wrote: > > Chris Whittle wrote: > > hmmm... > > Is there not a permission or role in freeIPA that I could give > a group > > or role just to see everything in > > my CN "cn=canlogin,cn=compat,dc=DOMAIN,dc=com" > > Can you provide more details on what you're doing, and how you are > binding? Can you search the cn=users,cn=compat,dc=DOMAIN,dc=com > tree? > > AFAICT you should be able to read cn=compat as long as you bind > as a user. > > rob > > > > > > > > > On Tue, Sep 2, 2014 at 3:06 PM, Dmitri Pal > > >> wrote: > > > > On 09/02/2014 09:34 PM, Chris Whittle wrote: > >> Ok Dmitri, I got it added using what you sent and the > following links > >> > https://git.fedorahosted.org/cgit/slapi-nis.git/tree/doc/sch-getting-started.txt > >> and > >> > https://www.redhat.com/archives/freeipa-users/2009-August/msg00013.html > >> > >> I think i'm 90% there with the caveat that I can't seem > to see > >> what permissions I need to give a user to view my NIS "view". > >> Right now Directory Manager can see it but that is it. > >> > >> Any ideas? > >> > > You got me :-) > > I would defer to specialist in this area to solve this > problem. > > > > > >> > >> > >> On Tue, Sep 2, 2014 at 9:00 AM, Chris Whittle > > >> >> wrote: > >> > >> Thanks Dimitri, before I get too far this rabbit hole > (cause > >> it looks a little scary) let me make sure I get it. > >> > >> So using Slap-NIS I should be able to create a view into > >> FreeIPA that would show only a subset of user based on > >> something like a group or an attribute? > >> > >> Then using the built in MAC Directory Utility (or any > LDAP > >> client) I should be able to use that Slap-NIS view as a > >> searchbase and it would return just people I wanted. > This > >> could be used keep anyone outside that view from > logging in? > >> > >> I'm sorry for the noob questions but there isn't a > lot of good > >> documentation on SlapNIS from first glance and I > don't want to > >> spend 2 days figuring it out if it's not going to work. > >> > >> As always extremely appreciated! > >> Whitt > >> > >> > >> > >> > >> > >> > >> > >> On Tue, Sep 2, 2014 at 3:54 AM, Dmitri Pal > > >> >> wrote: > >> > >> On 09/02/2014 03:04 AM, Chris Whittle wrote: > >>> I am trying to limit who can login to my macs > and I'm > >>> having to stick to what OSX will let me do. > >>> > >>> Currently I can only limit users using the > searchbase and > >>> right now it's > "cn=users,cn=accounts,dc=DOMAIN,dc=com" > >>> > >>> This works fine unless I wanted to create a user > that I > >>> wanted in LDAP for other purposes but not to login. > >>> > >>> So my questions are, > >>> A)Can we create different OUs in FreeIPA like > most LDAP > >>> servers? > >> > >> You can use slapi-nis to create an alternative > view of the > >> tree or trees and point your special client to > that tree. > >> There you might be able to expose a small subset > of users > >> that match your special criteria. > >> The slapi-nis and compat docs are in the doc > folder in the > >> corresponding git repo. > >> > >> IPA uses compat tree for its own purposes but you can > >> tweak it if you need or create a different view. > >> > >> HTH > >> > >> > >> > >>> B)If not anyone have any idea on how I could do > this with > >>> OSX's directory Utility? > >>> > >>> Thanks! > >>> > >>> > >>> > >> > >> > >> -- > >> Thank you, > >> Dmitri Pal > >> > >> Sr. Engineering Manager IdM portfolio > >> Red Hat, Inc. > >> > >> > >> > > > > > > -- > > Thank you, > > Dmitri Pal > > > > Sr. Engineering Manager IdM portfolio > > Red Hat, Inc. > > > > > > > > > > > From Dennis.Ott at mckesson.com Tue Sep 2 23:08:40 2014 From: Dennis.Ott at mckesson.com (Ott, Dennis) Date: Tue, 2 Sep 2014 23:08:40 +0000 Subject: [Freeipa-users] Cert Renewal In-Reply-To: <53FCE594.5040106@redhat.com> References: <53FBBA74.2040807@redhat.com> <53FCE594.5040106@redhat.com> Message-ID: I may need a little more direction here. The output from getcert list-cas does not contain the string 'ca_renewal'. What does this indicate? -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: Tuesday, August 26, 2014 3:53 PM To: Ott, Dennis; Freeipa-users at redhat.com Subject: Re: [Freeipa-users] Cert Renewal Ott, Dennis wrote: > No services are currently running on the replica (and I am hesitant to start them) but, my recollection is that I did the replica server installation with the --setup-ca option. Also, there are /var/lib/dirsrv/slapd-PKI-IPA/ and /etc/pki-ca/ directories in place on the replica. > > ipa-getcert list shows all certs with a status of: CA_UNREACHABLE (but > then, the service is down. The master also gave this status, even with > the service running, until I followed the cert renewal procedure.) > > So, with the replica running a CA, should I follow the same procedure that I used on the master? Anything else to look out for? No, the procedure is slightly different on the replica. You need to start by ensuring that certmonger has a CA type for renewal: # getcert list-cas Look for ca_renewal Check the CA subsystem certs to see how they are configured. The CA should be dogtag-ipa-retrieve-agent-submit for "auditSigningCert cert-pki-ca", "ocspSigningCert cert-pki-ca" and "subsystemCert cert-pki-ca" and a pre-save command of stop_pkicad and a post-save a restart_pkicad PKI-IPA The agent cert, ipaCert, should be using "dogtag-ipa-retrieve-agent-submit", a blank pre-save command and a post-save command of restart_httpd. rob > > Thanks. > > Dennis > > > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Monday, August 25, 2014 6:37 PM > To: Ott, Dennis; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Cert Renewal > > Ott, Dennis wrote: >> I have an IPA setup, one master, one replica; originally installed as >> v 2.x and later updated to v 3.0. For whatever reasons, the certs >> did not automatically renew and the services would no longer start. I >> updated the certs manually on the master using the procedure shown at: >> >> >> >> http://www.freeipa.org/page/IPA_2x_Certificate_Renewal >> >> >> >> The master is now functioning properly. >> >> >> >> >> >> At this point, the IPA service is still stopped on the replica. I >> hesitate to start it for concern it could interfere with the >> now-working master. >> >> >> >> What would be the recommended method for returning the replica to service? > > It depends on whether the replica. Does it also run a CA? If not then you can try restarting the certmonger service. This should cause it to fetch new certificates for the other IPA servers. ipa-getcert list will show you the status, wait until they are all MONITORING. > > Once that works then you can safely restart the world. Any changes on the master will be replicated out, and vice versa. > > rob > From mkosek at redhat.com Wed Sep 3 07:02:31 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 03 Sep 2014 09:02:31 +0200 Subject: [Freeipa-users] Search Base issues In-Reply-To: <540631F0.1020805@redhat.com> References: <540585B3.9030606@redhat.com> <5406233E.3040705@redhat.com> <54062920.4010605@redhat.com> <540631F0.1020805@redhat.com> Message-ID: <5406BD07.6040204@redhat.com> Ok, it indeed looks like we missed this tree when doing Permission V2 refactoring (ticket https://fedorahosted.org/freeipa/ticket/4521). This is something we will need to fix in upcoming FreeIPA 4.0.2, so please stay tuned. In the meantime, you can use the workaround that Rob sent, you would just need to delete it again when the fix is in, so that the permissions do not step on each other. Martin On 09/02/2014 11:09 PM, Rob Crittenden wrote: > Chris Whittle wrote: >> If I do this >> >> ldapsearch -LLL -H ldaps://DOMAIN:636 -x -D >> "uid=mac_slave,cn=users,cn=accounts,dc=domain,dc=com" -w 'nachopassword' >> -b "uid=awesomeuser,cn=users,cn=accounts,dc=domain,dc=com" >> >> It works fine > > AFAICT there currently isn't a permission for the compat tree. The admin > user can do it via 'Admin can manage any entry" and of course DM can do > it because it can do anything. > > A temporary workaround would be to add an aci manually: > > dn: dc=example,dc=com > changetype: modify > add: aci > aci: (targetattr = "*")(target = > "ldap:///uid=*,cn=canlogin,cn=compat,dc=example,dc=com")(version 3.0;acl > "Read canlogin compat tree";allow (compare,read,search) userdn = > "ldap:///all";) > > This won't show up as a permission and will grant all authenticated > users read access to the canlogin compat tree. I'm assuming here this > contains entries keyed on uid. > > rob > >> >> **Mac_Slave is my automation user. >> >> >> >> >> On Tue, Sep 2, 2014 at 3:40 PM, Chris Whittle > > wrote: >> >> For testing I'm using >> >> ldapsearch -LLL -H ldaps://DOMAIN636 -x -D "cn=directory manager" -w >> 'nachopassword' -b "cn=canlogin,cn=compat,dc=domain,dc=com" >> >> If I do it with directory manager it works fine, if I use my >> automation user (just a generic user with no extra permissions) it >> returns nothing, no error, just empty space >> >> if I add -v (verbose) i get >> >> ldap_initialize( ldaps://domain.com:636/??base >> ) >> >> filter: (objectclass=*) >> >> requesting: All userApplication attributes >> >> >> Thanks everyone! >> >> >> On Tue, Sep 2, 2014 at 3:31 PM, Rob Crittenden > > wrote: >> >> Chris Whittle wrote: >> > hmmm... >> > Is there not a permission or role in freeIPA that I could give >> a group >> > or role just to see everything in >> > my CN "cn=canlogin,cn=compat,dc=DOMAIN,dc=com" >> >> Can you provide more details on what you're doing, and how you are >> binding? Can you search the cn=users,cn=compat,dc=DOMAIN,dc=com >> tree? >> >> AFAICT you should be able to read cn=compat as long as you bind >> as a user. >> >> rob >> >> > >> > >> > >> > On Tue, Sep 2, 2014 at 3:06 PM, Dmitri Pal > >> > >> wrote: >> > >> > On 09/02/2014 09:34 PM, Chris Whittle wrote: >> >> Ok Dmitri, I got it added using what you sent and the >> following links >> >> >> https://git.fedorahosted.org/cgit/slapi-nis.git/tree/doc/sch-getting-started.txt >> >> and >> >> >> https://www.redhat.com/archives/freeipa-users/2009-August/msg00013.html >> >> >> >> I think i'm 90% there with the caveat that I can't seem >> to see >> >> what permissions I need to give a user to view my NIS "view". >> >> Right now Directory Manager can see it but that is it. >> >> >> >> Any ideas? >> >> >> > You got me :-) >> > I would defer to specialist in this area to solve this >> problem. >> > >> > >> >> >> >> >> >> On Tue, Sep 2, 2014 at 9:00 AM, Chris Whittle >> >> >> >> wrote: >> >> >> >> Thanks Dimitri, before I get too far this rabbit hole >> (cause >> >> it looks a little scary) let me make sure I get it. >> >> >> >> So using Slap-NIS I should be able to create a view into >> >> FreeIPA that would show only a subset of user based on >> >> something like a group or an attribute? >> >> >> >> Then using the built in MAC Directory Utility (or any >> LDAP >> >> client) I should be able to use that Slap-NIS view as a >> >> searchbase and it would return just people I wanted. >> This >> >> could be used keep anyone outside that view from >> logging in? >> >> >> >> I'm sorry for the noob questions but there isn't a >> lot of good >> >> documentation on SlapNIS from first glance and I >> don't want to >> >> spend 2 days figuring it out if it's not going to work. >> >> >> >> As always extremely appreciated! >> >> Whitt >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Tue, Sep 2, 2014 at 3:54 AM, Dmitri Pal >> >> >> >> wrote: >> >> >> >> On 09/02/2014 03:04 AM, Chris Whittle wrote: >> >>> I am trying to limit who can login to my macs >> and I'm >> >>> having to stick to what OSX will let me do. >> >>> >> >>> Currently I can only limit users using the >> searchbase and >> >>> right now it's >> "cn=users,cn=accounts,dc=DOMAIN,dc=com" >> >>> >> >>> This works fine unless I wanted to create a user >> that I >> >>> wanted in LDAP for other purposes but not to login. >> >>> >> >>> So my questions are, >> >>> A)Can we create different OUs in FreeIPA like >> most LDAP >> >>> servers? >> >> >> >> You can use slapi-nis to create an alternative >> view of the >> >> tree or trees and point your special client to >> that tree. >> >> There you might be able to expose a small subset >> of users >> >> that match your special criteria. >> >> The slapi-nis and compat docs are in the doc >> folder in the >> >> corresponding git repo. >> >> >> >> IPA uses compat tree for its own purposes but you can >> >> tweak it if you need or create a different view. >> >> >> >> HTH >> >> >> >> >> >> >> >>> B)If not anyone have any idea on how I could do >> this with >> >>> OSX's directory Utility? >> >>> >> >>> Thanks! >> >>> >> >>> >> >>> >> >> >> >> >> >> -- >> >> Thank you, >> >> Dmitri Pal >> >> >> >> Sr. Engineering Manager IdM portfolio >> >> Red Hat, Inc. >> >> >> >> >> >> >> > >> > >> > -- >> > Thank you, >> > Dmitri Pal >> > >> > Sr. Engineering Manager IdM portfolio >> > Red Hat, Inc. >> > >> > >> > >> > >> >> >> > From pspacek at redhat.com Wed Sep 3 07:25:15 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 03 Sep 2014 09:25:15 +0200 Subject: [Freeipa-users] FreeIPA bind also-notify behavior. In-Reply-To: <54044785.4010302@redhat.com> References: <5404092F.2090604@redhat.com> <540444FA.5090800@redhat.com> <54044785.4010302@redhat.com> Message-ID: <5406C25B.1000003@redhat.com> On 1.9.2014 12:16, Dmitri Pal wrote: > On 09/01/2014 12:05 PM, Martin Kosek wrote: >> On 09/01/2014 07:50 AM, Dmitri Pal wrote: >>> On 08/29/2014 09:32 PM, Matthew Sellers wrote: >>>> Hi Everyone! >>>> >>>> I am using FreeIPA 3.3.5 on Fedora 20 and attempting to configure FreeIPA to >>>> send notifies to non-IPA slaves, but it seems broken on IPA ( notify packets >>>> are never sent to to slaves ). >>>> >>>> I have configured also-notify { nameserverip; }; in named.conf on my FreeIPA >>>> test host in the options section and watched for notify traffic with tcpdump. >>>> >>>> This document suggests that this is supported, and this is something I have >>>> used in non-IPA bind servers with no issues. >>>> >>>> https://fedoraproject.org/wiki/QA:Testcase_freeipav3_dns_zone_transfer >>>> >>>> I wanted to ask the list before I file a bug with more details. Is anyone >>>> using this bind feature on IPA with any success? >>>> >>>> Thanks! >>>> Matt >>>> >>>> >>> The DNS level change propagation is not supported between IPA replicas instead >>> it uses LDAP replication to propagate the changes. >>> If you want another non IPA DNS server to be a slave then you can do it. See >>> http://www.freeipa.org/page/V3/DNS_SOA_serial_auto-incrementation for more >>> information. >> I thought that from F20, bind-dyndb-ldap was capable of native DNS operations >> like AXFR/IXFR which can be used to actually deploy slave DNS servers. I wonder >> if also-notify is something different. CCing Petr Spacek to advise. > AFAIU slave DNS servers not controlled by IPA yes, replicas as slaves - no. Let me summarize: - AXFR is supported (at least) by all versions RHEL 6.5 and newer versions - IXFR is supported by bind-dyndb-ldap 4.0 and newer (Fedora 20+) - DNS NOTIFY messages are always sent to servers listed in NS records I.e. you have to add your non-IPA slave servers to NS records in particular zone and then it should 'just work', no other configuration (like 'also-notify') is necessary. Please let me know if it doesn't work for you. -- Petr^2 Spacek From mkosek at redhat.com Wed Sep 3 07:29:06 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 03 Sep 2014 09:29:06 +0200 Subject: [Freeipa-users] Search Base issues In-Reply-To: <5406BD07.6040204@redhat.com> References: <540585B3.9030606@redhat.com> <5406233E.3040705@redhat.com> <54062920.4010605@redhat.com> <540631F0.1020805@redhat.com> <5406BD07.6040204@redhat.com> Message-ID: <5406C342.6060406@redhat.com> On 09/03/2014 09:02 AM, Martin Kosek wrote: > In the meantime, you can use the workaround that Rob sent, you would just need > to delete it again when the fix is in, so that the permissions do not step on > each other. Actually, wait a minute. I think Rob's ACI example may be too wide, it may expose any attribute in the compat tree, including a potential userPassword. As I see, it seems that slapi-nis plugin do not fortunately expose that, but it is safer to just list the attributes that one wants to display (this is also what we did in FreeIPA 4.0, no global wildcard allowing ACIs any more). I added a respective permission via Web UI (one part of it cannot be added via CLI, see https://fedorahosted.org/freeipa/ticket/4522) and compat tree now works for me. See attached example. Resulting permission shown in CLI: # ipa permission-show "TEMPORARY - Read compat tree" Permission name: TEMPORARY - Read compat tree Granted rights: read, search, compare Effective attributes: cn, description, gecos, gidnumber, homedirectory, loginshell, memberuid, objectclass, uid, uidnumber Bind rule type: all Subtree: dc=mkosek-fedora20,dc=test ACI target DN: cn=compat,dc=mkosek-fedora20,dc=test It is much easier to manipulate than ACI added via ldapmodify. HTH, Martin > > Martin > > On 09/02/2014 11:09 PM, Rob Crittenden wrote: >> Chris Whittle wrote: >>> If I do this >>> >>> ldapsearch -LLL -H ldaps://DOMAIN:636 -x -D >>> "uid=mac_slave,cn=users,cn=accounts,dc=domain,dc=com" -w 'nachopassword' >>> -b "uid=awesomeuser,cn=users,cn=accounts,dc=domain,dc=com" >>> >>> It works fine >> >> AFAICT there currently isn't a permission for the compat tree. The admin >> user can do it via 'Admin can manage any entry" and of course DM can do >> it because it can do anything. >> >> A temporary workaround would be to add an aci manually: >> >> dn: dc=example,dc=com >> changetype: modify >> add: aci >> aci: (targetattr = "*")(target = >> "ldap:///uid=*,cn=canlogin,cn=compat,dc=example,dc=com")(version 3.0;acl >> "Read canlogin compat tree";allow (compare,read,search) userdn = >> "ldap:///all";) >> >> This won't show up as a permission and will grant all authenticated >> users read access to the canlogin compat tree. I'm assuming here this >> contains entries keyed on uid. >> >> rob -------------- next part -------------- A non-text attachment was scrubbed... Name: permission-add-compat.png Type: image/png Size: 109917 bytes Desc: not available URL: From rcritten at redhat.com Wed Sep 3 13:08:38 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 03 Sep 2014 09:08:38 -0400 Subject: [Freeipa-users] Search Base issues In-Reply-To: <5406C342.6060406@redhat.com> References: <540585B3.9030606@redhat.com> <5406233E.3040705@redhat.com> <54062920.4010605@redhat.com> <540631F0.1020805@redhat.com> <5406BD07.6040204@redhat.com> <5406C342.6060406@redhat.com> Message-ID: <540712D6.9090909@redhat.com> Martin Kosek wrote: > On 09/03/2014 09:02 AM, Martin Kosek wrote: >> In the meantime, you can use the workaround that Rob sent, you would just need >> to delete it again when the fix is in, so that the permissions do not step on >> each other. > > Actually, wait a minute. I think Rob's ACI example may be too wide, it may > expose any attribute in the compat tree, including a potential userPassword. The ACI was on his custom cn=canlogin subtree, not all of cn=compat. > As I see, it seems that slapi-nis plugin do not fortunately expose that, but it > is safer to just list the attributes that one wants to display (this is also > what we did in FreeIPA 4.0, no global wildcard allowing ACIs any more). > > I added a respective permission via Web UI (one part of it cannot be added via > CLI, see https://fedorahosted.org/freeipa/ticket/4522) and compat tree now > works for me. See attached example. > > Resulting permission shown in CLI: > > # ipa permission-show "TEMPORARY - Read compat tree" > Permission name: TEMPORARY - Read compat tree > Granted rights: read, search, compare > Effective attributes: cn, description, gecos, gidnumber, homedirectory, > loginshell, memberuid, > objectclass, uid, uidnumber > Bind rule type: all > Subtree: dc=mkosek-fedora20,dc=test > ACI target DN: cn=compat,dc=mkosek-fedora20,dc=test > > It is much easier to manipulate than ACI added via ldapmodify. I see you filed a bug on the missing CLI option. That's why I did the ACI, because I couldn't demonstrate how to add this ACI on the CLI. I hadn't gotten around to doing that last night. rob > > HTH, > Martin > >> >> Martin >> >> On 09/02/2014 11:09 PM, Rob Crittenden wrote: >>> Chris Whittle wrote: >>>> If I do this >>>> >>>> ldapsearch -LLL -H ldaps://DOMAIN:636 -x -D >>>> "uid=mac_slave,cn=users,cn=accounts,dc=domain,dc=com" -w 'nachopassword' >>>> -b "uid=awesomeuser,cn=users,cn=accounts,dc=domain,dc=com" >>>> >>>> It works fine >>> >>> AFAICT there currently isn't a permission for the compat tree. The admin >>> user can do it via 'Admin can manage any entry" and of course DM can do >>> it because it can do anything. >>> >>> A temporary workaround would be to add an aci manually: >>> >>> dn: dc=example,dc=com >>> changetype: modify >>> add: aci >>> aci: (targetattr = "*")(target = >>> "ldap:///uid=*,cn=canlogin,cn=compat,dc=example,dc=com")(version 3.0;acl >>> "Read canlogin compat tree";allow (compare,read,search) userdn = >>> "ldap:///all";) >>> >>> This won't show up as a permission and will grant all authenticated >>> users read access to the canlogin compat tree. I'm assuming here this >>> contains entries keyed on uid. >>> >>> rob > From mkosek at redhat.com Wed Sep 3 14:10:32 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 03 Sep 2014 16:10:32 +0200 Subject: [Freeipa-users] Search Base issues In-Reply-To: <540712D6.9090909@redhat.com> References: <540585B3.9030606@redhat.com> <5406233E.3040705@redhat.com> <54062920.4010605@redhat.com> <540631F0.1020805@redhat.com> <5406BD07.6040204@redhat.com> <5406C342.6060406@redhat.com> <540712D6.9090909@redhat.com> Message-ID: <54072158.9080400@redhat.com> On 09/03/2014 03:08 PM, Rob Crittenden wrote: > Martin Kosek wrote: >> On 09/03/2014 09:02 AM, Martin Kosek wrote: >>> In the meantime, you can use the workaround that Rob sent, you would just need >>> to delete it again when the fix is in, so that the permissions do not step on >>> each other. >> >> Actually, wait a minute. I think Rob's ACI example may be too wide, it may >> expose any attribute in the compat tree, including a potential userPassword. > > The ACI was on his custom cn=canlogin subtree, not all of cn=compat. > >> As I see, it seems that slapi-nis plugin do not fortunately expose that, but it >> is safer to just list the attributes that one wants to display (this is also >> what we did in FreeIPA 4.0, no global wildcard allowing ACIs any more). >> >> I added a respective permission via Web UI (one part of it cannot be added via >> CLI, see https://fedorahosted.org/freeipa/ticket/4522) and compat tree now >> works for me. See attached example. >> >> Resulting permission shown in CLI: >> >> # ipa permission-show "TEMPORARY - Read compat tree" >> Permission name: TEMPORARY - Read compat tree >> Granted rights: read, search, compare >> Effective attributes: cn, description, gecos, gidnumber, homedirectory, >> loginshell, memberuid, >> objectclass, uid, uidnumber >> Bind rule type: all >> Subtree: dc=mkosek-fedora20,dc=test >> ACI target DN: cn=compat,dc=mkosek-fedora20,dc=test >> >> It is much easier to manipulate than ACI added via ldapmodify. > > I see you filed a bug on the missing CLI option. That's why I did the > ACI, because I couldn't demonstrate how to add this ACI on the CLI. I > hadn't gotten around to doing that last night. > > rob Right. Surprisingly, the option was available in Web UI, thus the Web UI screenshot I attached to the thread :) But we have the CLI option fixed already, will be part of FreeIPA 4.0.2 which will be released very soon. Martin From jkinney at emory.edu Wed Sep 3 15:03:29 2014 From: jkinney at emory.edu (Jim Kinney) Date: Wed, 03 Sep 2014 11:03:29 -0400 Subject: [Freeipa-users] replication - original master not replicating Message-ID: <1409756609.3681.43.camel@serenity.cci.emory.edu> Greetings, I'm running freeipa 3.0 with multimaster between 3 machines. The first system, the original installation machine and thus the keepers of the CA, etc, is not replicating with the other two. The other two are fine. Additionally, the original machine is no longer using the freeIPA running on it for authentication services. Examples: I created a new user on the first machine using ipa user-add .... and the other two systems didn't pick it up (even after an overnight wait). So I thought it was not created. I then tried to create the user again but on #2 machine on the web gui. It refused saying the private group of that user already existed. It did not error about the username. So I went to #1 and deleted the user. Back to #2 to create the user and #3 picked it up within a minute. But #1 picked it up this time. >From #1, running id on any user in the system returns a "No such user". But when I go to the gui on #1, I can find users. The #1 system has files sss in nsswitch for passwd, shadow, group, services, netgroup as do #2 and #3. When I setup #2, I ran the ipa-ca-install on the generated file from the #1 machine. So I think #2 now has the CA for my department. When I tried to setup #3 by using #1 as the master, it would not connect/complete back to #1. I replicated from #2 and it worked. It's been several months (10+ or so) since I set up the #1 machine and #2 was about 2 days after it. I don't know if #1 always didn't use freeIPA for authentication or not. #1 and #2 are CentOS 6.5. #3 is CentOS 7 and freeIPA 3.3. I was concerned that the version mismatch would be an issue but it seems to work well between #2 and #3. Clearly, if I add a user now, I use #2 or #3. I can get by with not messing around with #1 and it's just for master CA needs. Oh. I have all three in DNS and #1 and #2 are DNS servers. #3 is in a separate network segment and exists to provide auth services in the (likely) event a network link goes down between that location and the main stack. -- Jim Kinney Senior System Administrator Department of BioMedical Informatics Emory University jimkinney at emory.edu 404.712.0300 bmi.emory.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From cwhittl at gmail.com Wed Sep 3 15:51:18 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Wed, 3 Sep 2014 10:51:18 -0500 Subject: [Freeipa-users] Search Base issues In-Reply-To: <54072158.9080400@redhat.com> References: <540585B3.9030606@redhat.com> <5406233E.3040705@redhat.com> <54062920.4010605@redhat.com> <540631F0.1020805@redhat.com> <5406BD07.6040204@redhat.com> <5406C342.6060406@redhat.com> <540712D6.9090909@redhat.com> <54072158.9080400@redhat.com> Message-ID: That worked, but having issues get it to work with the OSX Directory Utility. I'm wondering if it's because when you go against the OU normally it's returning more info about the user versus what's being returned from the compat "view" I'm going to experiment with the attributes it's returning and see if that's it. I'm also wondering why FreeIPA doesn't support multiple OU's natively, this would be so much easier with multiple OUs (one for my non-users and one for my users) On Wed, Sep 3, 2014 at 9:10 AM, Martin Kosek wrote: > On 09/03/2014 03:08 PM, Rob Crittenden wrote: > > Martin Kosek wrote: > >> On 09/03/2014 09:02 AM, Martin Kosek wrote: > >>> In the meantime, you can use the workaround that Rob sent, you would > just need > >>> to delete it again when the fix is in, so that the permissions do not > step on > >>> each other. > >> > >> Actually, wait a minute. I think Rob's ACI example may be too wide, it > may > >> expose any attribute in the compat tree, including a potential > userPassword. > > > > The ACI was on his custom cn=canlogin subtree, not all of cn=compat. > > > >> As I see, it seems that slapi-nis plugin do not fortunately expose > that, but it > >> is safer to just list the attributes that one wants to display (this is > also > >> what we did in FreeIPA 4.0, no global wildcard allowing ACIs any more). > >> > >> I added a respective permission via Web UI (one part of it cannot be > added via > >> CLI, see https://fedorahosted.org/freeipa/ticket/4522) and compat tree > now > >> works for me. See attached example. > >> > >> Resulting permission shown in CLI: > >> > >> # ipa permission-show "TEMPORARY - Read compat tree" > >> Permission name: TEMPORARY - Read compat tree > >> Granted rights: read, search, compare > >> Effective attributes: cn, description, gecos, gidnumber, > homedirectory, > >> loginshell, memberuid, > >> objectclass, uid, uidnumber > >> Bind rule type: all > >> Subtree: dc=mkosek-fedora20,dc=test > >> ACI target DN: cn=compat,dc=mkosek-fedora20,dc=test > >> > >> It is much easier to manipulate than ACI added via ldapmodify. > > > > I see you filed a bug on the missing CLI option. That's why I did the > > ACI, because I couldn't demonstrate how to add this ACI on the CLI. I > > hadn't gotten around to doing that last night. > > > > rob > > Right. Surprisingly, the option was available in Web UI, thus the Web UI > screenshot I attached to the thread :) But we have the CLI option fixed > already, will be part of FreeIPA 4.0.2 which will be released very soon. > > Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ziplyx at gmail.com Wed Sep 3 16:08:48 2014 From: ziplyx at gmail.com (Zip Ly) Date: Wed, 3 Sep 2014 18:08:48 +0200 Subject: [Freeipa-users] Password expiration dates are different when being resetted by the (primary) admin and a different admin In-Reply-To: <5405E017.60309@redhat.com> References: <53FF5665.9010403@redhat.com> <54045333.5080102@redhat.com> <5405E017.60309@redhat.com> Message-ID: @Martin Ah that explains everything. We were using centos 6.5 + ipa 3.0.0 Now with a new test setup centos 7 + ipa 3.3.3, it works just as we wanted. Thank all for the help! On Tue, Sep 2, 2014 at 5:19 PM, Martin Kosek wrote: > On 09/02/2014 10:42 AM, Zip Ly wrote: > > @Martin > > > > The second admin is my service account. I use this account to communicate > > with our webapplication (it uses keytab and post/curl json to ipa). I can > > add users without a problem. But when it comes to changing password, the > > password is expired immediately. > > > > I have only one password policy and that's the 'global_policy'. The > > --maxlife you mentioned only affect this policy. If I use this service > > account to change the user password, the policy is ignored just as stated > > in the ipa wiki. Even if I set the --maxlife to 200, if the password is > > being resetted by this first admin, then the expire date is set to 90 > days > > or expired immediately by the second admin/service account. > > > > That's why I want to know how to change this 90 days and also apply it > for > > the service account. > > What version of FreeIPA do you use? Maybe you are hitting > https://fedorahosted.org/freeipa/ticket/3968 > that we fixed in FreeIPA 3.3.3. > > Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Wed Sep 3 16:12:10 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 03 Sep 2014 18:12:10 +0200 Subject: [Freeipa-users] Password expiration dates are different when being resetted by the (primary) admin and a different admin In-Reply-To: References: <53FF5665.9010403@redhat.com> <54045333.5080102@redhat.com> <5405E017.60309@redhat.com> Message-ID: <54073DDA.2000700@redhat.com> Great! Btw +1 for running on IPA 3.3.3, it has much more to offer than RHEL/CentOS 6.x one. Martin On 09/03/2014 06:08 PM, Zip Ly wrote: > @Martin > > Ah that explains everything. We were using centos 6.5 + ipa 3.0.0 > Now with a new test setup centos 7 + ipa 3.3.3, it works just as we wanted. > > Thank all for the help! > > > On Tue, Sep 2, 2014 at 5:19 PM, Martin Kosek wrote: > >> On 09/02/2014 10:42 AM, Zip Ly wrote: >>> @Martin >>> >>> The second admin is my service account. I use this account to communicate >>> with our webapplication (it uses keytab and post/curl json to ipa). I can >>> add users without a problem. But when it comes to changing password, the >>> password is expired immediately. >>> >>> I have only one password policy and that's the 'global_policy'. The >>> --maxlife you mentioned only affect this policy. If I use this service >>> account to change the user password, the policy is ignored just as stated >>> in the ipa wiki. Even if I set the --maxlife to 200, if the password is >>> being resetted by this first admin, then the expire date is set to 90 >> days >>> or expired immediately by the second admin/service account. >>> >>> That's why I want to know how to change this 90 days and also apply it >> for >>> the service account. >> >> What version of FreeIPA do you use? Maybe you are hitting >> https://fedorahosted.org/freeipa/ticket/3968 >> that we fixed in FreeIPA 3.3.3. >> >> Martin >> > From rap at phas.ubc.ca Wed Sep 3 16:18:20 2014 From: rap at phas.ubc.ca (Ron) Date: Wed, 03 Sep 2014 09:18:20 -0700 Subject: [Freeipa-users] ipa user-find finds user but ipa user-del fails Message-ID: <54073F4C.60602@phas.ubc.ca> user-find sees a user but user-del cannot remove it. What can I do? Thanks. Regards, Ron [root at ipa]# ipa user-find --login phys210e -------------- 1 user matched -------------- User login: phys210e First name: Testing Last name: Phys210 Home directory: /home2/phys210e Login shell: /bin/bash Email address: phys210e at phas.ubc.ca UID: 15010 GID: 15010 Account disabled: False Password: True Kerberos keys available: False ---------------------------- Number of entries returned 1 ---------------------------- [root at ipa]# ipa user-del phys210e --continue --------------- Deleted user "" --------------- Failed to remove: phys210e [root at ipa]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.5 (Santiago) [root at ipa]# rpm -qa|grep ipa; rpm -qa|grep 389 ipa-pki-ca-theme-9.0.3-7.el6.noarch ipa-admintools-3.0.0-37.el6.i686 ipa-pki-common-theme-9.0.3-7.el6.noarch libipa_hbac-1.9.2-129.el6_5.4.i686 ipa-server-selinux-3.0.0-37.el6.i686 python-iniparse-0.3.1-2.1.el6.noarch libipa_hbac-python-1.9.2-129.el6_5.4.i686 ipa-server-3.0.0-37.el6.i686 ipa-python-3.0.0-37.el6.i686 ipa-client-3.0.0-37.el6.i686 389-ds-base-libs-1.2.11.15-33.el6_5.i686 389-ds-base-1.2.11.15-33.el6_5.i686 -- Ron Parachoniak Systems Manager, Department of Physics & Astronomy University of British Columbia, Vancouver, B.C. V6T 1Z1 Phone: (604) 838-6437 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xA1D0F827.asc Type: application/pgp-keys Size: 4721 bytes Desc: not available URL: From mkosek at redhat.com Wed Sep 3 16:32:47 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 03 Sep 2014 18:32:47 +0200 Subject: [Freeipa-users] ipa user-find finds user but ipa user-del fails In-Reply-To: <54073F4C.60602@phas.ubc.ca> References: <54073F4C.60602@phas.ubc.ca> Message-ID: <540742AF.20402@redhat.com> Can you check /var/log/dirsrv/slapd-YOUR-REALM/access, search for the DEL operation and see what was the error code that DS gave when it refused to delete the user? Martin On 09/03/2014 06:18 PM, Ron wrote: > user-find sees a user but user-del cannot remove it. What can I do? > Thanks. > Regards, > Ron > > [root at ipa]# ipa user-find --login phys210e > -------------- > 1 user matched > -------------- > User login: phys210e > First name: Testing > Last name: Phys210 > Home directory: /home2/phys210e > Login shell: /bin/bash > Email address: phys210e at phas.ubc.ca > UID: 15010 > GID: 15010 > Account disabled: False > Password: True > Kerberos keys available: False > ---------------------------- > Number of entries returned 1 > ---------------------------- > [root at ipa]# ipa user-del phys210e --continue > --------------- > Deleted user "" > --------------- > Failed to remove: phys210e > > > [root at ipa]# cat /etc/redhat-release > Red Hat Enterprise Linux Server release 6.5 (Santiago) > > [root at ipa]# rpm -qa|grep ipa; rpm -qa|grep 389 > ipa-pki-ca-theme-9.0.3-7.el6.noarch > ipa-admintools-3.0.0-37.el6.i686 > ipa-pki-common-theme-9.0.3-7.el6.noarch > libipa_hbac-1.9.2-129.el6_5.4.i686 > ipa-server-selinux-3.0.0-37.el6.i686 > python-iniparse-0.3.1-2.1.el6.noarch > libipa_hbac-python-1.9.2-129.el6_5.4.i686 > ipa-server-3.0.0-37.el6.i686 > ipa-python-3.0.0-37.el6.i686 > ipa-client-3.0.0-37.el6.i686 > 389-ds-base-libs-1.2.11.15-33.el6_5.i686 > 389-ds-base-1.2.11.15-33.el6_5.i686 From rcritten at redhat.com Wed Sep 3 17:43:34 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 03 Sep 2014 13:43:34 -0400 Subject: [Freeipa-users] ipa user-find finds user but ipa user-del fails In-Reply-To: <540742AF.20402@redhat.com> References: <54073F4C.60602@phas.ubc.ca> <540742AF.20402@redhat.com> Message-ID: <54075346.4030505@redhat.com> Martin Kosek wrote: > Can you check /var/log/dirsrv/slapd-YOUR-REALM/access, search for the DEL > operation and see what was the error code that DS gave when it refused to > delete the user? Were I to guess the issue is that this is a replication conflict entry. If you do: # ipa user-show --all --raw phys210e |grep dn: It will likely begin with nsuniqueid=, ... The reason it can be found and not deleted is we create the dn to be removed, we don't search for it. So the user uid=phys210e,cn=users,... etc doesn't exist but the user nsuniqueid= ... does. You'll need to use ldapmodify or ldapdelete to remove the entry though I'd check your other masters to see what the state of the user is there. rob > > Martin > > On 09/03/2014 06:18 PM, Ron wrote: >> user-find sees a user but user-del cannot remove it. What can I do? >> Thanks. >> Regards, >> Ron >> >> [root at ipa]# ipa user-find --login phys210e >> -------------- >> 1 user matched >> -------------- >> User login: phys210e >> First name: Testing >> Last name: Phys210 >> Home directory: /home2/phys210e >> Login shell: /bin/bash >> Email address: phys210e at phas.ubc.ca >> UID: 15010 >> GID: 15010 >> Account disabled: False >> Password: True >> Kerberos keys available: False >> ---------------------------- >> Number of entries returned 1 >> ---------------------------- >> [root at ipa]# ipa user-del phys210e --continue >> --------------- >> Deleted user "" >> --------------- >> Failed to remove: phys210e >> >> >> [root at ipa]# cat /etc/redhat-release >> Red Hat Enterprise Linux Server release 6.5 (Santiago) >> >> [root at ipa]# rpm -qa|grep ipa; rpm -qa|grep 389 >> ipa-pki-ca-theme-9.0.3-7.el6.noarch >> ipa-admintools-3.0.0-37.el6.i686 >> ipa-pki-common-theme-9.0.3-7.el6.noarch >> libipa_hbac-1.9.2-129.el6_5.4.i686 >> ipa-server-selinux-3.0.0-37.el6.i686 >> python-iniparse-0.3.1-2.1.el6.noarch >> libipa_hbac-python-1.9.2-129.el6_5.4.i686 >> ipa-server-3.0.0-37.el6.i686 >> ipa-python-3.0.0-37.el6.i686 >> ipa-client-3.0.0-37.el6.i686 >> 389-ds-base-libs-1.2.11.15-33.el6_5.i686 >> 389-ds-base-1.2.11.15-33.el6_5.i686 > From rcritten at redhat.com Wed Sep 3 17:47:46 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 03 Sep 2014 13:47:46 -0400 Subject: [Freeipa-users] Search Base issues In-Reply-To: References: <540585B3.9030606@redhat.com> <5406233E.3040705@redhat.com> <54062920.4010605@redhat.com> <540631F0.1020805@redhat.com> <5406BD07.6040204@redhat.com> <5406C342.6060406@redhat.com> <540712D6.9090909@redhat.com> <54072158.9080400@redhat.com> Message-ID: <54075442.2050604@redhat.com> Chris Whittle wrote: > That worked, but having issues get it to work with the OSX Directory > Utility. > I'm wondering if it's because when you go against the OU normally it's > returning more info about the user versus what's being returned from the > compat "view" I'm going to experiment with the attributes it's returning > and see if that's it. > > I'm also wondering why FreeIPA doesn't support multiple OU's natively, > this would be so much easier with multiple OUs (one for my non-users and > one for my users) Because they are so very often used really, really poorly, resulting in having to move entries around a lot with no real technical reason behind it. Think about the number of times an IT department gets renamed, oops, today they are called Global Support Services, oh no, didn't you hear, now they are ... Each one requiring an entire subtree move. Where the users exist in LDAP does not generally need to reflect the organizational structure. Your case is a bit different from most, where you want to host two completely separate kinds of users. rob > > > On Wed, Sep 3, 2014 at 9:10 AM, Martin Kosek > wrote: > > On 09/03/2014 03:08 PM, Rob Crittenden wrote: > > Martin Kosek wrote: > >> On 09/03/2014 09:02 AM, Martin Kosek wrote: > >>> In the meantime, you can use the workaround that Rob sent, you > would just need > >>> to delete it again when the fix is in, so that the permissions > do not step on > >>> each other. > >> > >> Actually, wait a minute. I think Rob's ACI example may be too > wide, it may > >> expose any attribute in the compat tree, including a potential > userPassword. > > > > The ACI was on his custom cn=canlogin subtree, not all of cn=compat. > > > >> As I see, it seems that slapi-nis plugin do not fortunately > expose that, but it > >> is safer to just list the attributes that one wants to display > (this is also > >> what we did in FreeIPA 4.0, no global wildcard allowing ACIs any > more). > >> > >> I added a respective permission via Web UI (one part of it cannot > be added via > >> CLI, see https://fedorahosted.org/freeipa/ticket/4522) and compat > tree now > >> works for me. See attached example. > >> > >> Resulting permission shown in CLI: > >> > >> # ipa permission-show "TEMPORARY - Read compat tree" > >> Permission name: TEMPORARY - Read compat tree > >> Granted rights: read, search, compare > >> Effective attributes: cn, description, gecos, gidnumber, > homedirectory, > >> loginshell, memberuid, > >> objectclass, uid, uidnumber > >> Bind rule type: all > >> Subtree: dc=mkosek-fedora20,dc=test > >> ACI target DN: cn=compat,dc=mkosek-fedora20,dc=test > >> > >> It is much easier to manipulate than ACI added via ldapmodify. > > > > I see you filed a bug on the missing CLI option. That's why I did the > > ACI, because I couldn't demonstrate how to add this ACI on the CLI. I > > hadn't gotten around to doing that last night. > > > > rob > > Right. Surprisingly, the option was available in Web UI, thus the Web UI > screenshot I attached to the thread :) But we have the CLI option fixed > already, will be part of FreeIPA 4.0.2 which will be released very soon. > > Martin > > From rcritten at redhat.com Wed Sep 3 17:48:27 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 03 Sep 2014 13:48:27 -0400 Subject: [Freeipa-users] replication - original master not replicating In-Reply-To: <1409756609.3681.43.camel@serenity.cci.emory.edu> References: <1409756609.3681.43.camel@serenity.cci.emory.edu> Message-ID: <5407546B.8030802@redhat.com> Jim Kinney wrote: > Greetings, > > I'm running freeipa 3.0 with multimaster between 3 machines. The first > system, the original installation machine and thus the keepers of the > CA, etc, is not replicating with the other two. The other two are fine. > Additionally, the original machine is no longer using the freeIPA > running on it for authentication services. > > Examples: I created a new user on the first machine using ipa user-add > .... and the other two systems didn't pick it up (even after an > overnight wait). So I thought it was not created. I then tried to create > the user again but on #2 machine on the web gui. It refused saying the > private group of that user already existed. It did not error about the > username. So I went to #1 and deleted the user. Back to #2 to create the > user and #3 picked it up within a minute. But #1 picked it up this time. > >>From #1, running id on any user in the system returns a "No such > user". But when I go to the gui on #1, I can find users. The #1 system > has files sss in nsswitch for passwd, shadow, group, services, netgroup > as do #2 and #3. > > When I setup #2, I ran the ipa-ca-install on the generated file from the > #1 machine. So I think #2 now has the CA for my department. When I tried > to setup #3 by using #1 as the master, it would not connect/complete > back to #1. I replicated from #2 and it worked. > > It's been several months (10+ or so) since I set up the #1 machine and > #2 was about 2 days after it. I don't know if #1 always didn't use > freeIPA for authentication or not. > > #1 and #2 are CentOS 6.5. #3 is CentOS 7 and freeIPA 3.3. I was > concerned that the version mismatch would be an issue but it seems to > work well between #2 and #3. > > Clearly, if I add a user now, I use #2 or #3. I can get by with not > messing around with #1 and it's just for master CA needs. > > Oh. I have all three in DNS and #1 and #2 are DNS servers. #3 is in a > separate network segment and exists to provide auth services in the > (likely) event a network link goes down between that location and the > main stack. On each master I'd run: # ipa-replica-manage list -v `hostname` This will give you the replication status on each. rob From jkinney at emory.edu Wed Sep 3 17:59:05 2014 From: jkinney at emory.edu (Jim Kinney) Date: Wed, 03 Sep 2014 13:59:05 -0400 Subject: [Freeipa-users] replication - original master not replicating In-Reply-To: <5407546B.8030802@redhat.com> References: <1409756609.3681.43.camel@serenity.cci.emory.edu> <5407546B.8030802@redhat.com> Message-ID: <1409767145.3681.49.camel@serenity.cci.emory.edu> On Wed, 2014-09-03 at 13:48 -0400, Rob Crittenden wrote: > Jim Kinney wrote: > > Greetings, > > > > I'm running freeipa 3.0 with multimaster between 3 machines. The first > > system, the original installation machine and thus the keepers of the > > CA, etc, is not replicating with the other two. The other two are fine. > > Additionally, the original machine is no longer using the freeIPA > > running on it for authentication services. > > > > Examples: I created a new user on the first machine using ipa user-add > > .... and the other two systems didn't pick it up (even after an > > overnight wait). So I thought it was not created. I then tried to create > > the user again but on #2 machine on the web gui. It refused saying the > > private group of that user already existed. It did not error about the > > username. So I went to #1 and deleted the user. Back to #2 to create the > > user and #3 picked it up within a minute. But #1 picked it up this time. > > > >>From #1, running id on any user in the system returns a "No such > > user". But when I go to the gui on #1, I can find users. The #1 system > > has files sss in nsswitch for passwd, shadow, group, services, netgroup > > as do #2 and #3. > > > > When I setup #2, I ran the ipa-ca-install on the generated file from the > > #1 machine. So I think #2 now has the CA for my department. When I tried > > to setup #3 by using #1 as the master, it would not connect/complete > > back to #1. I replicated from #2 and it worked. > > > > It's been several months (10+ or so) since I set up the #1 machine and > > #2 was about 2 days after it. I don't know if #1 always didn't use > > freeIPA for authentication or not. > > > > #1 and #2 are CentOS 6.5. #3 is CentOS 7 and freeIPA 3.3. I was > > concerned that the version mismatch would be an issue but it seems to > > work well between #2 and #3. > > > > Clearly, if I add a user now, I use #2 or #3. I can get by with not > > messing around with #1 and it's just for master CA needs. > > > > Oh. I have all three in DNS and #1 and #2 are DNS servers. #3 is in a > > separate network segment and exists to provide auth services in the > > (likely) event a network link goes down between that location and the > > main stack. > > On each master I'd run: > > # ipa-replica-manage list -v `hostname` > > This will give you the replication status on each. > > rob > OK. Interesting results. #1 is vinz, #2 is prod01, #3 is beast : [root at vinz etc]# ipa-replica-manage list -v `hostname` beast.cci.emory.edu: replica last init status: None last init ended: None last update status: 32 - LDAP error: No such object last update ended: None prod01.cci.emory.edu: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2014-09-03 17:53:07+00:00 vinz.cci.emory.edu: replica last init status: None last init ended: None last update status: -1 Incremental update has failed and requires administrator actionLDAP error: Can't contact LDAP server last update ended: None [root at prod01 ~]# ipa-replica-manage list -v `hostname` beast.cci.emory.edu: replica last init status: 0 Total update succeeded last init ended: 2014-08-20 15:58:38+00:00 last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2014-09-03 17:54:20+00:00 vinz.cci.emory.edu: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2014-09-03 17:54:20+00:00 [root at beast ~]# ipa-replica-manage list -v `hostname` prod01.cci.emory.edu: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update started last update ended: None vinz.cci.emory.edu: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update started last update ended: None It looks like vinz is trying to replicate to itself. -- Jim Kinney Senior System Administrator Department of BioMedical Informatics Emory University jimkinney at emory.edu 404.712.0300 bmi.emory.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From cwhittl at gmail.com Wed Sep 3 18:04:44 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Wed, 3 Sep 2014 13:04:44 -0500 Subject: [Freeipa-users] Search Base issues In-Reply-To: <54075442.2050604@redhat.com> References: <540585B3.9030606@redhat.com> <5406233E.3040705@redhat.com> <54062920.4010605@redhat.com> <540631F0.1020805@redhat.com> <5406BD07.6040204@redhat.com> <5406C342.6060406@redhat.com> <540712D6.9090909@redhat.com> <54072158.9080400@redhat.com> <54075442.2050604@redhat.com> Message-ID: Thanks Rob for the explanation! I think I have it working, I just have to test a machine and verify. On Wed, Sep 3, 2014 at 12:47 PM, Rob Crittenden wrote: > Chris Whittle wrote: > > That worked, but having issues get it to work with the OSX Directory > > Utility. > > I'm wondering if it's because when you go against the OU normally it's > > returning more info about the user versus what's being returned from the > > compat "view" I'm going to experiment with the attributes it's returning > > and see if that's it. > > > > I'm also wondering why FreeIPA doesn't support multiple OU's natively, > > this would be so much easier with multiple OUs (one for my non-users and > > one for my users) > > Because they are so very often used really, really poorly, resulting in > having to move entries around a lot with no real technical reason behind > it. Think about the number of times an IT department gets renamed, oops, > today they are called Global Support Services, oh no, didn't you hear, > now they are ... Each one requiring an entire subtree move. Where the > users exist in LDAP does not generally need to reflect the > organizational structure. > > Your case is a bit different from most, where you want to host two > completely separate kinds of users. > > rob > > > > > > > On Wed, Sep 3, 2014 at 9:10 AM, Martin Kosek > > wrote: > > > > On 09/03/2014 03:08 PM, Rob Crittenden wrote: > > > Martin Kosek wrote: > > >> On 09/03/2014 09:02 AM, Martin Kosek wrote: > > >>> In the meantime, you can use the workaround that Rob sent, you > > would just need > > >>> to delete it again when the fix is in, so that the permissions > > do not step on > > >>> each other. > > >> > > >> Actually, wait a minute. I think Rob's ACI example may be too > > wide, it may > > >> expose any attribute in the compat tree, including a potential > > userPassword. > > > > > > The ACI was on his custom cn=canlogin subtree, not all of > cn=compat. > > > > > >> As I see, it seems that slapi-nis plugin do not fortunately > > expose that, but it > > >> is safer to just list the attributes that one wants to display > > (this is also > > >> what we did in FreeIPA 4.0, no global wildcard allowing ACIs any > > more). > > >> > > >> I added a respective permission via Web UI (one part of it cannot > > be added via > > >> CLI, see https://fedorahosted.org/freeipa/ticket/4522) and compat > > tree now > > >> works for me. See attached example. > > >> > > >> Resulting permission shown in CLI: > > >> > > >> # ipa permission-show "TEMPORARY - Read compat tree" > > >> Permission name: TEMPORARY - Read compat tree > > >> Granted rights: read, search, compare > > >> Effective attributes: cn, description, gecos, gidnumber, > > homedirectory, > > >> loginshell, memberuid, > > >> objectclass, uid, uidnumber > > >> Bind rule type: all > > >> Subtree: dc=mkosek-fedora20,dc=test > > >> ACI target DN: cn=compat,dc=mkosek-fedora20,dc=test > > >> > > >> It is much easier to manipulate than ACI added via ldapmodify. > > > > > > I see you filed a bug on the missing CLI option. That's why I did > the > > > ACI, because I couldn't demonstrate how to add this ACI on the > CLI. I > > > hadn't gotten around to doing that last night. > > > > > > rob > > > > Right. Surprisingly, the option was available in Web UI, thus the > Web UI > > screenshot I attached to the thread :) But we have the CLI option > fixed > > already, will be part of FreeIPA 4.0.2 which will be released very > soon. > > > > Martin > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Sep 3 18:27:33 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 03 Sep 2014 14:27:33 -0400 Subject: [Freeipa-users] replication - original master not replicating In-Reply-To: <1409767145.3681.49.camel@serenity.cci.emory.edu> References: <1409756609.3681.43.camel@serenity.cci.emory.edu> <5407546B.8030802@redhat.com> <1409767145.3681.49.camel@serenity.cci.emory.edu> Message-ID: <54075D95.4030105@redhat.com> Jim Kinney wrote: > On Wed, 2014-09-03 at 13:48 -0400, Rob Crittenden wrote: >> Jim Kinney wrote: >> > Greetings, >> > >> > I'm running freeipa 3.0 with multimaster between 3 machines. The first >> > system, the original installation machine and thus the keepers of the >> > CA, etc, is not replicating with the other two. The other two are fine. >> > Additionally, the original machine is no longer using the freeIPA >> > running on it for authentication services. >> > >> > Examples: I created a new user on the first machine using ipa user-add >> > .... and the other two systems didn't pick it up (even after an >> > overnight wait). So I thought it was not created. I then tried to create >> > the user again but on #2 machine on the web gui. It refused saying the >> > private group of that user already existed. It did not error about the >> > username. So I went to #1 and deleted the user. Back to #2 to create the >> > user and #3 picked it up within a minute. But #1 picked it up this time. >> > >> >>From #1, running id on any user in the system returns a "No such >> > user". But when I go to the gui on #1, I can find users. The #1 system >> > has files sss in nsswitch for passwd, shadow, group, services, netgroup >> > as do #2 and #3. >> > >> > When I setup #2, I ran the ipa-ca-install on the generated file from the >> > #1 machine. So I think #2 now has the CA for my department. When I tried >> > to setup #3 by using #1 as the master, it would not connect/complete >> > back to #1. I replicated from #2 and it worked. >> > >> > It's been several months (10+ or so) since I set up the #1 machine and >> > #2 was about 2 days after it. I don't know if #1 always didn't use >> > freeIPA for authentication or not. >> > >> > #1 and #2 are CentOS 6.5. #3 is CentOS 7 and freeIPA 3.3. I was >> > concerned that the version mismatch would be an issue but it seems to >> > work well between #2 and #3. >> > >> > Clearly, if I add a user now, I use #2 or #3. I can get by with not >> > messing around with #1 and it's just for master CA needs. >> > >> > Oh. I have all three in DNS and #1 and #2 are DNS servers. #3 is in a >> > separate network segment and exists to provide auth services in the >> > (likely) event a network link goes down between that location and the >> > main stack. >> >> On each master I'd run: >> >> # ipa-replica-manage list -v `hostname` >> >> This will give you the replication status on each. >> >> rob >> > OK. Interesting results. #1 is vinz, #2 is prod01, #3 is beast : > [root at vinz etc]# ipa-replica-manage list -v `hostname` > beast.cci.emory.edu: replica > last init status: None > last init ended: None > last update status: 32 - LDAP error: No such object > last update ended: None > prod01.cci.emory.edu: replica > last init status: None > last init ended: None > last update status: 0 Replica acquired successfully: Incremental > update succeeded > last update ended: 2014-09-03 17:53:07+00:00 > vinz.cci.emory.edu: replica > last init status: None > last init ended: None > last update status: -1 Incremental update has failed and requires > administrator actionLDAP error: Can't contact LDAP server > last update ended: None > > > [root at prod01 ~]# ipa-replica-manage list -v `hostname` > beast.cci.emory.edu: replica > last init status: 0 Total update succeeded > last init ended: 2014-08-20 15:58:38+00:00 > last update status: 0 Replica acquired successfully: Incremental > update succeeded > last update ended: 2014-09-03 17:54:20+00:00 > vinz.cci.emory.edu: replica > last init status: None > last init ended: None > last update status: 0 Replica acquired successfully: Incremental > update succeeded > last update ended: 2014-09-03 17:54:20+00:00 > > > [root at beast ~]# ipa-replica-manage list -v `hostname` > prod01.cci.emory.edu: replica > last init status: None > last init ended: None > last update status: 0 Replica acquired successfully: Incremental > update started > last update ended: None > vinz.cci.emory.edu: replica > last init status: None > last init ended: None > last update status: 0 Replica acquired successfully: Incremental > update started > last update ended: None > > > It looks like vinz is trying to replicate to itself. Yeah. You can see the actual agreements by binding as cn=Directory Manager and searching in cn=mapping tree, cn=config. We'd had to see the agreement to really know what's going on, but it shouldn't affect sending data to the other masters. So it looks like vinz is communicating ok with prod01 so the data should be getting shared ok, esp since prod01 and beast have agreements. I'd start by checking on the replication agreement between vinz and beast. The error 32 is a bit odd in itself. The 389-ds error log may contain more information. rob From rap at phas.ubc.ca Wed Sep 3 19:16:35 2014 From: rap at phas.ubc.ca (Ron) Date: Wed, 03 Sep 2014 12:16:35 -0700 Subject: [Freeipa-users] ipa user-find finds user but ipa user-del fails In-Reply-To: <54075346.4030505@redhat.com> References: <54073F4C.60602@phas.ubc.ca> <540742AF.20402@redhat.com> <54075346.4030505@redhat.com> Message-ID: <54076913.2070902@phas.ubc.ca> Here is what is in the /var/log/dirsrv/slapd-YOUR-REALM/access... logfile: conn=17342 fd=86 slot=86 connection from 142.103.xxx.xx to 142.103.xxx.xx conn=17342 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI conn=17342 op=0 RESULT err=14 tag=97 nentries=0 etime=1, SASL bind in progress conn=17342 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI conn=17342 op=1 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress conn=17342 op=2 BIND dn="" method=sasl version=3 mech=GSSAPI conn=17342 op=2 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=admin,cn=users,cn=accounts,dc=pxxx,dc=abc,dc=ca" conn=17342 op=3 SRCH base="cn=ipaconfig,cn=etc,dc=pxxx,dc=abc,dc=ca" scope=0 filter="(objectClass=*)" attrs=ALL conn=17342 op=3 RESULT err=0 tag=101 nentries=1 etime=0 conn=17342 op=4 SRCH base="cn=users,cn=accounts,dc=pxxx,dc=abc,dc=ca" scope=1 filter="(&(objectClass=posixaccount)(memberOf=cn=admins,cn=groups,cn=accounts,dc=pxxx,dc=abc,dc=ca))" attrs="telephoneNumber sshpubkeyfp uid title loginShell uidNumber gidNumber sn homeDirectory mail givenName nsAccountLock" conn=17342 op=4 RESULT err=0 tag=101 nentries=1 etime=0 conn=17342 op=5 SRCH base="uid=admin,cn=users,cn=accounts,dc=pxxx,dc=abc,dc=ca" scope=0 filter="(userPassword=*)" attrs="userPassword" conn=17342 op=5 RESULT err=0 tag=101 nentries=1 etime=0 conn=17342 op=6 SRCH base="uid=admin,cn=users,cn=accounts,dc=pxxx,dc=abc,dc=ca" scope=0 filter="(krbPrincipalKey=*)" attrs="krbPrincipalKey" conn=17342 op=6 RESULT err=0 tag=101 nentries=1 etime=0 conn=17342 op=7 SRCH base="uid=admin,cn=users,cn=accounts,dc=pxxx,dc=abc,dc=ca" scope=0 filter="(objectClass=*)" attrs="ipaSshPubKey" conn=17342 op=7 RESULT err=0 tag=101 nentries=1 etime=0 conn=17342 op=8 DEL dn="uid=phys210e,cn=users,cn=accounts,dc=pxxx,dc=abc,dc=ca" conn=17342 op=8 RESULT err=32 tag=107 nentries=0 etime=0 conn=17342 op=9 UNBIND conn=17342 op=9 fd=86 closed - U1 And here is the result of the user-show command: [root at ipa slapd-pxxx-abc-CA]# ipa user-find --login phys210e -------------- 1 user matched -------------- User login: phys210e First name: Testing Last name: Phys210 Home directory: /home2/phys210e Login shell: /bin/bash Email address: phys210e at pxxx.abc.ca UID: 15010 GID: 15010 Account disabled: False Password: True Kerberos keys available: False ---------------------------- Number of entries returned 1 ---------------------------- [root at ipa slapd-pxxx-abc-CA]# ipa user-show --all --raw phys210e ipa: ERROR: phys210e: user not found On 09/03/2014 10:43 AM, Rob Crittenden wrote: > Martin Kosek wrote: >> Can you check /var/log/dirsrv/slapd-YOUR-REALM/access, search for the DEL >> operation and see what was the error code that DS gave when it refused to >> delete the user? > Were I to guess the issue is that this is a replication conflict entry. > If you do: > > # ipa user-show --all --raw phys210e |grep dn: > > It will likely begin with nsuniqueid=, ... > > The reason it can be found and not deleted is we create the dn to be > removed, we don't search for it. So the user uid=phys210e,cn=users,... > etc doesn't exist but the user nsuniqueid= ... does. > > You'll need to use ldapmodify or ldapdelete to remove the entry though > I'd check your other masters to see what the state of the user is there. > > rob > >> Martin >> >> On 09/03/2014 06:18 PM, Ron wrote: >>> user-find sees a user but user-del cannot remove it. What can I do? >>> Thanks. >>> Regards, >>> Ron >>> >>> [root at ipa]# ipa user-find --login phys210e >>> -------------- >>> 1 user matched >>> -------------- >>> User login: phys210e >>> First name: Testing >>> Last name: Phys210 >>> Home directory: /home2/phys210e >>> Login shell: /bin/bash >>> Email address: phys210e at pxxx.abc.ca >>> UID: 15010 >>> GID: 15010 >>> Account disabled: False >>> Password: True >>> Kerberos keys available: False >>> ---------------------------- >>> Number of entries returned 1 >>> ---------------------------- >>> [root at ipa]# ipa user-del phys210e --continue >>> --------------- >>> Deleted user "" >>> --------------- >>> Failed to remove: phys210e >>> >>> >>> [root at ipa]# cat /etc/redhat-release >>> Red Hat Enterprise Linux Server release 6.5 (Santiago) >>> >>> [root at ipa]# rpm -qa|grep ipa; rpm -qa|grep 389 >>> ipa-pki-ca-theme-9.0.3-7.el6.noarch >>> ipa-admintools-3.0.0-37.el6.i686 >>> ipa-pki-common-theme-9.0.3-7.el6.noarch >>> libipa_hbac-1.9.2-129.el6_5.4.i686 >>> ipa-server-selinux-3.0.0-37.el6.i686 >>> python-iniparse-0.3.1-2.1.el6.noarch >>> libipa_hbac-python-1.9.2-129.el6_5.4.i686 >>> ipa-server-3.0.0-37.el6.i686 >>> ipa-python-3.0.0-37.el6.i686 >>> ipa-client-3.0.0-37.el6.i686 >>> 389-ds-base-libs-1.2.11.15-33.el6_5.i686 >>> 389-ds-base-1.2.11.15-33.el6_5.i686 -- Ron Parachoniak Systems Manager, Department of Physics & Astronomy University of British Columbia, Vancouver, B.C. V6T 1Z1 Phone: (604) 838-6437 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xA1D0F827.asc Type: application/pgp-keys Size: 4721 bytes Desc: not available URL: From rcritten at redhat.com Wed Sep 3 19:19:19 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 03 Sep 2014 15:19:19 -0400 Subject: [Freeipa-users] Cert Renewal In-Reply-To: References: <53FBBA74.2040807@redhat.com> <53FCE594.5040106@redhat.com> Message-ID: <540769B7.4030108@redhat.com> Ott, Dennis wrote: > I may need a little more direction here. > > The output from getcert list-cas does not contain the string 'ca_renewal'. > > What does this indicate? I don't have a 2 -> 3 updated server handy so I'm going on best guesses from reading the code. It is probably ok. You really just need to be sure to have a CA that has a submit script of: dogtag-ipa-retrieve-agent-submit and one for dogtag-ipa-renew-agent What is the output from list-cas? The way that CA renewal works is this: - One CA, the first install by default, is marked as the CA renewal master. The only thing that distinguishes this master is the way the renewal scripts are configured. This CA does the actual renewal of the certificates and pushes the resulting public certs into a shared space in the IPA LDAP tree - The other CA's monitor this area, via those two dotag-ipa-* scripts, and fetch and install updated certificates when one is available. When a cert is in CA_WORKING state it means that an update should be available but isn't in the shared tree, so certmonger will try again in a few hours. Assuming that certmonger is configured properly then it should just be a matter of getting the right certs added to the LDAP tree. rob > > > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Tuesday, August 26, 2014 3:53 PM > To: Ott, Dennis; Freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Cert Renewal > > Ott, Dennis wrote: >> No services are currently running on the replica (and I am hesitant to start them) but, my recollection is that I did the replica server installation with the --setup-ca option. Also, there are /var/lib/dirsrv/slapd-PKI-IPA/ and /etc/pki-ca/ directories in place on the replica. >> >> ipa-getcert list shows all certs with a status of: CA_UNREACHABLE (but >> then, the service is down. The master also gave this status, even with >> the service running, until I followed the cert renewal procedure.) >> >> So, with the replica running a CA, should I follow the same procedure that I used on the master? Anything else to look out for? > > No, the procedure is slightly different on the replica. > > You need to start by ensuring that certmonger has a CA type for renewal: > > # getcert list-cas > > Look for ca_renewal > > Check the CA subsystem certs to see how they are configured. > > The CA should be dogtag-ipa-retrieve-agent-submit for "auditSigningCert cert-pki-ca", "ocspSigningCert cert-pki-ca" and "subsystemCert cert-pki-ca" and a pre-save command of stop_pkicad and a post-save a restart_pkicad PKI-IPA > > The agent cert, ipaCert, should be using "dogtag-ipa-retrieve-agent-submit", a blank pre-save command and a post-save command of restart_httpd. > > rob > > >> > >> Thanks. >> >> Dennis >> >> >> -----Original Message----- >> From: Rob Crittenden [mailto:rcritten at redhat.com] >> Sent: Monday, August 25, 2014 6:37 PM >> To: Ott, Dennis; freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] Cert Renewal >> >> Ott, Dennis wrote: >>> I have an IPA setup, one master, one replica; originally installed as >>> v 2.x and later updated to v 3.0. For whatever reasons, the certs >>> did not automatically renew and the services would no longer start. I >>> updated the certs manually on the master using the procedure shown at: >>> >>> >>> >>> http://www.freeipa.org/page/IPA_2x_Certificate_Renewal >>> >>> >>> >>> The master is now functioning properly. >>> >>> >>> >>> >>> >>> At this point, the IPA service is still stopped on the replica. I >>> hesitate to start it for concern it could interfere with the >>> now-working master. >>> >>> >>> >>> What would be the recommended method for returning the replica to service? >> >> It depends on whether the replica. Does it also run a CA? If not then you can try restarting the certmonger service. This should cause it to fetch new certificates for the other IPA servers. ipa-getcert list will show you the status, wait until they are all MONITORING. >> >> Once that works then you can safely restart the world. Any changes on the master will be replicated out, and vice versa. >> >> rob >> > From rcritten at redhat.com Wed Sep 3 19:26:22 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 03 Sep 2014 15:26:22 -0400 Subject: [Freeipa-users] ipa user-find finds user but ipa user-del fails In-Reply-To: <54076913.2070902@phas.ubc.ca> References: <54073F4C.60602@phas.ubc.ca> <540742AF.20402@redhat.com> <54075346.4030505@redhat.com> <54076913.2070902@phas.ubc.ca> Message-ID: <54076B5E.3060501@redhat.com> Ron wrote: > And here is the result of the user-show command: > [root at ipa slapd-pxxx-abc-CA]# ipa user-show --all --raw phys210e > ipa: ERROR: phys210e: user not found Sorry, thinko on my part. Do ipa user-find --all --raw --login phys210e user-show is going to have the same issue as user-delete. rob > > > > On 09/03/2014 10:43 AM, Rob Crittenden wrote: >> Martin Kosek wrote: >>> Can you check /var/log/dirsrv/slapd-YOUR-REALM/access, search for the DEL >>> operation and see what was the error code that DS gave when it refused to >>> delete the user? >> Were I to guess the issue is that this is a replication conflict entry. >> If you do: >> >> # ipa user-show --all --raw phys210e |grep dn: >> >> It will likely begin with nsuniqueid=, ... >> >> The reason it can be found and not deleted is we create the dn to be >> removed, we don't search for it. So the user uid=phys210e,cn=users,... >> etc doesn't exist but the user nsuniqueid= ... does. >> >> You'll need to use ldapmodify or ldapdelete to remove the entry though >> I'd check your other masters to see what the state of the user is there. >> >> rob >> >>> Martin >>> >>> On 09/03/2014 06:18 PM, Ron wrote: >>>> user-find sees a user but user-del cannot remove it. What can I do? >>>> Thanks. >>>> Regards, >>>> Ron >>>> >>>> [root at ipa]# ipa user-find --login phys210e >>>> -------------- >>>> 1 user matched >>>> -------------- >>>> User login: phys210e >>>> First name: Testing >>>> Last name: Phys210 >>>> Home directory: /home2/phys210e >>>> Login shell: /bin/bash >>>> Email address: phys210e at pxxx.abc.ca >>>> UID: 15010 >>>> GID: 15010 >>>> Account disabled: False >>>> Password: True >>>> Kerberos keys available: False >>>> ---------------------------- >>>> Number of entries returned 1 >>>> ---------------------------- >>>> [root at ipa]# ipa user-del phys210e --continue >>>> --------------- >>>> Deleted user "" >>>> --------------- >>>> Failed to remove: phys210e >>>> >>>> >>>> [root at ipa]# cat /etc/redhat-release >>>> Red Hat Enterprise Linux Server release 6.5 (Santiago) >>>> >>>> [root at ipa]# rpm -qa|grep ipa; rpm -qa|grep 389 >>>> ipa-pki-ca-theme-9.0.3-7.el6.noarch >>>> ipa-admintools-3.0.0-37.el6.i686 >>>> ipa-pki-common-theme-9.0.3-7.el6.noarch >>>> libipa_hbac-1.9.2-129.el6_5.4.i686 >>>> ipa-server-selinux-3.0.0-37.el6.i686 >>>> python-iniparse-0.3.1-2.1.el6.noarch >>>> libipa_hbac-python-1.9.2-129.el6_5.4.i686 >>>> ipa-server-3.0.0-37.el6.i686 >>>> ipa-python-3.0.0-37.el6.i686 >>>> ipa-client-3.0.0-37.el6.i686 >>>> 389-ds-base-libs-1.2.11.15-33.el6_5.i686 >>>> 389-ds-base-1.2.11.15-33.el6_5.i686 > > > -- > Ron Parachoniak > Systems Manager, Department of Physics & Astronomy > University of British Columbia, Vancouver, B.C. V6T 1Z1 > Phone: (604) 838-6437 > From rap at phas.ubc.ca Wed Sep 3 20:05:56 2014 From: rap at phas.ubc.ca (Ron) Date: Wed, 03 Sep 2014 13:05:56 -0700 Subject: [Freeipa-users] ipa user-find finds user but ipa user-del fails In-Reply-To: <54076B5E.3060501@redhat.com> References: <54073F4C.60602@phas.ubc.ca> <540742AF.20402@redhat.com> <54075346.4030505@redhat.com> <54076913.2070902@phas.ubc.ca> <54076B5E.3060501@redhat.com> Message-ID: <540774A4.2030202@phas.ubc.ca> [root at ipa]# ipa user-find --all --raw --login phys210e | grep dn: dn: nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=xxxx,dc=abc,dc=ca On 09/03/2014 12:26 PM, Rob Crittenden wrote: > Ron wrote: >> And here is the result of the user-show command: >> [root at ipa slapd-pxxx-abc-CA]# ipa user-show --all --raw phys210e >> ipa: ERROR: phys210e: user not found > Sorry, thinko on my part. Do ipa user-find --all --raw --login phys210e > > user-show is going to have the same issue as user-delete. > > rob > >> >> >> On 09/03/2014 10:43 AM, Rob Crittenden wrote: >>> Martin Kosek wrote: >>>> Can you check /var/log/dirsrv/slapd-YOUR-REALM/access, search for the DEL >>>> operation and see what was the error code that DS gave when it refused to >>>> delete the user? >>> Were I to guess the issue is that this is a replication conflict entry. >>> If you do: >>> >>> # ipa user-show --all --raw phys210e |grep dn: >>> >>> It will likely begin with nsuniqueid=, ... >>> >>> The reason it can be found and not deleted is we create the dn to be >>> removed, we don't search for it. So the user uid=phys210e,cn=users,... >>> etc doesn't exist but the user nsuniqueid= ... does. >>> >>> You'll need to use ldapmodify or ldapdelete to remove the entry though >>> I'd check your other masters to see what the state of the user is there. >>> >>> rob >>> >>>> Martin >>>> >>>> On 09/03/2014 06:18 PM, Ron wrote: >>>>> user-find sees a user but user-del cannot remove it. What can I do? >>>>> Thanks. >>>>> Regards, >>>>> Ron >>>>> >>>>> [root at ipa]# ipa user-find --login phys210e >>>>> -------------- >>>>> 1 user matched >>>>> -------------- >>>>> User login: phys210e >>>>> First name: Testing >>>>> Last name: Phys210 >>>>> Home directory: /home2/phys210e >>>>> Login shell: /bin/bash >>>>> Email address: phys210e at pxxx.abc.ca >>>>> UID: 15010 >>>>> GID: 15010 >>>>> Account disabled: False >>>>> Password: True >>>>> Kerberos keys available: False >>>>> ---------------------------- >>>>> Number of entries returned 1 >>>>> ---------------------------- >>>>> [root at ipa]# ipa user-del phys210e --continue >>>>> --------------- >>>>> Deleted user "" >>>>> --------------- >>>>> Failed to remove: phys210e >>>>> >>>>> >>>>> [root at ipa]# cat /etc/redhat-release >>>>> Red Hat Enterprise Linux Server release 6.5 (Santiago) >>>>> >>>>> [root at ipa]# rpm -qa|grep ipa; rpm -qa|grep 389 >>>>> ipa-pki-ca-theme-9.0.3-7.el6.noarch >>>>> ipa-admintools-3.0.0-37.el6.i686 >>>>> ipa-pki-common-theme-9.0.3-7.el6.noarch >>>>> libipa_hbac-1.9.2-129.el6_5.4.i686 >>>>> ipa-server-selinux-3.0.0-37.el6.i686 >>>>> python-iniparse-0.3.1-2.1.el6.noarch >>>>> libipa_hbac-python-1.9.2-129.el6_5.4.i686 >>>>> ipa-server-3.0.0-37.el6.i686 >>>>> ipa-python-3.0.0-37.el6.i686 >>>>> ipa-client-3.0.0-37.el6.i686 >>>>> 389-ds-base-libs-1.2.11.15-33.el6_5.i686 >>>>> 389-ds-base-1.2.11.15-33.el6_5.i686 >> >> -- >> Ron Parachoniak >> Systems Manager, Department of Physics & Astronomy >> University of British Columbia, Vancouver, B.C. V6T 1Z1 >> Phone: (604) 838-6437 >> -- Ron Parachoniak Systems Manager, Department of Physics & Astronomy University of British Columbia, Vancouver, B.C. V6T 1Z1 Phone: (604) 838-6437 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xA1D0F827.asc Type: application/pgp-keys Size: 4721 bytes Desc: not available URL: From rap at phas.ubc.ca Wed Sep 3 20:44:32 2014 From: rap at phas.ubc.ca (Ron) Date: Wed, 03 Sep 2014 13:44:32 -0700 Subject: [Freeipa-users] ipa user-find finds user but ipa user-del fails In-Reply-To: <54076B5E.3060501@redhat.com> References: <54073F4C.60602@phas.ubc.ca> <540742AF.20402@redhat.com> <54075346.4030505@redhat.com> <54076913.2070902@phas.ubc.ca> <54076B5E.3060501@redhat.com> Message-ID: <54077DB0.10606@phas.ubc.ca> By the way, all three replica servers show the same: [root at ipa]# ipa user-find --all --raw --login phys210e | grep dn: dn: nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=xxxx,dc=abc,dc=ca [root at ipa01]# ipa user-find --all --raw --login phys210e | grep dn: dn: nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=xxxx,dc=abc,dc=ca [root at ipa02]# ipa user-find --all --raw --login phys210e | grep dn: dn: nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=xxxx,dc=abc,dc=ca On 09/03/2014 12:26 PM, Rob Crittenden wrote: > Ron wrote: >> And here is the result of the user-show command: >> [root at ipa slapd-pxxx-abc-CA]# ipa user-show --all --raw phys210e >> ipa: ERROR: phys210e: user not found > Sorry, thinko on my part. Do ipa user-find --all --raw --login phys210e > > user-show is going to have the same issue as user-delete. > > rob > >> >> >> On 09/03/2014 10:43 AM, Rob Crittenden wrote: >>> Martin Kosek wrote: >>>> Can you check /var/log/dirsrv/slapd-YOUR-REALM/access, search for the DEL >>>> operation and see what was the error code that DS gave when it refused to >>>> delete the user? >>> Were I to guess the issue is that this is a replication conflict entry. >>> If you do: >>> >>> # ipa user-show --all --raw phys210e |grep dn: >>> >>> It will likely begin with nsuniqueid=, ... >>> >>> The reason it can be found and not deleted is we create the dn to be >>> removed, we don't search for it. So the user uid=phys210e,cn=users,... >>> etc doesn't exist but the user nsuniqueid= ... does. >>> >>> You'll need to use ldapmodify or ldapdelete to remove the entry though >>> I'd check your other masters to see what the state of the user is there. >>> >>> rob >>> >>>> Martin >>>> >>>> On 09/03/2014 06:18 PM, Ron wrote: >>>>> user-find sees a user but user-del cannot remove it. What can I do? >>>>> Thanks. >>>>> Regards, >>>>> Ron >>>>> >>>>> [root at ipa]# ipa user-find --login phys210e >>>>> -------------- >>>>> 1 user matched >>>>> -------------- >>>>> User login: phys210e >>>>> First name: Testing >>>>> Last name: Phys210 >>>>> Home directory: /home2/phys210e >>>>> Login shell: /bin/bash >>>>> Email address: phys210e at pxxx.abc.ca >>>>> UID: 15010 >>>>> GID: 15010 >>>>> Account disabled: False >>>>> Password: True >>>>> Kerberos keys available: False >>>>> ---------------------------- >>>>> Number of entries returned 1 >>>>> ---------------------------- >>>>> [root at ipa]# ipa user-del phys210e --continue >>>>> --------------- >>>>> Deleted user "" >>>>> --------------- >>>>> Failed to remove: phys210e >>>>> >>>>> >>>>> [root at ipa]# cat /etc/redhat-release >>>>> Red Hat Enterprise Linux Server release 6.5 (Santiago) >>>>> >>>>> [root at ipa]# rpm -qa|grep ipa; rpm -qa|grep 389 >>>>> ipa-pki-ca-theme-9.0.3-7.el6.noarch >>>>> ipa-admintools-3.0.0-37.el6.i686 >>>>> ipa-pki-common-theme-9.0.3-7.el6.noarch >>>>> libipa_hbac-1.9.2-129.el6_5.4.i686 >>>>> ipa-server-selinux-3.0.0-37.el6.i686 >>>>> python-iniparse-0.3.1-2.1.el6.noarch >>>>> libipa_hbac-python-1.9.2-129.el6_5.4.i686 >>>>> ipa-server-3.0.0-37.el6.i686 >>>>> ipa-python-3.0.0-37.el6.i686 >>>>> ipa-client-3.0.0-37.el6.i686 >>>>> 389-ds-base-libs-1.2.11.15-33.el6_5.i686 >>>>> 389-ds-base-1.2.11.15-33.el6_5.i686 >> >> -- >> Ron Parachoniak >> Systems Manager, Department of Physics & Astronomy >> University of British Columbia, Vancouver, B.C. V6T 1Z1 >> Phone: (604) 838-6437 >> -- Ron Parachoniak Systems Manager, Department of Physics & Astronomy University of British Columbia, Vancouver, B.C. V6T 1Z1 Phone: (604) 838-6437 From cwhittl at gmail.com Wed Sep 3 20:45:29 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Wed, 3 Sep 2014 15:45:29 -0500 Subject: [Freeipa-users] Search Base issues In-Reply-To: References: <540585B3.9030606@redhat.com> <5406233E.3040705@redhat.com> <54062920.4010605@redhat.com> <540631F0.1020805@redhat.com> <5406BD07.6040204@redhat.com> <5406C342.6060406@redhat.com> <540712D6.9090909@redhat.com> <54072158.9080400@redhat.com> <54075442.2050604@redhat.com> Message-ID: Success here is my LDIF if anyone needs to do this with a MAC > dn: cn=Mac Users, cn=Schema Compatibility, cn=plugins, cn=config > > objectClass: top > > objectClass: extensibleObject > > cn: Mac Users > > schema-compat-search-base: cn=users,cn=accounts,dc=DOMAIN,dc=com > > schema-compat-search-filter: > (&(objectClass=posixaccount)(memberOf=cn=canlogin,cn=groups,cn=accounts,dc > DOMAIN,dc=com)) > > schema-compat-container-group: cn=compat,dc=DOMAIN,dc=com > > schema-compat-container-rdn: cn=canlogin > > schema-compat-entry-rdn: cn=%{cn} > > schema-compat-entry-attribute: objectclass=inetOrgPerson > > schema-compat-entry-attribute: objectclass=posixAccount > > schema-compat-entry-attribute: gecos=%{cn} > > schema-compat-entry-attribute: cn=%{cn} > > schema-compat-entry-attribute: uid=%{uid} > > schema-compat-entry-attribute: uidNumber=%{uidNumber} > > schema-compat-entry-attribute: gidNumber=%{gidNumber} > > schema-compat-entry-attribute: loginShell=%{loginShell} > > schema-compat-entry-attribute: homeDirectory=%{homeDirectory} > On Wed, Sep 3, 2014 at 1:04 PM, Chris Whittle wrote: > Thanks Rob for the explanation! > > I think I have it working, I just have to test a machine and verify. > > > On Wed, Sep 3, 2014 at 12:47 PM, Rob Crittenden > wrote: > >> Chris Whittle wrote: >> > That worked, but having issues get it to work with the OSX Directory >> > Utility. >> > I'm wondering if it's because when you go against the OU normally it's >> > returning more info about the user versus what's being returned from the >> > compat "view" I'm going to experiment with the attributes it's returning >> > and see if that's it. >> > >> > I'm also wondering why FreeIPA doesn't support multiple OU's natively, >> > this would be so much easier with multiple OUs (one for my non-users and >> > one for my users) >> >> Because they are so very often used really, really poorly, resulting in >> having to move entries around a lot with no real technical reason behind >> it. Think about the number of times an IT department gets renamed, oops, >> today they are called Global Support Services, oh no, didn't you hear, >> now they are ... Each one requiring an entire subtree move. Where the >> users exist in LDAP does not generally need to reflect the >> organizational structure. >> >> Your case is a bit different from most, where you want to host two >> completely separate kinds of users. >> >> rob >> >> > >> > >> > On Wed, Sep 3, 2014 at 9:10 AM, Martin Kosek > > > wrote: >> > >> > On 09/03/2014 03:08 PM, Rob Crittenden wrote: >> > > Martin Kosek wrote: >> > >> On 09/03/2014 09:02 AM, Martin Kosek wrote: >> > >>> In the meantime, you can use the workaround that Rob sent, you >> > would just need >> > >>> to delete it again when the fix is in, so that the permissions >> > do not step on >> > >>> each other. >> > >> >> > >> Actually, wait a minute. I think Rob's ACI example may be too >> > wide, it may >> > >> expose any attribute in the compat tree, including a potential >> > userPassword. >> > > >> > > The ACI was on his custom cn=canlogin subtree, not all of >> cn=compat. >> > > >> > >> As I see, it seems that slapi-nis plugin do not fortunately >> > expose that, but it >> > >> is safer to just list the attributes that one wants to display >> > (this is also >> > >> what we did in FreeIPA 4.0, no global wildcard allowing ACIs any >> > more). >> > >> >> > >> I added a respective permission via Web UI (one part of it cannot >> > be added via >> > >> CLI, see https://fedorahosted.org/freeipa/ticket/4522) and >> compat >> > tree now >> > >> works for me. See attached example. >> > >> >> > >> Resulting permission shown in CLI: >> > >> >> > >> # ipa permission-show "TEMPORARY - Read compat tree" >> > >> Permission name: TEMPORARY - Read compat tree >> > >> Granted rights: read, search, compare >> > >> Effective attributes: cn, description, gecos, gidnumber, >> > homedirectory, >> > >> loginshell, memberuid, >> > >> objectclass, uid, uidnumber >> > >> Bind rule type: all >> > >> Subtree: dc=mkosek-fedora20,dc=test >> > >> ACI target DN: cn=compat,dc=mkosek-fedora20,dc=test >> > >> >> > >> It is much easier to manipulate than ACI added via ldapmodify. >> > > >> > > I see you filed a bug on the missing CLI option. That's why I did >> the >> > > ACI, because I couldn't demonstrate how to add this ACI on the >> CLI. I >> > > hadn't gotten around to doing that last night. >> > > >> > > rob >> > >> > Right. Surprisingly, the option was available in Web UI, thus the >> Web UI >> > screenshot I attached to the thread :) But we have the CLI option >> fixed >> > already, will be part of FreeIPA 4.0.2 which will be released very >> soon. >> > >> > Martin >> > >> > >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Wed Sep 3 21:24:34 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 03 Sep 2014 15:24:34 -0600 Subject: [Freeipa-users] ipa user-find finds user but ipa user-del fails In-Reply-To: <54077DB0.10606@phas.ubc.ca> References: <54073F4C.60602@phas.ubc.ca> <540742AF.20402@redhat.com> <54075346.4030505@redhat.com> <54076913.2070902@phas.ubc.ca> <54076B5E.3060501@redhat.com> <54077DB0.10606@phas.ubc.ca> Message-ID: <54078712.8040902@redhat.com> On 09/03/2014 02:44 PM, Ron wrote: > By the way, all three replica servers show the same: > > [root at ipa]# ipa user-find --all --raw --login phys210e | grep dn: > dn: > nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=xxxx,dc=abc,dc=ca > > [root at ipa01]# ipa user-find --all --raw --login phys210e | grep dn: > dn: > nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=xxxx,dc=abc,dc=ca > > [root at ipa02]# ipa user-find --all --raw --login phys210e | grep dn: > dn: > nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=xxxx,dc=abc,dc=ca These appear to be replication conflict entries. Not sure what happened. See https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html > > On 09/03/2014 12:26 PM, Rob Crittenden wrote: >> Ron wrote: >>> And here is the result of the user-show command: >>> [root at ipa slapd-pxxx-abc-CA]# ipa user-show --all --raw phys210e >>> ipa: ERROR: phys210e: user not found >> Sorry, thinko on my part. Do ipa user-find --all --raw --login phys210e >> >> user-show is going to have the same issue as user-delete. >> >> rob >> >>> >>> On 09/03/2014 10:43 AM, Rob Crittenden wrote: >>>> Martin Kosek wrote: >>>>> Can you check /var/log/dirsrv/slapd-YOUR-REALM/access, search for the DEL >>>>> operation and see what was the error code that DS gave when it refused to >>>>> delete the user? >>>> Were I to guess the issue is that this is a replication conflict entry. >>>> If you do: >>>> >>>> # ipa user-show --all --raw phys210e |grep dn: >>>> >>>> It will likely begin with nsuniqueid=, ... >>>> >>>> The reason it can be found and not deleted is we create the dn to be >>>> removed, we don't search for it. So the user uid=phys210e,cn=users,... >>>> etc doesn't exist but the user nsuniqueid= ... does. >>>> >>>> You'll need to use ldapmodify or ldapdelete to remove the entry though >>>> I'd check your other masters to see what the state of the user is there. >>>> >>>> rob >>>> >>>>> Martin >>>>> >>>>> On 09/03/2014 06:18 PM, Ron wrote: >>>>>> user-find sees a user but user-del cannot remove it. What can I do? >>>>>> Thanks. >>>>>> Regards, >>>>>> Ron >>>>>> >>>>>> [root at ipa]# ipa user-find --login phys210e >>>>>> -------------- >>>>>> 1 user matched >>>>>> -------------- >>>>>> User login: phys210e >>>>>> First name: Testing >>>>>> Last name: Phys210 >>>>>> Home directory: /home2/phys210e >>>>>> Login shell: /bin/bash >>>>>> Email address: phys210e at pxxx.abc.ca >>>>>> UID: 15010 >>>>>> GID: 15010 >>>>>> Account disabled: False >>>>>> Password: True >>>>>> Kerberos keys available: False >>>>>> ---------------------------- >>>>>> Number of entries returned 1 >>>>>> ---------------------------- >>>>>> [root at ipa]# ipa user-del phys210e --continue >>>>>> --------------- >>>>>> Deleted user "" >>>>>> --------------- >>>>>> Failed to remove: phys210e >>>>>> >>>>>> >>>>>> [root at ipa]# cat /etc/redhat-release >>>>>> Red Hat Enterprise Linux Server release 6.5 (Santiago) >>>>>> >>>>>> [root at ipa]# rpm -qa|grep ipa; rpm -qa|grep 389 >>>>>> ipa-pki-ca-theme-9.0.3-7.el6.noarch >>>>>> ipa-admintools-3.0.0-37.el6.i686 >>>>>> ipa-pki-common-theme-9.0.3-7.el6.noarch >>>>>> libipa_hbac-1.9.2-129.el6_5.4.i686 >>>>>> ipa-server-selinux-3.0.0-37.el6.i686 >>>>>> python-iniparse-0.3.1-2.1.el6.noarch >>>>>> libipa_hbac-python-1.9.2-129.el6_5.4.i686 >>>>>> ipa-server-3.0.0-37.el6.i686 >>>>>> ipa-python-3.0.0-37.el6.i686 >>>>>> ipa-client-3.0.0-37.el6.i686 >>>>>> 389-ds-base-libs-1.2.11.15-33.el6_5.i686 >>>>>> 389-ds-base-1.2.11.15-33.el6_5.i686 >>> -- >>> Ron Parachoniak >>> Systems Manager, Department of Physics & Astronomy >>> University of British Columbia, Vancouver, B.C. V6T 1Z1 >>> Phone: (604) 838-6437 >>> > From Dennis.Ott at mckesson.com Wed Sep 3 21:28:23 2014 From: Dennis.Ott at mckesson.com (Ott, Dennis) Date: Wed, 3 Sep 2014 21:28:23 +0000 Subject: [Freeipa-users] Cert Renewal In-Reply-To: <540769B7.4030108@redhat.com> References: <53FBBA74.2040807@redhat.com> <53FCE594.5040106@redhat.com> <540769B7.4030108@redhat.com> Message-ID: The output of getcert list-cas from the replica is below. It contains both the 'renew' and the 'retrieve' items. As previously stated, the services are not running on the replica. I have been nervous about starting them; not wanting to impact the functional master. But, it is sounding like starting them up is all I really need to do to fix things. Would I need to set the date back on both systems? Will the certs renew more-or-less immediately, or will there be some lag after starting up the replica ipa service? CA 'SelfSign': is-default: no ca-type: INTERNAL:SELF next-serial-number: 01 CA 'IPA': is-default: no ca-type: EXTERNAL helper-location: /usr/libexec/certmonger/ipa-submit CA 'certmaster': is-default: no ca-type: EXTERNAL helper-location: /usr/libexec/certmonger/certmaster-submit CA 'dogtag-ipa-renew-agent': is-default: no ca-type: EXTERNAL helper-location: /usr/libexec/certmonger/dogtag-ipa-renew-agent-submit CA 'dogtag-ipa-retrieve-agent-submit': is-default: no ca-type: EXTERNAL helper-location: /usr/libexec/certmonger/dogtag-ipa-retrieve-agent-submit -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: Wednesday, September 03, 2014 3:19 PM To: Ott, Dennis; Freeipa-users at redhat.com Subject: Re: [Freeipa-users] Cert Renewal Ott, Dennis wrote: > I may need a little more direction here. > > The output from getcert list-cas does not contain the string 'ca_renewal'. > > What does this indicate? I don't have a 2 -> 3 updated server handy so I'm going on best guesses from reading the code. It is probably ok. You really just need to be sure to have a CA that has a submit script of: dogtag-ipa-retrieve-agent-submit and one for dogtag-ipa-renew-agent What is the output from list-cas? The way that CA renewal works is this: - One CA, the first install by default, is marked as the CA renewal master. The only thing that distinguishes this master is the way the renewal scripts are configured. This CA does the actual renewal of the certificates and pushes the resulting public certs into a shared space in the IPA LDAP tree - The other CA's monitor this area, via those two dotag-ipa-* scripts, and fetch and install updated certificates when one is available. When a cert is in CA_WORKING state it means that an update should be available but isn't in the shared tree, so certmonger will try again in a few hours. Assuming that certmonger is configured properly then it should just be a matter of getting the right certs added to the LDAP tree. rob > > > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Tuesday, August 26, 2014 3:53 PM > To: Ott, Dennis; Freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Cert Renewal > > Ott, Dennis wrote: >> No services are currently running on the replica (and I am hesitant to start them) but, my recollection is that I did the replica server installation with the --setup-ca option. Also, there are /var/lib/dirsrv/slapd-PKI-IPA/ and /etc/pki-ca/ directories in place on the replica. >> >> ipa-getcert list shows all certs with a status of: CA_UNREACHABLE >> (but then, the service is down. The master also gave this status, >> even with the service running, until I followed the cert renewal >> procedure.) >> >> So, with the replica running a CA, should I follow the same procedure that I used on the master? Anything else to look out for? > > No, the procedure is slightly different on the replica. > > You need to start by ensuring that certmonger has a CA type for renewal: > > # getcert list-cas > > Look for ca_renewal > > Check the CA subsystem certs to see how they are configured. > > The CA should be dogtag-ipa-retrieve-agent-submit for > "auditSigningCert cert-pki-ca", "ocspSigningCert cert-pki-ca" and > "subsystemCert cert-pki-ca" and a pre-save command of stop_pkicad and > a post-save a restart_pkicad PKI-IPA > > The agent cert, ipaCert, should be using "dogtag-ipa-retrieve-agent-submit", a blank pre-save command and a post-save command of restart_httpd. > > rob > > >> > >> Thanks. >> >> Dennis >> >> >> -----Original Message----- >> From: Rob Crittenden [mailto:rcritten at redhat.com] >> Sent: Monday, August 25, 2014 6:37 PM >> To: Ott, Dennis; freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] Cert Renewal >> >> Ott, Dennis wrote: >>> I have an IPA setup, one master, one replica; originally installed >>> as v 2.x and later updated to v 3.0. For whatever reasons, the >>> certs did not automatically renew and the services would no longer >>> start. I updated the certs manually on the master using the procedure shown at: >>> >>> >>> >>> http://www.freeipa.org/page/IPA_2x_Certificate_Renewal >>> >>> >>> >>> The master is now functioning properly. >>> >>> >>> >>> >>> >>> At this point, the IPA service is still stopped on the replica. I >>> hesitate to start it for concern it could interfere with the >>> now-working master. >>> >>> >>> >>> What would be the recommended method for returning the replica to service? >> >> It depends on whether the replica. Does it also run a CA? If not then you can try restarting the certmonger service. This should cause it to fetch new certificates for the other IPA servers. ipa-getcert list will show you the status, wait until they are all MONITORING. >> >> Once that works then you can safely restart the world. Any changes on the master will be replicated out, and vice versa. >> >> rob >> > From rap at phas.ubc.ca Wed Sep 3 23:50:23 2014 From: rap at phas.ubc.ca (Ron) Date: Wed, 03 Sep 2014 16:50:23 -0700 Subject: [Freeipa-users] ipa user-find finds user but ipa user-del fails In-Reply-To: <54078712.8040902@redhat.com> References: <54073F4C.60602@phas.ubc.ca> <540742AF.20402@redhat.com> <54075346.4030505@redhat.com> <54076913.2070902@phas.ubc.ca> <54076B5E.3060501@redhat.com> <54077DB0.10606@phas.ubc.ca> <54078712.8040902@redhat.com> Message-ID: <5407A93F.4050201@phas.ubc.ca> So in my case I would need to do the "Renaming an Entry with a Multi-Valued Naming Attribute" procedure on both IPA01 and IPA02? Would another way of doing this be to remove IPA01 (and later IPA02) as a replication-master and then re-add it? I ask this because I have about 70 of these entries. I think they are there because I was using a perl script (which used the perl ldap->add function) to create new user entries and for a while the script called this (ldap->add) on IPA then IPA02 immediately after. -Ron On 09/03/2014 02:24 PM, Rich Megginson wrote: > On 09/03/2014 02:44 PM, Ron wrote: >> By the way, all three replica servers show the same: >> >> [root at ipa]# ipa user-find --all --raw --login phys210e | grep dn: >> dn: >> nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=xxxx,dc=abc,dc=ca >> >> >> [root at ipa01]# ipa user-find --all --raw --login phys210e | grep dn: >> dn: >> nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=xxxx,dc=abc,dc=ca >> >> >> [root at ipa02]# ipa user-find --all --raw --login phys210e | grep dn: >> dn: >> nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=xxxx,dc=abc,dc=ca >> > > These appear to be replication conflict entries. Not sure what > happened. See > https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html > >> >> On 09/03/2014 12:26 PM, Rob Crittenden wrote: >>> Ron wrote: >>>> And here is the result of the user-show command: >>>> [root at ipa slapd-pxxx-abc-CA]# ipa user-show --all --raw phys210e >>>> ipa: ERROR: phys210e: user not found >>> Sorry, thinko on my part. Do ipa user-find --all --raw --login phys210e >>> >>> user-show is going to have the same issue as user-delete. >>> >>> rob >>> >>>> >>>> On 09/03/2014 10:43 AM, Rob Crittenden wrote: >>>>> Martin Kosek wrote: >>>>>> Can you check /var/log/dirsrv/slapd-YOUR-REALM/access, search for >>>>>> the DEL >>>>>> operation and see what was the error code that DS gave when it >>>>>> refused to >>>>>> delete the user? >>>>> Were I to guess the issue is that this is a replication conflict >>>>> entry. >>>>> If you do: >>>>> >>>>> # ipa user-show --all --raw phys210e |grep dn: >>>>> >>>>> It will likely begin with nsuniqueid=, ... >>>>> >>>>> The reason it can be found and not deleted is we create the dn to be >>>>> removed, we don't search for it. So the user >>>>> uid=phys210e,cn=users,... >>>>> etc doesn't exist but the user nsuniqueid= ... does. >>>>> >>>>> You'll need to use ldapmodify or ldapdelete to remove the entry >>>>> though >>>>> I'd check your other masters to see what the state of the user is >>>>> there. >>>>> >>>>> rob >>>>> >>>>>> Martin >>>>>> >>>>>> On 09/03/2014 06:18 PM, Ron wrote: >>>>>>> user-find sees a user but user-del cannot remove it. What can I >>>>>>> do? >>>>>>> Thanks. >>>>>>> Regards, >>>>>>> Ron >>>>>>> >>>>>>> [root at ipa]# ipa user-find --login phys210e >>>>>>> -------------- >>>>>>> 1 user matched >>>>>>> -------------- >>>>>>> User login: phys210e >>>>>>> First name: Testing >>>>>>> Last name: Phys210 >>>>>>> Home directory: /home2/phys210e >>>>>>> Login shell: /bin/bash >>>>>>> Email address: phys210e at pxxx.abc.ca >>>>>>> UID: 15010 >>>>>>> GID: 15010 >>>>>>> Account disabled: False >>>>>>> Password: True >>>>>>> Kerberos keys available: False >>>>>>> ---------------------------- >>>>>>> Number of entries returned 1 >>>>>>> ---------------------------- >>>>>>> [root at ipa]# ipa user-del phys210e --continue >>>>>>> --------------- >>>>>>> Deleted user "" >>>>>>> --------------- >>>>>>> Failed to remove: phys210e >>>>>>> >>>>>>> >>>>>>> [root at ipa]# cat /etc/redhat-release >>>>>>> Red Hat Enterprise Linux Server release 6.5 (Santiago) >>>>>>> >>>>>>> [root at ipa]# rpm -qa|grep ipa; rpm -qa|grep 389 >>>>>>> ipa-pki-ca-theme-9.0.3-7.el6.noarch >>>>>>> ipa-admintools-3.0.0-37.el6.i686 >>>>>>> ipa-pki-common-theme-9.0.3-7.el6.noarch >>>>>>> libipa_hbac-1.9.2-129.el6_5.4.i686 >>>>>>> ipa-server-selinux-3.0.0-37.el6.i686 >>>>>>> python-iniparse-0.3.1-2.1.el6.noarch >>>>>>> libipa_hbac-python-1.9.2-129.el6_5.4.i686 >>>>>>> ipa-server-3.0.0-37.el6.i686 >>>>>>> ipa-python-3.0.0-37.el6.i686 >>>>>>> ipa-client-3.0.0-37.el6.i686 >>>>>>> 389-ds-base-libs-1.2.11.15-33.el6_5.i686 >>>>>>> 389-ds-base-1.2.11.15-33.el6_5.i686 >>>> -- >>>> Ron Parachoniak >>>> Systems Manager, Department of Physics & Astronomy >>>> University of British Columbia, Vancouver, B.C. V6T 1Z1 >>>> Phone: (604) 838-6437 >>>> >> > -- Ron Parachoniak Systems Manager, Department of Physics & Astronomy University of British Columbia, Vancouver, B.C. V6T 1Z1 Phone: (604) 838-6437 From rmeggins at redhat.com Thu Sep 4 00:16:36 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 03 Sep 2014 18:16:36 -0600 Subject: [Freeipa-users] ipa user-find finds user but ipa user-del fails In-Reply-To: <5407A93F.4050201@phas.ubc.ca> References: <54073F4C.60602@phas.ubc.ca> <540742AF.20402@redhat.com> <54075346.4030505@redhat.com> <54076913.2070902@phas.ubc.ca> <54076B5E.3060501@redhat.com> <54077DB0.10606@phas.ubc.ca> <54078712.8040902@redhat.com> <5407A93F.4050201@phas.ubc.ca> Message-ID: <5407AF64.6030800@redhat.com> On 09/03/2014 05:50 PM, Ron wrote: > So in my case I would need to do the "Renaming an Entry with a > Multi-Valued Naming Attribute" procedure on both IPA01 and IPA02? Yes. > > Would another way of doing this be to remove IPA01 (and later IPA02) as > a replication-master and then re-add it? How would that solve the problem? Wouldn't you still have nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e on IPA03? > I ask this because I have > about 70 of these entries. I think they are there because I was using a > perl script (which used the perl ldap->add function) to create new user > entries and for a while the script called this (ldap->add) on IPA then > IPA02 immediately after. That would do it - adding the same entry to two or more servers before replication can occur. > > -Ron > > On 09/03/2014 02:24 PM, Rich Megginson wrote: >> On 09/03/2014 02:44 PM, Ron wrote: >>> By the way, all three replica servers show the same: >>> >>> [root at ipa]# ipa user-find --all --raw --login phys210e | grep dn: >>> dn: >>> nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=xxxx,dc=abc,dc=ca >>> >>> >>> [root at ipa01]# ipa user-find --all --raw --login phys210e | grep dn: >>> dn: >>> nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=xxxx,dc=abc,dc=ca >>> >>> >>> [root at ipa02]# ipa user-find --all --raw --login phys210e | grep dn: >>> dn: >>> nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=xxxx,dc=abc,dc=ca >>> >> These appear to be replication conflict entries. Not sure what >> happened. See >> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html >> >>> On 09/03/2014 12:26 PM, Rob Crittenden wrote: >>>> Ron wrote: >>>>> And here is the result of the user-show command: >>>>> [root at ipa slapd-pxxx-abc-CA]# ipa user-show --all --raw phys210e >>>>> ipa: ERROR: phys210e: user not found >>>> Sorry, thinko on my part. Do ipa user-find --all --raw --login phys210e >>>> >>>> user-show is going to have the same issue as user-delete. >>>> >>>> rob >>>> >>>>> On 09/03/2014 10:43 AM, Rob Crittenden wrote: >>>>>> Martin Kosek wrote: >>>>>>> Can you check /var/log/dirsrv/slapd-YOUR-REALM/access, search for >>>>>>> the DEL >>>>>>> operation and see what was the error code that DS gave when it >>>>>>> refused to >>>>>>> delete the user? >>>>>> Were I to guess the issue is that this is a replication conflict >>>>>> entry. >>>>>> If you do: >>>>>> >>>>>> # ipa user-show --all --raw phys210e |grep dn: >>>>>> >>>>>> It will likely begin with nsuniqueid=, ... >>>>>> >>>>>> The reason it can be found and not deleted is we create the dn to be >>>>>> removed, we don't search for it. So the user >>>>>> uid=phys210e,cn=users,... >>>>>> etc doesn't exist but the user nsuniqueid= ... does. >>>>>> >>>>>> You'll need to use ldapmodify or ldapdelete to remove the entry >>>>>> though >>>>>> I'd check your other masters to see what the state of the user is >>>>>> there. >>>>>> >>>>>> rob >>>>>> >>>>>>> Martin >>>>>>> >>>>>>> On 09/03/2014 06:18 PM, Ron wrote: >>>>>>>> user-find sees a user but user-del cannot remove it. What can I >>>>>>>> do? >>>>>>>> Thanks. >>>>>>>> Regards, >>>>>>>> Ron >>>>>>>> >>>>>>>> [root at ipa]# ipa user-find --login phys210e >>>>>>>> -------------- >>>>>>>> 1 user matched >>>>>>>> -------------- >>>>>>>> User login: phys210e >>>>>>>> First name: Testing >>>>>>>> Last name: Phys210 >>>>>>>> Home directory: /home2/phys210e >>>>>>>> Login shell: /bin/bash >>>>>>>> Email address: phys210e at pxxx.abc.ca >>>>>>>> UID: 15010 >>>>>>>> GID: 15010 >>>>>>>> Account disabled: False >>>>>>>> Password: True >>>>>>>> Kerberos keys available: False >>>>>>>> ---------------------------- >>>>>>>> Number of entries returned 1 >>>>>>>> ---------------------------- >>>>>>>> [root at ipa]# ipa user-del phys210e --continue >>>>>>>> --------------- >>>>>>>> Deleted user "" >>>>>>>> --------------- >>>>>>>> Failed to remove: phys210e >>>>>>>> >>>>>>>> >>>>>>>> [root at ipa]# cat /etc/redhat-release >>>>>>>> Red Hat Enterprise Linux Server release 6.5 (Santiago) >>>>>>>> >>>>>>>> [root at ipa]# rpm -qa|grep ipa; rpm -qa|grep 389 >>>>>>>> ipa-pki-ca-theme-9.0.3-7.el6.noarch >>>>>>>> ipa-admintools-3.0.0-37.el6.i686 >>>>>>>> ipa-pki-common-theme-9.0.3-7.el6.noarch >>>>>>>> libipa_hbac-1.9.2-129.el6_5.4.i686 >>>>>>>> ipa-server-selinux-3.0.0-37.el6.i686 >>>>>>>> python-iniparse-0.3.1-2.1.el6.noarch >>>>>>>> libipa_hbac-python-1.9.2-129.el6_5.4.i686 >>>>>>>> ipa-server-3.0.0-37.el6.i686 >>>>>>>> ipa-python-3.0.0-37.el6.i686 >>>>>>>> ipa-client-3.0.0-37.el6.i686 >>>>>>>> 389-ds-base-libs-1.2.11.15-33.el6_5.i686 >>>>>>>> 389-ds-base-1.2.11.15-33.el6_5.i686 >>>>> -- >>>>> Ron Parachoniak >>>>> Systems Manager, Department of Physics & Astronomy >>>>> University of British Columbia, Vancouver, B.C. V6T 1Z1 >>>>> Phone: (604) 838-6437 >>>>> > From mkosek at redhat.com Thu Sep 4 09:45:55 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 04 Sep 2014 11:45:55 +0200 Subject: [Freeipa-users] Search Base issues In-Reply-To: References: <540585B3.9030606@redhat.com> <5406233E.3040705@redhat.com> <54062920.4010605@redhat.com> <540631F0.1020805@redhat.com> <5406BD07.6040204@redhat.com> <5406C342.6060406@redhat.com> <540712D6.9090909@redhat.com> <54072158.9080400@redhat.com> <54075442.2050604@redhat.com> Message-ID: <540834D3.2070003@redhat.com> Ok, thanks. Good to see it is working for you. I see you actually do authorization decision based on Schema Compatibility plugin :) Note that an alternate, preferred way of doing authorization in FreeIPA though is HBAC where you would configure which group of users can login to which machines. But this is only being enforced when SSSD is on the client machine, so it may not be working for all your machines. Martin On 09/03/2014 10:45 PM, Chris Whittle wrote: > Success here is my LDIF if anyone needs to do this with a MAC > >> dn: cn=Mac Users, cn=Schema Compatibility, cn=plugins, cn=config >> >> objectClass: top >> >> objectClass: extensibleObject >> >> cn: Mac Users >> >> schema-compat-search-base: cn=users,cn=accounts,dc=DOMAIN,dc=com >> >> schema-compat-search-filter: >> (&(objectClass=posixaccount)(memberOf=cn=canlogin,cn=groups,cn=accounts,dc >> DOMAIN,dc=com)) >> >> schema-compat-container-group: cn=compat,dc=DOMAIN,dc=com >> >> schema-compat-container-rdn: cn=canlogin >> >> schema-compat-entry-rdn: cn=%{cn} >> >> schema-compat-entry-attribute: objectclass=inetOrgPerson >> >> schema-compat-entry-attribute: objectclass=posixAccount >> >> schema-compat-entry-attribute: gecos=%{cn} >> >> schema-compat-entry-attribute: cn=%{cn} >> >> schema-compat-entry-attribute: uid=%{uid} >> >> schema-compat-entry-attribute: uidNumber=%{uidNumber} >> >> schema-compat-entry-attribute: gidNumber=%{gidNumber} >> >> schema-compat-entry-attribute: loginShell=%{loginShell} >> >> schema-compat-entry-attribute: homeDirectory=%{homeDirectory} >> > > > > On Wed, Sep 3, 2014 at 1:04 PM, Chris Whittle wrote: > >> Thanks Rob for the explanation! >> >> I think I have it working, I just have to test a machine and verify. >> >> >> On Wed, Sep 3, 2014 at 12:47 PM, Rob Crittenden >> wrote: >> >>> Chris Whittle wrote: >>>> That worked, but having issues get it to work with the OSX Directory >>>> Utility. >>>> I'm wondering if it's because when you go against the OU normally it's >>>> returning more info about the user versus what's being returned from the >>>> compat "view" I'm going to experiment with the attributes it's returning >>>> and see if that's it. >>>> >>>> I'm also wondering why FreeIPA doesn't support multiple OU's natively, >>>> this would be so much easier with multiple OUs (one for my non-users and >>>> one for my users) >>> >>> Because they are so very often used really, really poorly, resulting in >>> having to move entries around a lot with no real technical reason behind >>> it. Think about the number of times an IT department gets renamed, oops, >>> today they are called Global Support Services, oh no, didn't you hear, >>> now they are ... Each one requiring an entire subtree move. Where the >>> users exist in LDAP does not generally need to reflect the >>> organizational structure. >>> >>> Your case is a bit different from most, where you want to host two >>> completely separate kinds of users. >>> >>> rob >>> >>>> >>>> >>>> On Wed, Sep 3, 2014 at 9:10 AM, Martin Kosek >>> > wrote: >>>> >>>> On 09/03/2014 03:08 PM, Rob Crittenden wrote: >>>> > Martin Kosek wrote: >>>> >> On 09/03/2014 09:02 AM, Martin Kosek wrote: >>>> >>> In the meantime, you can use the workaround that Rob sent, you >>>> would just need >>>> >>> to delete it again when the fix is in, so that the permissions >>>> do not step on >>>> >>> each other. >>>> >> >>>> >> Actually, wait a minute. I think Rob's ACI example may be too >>>> wide, it may >>>> >> expose any attribute in the compat tree, including a potential >>>> userPassword. >>>> > >>>> > The ACI was on his custom cn=canlogin subtree, not all of >>> cn=compat. >>>> > >>>> >> As I see, it seems that slapi-nis plugin do not fortunately >>>> expose that, but it >>>> >> is safer to just list the attributes that one wants to display >>>> (this is also >>>> >> what we did in FreeIPA 4.0, no global wildcard allowing ACIs any >>>> more). >>>> >> >>>> >> I added a respective permission via Web UI (one part of it cannot >>>> be added via >>>> >> CLI, see https://fedorahosted.org/freeipa/ticket/4522) and >>> compat >>>> tree now >>>> >> works for me. See attached example. >>>> >> >>>> >> Resulting permission shown in CLI: >>>> >> >>>> >> # ipa permission-show "TEMPORARY - Read compat tree" >>>> >> Permission name: TEMPORARY - Read compat tree >>>> >> Granted rights: read, search, compare >>>> >> Effective attributes: cn, description, gecos, gidnumber, >>>> homedirectory, >>>> >> loginshell, memberuid, >>>> >> objectclass, uid, uidnumber >>>> >> Bind rule type: all >>>> >> Subtree: dc=mkosek-fedora20,dc=test >>>> >> ACI target DN: cn=compat,dc=mkosek-fedora20,dc=test >>>> >> >>>> >> It is much easier to manipulate than ACI added via ldapmodify. >>>> > >>>> > I see you filed a bug on the missing CLI option. That's why I did >>> the >>>> > ACI, because I couldn't demonstrate how to add this ACI on the >>> CLI. I >>>> > hadn't gotten around to doing that last night. >>>> > >>>> > rob >>>> >>>> Right. Surprisingly, the option was available in Web UI, thus the >>> Web UI >>>> screenshot I attached to the thread :) But we have the CLI option >>> fixed >>>> already, will be part of FreeIPA 4.0.2 which will be released very >>> soon. >>>> >>>> Martin >>>> >>>> >>> >>> >> > From mkosek at redhat.com Thu Sep 4 09:48:32 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 04 Sep 2014 11:48:32 +0200 Subject: [Freeipa-users] ipa user-find finds user but ipa user-del fails In-Reply-To: <54077DB0.10606@phas.ubc.ca> References: <54073F4C.60602@phas.ubc.ca> <540742AF.20402@redhat.com> <54075346.4030505@redhat.com> <54076913.2070902@phas.ubc.ca> <54076B5E.3060501@redhat.com> <54077DB0.10606@phas.ubc.ca> Message-ID: <54083570.40802@redhat.com> Ah, ok. As Rob advised, you will need to delete it via ldapdelete CLI or via any LDAP GUI application of choice. BTW, this is upstream ticket tracking better means to resolve replication conflicts: https://fedorahosted.org/freeipa/ticket/1025 Martin On 09/03/2014 10:44 PM, Ron wrote: > By the way, all three replica servers show the same: > > [root at ipa]# ipa user-find --all --raw --login phys210e | grep dn: > dn: > nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=xxxx,dc=abc,dc=ca > > [root at ipa01]# ipa user-find --all --raw --login phys210e | grep dn: > dn: > nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=xxxx,dc=abc,dc=ca > > [root at ipa02]# ipa user-find --all --raw --login phys210e | grep dn: > dn: > nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=xxxx,dc=abc,dc=ca > > On 09/03/2014 12:26 PM, Rob Crittenden wrote: >> Ron wrote: >>> And here is the result of the user-show command: >>> [root at ipa slapd-pxxx-abc-CA]# ipa user-show --all --raw phys210e >>> ipa: ERROR: phys210e: user not found >> Sorry, thinko on my part. Do ipa user-find --all --raw --login phys210e >> >> user-show is going to have the same issue as user-delete. >> >> rob >> >>> >>> >>> On 09/03/2014 10:43 AM, Rob Crittenden wrote: >>>> Martin Kosek wrote: >>>>> Can you check /var/log/dirsrv/slapd-YOUR-REALM/access, search for the DEL >>>>> operation and see what was the error code that DS gave when it refused to >>>>> delete the user? >>>> Were I to guess the issue is that this is a replication conflict entry. >>>> If you do: >>>> >>>> # ipa user-show --all --raw phys210e |grep dn: >>>> >>>> It will likely begin with nsuniqueid=, ... >>>> >>>> The reason it can be found and not deleted is we create the dn to be >>>> removed, we don't search for it. So the user uid=phys210e,cn=users,... >>>> etc doesn't exist but the user nsuniqueid= ... does. >>>> >>>> You'll need to use ldapmodify or ldapdelete to remove the entry though >>>> I'd check your other masters to see what the state of the user is there. >>>> >>>> rob >>>> >>>>> Martin >>>>> >>>>> On 09/03/2014 06:18 PM, Ron wrote: >>>>>> user-find sees a user but user-del cannot remove it. What can I do? >>>>>> Thanks. >>>>>> Regards, >>>>>> Ron >>>>>> >>>>>> [root at ipa]# ipa user-find --login phys210e >>>>>> -------------- >>>>>> 1 user matched >>>>>> -------------- >>>>>> User login: phys210e >>>>>> First name: Testing >>>>>> Last name: Phys210 >>>>>> Home directory: /home2/phys210e >>>>>> Login shell: /bin/bash >>>>>> Email address: phys210e at pxxx.abc.ca >>>>>> UID: 15010 >>>>>> GID: 15010 >>>>>> Account disabled: False >>>>>> Password: True >>>>>> Kerberos keys available: False >>>>>> ---------------------------- >>>>>> Number of entries returned 1 >>>>>> ---------------------------- >>>>>> [root at ipa]# ipa user-del phys210e --continue >>>>>> --------------- >>>>>> Deleted user "" >>>>>> --------------- >>>>>> Failed to remove: phys210e >>>>>> >>>>>> >>>>>> [root at ipa]# cat /etc/redhat-release >>>>>> Red Hat Enterprise Linux Server release 6.5 (Santiago) >>>>>> >>>>>> [root at ipa]# rpm -qa|grep ipa; rpm -qa|grep 389 >>>>>> ipa-pki-ca-theme-9.0.3-7.el6.noarch >>>>>> ipa-admintools-3.0.0-37.el6.i686 >>>>>> ipa-pki-common-theme-9.0.3-7.el6.noarch >>>>>> libipa_hbac-1.9.2-129.el6_5.4.i686 >>>>>> ipa-server-selinux-3.0.0-37.el6.i686 >>>>>> python-iniparse-0.3.1-2.1.el6.noarch >>>>>> libipa_hbac-python-1.9.2-129.el6_5.4.i686 >>>>>> ipa-server-3.0.0-37.el6.i686 >>>>>> ipa-python-3.0.0-37.el6.i686 >>>>>> ipa-client-3.0.0-37.el6.i686 >>>>>> 389-ds-base-libs-1.2.11.15-33.el6_5.i686 >>>>>> 389-ds-base-1.2.11.15-33.el6_5.i686 >>> >>> -- >>> Ron Parachoniak >>> Systems Manager, Department of Physics & Astronomy >>> University of British Columbia, Vancouver, B.C. V6T 1Z1 >>> Phone: (604) 838-6437 >>> > > From sebastian.leitz at etes.de Thu Sep 4 12:20:17 2014 From: sebastian.leitz at etes.de (=?utf-8?Q?Sebastian_Leitz?=) Date: Thu, 4 Sep 2014 14:20:17 +0200 Subject: [Freeipa-users] Filters in bind-dyndb-ldap Message-ID: Hello, I am trying to use bind-dyndb-ldap to connect my BIND to an LDAP server for zones. I have a tiny question regarding this and both the project website and the kind people on #freeipa IRC directed me to this list. I hope someone is here who can answer my question. Sorry for intruding if I'm not asking in the correct place. For technical reasons we need to be able to filter zones in LDAP according to some flags, e.g. 'enabled'. Other services usually provide a config option to include LDAP search filters in every query, like ldap_search_filter = (enabled=1) Unfortunately, I can't find anything like this in the README file of bind-dyndb-ldap. Does anybody know of a way to pass a search filter to LDAP? Thanks in advance, Sebastian -- Sebastian Leitz Mail: sebastian.leitz at etes.de ETES GmbH Fon : +49 (7 11) 48 90 83 - 14 Gablenberger Hauptstrasse 32 Fax : +49 (7 11) 48 90 83 - 50 D-70186 Stuttgart Web : http://www.etes.de/ Registergericht: Amtsgericht Stuttgart HRB 721182 Gesch?ftsf?hrender Gesellschafter: Markus Espenhain Sitz der Gesellschaft: Stuttgart USt.-Id.Nr.: DE814767446 From cwhittl at gmail.com Thu Sep 4 12:23:49 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Thu, 4 Sep 2014 07:23:49 -0500 Subject: [Freeipa-users] Filters in bind-dyndb-ldap In-Reply-To: References: Message-ID: Look at nsaccountlock if it's TRUE then they are disabled. On Thu, Sep 4, 2014 at 7:20 AM, Sebastian Leitz wrote: > Hello, > > I am trying to use bind-dyndb-ldap to connect my BIND to an LDAP server > for zones. I have a tiny question regarding this and both the project > website and the kind people on #freeipa IRC directed me to this list. I > hope someone is here who can answer my question. Sorry for intruding if I'm > not asking in the correct place. > > For technical reasons we need to be able to filter zones in LDAP according > to some flags, e.g. 'enabled'. > Other services usually provide a config option to include LDAP search > filters in every query, like > > ldap_search_filter = (enabled=1) > > Unfortunately, I can't find anything like this in the README file of > bind-dyndb-ldap. Does anybody know of a way to pass a search filter to LDAP? > > Thanks in advance, > > Sebastian > > -- > Sebastian Leitz Mail: sebastian.leitz at etes.de > ETES GmbH Fon : +49 (7 11) 48 90 83 - 14 > Gablenberger Hauptstrasse 32 Fax : +49 (7 11) 48 90 83 - 50 > D-70186 Stuttgart Web : http://www.etes.de/ > > Registergericht: Amtsgericht Stuttgart HRB 721182 > Gesch?ftsf?hrender Gesellschafter: Markus Espenhain > Sitz der Gesellschaft: Stuttgart > USt.-Id.Nr.: DE814767446 > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Thu Sep 4 12:28:37 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 04 Sep 2014 14:28:37 +0200 Subject: [Freeipa-users] Filters in bind-dyndb-ldap In-Reply-To: References: Message-ID: <54085AF5.6070808@redhat.com> Actually, FreeIPA&bind-dynd-ldap use idnszoneactive attribute (TRUE/FALSE) to define which zones are active and which are not. On 09/04/2014 02:23 PM, Chris Whittle wrote: > Look at nsaccountlock if it's TRUE then they are disabled. > > > > On Thu, Sep 4, 2014 at 7:20 AM, Sebastian Leitz > wrote: > >> Hello, >> >> I am trying to use bind-dyndb-ldap to connect my BIND to an LDAP server >> for zones. I have a tiny question regarding this and both the project >> website and the kind people on #freeipa IRC directed me to this list. I >> hope someone is here who can answer my question. Sorry for intruding if I'm >> not asking in the correct place. >> >> For technical reasons we need to be able to filter zones in LDAP according >> to some flags, e.g. 'enabled'. >> Other services usually provide a config option to include LDAP search >> filters in every query, like >> >> ldap_search_filter = (enabled=1) >> >> Unfortunately, I can't find anything like this in the README file of >> bind-dyndb-ldap. Does anybody know of a way to pass a search filter to LDAP? >> >> Thanks in advance, >> >> Sebastian >> >> -- >> Sebastian Leitz Mail: sebastian.leitz at etes.de >> ETES GmbH Fon : +49 (7 11) 48 90 83 - 14 >> Gablenberger Hauptstrasse 32 Fax : +49 (7 11) 48 90 83 - 50 >> D-70186 Stuttgart Web : http://www.etes.de/ >> >> Registergericht: Amtsgericht Stuttgart HRB 721182 >> Gesch?ftsf?hrender Gesellschafter: Markus Espenhain >> Sitz der Gesellschaft: Stuttgart >> USt.-Id.Nr.: DE814767446 >> >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go To http://freeipa.org for more info on the project > > > From pspacek at redhat.com Thu Sep 4 13:22:15 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 04 Sep 2014 15:22:15 +0200 Subject: [Freeipa-users] Filters in bind-dyndb-ldap In-Reply-To: <54085AF5.6070808@redhat.com> References: <54085AF5.6070808@redhat.com> Message-ID: <54086787.9040100@redhat.com> On 4.9.2014 14:28, Martin Kosek wrote: > Actually, FreeIPA&bind-dynd-ldap use idnszoneactive attribute (TRUE/FALSE) to > define which zones are active and which are not. Martin is right, I will add couple more details about this: idnszoneactive attribute should work in bind-dyndb-ldap < 4.0. Versions >= 4.0 do not support it yet. This defficiency is tracked in https://fedorahosted.org/bind-dyndb-ldap/ticket/127 You have couple options as a workaround: 1) Use older version of bind-dyndb-ldap :-) 2) Use LDAP transformation on server side so the server doesn't return objects from sub-tree with idnszoneactive attribute = FALSE. 3) Try some ACI magic on server side so it will not return objects from given sub-tree if idnszoneactive = FALSE. (This seems to be easiest option to me.) Have a nice day! Petr^2 Spacek > On 09/04/2014 02:23 PM, Chris Whittle wrote: >> Look at nsaccountlock if it's TRUE then they are disabled. >> >> >> >> On Thu, Sep 4, 2014 at 7:20 AM, Sebastian Leitz >> wrote: >> >>> Hello, >>> >>> I am trying to use bind-dyndb-ldap to connect my BIND to an LDAP server >>> for zones. I have a tiny question regarding this and both the project >>> website and the kind people on #freeipa IRC directed me to this list. I >>> hope someone is here who can answer my question. Sorry for intruding if I'm >>> not asking in the correct place. >>> >>> For technical reasons we need to be able to filter zones in LDAP according >>> to some flags, e.g. 'enabled'. >>> Other services usually provide a config option to include LDAP search >>> filters in every query, like >>> >>> ldap_search_filter = (enabled=1) >>> >>> Unfortunately, I can't find anything like this in the README file of >>> bind-dyndb-ldap. Does anybody know of a way to pass a search filter to LDAP? >>> >>> Thanks in advance, >>> >>> Sebastian From sebastian.leitz at etes.de Thu Sep 4 13:37:53 2014 From: sebastian.leitz at etes.de (=?utf-8?Q?Sebastian_Leitz?=) Date: Thu, 4 Sep 2014 15:37:53 +0200 Subject: [Freeipa-users] Filters in bind-dyndb-ldap Message-ID: Thanks, Martin and Petr, for your comments and the workaround. As we're internally still on an old version of bind-dyndb-ldap I can actually use the LDAP attribute to achieve what I desire. Yeah! As for the future, I opended https://bugzilla.redhat.com/show_bug.cgi?id=1138317, if anybody is interested to upvote :-) -----Urspr?ngliche Nachricht----- > Von:Petr Spacek > Gesendet: Don 4 September 2014 15:23 > An: freeipa-users at redhat.com > Betreff: Re: [Freeipa-users] Filters in bind-dyndb-ldap > > On 4.9.2014 14:28, Martin Kosek wrote: > > Actually, FreeIPA&bind-dynd-ldap use idnszoneactive attribute (TRUE/FALSE) to > > define which zones are active and which are not. > > Martin is right, I will add couple more details about this: > idnszoneactive attribute should work in bind-dyndb-ldap < 4.0. > > Versions >= 4.0 do not support it yet. This defficiency is tracked in > https://fedorahosted.org/bind-dyndb-ldap/ticket/127 > > You have couple options as a workaround: > 1) Use older version of bind-dyndb-ldap :-) > > 2) Use LDAP transformation on server side so the server doesn't return objects > from sub-tree with idnszoneactive attribute = FALSE. > > 3) Try some ACI magic on server side so it will not return objects from given > sub-tree if idnszoneactive = FALSE. (This seems to be easiest option to me.) > > Have a nice day! > > Petr^2 Spacek > > > On 09/04/2014 02:23 PM, Chris Whittle wrote: > >> Look at nsaccountlock if it's TRUE then they are disabled. > >> > >> > >> > >> On Thu, Sep 4, 2014 at 7:20 AM, Sebastian Leitz > >> wrote: > >> > >>> Hello, > >>> > >>> I am trying to use bind-dyndb-ldap to connect my BIND to an LDAP server > >>> for zones. I have a tiny question regarding this and both the project > >>> website and the kind people on #freeipa IRC directed me to this list. I > >>> hope someone is here who can answer my question. Sorry for intruding if I'm > >>> not asking in the correct place. > >>> > >>> For technical reasons we need to be able to filter zones in LDAP according > >>> to some flags, e.g. 'enabled'. > >>> Other services usually provide a config option to include LDAP search > >>> filters in every query, like > >>> > >>> ldap_search_filter = (enabled=1) > >>> > >>> Unfortunately, I can't find anything like this in the README file of > >>> bind-dyndb-ldap. Does anybody know of a way to pass a search filter to LDAP? > >>> > >>> Thanks in advance, > >>> > >>> Sebastian > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > -- Sebastian Leitz Mail: sebastian.leitz at etes.de ETES GmbH Fon : +49 (7 11) 48 90 83 - 14 Gablenberger Hauptstrasse 32 Fax : +49 (7 11) 48 90 83 - 50 D-70186 Stuttgart Web : http://www.etes.de/ Registergericht: Amtsgericht Stuttgart HRB 721182 Gesch?ftsf?hrender Gesellschafter: Markus Espenhain Sitz der Gesellschaft: Stuttgart USt.-Id.Nr.: DE814767446 From guillermo.fuentes at modernizingmedicine.com Thu Sep 4 15:11:28 2014 From: guillermo.fuentes at modernizingmedicine.com (Guillermo Fuentes) Date: Thu, 4 Sep 2014 11:11:28 -0400 Subject: [Freeipa-users] Replication stopped working Message-ID: Hello list, We?re running FreeIPA with a master and 3 replicas. The replication stopped working and currently we?re adding resources only to the master. This is the environment we have: m1: OS: CentOS release 6.5 FreeIPA: 3.0.0-37 CA: pki-ca-9.0.3 # ipa-replica-manage list -v `hostname` m2.example.com: replica last init status: None last init ended: None last update status: 49 - LDAP error: Invalid credentials last update ended: None m3.example.com: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2014-09-04 14:28:44+00:00 m4.example.com: replica last init status: None last init ended: None last update status: -2 - LDAP error: Local error last update ended: None m2: OS: CentOS release 6.5 FreeIPA: 3.0.0-37 # ipa-replica-manage list -v `hostname` m1.example.com: replica last init status: None last init ended: None last update status: -1 Incremental update has failed and requires administrator actionLDAP error: Can't contact LDAP server last update ended: 2014-09-03 22:53:21+00:00 m3: OS: CentOS release 6.5 FreeIPA: 3.0.0-37 # ipa-replica-manage list -v `hostname` m1.example.com: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2014-09-04 14:31:51+00:00 m4: OS: CentOS release 6.5 FreeIPA: 3.3.3-28 # ipa-replica-manage list -v `hostname` m1.example.com: replica last init status: None last init ended: None last update status: 49 Unable to acquire replicaLDAP error: Invalid credentials last update ended: None Note that although m3 reports ?Incremental update succeeded?, users created on m1 are not replicated to m3, and users created on m3 are not replicated back to m1. We?ve tried different things including re-initializing m2. Can somebody point me in the right direction to get replication going again? Thanks in advance! Guillermo From fredy.sanchez at modmed.com Thu Sep 4 15:21:38 2014 From: fredy.sanchez at modmed.com (Fredy Sanchez) Date: Thu, 4 Sep 2014 11:21:38 -0400 Subject: [Freeipa-users] Replication stopped working In-Reply-To: References: Message-ID: I should add that we already tried everything at https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html On Thu, Sep 4, 2014 at 11:11 AM, Guillermo Fuentes < guillermo.fuentes at modernizingmedicine.com> wrote: > Hello list, > > We?re running FreeIPA with a master and 3 replicas. The replication > stopped working and currently we?re adding resources only to the > master. This is the environment we have: > m1: > OS: CentOS release 6.5 > FreeIPA: 3.0.0-37 > CA: pki-ca-9.0.3 > > > # ipa-replica-manage list -v `hostname` > m2.example.com: replica > last init status: None > last init ended: None > last update status: 49 - LDAP error: Invalid credentials > last update ended: None > m3.example.com: replica > last init status: None > last init ended: None > last update status: 0 Replica acquired successfully: Incremental > update succeeded > last update ended: 2014-09-04 14:28:44+00:00 > m4.example.com: replica > last init status: None > last init ended: None > last update status: -2 - LDAP error: Local error > last update ended: None > > m2: > OS: CentOS release 6.5 > FreeIPA: 3.0.0-37 > > # ipa-replica-manage list -v `hostname` > m1.example.com: replica > last init status: None > last init ended: None > last update status: -1 Incremental update has failed and requires > administrator actionLDAP error: Can't contact LDAP server > last update ended: 2014-09-03 22:53:21+00:00 > > m3: > OS: CentOS release 6.5 > FreeIPA: 3.0.0-37 > > # ipa-replica-manage list -v `hostname` > m1.example.com: replica > last init status: None > last init ended: None > last update status: 0 Replica acquired successfully: Incremental > update succeeded > last update ended: 2014-09-04 14:31:51+00:00 > > m4: > OS: CentOS release 6.5 > FreeIPA: 3.3.3-28 > > # ipa-replica-manage list -v `hostname` > m1.example.com: replica > last init status: None > last init ended: None > last update status: 49 Unable to acquire replicaLDAP error: Invalid > credentials > last update ended: None > > > Note that although m3 reports ?Incremental update succeeded?, users > created on m1 are not replicated to m3, and users created on m3 are > not replicated back to m1. > > We?ve tried different things including re-initializing m2. > > Can somebody point me in the right direction to get replication going > again? > > Thanks in advance! > > Guillermo > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project -- Cheers, Fredy Sanchez IT Manager @ Modernizing Medicine 561-880-2998 x237 fredy.sanchez at modmed.com Need IT support? Visit https://mmit.zendesk.com - - -------------- next part -------------- An HTML attachment was scrubbed... URL: From rap at phas.ubc.ca Thu Sep 4 20:31:56 2014 From: rap at phas.ubc.ca (Ron) Date: Thu, 04 Sep 2014 13:31:56 -0700 Subject: [Freeipa-users] ipa user-find finds user but ipa user-del fails In-Reply-To: <54083570.40802@redhat.com> References: <54073F4C.60602@phas.ubc.ca> <540742AF.20402@redhat.com> <54075346.4030505@redhat.com> <54076913.2070902@phas.ubc.ca> <54076B5E.3060501@redhat.com> <54077DB0.10606@phas.ubc.ca> <54083570.40802@redhat.com> Message-ID: <5408CC3C.7040809@phas.ubc.ca> So I tried to delete an entry on IPA01 without success: [root at ipa01 ~]# ldapdelete -D "uid=admin,cn=users,cn=accounts,dc=xxxx,dc=abc,dc=ca" -W -x "cn=userxyz+nsuniqueid=62c9c682-32ce11e4-8c13b928-a98b9061,cn=groups,cn=accounts,dc=xxxx,dc=abc,dc=ca" Enter LDAP Password: ldap_delete: Server is unwilling to perform (53) additional info: Deleting a managed entry is not allowed. It needs to be manually unlinked first Same problem if I try to use ldapmodify: [root at ipa01 ~]# ldapmodify -D "uid=admin,cn=users,cn=accounts,dc=xxxx,dc=abc,dc=ca" -W -x Enter LDAP Password: dn: cn=userxyz+nsuniqueid=62c9c682-32ce11e4-8c13b928-a98b9061,cn=groups,cn=accounts,dc=xxxx,dc=abc,dc=ca changetype: modrdn newrdn: uid=19000 deleteoldrdn: 0 modifying rdn of entry "cn=userxyz+nsuniqueid=62c9c682-32ce11e4-8c13b928-a98b9061,cn=groups,cn=accounts,dc=xxxx,dc=abc,dc=ca" ldap_rename: Server is unwilling to perform (53) additional info: Renaming a managed entry is not allowed. It needs to be manually unlinked first. (19000 is just an unused uid) Would this be because of the private group associated with the user? How do I unlink the entry? Would I use the following? ipa group-detach userxyz Thanks again for all your help! -Ron On 09/04/2014 02:48 AM, Martin Kosek wrote: > Ah, ok. As Rob advised, you will need to delete it via ldapdelete CLI or via > any LDAP GUI application of choice. > > BTW, this is upstream ticket tracking better means to resolve replication > conflicts: > https://fedorahosted.org/freeipa/ticket/1025 > > Martin > > On 09/03/2014 10:44 PM, Ron wrote: >> By the way, all three replica servers show the same: >> >> [root at ipa]# ipa user-find --all --raw --login phys210e | grep dn: >> dn: >> nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=xxxx,dc=abc,dc=ca >> >> [root at ipa01]# ipa user-find --all --raw --login phys210e | grep dn: >> dn: >> nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=xxxx,dc=abc,dc=ca >> >> [root at ipa02]# ipa user-find --all --raw --login phys210e | grep dn: >> dn: >> nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=xxxx,dc=abc,dc=ca From fredy.sanchez at modmed.com Thu Sep 4 21:03:09 2014 From: fredy.sanchez at modmed.com (Fredy Sanchez) Date: Thu, 4 Sep 2014 17:03:09 -0400 Subject: [Freeipa-users] Replication stopped working In-Reply-To: References: Message-ID: sudo ipa-replica-conncheck --replica for all replicas comes back with ... The following UDP ports could not be verified as open: 88, 464 This can happen if they are already bound to an application and ipa-replica-conncheck cannot attach own UDP responder. Connection from master to replica is OK. ipa-replica-manage -v list $REPLICA fails w/ Failed to get data from 'REPLICA': Invalid credentials SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context The common error is: nsds5replicaLastUpdateStatus: -2 - LDAP error: Local error On Thu, Sep 4, 2014 at 11:21 AM, Fredy Sanchez wrote: > I should add that we already tried everything at > https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html > > > On Thu, Sep 4, 2014 at 11:11 AM, Guillermo Fuentes < > guillermo.fuentes at modernizingmedicine.com> wrote: > >> Hello list, >> >> We?re running FreeIPA with a master and 3 replicas. The replication >> stopped working and currently we?re adding resources only to the >> master. This is the environment we have: >> m1: >> OS: CentOS release 6.5 >> FreeIPA: 3.0.0-37 >> CA: pki-ca-9.0.3 >> >> >> # ipa-replica-manage list -v `hostname` >> m2.example.com: replica >> last init status: None >> last init ended: None >> last update status: 49 - LDAP error: Invalid credentials >> last update ended: None >> m3.example.com: replica >> last init status: None >> last init ended: None >> last update status: 0 Replica acquired successfully: Incremental >> update succeeded >> last update ended: 2014-09-04 14:28:44+00:00 >> m4.example.com: replica >> last init status: None >> last init ended: None >> last update status: -2 - LDAP error: Local error >> last update ended: None >> >> m2: >> OS: CentOS release 6.5 >> FreeIPA: 3.0.0-37 >> >> # ipa-replica-manage list -v `hostname` >> m1.example.com: replica >> last init status: None >> last init ended: None >> last update status: -1 Incremental update has failed and requires >> administrator actionLDAP error: Can't contact LDAP server >> last update ended: 2014-09-03 22:53:21+00:00 >> >> m3: >> OS: CentOS release 6.5 >> FreeIPA: 3.0.0-37 >> >> # ipa-replica-manage list -v `hostname` >> m1.example.com: replica >> last init status: None >> last init ended: None >> last update status: 0 Replica acquired successfully: Incremental >> update succeeded >> last update ended: 2014-09-04 14:31:51+00:00 >> >> m4: >> OS: CentOS release 6.5 >> FreeIPA: 3.3.3-28 >> >> # ipa-replica-manage list -v `hostname` >> m1.example.com: replica >> last init status: None >> last init ended: None >> last update status: 49 Unable to acquire replicaLDAP error: Invalid >> credentials >> last update ended: None >> >> >> Note that although m3 reports ?Incremental update succeeded?, users >> created on m1 are not replicated to m3, and users created on m3 are >> not replicated back to m1. >> >> We?ve tried different things including re-initializing m2. >> >> Can somebody point me in the right direction to get replication going >> again? >> >> Thanks in advance! >> >> Guillermo >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go To http://freeipa.org for more info on the project > > > > > -- > Cheers, > > Fredy Sanchez > IT Manager @ Modernizing Medicine > 561-880-2998 x237 > fredy.sanchez at modmed.com > > Need IT support? Visit https://mmit.zendesk.com > > - > > > - > > -- Cheers, Fredy Sanchez IT Manager @ Modernizing Medicine 561-880-2998 x237 fredy.sanchez at modmed.com Need IT support? Visit https://mmit.zendesk.com - - -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Thu Sep 4 21:17:22 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 04 Sep 2014 15:17:22 -0600 Subject: [Freeipa-users] ipa user-find finds user but ipa user-del fails In-Reply-To: <5408CC3C.7040809@phas.ubc.ca> References: <54073F4C.60602@phas.ubc.ca> <540742AF.20402@redhat.com> <54075346.4030505@redhat.com> <54076913.2070902@phas.ubc.ca> <54076B5E.3060501@redhat.com> <54077DB0.10606@phas.ubc.ca> <54083570.40802@redhat.com> <5408CC3C.7040809@phas.ubc.ca> Message-ID: <5408D6E2.8040106@redhat.com> On 09/04/2014 02:31 PM, Ron wrote: > So I tried to delete an entry on IPA01 without success: > > [root at ipa01 ~]# ldapdelete -D > "uid=admin,cn=users,cn=accounts,dc=xxxx,dc=abc,dc=ca" -W -x > "cn=userxyz+nsuniqueid=62c9c682-32ce11e4-8c13b928-a98b9061,cn=groups,cn=accounts,dc=xxxx,dc=abc,dc=ca" > Enter LDAP Password: > ldap_delete: Server is unwilling to perform (53) > additional info: Deleting a managed entry is not allowed. It needs > to be manually unlinked first > > Same problem if I try to use ldapmodify: > > [root at ipa01 ~]# ldapmodify -D > "uid=admin,cn=users,cn=accounts,dc=xxxx,dc=abc,dc=ca" -W -x > Enter LDAP Password: > dn: > cn=userxyz+nsuniqueid=62c9c682-32ce11e4-8c13b928-a98b9061,cn=groups,cn=accounts,dc=xxxx,dc=abc,dc=ca > changetype: modrdn > newrdn: uid=19000 > deleteoldrdn: 0 > > modifying rdn of entry > "cn=userxyz+nsuniqueid=62c9c682-32ce11e4-8c13b928-a98b9061,cn=groups,cn=accounts,dc=xxxx,dc=abc,dc=ca" > ldap_rename: Server is unwilling to perform (53) > additional info: Renaming a managed entry is not allowed. It needs > to be manually unlinked first. > > (19000 is just an unused uid) > > Would this be because of the private group associated with the user? > > How do I unlink the entry? Would I use the following? > ipa group-detach userxyz Yes, see https://fedorahosted.org/freeipa/ticket/75 > > Thanks again for all your help! > -Ron > > On 09/04/2014 02:48 AM, Martin Kosek wrote: >> Ah, ok. As Rob advised, you will need to delete it via ldapdelete CLI or via >> any LDAP GUI application of choice. >> >> BTW, this is upstream ticket tracking better means to resolve replication >> conflicts: >> https://fedorahosted.org/freeipa/ticket/1025 >> >> Martin >> >> On 09/03/2014 10:44 PM, Ron wrote: >>> By the way, all three replica servers show the same: >>> >>> [root at ipa]# ipa user-find --all --raw --login phys210e | grep dn: >>> dn: >>> nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=xxxx,dc=abc,dc=ca >>> >>> [root at ipa01]# ipa user-find --all --raw --login phys210e | grep dn: >>> dn: >>> nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=xxxx,dc=abc,dc=ca >>> >>> [root at ipa02]# ipa user-find --all --raw --login phys210e | grep dn: >>> dn: >>> nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=xxxx,dc=abc,dc=ca From andrewmkrause at gmail.com Thu Sep 4 21:24:44 2014 From: andrewmkrause at gmail.com (Andrew Krause) Date: Thu, 4 Sep 2014 16:24:44 -0500 Subject: [Freeipa-users] Using 389-console with FreeIPA 3 Message-ID: I realize this question has been brought forth previously, but I am unable to find a clear answer. I have a 389-ds environment that is serving as an authentication back end for a python application. The plan was to use this as a kind of SSO for other future applications and we have MANY users/groups/OUs and different policies involved already. Since it's not really feasible to re-create everything, and it will not integrate directly with FreeIPA I would like to be able to import my subtree to the 389-ds instance within my new FreeIPA install and manage that subtree separately from all my hosts and POSIX users. The short question, how can I manage to get the admin console working with the 389-ds that is included in FreeIPA? I'd really like to use FreeIPA for all my host based authentication, but it becomes a non-option if we have to run multiple directory clusters. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Fri Sep 5 06:24:35 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 05 Sep 2014 08:24:35 +0200 Subject: [Freeipa-users] Replication stopped working In-Reply-To: References: Message-ID: <54095723.3050109@redhat.com> On 09/04/2014 05:11 PM, Guillermo Fuentes wrote: > Hello list, > > We?re running FreeIPA with a master and 3 replicas. The replication > stopped working and currently we?re adding resources only to the > master. This is the environment we have: > m1: > OS: CentOS release 6.5 > FreeIPA: 3.0.0-37 > CA: pki-ca-9.0.3 > > > # ipa-replica-manage list -v `hostname` > m2.example.com: replica > last init status: None > last init ended: None > last update status: 49 - LDAP error: Invalid credentials > last update ended: None > m3.example.com: replica > last init status: None > last init ended: None > last update status: 0 Replica acquired successfully: Incremental > update succeeded > last update ended: 2014-09-04 14:28:44+00:00 > m4.example.com: replica > last init status: None > last init ended: None > last update status: -2 - LDAP error: Local error > last update ended: None > > m2: > OS: CentOS release 6.5 > FreeIPA: 3.0.0-37 > > # ipa-replica-manage list -v `hostname` > m1.example.com: replica > last init status: None > last init ended: None > last update status: -1 Incremental update has failed and requires > administrator actionLDAP error: Can't contact LDAP server > last update ended: 2014-09-03 22:53:21+00:00 > > m3: > OS: CentOS release 6.5 > FreeIPA: 3.0.0-37 > > # ipa-replica-manage list -v `hostname` > m1.example.com: replica > last init status: None > last init ended: None > last update status: 0 Replica acquired successfully: Incremental > update succeeded > last update ended: 2014-09-04 14:31:51+00:00 > > m4: > OS: CentOS release 6.5 > FreeIPA: 3.3.3-28 > > # ipa-replica-manage list -v `hostname` > m1.example.com: replica > last init status: None > last init ended: None > last update status: 49 Unable to acquire replicaLDAP error: Invalid > credentials > last update ended: None > > > Note that although m3 reports ?Incremental update succeeded?, users > created on m1 are not replicated to m3, and users created on m3 are > not replicated back to m1. > > We?ve tried different things including re-initializing m2. > > Can somebody point me in the right direction to get replication going again? > > Thanks in advance! > > Guillermo Hello, I think we would need more troubleshooting information that are available in /var/log/dirsrv/slapd-EXAMPLE-COM/errors, especially on m2, m3, m4. Few pointers what I would try myself: 1) Check that all masters have time synced (difference in matter of seconds is OK) 2) Check that DNS is all right - all replicas can resolve master's forward and reverse address. Master can resolve all replicas forward and reverse address. This is common source of replication/Kerberos errors (http://www.freeipa.org/page/Troubleshooting#Kerberos_does_not_work) The error "Can't contact LDAP server" may point to DNS issues. 3) Check that you can do plain ldapsearch from replica to master. Ideally even authenticated with keytab from /etc/dirsrv/ds.keytab HTH, Martin From mkosek at redhat.com Fri Sep 5 06:44:21 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 05 Sep 2014 08:44:21 +0200 Subject: [Freeipa-users] ipa user-find finds user but ipa user-del fails In-Reply-To: <5408CC3C.7040809@phas.ubc.ca> References: <54073F4C.60602@phas.ubc.ca> <540742AF.20402@redhat.com> <54075346.4030505@redhat.com> <54076913.2070902@phas.ubc.ca> <54076B5E.3060501@redhat.com> <54077DB0.10606@phas.ubc.ca> <54083570.40802@redhat.com> <5408CC3C.7040809@phas.ubc.ca> Message-ID: <54095BC5.6080006@redhat.com> On 09/04/2014 10:31 PM, Ron wrote: > So I tried to delete an entry on IPA01 without success: > > [root at ipa01 ~]# ldapdelete -D > "uid=admin,cn=users,cn=accounts,dc=xxxx,dc=abc,dc=ca" -W -x > "cn=userxyz+nsuniqueid=62c9c682-32ce11e4-8c13b928-a98b9061,cn=groups,cn=accounts,dc=xxxx,dc=abc,dc=ca" > Enter LDAP Password: > ldap_delete: Server is unwilling to perform (53) > additional info: Deleting a managed entry is not allowed. It needs > to be manually unlinked first > > Same problem if I try to use ldapmodify: > > [root at ipa01 ~]# ldapmodify -D > "uid=admin,cn=users,cn=accounts,dc=xxxx,dc=abc,dc=ca" -W -x > Enter LDAP Password: > dn: > cn=userxyz+nsuniqueid=62c9c682-32ce11e4-8c13b928-a98b9061,cn=groups,cn=accounts,dc=xxxx,dc=abc,dc=ca > changetype: modrdn > newrdn: uid=19000 > deleteoldrdn: 0 > > modifying rdn of entry > "cn=userxyz+nsuniqueid=62c9c682-32ce11e4-8c13b928-a98b9061,cn=groups,cn=accounts,dc=xxxx,dc=abc,dc=ca" > ldap_rename: Server is unwilling to perform (53) > additional info: Renaming a managed entry is not allowed. It needs > to be manually unlinked first. > > (19000 is just an unused uid) > > Would this be because of the private group associated with the user? Exactly. > How do I unlink the entry? Would I use the following? > ipa group-detach userxyz You would normally use it, but I am not sure it would work given that group DN is changed with the nsuniqueid RDN. However, you can manually detach the group with ldapmodify: $ kinit admin $ ipa group-show fbar --all --raw dn: cn=fbar,cn=groups,cn=accounts,dc=mkosek-fedora20,dc=test cn: fbar description: User private group for fbar gidnumber: 82600004 ipaUniqueID: 2fbdbdd2-34c7-11e4-a98a-001a4a2221bf mepManagedBy: uid=fbar,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test objectClass: posixgroup objectClass: ipaobject objectClass: mepManagedEntry objectClass: top $ ldapmodify -Y GSSAPI -h `hostname` SASL/GSSAPI authentication started SASL username: admin at MKOSEK-FEDORA20.TEST SASL SSF: 56 SASL data security layer installed. dn: cn=fbar,cn=groups,cn=accounts,dc=mkosek-fedora20,dc=test changetype: modify delete: objectClass objectClass: mepManagedEntry - delete: mepManagedBy mepManagedBy: uid=fbar,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test modifying entry "cn=fbar,cn=groups,cn=accounts,dc=mkosek-fedora20,dc=test" Now the ldapdelete on group should work. > Thanks again for all your help! > -Ron > > On 09/04/2014 02:48 AM, Martin Kosek wrote: >> Ah, ok. As Rob advised, you will need to delete it via ldapdelete CLI or via >> any LDAP GUI application of choice. >> >> BTW, this is upstream ticket tracking better means to resolve replication >> conflicts: >> https://fedorahosted.org/freeipa/ticket/1025 >> >> Martin >> >> On 09/03/2014 10:44 PM, Ron wrote: >>> By the way, all three replica servers show the same: >>> >>> [root at ipa]# ipa user-find --all --raw --login phys210e | grep dn: >>> dn: >>> nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=xxxx,dc=abc,dc=ca >>> >>> [root at ipa01]# ipa user-find --all --raw --login phys210e | grep dn: >>> dn: >>> nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=xxxx,dc=abc,dc=ca >>> >>> [root at ipa02]# ipa user-find --all --raw --login phys210e | grep dn: >>> dn: >>> nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=xxxx,dc=abc,dc=ca > From dpal at redhat.com Fri Sep 5 09:22:56 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 05 Sep 2014 11:22:56 +0200 Subject: [Freeipa-users] Using 389-console with FreeIPA 3 In-Reply-To: References: Message-ID: <540980F0.6040008@redhat.com> On 09/04/2014 11:24 PM, Andrew Krause wrote: > I realize this question has been brought forth previously, but I am > unable to find a clear answer. I have a 389-ds environment that is > serving as an authentication back end for a python application. The > plan was to use this as a kind of SSO for other future applications > and we have MANY users/groups/OUs and different policies involved > already. Since it's not really feasible to re-create everything, and > it will not integrate directly with FreeIPA I would like to be able to > import my subtree to the 389-ds instance within my new FreeIPA install > and manage that subtree separately from all my hosts and POSIX users. > > The short question, how can I manage to get the admin console working > with the 389-ds that is included in FreeIPA? > > I'd really like to use FreeIPA for all my host based authentication, > but it becomes a non-option if we have to run multiple directory > clusters. > > The best way is to use ipa migrate-ds command to load the users from the external LDAP server. You can connect a console to IPA DS instance but we do not recommend doing modifications via it because IPA creates all sorts of object classes on the entries on top of usual posix account. You can use the console to validate on the low level that all data has been properly migrated. But again ipa has ipa user-find and user-show commands that allow you to validation too so console might actually not be needed. Please refer to ipa help and online downstream manuals on how to use migrate-ds command. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sramling at redhat.com Fri Sep 5 09:32:30 2014 From: sramling at redhat.com (Sankar Ramlingam) Date: Fri, 05 Sep 2014 15:02:30 +0530 Subject: [Freeipa-users] Using 389-console with FreeIPA 3 In-Reply-To: References: Message-ID: <5409832E.5080805@redhat.com> On 09/05/2014 02:54 AM, Andrew Krause wrote: > I realize this question has been brought forth previously, but I am > unable to find a clear answer. I have a 389-ds environment that is > serving as an authentication back end for a python application. The > plan was to use this as a kind of SSO for other future applications > and we have MANY users/groups/OUs and different policies involved > already. Since it's not really feasible to re-create everything, and > it will not integrate directly with FreeIPA I would like to be able to > import my subtree to the 389-ds instance within my new FreeIPA install > and manage that subtree separately from all my hosts and POSIX users. > > The short question, how can I manage to get the admin console working > with the 389-ds that is included in FreeIPA? Hi Andrew, I assume you are running FreeIPA server on Fedora19/20 or above. If that assumption is correct, then you can do "yum install 389-ds 389-admin-console idm-console-framework". All versions of fedora has these packages by default. Thanks, -Sankar R > > I'd really like to use FreeIPA for all my host based authentication, > but it becomes a non-option if we have to run multiple directory > clusters. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Fri Sep 5 13:28:14 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 05 Sep 2014 07:28:14 -0600 Subject: [Freeipa-users] Using 389-console with FreeIPA 3 In-Reply-To: <5409832E.5080805@redhat.com> References: <5409832E.5080805@redhat.com> Message-ID: <5409BA6E.2090006@redhat.com> On 09/05/2014 03:32 AM, Sankar Ramlingam wrote: > On 09/05/2014 02:54 AM, Andrew Krause wrote: >> I realize this question has been brought forth previously, but I am >> unable to find a clear answer. I have a 389-ds environment that is >> serving as an authentication back end for a python application. The >> plan was to use this as a kind of SSO for other future applications >> and we have MANY users/groups/OUs and different policies involved >> already. Since it's not really feasible to re-create everything, and >> it will not integrate directly with FreeIPA I would like to be able >> to import my subtree to the 389-ds instance within my new FreeIPA >> install and manage that subtree separately from all my hosts and >> POSIX users. >> >> The short question, how can I manage to get the admin console working >> with the 389-ds that is included in FreeIPA? > Hi Andrew, > I assume you are running FreeIPA server on Fedora19/20 or above. > If that assumption is correct, then you can do "yum install 389-ds > 389-admin-console idm-console-framework". All versions of fedora has > these packages by default. Actually, just "yum install 389-console" installs the console. However, that is not sufficient. You will need a "configuration directory server", which has been configured with the o=NetscapeRoot tree, among other things. You will need to install the 389-admin package on the machines that have 389-ds-base installed. You will need to run the register-ds-admin.pl script to create your configuration ds and to register directory servers with the config ds. And, since we do not test this at all, there is no guarantee that it will not break your IPA deployment, so be sure to backup/snapshot/etc. before going down this road. > > Thanks, > -Sankar R >> >> I'd really like to use FreeIPA for all my host based authentication, >> but it becomes a non-option if we have to run multiple directory >> clusters. >> >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Fri Sep 5 13:28:40 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 05 Sep 2014 07:28:40 -0600 Subject: [Freeipa-users] ipa user-find finds user but ipa user-del fails In-Reply-To: <54095BC5.6080006@redhat.com> References: <54073F4C.60602@phas.ubc.ca> <540742AF.20402@redhat.com> <54075346.4030505@redhat.com> <54076913.2070902@phas.ubc.ca> <54076B5E.3060501@redhat.com> <54077DB0.10606@phas.ubc.ca> <54083570.40802@redhat.com> <5408CC3C.7040809@phas.ubc.ca> <54095BC5.6080006@redhat.com> Message-ID: <5409BA88.4030400@redhat.com> On 09/05/2014 12:44 AM, Martin Kosek wrote: > On 09/04/2014 10:31 PM, Ron wrote: >> So I tried to delete an entry on IPA01 without success: >> >> [root at ipa01 ~]# ldapdelete -D >> "uid=admin,cn=users,cn=accounts,dc=xxxx,dc=abc,dc=ca" -W -x >> "cn=userxyz+nsuniqueid=62c9c682-32ce11e4-8c13b928-a98b9061,cn=groups,cn=accounts,dc=xxxx,dc=abc,dc=ca" >> Enter LDAP Password: >> ldap_delete: Server is unwilling to perform (53) >> additional info: Deleting a managed entry is not allowed. It needs >> to be manually unlinked first >> >> Same problem if I try to use ldapmodify: >> >> [root at ipa01 ~]# ldapmodify -D >> "uid=admin,cn=users,cn=accounts,dc=xxxx,dc=abc,dc=ca" -W -x >> Enter LDAP Password: >> dn: >> cn=userxyz+nsuniqueid=62c9c682-32ce11e4-8c13b928-a98b9061,cn=groups,cn=accounts,dc=xxxx,dc=abc,dc=ca >> changetype: modrdn >> newrdn: uid=19000 >> deleteoldrdn: 0 >> >> modifying rdn of entry >> "cn=userxyz+nsuniqueid=62c9c682-32ce11e4-8c13b928-a98b9061,cn=groups,cn=accounts,dc=xxxx,dc=abc,dc=ca" >> ldap_rename: Server is unwilling to perform (53) >> additional info: Renaming a managed entry is not allowed. It needs >> to be manually unlinked first. >> >> (19000 is just an unused uid) >> >> Would this be because of the private group associated with the user? > Exactly. > >> How do I unlink the entry? Would I use the following? >> ipa group-detach userxyz > You would normally use it, but I am not sure it would work given that group DN > is changed with the nsuniqueid RDN. > > However, you can manually detach the group with ldapmodify: > > $ kinit admin > $ ipa group-show fbar --all --raw > dn: cn=fbar,cn=groups,cn=accounts,dc=mkosek-fedora20,dc=test > cn: fbar > description: User private group for fbar > gidnumber: 82600004 > ipaUniqueID: 2fbdbdd2-34c7-11e4-a98a-001a4a2221bf > mepManagedBy: uid=fbar,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test > objectClass: posixgroup > objectClass: ipaobject > objectClass: mepManagedEntry > objectClass: top > > $ ldapmodify -Y GSSAPI -h `hostname` > SASL/GSSAPI authentication started > SASL username: admin at MKOSEK-FEDORA20.TEST > SASL SSF: 56 > SASL data security layer installed. > dn: cn=fbar,cn=groups,cn=accounts,dc=mkosek-fedora20,dc=test > changetype: modify > delete: objectClass > objectClass: mepManagedEntry > - > delete: mepManagedBy > mepManagedBy: uid=fbar,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test > > modifying entry "cn=fbar,cn=groups,cn=accounts,dc=mkosek-fedora20,dc=test" > > > Now the ldapdelete on group should work. Is this procedure documented somewhere? > >> Thanks again for all your help! >> -Ron >> >> On 09/04/2014 02:48 AM, Martin Kosek wrote: >>> Ah, ok. As Rob advised, you will need to delete it via ldapdelete CLI or via >>> any LDAP GUI application of choice. >>> >>> BTW, this is upstream ticket tracking better means to resolve replication >>> conflicts: >>> https://fedorahosted.org/freeipa/ticket/1025 >>> >>> Martin >>> >>> On 09/03/2014 10:44 PM, Ron wrote: >>>> By the way, all three replica servers show the same: >>>> >>>> [root at ipa]# ipa user-find --all --raw --login phys210e | grep dn: >>>> dn: >>>> nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=xxxx,dc=abc,dc=ca >>>> >>>> [root at ipa01]# ipa user-find --all --raw --login phys210e | grep dn: >>>> dn: >>>> nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=xxxx,dc=abc,dc=ca >>>> >>>> [root at ipa02]# ipa user-find --all --raw --login phys210e | grep dn: >>>> dn: >>>> nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=xxxx,dc=abc,dc=ca From bret.wortman at damascusgrp.com Fri Sep 5 16:14:42 2014 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Fri, 05 Sep 2014 12:14:42 -0400 Subject: [Freeipa-users] DNS not responding properly.... Message-ID: <5409E172.3050003@damascusgrp.com> I've got an odd situation with one of our networks. Our systems are properly registered in DNS within IPA, and the web interface and IPA queries work to resolve the hosts, but named isn't playing along with us. [root at ipa1 data]# ipa dnsrecord-find foo.net --name=asterisk Record name: asterisk A record: 192.168.252.155 ---------------------------- Number of entries returned 1 ---------------------------- [root at ipa1 data]# host asterisk.foo.net Host asterisk.foo.net not found: 3(NXDOMAIN) [root at ipa1 data]# cat /etc/resolv.conf search foo.net nameserver 192.168.252.61 <--------- This is ipa1 nameserver 192.168.252.62 nameserver 192.168.252.63 [root at ipa1 data]# ifconfig ens192: flags=4163 mtu 1500 inet 192.168.252.61 netmask 255.255.255.0 broadcast 192.168.252.255 inet6 fe80::250:56ff:fe04:401 prefixlen 64 scopeid 0x20 ether 00:50:56:04:04:01 txqueuelen 1000 (Ethernet) RX packets 2189 bytes 332143 (324.3 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 1523 bytes 428925 (418.8 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73 mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10 loop txqueuelen 0 (Local Loopback) RX packets 1037 bytes 718872 (702.0 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 1037 bytes 718872 (702.0 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 [root at ipa1 data]# When I dig into the named.run file, I see the trace below (I ran an "rndc reload" after seeing the request to do so at the end of an earlier section of the file; it obviously didn't help much). I'm not sure where else to look. /etc/named.conf and /var/named/named.ca both are in line with what we have on another similar system where everything is working just fine. Any thoughts? 05-Sep-2014 12:04:47.111 received control channel command 'reload' 05-Sep-2014 12:04:47.111 zone 252.168.192.in-addr.arpa/IN: shutting down 05-Sep-2014 12:04:47.112 loading configuration from '/etc/named.conf' 05-Sep-2014 12:04:47.112 using default UDP/IPv4 port range: [1024, 65535] 05-Sep-2014 12:04:47.112 using default UDP/IPv6 port range: [1024, 65535] 05-Sep-2014 12:04:47.113 sizing zone task pool based on 6 zones 05-Sep-2014 12:04:47.116 option 'serial_autoincrement' is not supported, ignoring 05-Sep-2014 12:04:47.194 automatic empty zone: 10.IN-ADDR.ARPA 05-Sep-2014 12:04:47.194 automatic empty zone: 16.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.194 automatic empty zone: 17.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.194 automatic empty zone: 18.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.194 automatic empty zone: 19.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.194 automatic empty zone: 20.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.194 automatic empty zone: 21.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.194 automatic empty zone: 22.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.194 automatic empty zone: 23.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.194 automatic empty zone: 24.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.194 automatic empty zone: 25.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.195 automatic empty zone: 26.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.196 automatic empty zone: 27.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.196 automatic empty zone: 28.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.196 automatic empty zone: 29.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.196 automatic empty zone: 30.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.196 automatic empty zone: 31.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.196 automatic empty zone: 168.192.IN-ADDR.ARPA 05-Sep-2014 12:04:47.196 automatic empty zone: 64.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.196 automatic empty zone: 65.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.196 automatic empty zone: 66.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 67.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 68.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 69.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 70.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 71.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 72.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 73.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 74.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 75.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 76.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 77.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 78.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 79.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.199 automatic empty zone: 80.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.199 automatic empty zone: 81.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.199 automatic empty zone: 82.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.199 automatic empty zone: 83.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.199 automatic empty zone: 84.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.200 automatic empty zone: 85.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.200 automatic empty zone: 86.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.200 automatic empty zone: 87.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.200 automatic empty zone: 88.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.200 automatic empty zone: 89.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.200 automatic empty zone: 90.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.201 automatic empty zone: 91.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.201 automatic empty zone: 92.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.201 automatic empty zone: 93.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.201 automatic empty zone: 94.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.201 automatic empty zone: 95.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.201 automatic empty zone: 96.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.202 automatic empty zone: 97.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.202 automatic empty zone: 98.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.202 automatic empty zone: 99.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.202 automatic empty zone: 100.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.202 automatic empty zone: 101.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.202 automatic empty zone: 102.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.203 automatic empty zone: 103.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.203 automatic empty zone: 104.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.203 automatic empty zone: 105.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.203 automatic empty zone: 106.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.203 automatic empty zone: 107.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.203 automatic empty zone: 108.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.204 automatic empty zone: 109.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.204 automatic empty zone: 110.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.204 automatic empty zone: 111.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.204 automatic empty zone: 112.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.204 automatic empty zone: 113.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.204 automatic empty zone: 114.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.205 automatic empty zone: 115.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.205 automatic empty zone: 116.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.205 automatic empty zone: 117.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.205 automatic empty zone: 118.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.205 automatic empty zone: 119.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.206 automatic empty zone: 120.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.206 automatic empty zone: 121.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.206 automatic empty zone: 122.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.206 automatic empty zone: 123.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.206 automatic empty zone: 124.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.207 automatic empty zone: 125.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.207 automatic empty zone: 126.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.207 automatic empty zone: 127.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.207 automatic empty zone: 127.IN-ADDR.ARPA 05-Sep-2014 12:04:47.207 automatic empty zone: 254.169.IN-ADDR.ARPA 05-Sep-2014 12:04:47.208 automatic empty zone: 2.0.192.IN-ADDR.ARPA 05-Sep-2014 12:04:47.208 automatic empty zone: 100.51.198.IN-ADDR.ARPA 05-Sep-2014 12:04:47.208 automatic empty zone: 113.0.203.IN-ADDR.ARPA 05-Sep-2014 12:04:47.208 automatic empty zone: 255.255.255.255.IN-ADDR.ARPA 05-Sep-2014 12:04:47.208 automatic empty zone: 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA 05-Sep-2014 12:04:47.209 automatic empty zone: D.F.IP6.ARPA 05-Sep-2014 12:04:47.209 automatic empty zone: 8.E.F.IP6.ARPA 05-Sep-2014 12:04:47.209 automatic empty zone: 9.E.F.IP6.ARPA 05-Sep-2014 12:04:47.209 automatic empty zone: A.E.F.IP6.ARPA 05-Sep-2014 12:04:47.209 automatic empty zone: B.E.F.IP6.ARPA 05-Sep-2014 12:04:47.210 automatic empty zone: 8.B.D.0.1.0.0.2.IP6.ARPA 05-Sep-2014 12:04:47.213 reloading configuration succeeded 05-Sep-2014 12:04:47.213 reloading zones succeeded 05-Sep-2014 12:04:47.225 all zones loaded 05-Sep-2014 12:04:47.226 running 05-Sep-2014 12:04:47.226 update_record (syncrepl) failed, dn 'idnsname=ipa1,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type 0x1. Records can be outdated, run `rndc reload`: not found 05-Sep-2014 12:04:47.226 update_record (syncrepl) failed, dn 'idnsname=_kerberos,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type 0x1. Records can be outdated, run `rndc reload`: not found 05-Sep-2014 12:04:47.317 update_record (syncrepl) failed, dn 'idnsname=_ldap._tcp,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type 0x1. Records can be outdated, run `rndc reload`: not found 05-Sep-2014 12:04:47.317 update_record (syncrepl) failed, dn 'idnsname=_kerberos._tcp,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type 0x1. Records can be outdated, run `rndc reload`: not found 05-Sep-2014 12:04:47.318 update_record (syncrepl) failed, dn 'idnsname=_kerberos._udp,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type 0x1. Records can be outdated, run `rndc reload`: not found 05-Sep-2014 12:04:47.318 update_record (syncrepl) failed, dn 'idnsname=_kerberos-master._tcp,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type 0x1. Records can be outdated, run `rndc reload`: not found 05-Sep-2014 12:04:47.318 update_record (syncrepl) failed, dn 'idnsname=_kerberos-master._udp,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type 0x1. Records can be outdated, run `rndc reload`: not found 05-Sep-2014 12:04:47.318 update_record (syncrepl) failed, dn 'idnsname=_kpasswd._tcp,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type 0x1. Records can be outdated, run `rndc reload`: not found 05-Sep-2014 12:04:47.318 update_record (syncrepl) failed, dn 'idnsname=_kpasswd._udp,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type 0x1. Records can be outdated, run `rndc reload`: not found 05-Sep-2014 12:04:47.319 update_record (syncrepl) failed, dn 'idnsname=_ntp._udp,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type 0x1. Records can be outdated, run `rndc reload`: not found 05-Sep-2014 12:04:47.319 update_record (syncrepl) failed, dn 'idnsname=ipa-ca,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type 0x1. Records can be outdated, run `rndc reload`: not found 05-Sep-2014 12:04:47.319 update_record (syncrepl) failed, dn 'idnsname=ipa2,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type 0x1. Records can be outdated, run `rndc reload`: not found 05-Sep-2014 12:04:47.319 update_record (syncrepl) failed, dn 'idnsname=mcnetmon,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type 0x1. Records can be outdated, run `rndc reload`: not found 05-Sep-2014 12:04:47.320 update_record (syncrepl) failed, dn 'idnsname=asterisk,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type 0x1. Records can be outdated, run `rndc reload`: not found 05-Sep-2014 12:04:47.320 zone 252.168.192.in-addr.arpa/IN: loaded serial 1409933087 05-Sep-2014 12:04:47.320 1 zones from LDAP instance 'ipa' loaded (1 zones defined) -- *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 51f7de33e4b08d2bdb8b4860 Type: image/png Size: 28526 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3766 bytes Desc: S/MIME Cryptographic Signature URL: From guillermo.fuentes at modernizingmedicine.com Fri Sep 5 16:43:10 2014 From: guillermo.fuentes at modernizingmedicine.com (Guillermo Fuentes) Date: Fri, 5 Sep 2014 12:43:10 -0400 Subject: [Freeipa-users] Replication stopped working In-Reply-To: <54095723.3050109@redhat.com> References: <54095723.3050109@redhat.com> Message-ID: Hi Martin, Attached are m2.log, m3.log and m4.log files. 1) All masters are time synced with same NTP server pool. 2) DNS is fine. Forward and reverse lookup. 3) ldapsearch: m1 to m2 and m3 work: kinit -k -t /etc/dirsrv/ds.keytab ldap/`hostname` # getting ticket on m1 ldapsearch -Y GSSAPI -H ldaps://m2.example.com -b "dc=example,dc=com" uid=testuser ldapsearch -Y GSSAPI -H ldaps://m3.example.com -b "dc=example,dc=com" uid=testuser m1 to m4 fails: # ldapsearch -Y GSSAPI -H ldaps://m4.example.com -b "dc=example,dc=com" uid=testuser SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (KDC returned error string: FINDING_SERVER_KEY) m2 to m1, and m3 to m1 work fine: kinit -k -t /etc/dirsrv/ds.keytab ldap/`hostname` ldapsearch -Y GSSAPI -H ldaps://m1.example.com -b "dc=example,dc=com" uid=testuser m4 to m1 fails: # ldapsearch -Y GSSAPI -H ldaps://m1.example.com -b "dc=example,dc=com" uid=testuser SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-14): authorization failure: security flags do not match required m2 and m3 are at the same state now where connections between them and m1 are fine but the updates won't happen logging the following on m1 (/var/log/dirsrv/slapd-EXAMPLE-COM/errors) for both: [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - agmt="cn=meTom3.example.com" (m3:389): replay_update: Sending modify operation (dn="uid=testuser,cn=users,cn=accounts,dc=example,dc=com" csn=53d66ecb000000040000) [05/Sep/2014:12:30:49 -0400] - repl5_inc_result_threadmain: read result for message_id 0 [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - agmt="cn=meTom3.example.com" (m3:389): replay_update: modifys operation (dn="uid=testuser,cn=users,cn=accounts,dc=example,dc=com" csn=53d66ecb000000040000) not sent - empty [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - agmt="cn=meTom3.example.com" (m3:389): replay_update: Consumer successfully sent operation with csn 53d66ecb000000040000 [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - agmt="cn=meTom3.example.com" (m3:389): Skipping update operation with no message_id (uniqueid 04b0b435-5ef311e3-9c91ec9f-6cd72e64, CSN 53d66ecb000000040000): [05/Sep/2014:12:30:49 -0400] agmt="cn=meTom3.example.com" (m3:389) - load=1 rec=38 csn=53d66ecb000200040000 [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - agmt="cn=meTom3.example.com" (m3:389): replay_update: Sending modify operation (dn="uid=testuser,cn=users,cn=accounts,dc=example,dc=com" csn=53d66ecb000200040000) [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - agmt="cn=meTom3.example.com" (m3:389): replay_update: modifys operation (dn="uid=testuser,cn=users,cn=accounts,dc=example,dc=com" csn=53d66ecb000200040000) not sent - empty [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - agmt="cn=meTom3.example.com" (m3:389): replay_update: Consumer successfully sent operation with csn 53d66ecb000200040000 [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - agmt="cn=meTom3.example.com" (m3:389): Skipping update operation with no message_id (uniqueid 04b0b435-5ef311e3-9c91ec9f-6cd72e64, CSN 53d66ecb000200040000): [05/Sep/2014:12:30:49 -0400] agmt="cn=meTom3.example.com" (m3:389) - load=1 rec=39 csn=53d66ecc000100040000 [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - agmt="cn=meTom3.example.com" (m3:389): replay_update: Sending modify operation (dn="uid=testuser,cn=users,cn=accounts,dc=example,dc=com" csn=53d66ecc000100040000) [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - agmt="cn=meTom3.example.com" (m3:389): replay_update: modifys operation (dn="uid=testuser,cn=users,cn=accounts,dc=example,dc=com" csn=53d66ecc000100040000) not sent - empty [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - agmt="cn=meTom3.example.com" (m3:389): replay_update: Consumer successfully sent operation with csn 53d66ecc000100040000 [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - agmt="cn=meTom3.example.com" (m3:389): Skipping update operation with no message_id (uniqueid 04b0b435-5ef311e3-9c91ec9f-6cd72e64, CSN 53d66ecc000100040000): [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - agmt="cn=meTom3.example.com" (m3:389): No more updates to send (cl5GetNextOperationToReplay) [05/Sep/2014:12:30:49 -0400] - repl5_inc_waitfor_async_results: 0 0 [05/Sep/2014:12:30:49 -0400] - repl5_inc_result_threadmain: read result for message_id 0 [05/Sep/2014:12:30:49 -0400] - repl5_inc_result_threadmain: read result for message_id 0 [05/Sep/2014:12:30:49 -0400] - repl5_inc_result_threadmain: read result for message_id 0 [05/Sep/2014:12:30:50 -0400] - repl5_inc_result_threadmain: read result for message_id 0 [05/Sep/2014:12:30:50 -0400] - repl5_inc_result_threadmain: read result for message_id 0 [05/Sep/2014:12:30:51 -0400] - repl5_inc_result_threadmain exiting [05/Sep/2014:12:30:51 -0400] agmt="cn=meTom2.example.com" (m2:389) - session end: state=3 load=1 sent=36 skipped=13 [05/Sep/2014:12:30:51 -0400] NSMMReplicationPlugin - agmt="cn=meTom2.example.com" (m2:389): Successfully released consumer [05/Sep/2014:12:30:51 -0400] NSMMReplicationPlugin - agmt="cn=meTom2.example.com" (m2:389): Beginning linger on the connection [05/Sep/2014:12:30:51 -0400] NSMMReplicationPlugin - agmt="cn=meTom2.example.com" (m2:389): State: sending_updates -> wait_for_changes [05/Sep/2014:12:30:51 -0400] - repl5_inc_result_threadmain exiting [05/Sep/2014:12:30:51 -0400] agmt="cn=meTom3.example.com" (m3:389) - session end: state=3 load=1 sent=36 skipped=13 [05/Sep/2014:12:30:51 -0400] NSMMReplicationPlugin - agmt="cn=meTom3.example.com" (m3:389): Successfully released consumer [05/Sep/2014:12:30:51 -0400] NSMMReplicationPlugin - agmt="cn=meTom3.example.com" (m3:389): Beginning linger on the connection [05/Sep/2014:12:30:51 -0400] NSMMReplicationPlugin - agmt="cn=meTom3.example.com" (m3:389): State: sending_updates -> wait_for_changes Thanks for your help! -- Guillermo Fuentes Rodriguez Computer Systems Analyst 561-880-2998 x337 guillermo.fuentes at modmed.com 866-799-2146 Toll Free 3600 FAU Blvd., Ste. 202, Boca Raton FL 33431 FORBES 2013 Top 50 - America's Most Promising Companies SFBJ 2013 Best Places To Work SFBJ 2012 & 2013 #1 Fastest Growing Company S. FL "Fast 50" Red Herring 2014 North America Top 100 Company On Fri, Sep 5, 2014 at 2:24 AM, Martin Kosek wrote: > On 09/04/2014 05:11 PM, Guillermo Fuentes wrote: >> Hello list, >> >> We?re running FreeIPA with a master and 3 replicas. The replication >> stopped working and currently we?re adding resources only to the >> master. This is the environment we have: >> m1: >> OS: CentOS release 6.5 >> FreeIPA: 3.0.0-37 >> CA: pki-ca-9.0.3 >> >> >> # ipa-replica-manage list -v `hostname` >> m2.example.com: replica >> last init status: None >> last init ended: None >> last update status: 49 - LDAP error: Invalid credentials >> last update ended: None >> m3.example.com: replica >> last init status: None >> last init ended: None >> last update status: 0 Replica acquired successfully: Incremental >> update succeeded >> last update ended: 2014-09-04 14:28:44+00:00 >> m4.example.com: replica >> last init status: None >> last init ended: None >> last update status: -2 - LDAP error: Local error >> last update ended: None >> >> m2: >> OS: CentOS release 6.5 >> FreeIPA: 3.0.0-37 >> >> # ipa-replica-manage list -v `hostname` >> m1.example.com: replica >> last init status: None >> last init ended: None >> last update status: -1 Incremental update has failed and requires >> administrator actionLDAP error: Can't contact LDAP server >> last update ended: 2014-09-03 22:53:21+00:00 >> >> m3: >> OS: CentOS release 6.5 >> FreeIPA: 3.0.0-37 >> >> # ipa-replica-manage list -v `hostname` >> m1.example.com: replica >> last init status: None >> last init ended: None >> last update status: 0 Replica acquired successfully: Incremental >> update succeeded >> last update ended: 2014-09-04 14:31:51+00:00 >> >> m4: >> OS: CentOS release 6.5 >> FreeIPA: 3.3.3-28 >> >> # ipa-replica-manage list -v `hostname` >> m1.example.com: replica >> last init status: None >> last init ended: None >> last update status: 49 Unable to acquire replicaLDAP error: Invalid >> credentials >> last update ended: None >> >> >> Note that although m3 reports ?Incremental update succeeded?, users >> created on m1 are not replicated to m3, and users created on m3 are >> not replicated back to m1. >> >> We?ve tried different things including re-initializing m2. >> >> Can somebody point me in the right direction to get replication going again? >> >> Thanks in advance! >> >> Guillermo > > Hello, > > I think we would need more troubleshooting information that are available in > /var/log/dirsrv/slapd-EXAMPLE-COM/errors, especially on m2, m3, m4. > > Few pointers what I would try myself: > 1) Check that all masters have time synced (difference in matter of seconds is OK) > > 2) Check that DNS is all right - all replicas can resolve master's forward and > reverse address. Master can resolve all replicas forward and reverse address. > > This is common source of replication/Kerberos errors > (http://www.freeipa.org/page/Troubleshooting#Kerberos_does_not_work) > The error "Can't contact LDAP server" may point to DNS issues. > > 3) Check that you can do plain ldapsearch from replica to master. Ideally even > authenticated with keytab from /etc/dirsrv/ds.keytab > > HTH, > Martin -- Guillermo Fuentes Rodriguez Computer Systems Analyst 561-880-2998 x337 guillermo.fuentes at modmed.com 866-799-2146 Toll Free 3600 FAU Blvd., Ste. 202, Boca Raton FL 33431 FORBES 2013 Top 50 - America's Most Promising Companies SFBJ 2013 Best Places To Work SFBJ 2012 & 2013 #1 Fastest Growing Company S. FL "Fast 50" Red Herring 2014 North America Top 100 Company -------------- next part -------------- A non-text attachment was scrubbed... Name: m4.log Type: application/octet-stream Size: 168105 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: m3.log Type: application/octet-stream Size: 556469 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: m2.log Type: application/octet-stream Size: 159411 bytes Desc: not available URL: From pspacek at redhat.com Fri Sep 5 17:56:54 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 05 Sep 2014 19:56:54 +0200 Subject: [Freeipa-users] DNS not responding properly.... In-Reply-To: <5409E172.3050003@damascusgrp.com> References: <5409E172.3050003@damascusgrp.com> Message-ID: <5409F966.6020603@redhat.com> Hello, On 5.9.2014 18:14, Bret Wortman wrote: > I've got an odd situation with one of our networks. Our systems are properly > registered in DNS within IPA, and the web interface and IPA queries work to > resolve the hosts, but named isn't playing along with us. > > [root at ipa1 data]# ipa dnsrecord-find foo.net --name=asterisk > Record name: asterisk > A record: 192.168.252.155 > ---------------------------- > Number of entries returned 1 > ---------------------------- > [root at ipa1 data]# host asterisk.foo.net > Host asterisk.foo.net not found: 3(NXDOMAIN) > [root at ipa1 data]# cat /etc/resolv.conf > search foo.net > nameserver 192.168.252.61 <--------- This is ipa1 > nameserver 192.168.252.62 > nameserver 192.168.252.63 > [root at ipa1 data]# ifconfig > ens192: flags=4163 mtu 1500 > inet 192.168.252.61 netmask 255.255.255.0 broadcast 192.168.252.255 > inet6 fe80::250:56ff:fe04:401 prefixlen 64 scopeid 0x20 > ether 00:50:56:04:04:01 txqueuelen 1000 (Ethernet) > RX packets 2189 bytes 332143 (324.3 KiB) > RX errors 0 dropped 0 overruns 0 frame 0 > TX packets 1523 bytes 428925 (418.8 KiB) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > > lo: flags=73 mtu 65536 > inet 127.0.0.1 netmask 255.0.0.0 > inet6 ::1 prefixlen 128 scopeid 0x10 > loop txqueuelen 0 (Local Loopback) > RX packets 1037 bytes 718872 (702.0 KiB) > RX errors 0 dropped 0 overruns 0 frame 0 > TX packets 1037 bytes 718872 (702.0 KiB) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > > [root at ipa1 data]# > > When I dig into the named.run file, I see the trace below (I ran an "rndc > reload" after seeing the request to do so at the end of an earlier section of > the file; it obviously didn't help much). I'm not sure where else to look. > /etc/named.conf and /var/named/named.ca both are in line with what we have on > another similar system where everything is working just fine. Any thoughts? Please double check output from $ ipa dnszone-show foo.net It should contain line like: Active zone: TRUE Petr^2 Spacek > 05-Sep-2014 12:04:47.111 received control channel command 'reload' > 05-Sep-2014 12:04:47.111 zone 252.168.192.in-addr.arpa/IN: shutting down > 05-Sep-2014 12:04:47.112 loading configuration from '/etc/named.conf' > 05-Sep-2014 12:04:47.112 using default UDP/IPv4 port range: [1024, 65535] > 05-Sep-2014 12:04:47.112 using default UDP/IPv6 port range: [1024, 65535] > 05-Sep-2014 12:04:47.113 sizing zone task pool based on 6 zones > 05-Sep-2014 12:04:47.116 option 'serial_autoincrement' is not supported, ignoring > 05-Sep-2014 12:04:47.194 automatic empty zone: 10.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.194 automatic empty zone: 16.172.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.194 automatic empty zone: 17.172.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.194 automatic empty zone: 18.172.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.194 automatic empty zone: 19.172.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.194 automatic empty zone: 20.172.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.194 automatic empty zone: 21.172.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.194 automatic empty zone: 22.172.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.194 automatic empty zone: 23.172.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.194 automatic empty zone: 24.172.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.194 automatic empty zone: 25.172.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.195 automatic empty zone: 26.172.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.196 automatic empty zone: 27.172.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.196 automatic empty zone: 28.172.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.196 automatic empty zone: 29.172.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.196 automatic empty zone: 30.172.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.196 automatic empty zone: 31.172.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.196 automatic empty zone: 168.192.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.196 automatic empty zone: 64.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.196 automatic empty zone: 65.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.196 automatic empty zone: 66.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.198 automatic empty zone: 67.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.198 automatic empty zone: 68.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.198 automatic empty zone: 69.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.198 automatic empty zone: 70.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.198 automatic empty zone: 71.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.198 automatic empty zone: 72.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.198 automatic empty zone: 73.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.198 automatic empty zone: 74.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.198 automatic empty zone: 75.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.198 automatic empty zone: 76.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.198 automatic empty zone: 77.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.198 automatic empty zone: 78.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.198 automatic empty zone: 79.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.199 automatic empty zone: 80.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.199 automatic empty zone: 81.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.199 automatic empty zone: 82.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.199 automatic empty zone: 83.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.199 automatic empty zone: 84.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.200 automatic empty zone: 85.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.200 automatic empty zone: 86.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.200 automatic empty zone: 87.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.200 automatic empty zone: 88.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.200 automatic empty zone: 89.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.200 automatic empty zone: 90.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.201 automatic empty zone: 91.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.201 automatic empty zone: 92.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.201 automatic empty zone: 93.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.201 automatic empty zone: 94.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.201 automatic empty zone: 95.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.201 automatic empty zone: 96.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.202 automatic empty zone: 97.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.202 automatic empty zone: 98.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.202 automatic empty zone: 99.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.202 automatic empty zone: 100.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.202 automatic empty zone: 101.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.202 automatic empty zone: 102.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.203 automatic empty zone: 103.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.203 automatic empty zone: 104.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.203 automatic empty zone: 105.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.203 automatic empty zone: 106.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.203 automatic empty zone: 107.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.203 automatic empty zone: 108.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.204 automatic empty zone: 109.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.204 automatic empty zone: 110.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.204 automatic empty zone: 111.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.204 automatic empty zone: 112.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.204 automatic empty zone: 113.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.204 automatic empty zone: 114.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.205 automatic empty zone: 115.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.205 automatic empty zone: 116.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.205 automatic empty zone: 117.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.205 automatic empty zone: 118.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.205 automatic empty zone: 119.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.206 automatic empty zone: 120.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.206 automatic empty zone: 121.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.206 automatic empty zone: 122.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.206 automatic empty zone: 123.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.206 automatic empty zone: 124.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.207 automatic empty zone: 125.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.207 automatic empty zone: 126.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.207 automatic empty zone: 127.100.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.207 automatic empty zone: 127.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.207 automatic empty zone: 254.169.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.208 automatic empty zone: 2.0.192.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.208 automatic empty zone: 100.51.198.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.208 automatic empty zone: 113.0.203.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.208 automatic empty zone: 255.255.255.255.IN-ADDR.ARPA > 05-Sep-2014 12:04:47.208 automatic empty zone: > 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA > 05-Sep-2014 12:04:47.209 automatic empty zone: D.F.IP6.ARPA > 05-Sep-2014 12:04:47.209 automatic empty zone: 8.E.F.IP6.ARPA > 05-Sep-2014 12:04:47.209 automatic empty zone: 9.E.F.IP6.ARPA > 05-Sep-2014 12:04:47.209 automatic empty zone: A.E.F.IP6.ARPA > 05-Sep-2014 12:04:47.209 automatic empty zone: B.E.F.IP6.ARPA > 05-Sep-2014 12:04:47.210 automatic empty zone: 8.B.D.0.1.0.0.2.IP6.ARPA > 05-Sep-2014 12:04:47.213 reloading configuration succeeded > 05-Sep-2014 12:04:47.213 reloading zones succeeded > 05-Sep-2014 12:04:47.225 all zones loaded > 05-Sep-2014 12:04:47.226 running > 05-Sep-2014 12:04:47.226 update_record (syncrepl) failed, dn > 'idnsname=ipa1,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type 0x1. Records > can be outdated, run `rndc reload`: not found > 05-Sep-2014 12:04:47.226 update_record (syncrepl) failed, dn > 'idnsname=_kerberos,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type 0x1. > Records can be outdated, run `rndc reload`: not found > 05-Sep-2014 12:04:47.317 update_record (syncrepl) failed, dn > 'idnsname=_ldap._tcp,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type 0x1. > Records can be outdated, run `rndc reload`: not found > 05-Sep-2014 12:04:47.317 update_record (syncrepl) failed, dn > 'idnsname=_kerberos._tcp,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type 0x1. > Records can be outdated, run `rndc reload`: not found > 05-Sep-2014 12:04:47.318 update_record (syncrepl) failed, dn > 'idnsname=_kerberos._udp,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type 0x1. > Records can be outdated, run `rndc reload`: not found > 05-Sep-2014 12:04:47.318 update_record (syncrepl) failed, dn > 'idnsname=_kerberos-master._tcp,idnsname=foo.net,cn=dns,dc=foo,dc=net' change > type 0x1. Records can be outdated, run `rndc reload`: not found > 05-Sep-2014 12:04:47.318 update_record (syncrepl) failed, dn > 'idnsname=_kerberos-master._udp,idnsname=foo.net,cn=dns,dc=foo,dc=net' change > type 0x1. Records can be outdated, run `rndc reload`: not found > 05-Sep-2014 12:04:47.318 update_record (syncrepl) failed, dn > 'idnsname=_kpasswd._tcp,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type 0x1. > Records can be outdated, run `rndc reload`: not found > 05-Sep-2014 12:04:47.318 update_record (syncrepl) failed, dn > 'idnsname=_kpasswd._udp,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type 0x1. > Records can be outdated, run `rndc reload`: not found > 05-Sep-2014 12:04:47.319 update_record (syncrepl) failed, dn > 'idnsname=_ntp._udp,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type 0x1. > Records can be outdated, run `rndc reload`: not found > 05-Sep-2014 12:04:47.319 update_record (syncrepl) failed, dn > 'idnsname=ipa-ca,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type 0x1. Records > can be outdated, run `rndc reload`: not found > 05-Sep-2014 12:04:47.319 update_record (syncrepl) failed, dn > 'idnsname=ipa2,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type 0x1. Records > can be outdated, run `rndc reload`: not found > 05-Sep-2014 12:04:47.319 update_record (syncrepl) failed, dn > 'idnsname=mcnetmon,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type 0x1. > Records can be outdated, run `rndc reload`: not found > 05-Sep-2014 12:04:47.320 update_record (syncrepl) failed, dn > 'idnsname=asterisk,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type 0x1. > Records can be outdated, run `rndc reload`: not found > 05-Sep-2014 12:04:47.320 zone 252.168.192.in-addr.arpa/IN: loaded serial 1409933087 > 05-Sep-2014 12:04:47.320 1 zones from LDAP instance 'ipa' loaded (1 zones defined) From guillermo.fuentes at modernizingmedicine.com Fri Sep 5 18:06:00 2014 From: guillermo.fuentes at modernizingmedicine.com (Guillermo Fuentes) Date: Fri, 5 Sep 2014 14:06:00 -0400 Subject: [Freeipa-users] Replication stopped working In-Reply-To: References: <54095723.3050109@redhat.com> Message-ID: Update: m2 and m3 are now in sync! After making sure ldapsearch was working both ways (m1<=>m2 and m1<=>m3) using the server's keytabs (/etc/dirsrv/ds.keytab) for getting the ticket, I re-initialize both replicas and they were able to get updated: @m2 # ipa-replica-manage re-initialize --from m1.example.com @m3 # ipa-replica-manage re-initialize --from m1.example.com Thanks so much for your hint Martin! On Fri, Sep 5, 2014 at 12:43 PM, Guillermo Fuentes wrote: > Hi Martin, > > Attached are m2.log, m3.log and m4.log files. > > 1) All masters are time synced with same NTP server pool. > 2) DNS is fine. Forward and reverse lookup. > 3) ldapsearch: > m1 to m2 and m3 work: > kinit -k -t /etc/dirsrv/ds.keytab ldap/`hostname` # getting ticket on m1 > > ldapsearch -Y GSSAPI -H ldaps://m2.example.com -b > "dc=example,dc=com" uid=testuser > ldapsearch -Y GSSAPI -H ldaps://m3.example.com -b > "dc=example,dc=com" uid=testuser > > m1 to m4 fails: > # ldapsearch -Y GSSAPI -H ldaps://m4.example.com -b > "dc=example,dc=com" uid=testuser > SASL/GSSAPI authentication started > ldap_sasl_interactive_bind_s: Local error (-2) > additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified > GSS failure. Minor code may provide more information (KDC returned > error string: FINDING_SERVER_KEY) > > > m2 to m1, and m3 to m1 work fine: > kinit -k -t /etc/dirsrv/ds.keytab ldap/`hostname` > ldapsearch -Y GSSAPI -H ldaps://m1.example.com -b > "dc=example,dc=com" uid=testuser > > m4 to m1 fails: > # ldapsearch -Y GSSAPI -H ldaps://m1.example.com -b > "dc=example,dc=com" uid=testuser > SASL/GSSAPI authentication started > ldap_sasl_interactive_bind_s: Invalid credentials (49) > additional info: SASL(-14): authorization failure: security flags do > not match required > > > m2 and m3 are at the same state now where connections between them and > m1 are fine but the updates won't happen logging the following on m1 > (/var/log/dirsrv/slapd-EXAMPLE-COM/errors) for both: > > [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - > agmt="cn=meTom3.example.com" (m3:389): replay_update: Sending modify > operation (dn="uid=testuser,cn=users,cn=accounts,dc=example,dc=com" > csn=53d66ecb000000040000) > [05/Sep/2014:12:30:49 -0400] - repl5_inc_result_threadmain: read > result for message_id 0 > [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - > agmt="cn=meTom3.example.com" (m3:389): replay_update: modifys > operation (dn="uid=testuser,cn=users,cn=accounts,dc=example,dc=com" > csn=53d66ecb000000040000) not sent - empty > [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - > agmt="cn=meTom3.example.com" (m3:389): replay_update: Consumer > successfully sent operation with csn 53d66ecb000000040000 > [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - > agmt="cn=meTom3.example.com" (m3:389): Skipping update operation with > no message_id (uniqueid 04b0b435-5ef311e3-9c91ec9f-6cd72e64, CSN > 53d66ecb000000040000): > [05/Sep/2014:12:30:49 -0400] agmt="cn=meTom3.example.com" (m3:389) - > load=1 rec=38 csn=53d66ecb000200040000 > [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - > agmt="cn=meTom3.example.com" (m3:389): replay_update: Sending modify > operation (dn="uid=testuser,cn=users,cn=accounts,dc=example,dc=com" > csn=53d66ecb000200040000) > [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - > agmt="cn=meTom3.example.com" (m3:389): replay_update: modifys > operation (dn="uid=testuser,cn=users,cn=accounts,dc=example,dc=com" > csn=53d66ecb000200040000) not sent - empty > [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - > agmt="cn=meTom3.example.com" (m3:389): replay_update: Consumer > successfully sent operation with csn 53d66ecb000200040000 > [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - > agmt="cn=meTom3.example.com" (m3:389): Skipping update operation with > no message_id (uniqueid 04b0b435-5ef311e3-9c91ec9f-6cd72e64, CSN > 53d66ecb000200040000): > [05/Sep/2014:12:30:49 -0400] agmt="cn=meTom3.example.com" (m3:389) - > load=1 rec=39 csn=53d66ecc000100040000 > [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - > agmt="cn=meTom3.example.com" (m3:389): replay_update: Sending modify > operation (dn="uid=testuser,cn=users,cn=accounts,dc=example,dc=com" > csn=53d66ecc000100040000) > [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - > agmt="cn=meTom3.example.com" (m3:389): replay_update: modifys > operation (dn="uid=testuser,cn=users,cn=accounts,dc=example,dc=com" > csn=53d66ecc000100040000) not sent - empty > [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - > agmt="cn=meTom3.example.com" (m3:389): replay_update: Consumer > successfully sent operation with csn 53d66ecc000100040000 > [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - > agmt="cn=meTom3.example.com" (m3:389): Skipping update operation with > no message_id (uniqueid 04b0b435-5ef311e3-9c91ec9f-6cd72e64, CSN > 53d66ecc000100040000): > [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - > agmt="cn=meTom3.example.com" (m3:389): No more updates to send > (cl5GetNextOperationToReplay) > [05/Sep/2014:12:30:49 -0400] - repl5_inc_waitfor_async_results: 0 0 > [05/Sep/2014:12:30:49 -0400] - repl5_inc_result_threadmain: read > result for message_id 0 > [05/Sep/2014:12:30:49 -0400] - repl5_inc_result_threadmain: read > result for message_id 0 > [05/Sep/2014:12:30:49 -0400] - repl5_inc_result_threadmain: read > result for message_id 0 > [05/Sep/2014:12:30:50 -0400] - repl5_inc_result_threadmain: read > result for message_id 0 > [05/Sep/2014:12:30:50 -0400] - repl5_inc_result_threadmain: read > result for message_id 0 > [05/Sep/2014:12:30:51 -0400] - repl5_inc_result_threadmain exiting > [05/Sep/2014:12:30:51 -0400] agmt="cn=meTom2.example.com" (m2:389) - > session end: state=3 load=1 sent=36 skipped=13 > [05/Sep/2014:12:30:51 -0400] NSMMReplicationPlugin - > agmt="cn=meTom2.example.com" (m2:389): Successfully released consumer > [05/Sep/2014:12:30:51 -0400] NSMMReplicationPlugin - > agmt="cn=meTom2.example.com" (m2:389): Beginning linger on the > connection > [05/Sep/2014:12:30:51 -0400] NSMMReplicationPlugin - > agmt="cn=meTom2.example.com" (m2:389): State: sending_updates -> > wait_for_changes > [05/Sep/2014:12:30:51 -0400] - repl5_inc_result_threadmain exiting > [05/Sep/2014:12:30:51 -0400] agmt="cn=meTom3.example.com" (m3:389) - > session end: state=3 load=1 sent=36 skipped=13 > [05/Sep/2014:12:30:51 -0400] NSMMReplicationPlugin - > agmt="cn=meTom3.example.com" (m3:389): Successfully released consumer > [05/Sep/2014:12:30:51 -0400] NSMMReplicationPlugin - > agmt="cn=meTom3.example.com" (m3:389): Beginning linger on the > connection > [05/Sep/2014:12:30:51 -0400] NSMMReplicationPlugin - > agmt="cn=meTom3.example.com" (m3:389): State: sending_updates -> > wait_for_changes > > Thanks for your help! > > -- > Guillermo Fuentes Rodriguez > Computer Systems Analyst > 561-880-2998 x337 > guillermo.fuentes at modmed.com > 866-799-2146 Toll Free > 3600 FAU Blvd., Ste. 202, Boca Raton FL 33431 > > > > FORBES 2013 Top 50 - America's Most Promising Companies > SFBJ 2013 Best Places To Work > SFBJ 2012 & 2013 #1 Fastest Growing Company S. FL "Fast 50" > Red Herring 2014 North America Top 100 Company > > > > > On Fri, Sep 5, 2014 at 2:24 AM, Martin Kosek wrote: >> On 09/04/2014 05:11 PM, Guillermo Fuentes wrote: >>> Hello list, >>> >>> We?re running FreeIPA with a master and 3 replicas. The replication >>> stopped working and currently we?re adding resources only to the >>> master. This is the environment we have: >>> m1: >>> OS: CentOS release 6.5 >>> FreeIPA: 3.0.0-37 >>> CA: pki-ca-9.0.3 >>> >>> >>> # ipa-replica-manage list -v `hostname` >>> m2.example.com: replica >>> last init status: None >>> last init ended: None >>> last update status: 49 - LDAP error: Invalid credentials >>> last update ended: None >>> m3.example.com: replica >>> last init status: None >>> last init ended: None >>> last update status: 0 Replica acquired successfully: Incremental >>> update succeeded >>> last update ended: 2014-09-04 14:28:44+00:00 >>> m4.example.com: replica >>> last init status: None >>> last init ended: None >>> last update status: -2 - LDAP error: Local error >>> last update ended: None >>> >>> m2: >>> OS: CentOS release 6.5 >>> FreeIPA: 3.0.0-37 >>> >>> # ipa-replica-manage list -v `hostname` >>> m1.example.com: replica >>> last init status: None >>> last init ended: None >>> last update status: -1 Incremental update has failed and requires >>> administrator actionLDAP error: Can't contact LDAP server >>> last update ended: 2014-09-03 22:53:21+00:00 >>> >>> m3: >>> OS: CentOS release 6.5 >>> FreeIPA: 3.0.0-37 >>> >>> # ipa-replica-manage list -v `hostname` >>> m1.example.com: replica >>> last init status: None >>> last init ended: None >>> last update status: 0 Replica acquired successfully: Incremental >>> update succeeded >>> last update ended: 2014-09-04 14:31:51+00:00 >>> >>> m4: >>> OS: CentOS release 6.5 >>> FreeIPA: 3.3.3-28 >>> >>> # ipa-replica-manage list -v `hostname` >>> m1.example.com: replica >>> last init status: None >>> last init ended: None >>> last update status: 49 Unable to acquire replicaLDAP error: Invalid >>> credentials >>> last update ended: None >>> >>> >>> Note that although m3 reports ?Incremental update succeeded?, users >>> created on m1 are not replicated to m3, and users created on m3 are >>> not replicated back to m1. >>> >>> We?ve tried different things including re-initializing m2. >>> >>> Can somebody point me in the right direction to get replication going again? >>> >>> Thanks in advance! >>> >>> Guillermo >> >> Hello, >> >> I think we would need more troubleshooting information that are available in >> /var/log/dirsrv/slapd-EXAMPLE-COM/errors, especially on m2, m3, m4. >> >> Few pointers what I would try myself: >> 1) Check that all masters have time synced (difference in matter of seconds is OK) >> >> 2) Check that DNS is all right - all replicas can resolve master's forward and >> reverse address. Master can resolve all replicas forward and reverse address. >> >> This is common source of replication/Kerberos errors >> (http://www.freeipa.org/page/Troubleshooting#Kerberos_does_not_work) >> The error "Can't contact LDAP server" may point to DNS issues. >> >> 3) Check that you can do plain ldapsearch from replica to master. Ideally even >> authenticated with keytab from /etc/dirsrv/ds.keytab >> >> HTH, >> Martin > > > > -- > Guillermo Fuentes Rodriguez > Computer Systems Analyst > 561-880-2998 x337 > guillermo.fuentes at modmed.com > 866-799-2146 Toll Free > 3600 FAU Blvd., Ste. 202, Boca Raton FL 33431 > > > > FORBES 2013 Top 50 - America's Most Promising Companies > SFBJ 2013 Best Places To Work > SFBJ 2012 & 2013 #1 Fastest Growing Company S. FL "Fast 50" > Red Herring 2014 North America Top 100 Company -- Guillermo Fuentes Rodriguez Computer Systems Analyst 561-880-2998 x337 guillermo.fuentes at modmed.com 866-799-2146 Toll Free 3600 FAU Blvd., Ste. 202, Boca Raton FL 33431 FORBES 2013 Top 50 - America's Most Promising Companies SFBJ 2013 Best Places To Work SFBJ 2012 & 2013 #1 Fastest Growing Company S. FL "Fast 50" Red Herring 2014 North America Top 100 Company From mkosek at redhat.com Fri Sep 5 20:22:28 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 05 Sep 2014 22:22:28 +0200 Subject: [Freeipa-users] Replication stopped working In-Reply-To: References: <54095723.3050109@redhat.com> Message-ID: <540A1B84.4020204@redhat.com> Good to hear Guillermo, I am glad you are back up and running. I am just curious, what as the root cause of your replication errors in the end? I did not catch that from the thread. Is it something we can fix in FreeIPA or is it just a configuration error? Thanks, Martin On 09/05/2014 08:06 PM, Guillermo Fuentes wrote: > Update: > m2 and m3 are now in sync! > > After making sure ldapsearch was working both ways (m1<=>m2 and > m1<=>m3) using the server's keytabs (/etc/dirsrv/ds.keytab) for > getting the ticket, I re-initialize both replicas and they were able > to get updated: > @m2 # ipa-replica-manage re-initialize --from m1.example.com > @m3 # ipa-replica-manage re-initialize --from m1.example.com > > Thanks so much for your hint Martin! From guillermo.fuentes at modernizingmedicine.com Fri Sep 5 22:28:31 2014 From: guillermo.fuentes at modernizingmedicine.com (Guillermo Fuentes) Date: Fri, 5 Sep 2014 18:28:31 -0400 Subject: [Freeipa-users] Replication stopped working In-Reply-To: <540A1B84.4020204@redhat.com> References: <54095723.3050109@redhat.com> <540A1B84.4020204@redhat.com> Message-ID: Hi Martin, That's a good question! We're not sure what was the root cause of the replication errors. When we realized the replication wasn't happening, we had recently updated FreeIPA from 3.0.0-36 to 3.0.0-37 (on CentOS 6.5) and we had shutdown m1 and m2 in order to do a snapshot of the VMs. We've been doing that for several months and never had a problem. Note that m3 wasn't shutdown and the replication stopped for it as well. The configuration wasn't change so I don't think it was a configuration problem. I did have to get a new ldap service keytab for the m2 replica (/etc/dirsrv/ds.keytab) but not for m3. I'll do more research on what happened and report back if I find anything relevant. Thanks again, Guillermo On Fri, Sep 5, 2014 at 4:22 PM, Martin Kosek wrote: > Good to hear Guillermo, I am glad you are back up and running. I am just > curious, what as the root cause of your replication errors in the end? I did > not catch that from the thread. Is it something we can fix in FreeIPA or is > it just a configuration error? > > Thanks, > Martin > > > On 09/05/2014 08:06 PM, Guillermo Fuentes wrote: >> >> Update: >> m2 and m3 are now in sync! >> >> After making sure ldapsearch was working both ways (m1<=>m2 and >> m1<=>m3) using the server's keytabs (/etc/dirsrv/ds.keytab) for >> getting the ticket, I re-initialize both replicas and they were able >> to get updated: >> @m2 # ipa-replica-manage re-initialize --from m1.example.com >> @m3 # ipa-replica-manage re-initialize --from m1.example.com >> >> Thanks so much for your hint Martin! > > From rap at phas.ubc.ca Fri Sep 5 23:40:03 2014 From: rap at phas.ubc.ca (Ron) Date: Fri, 05 Sep 2014 16:40:03 -0700 Subject: [Freeipa-users] ipa user-find finds user but ipa user-del fails In-Reply-To: <5408D6E2.8040106@redhat.com> References: <54073F4C.60602@phas.ubc.ca> <540742AF.20402@redhat.com> <54075346.4030505@redhat.com> <54076913.2070902@phas.ubc.ca> <54076B5E.3060501@redhat.com> <54077DB0.10606@phas.ubc.ca> <54083570.40802@redhat.com> <5408CC3C.7040809@phas.ubc.ca> <5408D6E2.8040106@redhat.com> Message-ID: <540A49D3.7070404@phas.ubc.ca> So, just for completeness in case someone else experiences the same issue, what I did in the end was install JXplorer and then use it to delete the problem entries. They appeared as (for example): nsuniqueid=4034e309-d63711e3-9b7eb928-a98b9061+uid=disk100,cn=users,cn=accounts,dc=xxx,dc=abc,dc=ca Just right-clicked and selected "delete". Based on ease of installation and ease of use, I highly recommend JXplorer (for solving problems like this). It can also be run in a readonly mode which is nice just to poke around without the possibility of messing things up. Regards, Ron On 09/04/2014 02:17 PM, Rich Megginson wrote: > On 09/04/2014 02:31 PM, Ron wrote: >> So I tried to delete an entry on IPA01 without success: >> >> [root at ipa01 ~]# ldapdelete -D >> "uid=admin,cn=users,cn=accounts,dc=xxxx,dc=abc,dc=ca" -W -x >> "cn=userxyz+nsuniqueid=62c9c682-32ce11e4-8c13b928-a98b9061,cn=groups,cn=accounts,dc=xxxx,dc=abc,dc=ca" >> >> Enter LDAP Password: >> ldap_delete: Server is unwilling to perform (53) >> additional info: Deleting a managed entry is not allowed. It needs >> to be manually unlinked first >> >> Same problem if I try to use ldapmodify: >> >> [root at ipa01 ~]# ldapmodify -D >> "uid=admin,cn=users,cn=accounts,dc=xxxx,dc=abc,dc=ca" -W -x >> Enter LDAP Password: >> dn: >> cn=userxyz+nsuniqueid=62c9c682-32ce11e4-8c13b928-a98b9061,cn=groups,cn=accounts,dc=xxxx,dc=abc,dc=ca >> >> changetype: modrdn >> newrdn: uid=19000 >> deleteoldrdn: 0 >> >> modifying rdn of entry >> "cn=userxyz+nsuniqueid=62c9c682-32ce11e4-8c13b928-a98b9061,cn=groups,cn=accounts,dc=xxxx,dc=abc,dc=ca" >> >> ldap_rename: Server is unwilling to perform (53) >> additional info: Renaming a managed entry is not allowed. It needs >> to be manually unlinked first. >> >> (19000 is just an unused uid) >> >> Would this be because of the private group associated with the user? >> >> How do I unlink the entry? Would I use the following? >> ipa group-detach userxyz > > Yes, see https://fedorahosted.org/freeipa/ticket/75 > >> >> Thanks again for all your help! >> -Ron >> >> On 09/04/2014 02:48 AM, Martin Kosek wrote: >>> Ah, ok. As Rob advised, you will need to delete it via ldapdelete >>> CLI or via >>> any LDAP GUI application of choice. >>> >>> BTW, this is upstream ticket tracking better means to resolve >>> replication >>> conflicts: >>> https://fedorahosted.org/freeipa/ticket/1025 >>> >>> Martin >>> >>> On 09/03/2014 10:44 PM, Ron wrote: >>>> By the way, all three replica servers show the same: >>>> >>>> [root at ipa]# ipa user-find --all --raw --login phys210e | grep dn: >>>> dn: >>>> nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=xxxx,dc=abc,dc=ca >>>> >>>> >>>> [root at ipa01]# ipa user-find --all --raw --login phys210e | grep dn: >>>> dn: >>>> nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=xxxx,dc=abc,dc=ca >>>> >>>> >>>> [root at ipa02]# ipa user-find --all --raw --login phys210e | grep dn: >>>> dn: >>>> nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=xxxx,dc=abc,dc=ca >>>> > -- Ron Parachoniak Systems Manager, Department of Physics & Astronomy University of British Columbia, Vancouver, B.C. V6T 1Z1 Phone: (604) 838-6437 From bret.wortman at damascusgrp.com Sat Sep 6 07:18:54 2014 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Sat, 06 Sep 2014 03:18:54 -0400 Subject: [Freeipa-users] DNS not responding properly.... In-Reply-To: <5409F966.6020603@redhat.com> References: <5409E172.3050003@damascusgrp.com> <5409F966.6020603@redhat.com> Message-ID: <540AB55E.4010703@damascusgrp.com> Check. [root at ipa1 data]# ipa dnszone-show foo.net Zone name: foo.net Authoritative nameserver: ipa1.foo.net. Administrator e-mail address: hostmaster.foo.net. SOA serial: 1400521450 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 Active zone: TRUE Allow query: any; Allow transfer: none; Zone forwarders: 8.8.8.8 [root at ipa1 data]# On 09/05/2014 01:56 PM, Petr Spacek wrote: > Hello, > > On 5.9.2014 18:14, Bret Wortman wrote: >> I've got an odd situation with one of our networks. Our systems are >> properly >> registered in DNS within IPA, and the web interface and IPA queries >> work to >> resolve the hosts, but named isn't playing along with us. >> >> [root at ipa1 data]# ipa dnsrecord-find foo.net --name=asterisk >> Record name: asterisk >> A record: 192.168.252.155 >> ---------------------------- >> Number of entries returned 1 >> ---------------------------- >> [root at ipa1 data]# host asterisk.foo.net >> Host asterisk.foo.net not found: 3(NXDOMAIN) >> [root at ipa1 data]# cat /etc/resolv.conf >> search foo.net >> nameserver 192.168.252.61 <--------- This is ipa1 >> nameserver 192.168.252.62 >> nameserver 192.168.252.63 >> [root at ipa1 data]# ifconfig >> ens192: flags=4163 mtu 1500 >> inet 192.168.252.61 netmask 255.255.255.0 broadcast >> 192.168.252.255 >> inet6 fe80::250:56ff:fe04:401 prefixlen 64 scopeid >> 0x20 >> ether 00:50:56:04:04:01 txqueuelen 1000 (Ethernet) >> RX packets 2189 bytes 332143 (324.3 KiB) >> RX errors 0 dropped 0 overruns 0 frame 0 >> TX packets 1523 bytes 428925 (418.8 KiB) >> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 >> >> lo: flags=73 mtu 65536 >> inet 127.0.0.1 netmask 255.0.0.0 >> inet6 ::1 prefixlen 128 scopeid 0x10 >> loop txqueuelen 0 (Local Loopback) >> RX packets 1037 bytes 718872 (702.0 KiB) >> RX errors 0 dropped 0 overruns 0 frame 0 >> TX packets 1037 bytes 718872 (702.0 KiB) >> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 >> >> [root at ipa1 data]# >> >> When I dig into the named.run file, I see the trace below (I ran an >> "rndc >> reload" after seeing the request to do so at the end of an earlier >> section of >> the file; it obviously didn't help much). I'm not sure where else to >> look. >> /etc/named.conf and /var/named/named.ca both are in line with what we >> have on >> another similar system where everything is working just fine. Any >> thoughts? > > Please double check output from > $ ipa dnszone-show foo.net > > It should contain line like: > Active zone: TRUE > > Petr^2 Spacek > >> 05-Sep-2014 12:04:47.111 received control channel command 'reload' >> 05-Sep-2014 12:04:47.111 zone 252.168.192.in-addr.arpa/IN: shutting down >> 05-Sep-2014 12:04:47.112 loading configuration from '/etc/named.conf' >> 05-Sep-2014 12:04:47.112 using default UDP/IPv4 port range: [1024, >> 65535] >> 05-Sep-2014 12:04:47.112 using default UDP/IPv6 port range: [1024, >> 65535] >> 05-Sep-2014 12:04:47.113 sizing zone task pool based on 6 zones >> 05-Sep-2014 12:04:47.116 option 'serial_autoincrement' is not >> supported, ignoring >> 05-Sep-2014 12:04:47.194 automatic empty zone: 10.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.194 automatic empty zone: 16.172.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.194 automatic empty zone: 17.172.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.194 automatic empty zone: 18.172.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.194 automatic empty zone: 19.172.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.194 automatic empty zone: 20.172.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.194 automatic empty zone: 21.172.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.194 automatic empty zone: 22.172.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.194 automatic empty zone: 23.172.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.194 automatic empty zone: 24.172.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.194 automatic empty zone: 25.172.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.195 automatic empty zone: 26.172.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.196 automatic empty zone: 27.172.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.196 automatic empty zone: 28.172.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.196 automatic empty zone: 29.172.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.196 automatic empty zone: 30.172.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.196 automatic empty zone: 31.172.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.196 automatic empty zone: 168.192.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.196 automatic empty zone: 64.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.196 automatic empty zone: 65.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.196 automatic empty zone: 66.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.198 automatic empty zone: 67.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.198 automatic empty zone: 68.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.198 automatic empty zone: 69.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.198 automatic empty zone: 70.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.198 automatic empty zone: 71.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.198 automatic empty zone: 72.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.198 automatic empty zone: 73.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.198 automatic empty zone: 74.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.198 automatic empty zone: 75.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.198 automatic empty zone: 76.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.198 automatic empty zone: 77.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.198 automatic empty zone: 78.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.198 automatic empty zone: 79.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.199 automatic empty zone: 80.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.199 automatic empty zone: 81.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.199 automatic empty zone: 82.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.199 automatic empty zone: 83.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.199 automatic empty zone: 84.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.200 automatic empty zone: 85.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.200 automatic empty zone: 86.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.200 automatic empty zone: 87.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.200 automatic empty zone: 88.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.200 automatic empty zone: 89.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.200 automatic empty zone: 90.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.201 automatic empty zone: 91.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.201 automatic empty zone: 92.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.201 automatic empty zone: 93.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.201 automatic empty zone: 94.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.201 automatic empty zone: 95.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.201 automatic empty zone: 96.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.202 automatic empty zone: 97.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.202 automatic empty zone: 98.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.202 automatic empty zone: 99.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.202 automatic empty zone: 100.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.202 automatic empty zone: 101.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.202 automatic empty zone: 102.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.203 automatic empty zone: 103.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.203 automatic empty zone: 104.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.203 automatic empty zone: 105.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.203 automatic empty zone: 106.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.203 automatic empty zone: 107.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.203 automatic empty zone: 108.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.204 automatic empty zone: 109.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.204 automatic empty zone: 110.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.204 automatic empty zone: 111.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.204 automatic empty zone: 112.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.204 automatic empty zone: 113.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.204 automatic empty zone: 114.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.205 automatic empty zone: 115.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.205 automatic empty zone: 116.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.205 automatic empty zone: 117.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.205 automatic empty zone: 118.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.205 automatic empty zone: 119.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.206 automatic empty zone: 120.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.206 automatic empty zone: 121.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.206 automatic empty zone: 122.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.206 automatic empty zone: 123.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.206 automatic empty zone: 124.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.207 automatic empty zone: 125.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.207 automatic empty zone: 126.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.207 automatic empty zone: 127.100.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.207 automatic empty zone: 127.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.207 automatic empty zone: 254.169.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.208 automatic empty zone: 2.0.192.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.208 automatic empty zone: 100.51.198.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.208 automatic empty zone: 113.0.203.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.208 automatic empty zone: >> 255.255.255.255.IN-ADDR.ARPA >> 05-Sep-2014 12:04:47.208 automatic empty zone: >> 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA >> 05-Sep-2014 12:04:47.209 automatic empty zone: D.F.IP6.ARPA >> 05-Sep-2014 12:04:47.209 automatic empty zone: 8.E.F.IP6.ARPA >> 05-Sep-2014 12:04:47.209 automatic empty zone: 9.E.F.IP6.ARPA >> 05-Sep-2014 12:04:47.209 automatic empty zone: A.E.F.IP6.ARPA >> 05-Sep-2014 12:04:47.209 automatic empty zone: B.E.F.IP6.ARPA >> 05-Sep-2014 12:04:47.210 automatic empty zone: 8.B.D.0.1.0.0.2.IP6.ARPA >> 05-Sep-2014 12:04:47.213 reloading configuration succeeded >> 05-Sep-2014 12:04:47.213 reloading zones succeeded >> 05-Sep-2014 12:04:47.225 all zones loaded >> 05-Sep-2014 12:04:47.226 running >> 05-Sep-2014 12:04:47.226 update_record (syncrepl) failed, dn >> 'idnsname=ipa1,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type >> 0x1. Records >> can be outdated, run `rndc reload`: not found >> 05-Sep-2014 12:04:47.226 update_record (syncrepl) failed, dn >> 'idnsname=_kerberos,idnsname=foo.net,cn=dns,dc=foo,dc=net' change >> type 0x1. >> Records can be outdated, run `rndc reload`: not found >> 05-Sep-2014 12:04:47.317 update_record (syncrepl) failed, dn >> 'idnsname=_ldap._tcp,idnsname=foo.net,cn=dns,dc=foo,dc=net' change >> type 0x1. >> Records can be outdated, run `rndc reload`: not found >> 05-Sep-2014 12:04:47.317 update_record (syncrepl) failed, dn >> 'idnsname=_kerberos._tcp,idnsname=foo.net,cn=dns,dc=foo,dc=net' >> change type 0x1. >> Records can be outdated, run `rndc reload`: not found >> 05-Sep-2014 12:04:47.318 update_record (syncrepl) failed, dn >> 'idnsname=_kerberos._udp,idnsname=foo.net,cn=dns,dc=foo,dc=net' >> change type 0x1. >> Records can be outdated, run `rndc reload`: not found >> 05-Sep-2014 12:04:47.318 update_record (syncrepl) failed, dn >> 'idnsname=_kerberos-master._tcp,idnsname=foo.net,cn=dns,dc=foo,dc=net' change >> >> type 0x1. Records can be outdated, run `rndc reload`: not found >> 05-Sep-2014 12:04:47.318 update_record (syncrepl) failed, dn >> 'idnsname=_kerberos-master._udp,idnsname=foo.net,cn=dns,dc=foo,dc=net' change >> >> type 0x1. Records can be outdated, run `rndc reload`: not found >> 05-Sep-2014 12:04:47.318 update_record (syncrepl) failed, dn >> 'idnsname=_kpasswd._tcp,idnsname=foo.net,cn=dns,dc=foo,dc=net' change >> type 0x1. >> Records can be outdated, run `rndc reload`: not found >> 05-Sep-2014 12:04:47.318 update_record (syncrepl) failed, dn >> 'idnsname=_kpasswd._udp,idnsname=foo.net,cn=dns,dc=foo,dc=net' change >> type 0x1. >> Records can be outdated, run `rndc reload`: not found >> 05-Sep-2014 12:04:47.319 update_record (syncrepl) failed, dn >> 'idnsname=_ntp._udp,idnsname=foo.net,cn=dns,dc=foo,dc=net' change >> type 0x1. >> Records can be outdated, run `rndc reload`: not found >> 05-Sep-2014 12:04:47.319 update_record (syncrepl) failed, dn >> 'idnsname=ipa-ca,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type >> 0x1. Records >> can be outdated, run `rndc reload`: not found >> 05-Sep-2014 12:04:47.319 update_record (syncrepl) failed, dn >> 'idnsname=ipa2,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type >> 0x1. Records >> can be outdated, run `rndc reload`: not found >> 05-Sep-2014 12:04:47.319 update_record (syncrepl) failed, dn >> 'idnsname=mcnetmon,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type >> 0x1. >> Records can be outdated, run `rndc reload`: not found >> 05-Sep-2014 12:04:47.320 update_record (syncrepl) failed, dn >> 'idnsname=asterisk,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type >> 0x1. >> Records can be outdated, run `rndc reload`: not found >> 05-Sep-2014 12:04:47.320 zone 252.168.192.in-addr.arpa/IN: loaded >> serial 1409933087 >> 05-Sep-2014 12:04:47.320 1 zones from LDAP instance 'ipa' loaded (1 >> zones defined) > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3766 bytes Desc: S/MIME Cryptographic Signature URL: From cwhittl at gmail.com Sat Sep 6 14:08:34 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Sat, 6 Sep 2014 09:08:34 -0500 Subject: [Freeipa-users] Search Base issues In-Reply-To: <540834D3.2070003@redhat.com> References: <540585B3.9030606@redhat.com> <5406233E.3040705@redhat.com> <54062920.4010605@redhat.com> <540631F0.1020805@redhat.com> <5406BD07.6040204@redhat.com> <5406C342.6060406@redhat.com> <540712D6.9090909@redhat.com> <54072158.9080400@redhat.com> <54075442.2050604@redhat.com> <540834D3.2070003@redhat.com> Message-ID: Thanks Martin, can you do SSSD on MAC's? On Thu, Sep 4, 2014 at 4:45 AM, Martin Kosek wrote: > Ok, thanks. Good to see it is working for you. > > I see you actually do authorization decision based on Schema Compatibility > plugin :) Note that an alternate, preferred way of doing authorization in > FreeIPA though is HBAC where you would configure which group of users can > login > to which machines. > > But this is only being enforced when SSSD is on the client machine, so it > may > not be working for all your machines. > > Martin > > On 09/03/2014 10:45 PM, Chris Whittle wrote: > > Success here is my LDIF if anyone needs to do this with a MAC > > > >> dn: cn=Mac Users, cn=Schema Compatibility, cn=plugins, cn=config > >> > >> objectClass: top > >> > >> objectClass: extensibleObject > >> > >> cn: Mac Users > >> > >> schema-compat-search-base: cn=users,cn=accounts,dc=DOMAIN,dc=com > >> > >> schema-compat-search-filter: > >> > (&(objectClass=posixaccount)(memberOf=cn=canlogin,cn=groups,cn=accounts,dc > >> DOMAIN,dc=com)) > >> > >> schema-compat-container-group: cn=compat,dc=DOMAIN,dc=com > >> > >> schema-compat-container-rdn: cn=canlogin > >> > >> schema-compat-entry-rdn: cn=%{cn} > >> > >> schema-compat-entry-attribute: objectclass=inetOrgPerson > >> > >> schema-compat-entry-attribute: objectclass=posixAccount > >> > >> schema-compat-entry-attribute: gecos=%{cn} > >> > >> schema-compat-entry-attribute: cn=%{cn} > >> > >> schema-compat-entry-attribute: uid=%{uid} > >> > >> schema-compat-entry-attribute: uidNumber=%{uidNumber} > >> > >> schema-compat-entry-attribute: gidNumber=%{gidNumber} > >> > >> schema-compat-entry-attribute: loginShell=%{loginShell} > >> > >> schema-compat-entry-attribute: homeDirectory=%{homeDirectory} > >> > > > > > > > > On Wed, Sep 3, 2014 at 1:04 PM, Chris Whittle wrote: > > > >> Thanks Rob for the explanation! > >> > >> I think I have it working, I just have to test a machine and verify. > >> > >> > >> On Wed, Sep 3, 2014 at 12:47 PM, Rob Crittenden > >> wrote: > >> > >>> Chris Whittle wrote: > >>>> That worked, but having issues get it to work with the OSX Directory > >>>> Utility. > >>>> I'm wondering if it's because when you go against the OU normally it's > >>>> returning more info about the user versus what's being returned from > the > >>>> compat "view" I'm going to experiment with the attributes it's > returning > >>>> and see if that's it. > >>>> > >>>> I'm also wondering why FreeIPA doesn't support multiple OU's natively, > >>>> this would be so much easier with multiple OUs (one for my non-users > and > >>>> one for my users) > >>> > >>> Because they are so very often used really, really poorly, resulting in > >>> having to move entries around a lot with no real technical reason > behind > >>> it. Think about the number of times an IT department gets renamed, > oops, > >>> today they are called Global Support Services, oh no, didn't you hear, > >>> now they are ... Each one requiring an entire subtree move. Where the > >>> users exist in LDAP does not generally need to reflect the > >>> organizational structure. > >>> > >>> Your case is a bit different from most, where you want to host two > >>> completely separate kinds of users. > >>> > >>> rob > >>> > >>>> > >>>> > >>>> On Wed, Sep 3, 2014 at 9:10 AM, Martin Kosek >>>> > wrote: > >>>> > >>>> On 09/03/2014 03:08 PM, Rob Crittenden wrote: > >>>> > Martin Kosek wrote: > >>>> >> On 09/03/2014 09:02 AM, Martin Kosek wrote: > >>>> >>> In the meantime, you can use the workaround that Rob sent, you > >>>> would just need > >>>> >>> to delete it again when the fix is in, so that the permissions > >>>> do not step on > >>>> >>> each other. > >>>> >> > >>>> >> Actually, wait a minute. I think Rob's ACI example may be too > >>>> wide, it may > >>>> >> expose any attribute in the compat tree, including a potential > >>>> userPassword. > >>>> > > >>>> > The ACI was on his custom cn=canlogin subtree, not all of > >>> cn=compat. > >>>> > > >>>> >> As I see, it seems that slapi-nis plugin do not fortunately > >>>> expose that, but it > >>>> >> is safer to just list the attributes that one wants to display > >>>> (this is also > >>>> >> what we did in FreeIPA 4.0, no global wildcard allowing ACIs > any > >>>> more). > >>>> >> > >>>> >> I added a respective permission via Web UI (one part of it > cannot > >>>> be added via > >>>> >> CLI, see https://fedorahosted.org/freeipa/ticket/4522) and > >>> compat > >>>> tree now > >>>> >> works for me. See attached example. > >>>> >> > >>>> >> Resulting permission shown in CLI: > >>>> >> > >>>> >> # ipa permission-show "TEMPORARY - Read compat tree" > >>>> >> Permission name: TEMPORARY - Read compat tree > >>>> >> Granted rights: read, search, compare > >>>> >> Effective attributes: cn, description, gecos, gidnumber, > >>>> homedirectory, > >>>> >> loginshell, memberuid, > >>>> >> objectclass, uid, uidnumber > >>>> >> Bind rule type: all > >>>> >> Subtree: dc=mkosek-fedora20,dc=test > >>>> >> ACI target DN: cn=compat,dc=mkosek-fedora20,dc=test > >>>> >> > >>>> >> It is much easier to manipulate than ACI added via ldapmodify. > >>>> > > >>>> > I see you filed a bug on the missing CLI option. That's why I > did > >>> the > >>>> > ACI, because I couldn't demonstrate how to add this ACI on the > >>> CLI. I > >>>> > hadn't gotten around to doing that last night. > >>>> > > >>>> > rob > >>>> > >>>> Right. Surprisingly, the option was available in Web UI, thus the > >>> Web UI > >>>> screenshot I attached to the thread :) But we have the CLI option > >>> fixed > >>>> already, will be part of FreeIPA 4.0.2 which will be released very > >>> soon. > >>>> > >>>> Martin > >>>> > >>>> > >>> > >>> > >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mohammadsereshki at yahoo.com Sun Sep 7 11:45:33 2014 From: mohammadsereshki at yahoo.com (mohammad sereshki) Date: Sun, 7 Sep 2014 04:45:33 -0700 Subject: [Freeipa-users] webmin can't work after installing freeipa Message-ID: <1410090333.5837.YahooMailNeo@web161503.mail.bf1.yahoo.com> Hi I configured IPA on solaris as client and it works correctly. but the problem is I have webmin to manage my servers and it can't login after IPA installation. Please help me. thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From mohammadsereshki at yahoo.com Sun Sep 7 14:08:12 2014 From: mohammadsereshki at yahoo.com (mohammad sereshki) Date: Sun, 7 Sep 2014 07:08:12 -0700 Subject: [Freeipa-users] webmin can't work after installing freeipa In-Reply-To: <1410090333.5837.YahooMailNeo@web161503.mail.bf1.yahoo.com> References: <1410090333.5837.YahooMailNeo@web161503.mail.bf1.yahoo.com> Message-ID: <1410098892.25866.YahooMailNeo@web161504.mail.bf1.yahoo.com> Hi I configured IPA on solaris as client and it works correctly. but the problem is I have webmin to manage my servers and it can't login after IPA installation. Please help me. thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From gregor.bregenzer at gmail.com Sun Sep 7 21:41:16 2014 From: gregor.bregenzer at gmail.com (Gregor Bregenzer) Date: Sun, 7 Sep 2014 23:41:16 +0200 Subject: [Freeipa-users] sssd receives another uid/gid after disabled HBAC rule Message-ID: Hi! I have an AD trust with FreeIPA 4.0.1 and defined a HBAC rule for a specific user group (=ad_users which is an posix group that has an external group as member) to login on a specific client (=linux1.linux.intern). The problem is: once i disable the rule and the AD user is not allowed to login anymore, the user on the client gets another uid and gid via sssd. I use the posix attributes from AD, which will get received by sssd perfectly. The client is running on CentOS 6.5 and uses sssd 1.9.2.129.el6_5.4 AD domain = aaa.intern IPA domain = linux.intern AD-User: user1 (uid=1005,gid=10005) Here an example: ---------------------------- 1.) disable the hbac rule and the default allow_all rule: 2.) check the uid/gid on the client (=linux1.linux.intern) and it looks fine: [root at linux1 sssd]# getent passwd user1 at aaa user1 at aaa.intern:*:10005:10005::/home/user1 at aaa.intern:/bin/bash 3.) Login with ssh to client as user1. It will be denied upon correct password input and ssh sessions closes. Up until now everything as expected. But now: 4.) check for the uid/gid on the client - something totally different. It now also receives the Firstname and Lastname from AD, latter is empty: [root at linux1 sssd]# getent passwd user1 at aaa user1 at aaa.intern:*:11601:11601:user1:/home/user1 at aaa.intern:/bin/bash 5.) Enable the hbac rule and login works, but the unexpected uid/gid stays the same: login as: user1 at aaa user1 at aaa@192.168.0.100's password: login as: user1 at aaa user1 at aaa@192.168.0.100's password: Last failed login: Sun Sep 7 23:19:49 CEST 2014 from 192.168.0.26 on ssh:notty There were 2 failed login attempts since the last successful login. Creating home directory for user1 at aaa. Last login: Sun Sep 7 23:21:02 2014 from 192.168.0.26 [user1 at aaa.intern@linux1 ~]$ id uid=11601(user1 at aaa.intern) gid=11601(user1 at aaa.intern) Gruppen=11601(user1 at aaa.intern),1933000004(ad_users) [user1 at aaa.intern@linux1 ~]$ --------------------------------- Anyone have a clue what might be the problem? Here's the sssd.conf: [root at linux1 sssd]# cat /etc/sssd/sssd.conf [domain/linux.intern] debug_level=6 cache_credentials = False krb5_store_password_if_offline = False ipa_domain = linux.intern id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = linux1.linux.intern chpass_provider = ipa ipa_dyndns_update = True ipa_server = _srv_, ipa1.linux.intern ldap_tls_cacert = /etc/ipa/ca.crt use_fully_qualified_domains = True # For the SUDO integration sudo_provider = ldap ldap_uri = ldap://ipa1.linux.intern ldap_sudo_search_base = ou=sudoers,dc=linux,dc=intern ldap_sasl_mech = GSSAPI ldap_sasl_authid = host/linux1.linux.intern ldap_sasl_realm = LINUX.INTERN krb5_server = ipa1.linux.intern entry_cache_sudo_timeout = 30 [sssd] debug_level=6 services = nss, pam, ssh, sudo config_file_version = 2 default_domain_suffix=aaa.intern domains = linux.intern [nss] debug_level=9 override_homedir = /home/%u override_shell = /bin/bash [pam] debug_level=6 [sudo] debug_level=6 [autofs] [ssh] debug_level=6 [pac] Thanks! Gregor From dpal at redhat.com Mon Sep 8 02:26:40 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 08 Sep 2014 04:26:40 +0200 Subject: [Freeipa-users] webmin can't work after installing freeipa In-Reply-To: <1410090333.5837.YahooMailNeo@web161503.mail.bf1.yahoo.com> References: <1410090333.5837.YahooMailNeo@web161503.mail.bf1.yahoo.com> Message-ID: <540D13E0.7030600@redhat.com> On 09/07/2014 01:45 PM, mohammad sereshki wrote: > Hi > I configured IPA on solaris as client and it works correctly. > but the problem is I have webmin to manage my servers and it can't > login after IPA installation. > Please help me. > thanks > > > Why do you need webmin if you are deploying IPA? What is your goal? IPA is the central store for the accounts it takes over the machine and configures the client on the server. Other tools should not be used after you install it. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mohammadsereshki at yahoo.com Mon Sep 8 06:03:47 2014 From: mohammadsereshki at yahoo.com (mohammad sereshki) Date: Sun, 7 Sep 2014 23:03:47 -0700 Subject: [Freeipa-users] webmin can't work after installing freeipa In-Reply-To: <540D13E0.7030600@redhat.com> References: <1410090333.5837.YahooMailNeo@web161503.mail.bf1.yahoo.com> <540D13E0.7030600@redhat.com> Message-ID: <1410156227.82404.YahooMailNeo@web161504.mail.bf1.yahoo.com> Dear I have some scripts that should be run on all servers and I should use webmin. anyway i fixed it by changing authentication mechanism from pam to don't use pam. ________________________________ From: Dmitri Pal To: freeipa-users at redhat.com Sent: Monday, September 8, 2014 6:56 AM Subject: Re: [Freeipa-users] webmin can't work after installing freeipa On 09/07/2014 01:45 PM, mohammad sereshki wrote: Hi >I configured IPA on solaris as client and it works correctly. >but the problem is I have webmin to manage my servers and it can't login after IPA installation. >Please help me. >thanks > > > > > Why do you need webmin if you are deploying IPA? What is your goal? IPA is the central store for the accounts it takes over the machine and configures the client on the server. Other tools should not be used after you install it. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Mon Sep 8 06:16:55 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 08 Sep 2014 08:16:55 +0200 Subject: [Freeipa-users] DNS not responding properly.... In-Reply-To: <540AB55E.4010703@damascusgrp.com> References: <5409E172.3050003@damascusgrp.com> <5409F966.6020603@redhat.com> <540AB55E.4010703@damascusgrp.com> Message-ID: <540D49D7.1060301@redhat.com> On 6.9.2014 09:18, Bret Wortman wrote: > Check. > > [root at ipa1 data]# ipa dnszone-show foo.net > Zone name: foo.net > Authoritative nameserver: ipa1.foo.net. > Administrator e-mail address: hostmaster.foo.net. > SOA serial: 1400521450 > SOA refresh: 3600 > SOA retry: 900 > SOA expire: 1209600 > SOA minimum: 3600 > Active zone: TRUE > Allow query: any; > Allow transfer: none; > Zone forwarders: 8.8.8.8 I suspect that you use IPA version < 4.0, right? Configuration > Zone forwarders: 8.8.8.8 instructs IPA to ignore whole content of the zone and to forward all queries to specified servers. The errors you can see in logs are saying that you are trying to add records to zone which doesn't exist (because 'forward zone' is not a real zone :-). The master and forward zones are clearly separated in IPA 4.0: http://www.freeipa.org/page/V4/Forward_zones My guess is that you can simply remove the forwarder and thing will start working again: $ ipa dnszone-mod foo.net --forwarder='' Have a nice day! Petr^2 Spacek > On 09/05/2014 01:56 PM, Petr Spacek wrote: >> Hello, >> >> On 5.9.2014 18:14, Bret Wortman wrote: >>> I've got an odd situation with one of our networks. Our systems are properly >>> registered in DNS within IPA, and the web interface and IPA queries work to >>> resolve the hosts, but named isn't playing along with us. >>> >>> [root at ipa1 data]# ipa dnsrecord-find foo.net --name=asterisk >>> Record name: asterisk >>> A record: 192.168.252.155 >>> ---------------------------- >>> Number of entries returned 1 >>> ---------------------------- >>> [root at ipa1 data]# host asterisk.foo.net >>> Host asterisk.foo.net not found: 3(NXDOMAIN) >>> [root at ipa1 data]# cat /etc/resolv.conf >>> search foo.net >>> nameserver 192.168.252.61 <--------- This is ipa1 >>> nameserver 192.168.252.62 >>> nameserver 192.168.252.63 >>> [root at ipa1 data]# ifconfig >>> ens192: flags=4163 mtu 1500 >>> inet 192.168.252.61 netmask 255.255.255.0 broadcast >>> 192.168.252.255 >>> inet6 fe80::250:56ff:fe04:401 prefixlen 64 scopeid 0x20 >>> ether 00:50:56:04:04:01 txqueuelen 1000 (Ethernet) >>> RX packets 2189 bytes 332143 (324.3 KiB) >>> RX errors 0 dropped 0 overruns 0 frame 0 >>> TX packets 1523 bytes 428925 (418.8 KiB) >>> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 >>> >>> lo: flags=73 mtu 65536 >>> inet 127.0.0.1 netmask 255.0.0.0 >>> inet6 ::1 prefixlen 128 scopeid 0x10 >>> loop txqueuelen 0 (Local Loopback) >>> RX packets 1037 bytes 718872 (702.0 KiB) >>> RX errors 0 dropped 0 overruns 0 frame 0 >>> TX packets 1037 bytes 718872 (702.0 KiB) >>> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 >>> >>> [root at ipa1 data]# >>> >>> When I dig into the named.run file, I see the trace below (I ran an "rndc >>> reload" after seeing the request to do so at the end of an earlier section of >>> the file; it obviously didn't help much). I'm not sure where else to look. >>> /etc/named.conf and /var/named/named.ca both are in line with what we have on >>> another similar system where everything is working just fine. Any thoughts? >> >> Please double check output from >> $ ipa dnszone-show foo.net >> >> It should contain line like: >> Active zone: TRUE >> >> Petr^2 Spacek >> >>> 05-Sep-2014 12:04:47.111 received control channel command 'reload' >>> 05-Sep-2014 12:04:47.111 zone 252.168.192.in-addr.arpa/IN: shutting down >>> 05-Sep-2014 12:04:47.112 loading configuration from '/etc/named.conf' >>> 05-Sep-2014 12:04:47.112 using default UDP/IPv4 port range: [1024, 65535] >>> 05-Sep-2014 12:04:47.112 using default UDP/IPv6 port range: [1024, 65535] >>> 05-Sep-2014 12:04:47.113 sizing zone task pool based on 6 zones >>> 05-Sep-2014 12:04:47.116 option 'serial_autoincrement' is not supported, >>> ignoring >>> 05-Sep-2014 12:04:47.194 automatic empty zone: 10.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.194 automatic empty zone: 16.172.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.194 automatic empty zone: 17.172.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.194 automatic empty zone: 18.172.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.194 automatic empty zone: 19.172.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.194 automatic empty zone: 20.172.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.194 automatic empty zone: 21.172.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.194 automatic empty zone: 22.172.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.194 automatic empty zone: 23.172.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.194 automatic empty zone: 24.172.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.194 automatic empty zone: 25.172.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.195 automatic empty zone: 26.172.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.196 automatic empty zone: 27.172.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.196 automatic empty zone: 28.172.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.196 automatic empty zone: 29.172.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.196 automatic empty zone: 30.172.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.196 automatic empty zone: 31.172.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.196 automatic empty zone: 168.192.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.196 automatic empty zone: 64.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.196 automatic empty zone: 65.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.196 automatic empty zone: 66.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.198 automatic empty zone: 67.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.198 automatic empty zone: 68.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.198 automatic empty zone: 69.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.198 automatic empty zone: 70.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.198 automatic empty zone: 71.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.198 automatic empty zone: 72.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.198 automatic empty zone: 73.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.198 automatic empty zone: 74.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.198 automatic empty zone: 75.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.198 automatic empty zone: 76.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.198 automatic empty zone: 77.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.198 automatic empty zone: 78.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.198 automatic empty zone: 79.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.199 automatic empty zone: 80.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.199 automatic empty zone: 81.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.199 automatic empty zone: 82.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.199 automatic empty zone: 83.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.199 automatic empty zone: 84.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.200 automatic empty zone: 85.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.200 automatic empty zone: 86.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.200 automatic empty zone: 87.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.200 automatic empty zone: 88.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.200 automatic empty zone: 89.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.200 automatic empty zone: 90.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.201 automatic empty zone: 91.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.201 automatic empty zone: 92.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.201 automatic empty zone: 93.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.201 automatic empty zone: 94.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.201 automatic empty zone: 95.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.201 automatic empty zone: 96.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.202 automatic empty zone: 97.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.202 automatic empty zone: 98.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.202 automatic empty zone: 99.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.202 automatic empty zone: 100.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.202 automatic empty zone: 101.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.202 automatic empty zone: 102.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.203 automatic empty zone: 103.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.203 automatic empty zone: 104.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.203 automatic empty zone: 105.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.203 automatic empty zone: 106.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.203 automatic empty zone: 107.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.203 automatic empty zone: 108.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.204 automatic empty zone: 109.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.204 automatic empty zone: 110.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.204 automatic empty zone: 111.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.204 automatic empty zone: 112.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.204 automatic empty zone: 113.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.204 automatic empty zone: 114.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.205 automatic empty zone: 115.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.205 automatic empty zone: 116.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.205 automatic empty zone: 117.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.205 automatic empty zone: 118.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.205 automatic empty zone: 119.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.206 automatic empty zone: 120.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.206 automatic empty zone: 121.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.206 automatic empty zone: 122.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.206 automatic empty zone: 123.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.206 automatic empty zone: 124.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.207 automatic empty zone: 125.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.207 automatic empty zone: 126.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.207 automatic empty zone: 127.100.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.207 automatic empty zone: 127.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.207 automatic empty zone: 254.169.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.208 automatic empty zone: 2.0.192.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.208 automatic empty zone: 100.51.198.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.208 automatic empty zone: 113.0.203.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.208 automatic empty zone: 255.255.255.255.IN-ADDR.ARPA >>> 05-Sep-2014 12:04:47.208 automatic empty zone: >>> 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA >>> 05-Sep-2014 12:04:47.209 automatic empty zone: D.F.IP6.ARPA >>> 05-Sep-2014 12:04:47.209 automatic empty zone: 8.E.F.IP6.ARPA >>> 05-Sep-2014 12:04:47.209 automatic empty zone: 9.E.F.IP6.ARPA >>> 05-Sep-2014 12:04:47.209 automatic empty zone: A.E.F.IP6.ARPA >>> 05-Sep-2014 12:04:47.209 automatic empty zone: B.E.F.IP6.ARPA >>> 05-Sep-2014 12:04:47.210 automatic empty zone: 8.B.D.0.1.0.0.2.IP6.ARPA >>> 05-Sep-2014 12:04:47.213 reloading configuration succeeded >>> 05-Sep-2014 12:04:47.213 reloading zones succeeded >>> 05-Sep-2014 12:04:47.225 all zones loaded >>> 05-Sep-2014 12:04:47.226 running >>> 05-Sep-2014 12:04:47.226 update_record (syncrepl) failed, dn >>> 'idnsname=ipa1,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type 0x1. Records >>> can be outdated, run `rndc reload`: not found >>> 05-Sep-2014 12:04:47.226 update_record (syncrepl) failed, dn >>> 'idnsname=_kerberos,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type 0x1. >>> Records can be outdated, run `rndc reload`: not found >>> 05-Sep-2014 12:04:47.317 update_record (syncrepl) failed, dn >>> 'idnsname=_ldap._tcp,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type 0x1. >>> Records can be outdated, run `rndc reload`: not found >>> 05-Sep-2014 12:04:47.317 update_record (syncrepl) failed, dn >>> 'idnsname=_kerberos._tcp,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type >>> 0x1. >>> Records can be outdated, run `rndc reload`: not found >>> 05-Sep-2014 12:04:47.318 update_record (syncrepl) failed, dn >>> 'idnsname=_kerberos._udp,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type >>> 0x1. >>> Records can be outdated, run `rndc reload`: not found >>> 05-Sep-2014 12:04:47.318 update_record (syncrepl) failed, dn >>> 'idnsname=_kerberos-master._tcp,idnsname=foo.net,cn=dns,dc=foo,dc=net' change >>> type 0x1. Records can be outdated, run `rndc reload`: not found >>> 05-Sep-2014 12:04:47.318 update_record (syncrepl) failed, dn >>> 'idnsname=_kerberos-master._udp,idnsname=foo.net,cn=dns,dc=foo,dc=net' change >>> type 0x1. Records can be outdated, run `rndc reload`: not found >>> 05-Sep-2014 12:04:47.318 update_record (syncrepl) failed, dn >>> 'idnsname=_kpasswd._tcp,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type >>> 0x1. >>> Records can be outdated, run `rndc reload`: not found >>> 05-Sep-2014 12:04:47.318 update_record (syncrepl) failed, dn >>> 'idnsname=_kpasswd._udp,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type >>> 0x1. >>> Records can be outdated, run `rndc reload`: not found >>> 05-Sep-2014 12:04:47.319 update_record (syncrepl) failed, dn >>> 'idnsname=_ntp._udp,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type 0x1. >>> Records can be outdated, run `rndc reload`: not found >>> 05-Sep-2014 12:04:47.319 update_record (syncrepl) failed, dn >>> 'idnsname=ipa-ca,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type 0x1. >>> Records >>> can be outdated, run `rndc reload`: not found >>> 05-Sep-2014 12:04:47.319 update_record (syncrepl) failed, dn >>> 'idnsname=ipa2,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type 0x1. Records >>> can be outdated, run `rndc reload`: not found >>> 05-Sep-2014 12:04:47.319 update_record (syncrepl) failed, dn >>> 'idnsname=mcnetmon,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type 0x1. >>> Records can be outdated, run `rndc reload`: not found >>> 05-Sep-2014 12:04:47.320 update_record (syncrepl) failed, dn >>> 'idnsname=asterisk,idnsname=foo.net,cn=dns,dc=foo,dc=net' change type 0x1. >>> Records can be outdated, run `rndc reload`: not found >>> 05-Sep-2014 12:04:47.320 zone 252.168.192.in-addr.arpa/IN: loaded serial >>> 1409933087 >>> 05-Sep-2014 12:04:47.320 1 zones from LDAP instance 'ipa' loaded (1 zones >>> defined) >> > > > > -- Petr^2 Spacek From sbose at redhat.com Mon Sep 8 07:17:51 2014 From: sbose at redhat.com (Sumit Bose) Date: Mon, 8 Sep 2014 09:17:51 +0200 Subject: [Freeipa-users] sssd receives another uid/gid after disabled HBAC rule In-Reply-To: References: Message-ID: <20140908071751.GN4089@localhost.localdomain> On Sun, Sep 07, 2014 at 11:41:16PM +0200, Gregor Bregenzer wrote: > Hi! > > I have an AD trust with FreeIPA 4.0.1 and defined a HBAC rule for a > specific user group (=ad_users which is an posix group that has an > external group as member) to login on a specific client > (=linux1.linux.intern). > > The problem is: once i disable the rule and the AD user is not allowed > to login anymore, the user on the client gets another uid and gid via > sssd. > > I use the posix attributes from AD, which will get received by sssd perfectly. > The client is running on CentOS 6.5 and uses sssd 1.9.2.129.el6_5.4 > AD domain = aaa.intern > IPA domain = linux.intern > AD-User: user1 (uid=1005,gid=10005) > > Here an example: > ---------------------------- > 1.) disable the hbac rule and the default allow_all rule: > 2.) check the uid/gid on the client (=linux1.linux.intern) and it looks fine: > > [root at linux1 sssd]# getent passwd user1 at aaa > user1 at aaa.intern:*:10005:10005::/home/user1 at aaa.intern:/bin/bash > > 3.) Login with ssh to client as user1. It will be denied upon correct > password input and ssh sessions closes. Up until now everything as > expected. But now: > > 4.) check for the uid/gid on the client - something totally different. > It now also receives the Firstname and Lastname from AD, latter is > empty: > > [root at linux1 sssd]# getent passwd user1 at aaa > user1 at aaa.intern:*:11601:11601:user1:/home/user1 at aaa.intern:/bin/bash > > 5.) Enable the hbac rule and login works, but the unexpected uid/gid > stays the same: > > login as: user1 at aaa > user1 at aaa@192.168.0.100's password: > login as: user1 at aaa > user1 at aaa@192.168.0.100's password: > Last failed login: Sun Sep 7 23:19:49 CEST 2014 from 192.168.0.26 on ssh:notty > There were 2 failed login attempts since the last successful login. > Creating home directory for user1 at aaa. > Last login: Sun Sep 7 23:21:02 2014 from 192.168.0.26 > [user1 at aaa.intern@linux1 ~]$ id > uid=11601(user1 at aaa.intern) gid=11601(user1 at aaa.intern) > Gruppen=11601(user1 at aaa.intern),1933000004(ad_users) > [user1 at aaa.intern@linux1 ~]$ > --------------------------------- > > Anyone have a clue what might be the problem? I would expect some kind of collision, but to be sure I need the SSSD log files. Please try to reproduce the switch and send me the log file, if possilbe with debug_level=9. bye, Sumit > > Here's the sssd.conf: > [root at linux1 sssd]# cat /etc/sssd/sssd.conf > [domain/linux.intern] > debug_level=6 > cache_credentials = False > krb5_store_password_if_offline = False > ipa_domain = linux.intern > id_provider = ipa > auth_provider = ipa > access_provider = ipa > ipa_hostname = linux1.linux.intern > chpass_provider = ipa > ipa_dyndns_update = True > ipa_server = _srv_, ipa1.linux.intern > ldap_tls_cacert = /etc/ipa/ca.crt > use_fully_qualified_domains = True > # For the SUDO integration > sudo_provider = ldap > ldap_uri = ldap://ipa1.linux.intern > ldap_sudo_search_base = ou=sudoers,dc=linux,dc=intern > ldap_sasl_mech = GSSAPI > ldap_sasl_authid = host/linux1.linux.intern > ldap_sasl_realm = LINUX.INTERN > krb5_server = ipa1.linux.intern > entry_cache_sudo_timeout = 30 > [sssd] > debug_level=6 > services = nss, pam, ssh, sudo > config_file_version = 2 > default_domain_suffix=aaa.intern > domains = linux.intern > [nss] > debug_level=9 > override_homedir = /home/%u > override_shell = /bin/bash > [pam] > debug_level=6 > [sudo] > debug_level=6 > [autofs] > > [ssh] > debug_level=6 > [pac] > > > > Thanks! > Gregor > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project From tevfik.ceydeliler at astron.yasar.com.tr Mon Sep 8 08:24:57 2014 From: tevfik.ceydeliler at astron.yasar.com.tr (Tevfik Ceydeliler) Date: Mon, 8 Sep 2014 11:24:57 +0300 Subject: [Freeipa-users] How to use sudo rules on ubuntu In-Reply-To: <20140902081338.GA31435@mail.corp.redhat.com> References: <20140901092021.GB3593@redhat.com> <5404505A.5090409@astron.yasar.com.tr> <20140901111858.GE3593@redhat.com> <540468D4.6020408@astron.yasar.com.tr> <20140901124231.GF8008@mail.corp.redhat.com> <54046B03.1030201@astron.yasar.com.tr> <20140901130410.GG8008@mail.corp.redhat.com> <5404881E.7050204@astron.yasar.com.tr> <20140901160539.GJ8008@mail.corp.redhat.com> <5405799A.7080507@astron.yasar.com.tr> <20140902081338.GA31435@mail.corp.redhat.com> Message-ID: <540D67D9.9030205@astron.yasar.com.tr> Is there any article to describe how to configure ubuntu client for ipa and sudo policy? On 02-09-2014 11:13, Lukas Slebodnik wrote: > On (02/09/14 11:02), Tevfik Ceydeliler wrote: >> Step 0 >> root at clnt:/home/awtadm# grep sudoers /etc/nsswitch.conf >> sudoers_debug: 1 >> sudoers: files sss >> >> root at clnt:/home/awtadm# ipa-client-install --no-ntp >> IPA client is already configured on this system. >> >> root at clnt:/home/awtadm# grep services /etc/sssd/sssd.conf >> services = nss, pam, ssh, sudo >> > You need to restart sssd after modification of option "services" in > /etc/sssd/sssd.conf. I forgot to mention it. > >> Step1 (there is some problem when create rule on CLI. No problem prompt on >> Web-based) >> ... >> [root at srv ~]# ipa sudorule-add-option readfiles >> Sudo Option: !authenticate >> ipa: ERROR: no such entry >> >> ... >> Then: >> awtadm at clnt:~$ su user1 >> Password: >> uid=1423400004(user1) gid=1423400004(user1) groups=1423400004(user1) >> user1 at clnt:/home/awtadm$ sudo -l >> [sudo] password for user1: >> Sorry, user user1 may not run sudo on clnt. > There is no reason to try sudo commands if "sudo -l" fails. > > It works for me on ubuntu 14.04. It is very likely you have problem > on FreeIPA Server. Other people can help you with server part, > I could help you just with client configuration. > (From my point of view, problem is solved) > > One more time, please follow instructions: > http://www.freeipa.org/docs/master/html-desktop/index.html#sudo > > LS --


Bu elektronik postada bulunan tum fikir ve gorusler ve ekindeki dosyalar sadece adres sahip/sahiplerine ait olup, Yasar Toplulugu Sirketleri bu mesajin icerigi ile ilgili olarak hic bir hukuksal sorumlulugu kabul etmez. Eger gonderilmesi dusunulen kisi veya kurulus degilseniz, lutfen gonderen kisiyi derhal haberdar ediniz ve mesaji sisteminizden siliniz.The information contained in this e-mail and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and Yasar Group Companies do not accept legal responsibility for the contents. If you are not the intended recipient, please immediately notify the sender and delete it from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.png Type: image/png Size: 15216 bytes Desc: not available URL: From asl.gerardo at gmail.com Mon Sep 8 09:44:10 2014 From: asl.gerardo at gmail.com (Gerardo Padierna) Date: Mon, 08 Sep 2014 11:44:10 +0200 Subject: [Freeipa-users] Solaris 10 client auth (ssh + kerberos) not working Message-ID: <540D7A6A.4030202@gmail.com> Hello folks, I'm setting up an IPA-server instance aimed to be used primarily for Linux/Unix clients ssh authentication (with kerberos). I've managed to successfully set up debian clients (via sssd and also on older debians, through libnss and pam_krb5). But for some reason I can't authenticate ssh on Solaris10 clients. On the Solaris box, I've followed the steps outiined here: http://www.freeipa.org/page/ConfiguringUnixClients and the nss part works fine (things like getent [group | passwd] and id work), but unfortunaltely, the ssh user authentication fails with an error: sshd auth.error PAM-KRB5 (auth): krb5_verify_init_creds failed: No such file or directory On the solaris clients, does there need to be a keytab in /etc/krb5/ directory copied over from the IPA server? (I didn't have to set up a keytab file fo the legacy debian clients, and in the solaris-clients doc previously mentioned, there's no mention of it). Well, since I read somewhere the keytab file need to be there, I copied it over from the IPA server to the solaris clients, Then I get a different error: PAM-KRB5 (auth): krb5_verify_init_creds failed: Key table entry not found This error seems to indicate that there isn't an matching entry found in the keytab file, so I added an entry for the solaris client, but I'm still getting the same 'Key table entry not found' error (it could be the entry I added is wrong, of course). But, for now, just want to be sure: On the solaris clients, do I need an /etc/krb5/krb5.keytab file? (if yes, why not in the non-sssd Debian hosts then?) Thanks in advance, -- *Gerardo Padierna Nanclares* T?cnico de Sistemas (grupo ASL) - [Fujitsu / Logware] Servicio de Sistemas de la Informaci?n (DGTI) - Generalitat Valenciana C/.Castan Tobe?as 77 ? 46018 Valencia ? Edificio A Tel: 961 208973 Email: asl.gerardo at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From lslebodn at redhat.com Mon Sep 8 10:24:58 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Mon, 8 Sep 2014 12:24:58 +0200 Subject: [Freeipa-users] How to use sudo rules on ubuntu In-Reply-To: <540D67D9.9030205@astron.yasar.com.tr> References: <20140901111858.GE3593@redhat.com> <540468D4.6020408@astron.yasar.com.tr> <20140901124231.GF8008@mail.corp.redhat.com> <54046B03.1030201@astron.yasar.com.tr> <20140901130410.GG8008@mail.corp.redhat.com> <5404881E.7050204@astron.yasar.com.tr> <20140901160539.GJ8008@mail.corp.redhat.com> <5405799A.7080507@astron.yasar.com.tr> <20140902081338.GA31435@mail.corp.redhat.com> <540D67D9.9030205@astron.yasar.com.tr> Message-ID: <20140908102458.GB4123@mail.corp.redhat.com> On (08/09/14 11:24), Tevfik Ceydeliler wrote: >Is there any article to describe how to configure ubuntu client for ipa and >sudo policy? > I have already described steps in this thread. It works for me. You did the same steps. It means there is problem on server side. LS From mohammadsereshki at yahoo.com Mon Sep 8 10:49:31 2014 From: mohammadsereshki at yahoo.com (mohammad sereshki) Date: Mon, 8 Sep 2014 03:49:31 -0700 Subject: [Freeipa-users] Solaris 10 client auth (ssh + kerberos) not working In-Reply-To: <540D7A6A.4030202@gmail.com> References: <540D7A6A.4030202@gmail.com> Message-ID: <1410173371.15200.YahooMailNeo@web161501.mail.bf1.yahoo.com> hi Please go ahead with below structure, It works! Re: [Freeipa-users] Does Solaris 11 work as client to IPA server? Re: [Freeipa-users] Does Solaris 11 work as client to IPA server? [Date Prev][Date Next] [Thread Prev][Thread Next] [Thread Index] [Date Index] [Author Index] Re: [Freeipa-users] Does Solaris 11 work as client to IPA server? View on www.redhat.com Preview by Yahoo ________________________________ From: Gerardo Padierna To: freeipa-users at redhat.com Sent: Monday, September 8, 2014 2:14 PM Subject: [Freeipa-users] Solaris 10 client auth (ssh + kerberos) not working Hello folks, I'm setting up an IPA-server instance aimed to be used primarily for Linux/Unix clients ssh authentication (with kerberos). I've managed to successfully set up debian clients (via sssd and also on older debians, through libnss and pam_krb5). But for some reason I can't authenticate ssh on Solaris10 clients. On the Solaris box, I've followed the steps outiined here: http://www.freeipa.org/page/ConfiguringUnixClients and the nss part works fine (things like getent [group | passwd] and id work), but unfortunaltely, the ssh user authentication fails with an error: sshd auth.error PAM-KRB5 (auth): krb5_verify_init_creds failed: No such file or directory On the solaris clients, does there need to be a keytab in /etc/krb5/ directory copied over from the IPA server? (I didn't have to set up a keytab file fo the legacy debian clients, and in the solaris-clients doc previously mentioned, there's no mention of it). Well, since I read somewhere the keytab file need to be there, I copied it over from the IPA server to the solaris clients, Then I get a different error: PAM-KRB5 (auth): krb5_verify_init_creds failed: Key table entry not found This error seems to indicate that there isn't an matching entry found in the keytab file, so I added an entry for the solaris client, but I'm still getting the same 'Key table entry not found' error (it could be the entry I added is wrong, of course). But, for now, just want to be sure: On the solaris clients, do I need an /etc/krb5/krb5.keytab file? (if yes, why not in the non-sssd Debian hosts then?) Thanks in advance, -- Gerardo Padierna Nanclares T?cnico de Sistemas (grupo ASL) - [Fujitsu / Logware] Servicio de Sistemas de la Informaci?n (DGTI) - Generalitat Valenciana C/.Castan Tobe?as 77 ? 46018 Valencia ? Edificio A Tel: 961 208973 Email: asl.gerardo at gmail.com -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Mon Sep 8 12:10:12 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 08 Sep 2014 14:10:12 +0200 Subject: [Freeipa-users] Announcing FreeIPA 4.0.2 Message-ID: <540D9CA4.1070602@redhat.com> The FreeIPA team is proud to announce FreeIPA v4.0.2! It can be downloaded from http://www.freeipa.org/page/Downloads. The builds will be available for Fedora 21. Builds for Fedora 20 are available in the official [https://copr.fedoraproject.org/coprs/mkosek/freeipa/ COPR repository]. == Highlights in 4.0.2 == === Enhancements === * TOTP watermark support was added. The last token interval is now being added to database and replicated in FreeIPA realm. Note that the number of writes is kept the same as an unnecessary LDAP write was eliminated. * Effective Attributes widget in the Add Permission Web UI page was improved * ipa-csreplica-manage can now set CA renewal master * trust-add is now capable of ensuring conditions for a Trust are met prior to establishing it in complex environments (e.g. only adding trust via AD DC with a PDC role in a forest root domain, falling back when no closest AD DC is available for the local site) === Bug fixes === * Server installation with certificates signed by external CA could crash with IndexError * ipa-client-install could add duplicate "sss" to /etc/nsswitch.conf when configuring sudo * ipa-client-install crashed when non-zero minSSF was set on FreeIPA server * Installers and helper tools now communicate with certmonger via its DBUS API instead of manipulating its configuration files, fixing the related intermittent uninstallation failures * idrange-* commands no longer allow unsupported range types (ipa-ad-winsync, ipa-ipa-trust) * user-add no longer fails when --user-auth-type is specified * Entries in Schema Compatibility tree are now accessible anonymously by default to aid legacy clients. == Known Issues == * The Directory Server may crash during install due to 389-ds bug 47889 (https://fedorahosted.org/389/ticket/47889). * Enumeration in SSSD may fail due to 389-ds bug 47885 (https://fedorahosted.org/389/ticket/47885). * Zone removal may misbehave due to a bind-dyndb-ldap bug. If FreeIPA is used to manage DNS root zones, bind-dyndb-ldap 5.1 or higher is recommended. Bind-dyndb-ldap 5.2 was built for Fedora 20 (http://copr.fedoraproject.org/coprs/mkosek/freeipa/build/31135/), 21 (https://admin.fedoraproject.org/updates/bind-dyndb-ldap-5.2-1.fc21), rawhide (http://koji.fedoraproject.org/koji/buildinfo?buildID=575841). == Upgrading == An IPA server can be upgraded simply by installing updated rpms. The server does not need to be shut down in advance. Please note that if you are doing the upgrade in special environment (e.g. FedUp) which does not allow running the LDAP server during upgrade process, upgrade scripts need to be run manually after the first boot: # ipa-ldap-updater --upgrade # ipa-upgradeconfig Also note that the performance improvements require an extended set of indexes to be configured. RPM update for an IPA server with a excessive number of users may require several minutes to finish. If you have multiple servers you may upgrade them one at a time. It is expected that all servers will be upgraded in a relatively short period (days or weeks, not months). They should be able to co-exist peacefully but new features will not be available on old servers and enrolling a new client against an old server will result in the SSH keys not being uploaded. Downgrading a server once upgraded is not supported. Upgrading from 3.3.0 and later versions is supported. Upgrading from previous versions is not supported and has not been tested. An enrolled client does not need the new packages installed unless you want to re-enroll it. SSH keys for already installed clients are not uploaded, you will have to re-enroll the client or manually upload the keys. == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list (http://www.redhat.com/mailman/listinfo/freeipa-users) or #freeipa channel on Freenode. == Detailed Changelog since 4.0.1 == === Alexander Bokovoy (5) === * ipaserver/dcerpc.py: if search of a closest GC failed, try to find any GC * ipaserver/dcerpc.py: make PDC discovery more robust * ipaserver/dcerpc.py: Avoid hitting issue with transitive trusts on Windows Server prior to 2012 * ipaserver/dcerpc.py: be more open to what domains can be seen through the forest trust * ipaserver/dcerpc.py: Make sure trust is established only to forest root domain === David Kupka (7) === * Fix group-remove-member crash when group is removed from a protected group * test group: remove group from protected group. * Verify otptoken timespan is valid * Add record(s) to /etc/host when IPA is configured as DNS server. * Use certmonger D-Bus API instead of messing with its files. * Do not restart apache server when not necessary. * Allow user to force Kerberos realm during installation. === Gabe (1) === * ipa trust-add command should be interactive === Jakub Hrozek (1) === * CLIENT: Explicitly require python-backports-ssl_match_hostname === Jan Cholasta (11) === * Check if /root/ipa.csr exists when installing server with external CA. * Exclude attributelevelrights from --raw result processing in baseldap. * Add test for baseldap.entry_to_dict. * Convert external CA chain to PKCS#7 before passing it to pkispawn. * Allow changing CA renewal master in ipa-csreplica-manage. * Add method for setting CA renewal master in LDAP to CAInstance. * Pick new CA renewal master when deleting a replica. * Normalize external CA cert before passing it to pkispawn * Add new NSSDatabase method get_cert for getting certs from NSS databases. * Make CA-less ipa-server-install option --root-ca-file optional. * Backup CS.cfg before modifying it === Martin Ba?ti (7) === * Fix DNS upgrade plugin should check if DNS container exists * FIX: named_enable_dnssec should verify if DNS is installed * Allow to add host if AAAA record exists * Tests: host tests with dns * Fix dnsrecord-mod raise error if last record attr is removed * FIX DNS wildcard records (RFC4592) * Tests: DNS wildcard records === Martin Ko?ek (2) === * Do not crash client basedn discovery when SSF not met * ipa-adtrust-install does not re-add member in adtrust agents group === Nathaniel McCallum (1) === * Ensure ipaUserAuthTypeClass when needed on user creation === Petr Viktorin (8) === * Update API.txt * test_ipagetkeytab: Fix assertion in negative test * freeipa.spec.in: Add python-backports-ssl_match_hostname to BuildRequires * permission plugin: Make --target available in the CLI * permission plugin: Improve description of the target option * Add managed read permissions for compat tree * Fix: Add managed read permissions for compat tree and operational attrs * Become IPA 4.0.2 === Petr Voborn?k (10) === * webui: support wildcard attribute level rights * webui: fix nested items creation in dropdown list * webui: internet explorer fixes * webui: detach facet nodes * webui: replace action_buttons with action_widget * webui: remove remaining action-button-disabled occurrences * webui-ci: fix reset password check * webui: better error reporting * webui-ci: fix table widget add * webui: extract complex pkey on Add and Edit === Rob Crittenden (1) === * No longer generate a machine certificate on client installs === Stephen Gallagher (1) === * Change BuildRequires for Java === Tom?? Babej (3) === * ipalib: idrange: Make non-implemented range types fail the validation * ipatests: test_trust: Add test to cover lookup of trusdomains * ipa-client-install: Do not add already configured sources to nsswitch.conf entries -- Petr? From anwar.fatayri at hotmail.co.uk Mon Sep 8 13:35:42 2014 From: anwar.fatayri at hotmail.co.uk (Anwar El fatayri) Date: Mon, 8 Sep 2014 15:35:42 +0200 Subject: [Freeipa-users] [freeipa 3.0.0] Changing the DN in the signing request Message-ID: Hello everyone... I'm trying to request SSL Certificates from my machines (ex : vadqualif02) for a specific service (ex : Syslog-ng). I would like to distinguish between my client and server certificates by changing the DN. The problem is that when I try to do that (see the command below), I'm still getting the default DN (CN=hostname). sudo ipa-getcert request -r -f /etc/pki/tls/certs/syslog-ng_vadqualif02.lbg.office.lyra.crt -k /etc/pki/tls/private/syslog-ng_vadqualif02.lbg.office.lyra.key -N OU=toto,CN=roro -K SYSLOG-NG_CLIENT/vadqualif02.lbg.office.lyra at OFFICE.LYRA Any ideas ? Thx in advance. El Fatayri Anwar -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Mon Sep 8 14:08:22 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 08 Sep 2014 10:08:22 -0400 Subject: [Freeipa-users] [freeipa 3.0.0] Changing the DN in the signing request In-Reply-To: References: Message-ID: <540DB856.4020902@redhat.com> Anwar El fatayri wrote: > *Hello everyone...* > * > * > *I'm trying to request SSL Certificates from my machines (ex : > vadqualif02) for a specific service (ex : Syslog-ng).* > * > * > *I would like to distinguish between my client and server certificates > by changing the DN. The problem is that when I try to do that (see the > command below), I'm still getting the default DN (CN=hostname).* > * > * > * > sudo ipa-getcert request -r -f > /etc/pki/tls/certs/syslog-ng_vadqualif02.lbg.office.lyra.crt -k > /etc/pki/tls/private/syslog-ng_vadqualif02.lbg.office.lyra.key -N > OU=toto,CN=roro -K SYSLOG-NG_CLIENT/vadqualif02.lbg.office.lyra at OFFICE.LYRA > > Any ideas ? I'm surprised this isn't just being rejected instead. IPA requires that the CN of the CSR match the host/service being requested for. It will also drop anything other than CN and replace it with the subject of the CA (usually O=EXAMPLE.COM). There is no way around this. rob From aglo at umich.edu Mon Sep 8 19:49:03 2014 From: aglo at umich.edu (Olga Kornievskaia) Date: Mon, 8 Sep 2014 15:49:03 -0400 Subject: [Freeipa-users] freeipa server install fails on fedora 20 Message-ID: Can somebody help with the following problem(s) I?ve encountered while trying to install the freeipa server? Problem #1: On fedora 20, I have: 1. using yum install acquired the free-ipa-server package. 2. ran ipa-server-install ? that has failed with ?CA did not start in 300s? One thing that?s noticeable in the logs (the snippet is included below) is that request for request ' https://ipa1.gateway.2wire.net:443/ca/admin/ca/getStatus' has 443 as port as for before all the requests for 8443 (e.g.., same (manual) request on port 8443 succeeds). Seems like an install script somewhere has the wrong port ? 2014-09-08T19:21:07Z DEBUG Waiting for CA to start... 2014-09-08T19:21:08Z DEBUG request ' https://ipa1.gateway.2wire.net:443/ca/admin/ca/getStatus' 2014-09-08T19:21:08Z DEBUG request body '' 2014-09-08T19:21:08Z DEBUG request status 503 2014-09-08T19:21:08Z DEBUG request reason_phrase u'Service Unavailable' 2014-09-08T19:21:08Z DEBUG request headers {'date': 'Mon, 08 Sep 2014 19:21:08 GMT', 'content-length': '299', 'content-type': 'text/html; charset=iso-8859-1', 'connection': 'close', 'server': 'Apache/2.4.10 (Fedora) mod_auth_kerb/5.4 mod_nss/2.4.6 NSS/3.15.3 Basic ECC mod_wsgi/3.5 Python/2.7.5'}2014-09-08T19:21:08Z DEBUG request body '\n\n503 Service Unavailable\n\n

Service Unavailable

\n

The server is temporarily unable to service your\nrequest due to maintenance downtime or capacity\nproblems. Please try again later.

\n\n' 2014-09-08T19:21:08Z DEBUG The CA status is: Service Unavailable Problem #2: The next problem I?m encountering and doesn?t seem to be related to the CA setup is on the next step of ?kinit admin?. It fails with ?generic pre authentication failure while getting initial credentials" stracing kinit show that it tried to open file ?/var/lib/sss/pubconf/ kdcinfo.GATEWAY.2WIRE.NET ?) and fails with ?no such file? error. ?pubconf? dir only has empty ?krb5.include.d?. I don?t know if this failure is due to the fact that the setup didn?t run all the way and some configuration is missing or this is a separate issue . Are these bugs that need to be filled with bugzilla or am I doing something incorrectly? Any help would be appreciated. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Mon Sep 8 21:50:50 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 08 Sep 2014 17:50:50 -0400 Subject: [Freeipa-users] freeipa server install fails on fedora 20 In-Reply-To: References: Message-ID: <540E24BA.3070803@redhat.com> On 09/08/2014 03:49 PM, Olga Kornievskaia wrote: > Can somebody help with the following problem(s) I've encountered while > trying to install the freeipa server? > > Problem #1: > On fedora 20, I have: > 1. using yum install acquired the free-ipa-server package. > 2. ran ipa-server-install > --- that has failed with "CA did not start in 300s" > > One thing that's noticeable in the logs (the snippet is included > below) is that request for request > 'https://ipa1.gateway.2wire.net:443/ca/admin/ca/getStatus' > > > has 443 as port as for before all the requests for 8443 (e.g.., same > (manual) request on port 8443 succeeds). Seems like an install script > somewhere has the wrong port ? 443 is the right port. Do you have something already running on the same box on that port? That might prevent things from installing and running. Please try on a clean machine or VM. Also more logs will be helpful. Please see this [1] on how to troubleshoot. The second problem is most likely an artifact of the incomplete install. [1] http://www.freeipa.org/page/Troubleshooting > > 2014-09-08T19:21:07Z DEBUG Waiting for CA to start... > > 2014-09-08T19:21:08Z DEBUG request > 'https://ipa1.gateway.2wire.net:443/ca/admin/ca/getStatus' > > 2014-09-08T19:21:08Z DEBUG request body '' > > 2014-09-08T19:21:08Z DEBUG request status 503 > > 2014-09-08T19:21:08Z DEBUG request reason_phrase u'Service Unavailable' > > 2014-09-08T19:21:08Z DEBUG request headers {'date': 'Mon, 08 Sep 2014 > 19:21:08 GMT', 'content-length': '299', 'content-type': 'text/html; > charset=iso-8859-1', 'connection': 'close', 'server': 'Apache/2.4.10 > (Fedora) mod_auth_kerb/5.4 mod_nss/2.4.6 NSS/3.15.3 Basic ECC > mod_wsgi/3.5 Python/2.7.5'}2014-09-08T19:21:08Z DEBUG request body > ' 2.0//EN">\n\n503 Service > Unavailable\n\n

Service > Unavailable

\n

The server is temporarily unable to service > your\nrequest due to maintenance downtime or capacity\nproblems. > Please try again later.

\n\n' > > 2014-09-08T19:21:08Z DEBUG The CA status is: Service Unavailable > > > Problem #2: > The next problem I'm encountering and doesn't seem to be related to > the CA setup is on the next step of "kinit admin". It fails with > "generic pre authentication failure while getting initial credentials" > > stracing kinit show that it tried to open file > "/var/lib/sss/pubconf/kdcinfo.GATEWAY.2WIRE.NET > ") and fails with "no such file" > error. "pubconf" dir only has empty "krb5.include.d". > > I don't know if this failure is due to the fact that the setup didn't > run all the way and some configuration is missing or this is a > separate issue . > > Are these bugs that need to be filled with bugzilla or am I doing > something incorrectly? > > Any help would be appreciated. > > Thank you. > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jreg2k at gmail.com Mon Sep 8 22:52:55 2014 From: jreg2k at gmail.com (James James) Date: Tue, 9 Sep 2014 00:52:55 +0200 Subject: [Freeipa-users] ACI for ipa-getkeytab Message-ID: Hi everybody, I want a user to be able to do ipa-getkeytab to retrieve the keys from any host in the realm. How can I do this ? Where I can find an ACI example ( https://www.redhat.com/archives/freeipa-users/2010-July/msg00024.html) which can helps me ? Thanks for your help. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Mon Sep 8 23:22:30 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 08 Sep 2014 19:22:30 -0400 Subject: [Freeipa-users] ACI for ipa-getkeytab In-Reply-To: References: Message-ID: <540E3A36.8080802@redhat.com> On 09/08/2014 06:52 PM, James James wrote: > Hi everybody, > > I want a user to be able to do ipa-getkeytab to retrieve the keys from > any host in the realm. > > How can I do this ? > > Where I can find an ACI example > (https://www.redhat.com/archives/freeipa-users/2010-July/msg00024.html) which > can helps me ? > > > Thanks for your help. > > > > Which version of IPA? There reason for the question is because in FreeIPA 4.0 the ACIs were significantly reworked. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aglo at umich.edu Mon Sep 8 23:29:54 2014 From: aglo at umich.edu (Olga Kornievskaia) Date: Mon, 8 Sep 2014 19:29:54 -0400 Subject: [Freeipa-users] freeipa server install fails on fedora 20 In-Reply-To: <540E24BA.3070803@redhat.com> References: <540E24BA.3070803@redhat.com> Message-ID: Thank you very much for your quick reply. It is a brand new fedora 20 vm. There is nothing that's running on port 443. catalina.out is empty system file is attached and reports that certificate is not in pkcs11 format. pki-ca-spaw.XX.log does not appear to report errors (also attached) Please let me know if I can enable any other debugging into that might be useful in figuring this out. Thank you. On Mon, Sep 8, 2014 at 5:50 PM, Dmitri Pal wrote: > On 09/08/2014 03:49 PM, Olga Kornievskaia wrote: > > Can somebody help with the following problem(s) I?ve encountered while > trying to install the freeipa server? > > Problem #1: > On fedora 20, I have: > 1. using yum install acquired the free-ipa-server package. > 2. ran ipa-server-install > ? that has failed with ?CA did not start in 300s? > > One thing that?s noticeable in the logs (the snippet is included below) > is that request for request ' > https://ipa1.gateway.2wire.net:443/ca/admin/ca/getStatus' > > > has 443 as port as for before all the requests for 8443 (e.g.., same > (manual) request on port 8443 succeeds). Seems like an install script > somewhere has the wrong port ? > > > 443 is the right port. > Do you have something already running on the same box on that port? > That might prevent things from installing and running. > > Please try on a clean machine or VM. > Also more logs will be helpful. > Please see this [1] on how to troubleshoot. > > The second problem is most likely an artifact of the incomplete install. > > [1] http://www.freeipa.org/page/Troubleshooting > > > 2014-09-08T19:21:07Z DEBUG Waiting for CA to start... > > 2014-09-08T19:21:08Z DEBUG request ' > https://ipa1.gateway.2wire.net:443/ca/admin/ca/getStatus' > > 2014-09-08T19:21:08Z DEBUG request body '' > > 2014-09-08T19:21:08Z DEBUG request status 503 > > 2014-09-08T19:21:08Z DEBUG request reason_phrase u'Service Unavailable' > > 2014-09-08T19:21:08Z DEBUG request headers {'date': 'Mon, 08 Sep 2014 > 19:21:08 GMT', 'content-length': '299', 'content-type': 'text/html; > charset=iso-8859-1', 'connection': 'close', 'server': 'Apache/2.4.10 > (Fedora) mod_auth_kerb/5.4 mod_nss/2.4.6 NSS/3.15.3 Basic ECC mod_wsgi/3.5 > Python/2.7.5'}2014-09-08T19:21:08Z DEBUG request body ' PUBLIC "-//IETF//DTD HTML 2.0//EN">\n\n503 Service > Unavailable\n\n

Service Unavailable

\n

The > server is temporarily unable to service your\nrequest due to maintenance > downtime or capacity\nproblems. Please try again > later.

\n\n' > > 2014-09-08T19:21:08Z DEBUG The CA status is: Service Unavailable > > Problem #2: > The next problem I?m encountering and doesn?t seem to be related to the CA > setup is on the next step of ?kinit admin?. It fails with ?generic pre > authentication failure while getting initial credentials" > > stracing kinit show that it tried to open file ?/var/lib/sss/pubconf/ > kdcinfo.GATEWAY.2WIRE.NET ?) and fails > with ?no such file? error. ?pubconf? dir only has empty ?krb5.include.d?. > > I don?t know if this failure is due to the fact that the setup didn?t > run all the way and some configuration is missing or this is a separate > issue . > > Are these bugs that need to be filled with bugzilla or am I doing > something incorrectly? > > Any help would be appreciated. > > Thank you. > > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki.pki-tomcat.ca.system Type: application/octet-stream Size: 1175 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-ca-spawn.20140908130404.log Type: application/octet-stream Size: 425670 bytes Desc: not available URL: From dpal at redhat.com Mon Sep 8 23:41:57 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 08 Sep 2014 19:41:57 -0400 Subject: [Freeipa-users] freeipa server install fails on fedora 20 In-Reply-To: References: <540E24BA.3070803@redhat.com> Message-ID: <540E3EC5.7050203@redhat.com> On 09/08/2014 07:29 PM, Olga Kornievskaia wrote: > Thank you very much for your quick reply. > > It is a brand new fedora 20 vm. OK good. Can you send or share the ipa server installation log? Are you using a cert from AD and trying to chain to an AD CA? > > There is nothing that's running on port 443. > > catalina.out is empty > system file is attached and reports that certificate is not in pkcs11 > format. > pki-ca-spaw.XX.log does not appear to report errors (also attached) > > Please let me know if I can enable any other debugging into that might > be useful in figuring this out. > > Thank you. > > > On Mon, Sep 8, 2014 at 5:50 PM, Dmitri Pal > wrote: > > On 09/08/2014 03:49 PM, Olga Kornievskaia wrote: >> Can somebody help with the following problem(s) I?ve encountered >> while trying to install the freeipa server? >> >> Problem #1: >> On fedora 20, I have: >> 1. using yum install acquired the free-ipa-server package. >> 2. ran ipa-server-install >> ? that has failed with ?CA did not start in 300s? >> >> One thing that?s noticeable in the logs (the snippet is included >> below) is that request for request >> 'https://ipa1.gateway.2wire.net:443/ca/admin/ca/getStatus' >> >> >> has 443 as port as for before all the requests for 8443 (e.g.., >> same (manual) request on port 8443 succeeds). Seems like an >> install script somewhere has the wrong port ? > > 443 is the right port. > Do you have something already running on the same box on that port? > That might prevent things from installing and running. > > Please try on a clean machine or VM. > Also more logs will be helpful. > Please see this [1] on how to troubleshoot. > > The second problem is most likely an artifact of the incomplete > install. > > [1] http://www.freeipa.org/page/Troubleshooting > >> >> 2014-09-08T19:21:07Z DEBUG Waiting for CA to start... >> >> 2014-09-08T19:21:08Z DEBUG request >> 'https://ipa1.gateway.2wire.net:443/ca/admin/ca/getStatus' >> >> 2014-09-08T19:21:08Z DEBUG request body '' >> >> 2014-09-08T19:21:08Z DEBUG request status 503 >> >> 2014-09-08T19:21:08Z DEBUG request reason_phrase u'Service >> Unavailable' >> >> 2014-09-08T19:21:08Z DEBUG request headers {'date': 'Mon, 08 Sep >> 2014 19:21:08 GMT', 'content-length': '299', 'content-type': >> 'text/html; charset=iso-8859-1', 'connection': 'close', 'server': >> 'Apache/2.4.10 (Fedora) mod_auth_kerb/5.4 mod_nss/2.4.6 >> NSS/3.15.3 Basic ECC mod_wsgi/3.5 >> Python/2.7.5'}2014-09-08T19:21:08Z DEBUG request body '> HTML PUBLIC "-//IETF//DTD HTML >> 2.0//EN">\n\n503 Service >> Unavailable\n\n

Service >> Unavailable

\n

The server is temporarily unable to service >> your\nrequest due to maintenance downtime or capacity\nproblems. >> Please try again later.

\n\n' >> >> 2014-09-08T19:21:08Z DEBUG The CA status is: Service Unavailable >> >> >> Problem #2: >> The next problem I?m encountering and doesn?t seem to be related >> to the CA setup is on the next step of ?kinit admin?. It fails >> with ?generic pre authentication failure while getting initial >> credentials" >> >> stracing kinit show that it tried to open file >> ?/var/lib/sss/pubconf/kdcinfo.GATEWAY.2WIRE.NET >> ?) and fails with ?no such >> file? error. ?pubconf? dir only has empty ?krb5.include.d?. >> >> I don?t know if this failure is due to the fact that the setup >> didn?t run all the way and some configuration is missing or this >> is a separate issue . >> >> Are these bugs that need to be filled with bugzilla or am I doing >> something incorrectly? >> >> Any help would be appreciated. >> >> Thank you. >> >> > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bnordgren at fs.fed.us Tue Sep 9 00:02:31 2014 From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS) Date: Tue, 9 Sep 2014 00:02:31 +0000 Subject: [Freeipa-users] Sane request? Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E7231C5@001FSN2MPN1-044.001f.mgd2.msft.net> Is it sane to request that freeipa store ssh keys for users who come into the environment via a trust? Not all of them, of course, but those who want to store public keys there. My freeipa server is mostly there to manage machines, and users (incl. me) mostly come in over trusts from the corporate AD. It'd sure be nice if I could put my laptop's public key on the freeipa server and use it everywhere. Food for thot. Bryce This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jreg2k at gmail.com Tue Sep 9 07:28:41 2014 From: jreg2k at gmail.com (James James) Date: Tue, 9 Sep 2014 09:28:41 +0200 Subject: [Freeipa-users] ACI for ipa-getkeytab In-Reply-To: <540E3A36.8080802@redhat.com> References: <540E3A36.8080802@redhat.com> Message-ID: My IPA version is 3.0.0 . Thanks 2014-09-09 1:22 GMT+02:00 Dmitri Pal : > On 09/08/2014 06:52 PM, James James wrote: > > Hi everybody, > > I want a user to be able to do ipa-getkeytab to retrieve the keys from > any host in the realm. > > How can I do this ? > > Where I can find an ACI example ( > https://www.redhat.com/archives/freeipa-users/2010-July/msg00024.html) > which can helps me ? > > > Thanks for your help. > > > > > Which version of IPA? > There reason for the question is because in FreeIPA 4.0 the ACIs were > significantly reworked. > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tevfik.ceydeliler at astron.yasar.com.tr Tue Sep 9 07:35:47 2014 From: tevfik.ceydeliler at astron.yasar.com.tr (Tevfik Ceydeliler) Date: Tue, 9 Sep 2014 10:35:47 +0300 Subject: [Freeipa-users] [freeipa 3.0.0] Changing the DN in the signing request In-Reply-To: References: Message-ID: <540EADD3.8080704@astron.yasar.com.tr> Hi, I try to create replica to my IPA Server env. When I try to use : ipa-replica-prepare rep.ipa.grp --ip-address 10.1.1.183 At the end I have an error: ---------------------------- [root at srv ~]# ipa-replica-prepare rep.ipa.grp --ip-address 10.1.1.183 Directory Manager (existing master) password: Preparing replica for rep.ipa.grp from srv.ipa.grp Creating SSL certificate for the Directory Server Creating SSL certificate for the dogtag Directory Server Creating SSL certificate for the Web Server Exporting RA certificate Copying additional files Finalizing configuration Packaging replica information into /var/lib/ipa/replica-info-rep.ipa.grp.gpg Adding DNS records for rep.ipa.grp Could not create forward DNS zone for the replica: Nameserver 'srv.ipa.grp.' does not have a corresponding A/AAAA record ------------------------------ Have you any idea about that? Or , is it an error? 10.1.1.183 is rep.ipa.grp (replica) 101.1.173 is srv.ipa.grp (IPA server)


Bu elektronik postada bulunan tum fikir ve gorusler ve ekindeki dosyalar sadece adres sahip/sahiplerine ait olup, Yasar Toplulugu Sirketleri bu mesajin icerigi ile ilgili olarak hic bir hukuksal sorumlulugu kabul etmez. Eger gonderilmesi dusunulen kisi veya kurulus degilseniz, lutfen gonderen kisiyi derhal haberdar ediniz ve mesaji sisteminizden siliniz.The information contained in this e-mail and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and Yasar Group Companies do not accept legal responsibility for the contents. If you are not the intended recipient, please immediately notify the sender and delete it from your system. From tevfik.ceydeliler at astron.yasar.com.tr Tue Sep 9 07:42:37 2014 From: tevfik.ceydeliler at astron.yasar.com.tr (Tevfik Ceydeliler) Date: Tue, 9 Sep 2014 10:42:37 +0300 Subject: [Freeipa-users] Error cretaing Replica In-Reply-To: <540EADD3.8080704@astron.yasar.com.tr> References: <540EADD3.8080704@astron.yasar.com.tr> Message-ID: <540EAF6D.8040607@astron.yasar.com.tr> Hi, I try to create replica to my IPA Server env. When I try to use : ipa-replica-prepare rep.ipa.grp --ip-address 10.1.1.183 At the end I have an error: ---------------------------- [root at srv ~]# ipa-replica-prepare rep.ipa.grp --ip-address 10.1.1.183 Directory Manager (existing master) password: Preparing replica for rep.ipa.grp from srv.ipa.grp Creating SSL certificate for the Directory Server Creating SSL certificate for the dogtag Directory Server Creating SSL certificate for the Web Server Exporting RA certificate Copying additional files Finalizing configuration Packaging replica information into /var/lib/ipa/replica-info-rep.ipa.grp.gpg Adding DNS records for rep.ipa.grp Could not create forward DNS zone for the replica: Nameserver 'srv.ipa.grp.' does not have a corresponding A/AAAA record ------------------------------ Have you any idea about that? Or , is it an error? 10.1.1.183 is rep.ipa.grp (replica) 101.1.173 is srv.ipa.grp (IPA server)


Bu elektronik postada bulunan tum fikir ve gorusler ve ekindeki dosyalar sadece adres sahip/sahiplerine ait olup, Yasar Toplulugu Sirketleri bu mesajin icerigi ile ilgili olarak hic bir hukuksal sorumlulugu kabul etmez. Eger gonderilmesi dusunulen kisi veya kurulus degilseniz, lutfen gonderen kisiyi derhal haberdar ediniz ve mesaji sisteminizden siliniz.The information contained in this e-mail and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and Yasar Group Companies do not accept legal responsibility for the contents. If you are not the intended recipient, please immediately notify the sender and delete it from your system. From tevfik.ceydeliler at astron.yasar.com.tr Tue Sep 9 08:00:41 2014 From: tevfik.ceydeliler at astron.yasar.com.tr (Tevfik Ceydeliler) Date: Tue, 9 Sep 2014 11:00:41 +0300 Subject: [Freeipa-users] Error cretaing Replica In-Reply-To: <540EAF6D.8040607@astron.yasar.com.tr> References: <540EADD3.8080704@astron.yasar.com.tr> <540EAF6D.8040607@astron.yasar.com.tr> Message-ID: <540EB3A9.5070005@astron.yasar.com.tr> By the way, When i try to ping rep.pa.grp from srv.ipa.grp cant resolve IP address. There is same result when I try to ping srv.ipa.grp from rep.pra.grp Is there a BIND problem? ---- [root at srv ~]# kinit admin Password for admin at IPA.GRP: [root at srv ~]# ping rep.ipa.grp ping: unknown host rep.ipa.grp [root at rep ~]# ping srvipa.grp ping: unknown host srvipa.grp On 09-09-2014 10:42, Tevfik Ceydeliler wrote: > Hi, > I try to create replica to my IPA Server env. > When I try to use : > > ipa-replica-prepare rep.ipa.grp --ip-address 10.1.1.183 > > At the end I have an error: > ---------------------------- > [root at srv ~]# ipa-replica-prepare rep.ipa.grp --ip-address 10.1.1.183 > Directory Manager (existing master) password: > > Preparing replica for rep.ipa.grp from srv.ipa.grp > Creating SSL certificate for the Directory Server > Creating SSL certificate for the dogtag Directory Server > Creating SSL certificate for the Web Server > Exporting RA certificate > Copying additional files > Finalizing configuration > Packaging replica information into > /var/lib/ipa/replica-info-rep.ipa.grp.gpg > Adding DNS records for rep.ipa.grp > > Could not create forward DNS zone for the replica: Nameserver > 'srv.ipa.grp.' does not have a corresponding A/AAAA record > > ------------------------------ > > Have you any idea about that? Or , is it an error? > > 10.1.1.183 is rep.ipa.grp (replica) > 101.1.173 is srv.ipa.grp (IPA server) --


Bu elektronik postada bulunan tum fikir ve gorusler ve ekindeki dosyalar sadece adres sahip/sahiplerine ait olup, Yasar Toplulugu Sirketleri bu mesajin icerigi ile ilgili olarak hic bir hukuksal sorumlulugu kabul etmez. Eger gonderilmesi dusunulen kisi veya kurulus degilseniz, lutfen gonderen kisiyi derhal haberdar ediniz ve mesaji sisteminizden siliniz.The information contained in this e-mail and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and Yasar Group Companies do not accept legal responsibility for the contents. If you are not the intended recipient, please immediately notify the sender and delete it from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.png Type: image/png Size: 15216 bytes Desc: not available URL: From mbasti at redhat.com Tue Sep 9 08:04:04 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 09 Sep 2014 10:04:04 +0200 Subject: [Freeipa-users] ipa-replica-prepare failed - could not create forward DNS zone In-Reply-To: <540EADD3.8080704@astron.yasar.com.tr> References: <540EADD3.8080704@astron.yasar.com.tr> Message-ID: <540EB474.9040806@redhat.com> On 09/09/14 09:35, Tevfik Ceydeliler wrote: > > Hi, > I try to create replica to my IPA Server env. > When I try to use : > > ipa-replica-prepare rep.ipa.grp --ip-address 10.1.1.183 > > At the end I have an error: > ---------------------------- > [root at srv ~]# ipa-replica-prepare rep.ipa.grp --ip-address 10.1.1.183 > Directory Manager (existing master) password: > > Preparing replica for rep.ipa.grp from srv.ipa.grp > Creating SSL certificate for the Directory Server > Creating SSL certificate for the dogtag Directory Server > Creating SSL certificate for the Web Server > Exporting RA certificate > Copying additional files > Finalizing configuration > Packaging replica information into > /var/lib/ipa/replica-info-rep.ipa.grp.gpg > Adding DNS records for rep.ipa.grp > > Could not create forward DNS zone for the replica: Nameserver > 'srv.ipa.grp.' does not have a corresponding A/AAAA record > > ------------------------------ > > Have you any idea about that? Or , is it an error? > > 10.1.1.183 is rep.ipa.grp (replica) > 101.1.173 is srv.ipa.grp (IPA server) Hello, can you resolve the srv.ipa.grp. address? $ dig A srv.ipa.grp. -- Martin Basti From mbasti at redhat.com Tue Sep 9 08:06:37 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 09 Sep 2014 10:06:37 +0200 Subject: [Freeipa-users] Error cretaing Replica In-Reply-To: <540EB3A9.5070005@astron.yasar.com.tr> References: <540EADD3.8080704@astron.yasar.com.tr> <540EAF6D.8040607@astron.yasar.com.tr> <540EB3A9.5070005@astron.yasar.com.tr> Message-ID: <540EB50D.4010208@redhat.com> On 09/09/14 10:00, Tevfik Ceydeliler wrote: > By the way, > When i try to ping rep.pa.grp from srv.ipa.grp cant resolve IP address. > There is same result when I try to ping srv.ipa.grp from rep.pra.grp > > Is there a BIND problem? > > ---- > [root at srv ~]# kinit admin > Password for admin at IPA.GRP: > [root at srv ~]# ping rep.ipa.grp > ping: unknown host rep.ipa.grp > > > [root at rep ~]# ping srvipa.grp > ping: unknown host srvipa.grp Hi, this command shows status of ipa services, check named service # ipactl status > > > > On 09-09-2014 10:42, Tevfik Ceydeliler wrote: >> Hi, >> I try to create replica to my IPA Server env. >> When I try to use : >> >> ipa-replica-prepare rep.ipa.grp --ip-address 10.1.1.183 >> >> At the end I have an error: >> ---------------------------- >> [root at srv ~]# ipa-replica-prepare rep.ipa.grp --ip-address 10.1.1.183 >> Directory Manager (existing master) password: >> >> Preparing replica for rep.ipa.grp from srv.ipa.grp >> Creating SSL certificate for the Directory Server >> Creating SSL certificate for the dogtag Directory Server >> Creating SSL certificate for the Web Server >> Exporting RA certificate >> Copying additional files >> Finalizing configuration >> Packaging replica information into >> /var/lib/ipa/replica-info-rep.ipa.grp.gpg >> Adding DNS records for rep.ipa.grp >> >> Could not create forward DNS zone for the replica: Nameserver >> 'srv.ipa.grp.' does not have a corresponding A/AAAA record >> >> ------------------------------ >> >> Have you any idea about that? Or , is it an error? >> >> 10.1.1.183 is rep.ipa.grp (replica) >> 101.1.173 is srv.ipa.grp (IPA server) > > -- > > > > > > > Bu elektronik postada bulunan tum fikir ve gorusler ve ekindeki > dosyalar sadece adres sahip/sahiplerine ait olup, Yasar Toplulugu > Sirketleri bu mesajin icerigi ile ilgili olarak hic bir hukuksal > sorumlulugu kabul etmez. Eger gonderilmesi dusunulen kisi veya kurulus > degilseniz, lutfen gonderen kisiyi derhal haberdar ediniz ve mesaji > sisteminizden siliniz.The information contained in this e-mail and any > files transmitted with it are intended solely for the use of the > individual or entity to whom they are addressed and Yasar Group > Companies do not accept legal responsibility for the contents. If you > are not the intended recipient, please immediately notify the sender > and delete it from your system. > > > -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 15216 bytes Desc: not available URL: From tevfik.ceydeliler at astron.yasar.com.tr Tue Sep 9 08:29:16 2014 From: tevfik.ceydeliler at astron.yasar.com.tr (Tevfik Ceydeliler) Date: Tue, 9 Sep 2014 11:29:16 +0300 Subject: [Freeipa-users] Error cretaing Replica In-Reply-To: <540EB3A9.5070005@astron.yasar.com.tr> References: <540EADD3.8080704@astron.yasar.com.tr> <540EAF6D.8040607@astron.yasar.com.tr> <540EB3A9.5070005@astron.yasar.com.tr> Message-ID: <540EBA5C.3080200@astron.yasar.com.tr> Another symptom is : -- [root at srv ~]# service named status rndc: connect failed: 127.0.0.1#953: connection refused named dead but pid file exists --- On 09-09-2014 11:00, Tevfik Ceydeliler wrote: > By the way, > When i try to ping rep.pa.grp from srv.ipa.grp cant resolve IP address. > There is same result when I try to ping srv.ipa.grp from rep.pra.grp > > Is there a BIND problem? > > ---- > [root at srv ~]# kinit admin > Password for admin at IPA.GRP: > [root at srv ~]# ping rep.ipa.grp > ping: unknown host rep.ipa.grp > > > [root at rep ~]# ping srvipa.grp > ping: unknown host srvipa.grp > > > > On 09-09-2014 10:42, Tevfik Ceydeliler wrote: >> Hi, >> I try to create replica to my IPA Server env. >> When I try to use : >> >> ipa-replica-prepare rep.ipa.grp --ip-address 10.1.1.183 >> >> At the end I have an error: >> ---------------------------- >> [root at srv ~]# ipa-replica-prepare rep.ipa.grp --ip-address 10.1.1.183 >> Directory Manager (existing master) password: >> >> Preparing replica for rep.ipa.grp from srv.ipa.grp >> Creating SSL certificate for the Directory Server >> Creating SSL certificate for the dogtag Directory Server >> Creating SSL certificate for the Web Server >> Exporting RA certificate >> Copying additional files >> Finalizing configuration >> Packaging replica information into >> /var/lib/ipa/replica-info-rep.ipa.grp.gpg >> Adding DNS records for rep.ipa.grp >> >> Could not create forward DNS zone for the replica: Nameserver >> 'srv.ipa.grp.' does not have a corresponding A/AAAA record >> >> ------------------------------ >> >> Have you any idea about that? Or , is it an error? >> >> 10.1.1.183 is rep.ipa.grp (replica) >> 101.1.173 is srv.ipa.grp (IPA server) > > -- --


Bu elektronik postada bulunan tum fikir ve gorusler ve ekindeki dosyalar sadece adres sahip/sahiplerine ait olup, Yasar Toplulugu Sirketleri bu mesajin icerigi ile ilgili olarak hic bir hukuksal sorumlulugu kabul etmez. Eger gonderilmesi dusunulen kisi veya kurulus degilseniz, lutfen gonderen kisiyi derhal haberdar ediniz ve mesaji sisteminizden siliniz.The information contained in this e-mail and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and Yasar Group Companies do not accept legal responsibility for the contents. If you are not the intended recipient, please immediately notify the sender and delete it from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 15216 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.png Type: image/png Size: 15216 bytes Desc: not available URL: From mbasti at redhat.com Tue Sep 9 08:37:13 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 09 Sep 2014 10:37:13 +0200 Subject: [Freeipa-users] Error cretaing Replica In-Reply-To: <540EBA5C.3080200@astron.yasar.com.tr> References: <540EADD3.8080704@astron.yasar.com.tr> <540EAF6D.8040607@astron.yasar.com.tr> <540EB3A9.5070005@astron.yasar.com.tr> <540EBA5C.3080200@astron.yasar.com.tr> Message-ID: <540EBC39.5020607@redhat.com> On 09/09/14 10:29, Tevfik Ceydeliler wrote: > Another symptom is : > -- > [root at srv ~]# service named status > rndc: connect failed: 127.0.0.1#953: connection refused > named dead but pid file exists > --- > Please send logs, why bind failed. journalctl -u named And restart named > On 09-09-2014 11:00, Tevfik Ceydeliler wrote: >> By the way, >> When i try to ping rep.pa.grp from srv.ipa.grp cant resolve IP address. >> There is same result when I try to ping srv.ipa.grp from rep.pra.grp >> >> Is there a BIND problem? >> >> ---- >> [root at srv ~]# kinit admin >> Password for admin at IPA.GRP: >> [root at srv ~]# ping rep.ipa.grp >> ping: unknown host rep.ipa.grp >> >> >> [root at rep ~]# ping srvipa.grp >> ping: unknown host srvipa.grp >> >> >> >> On 09-09-2014 10:42, Tevfik Ceydeliler wrote: >>> Hi, >>> I try to create replica to my IPA Server env. >>> When I try to use : >>> >>> ipa-replica-prepare rep.ipa.grp --ip-address 10.1.1.183 >>> >>> At the end I have an error: >>> ---------------------------- >>> [root at srv ~]# ipa-replica-prepare rep.ipa.grp --ip-address 10.1.1.183 >>> Directory Manager (existing master) password: >>> >>> Preparing replica for rep.ipa.grp from srv.ipa.grp >>> Creating SSL certificate for the Directory Server >>> Creating SSL certificate for the dogtag Directory Server >>> Creating SSL certificate for the Web Server >>> Exporting RA certificate >>> Copying additional files >>> Finalizing configuration >>> Packaging replica information into >>> /var/lib/ipa/replica-info-rep.ipa.grp.gpg >>> Adding DNS records for rep.ipa.grp >>> >>> Could not create forward DNS zone for the replica: Nameserver >>> 'srv.ipa.grp.' does not have a corresponding A/AAAA record >>> >>> ------------------------------ >>> >>> Have you any idea about that? Or , is it an error? >>> >>> 10.1.1.183 is rep.ipa.grp (replica) >>> 101.1.173 is srv.ipa.grp (IPA server) >> >> -- > > -- > > > > > > > Bu elektronik postada bulunan tum fikir ve gorusler ve ekindeki > dosyalar sadece adres sahip/sahiplerine ait olup, Yasar Toplulugu > Sirketleri bu mesajin icerigi ile ilgili olarak hic bir hukuksal > sorumlulugu kabul etmez. Eger gonderilmesi dusunulen kisi veya kurulus > degilseniz, lutfen gonderen kisiyi derhal haberdar ediniz ve mesaji > sisteminizden siliniz.The information contained in this e-mail and any > files transmitted with it are intended solely for the use of the > individual or entity to whom they are addressed and Yasar Group > Companies do not accept legal responsibility for the contents. If you > are not the intended recipient, please immediately notify the sender > and delete it from your system. > > > -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 15216 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 15216 bytes Desc: not available URL: From tevfik.ceydeliler at astron.yasar.com.tr Tue Sep 9 08:55:16 2014 From: tevfik.ceydeliler at astron.yasar.com.tr (Tevfik Ceydeliler) Date: Tue, 9 Sep 2014 11:55:16 +0300 Subject: [Freeipa-users] Error cretaing Replica In-Reply-To: <540EBA5C.3080200@astron.yasar.com.tr> References: <540EADD3.8080704@astron.yasar.com.tr> <540EAF6D.8040607@astron.yasar.com.tr> <540EB3A9.5070005@astron.yasar.com.tr> <540EBA5C.3080200@astron.yasar.com.tr> Message-ID: <540EC074.1020409@astron.yasar.com.tr> Finally Found solution. check the file /etc/sysconfig/named and comment #ROOTDIR="/var/named/chroot" line. And restart named service On 09-09-2014 11:29, Tevfik Ceydeliler wrote: > Another symptom is : > -- > [root at srv ~]# service named status > rndc: connect failed: 127.0.0.1#953: connection refused > named dead but pid file exists > --- > > On 09-09-2014 11:00, Tevfik Ceydeliler wrote: >> By the way, >> When i try to ping rep.pa.grp from srv.ipa.grp cant resolve IP address. >> There is same result when I try to ping srv.ipa.grp from rep.pra.grp >> >> Is there a BIND problem? >> >> ---- >> [root at srv ~]# kinit admin >> Password for admin at IPA.GRP: >> [root at srv ~]# ping rep.ipa.grp >> ping: unknown host rep.ipa.grp >> >> >> [root at rep ~]# ping srvipa.grp >> ping: unknown host srvipa.grp >> >> >> >> On 09-09-2014 10:42, Tevfik Ceydeliler wrote: >>> Hi, >>> I try to create replica to my IPA Server env. >>> When I try to use : >>> >>> ipa-replica-prepare rep.ipa.grp --ip-address 10.1.1.183 >>> >>> At the end I have an error: >>> ---------------------------- >>> [root at srv ~]# ipa-replica-prepare rep.ipa.grp --ip-address 10.1.1.183 >>> Directory Manager (existing master) password: >>> >>> Preparing replica for rep.ipa.grp from srv.ipa.grp >>> Creating SSL certificate for the Directory Server >>> Creating SSL certificate for the dogtag Directory Server >>> Creating SSL certificate for the Web Server >>> Exporting RA certificate >>> Copying additional files >>> Finalizing configuration >>> Packaging replica information into >>> /var/lib/ipa/replica-info-rep.ipa.grp.gpg >>> Adding DNS records for rep.ipa.grp >>> >>> Could not create forward DNS zone for the replica: Nameserver >>> 'srv.ipa.grp.' does not have a corresponding A/AAAA record >>> >>> ------------------------------ >>> >>> Have you any idea about that? Or , is it an error? >>> >>> 10.1.1.183 is rep.ipa.grp (replica) >>> 101.1.173 is srv.ipa.grp (IPA server) >> >> -- > > -- --


Bu elektronik postada bulunan tum fikir ve gorusler ve ekindeki dosyalar sadece adres sahip/sahiplerine ait olup, Yasar Toplulugu Sirketleri bu mesajin icerigi ile ilgili olarak hic bir hukuksal sorumlulugu kabul etmez. Eger gonderilmesi dusunulen kisi veya kurulus degilseniz, lutfen gonderen kisiyi derhal haberdar ediniz ve mesaji sisteminizden siliniz.The information contained in this e-mail and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and Yasar Group Companies do not accept legal responsibility for the contents. If you are not the intended recipient, please immediately notify the sender and delete it from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 15216 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 15216 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.png Type: image/png Size: 15216 bytes Desc: not available URL: From natxo.asenjo at gmail.com Tue Sep 9 09:12:25 2014 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Tue, 9 Sep 2014 11:12:25 +0200 Subject: [Freeipa-users] Solaris 10 client auth (ssh + kerberos) not working In-Reply-To: <540D7A6A.4030202@gmail.com> References: <540D7A6A.4030202@gmail.com> Message-ID: On Mon, Sep 8, 2014 at 11:44 AM, Gerardo Padierna wrote: > Hello folks, > hi, I'm setting up an IPA-server instance aimed to be used primarily for > Linux/Unix clients ssh authentication (with kerberos). > I've managed to successfully set up debian clients (via sssd and also on > older debians, through libnss and pam_krb5). But for some reason I can't > authenticate ssh on Solaris10 clients. > On the Solaris box, I've followed the steps outiined here: > http://www.freeipa.org/page/ConfiguringUnixClients > and the nss part works fine (things like getent [group | passwd] and id > work), but unfortunaltely, the ssh user authentication fails with an > error: > sshd auth.error PAM-KRB5 (auth): krb5_verify_init_creds failed: No such > file or directory > > On the solaris clients, does there need to be a keytab in /etc/krb5/ > directory copied over from the IPA server? > I have integrated omnios (open solaris derivative) with ipa using these notes: http://test.asenjo.nl/index.php/Omnios_ipa_client that info may or may not be useful for solaris 10 as I have zero experiece with older solaris versions. But in principle, yes, you need a host keytab to login using kerberos SSO. HTH. -- Regards, natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From asl.gerardo at gmail.com Tue Sep 9 10:19:37 2014 From: asl.gerardo at gmail.com (Gerardo Padierna) Date: Tue, 09 Sep 2014 12:19:37 +0200 Subject: [Freeipa-users] Solaris 10 client auth (ssh + kerberos) not working In-Reply-To: <1410173371.15200.YahooMailNeo@web161501.mail.bf1.yahoo.com> References: <540D7A6A.4030202@gmail.com> <1410173371.15200.YahooMailNeo@web161501.mail.bf1.yahoo.com> Message-ID: <540ED439.8060800@gmail.com> Hi Mohammad, This is for Solaris 11; it seems that some of the options for the pam.conf file are not available in Solaris 10 (I think it was the following options: auth definitive pam_user_policy.so.1 account required pam_tsol_account.so.1 password required pam_authtok_store.so.1 ... had to remove them from the pam.conf file..) Still didn't get the ssh auth to work... This may be a stupid question, but do you know if the keytab file must be _exactly_ the same as in the IPA server, or does it only need to contain the entries relevant for the (solaris) client? According to the link you're pointing me to, it seems to just take from the server keytab file those entries relevant for the client, create a new keytab file with that content, and copy it over to the client. Is such a 'stipped down' keytab file supposed to work for the client's auth? Regards, Gerardo El 08/09/14 a las #4, mohammad sereshki escribi?: > > hi > Please go ahead with below structure, It works! > > > Re: [Freeipa-users] Does Solaris 11 work as client to IPA server? > > > > > > Re: [Freeipa-users] Does Solaris 11 work as client to IPA server? > > > [Date Prev][Date Next] [Thread Prev][Thread Next] [Thread Index] > [Date Index] [Author Index] Re: [Freeipa-users] Does Solaris 11 work > as client to IPA server? > > View on www.redhat.com > > > Preview by Yahoo > > > ------------------------------------------------------------------------ > *From:* Gerardo Padierna > *To:* freeipa-users at redhat.com > *Sent:* Monday, September 8, 2014 2:14 PM > *Subject:* [Freeipa-users] Solaris 10 client auth (ssh + kerberos) not > working > > Hello folks, > > I'm setting up an IPA-server instance aimed to be used primarily for > Linux/Unix clients ssh authentication (with kerberos). > I've managed to successfully set up debian clients (via sssd and also > on older debians, through libnss and pam_krb5). But for some reason I > can't authenticate ssh on Solaris10 clients. > On the Solaris box, I've followed the steps outiined here: > http://www.freeipa.org/page/ConfiguringUnixClients > and the nss part works fine (things like getent [group | passwd] and > id work), but unfortunaltely, the ssh user authentication fails > with an error: > sshd auth.error PAM-KRB5 (auth): krb5_verify_init_creds failed: No > such file or directory > > On the solaris clients, does there need to be a keytab in /etc/krb5/ > directory copied over from the IPA server? (I didn't have to set up a > keytab file fo the legacy debian clients, and in the solaris-clients > doc previously mentioned, there's no mention of it). Well, since I > read somewhere the keytab file need to be there, I copied it over from > the IPA server to the solaris clients, Then I get a different error: > PAM-KRB5 (auth): krb5_verify_init_creds failed: Key table entry not found > > This error seems to indicate that there isn't an matching entry found > in the keytab file, so I added an entry for the solaris client, but > I'm still getting the same 'Key table entry not found' error (it could > be the entry I added is wrong, of course). But, for now, just want to > be sure: On the solaris clients, do I need an /etc/krb5/krb5.keytab > file? (if yes, why not in the non-sssd Debian hosts then?) > > Thanks in advance, > -- > *Gerardo Padierna Nanclares* > T?cnico de Sistemas (grupo ASL) - [Fujitsu / Logware] > Servicio de Sistemas de la Informaci?n (DGTI) - Generalitat Valenciana > C/.Castan Tobe?as 77 ? 46018 Valencia ? Edificio A > Tel: 961 208973 > Email: asl.gerardo at gmail.com > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > -- *Gerardo Padierna Nanclares* T?cnico de Sistemas (grupo ASL) - [Fujitsu / Logware] Servicio de Sistemas de la Informaci?n (DGTI) - Generalitat Valenciana C/.Castan Tobe?as 77 ? 46018 Valencia ? Edificio A Tel: 961 208973 Email: asl.gerardo at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicklas.bjork at skalarit.se Tue Sep 9 12:52:59 2014 From: nicklas.bjork at skalarit.se (=?UTF-8?B?Tmlja2xhcyBCasO2cms=?=) Date: Tue, 09 Sep 2014 14:52:59 +0200 Subject: [Freeipa-users] RHEL 7 Upgrade experience so far In-Reply-To: <53FEEF4B.2070307@skalarit.se> References: <53FEEF4B.2070307@skalarit.se> Message-ID: <540EF82B.4060507@skalarit.se> On 2014-08-28 10:58, Nicklas Bj?rk wrote: > 2014-08-27T14:45:19Z DEBUG stderr=pkispawn : WARNING ....... unable > to validate security domain user/password through REST interface. > Interface not available Digging a bit further I found the following in /var/lib/pki-ca/logs/debug on the FreeIPA master. All lines share the common prefix [09/Sep/2014:14:30:27][TP-Processor6]. CMSServlet:service() uri = /ca/agent/ca/updateDomainXML CMSServlet::service() param name='name' value='"/var/lib/pki/pki-tomcat"' CMSServlet::service() param name='ncsport' value='8443' CMSServlet::service() param name='sport' value='None' CMSServlet::service() param name='operation' value='remove' CMSServlet::service() param name='adminsport' value='8443' CMSServlet::service() param name='list' value='caList' CMSServlet::service() param name='type' value='CA' CMSServlet::service() param name='agentsport' value='8443' CMSServlet::service() param name='host' value='replica.example.net' CMSServlet: caUpdateDomainXML start to service. UpdateDomainXML: processing... UpdateDomainXML process: authentication starts IP: 192.168.1.20 AuthMgrName: certUserDBAuthMgr CMSServlet: retrieving SSL certificate CMSServlet: certUID=CN=CA Subsystem,O=EXAMPLE.NET CertUserDBAuth: started CertUserDBAuth: Retrieving client certificate CertUserDBAuth: Got client certificate Authentication: client certificate found In LdapBoundConnFactory::getConn() masterConn is connected: true getConn: conn is connected true getConn: mNumConns now 2 returnConn: mNumConns now 3 SignedAuditEventFactory: create() message=[AuditEvent=AUTH_FAIL][SubjectID=$Unidentified$][Outcome=Failure][AuthMgr=certUserDBAuthMgr][AttemptedCred=CN=CA Subsystem,O=EXAMPLE.NET] authentication failure CMSServlet: curDate=Tue Sep 09 14:30:27 CEST 2014 id=caUpdateDomainXML time=5 What kind of authentication is it complaining about, and is it possible to repair it? Nicklas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 246 bytes Desc: OpenPGP digital signature URL: From rcritten at redhat.com Tue Sep 9 14:14:29 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 09 Sep 2014 10:14:29 -0400 Subject: [Freeipa-users] ACI for ipa-getkeytab In-Reply-To: References: <540E3A36.8080802@redhat.com> Message-ID: <540F0B45.5060304@redhat.com> James James wrote: > My IPA version is 3.0.0 . > Thanks The permission 'Manage host keytab' should do the trick. rob > > 2014-09-09 1:22 GMT+02:00 Dmitri Pal >: > > On 09/08/2014 06:52 PM, James James wrote: >> Hi everybody, >> >> I want a user to be able to do ipa-getkeytab to retrieve the keys >> from any host in the realm. >> >> How can I do this ? >> >> Where I can find an ACI example >> (https://www.redhat.com/archives/freeipa-users/2010-July/msg00024.html) >> which can helps me ? >> >> >> Thanks for your help. >> >> >> >> > Which version of IPA? > There reason for the question is because in FreeIPA 4.0 the ACIs > were significantly reworked. > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > > > > From aglo at umich.edu Tue Sep 9 14:28:19 2014 From: aglo at umich.edu (Olga Kornievskaia) Date: Tue, 9 Sep 2014 10:28:19 -0400 Subject: [Freeipa-users] freeipa server install fails on fedora 20 In-Reply-To: <540E3EC5.7050203@redhat.com> References: <540E24BA.3070803@redhat.com> <540E3EC5.7050203@redhat.com> Message-ID: On Mon, Sep 8, 2014 at 7:41 PM, Dmitri Pal wrote: > On 09/08/2014 07:29 PM, Olga Kornievskaia wrote: > > Thank you very much for your quick reply. > > It is a brand new fedora 20 vm. > > > OK good. > Can you send or share the ipa server installation log? > Can you please suggest how I can do that? My original post was rejected by the administrator of this list because I've included the install log that compressed was over 5M. > Are you using a cert from AD and trying to chain to an AD CA? > I'm not specifying any cert options on the install command (i.e. I'm using the default certs supplied with the install). > > > > > There is nothing that's running on port 443. > > catalina.out is empty > system file is attached and reports that certificate is not in pkcs11 > format. > pki-ca-spaw.XX.log does not appear to report errors (also attached) > > Please let me know if I can enable any other debugging into that might > be useful in figuring this out. > > Thank you. > > > On Mon, Sep 8, 2014 at 5:50 PM, Dmitri Pal wrote: > >> On 09/08/2014 03:49 PM, Olga Kornievskaia wrote: >> >> Can somebody help with the following problem(s) I?ve encountered while >> trying to install the freeipa server? >> >> Problem #1: >> On fedora 20, I have: >> 1. using yum install acquired the free-ipa-server package. >> 2. ran ipa-server-install >> ? that has failed with ?CA did not start in 300s? >> >> One thing that?s noticeable in the logs (the snippet is included below) >> is that request for request ' >> https://ipa1.gateway.2wire.net:443/ca/admin/ca/getStatus' >> >> >> has 443 as port as for before all the requests for 8443 (e.g.., same >> (manual) request on port 8443 succeeds). Seems like an install script >> somewhere has the wrong port ? >> >> >> 443 is the right port. >> Do you have something already running on the same box on that port? >> That might prevent things from installing and running. >> >> Please try on a clean machine or VM. >> Also more logs will be helpful. >> Please see this [1] on how to troubleshoot. >> >> The second problem is most likely an artifact of the incomplete install. >> >> [1] http://www.freeipa.org/page/Troubleshooting >> >> >> 2014-09-08T19:21:07Z DEBUG Waiting for CA to start... >> >> 2014-09-08T19:21:08Z DEBUG request ' >> https://ipa1.gateway.2wire.net:443/ca/admin/ca/getStatus' >> >> 2014-09-08T19:21:08Z DEBUG request body '' >> >> 2014-09-08T19:21:08Z DEBUG request status 503 >> >> 2014-09-08T19:21:08Z DEBUG request reason_phrase u'Service Unavailable' >> >> 2014-09-08T19:21:08Z DEBUG request headers {'date': 'Mon, 08 Sep 2014 >> 19:21:08 GMT', 'content-length': '299', 'content-type': 'text/html; >> charset=iso-8859-1', 'connection': 'close', 'server': 'Apache/2.4.10 >> (Fedora) mod_auth_kerb/5.4 mod_nss/2.4.6 NSS/3.15.3 Basic ECC mod_wsgi/3.5 >> Python/2.7.5'}2014-09-08T19:21:08Z DEBUG request body '> PUBLIC "-//IETF//DTD HTML 2.0//EN">\n\n503 Service >> Unavailable\n\n

Service Unavailable

\n

The >> server is temporarily unable to service your\nrequest due to maintenance >> downtime or capacity\nproblems. Please try again >> later.

\n\n' >> >> 2014-09-08T19:21:08Z DEBUG The CA status is: Service Unavailable >> >> Problem #2: >> The next problem I?m encountering and doesn?t seem to be related to the >> CA setup is on the next step of ?kinit admin?. It fails with ?generic pre >> authentication failure while getting initial credentials" >> >> stracing kinit show that it tried to open file ?/var/lib/sss/pubconf/ >> kdcinfo.GATEWAY.2WIRE.NET ?) and >> fails with ?no such file? error. ?pubconf? dir only has empty >> ?krb5.include.d?. >> >> I don?t know if this failure is due to the fact that the setup didn?t >> run all the way and some configuration is missing or this is a separate >> issue . >> >> Are these bugs that need to be filled with bugzilla or am I doing >> something incorrectly? >> >> Any help would be appreciated. >> >> Thank you. >> >> >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go To http://freeipa.org for more info on the project >> > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From uncommonkat at gmail.com Tue Sep 9 14:39:53 2014 From: uncommonkat at gmail.com (Kat) Date: Tue, 09 Sep 2014 07:39:53 -0700 Subject: [Freeipa-users] unhappy replication? Message-ID: <540F1139.8050604@gmail.com> Anyone seen this before -- 2 freshly kicked CentOS 7 installs: On the replica from the ipa-replica-install : 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. and then the errors file for 389-ds "The remote replica has a different database generation ID than the local database. You may have to reinitialize the remote replica, or the local replica." ~K From rcritten at redhat.com Tue Sep 9 14:41:07 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 09 Sep 2014 10:41:07 -0400 Subject: [Freeipa-users] freeipa server install fails on fedora 20 In-Reply-To: References: <540E24BA.3070803@redhat.com> <540E3EC5.7050203@redhat.com> Message-ID: <540F1183.3010607@redhat.com> Olga Kornievskaia wrote: > > > On Mon, Sep 8, 2014 at 7:41 PM, Dmitri Pal > wrote: > > On 09/08/2014 07:29 PM, Olga Kornievskaia wrote: >> Thank you very much for your quick reply. >> >> It is a brand new fedora 20 vm. > > OK good. > Can you send or share the ipa server installation log? > > > Can you please suggest how I can do that? My original post was rejected > by the administrator of this list because I've included the install log > that compressed was over 5M. If you have a web/ftp server available you can put it there for download. I'd look at the catalina.* logs in /var/log/pki/pki-tomcat and debug in the ca subdirectory. Those are more likely to hold startup failures. journalctl may hold information on why it didn't start too. Incidentally, the second problem is likely related to the first. The installation didn't succeed so the system state is indeterminate. rob > > > Are you using a cert from AD and trying to chain to an AD CA? > > > I'm not specifying any cert options on the install command (i.e. I'm > using the default certs supplied with the install). > > > > > > >> >> There is nothing that's running on port 443. >> >> catalina.out is empty >> system file is attached and reports that certificate is not in >> pkcs11 format. >> pki-ca-spaw.XX.log does not appear to report errors (also attached) >> >> Please let me know if I can enable any other debugging into that >> might be useful in figuring this out. >> >> Thank you. >> >> >> On Mon, Sep 8, 2014 at 5:50 PM, Dmitri Pal > > wrote: >> >> On 09/08/2014 03:49 PM, Olga Kornievskaia wrote: >>> Can somebody help with the following problem(s) I?ve >>> encountered while trying to install the freeipa server? >>> >>> Problem #1: >>> On fedora 20, I have: >>> 1. using yum install acquired the free-ipa-server package. >>> 2. ran ipa-server-install >>> ? that has failed with ?CA did not start in 300s? >>> >>> One thing that?s noticeable in the logs (the snippet is >>> included below) is that request for request >>> 'https://ipa1.gateway.2wire.net:443/ca/admin/ca/getStatus' >>> >>> >>> has 443 as port as for before all the requests for 8443 >>> (e.g.., same (manual) request on port 8443 succeeds). Seems >>> like an install script somewhere has the wrong port ? >> >> 443 is the right port. >> Do you have something already running on the same box on that >> port? >> That might prevent things from installing and running. >> >> Please try on a clean machine or VM. >> Also more logs will be helpful. >> Please see this [1] on how to troubleshoot. >> >> The second problem is most likely an artifact of the >> incomplete install. >> >> [1] http://www.freeipa.org/page/Troubleshooting >> >>> >>> 2014-09-08T19:21:07Z DEBUG Waiting for CA to start... >>> >>> 2014-09-08T19:21:08Z DEBUG request >>> 'https://ipa1.gateway.2wire.net:443/ca/admin/ca/getStatus' >>> >>> 2014-09-08T19:21:08Z DEBUG request body '' >>> >>> 2014-09-08T19:21:08Z DEBUG request status 503 >>> >>> 2014-09-08T19:21:08Z DEBUG request reason_phrase u'Service >>> Unavailable' >>> >>> 2014-09-08T19:21:08Z DEBUG request headers {'date': 'Mon, 08 >>> Sep 2014 19:21:08 GMT', 'content-length': '299', >>> 'content-type': 'text/html; charset=iso-8859-1', >>> 'connection': 'close', 'server': 'Apache/2.4.10 (Fedora) >>> mod_auth_kerb/5.4 mod_nss/2.4.6 NSS/3.15.3 Basic ECC >>> mod_wsgi/3.5 Python/2.7.5'}2014-09-08T19:21:08Z DEBUG request >>> body '>> 2.0//EN">\n\n503 Service >>> Unavailable\n\n

Service >>> Unavailable

\n

The server is temporarily unable to >>> service your\nrequest due to maintenance downtime or >>> capacity\nproblems. Please try again >>> later.

\n\n' >>> >>> 2014-09-08T19:21:08Z DEBUG The CA status is: Service Unavailable >>> >>> >>> Problem #2: >>> The next problem I?m encountering and doesn?t seem to be >>> related to the CA setup is on the next step of ?kinit admin?. >>> It fails with ?generic pre authentication failure while >>> getting initial credentials" >>> >>> stracing kinit show that it tried to open file >>> ?/var/lib/sss/pubconf/kdcinfo.GATEWAY.2WIRE.NET >>> ?) and fails with ?no such >>> file? error. ?pubconf? dir only has empty ?krb5.include.d?. >>> >>> I don?t know if this failure is due to the fact that the >>> setup didn?t run all the way and some configuration is >>> missing or this is a separate issue . >>> >>> Are these bugs that need to be filled with bugzilla or am I >>> doing something incorrectly? >>> >>> Any help would be appreciated. >>> >>> Thank you. >>> >>> >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go To http://freeipa.org for more info on the project >> >> > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > > From rmeggins at redhat.com Tue Sep 9 14:56:48 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 09 Sep 2014 08:56:48 -0600 Subject: [Freeipa-users] unhappy replication? In-Reply-To: <540F1139.8050604@gmail.com> References: <540F1139.8050604@gmail.com> Message-ID: <540F1530.2040309@redhat.com> On 09/09/2014 08:39 AM, Kat wrote: > Anyone seen this before -- 2 freshly kicked CentOS 7 installs: > > On the replica from the ipa-replica-install : > > 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. Is it possible that the replica was being initialized by another replica, or you tried to initialize it again while a replica init was already running? Error 10 Referral is returned by a replica when you attempt an ldap operation against it while it is being initialized i.e. the database is locked, so any other operation gets a "busy signal" and a referral to another replica. > > and then the errors file for 389-ds > > "The remote replica has a different database generation ID than the > local database. You may have to reinitialize the remote replica, or > the local replica." This just means the replica has not been initialized yet. > > ~K > From rcritten at redhat.com Tue Sep 9 14:59:57 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 09 Sep 2014 10:59:57 -0400 Subject: [Freeipa-users] ACI for ipa-getkeytab In-Reply-To: References: <540E3A36.8080802@redhat.com> <540F0B45.5060304@redhat.com> Message-ID: <540F15ED.9080302@redhat.com> James James wrote: > My user : realm-proxy is in a group (Smart Proxy Host Management) which > has the Manager host keytab permission : > > Permission name: Manage host keytab > Permissions: write > Attributes: krbprincipalkey, krblastpwdchange > Type: host > Granted to Privilege: Host Administrators, Host Enrollment, Smart > Proxy Host Management > > > When I try to retreive a keytab from another host when my principal is > the realm-proxy : > > > [root at client1 ~]# kinit realm-proxy at EXAMPLE.COM > -k -t /tmp/freeipa.keytab > > [root at client1 ~]# klist > > Ticket cache: KEYRING:persistent:0:0 > Default principal: realm-proxy at EXAMPLE.COM > > Valid starting Expires Service principal > 09/09/2014 14:35:50 09/10/2014 14:35:50 krbtgt/EXAMPLE.COM at EXAMPLE.COM > > > [root at client1 ~]# ipa-getkeytab --server=ipa.example.com > --principal=host/client1.example.com > --keytab=/etc/krb5.keytab > Operation failed! Insufficient access rights > > > I can't retrieve the key .. I'd need to see the smart-proxy user, show --all --raw would be best. I just tested this on a RHEL-6 instance I had handy and it worked fine: # ipa user-add --first=test --last=user tuser1 --password # ipa role-add 'host keytab' --desc 'manage host keytabs' # ipa privilege-add 'manage host keytab' --desc 'manage host keytabs' # ipa privilege-add-permission 'manage host keytab' --permissions='manage host keytab' # ipa role-add-privilege 'host keytab' --privileges='manage host keytab' # ipa role-add-member --users=tuser1 'host keytab' # kinit tuser1 # ipa-getkeytab -s `hostname` -k /tmp/test.keytab -p host/test.example.com Keytab successfully retrieved and stored in: /tmp/test.keytab rob > > 2014-09-09 16:14 GMT+02:00 Rob Crittenden >: > > James James wrote: > > My IPA version is 3.0.0 . > > Thanks > > The permission 'Manage host keytab' should do the trick. > > rob > > > > > 2014-09-09 1:22 GMT+02:00 Dmitri Pal > > >>: > > > > On 09/08/2014 06:52 PM, James James wrote: > >> Hi everybody, > >> > >> I want a user to be able to do ipa-getkeytab to retrieve the keys > >> from any host in the realm. > >> > >> How can I do this ? > >> > >> Where I can find an ACI example > >> > (https://www.redhat.com/archives/freeipa-users/2010-July/msg00024.html) > >> which can helps me ? > >> > >> > >> Thanks for your help. > >> > >> > >> > >> > > Which version of IPA? > > There reason for the question is because in FreeIPA 4.0 the ACIs > > were significantly reworked. > > > > -- > > Thank you, > > Dmitri Pal > > > > Sr. Engineering Manager IdM portfolio > > Red Hat, Inc. > > > > > > -- > > Manage your subscription for the Freeipa-users mailing list: > > https://www.redhat.com/mailman/listinfo/freeipa-users > > Go To http://freeipa.org for more info on the project > > > > > > > > > > From uncommonkat at gmail.com Tue Sep 9 15:20:02 2014 From: uncommonkat at gmail.com (Kat) Date: Tue, 09 Sep 2014 08:20:02 -0700 Subject: [Freeipa-users] unhappy replication? In-Reply-To: <540F1530.2040309@redhat.com> References: <540F1139.8050604@gmail.com> <540F1530.2040309@redhat.com> Message-ID: <540F1AA2.2070609@gmail.com> This brings up a question - if I just installed a master -- shouldn't I be able to create the replica immediately after (even if I did a migration from an old LDAP server?) Am I looking at some sort of "wait until I'm done.." condition with the primary server? This is the only other replica so there is nothing there. I guess time to go digging around. It is 3.3.3 on CentOS 7.. I'll let you know if I fine anything else. Thanks. On 9/9/14 7:56 AM, Rich Megginson wrote: > On 09/09/2014 08:39 AM, Kat wrote: >> Anyone seen this before -- 2 freshly kicked CentOS 7 installs: >> >> On the replica from the ipa-replica-install : >> >> 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. > > Is it possible that the replica was being initialized by another > replica, or you tried to initialize it again while a replica init was > already running? Error 10 Referral is returned by a replica when you > attempt an ldap operation against it while it is being initialized > i.e. the database is locked, so any other operation gets a "busy > signal" and a referral to another replica. > >> >> and then the errors file for 389-ds >> >> "The remote replica has a different database generation ID than the >> local database. You may have to reinitialize the remote replica, or >> the local replica." > > This just means the replica has not been initialized yet. > >> >> ~K >> > From rmeggins at redhat.com Tue Sep 9 15:25:40 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 09 Sep 2014 09:25:40 -0600 Subject: [Freeipa-users] unhappy replication? In-Reply-To: <540F1AA2.2070609@gmail.com> References: <540F1139.8050604@gmail.com> <540F1530.2040309@redhat.com> <540F1AA2.2070609@gmail.com> Message-ID: <540F1BF4.6010507@redhat.com> On 09/09/2014 09:20 AM, Kat wrote: > This brings up a question - if I just installed a master -- shouldn't > I be able to create the replica immediately after (even if I did a > migration from an old LDAP server?) Yes. > Am I looking at some sort of "wait until I'm done.." condition with > the primary server? Well, it depends. Did you get the "[10 Total update abortedLDAP error: Referral]" from the primary or the secondary? > > This is the only other replica so there is nothing there. I guess > time to go digging around. It is 3.3.3 on CentOS 7.. > > I'll let you know if I fine anything else. > > Thanks. > > On 9/9/14 7:56 AM, Rich Megginson wrote: >> On 09/09/2014 08:39 AM, Kat wrote: >>> Anyone seen this before -- 2 freshly kicked CentOS 7 installs: >>> >>> On the replica from the ipa-replica-install : >>> >>> 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. >> >> Is it possible that the replica was being initialized by another >> replica, or you tried to initialize it again while a replica init was >> already running? Error 10 Referral is returned by a replica when you >> attempt an ldap operation against it while it is being initialized >> i.e. the database is locked, so any other operation gets a "busy >> signal" and a referral to another replica. >> >>> >>> and then the errors file for 389-ds >>> >>> "The remote replica has a different database generation ID than the >>> local database. You may have to reinitialize the remote replica, or >>> the local replica." >> >> This just means the replica has not been initialized yet. >> >>> >>> ~K >>> >> > From aglo at umich.edu Tue Sep 9 15:27:14 2014 From: aglo at umich.edu (Olga Kornievskaia) Date: Tue, 9 Sep 2014 11:27:14 -0400 Subject: [Freeipa-users] freeipa server install fails on fedora 20 In-Reply-To: <540F1183.3010607@redhat.com> References: <540E24BA.3070803@redhat.com> <540E3EC5.7050203@redhat.com> <540F1183.3010607@redhat.com> Message-ID: On Tue, Sep 9, 2014 at 10:41 AM, Rob Crittenden wrote: > Olga Kornievskaia wrote: > > > > > > On Mon, Sep 8, 2014 at 7:41 PM, Dmitri Pal > > wrote: > > > > On 09/08/2014 07:29 PM, Olga Kornievskaia wrote: > >> Thank you very much for your quick reply. > >> > >> It is a brand new fedora 20 vm. > > > > OK good. > > Can you send or share the ipa server installation log? > > > > > > Can you please suggest how I can do that? My original post was rejected > > by the administrator of this list because I've included the install log > > that compressed was over 5M. > > If you have a web/ftp server available you can put it there for download. > I have put the files in google drive and they should be accessible via this link: freeipa-install-logs - https://drive.google.com/folderview?id=0B7NX-2naBL7GWXVIOS11YnZLZWM&usp=sharing Please let me know if there are problems accessing it. > > I'd look at the catalina.* logs in /var/log/pki/pki-tomcat and debug in > the ca subdirectory. Those are more likely to hold startup failures. > I have included the "debug", "ca-spawn", and snippet of "journalctl" output files. Personally, I wasn't able to find any error messages in there. Thank you. > journalctl may hold information on why it didn't start too. > > Incidentally, the second problem is likely related to the first. The > installation didn't succeed so the system state is indeterminate. > > rob > > > > > > > Are you using a cert from AD and trying to chain to an AD CA? > > > > > > I'm not specifying any cert options on the install command (i.e. I'm > > using the default certs supplied with the install). > > > > > > > > > > > > > >> > >> There is nothing that's running on port 443. > >> > >> catalina.out is empty > >> system file is attached and reports that certificate is not in > >> pkcs11 format. > >> pki-ca-spaw.XX.log does not appear to report errors (also attached) > >> > >> Please let me know if I can enable any other debugging into that > >> might be useful in figuring this out. > >> > >> Thank you. > >> > >> > >> On Mon, Sep 8, 2014 at 5:50 PM, Dmitri Pal >> > wrote: > >> > >> On 09/08/2014 03:49 PM, Olga Kornievskaia wrote: > >>> Can somebody help with the following problem(s) I?ve > >>> encountered while trying to install the freeipa server? > >>> > >>> Problem #1: > >>> On fedora 20, I have: > >>> 1. using yum install acquired the free-ipa-server package. > >>> 2. ran ipa-server-install > >>> ? that has failed with ?CA did not start in 300s? > >>> > >>> One thing that?s noticeable in the logs (the snippet is > >>> included below) is that request for request > >>> 'https://ipa1.gateway.2wire.net:443/ca/admin/ca/getStatus' > >>> > >>> > >>> has 443 as port as for before all the requests for 8443 > >>> (e.g.., same (manual) request on port 8443 succeeds). Seems > >>> like an install script somewhere has the wrong port ? > >> > >> 443 is the right port. > >> Do you have something already running on the same box on that > >> port? > >> That might prevent things from installing and running. > >> > >> Please try on a clean machine or VM. > >> Also more logs will be helpful. > >> Please see this [1] on how to troubleshoot. > >> > >> The second problem is most likely an artifact of the > >> incomplete install. > >> > >> [1] http://www.freeipa.org/page/Troubleshooting > >> > >>> > >>> 2014-09-08T19:21:07Z DEBUG Waiting for CA to start... > >>> > >>> 2014-09-08T19:21:08Z DEBUG request > >>> 'https://ipa1.gateway.2wire.net:443/ca/admin/ca/getStatus' > >>> > >>> 2014-09-08T19:21:08Z DEBUG request body '' > >>> > >>> 2014-09-08T19:21:08Z DEBUG request status 503 > >>> > >>> 2014-09-08T19:21:08Z DEBUG request reason_phrase u'Service > >>> Unavailable' > >>> > >>> 2014-09-08T19:21:08Z DEBUG request headers {'date': 'Mon, 08 > >>> Sep 2014 19:21:08 GMT', 'content-length': '299', > >>> 'content-type': 'text/html; charset=iso-8859-1', > >>> 'connection': 'close', 'server': 'Apache/2.4.10 (Fedora) > >>> mod_auth_kerb/5.4 mod_nss/2.4.6 NSS/3.15.3 Basic ECC > >>> mod_wsgi/3.5 Python/2.7.5'}2014-09-08T19:21:08Z DEBUG request > >>> body ' >>> 2.0//EN">\n\n503 Service > >>> Unavailable\n\n

Service > >>> Unavailable

\n

The server is temporarily unable to > >>> service your\nrequest due to maintenance downtime or > >>> capacity\nproblems. Please try again > >>> later.

\n\n' > >>> > >>> 2014-09-08T19:21:08Z DEBUG The CA status is: Service > Unavailable > >>> > >>> > >>> Problem #2: > >>> The next problem I?m encountering and doesn?t seem to be > >>> related to the CA setup is on the next step of ?kinit admin?. > >>> It fails with ?generic pre authentication failure while > >>> getting initial credentials" > >>> > >>> stracing kinit show that it tried to open file > >>> ?/var/lib/sss/pubconf/kdcinfo.GATEWAY.2WIRE.NET > >>> ?) and fails with ?no such > >>> file? error. ?pubconf? dir only has empty ?krb5.include.d?. > >>> > >>> I don?t know if this failure is due to the fact that the > >>> setup didn?t run all the way and some configuration is > >>> missing or this is a separate issue . > >>> > >>> Are these bugs that need to be filled with bugzilla or am I > >>> doing something incorrectly? > >>> > >>> Any help would be appreciated. > >>> > >>> Thank you. > >>> > >>> > >> > >> > >> -- > >> Thank you, > >> Dmitri Pal > >> > >> Sr. Engineering Manager IdM portfolio > >> Red Hat, Inc. > >> > >> > >> -- > >> Manage your subscription for the Freeipa-users mailing list: > >> https://www.redhat.com/mailman/listinfo/freeipa-users > >> Go To http://freeipa.org for more info on the project > >> > >> > > > > > > -- > > Thank you, > > Dmitri Pal > > > > Sr. Engineering Manager IdM portfolio > > Red Hat, Inc. > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From uncommonkat at gmail.com Tue Sep 9 16:12:35 2014 From: uncommonkat at gmail.com (Kat) Date: Tue, 09 Sep 2014 09:12:35 -0700 Subject: [Freeipa-users] unhappy replication? In-Reply-To: <540F1BF4.6010507@redhat.com> References: <540F1139.8050604@gmail.com> <540F1530.2040309@redhat.com> <540F1AA2.2070609@gmail.com> <540F1BF4.6010507@redhat.com> Message-ID: <540F26F3.1060802@gmail.com> Well - here is the problem and solution: Fails every time: Install master, enable migration, migrate existing LDAP config/users, setup replication, fails. Works every time: Install master, setup replication, enable migration, migrate existing LDAP config/users, works perfectly. So -- a problem with migration settings?? On 9/9/14 8:25 AM, Rich Megginson wrote: > On 09/09/2014 09:20 AM, Kat wrote: >> This brings up a question - if I just installed a master -- shouldn't >> I be able to create the replica immediately after (even if I did a >> migration from an old LDAP server?) > > Yes. > >> Am I looking at some sort of "wait until I'm done.." condition with >> the primary server? > > Well, it depends. Did you get the "[10 Total update abortedLDAP > error: Referral]" from the primary or the secondary? > >> >> This is the only other replica so there is nothing there. I guess >> time to go digging around. It is 3.3.3 on CentOS 7.. >> >> I'll let you know if I fine anything else. >> >> Thanks. >> >> On 9/9/14 7:56 AM, Rich Megginson wrote: >>> On 09/09/2014 08:39 AM, Kat wrote: >>>> Anyone seen this before -- 2 freshly kicked CentOS 7 installs: >>>> >>>> On the replica from the ipa-replica-install : >>>> >>>> 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. >>> >>> Is it possible that the replica was being initialized by another >>> replica, or you tried to initialize it again while a replica init >>> was already running? Error 10 Referral is returned by a replica >>> when you attempt an ldap operation against it while it is being >>> initialized i.e. the database is locked, so any other operation gets >>> a "busy signal" and a referral to another replica. >>> >>>> >>>> and then the errors file for 389-ds >>>> >>>> "The remote replica has a different database generation ID than the >>>> local database. You may have to reinitialize the remote replica, >>>> or the local replica." >>> >>> This just means the replica has not been initialized yet. >>> >>>> >>>> ~K >>>> >>> >> > From rmeggins at redhat.com Tue Sep 9 16:24:42 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 09 Sep 2014 10:24:42 -0600 Subject: [Freeipa-users] unhappy replication? In-Reply-To: <540F26F3.1060802@gmail.com> References: <540F1139.8050604@gmail.com> <540F1530.2040309@redhat.com> <540F1AA2.2070609@gmail.com> <540F1BF4.6010507@redhat.com> <540F26F3.1060802@gmail.com> Message-ID: <540F29CA.8000509@redhat.com> On 09/09/2014 10:12 AM, Kat wrote: > Well - here is the problem and solution: > > Fails every time: > > Install master, enable migration, migrate existing LDAP config/users, > setup replication, fails. > > Works every time: > > Install master, setup replication, enable migration, migrate existing > LDAP config/users, works perfectly. > > So -- a problem with migration settings?? Could be. Is it a problem if the only way you can successfully set things up is to do the latter procedure? > > On 9/9/14 8:25 AM, Rich Megginson wrote: >> On 09/09/2014 09:20 AM, Kat wrote: >>> This brings up a question - if I just installed a master -- >>> shouldn't I be able to create the replica immediately after (even if >>> I did a migration from an old LDAP server?) >> >> Yes. >> >>> Am I looking at some sort of "wait until I'm done.." condition with >>> the primary server? >> >> Well, it depends. Did you get the "[10 Total update abortedLDAP >> error: Referral]" from the primary or the secondary? >> >>> >>> This is the only other replica so there is nothing there. I guess >>> time to go digging around. It is 3.3.3 on CentOS 7.. >>> >>> I'll let you know if I fine anything else. >>> >>> Thanks. >>> >>> On 9/9/14 7:56 AM, Rich Megginson wrote: >>>> On 09/09/2014 08:39 AM, Kat wrote: >>>>> Anyone seen this before -- 2 freshly kicked CentOS 7 installs: >>>>> >>>>> On the replica from the ipa-replica-install : >>>>> >>>>> 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. >>>> >>>> Is it possible that the replica was being initialized by another >>>> replica, or you tried to initialize it again while a replica init >>>> was already running? Error 10 Referral is returned by a replica >>>> when you attempt an ldap operation against it while it is being >>>> initialized i.e. the database is locked, so any other operation >>>> gets a "busy signal" and a referral to another replica. >>>> >>>>> >>>>> and then the errors file for 389-ds >>>>> >>>>> "The remote replica has a different database generation ID than >>>>> the local database. You may have to reinitialize the remote >>>>> replica, or the local replica." >>>> >>>> This just means the replica has not been initialized yet. >>>> >>>>> >>>>> ~K >>>>> >>>> >>> >> > From uncommonkat at gmail.com Tue Sep 9 16:41:54 2014 From: uncommonkat at gmail.com (Kat) Date: Tue, 09 Sep 2014 09:41:54 -0700 Subject: [Freeipa-users] unhappy replication? In-Reply-To: <540F29CA.8000509@redhat.com> References: <540F1139.8050604@gmail.com> <540F1530.2040309@redhat.com> <540F1AA2.2070609@gmail.com> <540F1BF4.6010507@redhat.com> <540F26F3.1060802@gmail.com> <540F29CA.8000509@redhat.com> Message-ID: <540F2DD2.1010609@gmail.com> The problem I see is simple - not being able to add additional replicas after the migration? On 9/9/14 9:24 AM, Rich Megginson wrote: > On 09/09/2014 10:12 AM, Kat wrote: >> Well - here is the problem and solution: >> >> Fails every time: >> >> Install master, enable migration, migrate existing LDAP config/users, >> setup replication, fails. >> >> Works every time: >> >> Install master, setup replication, enable migration, migrate existing >> LDAP config/users, works perfectly. >> >> So -- a problem with migration settings?? > > Could be. Is it a problem if the only way you can successfully set > things up is to do the latter procedure? From rmeggins at redhat.com Tue Sep 9 16:55:56 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 09 Sep 2014 10:55:56 -0600 Subject: [Freeipa-users] unhappy replication? In-Reply-To: <540F2DD2.1010609@gmail.com> References: <540F1139.8050604@gmail.com> <540F1530.2040309@redhat.com> <540F1AA2.2070609@gmail.com> <540F1BF4.6010507@redhat.com> <540F26F3.1060802@gmail.com> <540F29CA.8000509@redhat.com> <540F2DD2.1010609@gmail.com> Message-ID: <540F311C.7090900@redhat.com> On 09/09/2014 10:41 AM, Kat wrote: > The problem I see is simple - not being able to add additional > replicas after the migration? What I meant to say is - Is the workaround of setting replication first, then doing migration, acceptable? > > On 9/9/14 9:24 AM, Rich Megginson wrote: >> On 09/09/2014 10:12 AM, Kat wrote: >>> Well - here is the problem and solution: >>> >>> Fails every time: >>> >>> Install master, enable migration, migrate existing LDAP >>> config/users, setup replication, fails. >>> >>> Works every time: >>> >>> Install master, setup replication, enable migration, migrate >>> existing LDAP config/users, works perfectly. >>> >>> So -- a problem with migration settings?? >> >> Could be. Is it a problem if the only way you can successfully set >> things up is to do the latter procedure? > From passmossis at gmail.com Tue Sep 9 16:01:57 2014 From: passmossis at gmail.com (Eric Hart) Date: Tue, 9 Sep 2014 12:01:57 -0400 Subject: [Freeipa-users] IPA Version 3.0.0 Allow Self-Signed Certificates Message-ID: I'm trying to find a way to enable FreeIPA to allow Self-Signed Certificates. I haven't found a way to enable that capability yet.. I've manually edited configuration files within /etc/dirsrv/slapd-EXAMPLE-COM, specifically the nsslapd-ssl-check-hostname, nsslapd-validate-cert options set to off and warn respectively. Not allowing self-signed certificates has caused me to not be able to establish a replicated server or integrate a device for SSO that provides a self signed certificate. Thanks for any input or insight, Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From mohammadsereshki at yahoo.com Tue Sep 9 19:15:00 2014 From: mohammadsereshki at yahoo.com (mohammad sereshki) Date: Tue, 9 Sep 2014 12:15:00 -0700 Subject: [Freeipa-users] Solaris 10 client auth (ssh + kerberos) not working In-Reply-To: <540ED439.8060800@gmail.com> References: <540D7A6A.4030202@gmail.com> <1410173371.15200.YahooMailNeo@web161501.mail.bf1.yahoo.com> <540ED439.8060800@gmail.com> Message-ID: <1410290100.99443.YahooMailNeo@web161501.mail.bf1.yahoo.com> Dear below must be configured in the pam.conf also each host needs seperate keytab, solaris 11 is same as solaris 10 login auth requisite pam_authtok_get.so.1 login auth required pam_dhkeys.so.1 login auth required pam_unix_cred.so.1 login auth sufficient pam_krb5.so.1 try_first_pass login auth required pam_unix_auth.so.1 login auth required pam_dial_auth.so.1 rlogin auth sufficient pam_rhosts_auth.so.1 rlogin auth requisite pam_authtok_get.so.1 rlogin auth required pam_dhkeys.so.1 rlogin auth required pam_unix_cred.so.1 rlogin auth required pam_unix_auth.so.1 krlogin auth required pam_unix_cred.so.1 krlogin auth required pam_krb5.so.1 rsh auth sufficient pam_rhosts_auth.so.1 rsh auth required pam_unix_cred.so.1 krsh auth required pam_unix_cred.so.1 krsh auth required pam_krb5.so.1 ktelnet auth required pam_unix_cred.so.1 ktelnet auth required pam_krb5.so.1 ppp auth requisite pam_authtok_get.so.1 ppp auth required pam_dhkeys.so.1 ppp auth required pam_unix_cred.so.1 ppp auth required pam_unix_auth.so.1 ppp auth required pam_dial_auth.so.1 other auth requisite pam_authtok_get.so.1 other auth required pam_dhkeys.so.1 other auth required pam_unix_cred.so.1 other auth sufficient pam_krb5.so.1 other auth required pam_unix_auth.so.1 passwd auth required pam_passwd_auth.so.1 cron account required pam_unix_account.so.1 other account requisite pam_roles.so.1 other account required pam_unix_account.so.1 other account sufficient pam_krb5.so.1 other account required pam_tsol_account.so.1 other session required pam_unix_session.so.1 other password required pam_dhkeys.so.1 other password requisite pam_authtok_get.so.1 other password requisite pam_authtok_check.so.1 force_check other password sufficient pam_krb5.so.1 other password required pam_authtok_store.so.1 ________________________________ From: Gerardo Padierna To: mohammad sereshki ; "freeipa-users at redhat.com" Sent: Tuesday, September 9, 2014 2:49 PM Subject: Re: [Freeipa-users] Solaris 10 client auth (ssh + kerberos) not working Hi Mohammad, This is for Solaris 11; it seems that some of the options for the pam.conf file are not available in Solaris 10 (I think it was the following options: auth definitive pam_user_policy.so.1 account required pam_tsol_account.so.1 password required pam_authtok_store.so.1 ... had to remove them from the pam.conf file..) Still didn't get the ssh auth to work... This may be a stupid question, but do you know if the keytab file must be _exactly_ the same as in the IPA server, or does it only need to contain the entries relevant for the (solaris) client? According to the link you're pointing me to, it seems to just take from the server keytab file those entries relevant for the client, create a new keytab file with that content, and copy it over to the client. Is such a 'stipped down' keytab file supposed to work for the client's auth? Regards, Gerardo El 08/09/14 a las #4, mohammad sereshki escribi?: > >hi >Please go ahead with below structure, It works! > > > > > >Re: [Freeipa-users] Does Solaris 11 work as client to IPA server? > > > >Re: [Freeipa-users] Does Solaris 11 work as client to IPA server? >[Date Prev][Date Next] [Thread Prev][Thread Next] [Thread Index] [Date Index] [Author Index] Re: [Freeipa-users] Does Solaris 11 work as client to IPA server? > > >View on www.redhat.com Preview by Yahoo > > > > > > >________________________________ > From: Gerardo Padierna >To: freeipa-users at redhat.com >Sent: Monday, September 8, 2014 2:14 PM >Subject: [Freeipa-users] Solaris 10 client auth (ssh + kerberos) not working > > > >Hello folks, > >I'm setting up an IPA-server instance aimed to be used primarily for Linux/Unix clients ssh authentication (with kerberos). >I've managed to successfully set up debian clients (via sssd and also on older debians, through libnss and pam_krb5). But for some reason I can't authenticate ssh on Solaris10 clients. >On the Solaris box, I've followed the steps outiined here: >http://www.freeipa.org/page/ConfiguringUnixClients >and the nss part works fine (things like getent [group | passwd] and id work), but unfortunaltely, the ssh user authentication fails with an error: >sshd auth.error PAM-KRB5 (auth): krb5_verify_init_creds failed: No such file or directory > >On the solaris clients, does there need to be a keytab in /etc/krb5/ directory copied over from the IPA server? (I didn't have to set up a keytab file fo the legacy debian clients, and in the solaris-clients doc previously mentioned, there's no mention of it). Well, since I read somewhere the keytab file need to be there, I copied it over from the IPA server to the solaris clients, Then I get a different error: >PAM-KRB5 (auth): krb5_verify_init_creds failed: Key table entry not found > >This error seems to indicate that there isn't an matching entry found in the keytab file, so I added an entry for the solaris client, but I'm still getting the same 'Key table entry not found' error (it could be the entry I added is wrong, of course). But, for now, just want to be sure: On the solaris clients, do I need an /etc/krb5/krb5.keytab file? (if yes, why not in the non-sssd Debian hosts then?) > >Thanks in advance, > >-- > >Gerardo Padierna Nanclares >T?cnico de Sistemas (grupo ASL) - [Fujitsu / Logware] >Servicio de Sistemas de la Informaci?n (DGTI) - Generalitat Valenciana >C/.Castan Tobe?as 77 ? 46018 Valencia ? Edificio A >Tel: 961 208973 >Email: asl.gerardo at gmail.com >-- >Manage your subscription for the Freeipa-users mailing list: >https://www.redhat.com/mailman/listinfo/freeipa-users >Go To http://freeipa.org for more info on the project > > -- Gerardo Padierna Nanclares T?cnico de Sistemas (grupo ASL) - [Fujitsu / Logware] Servicio de Sistemas de la Informaci?n (DGTI) - Generalitat Valenciana C/.Castan Tobe?as 77 ? 46018 Valencia ? Edificio A Tel: 961 208973 Email: asl.gerardo at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Tue Sep 9 20:58:18 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 09 Sep 2014 16:58:18 -0400 Subject: [Freeipa-users] Sane request? In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E7231C5@001FSN2MPN1-044.001f.mgd2.msft.net> References: <82E7C9A01FD0764CACDD35D10F5DFB6E7231C5@001FSN2MPN1-044.001f.mgd2.msft.net> Message-ID: <540F69EA.6090308@redhat.com> On 09/08/2014 08:02 PM, Nordgren, Bryce L -FS wrote: > > Is it sane to request that freeipa store ssh keys for users who come > into the environment via a trust? Not all of them, of course, but > those who want to store public keys there. > > My freeipa server is mostly there to manage machines, and users (incl. > me) mostly come in over trusts from the corporate AD. It'd sure be > nice if I could put my laptop's public key on the freeipa server and > use it everywhere. > You are talking about this, right? https://fedorahosted.org/freeipa/ticket/4509 > Food for thot. > > Bryce > > > > > > This electronic message contains information generated by the USDA > solely for the intended recipients. Any unauthorized interception of > this message or the use or disclosure of the information it contains > may violate the law and subject the violator to civil or criminal > penalties. If you believe you have received this message in error, > please notify the sender and delete the email immediately. > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jreg2k at gmail.com Tue Sep 9 21:17:31 2014 From: jreg2k at gmail.com (James James) Date: Tue, 9 Sep 2014 23:17:31 +0200 Subject: [Freeipa-users] ACI for ipa-getkeytab In-Reply-To: <540F15ED.9080302@redhat.com> References: <540E3A36.8080802@redhat.com> <540F0B45.5060304@redhat.com> <540F15ED.9080302@redhat.com> Message-ID: SOLVED. realm-proxy has to be indirect member of : memberofindirect: cn=manage host keytab,cn=privileges,cn=pbac,dc=example,dc=com Thanks for your help. 2014-09-09 16:59 GMT+02:00 Rob Crittenden : > James James wrote: > > My user : realm-proxy is in a group (Smart Proxy Host Management) which > > has the Manager host keytab permission : > > > > Permission name: Manage host keytab > > Permissions: write > > Attributes: krbprincipalkey, krblastpwdchange > > Type: host > > Granted to Privilege: Host Administrators, Host Enrollment, Smart > > Proxy Host Management > > > > > > When I try to retreive a keytab from another host when my principal is > > the realm-proxy : > > > > > > [root at client1 ~]# kinit realm-proxy at EXAMPLE.COM > > -k -t /tmp/freeipa.keytab > > > > [root at client1 ~]# klist > > > > Ticket cache: KEYRING:persistent:0:0 > > Default principal: realm-proxy at EXAMPLE.COM realm-proxy at EXAMPLE.COM> > > > > Valid starting Expires Service principal > > 09/09/2014 14:35:50 09/10/2014 14:35:50 krbtgt/EXAMPLE.COM at EXAMPLE.COM > > > > > > [root at client1 ~]# ipa-getkeytab --server=ipa.example.com > > --principal=host/client1.example.com > > --keytab=/etc/krb5.keytab > > Operation failed! Insufficient access rights > > > > > > I can't retrieve the key .. > > I'd need to see the smart-proxy user, show --all --raw would be best. > > I just tested this on a RHEL-6 instance I had handy and it worked fine: > > # ipa user-add --first=test --last=user tuser1 --password > # ipa role-add 'host keytab' --desc 'manage host keytabs' > # ipa privilege-add 'manage host keytab' --desc 'manage host keytabs' > # ipa privilege-add-permission 'manage host keytab' > --permissions='manage host keytab' > # ipa role-add-privilege 'host keytab' --privileges='manage host keytab' > # ipa role-add-member --users=tuser1 'host keytab' > # kinit tuser1 > # ipa-getkeytab -s `hostname` -k /tmp/test.keytab -p host/test.example.com > Keytab successfully retrieved and stored in: /tmp/test.keytab > > rob > > > > > 2014-09-09 16:14 GMT+02:00 Rob Crittenden > >: > > > > James James wrote: > > > My IPA version is 3.0.0 . > > > Thanks > > > > The permission 'Manage host keytab' should do the trick. > > > > rob > > > > > > > > 2014-09-09 1:22 GMT+02:00 Dmitri Pal dpal at redhat.com> > > > >>: > > > > > > On 09/08/2014 06:52 PM, James James wrote: > > >> Hi everybody, > > >> > > >> I want a user to be able to do ipa-getkeytab to retrieve the > keys > > >> from any host in the realm. > > >> > > >> How can I do this ? > > >> > > >> Where I can find an ACI example > > >> > > ( > https://www.redhat.com/archives/freeipa-users/2010-July/msg00024.html) > > >> which can helps me ? > > >> > > >> > > >> Thanks for your help. > > >> > > >> > > >> > > >> > > > Which version of IPA? > > > There reason for the question is because in FreeIPA 4.0 the > ACIs > > > were significantly reworked. > > > > > > -- > > > Thank you, > > > Dmitri Pal > > > > > > Sr. Engineering Manager IdM portfolio > > > Red Hat, Inc. > > > > > > > > > -- > > > Manage your subscription for the Freeipa-users mailing list: > > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > Go To http://freeipa.org for more info on the project > > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bnordgren at fs.fed.us Tue Sep 9 21:21:21 2014 From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS) Date: Tue, 9 Sep 2014 21:21:21 +0000 Subject: [Freeipa-users] Sane request? In-Reply-To: <540F69EA.6090308@redhat.com> References: <82E7C9A01FD0764CACDD35D10F5DFB6E7231C5@001FSN2MPN1-044.001f.mgd2.msft.net> <540F69EA.6090308@redhat.com> Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E72366E@001FSN2MPN1-044.001f.mgd2.msft.net> Sweet! Yes I am apparently talking about that. Consider this an independent request for that. :) You are talking about this, right? https://fedorahosted.org/freeipa/ticket/4509 This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Tue Sep 9 22:18:37 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 09 Sep 2014 18:18:37 -0400 Subject: [Freeipa-users] unhappy replication? In-Reply-To: <540F311C.7090900@redhat.com> References: <540F1139.8050604@gmail.com> <540F1530.2040309@redhat.com> <540F1AA2.2070609@gmail.com> <540F1BF4.6010507@redhat.com> <540F26F3.1060802@gmail.com> <540F29CA.8000509@redhat.com> <540F2DD2.1010609@gmail.com> <540F311C.7090900@redhat.com> Message-ID: <540F7CBD.9030202@redhat.com> On 09/09/2014 12:55 PM, Rich Megginson wrote: > On 09/09/2014 10:41 AM, Kat wrote: >> The problem I see is simple - not being able to add additional >> replicas after the migration? > > What I meant to say is - Is the workaround of setting replication > first, then doing migration, acceptable? > >> >> On 9/9/14 9:24 AM, Rich Megginson wrote: >>> On 09/09/2014 10:12 AM, Kat wrote: >>>> Well - here is the problem and solution: >>>> >>>> Fails every time: >>>> >>>> Install master, enable migration, migrate existing LDAP >>>> config/users, setup replication, fails. >>>> >>>> Works every time: >>>> >>>> Install master, setup replication, enable migration, migrate >>>> existing LDAP config/users, works perfectly. >>>> >>>> So -- a problem with migration settings?? >>> >>> Could be. Is it a problem if the only way you can successfully set >>> things up is to do the latter procedure? >> > Would be nice to test this scenario at some point and reproduce it. I do not think the workaround is acceptable. One should be able to add the replicas after migration. Is this a timing issue? I mean can you add replica next day for example or never? If you never can add a replica after migration it is a problem and we should fix it. If you can't just for s short period of time then we should probably file a ticket and process it later. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Tue Sep 9 22:20:28 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 09 Sep 2014 18:20:28 -0400 Subject: [Freeipa-users] Sane request? In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E72366E@001FSN2MPN1-044.001f.mgd2.msft.net> References: <82E7C9A01FD0764CACDD35D10F5DFB6E7231C5@001FSN2MPN1-044.001f.mgd2.msft.net> <540F69EA.6090308@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E72366E@001FSN2MPN1-044.001f.mgd2.msft.net> Message-ID: <540F7D2C.6020602@redhat.com> On 09/09/2014 05:21 PM, Nordgren, Bryce L -FS wrote: > > Sweet! Yes I am apparently talking about that. Consider this an > independent request for that. J > Please add a comment to the ticket that you are an an independent requester of this feature. > > You are talking about this, right? > https://fedorahosted.org/freeipa/ticket/4509 > > > > > > > > This electronic message contains information generated by the USDA > solely for the intended recipients. Any unauthorized interception of > this message or the use or disclosure of the information it contains > may violate the law and subject the violator to civil or criminal > penalties. If you believe you have received this message in error, > please notify the sender and delete the email immediately. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From uncommonkat at gmail.com Tue Sep 9 22:42:08 2014 From: uncommonkat at gmail.com (Kat) Date: Tue, 09 Sep 2014 15:42:08 -0700 Subject: [Freeipa-users] unhappy replication? In-Reply-To: <540F7CBD.9030202@redhat.com> References: <540F1139.8050604@gmail.com> <540F1530.2040309@redhat.com> <540F1AA2.2070609@gmail.com> <540F1BF4.6010507@redhat.com> <540F26F3.1060802@gmail.com> <540F29CA.8000509@redhat.com> <540F2DD2.1010609@gmail.com> <540F311C.7090900@redhat.com> <540F7CBD.9030202@redhat.com> Message-ID: <540F8240.3020602@gmail.com> On 9/9/14 3:18 PM, Dmitri Pal wrote: > On 09/09/2014 12:55 PM, Rich Megginson wrote: >> On 09/09/2014 10:41 AM, Kat wrote: >>> The problem I see is simple - not being able to add additional >>> replicas after the migration? >> >> What I meant to say is - Is the workaround of setting replication >> first, then doing migration, acceptable? >> >>> >>> On 9/9/14 9:24 AM, Rich Megginson wrote: >>>> On 09/09/2014 10:12 AM, Kat wrote: >>>>> Well - here is the problem and solution: >>>>> >>>>> Fails every time: >>>>> >>>>> Install master, enable migration, migrate existing LDAP >>>>> config/users, setup replication, fails. >>>>> >>>>> Works every time: >>>>> >>>>> Install master, setup replication, enable migration, migrate >>>>> existing LDAP config/users, works perfectly. >>>>> >>>>> So -- a problem with migration settings?? >>>> >>>> Could be. Is it a problem if the only way you can successfully set >>>> things up is to do the latter procedure? >>> >> > Would be nice to test this scenario at some point and reproduce it. > I do not think the workaround is acceptable. One should be able to add > the replicas after migration. > Is this a timing issue? I mean can you add replica next day for > example or never? > If you never can add a replica after migration it is a problem and we > should fix it. If you can't just for s short period of time then we > should probably file a ticket and process it later. > Sadly - no - I waited 24 hours after the migration from OpenLDAP to IPA and still could not do it. Going to try something else. Since the bug still exists migrating to 4.x directly - going to migrate to 3.3.5, THEN upgrade to 4.0.1 and then try the replica addition. I will let you know what happens. ~K From rcritten at redhat.com Tue Sep 9 22:44:40 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 09 Sep 2014 18:44:40 -0400 Subject: [Freeipa-users] unhappy replication? In-Reply-To: <540F8240.3020602@gmail.com> References: <540F1139.8050604@gmail.com> <540F1530.2040309@redhat.com> <540F1AA2.2070609@gmail.com> <540F1BF4.6010507@redhat.com> <540F26F3.1060802@gmail.com> <540F29CA.8000509@redhat.com> <540F2DD2.1010609@gmail.com> <540F311C.7090900@redhat.com> <540F7CBD.9030202@redhat.com> <540F8240.3020602@gmail.com> Message-ID: <540F82D8.500@redhat.com> Kat wrote: > On 9/9/14 3:18 PM, Dmitri Pal wrote: >> On 09/09/2014 12:55 PM, Rich Megginson wrote: >>> On 09/09/2014 10:41 AM, Kat wrote: >>>> The problem I see is simple - not being able to add additional >>>> replicas after the migration? >>> >>> What I meant to say is - Is the workaround of setting replication >>> first, then doing migration, acceptable? >>> >>>> >>>> On 9/9/14 9:24 AM, Rich Megginson wrote: >>>>> On 09/09/2014 10:12 AM, Kat wrote: >>>>>> Well - here is the problem and solution: >>>>>> >>>>>> Fails every time: >>>>>> >>>>>> Install master, enable migration, migrate existing LDAP >>>>>> config/users, setup replication, fails. >>>>>> >>>>>> Works every time: >>>>>> >>>>>> Install master, setup replication, enable migration, migrate >>>>>> existing LDAP config/users, works perfectly. >>>>>> >>>>>> So -- a problem with migration settings?? >>>>> >>>>> Could be. Is it a problem if the only way you can successfully set >>>>> things up is to do the latter procedure? >>>> >>> >> Would be nice to test this scenario at some point and reproduce it. >> I do not think the workaround is acceptable. One should be able to add >> the replicas after migration. >> Is this a timing issue? I mean can you add replica next day for >> example or never? >> If you never can add a replica after migration it is a problem and we >> should fix it. If you can't just for s short period of time then we >> should probably file a ticket and process it later. >> > Sadly - no - I waited 24 hours after the migration from OpenLDAP to IPA > and still could not do it. > > Going to try something else. Since the bug still exists migrating to 4.x > directly - going to migrate to 3.3.5, THEN upgrade to 4.0.1 and then try > the replica addition. I will let you know what happens. Honestly, I find it hard to believe that this is related to migration. All migration does is pull over users and groups over LDAP. Whether you set up the agreement before or after, it is going to do a full database dump. The only difference is that after it will get more data. rob From dpal at redhat.com Tue Sep 9 23:32:06 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 09 Sep 2014 19:32:06 -0400 Subject: [Freeipa-users] unhappy replication? In-Reply-To: <540F82D8.500@redhat.com> References: <540F1139.8050604@gmail.com> <540F1530.2040309@redhat.com> <540F1AA2.2070609@gmail.com> <540F1BF4.6010507@redhat.com> <540F26F3.1060802@gmail.com> <540F29CA.8000509@redhat.com> <540F2DD2.1010609@gmail.com> <540F311C.7090900@redhat.com> <540F7CBD.9030202@redhat.com> <540F8240.3020602@gmail.com> <540F82D8.500@redhat.com> Message-ID: <540F8DF6.2030301@redhat.com> On 09/09/2014 06:44 PM, Rob Crittenden wrote: > Kat wrote: >> On 9/9/14 3:18 PM, Dmitri Pal wrote: >>> On 09/09/2014 12:55 PM, Rich Megginson wrote: >>>> On 09/09/2014 10:41 AM, Kat wrote: >>>>> The problem I see is simple - not being able to add additional >>>>> replicas after the migration? >>>> What I meant to say is - Is the workaround of setting replication >>>> first, then doing migration, acceptable? >>>> >>>>> On 9/9/14 9:24 AM, Rich Megginson wrote: >>>>>> On 09/09/2014 10:12 AM, Kat wrote: >>>>>>> Well - here is the problem and solution: >>>>>>> >>>>>>> Fails every time: >>>>>>> >>>>>>> Install master, enable migration, migrate existing LDAP >>>>>>> config/users, setup replication, fails. >>>>>>> >>>>>>> Works every time: >>>>>>> >>>>>>> Install master, setup replication, enable migration, migrate >>>>>>> existing LDAP config/users, works perfectly. >>>>>>> >>>>>>> So -- a problem with migration settings?? >>>>>> Could be. Is it a problem if the only way you can successfully set >>>>>> things up is to do the latter procedure? >>> Would be nice to test this scenario at some point and reproduce it. >>> I do not think the workaround is acceptable. One should be able to add >>> the replicas after migration. >>> Is this a timing issue? I mean can you add replica next day for >>> example or never? >>> If you never can add a replica after migration it is a problem and we >>> should fix it. If you can't just for s short period of time then we >>> should probably file a ticket and process it later. >>> >> Sadly - no - I waited 24 hours after the migration from OpenLDAP to IPA >> and still could not do it. >> >> Going to try something else. Since the bug still exists migrating to 4.x >> directly - going to migrate to 3.3.5, THEN upgrade to 4.0.1 and then try >> the replica addition. I will let you know what happens. > Honestly, I find it hard to believe that this is related to migration. > All migration does is pull over users and groups over LDAP. Whether you > set up the agreement before or after, it is going to do a full database > dump. The only difference is that after it will get more data. > > rob > Well may be the data is so big that the replication gets stuck? May be there is some huge group membership issue or something like. Do you have a huge group? Multiples of huge groups? Do you use auto membership? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From uncommonkat at gmail.com Tue Sep 9 23:40:07 2014 From: uncommonkat at gmail.com (Kat) Date: Tue, 09 Sep 2014 16:40:07 -0700 Subject: [Freeipa-users] unhappy replication? In-Reply-To: <540F8DF6.2030301@redhat.com> References: <540F1139.8050604@gmail.com> <540F1530.2040309@redhat.com> <540F1AA2.2070609@gmail.com> <540F1BF4.6010507@redhat.com> <540F26F3.1060802@gmail.com> <540F29CA.8000509@redhat.com> <540F2DD2.1010609@gmail.com> <540F311C.7090900@redhat.com> <540F7CBD.9030202@redhat.com> <540F8240.3020602@gmail.com> <540F82D8.500@redhat.com> <540F8DF6.2030301@redhat.com> Message-ID: <540F8FD7.7060004@gmail.com> some stats: ~2000 users ~275 groups ~largest groups = 150+ users (a couple dozen of these) ~K On 9/9/14 4:32 PM, Dmitri Pal wrote >> > Well may be the data is so big that the replication gets stuck? > May be there is some huge group membership issue or something like. > Do you have a huge group? Multiples of huge groups? Do you use auto > membership? > From dpal at redhat.com Wed Sep 10 00:13:30 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 09 Sep 2014 20:13:30 -0400 Subject: [Freeipa-users] unhappy replication? In-Reply-To: <540F8FD7.7060004@gmail.com> References: <540F1139.8050604@gmail.com> <540F1530.2040309@redhat.com> <540F1AA2.2070609@gmail.com> <540F1BF4.6010507@redhat.com> <540F26F3.1060802@gmail.com> <540F29CA.8000509@redhat.com> <540F2DD2.1010609@gmail.com> <540F311C.7090900@redhat.com> <540F7CBD.9030202@redhat.com> <540F8240.3020602@gmail.com> <540F82D8.500@redhat.com> <540F8DF6.2030301@redhat.com> <540F8FD7.7060004@gmail.com> Message-ID: <540F97AA.2010106@redhat.com> On 09/09/2014 07:40 PM, Kat wrote: > some stats: > ~2000 users > ~275 groups > ~largest groups = 150+ users > (a couple dozen of these) Does not sound offensive... May be we should take a look at your DS logs for the failed replication after migration. Any chance we can take a look? Is this the problem for the first replica or for any replica? I mean that if you add any new replica after the migration (install master and replica and then migrate then add another replica) you would be able to reproduce the problem. Is this the case? > > ~K > > On 9/9/14 4:32 PM, Dmitri Pal wrote >>> >> Well may be the data is so big that the replication gets stuck? >> May be there is some huge group membership issue or something like. >> Do you have a huge group? Multiples of huge groups? Do you use auto >> membership? >> > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From gregor.bregenzer at gmail.com Wed Sep 10 06:19:15 2014 From: gregor.bregenzer at gmail.com (Gregor Bregenzer) Date: Wed, 10 Sep 2014 08:19:15 +0200 Subject: [Freeipa-users] sssd receives another uid/gid after disabled HBAC rule In-Reply-To: <20140908071751.GN4089@localhost.localdomain> References: <20140908071751.GN4089@localhost.localdomain> Message-ID: Hello Sumit, i think maybe there is a different problem i just discovered by accident. As stated in the first email, i have an AD trust with FreeIPA that receives all POSIX attributes from AD, but i get different values: On the FreeIPA server that has the AD trust (ipa1.linux.intern) i get the correct GID (=10000, this is the AD group linuxusers) that is set in AD, but on the client (linux1.linux.intern) i get another one ( = 10005): ipa1.linux.intern ~~~~ [root at ipa1 httpd]# getent passwd user1 at aaa user1 at aaa.intern:*:10005: 10000:user1:/home/aaa.intern/user1:/bin/bash -bash-4.2$ id uid=10005(user1 at aaa.intern) gid=10000(linuxusers at aaa.intern) groups=10000(linuxusers at aaa.intern),1933000004(ad_users) ~~~~ linux1.linux.intern ~~~~~~~~ [root at linux1 sssd]# getent passwd user1 at aaa user1 at aaa.intern:*:10005:10005::/home/user1 at aaa.intern:/bin/bash [user1 at aaa.intern@linux1 ~]$ id uid=10005(user1 at aaa.intern) gid=10005(user1 at aaa.intern) Gruppen=10005(user1 at aaa.intern),1933000004(ad_users) Logfile on ipa1.linux.intern sssd_nss.log (Wed Sep 10 08:14:42 2014) [sssd[nss]] [nss_cmd_getbynam] (0x0400): Running command [17] with input [user1 at aaa.intern]. ? (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): name 'user1 at aaa.intern' matched expression for domain 'aaa.intern', user is user1 ? (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [user1] from [aaa.intern] ? (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sss_ncache_check_str] (0x2000): Checking negative cache for [NCE/USER/aaa.intern/user1] ? (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [user1 at aaa.intern] ? (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7fe19e562700 ? (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x7fe19e562830 ? 03?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Running timer event 0x7fe19e562700 "ltdb_callback" ? (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Destroying timer event 0x7fe19e562830 "ltdb_timeout" ?va r/?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Ending timer event 0x7fe19e562700 "ltdb_callback" ? ?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [check_cache] (0x0400): Cached entry is valid, returning.. ? (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0400): Returning info for user [user1 at aaa.intern] ? (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x7fe19e563d40][21] ? ---------- Logfile on linux1.linux.intern sssd_nss.log (Wed Sep 10 08:14:42 2014) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): name 'user1 at aaa' matched expression for domain 'aaa.intern', user is user1 ? (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [nss_cmd_getpwnam] (0x0100): Requesting info for [user1] from [aaa.intern] ? (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sss_ncache_check_str] (0x2000): Checking negative cache for [NCE/USER/aaa.intern/user1] ? (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [user1 at aaa.intern] ? (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x20e2c20 ? (W? ? 00?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x20e2590 ? (W? ? (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Running timer event 0x20e2c20 "ltdb_callback" ? (W? ? (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Destroying timer event 0x20e2590 "ltdb_timeout" ? (W? ? (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Ending timer event 0x20e2c20 "ltdb_callback" ? (W? ? (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sss_dp_issue_request] (0x0400): Issuing request for [0x432730:1:user1 at aaa.intern] ? (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sss_dp_get_account_msg] (0x0400): Creating request for [aaa.intern][4097][1][name=user1] ? (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sbus_add_timeout] (0x2000): 0x20d72e0 ? (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sss_dp_internal_get_send] (0x0400): Entering request [0x432730:1:user1 at aaa.intern] ? 01?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sbus_remove_timeout] (0x2000): 0x20d72e0 ? (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sbus_dispatch] (0x4000): dbus conn: 20DB0F0 ? (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sbus_dispatch] (0x4000): Dispatching. ? (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sss_dp_get_reply] (0x1000): Got reply from Data Provider - DP error code: 0 errno: 0 error message: Success ? (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sss_ncache_check_str] (0x2000): Checking negative cache for [NCE/USER/aaa.intern/user1] ? (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [user1 at aaa.intern] ? (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x20e8530 ? (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x20e85e0 ? (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Running timer event 0x20e8530 "ltdb_callback" ? (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Destroying timer event 0x20e85e0 "ltdb_timeout" ? (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Ending timer event 0x20e8530 "ltdb_callback" ? (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0400): Returning info for user [user1 at aaa.intern] ? 02?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sss_dp_req_destructor] (0x0400): Deleting request: [0x432730:1:user1 at aaa.intern] ? :/?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x20e44a0][20] ? ?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x20e44a0][20] ? (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [client_recv] (0x0200): Client disconnected! ?/v ar?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [client_destructor] (0x2000): Terminated client [0x20e44a0][20] ~~~~ I think i need to get this one right before the HBAC rule - right? Here is my ipa1.linux.intern sssd.conf: ~~~~~~~~~ [domain/linux.intern] debug_level=9 cache_credentials = True krb5_store_password_if_offline = True ipa_domain = linux.intern id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = ipa1.linux.intern chpass_provider = ipa ipa_server = ipa1.linux.intern ipa_server_mode = True ldap_tls_cacert = /etc/ipa/ca.crt [sssd] debug_level=9 services = nss, sudo, pam, ssh, pac config_file_version = 2 subdomains_provider = ipa domains = linux.intern [nss] debug_level=9 homedir_substring = /home [pam] debug_level=9 [sudo] [autofs] [ssh] [pac] debug_level=9 [ifp] ~~~~~~~~~~~~~~ Here's my linux1.linux.intern sssd.conf ~~~~~ [domain/linux.intern] debug_level=9 cache_credentials = False krb5_store_password_if_offline = False ipa_domain = linux.intern id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = linux1.linux.intern chpass_provider = ipa ipa_dyndns_update = True ipa_server = _srv_, ipa1.linux.intern ldap_tls_cacert = /etc/ipa/ca.crt use_fully_qualified_domains = True # For the SUDO integration sudo_provider = ldap ldap_uri = ldap://ipa1.linux.intern ldap_sudo_search_base = ou=sudoers,dc=linux,dc=intern ldap_sasl_mech = GSSAPI ldap_sasl_authid = host/linux1.linux.intern ldap_sasl_realm = LINUX.INTERN krb5_server = ipa1.linux.intern [sssd] debug_level=9 services = nss, pam, ssh, sudo config_file_version = 2 #default_domain_suffix=aaa.intern domains = linux.intern [nss] debug_level=9 override_homedir = /home/%u override_shell = /bin/bash [pam] debug_level=9 [sudo] [autofs] [ssh] debug_level=9 [pac] debug_level=9 ~~~~ I used the following command to create the AD trust: ipa trust-add --type=ad aaa.intern --admin Administrator --password --range-type ipa-ad-trust-posix Do you need any other debug information? Thanks! Gregor 2014-09-08 9:17 GMT+02:00 Sumit Bose : > On Sun, Sep 07, 2014 at 11:41:16PM +0200, Gregor Bregenzer wrote: >> Hi! >> >> I have an AD trust with FreeIPA 4.0.1 and defined a HBAC rule for a >> specific user group (=ad_users which is an posix group that has an >> external group as member) to login on a specific client >> (=linux1.linux.intern). >> >> The problem is: once i disable the rule and the AD user is not allowed >> to login anymore, the user on the client gets another uid and gid via >> sssd. >> >> I use the posix attributes from AD, which will get received by sssd perfectly. >> The client is running on CentOS 6.5 and uses sssd 1.9.2.129.el6_5.4 >> AD domain = aaa.intern >> IPA domain = linux.intern >> AD-User: user1 (uid=1005,gid=10005) >> >> Here an example: >> ---------------------------- >> 1.) disable the hbac rule and the default allow_all rule: >> 2.) check the uid/gid on the client (=linux1.linux.intern) and it looks fine: >> >> [root at linux1 sssd]# getent passwd user1 at aaa >> user1 at aaa.intern:*:10005:10005::/home/user1 at aaa.intern:/bin/bash >> >> 3.) Login with ssh to client as user1. It will be denied upon correct >> password input and ssh sessions closes. Up until now everything as >> expected. But now: >> >> 4.) check for the uid/gid on the client - something totally different. >> It now also receives the Firstname and Lastname from AD, latter is >> empty: >> >> [root at linux1 sssd]# getent passwd user1 at aaa >> user1 at aaa.intern:*:11601:11601:user1:/home/user1 at aaa.intern:/bin/bash >> >> 5.) Enable the hbac rule and login works, but the unexpected uid/gid >> stays the same: >> >> login as: user1 at aaa >> user1 at aaa@192.168.0.100's password: >> login as: user1 at aaa >> user1 at aaa@192.168.0.100's password: >> Last failed login: Sun Sep 7 23:19:49 CEST 2014 from 192.168.0.26 on ssh:notty >> There were 2 failed login attempts since the last successful login. >> Creating home directory for user1 at aaa. >> Last login: Sun Sep 7 23:21:02 2014 from 192.168.0.26 >> [user1 at aaa.intern@linux1 ~]$ id >> uid=11601(user1 at aaa.intern) gid=11601(user1 at aaa.intern) >> Gruppen=11601(user1 at aaa.intern),1933000004(ad_users) >> [user1 at aaa.intern@linux1 ~]$ >> --------------------------------- >> >> Anyone have a clue what might be the problem? > > I would expect some kind of collision, but to be sure I need the SSSD > log files. Please try to reproduce the switch and send me the log file, > if possilbe with debug_level=9. > > bye, > Sumit > >> >> Here's the sssd.conf: >> [root at linux1 sssd]# cat /etc/sssd/sssd.conf >> [domain/linux.intern] >> debug_level=6 >> cache_credentials = False >> krb5_store_password_if_offline = False >> ipa_domain = linux.intern >> id_provider = ipa >> auth_provider = ipa >> access_provider = ipa >> ipa_hostname = linux1.linux.intern >> chpass_provider = ipa >> ipa_dyndns_update = True >> ipa_server = _srv_, ipa1.linux.intern >> ldap_tls_cacert = /etc/ipa/ca.crt >> use_fully_qualified_domains = True >> # For the SUDO integration >> sudo_provider = ldap >> ldap_uri = ldap://ipa1.linux.intern >> ldap_sudo_search_base = ou=sudoers,dc=linux,dc=intern >> ldap_sasl_mech = GSSAPI >> ldap_sasl_authid = host/linux1.linux.intern >> ldap_sasl_realm = LINUX.INTERN >> krb5_server = ipa1.linux.intern >> entry_cache_sudo_timeout = 30 >> [sssd] >> debug_level=6 >> services = nss, pam, ssh, sudo >> config_file_version = 2 >> default_domain_suffix=aaa.intern >> domains = linux.intern >> [nss] >> debug_level=9 >> override_homedir = /home/%u >> override_shell = /bin/bash >> [pam] >> debug_level=6 >> [sudo] >> debug_level=6 >> [autofs] >> >> [ssh] >> debug_level=6 >> [pac] >> >> >> >> Thanks! >> Gregor >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go To http://freeipa.org for more info on the project > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project From gregor.bregenzer at gmail.com Wed Sep 10 15:05:45 2014 From: gregor.bregenzer at gmail.com (Gregor Bregenzer) Date: Wed, 10 Sep 2014 17:05:45 +0200 Subject: [Freeipa-users] sssd receives another uid/gid after disabled HBAC rule In-Reply-To: References: <20140908071751.GN4089@localhost.localdomain> Message-ID: I added the correct logfiles now - sorry! On linux1.linux.intern 1.) service sssd stop; rm -f /var/lib/sss/db/* ; service sssd start 2.) getent passwd user1 at aaa Logfile sssd_linux.intern.log ~~~~~~~~~~~~ (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sbus_dispatch] (0x4000): dbus conn: 23510F0 (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sbus_dispatch] (0x4000): Dispatching. (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sbus_message_handler] (0x4000): Received SBUS method [getDomains] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [be_get_subdomains] (0x0400): Got get subdomains [forced][aaa] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [objectclass=ipaNTTrustedDomain][cn=trusts,dc=linux,dc=intern]. (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaNTFlatName] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaNTTrustedDomainSID] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 8 (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_process_result] (0x2000): Trace: sh[0x234f5c0], connected[1], ops[0x233b9e0], ldap[0x233f620] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=aaa.intern,cn=ad,cn=trusts,dc=linux,dc=intern]. (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaNTFlatName] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaNTTrustedDomainSID] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_process_result] (0x2000): Trace: sh[0x234f5c0], connected[1], ops[0x233b9e0], ldap[0x233f620] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [objectclass=ipaIDRange][cn=ranges,cn=etc,dc=linux,dc=intern]. (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaBaseID] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaBaseRID] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSecondaryBaseRID] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaIDRangeSize] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaNTTrustedDomainSID] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 9 (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_process_result] (0x2000): Trace: sh[0x234f5c0], connected[1], ops[0x234e550], ldap[0x233f620] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_process_result] (0x2000): Trace: sh[0x234f5c0], connected[1], ops[0x234e550], ldap[0x233f620] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=LINUX.INTERN_id_range,cn=ranges,cn=etc,dc=linux,dc=intern]. (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectClass] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaBaseID] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaBaseRID] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaSecondaryBaseRID] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaIDRangeSize] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_process_result] (0x2000): Trace: sh[0x234f5c0], connected[1], ops[0x234e550], ldap[0x233f620] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=AAA.INTERN_id_range,cn=ranges,cn=etc,dc=linux,dc=intern]. (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectClass] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaBaseID] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaBaseRID] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaIDRangeSize] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaNTTrustedDomainSID] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_process_result] (0x2000): Trace: sh[0x234f5c0], connected[1], ops[0x234e550], ldap[0x233f620] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x233cc00 (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x2370a30 (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): Running timer event 0x233cc00 "ltdb_callback" (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): Destroying timer event 0x2370a30 "ltdb_timeout" (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): Ending timer event 0x233cc00 "ltdb_callback" (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): start ldb transaction (nesting: 0) (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): commit ldb transaction (nesting: 0) (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x2370210 (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x234eba0 (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): Running timer event 0x2370210 "ltdb_callback" (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): Destroying timer event 0x234eba0 "ltdb_timeout" (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): Ending timer event 0x2370210 "ltdb_callback" (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [objectclass=ipaNTDomainAttrs][cn=ad,cn=etc,dc=linux,dc=intern]. (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaNTFlatName] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaNTSecurityIdentifier] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 10 (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_process_result] (0x2000): Trace: sh[0x234f5c0], connected[1], ops[0x234e550], ldap[0x233f620] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_process_result] (0x2000): Trace: sh[0x234f5c0], connected[1], ops[0x234e550], ldap[0x233f620] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_parse_entry] (0x4000): OriginalDN: [cn=linux.intern,cn=ad,cn=etc,dc=linux,dc=intern]. (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaNTFlatName] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaNTSecurityIdentifier] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_process_result] (0x2000): Trace: sh[0x234f5c0], connected[1], ops[0x234e550], ldap[0x233f620] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x2376530 (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x23765e0 (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): Running timer event 0x2376530 "ltdb_callback" (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): Destroying timer event 0x23765e0 "ltdb_timeout" (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): Ending timer event 0x2376530 "ltdb_callback" (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_id_op_destroy] (0x4000): releasing operation connection (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [get_subdomains_callback] (0x0400): Backend returned: (0, 0, ) [Success] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_process_result] (0x2000): Trace: sh[0x234f5c0], connected[1], ops[(nil)], ldap[0x233f620] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sbus_dispatch] (0x4000): dbus conn: 23510F0 (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sbus_dispatch] (0x4000): Dispatching. (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [be_get_account_info] (0x0100): Got request for [4097][1][name=user1] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ipa_s2n_exop_send] (0x0400): Executing extended operation (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ipa_s2n_exop_send] (0x2000): ldap_extended_operation sent, msgid = 11 (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_process_result] (0x2000): Trace: sh[0x234f5c0], connected[1], ops[0x234d040], ldap[0x233f620] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_EXTENDED] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ipa_s2n_exop_done] (0x0400): ldap_extended_operation result: Success(0), (null) (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): start ldb transaction (nesting: 0) (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x236f750 (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x236f870 (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): Running timer event 0x236f750 "ltdb_callback" (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): Destroying timer event 0x236f870 "ltdb_timeout" (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): Ending timer event 0x236f750 "ltdb_callback" (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sysdb_search_user_by_name] (0x0400): No such entry (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): start ldb transaction (nesting: 1) (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x2373ce0 (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x236f630 (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): Running timer event 0x2373ce0 "ltdb_callback" (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): Destroying timer event 0x236f630 "ltdb_timeout" (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): Ending timer event 0x2373ce0 "ltdb_callback" (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sysdb_search_group_by_name] (0x0400): No such entry (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x2373d80 (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x236fb00 (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): Running timer event 0x2373d80 "ltdb_callback" (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): Destroying timer event 0x236fb00 "ltdb_timeout" (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): Ending timer event 0x2373d80 "ltdb_callback" (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sysdb_search_user_by_uid] (0x0400): No such entry (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): start ldb transaction (nesting: 2) (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x2381240 (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x2381360 (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): Running timer event 0x2381240 "ltdb_callback" (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): Destroying timer event 0x2381360 "ltdb_timeout" (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): Ending timer event 0x2381240 "ltdb_callback" (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): start ldb transaction (nesting: 2) (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x2381360 (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x236f870 (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): Running timer event 0x2381360 "ltdb_callback" (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): Destroying timer event 0x236f870 "ltdb_timeout" (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): Ending timer event 0x2381360 "ltdb_callback" (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x236f870 (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x2381360 (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): Running timer event 0x236f870 "ltdb_callback" (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): Destroying timer event 0x2381360 "ltdb_timeout" (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): Ending timer event 0x236f870 "ltdb_callback" (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): commit ldb transaction (nesting: 1) (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [ldb] (0x4000): commit ldb transaction (nesting: 0) (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_id_op_done] (0x4000): releasing operation connection (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_process_result] (0x2000): Trace: sh[0x234f5c0], connected[1], ops[(nil)], ldap[0x233f620] (Wed Sep 10 17:04:24 2014) [sssd[be[linux.intern]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! (Wed Sep 10 17:04:28 2014) [sssd[be[linux.intern]]] [sbus_dispatch] (0x4000): dbus conn: 230E920 (Wed Sep 10 17:04:28 2014) [sssd[be[linux.intern]]] [sbus_dispatch] (0x4000): Dispatching. (Wed Sep 10 17:04:28 2014) [sssd[be[linux.intern]]] [sbus_message_handler] (0x4000): Received SBUS method [ping] ~~~~~~~~~~~~ Thanks, Gregor 2014-09-10 8:19 GMT+02:00 Gregor Bregenzer : > Hello Sumit, > i think maybe there is a different problem i just discovered by > accident. As stated in the first email, i have an AD trust with > FreeIPA that receives all POSIX attributes from AD, but i get > different values: > On the FreeIPA server that has the AD trust (ipa1.linux.intern) i get > the correct GID (=10000, this is the AD group linuxusers) that is set > in AD, but on the client (linux1.linux.intern) i get another one ( = > 10005): > > ipa1.linux.intern > ~~~~ > [root at ipa1 httpd]# getent passwd user1 at aaa > user1 at aaa.intern:*:10005: > 10000:user1:/home/aaa.intern/user1:/bin/bash > > -bash-4.2$ id > uid=10005(user1 at aaa.intern) gid=10000(linuxusers at aaa.intern) > groups=10000(linuxusers at aaa.intern),1933000004(ad_users) > ~~~~ > > linux1.linux.intern > ~~~~~~~~ > [root at linux1 sssd]# getent passwd user1 at aaa > user1 at aaa.intern:*:10005:10005::/home/user1 at aaa.intern:/bin/bash > > [user1 at aaa.intern@linux1 ~]$ id > uid=10005(user1 at aaa.intern) gid=10005(user1 at aaa.intern) > Gruppen=10005(user1 at aaa.intern),1933000004(ad_users) > > Logfile on ipa1.linux.intern sssd_nss.log > (Wed Sep 10 08:14:42 2014) [sssd[nss]] [nss_cmd_getbynam] (0x0400): > Running command [17] with input [user1 at aaa.intern]. > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sss_parse_name_for_domains] > (0x0200): name 'user1 at aaa.intern' matched expression for domain > 'aaa.intern', user is user1 ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [nss_cmd_getbynam] (0x0100): > Requesting info for [user1] from [aaa.intern] > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sss_ncache_check_str] > (0x2000): Checking negative cache for [NCE/USER/aaa.intern/user1] > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [nss_cmd_getpwnam_search] > (0x0100): Requesting info for [user1 at aaa.intern] > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Added timed > event "ltdb_callback": 0x7fe19e562700 > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Added timed > event "ltdb_timeout": 0x7fe19e562830 > ? > 03?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Running > timer event 0x7fe19e562700 "ltdb_callback" > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Destroying > timer event 0x7fe19e562830 "ltdb_timeout" > ?va > r/?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Ending timer > event 0x7fe19e562700 "ltdb_callback" > ? > ?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [check_cache] (0x0400): > Cached entry is valid, returning.. > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [nss_cmd_getpwnam_search] > (0x0400): Returning info for user [user1 at aaa.intern] > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [reset_idle_timer] (0x4000): > Idle timer re-set for client [0x7fe19e563d40][21] > ? > > ---------- > Logfile on linux1.linux.intern sssd_nss.log > > (Wed Sep 10 08:14:42 2014) [sssd[nss]] [sss_parse_name_for_domains] > (0x0200): name 'user1 at aaa' matched expression for domain 'aaa.intern', > user is user1 ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [nss_cmd_getpwnam] (0x0100): > Requesting info for [user1] from [aaa.intern] > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sss_ncache_check_str] > (0x2000): Checking negative cache for [NCE/USER/aaa.intern/user1] > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [nss_cmd_getpwnam_search] > (0x0100): Requesting info for [user1 at aaa.intern] > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Added timed > event "ltdb_callback": 0x20e2c20 > ? > (W? > > ? > 00?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Added timed > event "ltdb_timeout": 0x20e2590 > ? > (W? > > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Running > timer event 0x20e2c20 "ltdb_callback" > ? > (W? > > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Destroying > timer event 0x20e2590 "ltdb_timeout" > ? > (W? > > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Ending timer > event 0x20e2c20 "ltdb_callback" > ? > (W? > > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sss_dp_issue_request] > (0x0400): Issuing request for [0x432730:1:user1 at aaa.intern] > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sss_dp_get_account_msg] > (0x0400): Creating request for [aaa.intern][4097][1][name=user1] > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sbus_add_timeout] (0x2000): > 0x20d72e0 > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sss_dp_internal_get_send] > (0x0400): Entering request [0x432730:1:user1 at aaa.intern] > ? > 01?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sbus_remove_timeout] > (0x2000): 0x20d72e0 > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sbus_dispatch] (0x4000): > dbus conn: 20DB0F0 > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sbus_dispatch] (0x4000): > Dispatching. > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sss_dp_get_reply] (0x1000): > Got reply from Data Provider - DP error code: 0 errno: 0 error > message: Success > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sss_ncache_check_str] > (0x2000): Checking negative cache for [NCE/USER/aaa.intern/user1] > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [nss_cmd_getpwnam_search] > (0x0100): Requesting info for [user1 at aaa.intern] > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Added timed > event "ltdb_callback": 0x20e8530 > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Added timed > event "ltdb_timeout": 0x20e85e0 > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Running > timer event 0x20e8530 "ltdb_callback" > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Destroying > timer event 0x20e85e0 "ltdb_timeout" > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Ending timer > event 0x20e8530 "ltdb_callback" > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [nss_cmd_getpwnam_search] > (0x0400): Returning info for user [user1 at aaa.intern] > ? > 02?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sss_dp_req_destructor] > (0x0400): Deleting request: [0x432730:1:user1 at aaa.intern] > ? > :/?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [reset_idle_timer] (0x4000): > Idle timer re-set for client [0x20e44a0][20] > ? > ?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [reset_idle_timer] (0x4000): > Idle timer re-set for client [0x20e44a0][20] > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [client_recv] (0x0200): > Client disconnected! > ?/v > ar?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [client_destructor] > (0x2000): Terminated client [0x20e44a0][20] > > ~~~~ > > > I think i need to get this one right before the HBAC rule - right? > > > Here is my ipa1.linux.intern sssd.conf: > ~~~~~~~~~ > [domain/linux.intern] > debug_level=9 > cache_credentials = True > krb5_store_password_if_offline = True > ipa_domain = linux.intern > id_provider = ipa > auth_provider = ipa > access_provider = ipa > ipa_hostname = ipa1.linux.intern > chpass_provider = ipa > ipa_server = ipa1.linux.intern > ipa_server_mode = True > ldap_tls_cacert = /etc/ipa/ca.crt > [sssd] > debug_level=9 > services = nss, sudo, pam, ssh, pac > config_file_version = 2 > subdomains_provider = ipa > domains = linux.intern > [nss] > debug_level=9 > homedir_substring = /home > > [pam] > debug_level=9 > [sudo] > > [autofs] > > [ssh] > > [pac] > debug_level=9 > [ifp] > > ~~~~~~~~~~~~~~ > > Here's my linux1.linux.intern sssd.conf > ~~~~~ > [domain/linux.intern] > debug_level=9 > cache_credentials = False > krb5_store_password_if_offline = False > ipa_domain = linux.intern > id_provider = ipa > auth_provider = ipa > access_provider = ipa > ipa_hostname = linux1.linux.intern > chpass_provider = ipa > ipa_dyndns_update = True > ipa_server = _srv_, ipa1.linux.intern > ldap_tls_cacert = /etc/ipa/ca.crt > use_fully_qualified_domains = True > # For the SUDO integration > sudo_provider = ldap > ldap_uri = ldap://ipa1.linux.intern > ldap_sudo_search_base = ou=sudoers,dc=linux,dc=intern > ldap_sasl_mech = GSSAPI > ldap_sasl_authid = host/linux1.linux.intern > ldap_sasl_realm = LINUX.INTERN > krb5_server = ipa1.linux.intern > > [sssd] > debug_level=9 > services = nss, pam, ssh, sudo > config_file_version = 2 > #default_domain_suffix=aaa.intern > domains = linux.intern > [nss] > debug_level=9 > override_homedir = /home/%u > override_shell = /bin/bash > [pam] > debug_level=9 > [sudo] > > [autofs] > > [ssh] > debug_level=9 > [pac] > debug_level=9 > > ~~~~ > > > I used the following command to create the AD trust: > > ipa trust-add --type=ad aaa.intern --admin Administrator > --password --range-type ipa-ad-trust-posix > > Do you need any other debug information? > > > Thanks! > Gregor > > 2014-09-08 9:17 GMT+02:00 Sumit Bose : >> On Sun, Sep 07, 2014 at 11:41:16PM +0200, Gregor Bregenzer wrote: >>> Hi! >>> >>> I have an AD trust with FreeIPA 4.0.1 and defined a HBAC rule for a >>> specific user group (=ad_users which is an posix group that has an >>> external group as member) to login on a specific client >>> (=linux1.linux.intern). >>> >>> The problem is: once i disable the rule and the AD user is not allowed >>> to login anymore, the user on the client gets another uid and gid via >>> sssd. >>> >>> I use the posix attributes from AD, which will get received by sssd perfectly. >>> The client is running on CentOS 6.5 and uses sssd 1.9.2.129.el6_5.4 >>> AD domain = aaa.intern >>> IPA domain = linux.intern >>> AD-User: user1 (uid=1005,gid=10005) >>> >>> Here an example: >>> ---------------------------- >>> 1.) disable the hbac rule and the default allow_all rule: >>> 2.) check the uid/gid on the client (=linux1.linux.intern) and it looks fine: >>> >>> [root at linux1 sssd]# getent passwd user1 at aaa >>> user1 at aaa.intern:*:10005:10005::/home/user1 at aaa.intern:/bin/bash >>> >>> 3.) Login with ssh to client as user1. It will be denied upon correct >>> password input and ssh sessions closes. Up until now everything as >>> expected. But now: >>> >>> 4.) check for the uid/gid on the client - something totally different. >>> It now also receives the Firstname and Lastname from AD, latter is >>> empty: >>> >>> [root at linux1 sssd]# getent passwd user1 at aaa >>> user1 at aaa.intern:*:11601:11601:user1:/home/user1 at aaa.intern:/bin/bash >>> >>> 5.) Enable the hbac rule and login works, but the unexpected uid/gid >>> stays the same: >>> >>> login as: user1 at aaa >>> user1 at aaa@192.168.0.100's password: >>> login as: user1 at aaa >>> user1 at aaa@192.168.0.100's password: >>> Last failed login: Sun Sep 7 23:19:49 CEST 2014 from 192.168.0.26 on ssh:notty >>> There were 2 failed login attempts since the last successful login. >>> Creating home directory for user1 at aaa. >>> Last login: Sun Sep 7 23:21:02 2014 from 192.168.0.26 >>> [user1 at aaa.intern@linux1 ~]$ id >>> uid=11601(user1 at aaa.intern) gid=11601(user1 at aaa.intern) >>> Gruppen=11601(user1 at aaa.intern),1933000004(ad_users) >>> [user1 at aaa.intern@linux1 ~]$ >>> --------------------------------- >>> >>> Anyone have a clue what might be the problem? >> >> I would expect some kind of collision, but to be sure I need the SSSD >> log files. Please try to reproduce the switch and send me the log file, >> if possilbe with debug_level=9. >> >> bye, >> Sumit >> >>> >>> Here's the sssd.conf: >>> [root at linux1 sssd]# cat /etc/sssd/sssd.conf >>> [domain/linux.intern] >>> debug_level=6 >>> cache_credentials = False >>> krb5_store_password_if_offline = False >>> ipa_domain = linux.intern >>> id_provider = ipa >>> auth_provider = ipa >>> access_provider = ipa >>> ipa_hostname = linux1.linux.intern >>> chpass_provider = ipa >>> ipa_dyndns_update = True >>> ipa_server = _srv_, ipa1.linux.intern >>> ldap_tls_cacert = /etc/ipa/ca.crt >>> use_fully_qualified_domains = True >>> # For the SUDO integration >>> sudo_provider = ldap >>> ldap_uri = ldap://ipa1.linux.intern >>> ldap_sudo_search_base = ou=sudoers,dc=linux,dc=intern >>> ldap_sasl_mech = GSSAPI >>> ldap_sasl_authid = host/linux1.linux.intern >>> ldap_sasl_realm = LINUX.INTERN >>> krb5_server = ipa1.linux.intern >>> entry_cache_sudo_timeout = 30 >>> [sssd] >>> debug_level=6 >>> services = nss, pam, ssh, sudo >>> config_file_version = 2 >>> default_domain_suffix=aaa.intern >>> domains = linux.intern >>> [nss] >>> debug_level=9 >>> override_homedir = /home/%u >>> override_shell = /bin/bash >>> [pam] >>> debug_level=6 >>> [sudo] >>> debug_level=6 >>> [autofs] >>> >>> [ssh] >>> debug_level=6 >>> [pac] >>> >>> >>> >>> Thanks! >>> Gregor >>> >>> -- >>> Manage your subscription for the Freeipa-users mailing list: >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> Go To http://freeipa.org for more info on the project >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go To http://freeipa.org for more info on the project From uncommonkat at gmail.com Wed Sep 10 16:02:32 2014 From: uncommonkat at gmail.com (Kat) Date: Wed, 10 Sep 2014 09:02:32 -0700 Subject: [Freeipa-users] 4.0.2-1 not ready for primetime or testing? Message-ID: <54107618.6040102@gmail.com> Trying to do some testing with 4.0.2-1 on FC22/rawhide -- the install blows up: Configuring directory server (dirsrv): Estimated time 10 seconds [1/3]: configuring ssl for ds instance [2/3]: restarting directory server ipa : CRITICAL Failed to restart the directory server. See the installation log for details. and from the logs -- any ideas? 2014-09-10T15:58:42Z DEBUG stderr= 2014-09-10T15:58:42Z CRITICAL Failed to restart the directory server. See the installation log for details. 2014-09-10T15:58:42Z DEBUG File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 639, in run_script return_value = main_function() File "/usr/sbin/ipa-server-install", line 1127, in main ds.enable_ssl() File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line 351, in enable_ssl self.start_creation(runtime=10) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 367, in start_creation method() File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line 515, in __restart_instance self.restart(self.serverid) File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line 509, in restart raise e 2014-09-10T15:58:42Z DEBUG The ipa-server-install command failed, exception: SystemExit: 1 From rmeggins at redhat.com Wed Sep 10 16:11:00 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 10 Sep 2014 10:11:00 -0600 Subject: [Freeipa-users] 4.0.2-1 not ready for primetime or testing? In-Reply-To: <54107618.6040102@gmail.com> References: <54107618.6040102@gmail.com> Message-ID: <54107814.2080307@redhat.com> On 09/10/2014 10:02 AM, Kat wrote: > Trying to do some testing with 4.0.2-1 on FC22/rawhide -- the install > blows up: > > Configuring directory server (dirsrv): Estimated time 10 seconds > [1/3]: configuring ssl for ds instance > [2/3]: restarting directory server > ipa : CRITICAL Failed to restart the directory server. See the > installation log for details. > > > and from the logs -- any ideas? What's in /var/log/dirsrv/slapd-*/errors? > > 2014-09-10T15:58:42Z DEBUG stderr= > 2014-09-10T15:58:42Z CRITICAL Failed to restart the directory server. > See the installation log for details. > 2014-09-10T15:58:42Z DEBUG File > "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", > line 639, in run_script > return_value = main_function() > > File "/usr/sbin/ipa-server-install", line 1127, in main > ds.enable_ssl() > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", > line 351, in enable_ssl self.start_creation(runtime=10) > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line > 367, in start_creation method() > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", > line 515, in __restart_instance self.restart(self.serverid) > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", > line 509, in restart raise e > > 2014-09-10T15:58:42Z DEBUG The ipa-server-install command failed, > exception: SystemExit: 1 > From darran.lofthouse at jboss.com Wed Sep 10 16:48:06 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Wed, 10 Sep 2014 17:48:06 +0100 Subject: [Freeipa-users] Force ticket type to des3-cbc-sha1 Message-ID: <541080C6.7020803@jboss.com> Hi there, Hi there any quick way to force the ticket type obtained by kinit to des3-cbc-sha1? Regards, Darran Lofthouse. From rcritten at redhat.com Wed Sep 10 17:16:37 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 10 Sep 2014 13:16:37 -0400 Subject: [Freeipa-users] Force ticket type to des3-cbc-sha1 In-Reply-To: <541080C6.7020803@jboss.com> References: <541080C6.7020803@jboss.com> Message-ID: <54108775.40005@redhat.com> Darran Lofthouse wrote: > Hi there, > > Hi there any quick way to force the ticket type obtained by kinit to > des3-cbc-sha1? For all users everywhere, on a particular host, or for a particular application? rob From darran.lofthouse at jboss.com Wed Sep 10 17:24:24 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Wed, 10 Sep 2014 18:24:24 +0100 Subject: [Freeipa-users] Force ticket type to des3-cbc-sha1 In-Reply-To: <54108775.40005@redhat.com> References: <541080C6.7020803@jboss.com> <54108775.40005@redhat.com> Message-ID: <54108948.3070303@jboss.com> This is just for testing, ideally for one user but will take anything ;-) On 10/09/14 18:16, Rob Crittenden wrote: > Darran Lofthouse wrote: >> Hi there, >> >> Hi there any quick way to force the ticket type obtained by kinit to >> des3-cbc-sha1? > > For all users everywhere, on a particular host, or for a particular > application? > > rob From darran.lofthouse at jboss.com Wed Sep 10 17:31:38 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Wed, 10 Sep 2014 18:31:38 +0100 Subject: [Freeipa-users] Force ticket type to des3-cbc-sha1 In-Reply-To: <54108948.3070303@jboss.com> References: <541080C6.7020803@jboss.com> <54108775.40005@redhat.com> <54108948.3070303@jboss.com> Message-ID: <54108AFA.8010606@jboss.com> Actually ignore me for a minute, I may be looking at this from the wrong side !! On 10/09/14 18:24, Darran Lofthouse wrote: > This is just for testing, ideally for one user but will take anything ;-) > > On 10/09/14 18:16, Rob Crittenden wrote: >> Darran Lofthouse wrote: >>> Hi there, >>> >>> Hi there any quick way to force the ticket type obtained by kinit to >>> des3-cbc-sha1? >> >> For all users everywhere, on a particular host, or for a particular >> application? >> >> rob From darran.lofthouse at jboss.com Wed Sep 10 17:40:30 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Wed, 10 Sep 2014 18:40:30 +0100 Subject: [Freeipa-users] Force ticket type to des3-cbc-sha1 In-Reply-To: <54108AFA.8010606@jboss.com> References: <541080C6.7020803@jboss.com> <54108775.40005@redhat.com> <54108948.3070303@jboss.com> <54108AFA.8010606@jboss.com> Message-ID: <54108D0E.50500@jboss.com> Thanks, was looking at the wrong side - just needed to re-export the keytab for my service using des3-cbc-sha1 instead. On 10/09/14 18:31, Darran Lofthouse wrote: > Actually ignore me for a minute, I may be looking at this from the wrong > side !! > > On 10/09/14 18:24, Darran Lofthouse wrote: >> This is just for testing, ideally for one user but will take anything ;-) >> >> On 10/09/14 18:16, Rob Crittenden wrote: >>> Darran Lofthouse wrote: >>>> Hi there, >>>> >>>> Hi there any quick way to force the ticket type obtained by kinit to >>>> des3-cbc-sha1? >>> >>> For all users everywhere, on a particular host, or for a particular >>> application? >>> >>> rob From traiano at gmail.com Wed Sep 10 21:12:14 2014 From: traiano at gmail.com (Traiano Welcome) Date: Thu, 11 Sep 2014 00:12:14 +0300 Subject: [Freeipa-users] Integrating FreeIPA with ActiveDirectory (Windows 2008 R2) Message-ID: Hi List I've been following the AD integration guide for IPAv3 here: http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup However, when I reach the "Add trust with AD domain" step I get the following error: --- [root at ipa ~]# ipa trust-add --type=ad mhatest.local --admin Administrator --password Active directory domain administrator's password: ipa: ERROR: CIFS server communication error: code "-1073741801", message "Memory allocation error" (both may be "None") --- ... And I'm at a loss for how to interpret this :-) Details on my setup: - Windows 2008 R2 AD DC - CentOS Linux 6.5 IPA server (installed from yum repos) I've attached the output of "ipa trust-add" with the debug flag set. There is also a summary of the packet conversation between the IPA server and the AD DC during the run of "ipa trust-add": --- [root at ipa ~]# tcpdump host 172.16.107.109 and host 172.16.107.108 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 00:05:28.624337 IP ipa.linux.mhatest.local.48394 > kwthqtstad001.mhatest.local.domain: 0+ A? ipa.linux.mhatest.local. (41) 00:05:28.624857 IP kwthqtstad001.mhatest.local.domain > ipa.linux.mhatest.local.48394: 0 NXDomain* 0/1/0 (121) 00:05:33.594937 ARP, Request who-has ipa.linux.mhatest.local (00:50:56:9c:18:d4 (oui Unknown)) tell kwthqtstad001.mhatest.local, length 46 00:05:33.594952 ARP, Reply ipa.linux.mhatest.local is-at 00:50:56:9c:18:d4 (oui Unknown), length 28 00:06:05.056522 IP ipa.linux.mhatest.local.54679 > kwthqtstad001.mhatest.local.domain: 0+ SRV? _ldap._tcp.linux.mhatest.local. (48) 00:06:05.057022 IP kwthqtstad001.mhatest.local.domain > ipa.linux.mhatest.local.54679: 0* 1/0/0 SRV ipa.linux.mhatest.local.:389 0 100 (91) 00:06:09.599671 ARP, Request who-has ipa.linux.mhatest.local (00:50:56:9c:18:d4 (oui Unknown)) tell kwthqtstad001.mhatest.local, length 46 00:06:09.599686 ARP, Reply ipa.linux.mhatest.local is-at 00:50:56:9c:18:d4 (oui Unknown), length 28 00:06:15.376853 IP ipa.linux.mhatest.local.44400 > kwthqtstad001.mhatest.local.domain: 0+ SRV? _ldap._tcp.linux.mhatest.local. (48) 00:06:15.377319 IP kwthqtstad001.mhatest.local.domain > ipa.linux.mhatest.local.44400: 0* 1/0/0 SRV ipa.linux.mhatest.local.:389 0 100 (91) 00:06:20.375747 ARP, Request who-has kwthqtstad001.mhatest.local tell ipa.linux.mhatest.local, length 28 00:06:20.376025 ARP, Reply kwthqtstad001.mhatest.local is-at 00:15:5d:0a:0d:8b (oui Unknown), length 46 ---- Any help on how to fix this and establish the AD trust relationship would be much appreciated! Many thanks in advance, Traiano The DNS configuration scenario I'm using is : http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#If_IPA_is_subdomain_of_AD -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dump1.log Type: application/octet-stream Size: 10679 bytes Desc: not available URL: From abokovoy at redhat.com Wed Sep 10 21:31:51 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 11 Sep 2014 00:31:51 +0300 Subject: [Freeipa-users] Integrating FreeIPA with ActiveDirectory (Windows 2008 R2) In-Reply-To: References: Message-ID: <20140910213151.GC2541@redhat.com> On Thu, 11 Sep 2014, Traiano Welcome wrote: >Hi List > >I've been following the AD integration guide for IPAv3 here: >http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup >However, when I reach the "Add trust with AD domain" step I get the >following error: > >--- >[root at ipa ~]# ipa trust-add --type=ad mhatest.local --admin Administrator >--password >Active directory domain administrator's password: >ipa: ERROR: CIFS server communication error: code "-1073741801", > message "Memory allocation error" (both may be "None") >--- > >... And I'm at a loss for how to interpret this :-) Details on my setup: Please follow http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Debugging_trust to provide useful debugging information. >- Windows 2008 R2 AD DC >- CentOS Linux 6.5 IPA server (installed from yum repos) Ideally you'd need to use RHEL 7 or CentOS 7 for trusts as IPA version 3.3 is more mature in this regard. -- / Alexander Bokovoy From trevor.t.kates at dom.com Wed Sep 10 21:58:27 2014 From: trevor.t.kates at dom.com (Trevor T Kates (Services - 6)) Date: Wed, 10 Sep 2014 21:58:27 +0000 Subject: [Freeipa-users] FreeIPA, SSSD, sudo and Local Users Message-ID: Hi all: I'm using FreeIPA 3.0 under CentOS 6.5 and I'm trying to solve a bit of a quirky problem. From what I've read thus far, sudo under SSSD can't provide sudo rules for local users that are not part of the directory. To get around this, I've been using the sudo-ldap.conf file to provide sudo with direct access to the directory. This, however, can't make use of service discovery, so if the first server in the ldap_uri list is taken down, sudo delays for the length of the timeout set. My idea for getting around this has been to use sudo in SSSD for users that are in the directory and let sudo-ldap take care of local users with a line in nsswitch.conf like this: sudoers: files sss ldap My problem now seems to be that the ldap query is still run even if a successful hit is made to sssd. Changing the line in nsswitch.conf to: sudoers: files sss [success=return] ldap doesn't seem to actually work. Does anyone have pointers on how I can resolve this particular problem? Thanks! Trevor T. Kates CONFIDENTIALITY NOTICE: This electronic message contains information which may be legally confidential and or privileged and does not in any case represent a firm ENERGY COMMODITY bid or offer relating thereto which binds the sender without an additional express written confirmation to that effect. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. From wgraboyes at cenic.org Wed Sep 10 22:50:43 2014 From: wgraboyes at cenic.org (William Graboyes) Date: Wed, 10 Sep 2014 15:50:43 -0700 Subject: [Freeipa-users] Certs. Message-ID: <5410D5C3.7020805@cenic.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello list, I have been fruitlessly searching for some information, especially related to Certs, namely how to replace the self signed certs with certs from a trusted CA? As we are moving forward into productionizing of our free-ipa install, I am finding information on the net to be a bit lacking. There is also the possibility that I am not looking in the right places, or using the correct search terms. Any help on this front would be greatly appreciated. Thanks, Bill -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJUENXDAAoJEJFMz73A1+zr5vQP/1Zt7S+5C+B+dgzI1UJWgxGj KGh3pvn0zmp3Ge6zCtQ6Is+jQRTZPp4xH8sW1KMdfmBD1l9qcf3GgqH529UHfe5X DGl8xC1h+yKr8DUm0ckl5fCcs9bpyjXIisCJzBB31ne4wsveeEQN0tVhsYvZ+zH3 98j/uRpnXEnDGOJq1e1h5bkHPTTTDgBSUVD1+oLKg4LxYaacbU4q85BVXBAB73SX NunN8snqZ0fVVPMAz4ejd5kIhU+RCfIkzVuP+V2/9W/iLs2bte3eV1h/ppweuI7x CRSEi/UPEC+cG0pF8ImodSN70nG0bjqDf95eg9VnAHXQXlY83dIOm5M9SkeiQEdP bWmKEE4kejEewBJtkCIR3ldckVAU+x4xLTk3tpSi6rZwdDNBC+E4m9PXhMpT2hFW 3QlxaMDlXjKFEgv9c36NR5sNs4YY7cOLAbaGaFcuiBQcsjXk6A2I/u6C5RQkhFpq Eqhgz/5Ow+oRAHvE/mhORORHaweCcZbR5oMNeQS8Tanju/1VcDtYy12+1U1QX1vY 1nUaTtAsPflYyJSudrFclLZFw4YaC4d5SoSnN+LDiOcmpz2AIfHlmwc2AMZW/c2G nHcbSw0JNrfS1bHK6H9AO6q2LORWji8Usf3xTcZba+vC3eD/v0UPmISUW1kVWdKh Jrc6QM2LipgK5KmpjTKa =t75e -----END PGP SIGNATURE----- From wgraboyes at cenic.org Wed Sep 10 22:52:43 2014 From: wgraboyes at cenic.org (William Graboyes) Date: Wed, 10 Sep 2014 15:52:43 -0700 Subject: [Freeipa-users] Branding Message-ID: <5410D63B.9060301@cenic.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi List, I am looking into changing the branding on the free-ipa GUI interface. This is something that is being requested by my management, considering that we are asking users to trust an e-mail prodding them to change their password. I don't see an easy method in the GUI interface for changing the logo. I was wondering if anyone else has had need for these changes, and what steps they may have taken to change the branding. Thanks, Bill -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJUENY7AAoJEJFMz73A1+zrxuoP/0NUQdonXJFSrxxy1/3vVHuW Mbf/kHo3tCn26GGkNBYgVqa5FJ7hri9eEsRhIR/krJP7mbRk9XoRJ7XcGF8YO+4c O5MtJftMU6vueOWQZx6JZXm9+bqhvDnT24kwq2V19IrQX5Q0JcRY4EOzLc5BgBqR bSlNbhxBj0H+WFdU7z4jkfiSbOoRcYSIV+nlX7hZK9G7WHVqcYRi2iaTQ1kMX5ju oMTbkOrSKK8EixNamvHdr9y4UrxQhEks9Pa1xBHo0sZm2/YTeIX4KRWBs4dT/KKt flSa93AF/8CnPeQHGCHP37FMJLtct7ySRuldo09AQULNN51fqBZlbHpMGSILmbt+ BIrRaG3tZ4cB5rOfYlJ7UBnTFO7o101a1BJIxXWahsg39QBYsEQFswOPmR3ivvfg bJnPbJ7WqB5ir7b21iQJ1kkNcpeScdFhebMlEqskfZ92CBJu/S6Av25mxy4fku4b 1HhOAXK9s1LDR8l8LhwxVOAAIs2ILQ5SxFl6u/hNsgvdC0M5tPtvCnpgvpvoMBB/ E+poXBWbVQkkxl8AI+IERQaUx4Ou+ihwhMrGuBjXry6zts9J3b+cgIHzbbS3thZf PooMTTiiy7R6gZiZdvqjl0G4QmJvegjHjWySZZwIjPKZAeEb7fI8jEpLOSM54KQ6 sqSR7rg3TB0P91YAMqXo =AscS -----END PGP SIGNATURE----- From cwhittl at gmail.com Wed Sep 10 22:55:56 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Wed, 10 Sep 2014 17:55:56 -0500 Subject: [Freeipa-users] Certs. In-Reply-To: <5410D5C3.7020805@cenic.org> References: <5410D5C3.7020805@cenic.org> Message-ID: Search the list for a post by me and certs... Basically there is a install flag that will do all the work for you once you have it the cert in the right format. On Sep 10, 2014 5:53 PM, "William Graboyes" wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hello list, > > I have been fruitlessly searching for some information, especially > related to Certs, namely how to replace the self signed certs with > certs from a trusted CA? As we are moving forward into > productionizing of our free-ipa install, I am finding information on > the net to be a bit lacking. There is also the possibility that I am > not looking in the right places, or using the correct search terms. > Any help on this front would be greatly appreciated. > > Thanks, > Bill > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: GPGTools - https://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCgAGBQJUENXDAAoJEJFMz73A1+zr5vQP/1Zt7S+5C+B+dgzI1UJWgxGj > KGh3pvn0zmp3Ge6zCtQ6Is+jQRTZPp4xH8sW1KMdfmBD1l9qcf3GgqH529UHfe5X > DGl8xC1h+yKr8DUm0ckl5fCcs9bpyjXIisCJzBB31ne4wsveeEQN0tVhsYvZ+zH3 > 98j/uRpnXEnDGOJq1e1h5bkHPTTTDgBSUVD1+oLKg4LxYaacbU4q85BVXBAB73SX > NunN8snqZ0fVVPMAz4ejd5kIhU+RCfIkzVuP+V2/9W/iLs2bte3eV1h/ppweuI7x > CRSEi/UPEC+cG0pF8ImodSN70nG0bjqDf95eg9VnAHXQXlY83dIOm5M9SkeiQEdP > bWmKEE4kejEewBJtkCIR3ldckVAU+x4xLTk3tpSi6rZwdDNBC+E4m9PXhMpT2hFW > 3QlxaMDlXjKFEgv9c36NR5sNs4YY7cOLAbaGaFcuiBQcsjXk6A2I/u6C5RQkhFpq > Eqhgz/5Ow+oRAHvE/mhORORHaweCcZbR5oMNeQS8Tanju/1VcDtYy12+1U1QX1vY > 1nUaTtAsPflYyJSudrFclLZFw4YaC4d5SoSnN+LDiOcmpz2AIfHlmwc2AMZW/c2G > nHcbSw0JNrfS1bHK6H9AO6q2LORWji8Usf3xTcZba+vC3eD/v0UPmISUW1kVWdKh > Jrc6QM2LipgK5KmpjTKa > =t75e > -----END PGP SIGNATURE----- > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tompos at martos.bme.hu Wed Sep 10 23:10:48 2014 From: tompos at martos.bme.hu (Tamas Papp) Date: Thu, 11 Sep 2014 01:10:48 +0200 Subject: [Freeipa-users] json api docs Message-ID: <5410DA78.2030802@martos.bme.hu> hi All, Is there an offficial API documentation available? Also is there a simple way to logon and run commands through API without a kerberos ticket? Thanks, tamas From wgraboyes at cenic.org Wed Sep 10 23:26:01 2014 From: wgraboyes at cenic.org (William Graboyes) Date: Wed, 10 Sep 2014 16:26:01 -0700 Subject: [Freeipa-users] Certs. In-Reply-To: References: <5410D5C3.7020805@cenic.org> Message-ID: <5410DE09.4050700@cenic.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Chris, Thank you for the suggestion. Looking at http://www.redhat.com/archives/freeipa-users/2014-August/msg00334.html Installing a new, third party cert requires a reinstall of IPA? IPA Devs, that is a bit silly don't you think? A year or two in the cert expires, now you have to start from scratch? I will wait for some form of response before I attempt at eating crow in front of management. I forgot to mention, free-ipa version ipa-server-3.0.0-37.el6.x86_64. On Wed Sep 10 15:55:56 2014, Chris Whittle wrote: > Search the list for a post by me and certs... Basically there is a install > flag that will do all the work for you once you have it the cert in the > right format. > On Sep 10, 2014 5:53 PM, "William Graboyes" wrote: > >> > > ********* *BEGIN ENCRYPTED or SIGNED PART* ********* > > Hello list, > > I have been fruitlessly searching for some information, especially > related to Certs, namely how to replace the self signed certs with > certs from a trusted CA? As we are moving forward into > productionizing of our free-ipa install, I am finding information on > the net to be a bit lacking. There is also the possibility that I am > not looking in the right places, or using the correct search terms. > Any help on this front would be greatly appreciated. > > Thanks, > Bill > > > ********** *END ENCRYPTED or SIGNED PART* ********** > >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go To http://freeipa.org for more info on the project >> > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJUEN4JAAoJEJFMz73A1+zrjNAP/1aZOjhp6c6JwWXUjBE4Pt4i u6Z1BRFNYgIc5/aNsPAKrdzMqQgTjgWJvSh5UCON0VdmuIx7pQLP7nIlaCCXTRRK pKx2Cez5Ho7Lwlsb87WW3bzjcyKGX5Wd3+VJdQ6ugYJTpVS4gMxh8atZCV613EY6 FuMk1RS6qlWM2Ut3SjmaAZK3jTw2pUsJzW3zzB271i6sJqAMZTh7Lrie6QcGqAON eLGlWBZuCaeULUuQmArVZiP3qPnH5NuccvXLFVbX7D1+SM8XeLWrTklN1bfX2HF0 QCFlizb+bBga/d5cEaCv7R8v6m46R4wS779KSUV1jn9PpHISNcmLafv6dTAb6F+5 RBADwBP6coh5LrOJJh0pIByx9dYRbdif/BSH4VMcvfvFMs/EO1PAsGLWQPwoNfYO 0SzUV1R47JW9NGzeTxja+byKz9hwGtAT2FIw0NibR+M1FydPD9k3LTjTnQWgeSro ks3AUPDy/hj+E72QDORj+/Zvy3sw8wDFVRw2LH/jaDmWbWhZUG4riC3w2egPjcSK KIYQ7L/fdeN6S9jt8UcUf1YDHgfLU+iTgqyssr54RufVuM9iBNOkoWxxI0Q9oyMF NDKiOY8rs2rBu6x09NiHG0BoX1LQzrrKQFQ4ao48w2RH3ocFCgQbsEHZ18uIfo4Y CB5M63nykETHkkR3ZFkd =8T1Y -----END PGP SIGNATURE----- From cwhittl at gmail.com Wed Sep 10 23:30:10 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Wed, 10 Sep 2014 18:30:10 -0500 Subject: [Freeipa-users] Certs. In-Reply-To: <5410DE09.4050700@cenic.org> References: <5410D5C3.7020805@cenic.org> <5410DE09.4050700@cenic.org> Message-ID: There is other instructions but I could never get a fully successful setup until the that one. On Sep 10, 2014 6:26 PM, "William Graboyes" wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hi Chris, > > Thank you for the suggestion. Looking at > http://www.redhat.com/archives/freeipa-users/2014-August/msg00334.html > > Installing a new, third party cert requires a reinstall of IPA? IPA > Devs, that is a bit silly don't you think? A year or two in the cert > expires, now you have to start from scratch? I will wait for some form > of response before I attempt at eating crow in front of management. > > I forgot to mention, free-ipa version ipa-server-3.0.0-37.el6.x86_64. > > > > On Wed Sep 10 15:55:56 2014, Chris Whittle wrote: > > Search the list for a post by me and certs... Basically there is a > install > > flag that will do all the work for you once you have it the cert in the > > right format. > > On Sep 10, 2014 5:53 PM, "William Graboyes" wrote: > > > >> > > > > ********* *BEGIN ENCRYPTED or SIGNED PART* ********* > > > > Hello list, > > > > I have been fruitlessly searching for some information, especially > > related to Certs, namely how to replace the self signed certs with > > certs from a trusted CA? As we are moving forward into > > productionizing of our free-ipa install, I am finding information on > > the net to be a bit lacking. There is also the possibility that I am > > not looking in the right places, or using the correct search terms. > > Any help on this front would be greatly appreciated. > > > > Thanks, > > Bill > > > > > > ********** *END ENCRYPTED or SIGNED PART* ********** > > > >> > >> -- > >> Manage your subscription for the Freeipa-users mailing list: > >> https://www.redhat.com/mailman/listinfo/freeipa-users > >> Go To http://freeipa.org for more info on the project > >> > > > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: GPGTools - https://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCgAGBQJUEN4JAAoJEJFMz73A1+zrjNAP/1aZOjhp6c6JwWXUjBE4Pt4i > u6Z1BRFNYgIc5/aNsPAKrdzMqQgTjgWJvSh5UCON0VdmuIx7pQLP7nIlaCCXTRRK > pKx2Cez5Ho7Lwlsb87WW3bzjcyKGX5Wd3+VJdQ6ugYJTpVS4gMxh8atZCV613EY6 > FuMk1RS6qlWM2Ut3SjmaAZK3jTw2pUsJzW3zzB271i6sJqAMZTh7Lrie6QcGqAON > eLGlWBZuCaeULUuQmArVZiP3qPnH5NuccvXLFVbX7D1+SM8XeLWrTklN1bfX2HF0 > QCFlizb+bBga/d5cEaCv7R8v6m46R4wS779KSUV1jn9PpHISNcmLafv6dTAb6F+5 > RBADwBP6coh5LrOJJh0pIByx9dYRbdif/BSH4VMcvfvFMs/EO1PAsGLWQPwoNfYO > 0SzUV1R47JW9NGzeTxja+byKz9hwGtAT2FIw0NibR+M1FydPD9k3LTjTnQWgeSro > ks3AUPDy/hj+E72QDORj+/Zvy3sw8wDFVRw2LH/jaDmWbWhZUG4riC3w2egPjcSK > KIYQ7L/fdeN6S9jt8UcUf1YDHgfLU+iTgqyssr54RufVuM9iBNOkoWxxI0Q9oyMF > NDKiOY8rs2rBu6x09NiHG0BoX1LQzrrKQFQ4ao48w2RH3ocFCgQbsEHZ18uIfo4Y > CB5M63nykETHkkR3ZFkd > =8T1Y > -----END PGP SIGNATURE----- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Sep 10 23:41:23 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 10 Sep 2014 19:41:23 -0400 Subject: [Freeipa-users] Integrating FreeIPA with ActiveDirectory (Windows 2008 R2) In-Reply-To: <20140910213151.GC2541@redhat.com> References: <20140910213151.GC2541@redhat.com> Message-ID: <5410E1A3.2090300@redhat.com> On 09/10/2014 05:31 PM, Alexander Bokovoy wrote: > On Thu, 11 Sep 2014, Traiano Welcome wrote: >> Hi List >> >> I've been following the AD integration guide for IPAv3 here: >> http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup >> However, when I reach the "Add trust with AD domain" step I get the >> following error: >> >> --- >> [root at ipa ~]# ipa trust-add --type=ad mhatest.local --admin >> Administrator >> --password >> Active directory domain administrator's password: >> ipa: ERROR: CIFS server communication error: code "-1073741801", >> message "Memory allocation error" (both may be "None") >> --- >> >> ... And I'm at a loss for how to interpret this :-) Details on my setup: > Please follow > http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Debugging_trust > to provide useful debugging information. > >> - Windows 2008 R2 AD DC >> - CentOS Linux 6.5 IPA server (installed from yum repos) > Ideally you'd need to use RHEL 7 or CentOS 7 for trusts as IPA version > 3.3 is more mature in this regard. > FYI https://fedorahosted.org/freeipa/ticket/3266 -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Wed Sep 10 23:42:29 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 10 Sep 2014 19:42:29 -0400 Subject: [Freeipa-users] Branding In-Reply-To: <5410D63B.9060301@cenic.org> References: <5410D63B.9060301@cenic.org> Message-ID: <5410E1E5.5010008@redhat.com> On 09/10/2014 06:52 PM, William Graboyes wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hi List, > > I am looking into changing the branding on the free-ipa GUI interface. > This is something that is being requested by my management, > considering that we are asking users to trust an e-mail prodding them > to change their password. I don't see an easy method in the GUI > interface for changing the logo. I was wondering if anyone else has > had need for these changes, and what steps they may have taken to > change the branding. Is it just the logo or other things too, like colors and styles? > > Thanks, > Bill > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: GPGTools - https://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCgAGBQJUENY7AAoJEJFMz73A1+zrxuoP/0NUQdonXJFSrxxy1/3vVHuW > Mbf/kHo3tCn26GGkNBYgVqa5FJ7hri9eEsRhIR/krJP7mbRk9XoRJ7XcGF8YO+4c > O5MtJftMU6vueOWQZx6JZXm9+bqhvDnT24kwq2V19IrQX5Q0JcRY4EOzLc5BgBqR > bSlNbhxBj0H+WFdU7z4jkfiSbOoRcYSIV+nlX7hZK9G7WHVqcYRi2iaTQ1kMX5ju > oMTbkOrSKK8EixNamvHdr9y4UrxQhEks9Pa1xBHo0sZm2/YTeIX4KRWBs4dT/KKt > flSa93AF/8CnPeQHGCHP37FMJLtct7ySRuldo09AQULNN51fqBZlbHpMGSILmbt+ > BIrRaG3tZ4cB5rOfYlJ7UBnTFO7o101a1BJIxXWahsg39QBYsEQFswOPmR3ivvfg > bJnPbJ7WqB5ir7b21iQJ1kkNcpeScdFhebMlEqskfZ92CBJu/S6Av25mxy4fku4b > 1HhOAXK9s1LDR8l8LhwxVOAAIs2ILQ5SxFl6u/hNsgvdC0M5tPtvCnpgvpvoMBB/ > E+poXBWbVQkkxl8AI+IERQaUx4Ou+ihwhMrGuBjXry6zts9J3b+cgIHzbbS3thZf > PooMTTiiy7R6gZiZdvqjl0G4QmJvegjHjWySZZwIjPKZAeEb7fI8jEpLOSM54KQ6 > sqSR7rg3TB0P91YAMqXo > =AscS > -----END PGP SIGNATURE----- > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Wed Sep 10 23:47:37 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 10 Sep 2014 19:47:37 -0400 Subject: [Freeipa-users] Certs. In-Reply-To: <5410D5C3.7020805@cenic.org> References: <5410D5C3.7020805@cenic.org> Message-ID: <5410E319.4070804@redhat.com> On 09/10/2014 06:50 PM, William Graboyes wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hello list, > > I have been fruitlessly searching for some information, especially > related to Certs, namely how to replace the self signed certs with > certs from a trusted CA? This is an install time decision so when you deploy a new production environment you will need to use the ipa-server-install with the related arguments to do the chaining. > As we are moving forward into > productionizing of our free-ipa install, I am finding information on > the net to be a bit lacking. There is also the possibility that I am > not looking in the right places, or using the correct search terms. > Any help on this front would be greatly appreciated. The ability to replace the cert from being a self signed to a chained is a feature that is coming in IPA 4.1 The design page is here: http://www.freeipa.org/page/V4/CA_certificate_renewal What distro are you planning to use? It is considered for the next release of RHEL. > > Thanks, > Bill > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: GPGTools - https://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCgAGBQJUENXDAAoJEJFMz73A1+zr5vQP/1Zt7S+5C+B+dgzI1UJWgxGj > KGh3pvn0zmp3Ge6zCtQ6Is+jQRTZPp4xH8sW1KMdfmBD1l9qcf3GgqH529UHfe5X > DGl8xC1h+yKr8DUm0ckl5fCcs9bpyjXIisCJzBB31ne4wsveeEQN0tVhsYvZ+zH3 > 98j/uRpnXEnDGOJq1e1h5bkHPTTTDgBSUVD1+oLKg4LxYaacbU4q85BVXBAB73SX > NunN8snqZ0fVVPMAz4ejd5kIhU+RCfIkzVuP+V2/9W/iLs2bte3eV1h/ppweuI7x > CRSEi/UPEC+cG0pF8ImodSN70nG0bjqDf95eg9VnAHXQXlY83dIOm5M9SkeiQEdP > bWmKEE4kejEewBJtkCIR3ldckVAU+x4xLTk3tpSi6rZwdDNBC+E4m9PXhMpT2hFW > 3QlxaMDlXjKFEgv9c36NR5sNs4YY7cOLAbaGaFcuiBQcsjXk6A2I/u6C5RQkhFpq > Eqhgz/5Ow+oRAHvE/mhORORHaweCcZbR5oMNeQS8Tanju/1VcDtYy12+1U1QX1vY > 1nUaTtAsPflYyJSudrFclLZFw4YaC4d5SoSnN+LDiOcmpz2AIfHlmwc2AMZW/c2G > nHcbSw0JNrfS1bHK6H9AO6q2LORWji8Usf3xTcZba+vC3eD/v0UPmISUW1kVWdKh > Jrc6QM2LipgK5KmpjTKa > =t75e > -----END PGP SIGNATURE----- > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Wed Sep 10 23:49:24 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 10 Sep 2014 19:49:24 -0400 Subject: [Freeipa-users] Certs. In-Reply-To: <5410DE09.4050700@cenic.org> References: <5410D5C3.7020805@cenic.org> <5410DE09.4050700@cenic.org> Message-ID: <5410E384.4070703@redhat.com> On 09/10/2014 07:26 PM, William Graboyes wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hi Chris, > > Thank you for the suggestion. Looking at > http://www.redhat.com/archives/freeipa-users/2014-August/msg00334.html > > Installing a new, third party cert requires a reinstall of IPA? IPA > Devs, that is a bit silly don't you think? A year or two in the cert > expires, now you have to start from scratch? I will wait for some form > of response before I attempt at eating crow in front of management. > > I forgot to mention, free-ipa version ipa-server-3.0.0-37.el6.x86_64. Since 3.0 internal certs are issued for 2 years and are renewed automatically. The root cert is valid for more than two years (AFAIR it is 20). > > > > On Wed Sep 10 15:55:56 2014, Chris Whittle wrote: >> Search the list for a post by me and certs... Basically there is a install >> flag that will do all the work for you once you have it the cert in the >> right format. >> On Sep 10, 2014 5:53 PM, "William Graboyes" wrote: >> >> ********* *BEGIN ENCRYPTED or SIGNED PART* ********* >> >> Hello list, >> >> I have been fruitlessly searching for some information, especially >> related to Certs, namely how to replace the self signed certs with >> certs from a trusted CA? As we are moving forward into >> productionizing of our free-ipa install, I am finding information on >> the net to be a bit lacking. There is also the possibility that I am >> not looking in the right places, or using the correct search terms. >> Any help on this front would be greatly appreciated. >> >> Thanks, >> Bill >> >> >> ********** *END ENCRYPTED or SIGNED PART* ********** >> >>> -- >>> Manage your subscription for the Freeipa-users mailing list: >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> Go To http://freeipa.org for more info on the project >>> >> >> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: GPGTools - https://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCgAGBQJUEN4JAAoJEJFMz73A1+zrjNAP/1aZOjhp6c6JwWXUjBE4Pt4i > u6Z1BRFNYgIc5/aNsPAKrdzMqQgTjgWJvSh5UCON0VdmuIx7pQLP7nIlaCCXTRRK > pKx2Cez5Ho7Lwlsb87WW3bzjcyKGX5Wd3+VJdQ6ugYJTpVS4gMxh8atZCV613EY6 > FuMk1RS6qlWM2Ut3SjmaAZK3jTw2pUsJzW3zzB271i6sJqAMZTh7Lrie6QcGqAON > eLGlWBZuCaeULUuQmArVZiP3qPnH5NuccvXLFVbX7D1+SM8XeLWrTklN1bfX2HF0 > QCFlizb+bBga/d5cEaCv7R8v6m46R4wS779KSUV1jn9PpHISNcmLafv6dTAb6F+5 > RBADwBP6coh5LrOJJh0pIByx9dYRbdif/BSH4VMcvfvFMs/EO1PAsGLWQPwoNfYO > 0SzUV1R47JW9NGzeTxja+byKz9hwGtAT2FIw0NibR+M1FydPD9k3LTjTnQWgeSro > ks3AUPDy/hj+E72QDORj+/Zvy3sw8wDFVRw2LH/jaDmWbWhZUG4riC3w2egPjcSK > KIYQ7L/fdeN6S9jt8UcUf1YDHgfLU+iTgqyssr54RufVuM9iBNOkoWxxI0Q9oyMF > NDKiOY8rs2rBu6x09NiHG0BoX1LQzrrKQFQ4ao48w2RH3ocFCgQbsEHZ18uIfo4Y > CB5M63nykETHkkR3ZFkd > =8T1Y > -----END PGP SIGNATURE----- > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From wgraboyes at cenic.org Wed Sep 10 23:49:57 2014 From: wgraboyes at cenic.org (William Graboyes) Date: Wed, 10 Sep 2014 16:49:57 -0700 Subject: [Freeipa-users] Branding In-Reply-To: <5410E1E5.5010008@redhat.com> References: <5410D63B.9060301@cenic.org> <5410E1E5.5010008@redhat.com> Message-ID: <5410E3A5.9070709@cenic.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Dimitri, Yeah just the logo should do, I believe I found it at `/usr/share/ipa/ui/images/ipa-logo.png`. I am more just making sure it is allowed. Thanks, Bill On Wed Sep 10 16:42:29 2014, Dmitri Pal wrote: > On 09/10/2014 06:52 PM, William Graboyes wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> Hi List, >> >> I am looking into changing the branding on the free-ipa GUI interface. >> This is something that is being requested by my management, >> considering that we are asking users to trust an e-mail prodding them >> to change their password. I don't see an easy method in the GUI >> interface for changing the logo. I was wondering if anyone else has >> had need for these changes, and what steps they may have taken to >> change the branding. > Is it just the logo or other things too, like colors and styles? > > >> >> Thanks, >> Bill >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG/MacGPG2 v2.0.22 (Darwin) >> Comment: GPGTools - https://gpgtools.org >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >> >> iQIcBAEBCgAGBQJUENY7AAoJEJFMz73A1+zrxuoP/0NUQdonXJFSrxxy1/3vVHuW >> Mbf/kHo3tCn26GGkNBYgVqa5FJ7hri9eEsRhIR/krJP7mbRk9XoRJ7XcGF8YO+4c >> O5MtJftMU6vueOWQZx6JZXm9+bqhvDnT24kwq2V19IrQX5Q0JcRY4EOzLc5BgBqR >> bSlNbhxBj0H+WFdU7z4jkfiSbOoRcYSIV+nlX7hZK9G7WHVqcYRi2iaTQ1kMX5ju >> oMTbkOrSKK8EixNamvHdr9y4UrxQhEks9Pa1xBHo0sZm2/YTeIX4KRWBs4dT/KKt >> flSa93AF/8CnPeQHGCHP37FMJLtct7ySRuldo09AQULNN51fqBZlbHpMGSILmbt+ >> BIrRaG3tZ4cB5rOfYlJ7UBnTFO7o101a1BJIxXWahsg39QBYsEQFswOPmR3ivvfg >> bJnPbJ7WqB5ir7b21iQJ1kkNcpeScdFhebMlEqskfZ92CBJu/S6Av25mxy4fku4b >> 1HhOAXK9s1LDR8l8LhwxVOAAIs2ILQ5SxFl6u/hNsgvdC0M5tPtvCnpgvpvoMBB/ >> E+poXBWbVQkkxl8AI+IERQaUx4Ou+ihwhMrGuBjXry6zts9J3b+cgIHzbbS3thZf >> PooMTTiiy7R6gZiZdvqjl0G4QmJvegjHjWySZZwIjPKZAeEb7fI8jEpLOSM54KQ6 >> sqSR7rg3TB0P91YAMqXo >> =AscS >> -----END PGP SIGNATURE----- >> > > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJUEOOlAAoJEJFMz73A1+zrASEP/0gBH7ZilDBY/UEVrGxFDLkx FnGpCniouAF05b4EvvKz6KH+S4DElXgpVJOYPeufLtFg3xYLmhrzRI5uPG1Bpp8D 9caoEqsyqiKz96+gqglrcvjptwCLNuzBuC46l8QJLhL6ROPwB72Xwh8JVfUzMn9e gIn2McnsCIz2/tZOLgDqXraw0dIsvxS4T0aRO4XkRpEZ/EkozYzxJHEHHuCoL5GO P7ITGroyPZaCojj0UJaCMjeK1ddIHS2anot64qkQUQiIBkCjvBZpqFbpQumoGd5T ZbdpM/yRkhHFgHPEjQn0+cxBzhNEqfTfotU1zBwAQEu3GbpxAXmbILrJJpOup8hf mOdCmkAv2Pwne5x4481qn0mnobmLZYyCTjRLgKttMGz4NbH0E1WkQeLN523Q8wyC seQf+Jtxvt6K+ZbD4RlcVTAKUJfvBiQQwJsK9b8++vjebv4Dhrr+vp3wTZBHEpRt gGU/5eXUWAyEiYv3Ce5aAjtTX88fGr3J95wdTmAWv4vmQ7D20FvVKuUEkRz5q/Hy xYTxUhK9ccmzvkzxAeUkuwOR7tVKp3rP5eM9K3vG1+YhT2xYa/I7JpNIwRmYmnHM TLCia5mEZAFBZtsI0up6DXGUAu356+kRe1tjvU8TgsbAmKAGPgqZZDbhwDmGsNee wo6IQ6Itxp6ucU5m2Qet =wjKX -----END PGP SIGNATURE----- From wgraboyes at cenic.org Wed Sep 10 23:57:48 2014 From: wgraboyes at cenic.org (William Graboyes) Date: Wed, 10 Sep 2014 16:57:48 -0700 Subject: [Freeipa-users] Certs. In-Reply-To: <5410E384.4070703@redhat.com> References: <5410D5C3.7020805@cenic.org> <5410DE09.4050700@cenic.org> <5410E384.4070703@redhat.com> Message-ID: <5410E57C.5030204@cenic.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Dmitri, Production Environment is going to be RH 6.5, We are still evaluating the usage of systemd. More like we are taking a wait and see approach to to systemd, while actively testing it. Thanks, Bill On Wed Sep 10 16:49:24 2014, Dmitri Pal wrote: > On 09/10/2014 07:26 PM, William Graboyes wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> Hi Chris, >> >> Thank you for the suggestion. Looking at >> http://www.redhat.com/archives/freeipa-users/2014-August/msg00334.html >> >> Installing a new, third party cert requires a reinstall of IPA? IPA >> Devs, that is a bit silly don't you think? A year or two in the cert >> expires, now you have to start from scratch? I will wait for some form >> of response before I attempt at eating crow in front of management. >> >> I forgot to mention, free-ipa version ipa-server-3.0.0-37.el6.x86_64. > > Since 3.0 internal certs are issued for 2 years and are renewed > automatically. The root cert is valid for more than two years (AFAIR > it is 20). > > > >> >> >> >> On Wed Sep 10 15:55:56 2014, Chris Whittle wrote: >>> Search the list for a post by me and certs... Basically there is a >>> install >>> flag that will do all the work for you once you have it the cert in the >>> right format. >>> On Sep 10, 2014 5:53 PM, "William Graboyes" >>> wrote: >>> >>> ********* *BEGIN ENCRYPTED or SIGNED PART* ********* >>> >>> Hello list, >>> >>> I have been fruitlessly searching for some information, especially >>> related to Certs, namely how to replace the self signed certs with >>> certs from a trusted CA? As we are moving forward into >>> productionizing of our free-ipa install, I am finding information on >>> the net to be a bit lacking. There is also the possibility that I am >>> not looking in the right places, or using the correct search terms. >>> Any help on this front would be greatly appreciated. >>> >>> Thanks, >>> Bill >>> >>> >>> ********** *END ENCRYPTED or SIGNED PART* ********** >>> >>>> -- >>>> Manage your subscription for the Freeipa-users mailing list: >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>> Go To http://freeipa.org for more info on the project >>>> >>> >>> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG/MacGPG2 v2.0.22 (Darwin) >> Comment: GPGTools - https://gpgtools.org >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >> >> iQIcBAEBCgAGBQJUEN4JAAoJEJFMz73A1+zrjNAP/1aZOjhp6c6JwWXUjBE4Pt4i >> u6Z1BRFNYgIc5/aNsPAKrdzMqQgTjgWJvSh5UCON0VdmuIx7pQLP7nIlaCCXTRRK >> pKx2Cez5Ho7Lwlsb87WW3bzjcyKGX5Wd3+VJdQ6ugYJTpVS4gMxh8atZCV613EY6 >> FuMk1RS6qlWM2Ut3SjmaAZK3jTw2pUsJzW3zzB271i6sJqAMZTh7Lrie6QcGqAON >> eLGlWBZuCaeULUuQmArVZiP3qPnH5NuccvXLFVbX7D1+SM8XeLWrTklN1bfX2HF0 >> QCFlizb+bBga/d5cEaCv7R8v6m46R4wS779KSUV1jn9PpHISNcmLafv6dTAb6F+5 >> RBADwBP6coh5LrOJJh0pIByx9dYRbdif/BSH4VMcvfvFMs/EO1PAsGLWQPwoNfYO >> 0SzUV1R47JW9NGzeTxja+byKz9hwGtAT2FIw0NibR+M1FydPD9k3LTjTnQWgeSro >> ks3AUPDy/hj+E72QDORj+/Zvy3sw8wDFVRw2LH/jaDmWbWhZUG4riC3w2egPjcSK >> KIYQ7L/fdeN6S9jt8UcUf1YDHgfLU+iTgqyssr54RufVuM9iBNOkoWxxI0Q9oyMF >> NDKiOY8rs2rBu6x09NiHG0BoX1LQzrrKQFQ4ao48w2RH3ocFCgQbsEHZ18uIfo4Y >> CB5M63nykETHkkR3ZFkd >> =8T1Y >> -----END PGP SIGNATURE----- >> > > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJUEOV8AAoJEJFMz73A1+zrgwAQAJkx74MPOVvbnrG+dmY8w7ok J/6NWt9Rb/pS9gRrN7iFopni3BoHuLFC6ltwD6KoWllYClwoXke4T0FQ/nU6Ar6M tsuQMYxP0boxhQua2uF/kZ/atMolxoNMShNixXd4dnWtBlpl+R+V58FtfjSGfy49 qX2Ge6g6wEFATwKReM1KpKCFIfO/yq/wM4NLvvBd6WShJXh6TQBE44y9aXLLJIlP DApoLnMHaopNZITSNKt1t7dgw6ne9O370nQwOxR5L0peH8bxla0FLJ57vX+RCC0f 3EV/tQHKiXET1RqWE927tfPf171Xcq7sdjLRUL2JTVCK3zPZUuVg9WmuqrLUArhW f1XRpn1MM2e0xn18rvHfuRZr2IIUuPE+RfVcQMgEcgtSYuDNlVYCO/ONyTQHxJ/E JRkN6nDOZ1nlItJlrrT0MVgdMKQLG7IxkvOndGsyOShD/XvvjQYlQbDvRvodnAlc JUIlcC3PbGZh+CRymXzu6M7DYceE5rJ/HzbR1UAPM/dep1P6zA3WyTS15tzIJ93f pjLYTciDvPbTOfRTV+1PQvvVDbHZve34wcjGZHaqV35qUQwXcd/DQK18L8S7EmDx BeBmii/cX2qBSyzDNGgSjtBTh0AT67tpJQPnH7brsVc9S75+E/MyDqXZjqiJv/9N i22XgsD/iTzkP3o0OTjs =FKVl -----END PGP SIGNATURE----- From dpal at redhat.com Wed Sep 10 23:58:01 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 10 Sep 2014 19:58:01 -0400 Subject: [Freeipa-users] Branding In-Reply-To: <5410E3A5.9070709@cenic.org> References: <5410D63B.9060301@cenic.org> <5410E1E5.5010008@redhat.com> <5410E3A5.9070709@cenic.org> Message-ID: <5410E589.9020308@redhat.com> On 09/10/2014 07:49 PM, William Graboyes wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hi Dimitri, > > Yeah just the logo should do, I believe I found it at > `/usr/share/ipa/ui/images/ipa-logo.png`. I am more just making sure it > is allowed. I do not know what you mean. Yes it is allowed. But it is your responsibility to either rebuild the package with new bitmap and support it in your deployment or change it to your image after every update in your deployment. > > Thanks, > Bill > > On Wed Sep 10 16:42:29 2014, Dmitri Pal wrote: >> On 09/10/2014 06:52 PM, William Graboyes wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA512 >>> >>> Hi List, >>> >>> I am looking into changing the branding on the free-ipa GUI interface. >>> This is something that is being requested by my management, >>> considering that we are asking users to trust an e-mail prodding them >>> to change their password. I don't see an easy method in the GUI >>> interface for changing the logo. I was wondering if anyone else has >>> had need for these changes, and what steps they may have taken to >>> change the branding. >> Is it just the logo or other things too, like colors and styles? >> >> >>> Thanks, >>> Bill >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG/MacGPG2 v2.0.22 (Darwin) >>> Comment: GPGTools - https://gpgtools.org >>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >>> >>> iQIcBAEBCgAGBQJUENY7AAoJEJFMz73A1+zrxuoP/0NUQdonXJFSrxxy1/3vVHuW >>> Mbf/kHo3tCn26GGkNBYgVqa5FJ7hri9eEsRhIR/krJP7mbRk9XoRJ7XcGF8YO+4c >>> O5MtJftMU6vueOWQZx6JZXm9+bqhvDnT24kwq2V19IrQX5Q0JcRY4EOzLc5BgBqR >>> bSlNbhxBj0H+WFdU7z4jkfiSbOoRcYSIV+nlX7hZK9G7WHVqcYRi2iaTQ1kMX5ju >>> oMTbkOrSKK8EixNamvHdr9y4UrxQhEks9Pa1xBHo0sZm2/YTeIX4KRWBs4dT/KKt >>> flSa93AF/8CnPeQHGCHP37FMJLtct7ySRuldo09AQULNN51fqBZlbHpMGSILmbt+ >>> BIrRaG3tZ4cB5rOfYlJ7UBnTFO7o101a1BJIxXWahsg39QBYsEQFswOPmR3ivvfg >>> bJnPbJ7WqB5ir7b21iQJ1kkNcpeScdFhebMlEqskfZ92CBJu/S6Av25mxy4fku4b >>> 1HhOAXK9s1LDR8l8LhwxVOAAIs2ILQ5SxFl6u/hNsgvdC0M5tPtvCnpgvpvoMBB/ >>> E+poXBWbVQkkxl8AI+IERQaUx4Ou+ihwhMrGuBjXry6zts9J3b+cgIHzbbS3thZf >>> PooMTTiiy7R6gZiZdvqjl0G4QmJvegjHjWySZZwIjPKZAeEb7fI8jEpLOSM54KQ6 >>> sqSR7rg3TB0P91YAMqXo >>> =AscS >>> -----END PGP SIGNATURE----- >>> >> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: GPGTools - https://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCgAGBQJUEOOlAAoJEJFMz73A1+zrASEP/0gBH7ZilDBY/UEVrGxFDLkx > FnGpCniouAF05b4EvvKz6KH+S4DElXgpVJOYPeufLtFg3xYLmhrzRI5uPG1Bpp8D > 9caoEqsyqiKz96+gqglrcvjptwCLNuzBuC46l8QJLhL6ROPwB72Xwh8JVfUzMn9e > gIn2McnsCIz2/tZOLgDqXraw0dIsvxS4T0aRO4XkRpEZ/EkozYzxJHEHHuCoL5GO > P7ITGroyPZaCojj0UJaCMjeK1ddIHS2anot64qkQUQiIBkCjvBZpqFbpQumoGd5T > ZbdpM/yRkhHFgHPEjQn0+cxBzhNEqfTfotU1zBwAQEu3GbpxAXmbILrJJpOup8hf > mOdCmkAv2Pwne5x4481qn0mnobmLZYyCTjRLgKttMGz4NbH0E1WkQeLN523Q8wyC > seQf+Jtxvt6K+ZbD4RlcVTAKUJfvBiQQwJsK9b8++vjebv4Dhrr+vp3wTZBHEpRt > gGU/5eXUWAyEiYv3Ce5aAjtTX88fGr3J95wdTmAWv4vmQ7D20FvVKuUEkRz5q/Hy > xYTxUhK9ccmzvkzxAeUkuwOR7tVKp3rP5eM9K3vG1+YhT2xYa/I7JpNIwRmYmnHM > TLCia5mEZAFBZtsI0up6DXGUAu356+kRe1tjvU8TgsbAmKAGPgqZZDbhwDmGsNee > wo6IQ6Itxp6ucU5m2Qet > =wjKX > -----END PGP SIGNATURE----- > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Thu Sep 11 00:01:40 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 10 Sep 2014 20:01:40 -0400 Subject: [Freeipa-users] Certs. In-Reply-To: <5410E57C.5030204@cenic.org> References: <5410D5C3.7020805@cenic.org> <5410DE09.4050700@cenic.org> <5410E384.4070703@redhat.com> <5410E57C.5030204@cenic.org> Message-ID: <5410E664.6080602@redhat.com> On 09/10/2014 07:57 PM, William Graboyes wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hi Dmitri, > > Production Environment is going to be RH 6.5, We are still evaluating > the usage of systemd. More like we are taking a wait and see approach > to to systemd, while actively testing it. The command line options for chaining are there from day one. So you would need to chain your production environment when you deploy it. In future when you migrate to later versions (in couple of years or so) you will be able to change the chaining using the new tools. Right now it is a vary hard multi step manual procedure. This is why we developed the tool. But you should be all set for now. You would not need to change anything for several years. Thanks Dmitri > Thanks, > Bill > > On Wed Sep 10 16:49:24 2014, Dmitri Pal wrote: >> On 09/10/2014 07:26 PM, William Graboyes wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA512 >>> >>> Hi Chris, >>> >>> Thank you for the suggestion. Looking at >>> http://www.redhat.com/archives/freeipa-users/2014-August/msg00334.html >>> >>> Installing a new, third party cert requires a reinstall of IPA? IPA >>> Devs, that is a bit silly don't you think? A year or two in the cert >>> expires, now you have to start from scratch? I will wait for some form >>> of response before I attempt at eating crow in front of management. >>> >>> I forgot to mention, free-ipa version ipa-server-3.0.0-37.el6.x86_64. >> Since 3.0 internal certs are issued for 2 years and are renewed >> automatically. The root cert is valid for more than two years (AFAIR >> it is 20). >> >> >> >>> >>> >>> On Wed Sep 10 15:55:56 2014, Chris Whittle wrote: >>>> Search the list for a post by me and certs... Basically there is a >>>> install >>>> flag that will do all the work for you once you have it the cert in the >>>> right format. >>>> On Sep 10, 2014 5:53 PM, "William Graboyes" >>>> wrote: >>>> >>>> ********* *BEGIN ENCRYPTED or SIGNED PART* ********* >>>> >>>> Hello list, >>>> >>>> I have been fruitlessly searching for some information, especially >>>> related to Certs, namely how to replace the self signed certs with >>>> certs from a trusted CA? As we are moving forward into >>>> productionizing of our free-ipa install, I am finding information on >>>> the net to be a bit lacking. There is also the possibility that I am >>>> not looking in the right places, or using the correct search terms. >>>> Any help on this front would be greatly appreciated. >>>> >>>> Thanks, >>>> Bill >>>> >>>> >>>> ********** *END ENCRYPTED or SIGNED PART* ********** >>>> >>>>> -- >>>>> Manage your subscription for the Freeipa-users mailing list: >>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>> Go To http://freeipa.org for more info on the project >>>>> >>>> >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG/MacGPG2 v2.0.22 (Darwin) >>> Comment: GPGTools - https://gpgtools.org >>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >>> >>> iQIcBAEBCgAGBQJUEN4JAAoJEJFMz73A1+zrjNAP/1aZOjhp6c6JwWXUjBE4Pt4i >>> u6Z1BRFNYgIc5/aNsPAKrdzMqQgTjgWJvSh5UCON0VdmuIx7pQLP7nIlaCCXTRRK >>> pKx2Cez5Ho7Lwlsb87WW3bzjcyKGX5Wd3+VJdQ6ugYJTpVS4gMxh8atZCV613EY6 >>> FuMk1RS6qlWM2Ut3SjmaAZK3jTw2pUsJzW3zzB271i6sJqAMZTh7Lrie6QcGqAON >>> eLGlWBZuCaeULUuQmArVZiP3qPnH5NuccvXLFVbX7D1+SM8XeLWrTklN1bfX2HF0 >>> QCFlizb+bBga/d5cEaCv7R8v6m46R4wS779KSUV1jn9PpHISNcmLafv6dTAb6F+5 >>> RBADwBP6coh5LrOJJh0pIByx9dYRbdif/BSH4VMcvfvFMs/EO1PAsGLWQPwoNfYO >>> 0SzUV1R47JW9NGzeTxja+byKz9hwGtAT2FIw0NibR+M1FydPD9k3LTjTnQWgeSro >>> ks3AUPDy/hj+E72QDORj+/Zvy3sw8wDFVRw2LH/jaDmWbWhZUG4riC3w2egPjcSK >>> KIYQ7L/fdeN6S9jt8UcUf1YDHgfLU+iTgqyssr54RufVuM9iBNOkoWxxI0Q9oyMF >>> NDKiOY8rs2rBu6x09NiHG0BoX1LQzrrKQFQ4ao48w2RH3ocFCgQbsEHZ18uIfo4Y >>> CB5M63nykETHkkR3ZFkd >>> =8T1Y >>> -----END PGP SIGNATURE----- >>> >> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: GPGTools - https://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCgAGBQJUEOV8AAoJEJFMz73A1+zrgwAQAJkx74MPOVvbnrG+dmY8w7ok > J/6NWt9Rb/pS9gRrN7iFopni3BoHuLFC6ltwD6KoWllYClwoXke4T0FQ/nU6Ar6M > tsuQMYxP0boxhQua2uF/kZ/atMolxoNMShNixXd4dnWtBlpl+R+V58FtfjSGfy49 > qX2Ge6g6wEFATwKReM1KpKCFIfO/yq/wM4NLvvBd6WShJXh6TQBE44y9aXLLJIlP > DApoLnMHaopNZITSNKt1t7dgw6ne9O370nQwOxR5L0peH8bxla0FLJ57vX+RCC0f > 3EV/tQHKiXET1RqWE927tfPf171Xcq7sdjLRUL2JTVCK3zPZUuVg9WmuqrLUArhW > f1XRpn1MM2e0xn18rvHfuRZr2IIUuPE+RfVcQMgEcgtSYuDNlVYCO/ONyTQHxJ/E > JRkN6nDOZ1nlItJlrrT0MVgdMKQLG7IxkvOndGsyOShD/XvvjQYlQbDvRvodnAlc > JUIlcC3PbGZh+CRymXzu6M7DYceE5rJ/HzbR1UAPM/dep1P6zA3WyTS15tzIJ93f > pjLYTciDvPbTOfRTV+1PQvvVDbHZve34wcjGZHaqV35qUQwXcd/DQK18L8S7EmDx > BeBmii/cX2qBSyzDNGgSjtBTh0AT67tpJQPnH7brsVc9S75+E/MyDqXZjqiJv/9N > i22XgsD/iTzkP3o0OTjs > =FKVl > -----END PGP SIGNATURE----- > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Thu Sep 11 00:06:41 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 10 Sep 2014 20:06:41 -0400 Subject: [Freeipa-users] json api docs In-Reply-To: <5410DA78.2030802@martos.bme.hu> References: <5410DA78.2030802@martos.bme.hu> Message-ID: <5410E791.2090407@redhat.com> On 09/10/2014 07:10 PM, Tamas Papp wrote: > hi All, > > Is there an offficial API documentation available? Unfortunately not much. You can search archives and find some recommendations that helped people in the past. https://www.redhat.com/archives/freeipa-users/2013-January/msg00109.html We also have a ticket https://fedorahosted.org/freeipa/ticket/3129 > > Also is there a simple way to logon and run commands through API > without a kerberos ticket? Once you authenticated with Kerberos and negotiated GSSAPI the server will issue a cookie that will be stored on the client and can be used to continue operations. But Kerberos is needed for the first connection. It is a requirement because it is a best practice. > > > Thanks, > tamas > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From rcritten at redhat.com Thu Sep 11 00:56:16 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 10 Sep 2014 20:56:16 -0400 Subject: [Freeipa-users] Certs. In-Reply-To: <5410E664.6080602@redhat.com> References: <5410D5C3.7020805@cenic.org> <5410DE09.4050700@cenic.org> <5410E384.4070703@redhat.com> <5410E57C.5030204@cenic.org> <5410E664.6080602@redhat.com> Message-ID: <5410F330.1030605@redhat.com> Dmitri Pal wrote: > On 09/10/2014 07:57 PM, William Graboyes wrote: > Hi Dmitri, > > Production Environment is going to be RH 6.5, We are still evaluating > the usage of systemd. More like we are taking a wait and see approach > to to systemd, while actively testing it. >> The command line options for chaining are there from day one. >> So you would need to chain your production environment when you deploy it. >> In future when you migrate to later versions (in couple of years or so) >> you will be able to change the chaining using the new tools. Right now >> it is a vary hard multi step manual procedure. This is why we developed >> the tool. >> But you should be all set for now. You would not need to change anything >> for several years. I also think we need to understand what you mean by replace the certs. Do you just want to replace the web and ldap certs, and never need to use any IPA-issued certificates or at you looking to replace the entire CA? rob From rcritten at redhat.com Thu Sep 11 01:16:22 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 10 Sep 2014 21:16:22 -0400 Subject: [Freeipa-users] 4.0.2-1 not ready for primetime or testing? In-Reply-To: <54107618.6040102@gmail.com> References: <54107618.6040102@gmail.com> Message-ID: <5410F7E6.5070109@redhat.com> Kat wrote: > Trying to do some testing with 4.0.2-1 on FC22/rawhide -- the install > blows up: > > Configuring directory server (dirsrv): Estimated time 10 seconds > [1/3]: configuring ssl for ds instance > [2/3]: restarting directory server > ipa : CRITICAL Failed to restart the directory server. See the > installation log for details. > > > and from the logs -- any ideas? I think you're seeing https://bugzilla.redhat.com/show_bug.cgi?id=1139954 It's being worked on. rob From asl.gerardo at gmail.com Thu Sep 11 07:27:56 2014 From: asl.gerardo at gmail.com (Gerardo Padierna) Date: Thu, 11 Sep 2014 09:27:56 +0200 Subject: [Freeipa-users] Integrating FreeIPA with ActiveDirectory (Windows 2008 R2) In-Reply-To: <5410E1A3.2090300@redhat.com> References: <20140910213151.GC2541@redhat.com> <5410E1A3.2090300@redhat.com> Message-ID: <54114EFC.6080508@gmail.com> Hi Traiano, I think it really needs quite some memory (I think it's the SELinux setboolean part); In my case, I ran some initial configuration tests on virtual machines (configured initially with just around 512MB mem), and had to increase to close to 800MB for the config setup scripts to run fine. Can you monitor your free mem while you run the scripts? (btw, how much total mem do you have?) Regards, Gerardo El 11/09/14 a las #4, Dmitri Pal escribi?: > On 09/10/2014 05:31 PM, Alexander Bokovoy wrote: >> On Thu, 11 Sep 2014, Traiano Welcome wrote: >>> Hi List >>> >>> I've been following the AD integration guide for IPAv3 here: >>> http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup >>> However, when I reach the "Add trust with AD domain" step I get the >>> following error: >>> >>> --- >>> [root at ipa ~]# ipa trust-add --type=ad mhatest.local --admin >>> Administrator >>> --password >>> Active directory domain administrator's password: >>> ipa: ERROR: CIFS server communication error: code "-1073741801", >>> message "Memory allocation error" (both may be "None") >>> --- >>> >>> ... And I'm at a loss for how to interpret this :-) Details on my >>> setup: >> Please follow >> http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Debugging_trust >> to provide useful debugging information. >> >>> - Windows 2008 R2 AD DC >>> - CentOS Linux 6.5 IPA server (installed from yum repos) >> Ideally you'd need to use RHEL 7 or CentOS 7 for trusts as IPA version >> 3.3 is more mature in this regard. >> > > FYI > https://fedorahosted.org/freeipa/ticket/3266 > -- *Gerardo Padierna Nanclares* T?cnico de Sistemas (grupo ASL) - [Fujitsu / Logware] Servicio de Sistemas de la Informaci?n (DGTI) - Generalitat Valenciana C/.Castan Tobe?as 77 ? 46018 Valencia ? Edificio A Tel: 961 208973 Email: asl.gerardo at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tevfik.ceydeliler at astron.yasar.com.tr Thu Sep 11 10:24:51 2014 From: tevfik.ceydeliler at astron.yasar.com.tr (Tevfik Ceydeliler) Date: Thu, 11 Sep 2014 13:24:51 +0300 Subject: [Freeipa-users] FreeIPA Web UI error: Service Unavailable In-Reply-To: References: Message-ID: <54117873.4090205@astron.yasar.com.tr> Hi all, I tried to do single sign on for FreeIPa Web UI according to "4.3.3. Configuring the Browser" I did browser side and then turn back to server side. And run those command: # scp /etc/krb5.conf root at externalmachine.example.com:/etc/krb5_ipa.conf and vim /etc/httpd/conf.d/ipa.conf and change this: KrbMethodK5Passwd off --> to --> KrbMethodK5Passwd on and restart httpd. Then nothing change. And then I rollback vim /etc/httpd/conf.d/ipa.conf Now when I try to open Web UI I get An popup error: "Service Unavailable" Have you any idea?


Bu elektronik postada bulunan tum fikir ve gorusler ve ekindeki dosyalar sadece adres sahip/sahiplerine ait olup, Yasar Toplulugu Sirketleri bu mesajin icerigi ile ilgili olarak hic bir hukuksal sorumlulugu kabul etmez. Eger gonderilmesi dusunulen kisi veya kurulus degilseniz, lutfen gonderen kisiyi derhal haberdar ediniz ve mesaji sisteminizden siliniz.The information contained in this e-mail and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and Yasar Group Companies do not accept legal responsibility for the contents. If you are not the intended recipient, please immediately notify the sender and delete it from your system. From sbose at redhat.com Thu Sep 11 10:58:43 2014 From: sbose at redhat.com (Sumit Bose) Date: Thu, 11 Sep 2014 12:58:43 +0200 Subject: [Freeipa-users] sssd receives another uid/gid after disabled HBAC rule In-Reply-To: References: <20140908071751.GN4089@localhost.localdomain> Message-ID: <20140911105842.GP2947@localhost.localdomain> On Wed, Sep 10, 2014 at 08:19:15AM +0200, Gregor Bregenzer wrote: > Hello Sumit, > i think maybe there is a different problem i just discovered by > accident. As stated in the first email, i have an AD trust with > FreeIPA that receives all POSIX attributes from AD, but i get > different values: > On the FreeIPA server that has the AD trust (ipa1.linux.intern) i get > the correct GID (=10000, this is the AD group linuxusers) that is set > in AD, but on the client (linux1.linux.intern) i get another one ( = > 10005): > > ipa1.linux.intern > ~~~~ > [root at ipa1 httpd]# getent passwd user1 at aaa > user1 at aaa.intern:*:10005: > 10000:user1:/home/aaa.intern/user1:/bin/bash > > -bash-4.2$ id > uid=10005(user1 at aaa.intern) gid=10000(linuxusers at aaa.intern) > groups=10000(linuxusers at aaa.intern),1933000004(ad_users) > ~~~~ > > linux1.linux.intern > ~~~~~~~~ > [root at linux1 sssd]# getent passwd user1 at aaa > user1 at aaa.intern:*:10005:10005::/home/user1 at aaa.intern:/bin/bash > > [user1 at aaa.intern@linux1 ~]$ id > uid=10005(user1 at aaa.intern) gid=10005(user1 at aaa.intern) > Gruppen=10005(user1 at aaa.intern),1933000004(ad_users) Since you are using SSSD-1.9.x on the client this behaviour is expected. In this version SSSD could only handle users from a trusted AD domain as users with User Private Groups (UPG), hence POSIX UID and GID are the same. The additional group memberships are only available after the user logged in. For this the PAC from the Kerberos ticket is evaluated. But the PAC does not contain any information about POSIX attributes and only contains groups the user is member of from the AD point of view. If user1 is not a member of the linuxuser AD group SSSD cannot resolve this membership. Nevertheless I think this is not related to the UID change you reported earlier. bye, Sumit > > Logfile on ipa1.linux.intern sssd_nss.log > (Wed Sep 10 08:14:42 2014) [sssd[nss]] [nss_cmd_getbynam] (0x0400): > Running command [17] with input [user1 at aaa.intern]. > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sss_parse_name_for_domains] > (0x0200): name 'user1 at aaa.intern' matched expression for domain > 'aaa.intern', user is user1 ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [nss_cmd_getbynam] (0x0100): > Requesting info for [user1] from [aaa.intern] > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sss_ncache_check_str] > (0x2000): Checking negative cache for [NCE/USER/aaa.intern/user1] > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [nss_cmd_getpwnam_search] > (0x0100): Requesting info for [user1 at aaa.intern] > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Added timed > event "ltdb_callback": 0x7fe19e562700 > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Added timed > event "ltdb_timeout": 0x7fe19e562830 > ? > 03?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Running > timer event 0x7fe19e562700 "ltdb_callback" > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Destroying > timer event 0x7fe19e562830 "ltdb_timeout" > ?va > r/?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Ending timer > event 0x7fe19e562700 "ltdb_callback" > ? > ?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [check_cache] (0x0400): > Cached entry is valid, returning.. > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [nss_cmd_getpwnam_search] > (0x0400): Returning info for user [user1 at aaa.intern] > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [reset_idle_timer] (0x4000): > Idle timer re-set for client [0x7fe19e563d40][21] > ? > > ---------- > Logfile on linux1.linux.intern sssd_nss.log > > (Wed Sep 10 08:14:42 2014) [sssd[nss]] [sss_parse_name_for_domains] > (0x0200): name 'user1 at aaa' matched expression for domain 'aaa.intern', > user is user1 ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [nss_cmd_getpwnam] (0x0100): > Requesting info for [user1] from [aaa.intern] > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sss_ncache_check_str] > (0x2000): Checking negative cache for [NCE/USER/aaa.intern/user1] > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [nss_cmd_getpwnam_search] > (0x0100): Requesting info for [user1 at aaa.intern] > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Added timed > event "ltdb_callback": 0x20e2c20 > ? > (W? > > ? > 00?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Added timed > event "ltdb_timeout": 0x20e2590 > ? > (W? > > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Running > timer event 0x20e2c20 "ltdb_callback" > ? > (W? > > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Destroying > timer event 0x20e2590 "ltdb_timeout" > ? > (W? > > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Ending timer > event 0x20e2c20 "ltdb_callback" > ? > (W? > > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sss_dp_issue_request] > (0x0400): Issuing request for [0x432730:1:user1 at aaa.intern] > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sss_dp_get_account_msg] > (0x0400): Creating request for [aaa.intern][4097][1][name=user1] > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sbus_add_timeout] (0x2000): > 0x20d72e0 > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sss_dp_internal_get_send] > (0x0400): Entering request [0x432730:1:user1 at aaa.intern] > ? > 01?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sbus_remove_timeout] > (0x2000): 0x20d72e0 > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sbus_dispatch] (0x4000): > dbus conn: 20DB0F0 > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sbus_dispatch] (0x4000): > Dispatching. > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sss_dp_get_reply] (0x1000): > Got reply from Data Provider - DP error code: 0 errno: 0 error > message: Success > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sss_ncache_check_str] > (0x2000): Checking negative cache for [NCE/USER/aaa.intern/user1] > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [nss_cmd_getpwnam_search] > (0x0100): Requesting info for [user1 at aaa.intern] > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Added timed > event "ltdb_callback": 0x20e8530 > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Added timed > event "ltdb_timeout": 0x20e85e0 > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Running > timer event 0x20e8530 "ltdb_callback" > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Destroying > timer event 0x20e85e0 "ltdb_timeout" > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Ending timer > event 0x20e8530 "ltdb_callback" > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [nss_cmd_getpwnam_search] > (0x0400): Returning info for user [user1 at aaa.intern] > ? > 02?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sss_dp_req_destructor] > (0x0400): Deleting request: [0x432730:1:user1 at aaa.intern] > ? > :/?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [reset_idle_timer] (0x4000): > Idle timer re-set for client [0x20e44a0][20] > ? > ?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [reset_idle_timer] (0x4000): > Idle timer re-set for client [0x20e44a0][20] > ? > (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [client_recv] (0x0200): > Client disconnected! > ?/v > ar?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [client_destructor] > (0x2000): Terminated client [0x20e44a0][20] > > ~~~~ > > > I think i need to get this one right before the HBAC rule - right? > > > Here is my ipa1.linux.intern sssd.conf: > ~~~~~~~~~ > [domain/linux.intern] > debug_level=9 > cache_credentials = True > krb5_store_password_if_offline = True > ipa_domain = linux.intern > id_provider = ipa > auth_provider = ipa > access_provider = ipa > ipa_hostname = ipa1.linux.intern > chpass_provider = ipa > ipa_server = ipa1.linux.intern > ipa_server_mode = True > ldap_tls_cacert = /etc/ipa/ca.crt > [sssd] > debug_level=9 > services = nss, sudo, pam, ssh, pac > config_file_version = 2 > subdomains_provider = ipa > domains = linux.intern > [nss] > debug_level=9 > homedir_substring = /home > > [pam] > debug_level=9 > [sudo] > > [autofs] > > [ssh] > > [pac] > debug_level=9 > [ifp] > > ~~~~~~~~~~~~~~ > > Here's my linux1.linux.intern sssd.conf > ~~~~~ > [domain/linux.intern] > debug_level=9 > cache_credentials = False > krb5_store_password_if_offline = False > ipa_domain = linux.intern > id_provider = ipa > auth_provider = ipa > access_provider = ipa > ipa_hostname = linux1.linux.intern > chpass_provider = ipa > ipa_dyndns_update = True > ipa_server = _srv_, ipa1.linux.intern > ldap_tls_cacert = /etc/ipa/ca.crt > use_fully_qualified_domains = True > # For the SUDO integration > sudo_provider = ldap > ldap_uri = ldap://ipa1.linux.intern > ldap_sudo_search_base = ou=sudoers,dc=linux,dc=intern > ldap_sasl_mech = GSSAPI > ldap_sasl_authid = host/linux1.linux.intern > ldap_sasl_realm = LINUX.INTERN > krb5_server = ipa1.linux.intern > > [sssd] > debug_level=9 > services = nss, pam, ssh, sudo > config_file_version = 2 > #default_domain_suffix=aaa.intern > domains = linux.intern > [nss] > debug_level=9 > override_homedir = /home/%u > override_shell = /bin/bash > [pam] > debug_level=9 > [sudo] > > [autofs] > > [ssh] > debug_level=9 > [pac] > debug_level=9 > > ~~~~ > > > I used the following command to create the AD trust: > > ipa trust-add --type=ad aaa.intern --admin Administrator > --password --range-type ipa-ad-trust-posix > > Do you need any other debug information? > > > Thanks! > Gregor > > 2014-09-08 9:17 GMT+02:00 Sumit Bose : > > On Sun, Sep 07, 2014 at 11:41:16PM +0200, Gregor Bregenzer wrote: > >> Hi! > >> > >> I have an AD trust with FreeIPA 4.0.1 and defined a HBAC rule for a > >> specific user group (=ad_users which is an posix group that has an > >> external group as member) to login on a specific client > >> (=linux1.linux.intern). > >> > >> The problem is: once i disable the rule and the AD user is not allowed > >> to login anymore, the user on the client gets another uid and gid via > >> sssd. > >> > >> I use the posix attributes from AD, which will get received by sssd perfectly. > >> The client is running on CentOS 6.5 and uses sssd 1.9.2.129.el6_5.4 > >> AD domain = aaa.intern > >> IPA domain = linux.intern > >> AD-User: user1 (uid=1005,gid=10005) > >> > >> Here an example: > >> ---------------------------- > >> 1.) disable the hbac rule and the default allow_all rule: > >> 2.) check the uid/gid on the client (=linux1.linux.intern) and it looks fine: > >> > >> [root at linux1 sssd]# getent passwd user1 at aaa > >> user1 at aaa.intern:*:10005:10005::/home/user1 at aaa.intern:/bin/bash > >> > >> 3.) Login with ssh to client as user1. It will be denied upon correct > >> password input and ssh sessions closes. Up until now everything as > >> expected. But now: > >> > >> 4.) check for the uid/gid on the client - something totally different. > >> It now also receives the Firstname and Lastname from AD, latter is > >> empty: > >> > >> [root at linux1 sssd]# getent passwd user1 at aaa > >> user1 at aaa.intern:*:11601:11601:user1:/home/user1 at aaa.intern:/bin/bash > >> > >> 5.) Enable the hbac rule and login works, but the unexpected uid/gid > >> stays the same: > >> > >> login as: user1 at aaa > >> user1 at aaa@192.168.0.100's password: > >> login as: user1 at aaa > >> user1 at aaa@192.168.0.100's password: > >> Last failed login: Sun Sep 7 23:19:49 CEST 2014 from 192.168.0.26 on ssh:notty > >> There were 2 failed login attempts since the last successful login. > >> Creating home directory for user1 at aaa. > >> Last login: Sun Sep 7 23:21:02 2014 from 192.168.0.26 > >> [user1 at aaa.intern@linux1 ~]$ id > >> uid=11601(user1 at aaa.intern) gid=11601(user1 at aaa.intern) > >> Gruppen=11601(user1 at aaa.intern),1933000004(ad_users) > >> [user1 at aaa.intern@linux1 ~]$ > >> --------------------------------- > >> > >> Anyone have a clue what might be the problem? > > > > I would expect some kind of collision, but to be sure I need the SSSD > > log files. Please try to reproduce the switch and send me the log file, > > if possilbe with debug_level=9. > > > > bye, > > Sumit > > > >> > >> Here's the sssd.conf: > >> [root at linux1 sssd]# cat /etc/sssd/sssd.conf > >> [domain/linux.intern] > >> debug_level=6 > >> cache_credentials = False > >> krb5_store_password_if_offline = False > >> ipa_domain = linux.intern > >> id_provider = ipa > >> auth_provider = ipa > >> access_provider = ipa > >> ipa_hostname = linux1.linux.intern > >> chpass_provider = ipa > >> ipa_dyndns_update = True > >> ipa_server = _srv_, ipa1.linux.intern > >> ldap_tls_cacert = /etc/ipa/ca.crt > >> use_fully_qualified_domains = True > >> # For the SUDO integration > >> sudo_provider = ldap > >> ldap_uri = ldap://ipa1.linux.intern > >> ldap_sudo_search_base = ou=sudoers,dc=linux,dc=intern > >> ldap_sasl_mech = GSSAPI > >> ldap_sasl_authid = host/linux1.linux.intern > >> ldap_sasl_realm = LINUX.INTERN > >> krb5_server = ipa1.linux.intern > >> entry_cache_sudo_timeout = 30 > >> [sssd] > >> debug_level=6 > >> services = nss, pam, ssh, sudo > >> config_file_version = 2 > >> default_domain_suffix=aaa.intern > >> domains = linux.intern > >> [nss] > >> debug_level=9 > >> override_homedir = /home/%u > >> override_shell = /bin/bash > >> [pam] > >> debug_level=6 > >> [sudo] > >> debug_level=6 > >> [autofs] > >> > >> [ssh] > >> debug_level=6 > >> [pac] > >> > >> > >> > >> Thanks! > >> Gregor > >> > >> -- > >> Manage your subscription for the Freeipa-users mailing list: > >> https://www.redhat.com/mailman/listinfo/freeipa-users > >> Go To http://freeipa.org for more info on the project > > > > -- > > Manage your subscription for the Freeipa-users mailing list: > > https://www.redhat.com/mailman/listinfo/freeipa-users > > Go To http://freeipa.org for more info on the project From pvoborni at redhat.com Thu Sep 11 11:18:43 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 11 Sep 2014 13:18:43 +0200 Subject: [Freeipa-users] FreeIPA Web UI error: Service Unavailable In-Reply-To: <54117873.4090205@astron.yasar.com.tr> References: <54117873.4090205@astron.yasar.com.tr> Message-ID: <54118513.6090206@redhat.com> Hello Tevfik, comments inline On 11.9.2014 12:24, Tevfik Ceydeliler wrote: > > Hi all, > I tried to do single sign on for FreeIPa Web UI according to "4.3.3. > Configuring the Browser" > I did browser side and then turn back to server side. And run those > command: > > # scp /etc/krb5.conf root at externalmachine.example.com:/etc/krb5_ipa.conf > and I assume that you want to configure the machine without enrolling it as FreeIPA client. If not, I would suggest you enrolling it as a client using ipa-client-install. Then you don't have to do anything else except browser config. Why /etc/krb5_ipa.conf ?, it should be /etc/krb5.conf > > vim /etc/httpd/conf.d/ipa.conf > > and change this: > > KrbMethodK5Passwd off --> to --> KrbMethodK5Passwd on FreeIPA's Web UI support forms-based auth so this is not usually needed. > > and restart httpd. > > Then nothing change. And then I rollback vim /etc/httpd/conf.d/ipa.conf > > Now when I try to open Web UI I get An popup error: > "Service Unavailable" run: ipactl status or systemctl status httpd.service or inspect /var/log/httpd/error_log to find out if web server is running - might not be the case because of invalid modifications in /etc/httpd/conf.d/ipa.conf , reason should be in the log > > Have you any idea? > -- Petr Vobornik From tevfik.ceydeliler at astron.yasar.com.tr Thu Sep 11 11:36:46 2014 From: tevfik.ceydeliler at astron.yasar.com.tr (Tevfik Ceydeliler) Date: Thu, 11 Sep 2014 14:36:46 +0300 Subject: [Freeipa-users] FreeIPA Web UI error: Service Unavailable In-Reply-To: <54118513.6090206@redhat.com> References: <54117873.4090205@astron.yasar.com.tr> <54118513.6090206@redhat.com> Message-ID: <5411894E.5000809@astron.yasar.com.tr> hi, thnx for comment. I really dont care sibgle sign on or something like that now :) All I want I try to get back my ipa server :) I check IPA status and : [root at srv httpd]# ipactl status Directory Service: RUNNING KDC Service: RUNNING KPASSWD Service: RUNNING DNS Service: RUNNING MEMCACHE Service: RUNNING HTTP Service: RUNNING CA Service: RUNNING seems no problem ?n that side. Now I will resert my httpd error log and restart server. [root at srv httpd]# more error_log [Thu Sep 11 14:22:59 2014] [notice] caught SIGTERM, shutting down [Thu Sep 11 14:24:18 2014] [notice] SELinux policy enabled; httpd running as context system_u:system_r:httpd_t:s0 [Thu Sep 11 14:24:18 2014] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) [Thu Sep 11 14:24:18 2014] [notice] Digest: generating secret for digest authentication ... [Thu Sep 11 14:24:18 2014] [notice] Digest: done [Thu Sep 11 14:24:19 2014] [notice] Apache/2.2.15 (Unix) DAV/2 mod_auth_kerb/5.4 mod_nss/2.2.15 NSS/3.15.1 Basic ECC mod_wsgi/3.2 Python/2.6.6 configure d -- resuming normal operations [Thu Sep 11 14:24:23 2014] [error] ipa: INFO: *** PROCESS START *** [Thu Sep 11 14:24:23 2014] [error] ipa: INFO: *** PROCESS START *** And [root at srv httpd]# service iptables status iptables: Firewall is not running Seems no problem here. Which service not available? On 11-09-2014 14:18, Petr Vobornik wrote: > Hello Tevfik, > > comments inline > > On 11.9.2014 12:24, Tevfik Ceydeliler wrote: >> >> Hi all, >> I tried to do single sign on for FreeIPa Web UI according to "4.3.3. >> Configuring the Browser" >> I did browser side and then turn back to server side. And run those >> command: >> >> # scp /etc/krb5.conf root at externalmachine.example.com:/etc/krb5_ipa.conf >> and > > I assume that you want to configure the machine without enrolling it > as FreeIPA client. If not, I would suggest you enrolling it as a > client using ipa-client-install. Then you don't have to do anything > else except browser config. > > Why /etc/krb5_ipa.conf ?, it should be /etc/krb5.conf > >> >> vim /etc/httpd/conf.d/ipa.conf >> >> and change this: >> >> KrbMethodK5Passwd off --> to --> KrbMethodK5Passwd on > > FreeIPA's Web UI support forms-based auth so this is not usually needed. > >> >> and restart httpd. >> >> Then nothing change. And then I rollback vim /etc/httpd/conf.d/ipa.conf >> >> Now when I try to open Web UI I get An popup error: >> "Service Unavailable" > > run: > > ipactl status > or > systemctl status httpd.service > > or inspect > > /var/log/httpd/error_log > > to find out if web server is running - might not be the case because > of invalid modifications in /etc/httpd/conf.d/ipa.conf , reason should > be in the log > >> >> Have you any idea? >> --


Bu elektronik postada bulunan tum fikir ve gorusler ve ekindeki dosyalar sadece adres sahip/sahiplerine ait olup, Yasar Toplulugu Sirketleri bu mesajin icerigi ile ilgili olarak hic bir hukuksal sorumlulugu kabul etmez. Eger gonderilmesi dusunulen kisi veya kurulus degilseniz, lutfen gonderen kisiyi derhal haberdar ediniz ve mesaji sisteminizden siliniz.The information contained in this e-mail and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and Yasar Group Companies do not accept legal responsibility for the contents. If you are not the intended recipient, please immediately notify the sender and delete it from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.png Type: image/png Size: 15216 bytes Desc: not available URL: From gregor.bregenzer at gmail.com Thu Sep 11 12:01:52 2014 From: gregor.bregenzer at gmail.com (Gregor Bregenzer) Date: Thu, 11 Sep 2014 14:01:52 +0200 Subject: [Freeipa-users] sssd receives another uid/gid after disabled HBAC rule In-Reply-To: <20140911105842.GP2947@localhost.localdomain> References: <20140908071751.GN4089@localhost.localdomain> <20140911105842.GP2947@localhost.localdomain> Message-ID: Hello Sumit! Ah, thanks alot! I was wondering why this worked on the FreeIPA server (ipa1.linux.intern), but there i have SSSD 1.12. I will try with a newer client on another client and join the FreeIPA domain. About the original UID change problem: i will try that again and post the correct logfiles with the appropriate loglevel. Thanks! Gregor 2014-09-11 12:58 GMT+02:00 Sumit Bose : > On Wed, Sep 10, 2014 at 08:19:15AM +0200, Gregor Bregenzer wrote: >> Hello Sumit, >> i think maybe there is a different problem i just discovered by >> accident. As stated in the first email, i have an AD trust with >> FreeIPA that receives all POSIX attributes from AD, but i get >> different values: >> On the FreeIPA server that has the AD trust (ipa1.linux.intern) i get >> the correct GID (=10000, this is the AD group linuxusers) that is set >> in AD, but on the client (linux1.linux.intern) i get another one ( = >> 10005): >> >> ipa1.linux.intern >> ~~~~ >> [root at ipa1 httpd]# getent passwd user1 at aaa >> user1 at aaa.intern:*:10005: >> 10000:user1:/home/aaa.intern/user1:/bin/bash >> >> -bash-4.2$ id >> uid=10005(user1 at aaa.intern) gid=10000(linuxusers at aaa.intern) >> groups=10000(linuxusers at aaa.intern),1933000004(ad_users) >> ~~~~ >> >> linux1.linux.intern >> ~~~~~~~~ >> [root at linux1 sssd]# getent passwd user1 at aaa >> user1 at aaa.intern:*:10005:10005::/home/user1 at aaa.intern:/bin/bash >> >> [user1 at aaa.intern@linux1 ~]$ id >> uid=10005(user1 at aaa.intern) gid=10005(user1 at aaa.intern) >> Gruppen=10005(user1 at aaa.intern),1933000004(ad_users) > > Since you are using SSSD-1.9.x on the client this behaviour is expected. > In this version SSSD could only handle users from a trusted AD domain as > users with User Private Groups (UPG), hence POSIX UID and GID are the > same. The additional group memberships are only available after the user > logged in. For this the PAC from the Kerberos ticket is evaluated. But > the PAC does not contain any information about POSIX attributes and only > contains groups the user is member of from the AD point of view. If > user1 is not a member of the linuxuser AD group SSSD cannot resolve this > membership. > > Nevertheless I think this is not related to the UID change you reported > earlier. > > bye, > Sumit > >> >> Logfile on ipa1.linux.intern sssd_nss.log >> (Wed Sep 10 08:14:42 2014) [sssd[nss]] [nss_cmd_getbynam] (0x0400): >> Running command [17] with input [user1 at aaa.intern]. >> ? >> (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sss_parse_name_for_domains] >> (0x0200): name 'user1 at aaa.intern' matched expression for domain >> 'aaa.intern', user is user1 ? >> (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [nss_cmd_getbynam] (0x0100): >> Requesting info for [user1] from [aaa.intern] >> ? >> (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sss_ncache_check_str] >> (0x2000): Checking negative cache for [NCE/USER/aaa.intern/user1] >> ? >> (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [nss_cmd_getpwnam_search] >> (0x0100): Requesting info for [user1 at aaa.intern] >> ? >> (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Added timed >> event "ltdb_callback": 0x7fe19e562700 >> ? >> (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Added timed >> event "ltdb_timeout": 0x7fe19e562830 >> ? >> 03?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Running >> timer event 0x7fe19e562700 "ltdb_callback" >> ? >> (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Destroying >> timer event 0x7fe19e562830 "ltdb_timeout" >> ?va >> r/?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Ending timer >> event 0x7fe19e562700 "ltdb_callback" >> ? >> ?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [check_cache] (0x0400): >> Cached entry is valid, returning.. >> ? >> (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [nss_cmd_getpwnam_search] >> (0x0400): Returning info for user [user1 at aaa.intern] >> ? >> (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [reset_idle_timer] (0x4000): >> Idle timer re-set for client [0x7fe19e563d40][21] >> ? >> >> ---------- >> Logfile on linux1.linux.intern sssd_nss.log >> >> (Wed Sep 10 08:14:42 2014) [sssd[nss]] [sss_parse_name_for_domains] >> (0x0200): name 'user1 at aaa' matched expression for domain 'aaa.intern', >> user is user1 ? >> (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [nss_cmd_getpwnam] (0x0100): >> Requesting info for [user1] from [aaa.intern] >> ? >> (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sss_ncache_check_str] >> (0x2000): Checking negative cache for [NCE/USER/aaa.intern/user1] >> ? >> (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [nss_cmd_getpwnam_search] >> (0x0100): Requesting info for [user1 at aaa.intern] >> ? >> (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Added timed >> event "ltdb_callback": 0x20e2c20 >> ? >> (W? >> >> ? >> 00?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Added timed >> event "ltdb_timeout": 0x20e2590 >> ? >> (W? >> >> ? >> (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Running >> timer event 0x20e2c20 "ltdb_callback" >> ? >> (W? >> >> ? >> (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Destroying >> timer event 0x20e2590 "ltdb_timeout" >> ? >> (W? >> >> ? >> (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Ending timer >> event 0x20e2c20 "ltdb_callback" >> ? >> (W? >> >> ? >> (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sss_dp_issue_request] >> (0x0400): Issuing request for [0x432730:1:user1 at aaa.intern] >> ? >> (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sss_dp_get_account_msg] >> (0x0400): Creating request for [aaa.intern][4097][1][name=user1] >> ? >> (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sbus_add_timeout] (0x2000): >> 0x20d72e0 >> ? >> (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sss_dp_internal_get_send] >> (0x0400): Entering request [0x432730:1:user1 at aaa.intern] >> ? >> 01?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sbus_remove_timeout] >> (0x2000): 0x20d72e0 >> ? >> (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sbus_dispatch] (0x4000): >> dbus conn: 20DB0F0 >> ? >> (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sbus_dispatch] (0x4000): >> Dispatching. >> ? >> (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sss_dp_get_reply] (0x1000): >> Got reply from Data Provider - DP error code: 0 errno: 0 error >> message: Success >> ? >> (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sss_ncache_check_str] >> (0x2000): Checking negative cache for [NCE/USER/aaa.intern/user1] >> ? >> (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [nss_cmd_getpwnam_search] >> (0x0100): Requesting info for [user1 at aaa.intern] >> ? >> (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Added timed >> event "ltdb_callback": 0x20e8530 >> ? >> (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Added timed >> event "ltdb_timeout": 0x20e85e0 >> ? >> (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Running >> timer event 0x20e8530 "ltdb_callback" >> ? >> (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Destroying >> timer event 0x20e85e0 "ltdb_timeout" >> ? >> (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [ldb] (0x4000): Ending timer >> event 0x20e8530 "ltdb_callback" >> ? >> (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [nss_cmd_getpwnam_search] >> (0x0400): Returning info for user [user1 at aaa.intern] >> ? >> 02?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [sss_dp_req_destructor] >> (0x0400): Deleting request: [0x432730:1:user1 at aaa.intern] >> ? >> :/?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [reset_idle_timer] (0x4000): >> Idle timer re-set for client [0x20e44a0][20] >> ? >> ?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [reset_idle_timer] (0x4000): >> Idle timer re-set for client [0x20e44a0][20] >> ? >> (W?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [client_recv] (0x0200): >> Client disconnected! >> ?/v >> ar?(Wed Sep 10 08:14:42 2014) [sssd[nss]] [client_destructor] >> (0x2000): Terminated client [0x20e44a0][20] >> >> ~~~~ >> >> >> I think i need to get this one right before the HBAC rule - right? >> >> >> Here is my ipa1.linux.intern sssd.conf: >> ~~~~~~~~~ >> [domain/linux.intern] >> debug_level=9 >> cache_credentials = True >> krb5_store_password_if_offline = True >> ipa_domain = linux.intern >> id_provider = ipa >> auth_provider = ipa >> access_provider = ipa >> ipa_hostname = ipa1.linux.intern >> chpass_provider = ipa >> ipa_server = ipa1.linux.intern >> ipa_server_mode = True >> ldap_tls_cacert = /etc/ipa/ca.crt >> [sssd] >> debug_level=9 >> services = nss, sudo, pam, ssh, pac >> config_file_version = 2 >> subdomains_provider = ipa >> domains = linux.intern >> [nss] >> debug_level=9 >> homedir_substring = /home >> >> [pam] >> debug_level=9 >> [sudo] >> >> [autofs] >> >> [ssh] >> >> [pac] >> debug_level=9 >> [ifp] >> >> ~~~~~~~~~~~~~~ >> >> Here's my linux1.linux.intern sssd.conf >> ~~~~~ >> [domain/linux.intern] >> debug_level=9 >> cache_credentials = False >> krb5_store_password_if_offline = False >> ipa_domain = linux.intern >> id_provider = ipa >> auth_provider = ipa >> access_provider = ipa >> ipa_hostname = linux1.linux.intern >> chpass_provider = ipa >> ipa_dyndns_update = True >> ipa_server = _srv_, ipa1.linux.intern >> ldap_tls_cacert = /etc/ipa/ca.crt >> use_fully_qualified_domains = True >> # For the SUDO integration >> sudo_provider = ldap >> ldap_uri = ldap://ipa1.linux.intern >> ldap_sudo_search_base = ou=sudoers,dc=linux,dc=intern >> ldap_sasl_mech = GSSAPI >> ldap_sasl_authid = host/linux1.linux.intern >> ldap_sasl_realm = LINUX.INTERN >> krb5_server = ipa1.linux.intern >> >> [sssd] >> debug_level=9 >> services = nss, pam, ssh, sudo >> config_file_version = 2 >> #default_domain_suffix=aaa.intern >> domains = linux.intern >> [nss] >> debug_level=9 >> override_homedir = /home/%u >> override_shell = /bin/bash >> [pam] >> debug_level=9 >> [sudo] >> >> [autofs] >> >> [ssh] >> debug_level=9 >> [pac] >> debug_level=9 >> >> ~~~~ >> >> >> I used the following command to create the AD trust: >> >> ipa trust-add --type=ad aaa.intern --admin Administrator >> --password --range-type ipa-ad-trust-posix >> >> Do you need any other debug information? >> >> >> Thanks! >> Gregor >> >> 2014-09-08 9:17 GMT+02:00 Sumit Bose : >> > On Sun, Sep 07, 2014 at 11:41:16PM +0200, Gregor Bregenzer wrote: >> >> Hi! >> >> >> >> I have an AD trust with FreeIPA 4.0.1 and defined a HBAC rule for a >> >> specific user group (=ad_users which is an posix group that has an >> >> external group as member) to login on a specific client >> >> (=linux1.linux.intern). >> >> >> >> The problem is: once i disable the rule and the AD user is not allowed >> >> to login anymore, the user on the client gets another uid and gid via >> >> sssd. >> >> >> >> I use the posix attributes from AD, which will get received by sssd perfectly. >> >> The client is running on CentOS 6.5 and uses sssd 1.9.2.129.el6_5.4 >> >> AD domain = aaa.intern >> >> IPA domain = linux.intern >> >> AD-User: user1 (uid=1005,gid=10005) >> >> >> >> Here an example: >> >> ---------------------------- >> >> 1.) disable the hbac rule and the default allow_all rule: >> >> 2.) check the uid/gid on the client (=linux1.linux.intern) and it looks fine: >> >> >> >> [root at linux1 sssd]# getent passwd user1 at aaa >> >> user1 at aaa.intern:*:10005:10005::/home/user1 at aaa.intern:/bin/bash >> >> >> >> 3.) Login with ssh to client as user1. It will be denied upon correct >> >> password input and ssh sessions closes. Up until now everything as >> >> expected. But now: >> >> >> >> 4.) check for the uid/gid on the client - something totally different. >> >> It now also receives the Firstname and Lastname from AD, latter is >> >> empty: >> >> >> >> [root at linux1 sssd]# getent passwd user1 at aaa >> >> user1 at aaa.intern:*:11601:11601:user1:/home/user1 at aaa.intern:/bin/bash >> >> >> >> 5.) Enable the hbac rule and login works, but the unexpected uid/gid >> >> stays the same: >> >> >> >> login as: user1 at aaa >> >> user1 at aaa@192.168.0.100's password: >> >> login as: user1 at aaa >> >> user1 at aaa@192.168.0.100's password: >> >> Last failed login: Sun Sep 7 23:19:49 CEST 2014 from 192.168.0.26 on ssh:notty >> >> There were 2 failed login attempts since the last successful login. >> >> Creating home directory for user1 at aaa. >> >> Last login: Sun Sep 7 23:21:02 2014 from 192.168.0.26 >> >> [user1 at aaa.intern@linux1 ~]$ id >> >> uid=11601(user1 at aaa.intern) gid=11601(user1 at aaa.intern) >> >> Gruppen=11601(user1 at aaa.intern),1933000004(ad_users) >> >> [user1 at aaa.intern@linux1 ~]$ >> >> --------------------------------- >> >> >> >> Anyone have a clue what might be the problem? >> > >> > I would expect some kind of collision, but to be sure I need the SSSD >> > log files. Please try to reproduce the switch and send me the log file, >> > if possilbe with debug_level=9. >> > >> > bye, >> > Sumit >> > >> >> >> >> Here's the sssd.conf: >> >> [root at linux1 sssd]# cat /etc/sssd/sssd.conf >> >> [domain/linux.intern] >> >> debug_level=6 >> >> cache_credentials = False >> >> krb5_store_password_if_offline = False >> >> ipa_domain = linux.intern >> >> id_provider = ipa >> >> auth_provider = ipa >> >> access_provider = ipa >> >> ipa_hostname = linux1.linux.intern >> >> chpass_provider = ipa >> >> ipa_dyndns_update = True >> >> ipa_server = _srv_, ipa1.linux.intern >> >> ldap_tls_cacert = /etc/ipa/ca.crt >> >> use_fully_qualified_domains = True >> >> # For the SUDO integration >> >> sudo_provider = ldap >> >> ldap_uri = ldap://ipa1.linux.intern >> >> ldap_sudo_search_base = ou=sudoers,dc=linux,dc=intern >> >> ldap_sasl_mech = GSSAPI >> >> ldap_sasl_authid = host/linux1.linux.intern >> >> ldap_sasl_realm = LINUX.INTERN >> >> krb5_server = ipa1.linux.intern >> >> entry_cache_sudo_timeout = 30 >> >> [sssd] >> >> debug_level=6 >> >> services = nss, pam, ssh, sudo >> >> config_file_version = 2 >> >> default_domain_suffix=aaa.intern >> >> domains = linux.intern >> >> [nss] >> >> debug_level=9 >> >> override_homedir = /home/%u >> >> override_shell = /bin/bash >> >> [pam] >> >> debug_level=6 >> >> [sudo] >> >> debug_level=6 >> >> [autofs] >> >> >> >> [ssh] >> >> debug_level=6 >> >> [pac] >> >> >> >> >> >> >> >> Thanks! >> >> Gregor >> >> >> >> -- >> >> Manage your subscription for the Freeipa-users mailing list: >> >> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> Go To http://freeipa.org for more info on the project >> > >> > -- >> > Manage your subscription for the Freeipa-users mailing list: >> > https://www.redhat.com/mailman/listinfo/freeipa-users >> > Go To http://freeipa.org for more info on the project From traiano at gmail.com Thu Sep 11 12:16:59 2014 From: traiano at gmail.com (Traiano Welcome) Date: Thu, 11 Sep 2014 15:16:59 +0300 Subject: [Freeipa-users] Integrating FreeIPA with ActiveDirectory (Windows 2008 R2) In-Reply-To: <20140910213151.GC2541@redhat.com> References: <20140910213151.GC2541@redhat.com> Message-ID: Thanks for your responses Alexander, Dimitri and Gerardo. It appears further debugging will be unnecessary: I reinstalled on RHEL 7 and the trust established without issue: ---- [root at kwtpocidm001 ~]# ipa trust-add --type=ad mhatest.local --admin Administrator --password Active directory domain administrator's password: ------------------------------------------------------ Added Active Directory trust for realm "MHATEST.LOCAL" ------------------------------------------------------ Realm name: MHATEST.LOCAL Domain NetBIOS name: MHATEST Domain Security Identifier: S-1-5-21-2226261992-3934846357-352671753 SID blacklist incoming: S-1-0, S-1-1, S-1-2, S-1-3, S-1-5-1, S-1-5-2, S-1-5-3, S-1-5-4, S-1-5-5, S-1-5-6, S-1-5-7, S-1-5-8, S-1-5-9, S-1-5-10, S-1-5-11, S-1-5-12, S-1-5-13, S-1-5-14, S-1-5-15, S-1-5-16, S-1-5-17, S-1-5-18, S-1-5-19, S-1-5-20 SID blacklist outgoing: S-1-0, S-1-1, S-1-2, S-1-3, S-1-5-1, S-1-5-2, S-1-5-3, S-1-5-4, S-1-5-5, S-1-5-6, S-1-5-7, S-1-5-8, S-1-5-9, S-1-5-10, S-1-5-11, S-1-5-12, S-1-5-13, S-1-5-14, S-1-5-15, S-1-5-16, S-1-5-17, S-1-5-18, S-1-5-19, S-1-5-20 Trust direction: Two-way trust Trust type: Active Directory domain Trust status: Established and verified [root at kwtpocidm001 ~]# ---- Now onto the next hurdle :-) On Thu, Sep 11, 2014 at 12:31 AM, Alexander Bokovoy wrote: > On Thu, 11 Sep 2014, Traiano Welcome wrote: > >> Hi List >> >> I've been following the AD integration guide for IPAv3 here: >> http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup >> However, when I reach the "Add trust with AD domain" step I get the >> following error: >> >> --- >> [root at ipa ~]# ipa trust-add --type=ad mhatest.local --admin Administrator >> --password >> Active directory domain administrator's password: >> ipa: ERROR: CIFS server communication error: code "-1073741801", >> message "Memory allocation error" (both may be "None") >> --- >> >> ... And I'm at a loss for how to interpret this :-) Details on my setup: >> > Please follow > http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Debugging_trust > to provide useful debugging information. > > - Windows 2008 R2 AD DC >> - CentOS Linux 6.5 IPA server (installed from yum repos) >> > Ideally you'd need to use RHEL 7 or CentOS 7 for trusts as IPA version > 3.3 is more mature in this regard. > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kfiresmith at gmail.com Thu Sep 11 12:21:03 2014 From: kfiresmith at gmail.com (Kodiak Firesmith) Date: Thu, 11 Sep 2014 08:21:03 -0400 Subject: [Freeipa-users] Branding In-Reply-To: <5410E589.9020308@redhat.com> References: <5410D63B.9060301@cenic.org> <5410E1E5.5010008@redhat.com> <5410E3A5.9070709@cenic.org> <5410E589.9020308@redhat.com> Message-ID: Sounds like a job for Puppet. On Wed, Sep 10, 2014 at 7:58 PM, Dmitri Pal wrote: > On 09/10/2014 07:49 PM, William Graboyes wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> Hi Dimitri, >> >> Yeah just the logo should do, I believe I found it at >> `/usr/share/ipa/ui/images/ipa-logo.png`. I am more just making sure it >> is allowed. > > > I do not know what you mean. > Yes it is allowed. > But it is your responsibility to either rebuild the package with new bitmap > and support it in your deployment or change it to your image after every > update in your deployment. > > > >> >> Thanks, >> Bill >> >> On Wed Sep 10 16:42:29 2014, Dmitri Pal wrote: >>> >>> On 09/10/2014 06:52 PM, William Graboyes wrote: >>>> >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA512 >>>> >>>> Hi List, >>>> >>>> I am looking into changing the branding on the free-ipa GUI interface. >>>> This is something that is being requested by my management, >>>> considering that we are asking users to trust an e-mail prodding them >>>> to change their password. I don't see an easy method in the GUI >>>> interface for changing the logo. I was wondering if anyone else has >>>> had need for these changes, and what steps they may have taken to >>>> change the branding. >>> >>> Is it just the logo or other things too, like colors and styles? >>> >>> >>>> Thanks, >>>> Bill >>>> -----BEGIN PGP SIGNATURE----- >>>> Version: GnuPG/MacGPG2 v2.0.22 (Darwin) >>>> Comment: GPGTools - https://gpgtools.org >>>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >>>> >>>> iQIcBAEBCgAGBQJUENY7AAoJEJFMz73A1+zrxuoP/0NUQdonXJFSrxxy1/3vVHuW >>>> Mbf/kHo3tCn26GGkNBYgVqa5FJ7hri9eEsRhIR/krJP7mbRk9XoRJ7XcGF8YO+4c >>>> O5MtJftMU6vueOWQZx6JZXm9+bqhvDnT24kwq2V19IrQX5Q0JcRY4EOzLc5BgBqR >>>> bSlNbhxBj0H+WFdU7z4jkfiSbOoRcYSIV+nlX7hZK9G7WHVqcYRi2iaTQ1kMX5ju >>>> oMTbkOrSKK8EixNamvHdr9y4UrxQhEks9Pa1xBHo0sZm2/YTeIX4KRWBs4dT/KKt >>>> flSa93AF/8CnPeQHGCHP37FMJLtct7ySRuldo09AQULNN51fqBZlbHpMGSILmbt+ >>>> BIrRaG3tZ4cB5rOfYlJ7UBnTFO7o101a1BJIxXWahsg39QBYsEQFswOPmR3ivvfg >>>> bJnPbJ7WqB5ir7b21iQJ1kkNcpeScdFhebMlEqskfZ92CBJu/S6Av25mxy4fku4b >>>> 1HhOAXK9s1LDR8l8LhwxVOAAIs2ILQ5SxFl6u/hNsgvdC0M5tPtvCnpgvpvoMBB/ >>>> E+poXBWbVQkkxl8AI+IERQaUx4Ou+ihwhMrGuBjXry6zts9J3b+cgIHzbbS3thZf >>>> PooMTTiiy7R6gZiZdvqjl0G4QmJvegjHjWySZZwIjPKZAeEb7fI8jEpLOSM54KQ6 >>>> sqSR7rg3TB0P91YAMqXo >>>> =AscS >>>> -----END PGP SIGNATURE----- >>>> >>> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG/MacGPG2 v2.0.22 (Darwin) >> Comment: GPGTools - https://gpgtools.org >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >> >> iQIcBAEBCgAGBQJUEOOlAAoJEJFMz73A1+zrASEP/0gBH7ZilDBY/UEVrGxFDLkx >> FnGpCniouAF05b4EvvKz6KH+S4DElXgpVJOYPeufLtFg3xYLmhrzRI5uPG1Bpp8D >> 9caoEqsyqiKz96+gqglrcvjptwCLNuzBuC46l8QJLhL6ROPwB72Xwh8JVfUzMn9e >> gIn2McnsCIz2/tZOLgDqXraw0dIsvxS4T0aRO4XkRpEZ/EkozYzxJHEHHuCoL5GO >> P7ITGroyPZaCojj0UJaCMjeK1ddIHS2anot64qkQUQiIBkCjvBZpqFbpQumoGd5T >> ZbdpM/yRkhHFgHPEjQn0+cxBzhNEqfTfotU1zBwAQEu3GbpxAXmbILrJJpOup8hf >> mOdCmkAv2Pwne5x4481qn0mnobmLZYyCTjRLgKttMGz4NbH0E1WkQeLN523Q8wyC >> seQf+Jtxvt6K+ZbD4RlcVTAKUJfvBiQQwJsK9b8++vjebv4Dhrr+vp3wTZBHEpRt >> gGU/5eXUWAyEiYv3Ce5aAjtTX88fGr3J95wdTmAWv4vmQ7D20FvVKuUEkRz5q/Hy >> xYTxUhK9ccmzvkzxAeUkuwOR7tVKp3rP5eM9K3vG1+YhT2xYa/I7JpNIwRmYmnHM >> TLCia5mEZAFBZtsI0up6DXGUAu356+kRe1tjvU8TgsbAmKAGPgqZZDbhwDmGsNee >> wo6IQ6Itxp6ucU5m2Qet >> =wjKX >> -----END PGP SIGNATURE----- >> > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project From renier.gertzen at adcock.com Thu Sep 11 12:20:50 2014 From: renier.gertzen at adcock.com (Renier Gertzen) Date: Thu, 11 Sep 2014 12:20:50 +0000 Subject: [Freeipa-users] BIND not starting after IPA install Message-ID: <1410438045.3686.29.camel@DV10MX1-Lin.adcock.com> Hi, My bind server refuses to start. I get the following: Sep 11 14:14:40 orpst named-sdb[4343]: generating session key for dynamic DNS Sep 11 14:14:40 orpst named-sdb[4343]: sizing zone task pool based on 6 zones Sep 11 14:14:40 orpst named-sdb[4343]: set up managed keys zone for view _default, file 'dynamic/managed-keys.bind' Sep 11 14:15:30 orpst named-sdb[4343]: Failed to retrieve default realm (Configuration file does not specify default realm) Sep 11 14:15:30 orpst named-sdb[4343]: Failed to init credentials (Cryptosystem internal error) Sep 11 14:15:30 orpst named-sdb[4343]: loading configuration: failure Sep 11 14:15:30 orpst named-sdb[4343]: exiting (due to fatal error) System is running Oracle Linux 6.5 The following is my config: dynamic-db "ipa" { library "ldap.so"; arg "uri ldapi://%2fvar%2frun%2fslapd-SUBDOM-EXAMPLE-COM.socket"; arg "base cn=dns, dc=subdom,dc=example,dc=com"; arg "fake_mname server.subdom.example.com."; arg "auth_method sasl"; arg "sasl_mech GSSAPI"; arg "sasl_user DNS/server.subdom.example.com at SERVER.SUBDOM.COM"; arg "zone_refresh 0"; arg "psearch yes"; arg "serial_autoincrement yes"; }; Any assistance would be appreciated. Regards, -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From traiano at gmail.com Thu Sep 11 13:18:19 2014 From: traiano at gmail.com (Traiano Welcome) Date: Thu, 11 Sep 2014 16:18:19 +0300 Subject: [Freeipa-users] FreeIPA Active directory Integration: ipa "unknown command trustdomain-fetch" Message-ID: Hi List I'm currently working through the IPAv3 AD integration document at: http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup I've managed to establish a trust between the IdM and the AD server. However, when I run the command: --- [root at kwtpocidm001 ~]# ipa trustdomain-fetch "mhatest.local" ipa: ERROR: unknown command 'trustdomain-fetch' --- It would appear the 'trustdomain-fetch' command is not present anymore or has been replaced with something else? I speculate it's this: --- [root at kwtpocidm001 ~]# ipa trust-fetch-domains "mhatest.local" ipa: ERROR: AD domain controller complains about communication sequence. It may mean unsynchronized time on both sides, for example --- Is this correct? If indeed "trust-fetch-domains" is the correct command, then .w.r.t this error message: "ipa: ERROR: AD domain controller complains about communication sequence. It may mean unsynchronized time on both sides, for example" a) Checked the time synch on the AD server and the RHEL 7 IdM server and it's fine. b) Here's a snippet around the error when running ipa with "-d": ---- ipa: DEBUG: approved_usage = SSL Server intended_usage = SSL Server ipa: DEBUG: cert valid True for "CN=kwtpocidm001.linux.mhatest.local,O=LINUX.MHATEST.LOCAL" ipa: DEBUG: handshake complete, peer = 172.16.107.108:443 ipa: DEBUG: received Set-Cookie 'ipa_session=1fe28460c7ec75d6da8d7e3b53c2e51f; Domain=kwtpocidm001.linux.mhatest.local; Path=/ipa; Expires=Thu, 11 Sep 2014 13:12:02 GMT; Secure; HttpOnly' ipa: DEBUG: storing cookie 'ipa_session=1fe28460c7ec75d6da8d7e3b53c2e51f; Domain=kwtpocidm001.linux.mhatest.local; Path=/ipa; Expires=Thu, 11 Sep 2014 13:12:02 GMT; Secure; HttpOnly' for principal admin at LINUX.MHATEST.LOCAL ipa: DEBUG: Starting external process ipa: DEBUG: args=keyctl search @s user ipa_session_cookie:admin at LINUX.MHATEST.LOCAL ipa: DEBUG: Process finished, return code=0 ipa: DEBUG: stdout=334684795 ipa: DEBUG: stderr= ipa: DEBUG: Starting external process ipa: DEBUG: args=keyctl search @s user ipa_session_cookie:admin at LINUX.MHATEST.LOCAL ipa: DEBUG: Process finished, return code=0 ipa: DEBUG: stdout=334684795 ipa: DEBUG: stderr= ipa: DEBUG: Starting external process ipa: DEBUG: args=keyctl pupdate 334684795 ipa: DEBUG: Process finished, return code=0 ipa: DEBUG: stdout= ipa: DEBUG: stderr= ipa: DEBUG: Caught fault 4016 from server https://kwtpocidm001.linux.mhatest.local/ipa/session/xml: AD domain controller complains about communication sequence. It may mean unsynchronized time on both sides, for example ipa: DEBUG: Destroyed connection context.xmlclient ipa: ERROR: AD domain controller complains about communication sequence. It may mean unsynchronized time on both sides, for example ---- Many thanks in advance for any assistance! Traiano -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Thu Sep 11 13:38:01 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 11 Sep 2014 16:38:01 +0300 Subject: [Freeipa-users] FreeIPA Active directory Integration: ipa "unknown command trustdomain-fetch" In-Reply-To: References: Message-ID: <20140911133801.GD2541@redhat.com> On Thu, 11 Sep 2014, Traiano Welcome wrote: >Hi List > >I'm currently working through the IPAv3 AD integration document at: > >http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup > > >I've managed to establish a trust between the IdM and the AD server. >However, when I run the command: > >--- >[root at kwtpocidm001 ~]# ipa trustdomain-fetch "mhatest.local" >ipa: ERROR: unknown command 'trustdomain-fetch' >--- > >It would appear the 'trustdomain-fetch' command is not present anymore or >has been replaced with something else? No, it was my mistake when I expanded the wiki few days ago. ;) # ipa trust 2>&1|grep ' trust' trust-add Add new trust to use. trust-del Delete a trust. trust-fetch-domains Refresh list of the domains associated with the trust trust-find Search for trusts. trust-mod Modify a trust (for future use). trust-show Display information about a trust. trustconfig-mod Modify global trust configuration. trustconfig-show Show global trust configuration. trustdomain-del Remove infromation about the domain associated with the trust. trustdomain-disable Disable use of IPA resources by the domain of the trust trustdomain-enable Allow use of IPA resources by the domain of the trust trustdomain-find Search domains of the trust I fixed the page to use proper one -- trust-fetch-domains. >I speculate it's this: > >--- >[root at kwtpocidm001 ~]# ipa trust-fetch-domains "mhatest.local" >ipa: ERROR: AD domain controller complains about communication sequence. It >may mean unsynchronized time on both sides, for example >--- > >Is this correct? > > >If indeed "trust-fetch-domains" is the correct command, then .w.r.t this >error message: > >"ipa: ERROR: AD domain controller complains about communication sequence. >It may mean unsynchronized time on both sides, for example" > >a) Checked the time synch on the AD server and the RHEL 7 IdM server and >it's fine. Check time zone. I've seen many times that time zone on test Windows installs is set to PDT while your actual zone might be something different; thus it gets out of sync. >b) Here's a snippet around the error when running ipa with "-d": This one is not usable. You need to enable debugging on the server side. See http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Debugging_trust in the part where it talks about /usr/share/ipa/smb.conf.empty. -- / Alexander Bokovoy From jhrozek at redhat.com Thu Sep 11 14:12:40 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 11 Sep 2014 16:12:40 +0200 Subject: [Freeipa-users] FreeIPA, SSSD, sudo and Local Users In-Reply-To: References: Message-ID: <20140911141240.GI20748@hendrix.brq.redhat.com> On Wed, Sep 10, 2014 at 09:58:27PM +0000, Trevor T Kates (Services - 6) wrote: > Hi all: > > I'm using FreeIPA 3.0 under CentOS 6.5 and I'm trying to solve a bit of a quirky > problem. From what I've read thus far, sudo under SSSD can't provide sudo rules > for local users that are not part of the directory. To get around this, I've been > using the sudo-ldap.conf file to provide sudo with direct access to the directory. > This, however, can't make use of service discovery, so if the first server in the > ldap_uri list is taken down, sudo delays for the length of the timeout set. My > idea for getting around this has been to use sudo in SSSD for users that are in > the directory and let sudo-ldap take care of local users with a line in nsswitch.conf > like this: > > sudoers: files sss ldap I think this is more of a sudo question and I'm not too familiar with the sudo code to answer this question well. I added the sudo Fedora maintainer to CC, maybe he has some ideas? > > My problem now seems to be that the ldap query is still run even if a successful hit > is made to sssd. Changing the line in nsswitch.conf to: > > sudoers: files sss [success=return] ldap I don't think [success=return] will work here. Despite sudoers being configured in nsswitch.conf, it's not actually a NSS map handled by glibc. sudo itself parses the file.. > > doesn't seem to actually work. > > Does anyone have pointers on how I can resolve this particular problem? > > Thanks! > > > Trevor T. Kates > > > > > CONFIDENTIALITY NOTICE: This electronic message contains information which may be legally confidential and or privileged and does not in any case represent a firm ENERGY COMMODITY bid or offer relating thereto which binds the sender without an additional express written confirmation to that effect. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project From traiano at gmail.com Thu Sep 11 16:31:27 2014 From: traiano at gmail.com (Traiano Welcome) Date: Thu, 11 Sep 2014 19:31:27 +0300 Subject: [Freeipa-users] FreeIPA Active directory Integration: ipa "unknown command trustdomain-fetch" In-Reply-To: References: <20140911133801.GD2541@redhat.com> Message-ID: On Thu, Sep 11, 2014 at 6:06 PM, Traiano Welcome wrote: > Hi Alexander > > > > On Thu, Sep 11, 2014 at 4:38 PM, Alexander Bokovoy > wrote: > >> On Thu, 11 Sep 2014, Traiano Welcome wrote: >> >>> Hi List >>> >>> I'm currently working through the IPAv3 AD integration document at: >>> >>> http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup >>> >>> >>> I've managed to establish a trust between the IdM and the AD server. >>> However, when I run the command: >>> >>> --- >>> [root at kwtpocidm001 ~]# ipa trustdomain-fetch "mhatest.local" >>> ipa: ERROR: unknown command 'trustdomain-fetch' >>> --- >>> >>> It would appear the 'trustdomain-fetch' command is not present anymore >>> or >>> has been replaced with something else? >>> >> No, it was my mistake when I expanded the wiki few days ago. ;) >> >> # ipa trust 2>&1|grep ' trust' >> trust-add Add new trust to use. >> trust-del Delete a trust. >> trust-fetch-domains Refresh list of the domains associated with the >> trust >> trust-find Search for trusts. >> trust-mod Modify a trust (for future use). >> trust-show Display information about a trust. >> trustconfig-mod Modify global trust configuration. >> trustconfig-show Show global trust configuration. >> trustdomain-del Remove infromation about the domain associated with >> the trust. >> trustdomain-disable Disable use of IPA resources by the domain of the >> trust >> trustdomain-enable Allow use of IPA resources by the domain of the >> trust >> trustdomain-find Search domains of the trust >> >> I fixed the page to use proper one -- trust-fetch-domains. >> >> > > Excellent. Thanks. > > > > > > >> I speculate it's this: >>> >>> --- >>> [root at kwtpocidm001 ~]# ipa trust-fetch-domains "mhatest.local" >>> ipa: ERROR: AD domain controller complains about communication sequence. >>> It >>> may mean unsynchronized time on both sides, for example >>> --- >>> >>> Is this correct? >>> >>> >>> If indeed "trust-fetch-domains" is the correct command, then .w.r.t this >>> error message: >>> >>> "ipa: ERROR: AD domain controller complains about communication sequence. >>> It may mean unsynchronized time on both sides, for example" >>> >>> a) Checked the time synch on the AD server and the RHEL 7 IdM server and >>> it's fine. >>> >> Check time zone. I've seen many times that time zone on test Windows >> installs is set to PDT while your actual zone might be something >> different; thus it gets out of sync. >> >> > > Timezones appear synced/the same: > > - IPA server: Thu Sep 11 18:01:58 AST 2014 > - Windows AD server:Thursday, ?September ?11, ?2014, 6:02:10 PM TZ: > (UTC+03:00) Kuwait, Riyadh > > Just to confirm they're both in sync, I've set the IdM server to use the AD DC as an ntp service: --- [root at kwtpocidm001 ~]# ntpdate -u 172.16.107.109 11 Sep 19:29:11 ntpdate[2736]: adjust time server 172.16.107.109 offset -0.146107 sec --- > > > > >> b) Here's a snippet around the error when running ipa with "-d": >>> >> This one is not usable. You need to enable debugging on the server side. >> See http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup# >> Debugging_trust >> in the part where it talks about /usr/share/ipa/smb.conf.empty. >> >> > > I've attached the debug logs, I'd be thankful if you could find anything > in them! > > >> -- >> / Alexander Bokovoy >> > > Traiano Welcome > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From traiano at gmail.com Thu Sep 11 15:06:50 2014 From: traiano at gmail.com (Traiano Welcome) Date: Thu, 11 Sep 2014 18:06:50 +0300 Subject: [Freeipa-users] FreeIPA Active directory Integration: ipa "unknown command trustdomain-fetch" In-Reply-To: <20140911133801.GD2541@redhat.com> References: <20140911133801.GD2541@redhat.com> Message-ID: Hi Alexander On Thu, Sep 11, 2014 at 4:38 PM, Alexander Bokovoy wrote: > On Thu, 11 Sep 2014, Traiano Welcome wrote: > >> Hi List >> >> I'm currently working through the IPAv3 AD integration document at: >> >> http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup >> >> >> I've managed to establish a trust between the IdM and the AD server. >> However, when I run the command: >> >> --- >> [root at kwtpocidm001 ~]# ipa trustdomain-fetch "mhatest.local" >> ipa: ERROR: unknown command 'trustdomain-fetch' >> --- >> >> It would appear the 'trustdomain-fetch' command is not present anymore or >> has been replaced with something else? >> > No, it was my mistake when I expanded the wiki few days ago. ;) > > # ipa trust 2>&1|grep ' trust' > trust-add Add new trust to use. > trust-del Delete a trust. > trust-fetch-domains Refresh list of the domains associated with the trust > trust-find Search for trusts. > trust-mod Modify a trust (for future use). > trust-show Display information about a trust. > trustconfig-mod Modify global trust configuration. > trustconfig-show Show global trust configuration. > trustdomain-del Remove infromation about the domain associated with > the trust. > trustdomain-disable Disable use of IPA resources by the domain of the > trust > trustdomain-enable Allow use of IPA resources by the domain of the trust > trustdomain-find Search domains of the trust > > I fixed the page to use proper one -- trust-fetch-domains. > > Excellent. Thanks. > I speculate it's this: >> >> --- >> [root at kwtpocidm001 ~]# ipa trust-fetch-domains "mhatest.local" >> ipa: ERROR: AD domain controller complains about communication sequence. >> It >> may mean unsynchronized time on both sides, for example >> --- >> >> Is this correct? >> >> >> If indeed "trust-fetch-domains" is the correct command, then .w.r.t this >> error message: >> >> "ipa: ERROR: AD domain controller complains about communication sequence. >> It may mean unsynchronized time on both sides, for example" >> >> a) Checked the time synch on the AD server and the RHEL 7 IdM server and >> it's fine. >> > Check time zone. I've seen many times that time zone on test Windows > installs is set to PDT while your actual zone might be something > different; thus it gets out of sync. > > Timezones appear synced/the same: - IPA server: Thu Sep 11 18:01:58 AST 2014 - Windows AD server:Thursday, ?September ?11, ?2014, 6:02:10 PM TZ: (UTC+03:00) Kuwait, Riyadh > b) Here's a snippet around the error when running ipa with "-d": >> > This one is not usable. You need to enable debugging on the server side. > See http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Debugging_trust > in the part where it talks about /usr/share/ipa/smb.conf.empty. > > I've attached the debug logs, I'd be thankful if you could find anything in them! > -- > / Alexander Bokovoy > Traiano Welcome -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: debug_data.tar.gz Type: application/x-gzip Size: 492663 bytes Desc: not available URL: From pspacek at redhat.com Thu Sep 11 17:08:11 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 11 Sep 2014 19:08:11 +0200 Subject: [Freeipa-users] BIND not starting after IPA install In-Reply-To: <1410438045.3686.29.camel@DV10MX1-Lin.adcock.com> References: <1410438045.3686.29.camel@DV10MX1-Lin.adcock.com> Message-ID: <5411D6FB.6020002@redhat.com> On 11.9.2014 14:20, Renier Gertzen wrote: > Hi, > > My bind server refuses to start. I get the following: > Sep 11 14:14:40 orpst named-sdb[4343]: generating session key for dynamic DNS > Sep 11 14:14:40 orpst named-sdb[4343]: sizing zone task pool based on 6 zones > Sep 11 14:14:40 orpst named-sdb[4343]: set up managed keys zone for view _default, file 'dynamic/managed-keys.bind' > Sep 11 14:15:30 orpst named-sdb[4343]: Failed to retrieve default realm (Configuration file does not specify default realm) > Sep 11 14:15:30 orpst named-sdb[4343]: Failed to init credentials (Cryptosystem internal error) > Sep 11 14:15:30 orpst named-sdb[4343]: loading configuration: failure > Sep 11 14:15:30 orpst named-sdb[4343]: exiting (due to fatal error) > > System is running Oracle Linux 6.5 > > The following is my config: > dynamic-db "ipa" { > library "ldap.so"; > arg "uri ldapi://%2fvar%2frun%2fslapd-SUBDOM-EXAMPLE-COM.socket"; > arg "base cn=dns, dc=subdom,dc=example,dc=com"; > arg "fake_mname server.subdom.example.com."; > arg "auth_method sasl"; > arg "sasl_mech GSSAPI"; > arg "sasl_user DNS/server.subdom.example.com at SERVER.SUBDOM.COM"; > arg "zone_refresh 0"; > arg "psearch yes"; > arg "serial_autoincrement yes"; > }; > > Any assistance would be appreciated. Hello! Do you use IPA or not? Which version of IPA and bind-dyndb-ldap do you have? AFAIK bind-dyndb-ldap was never tested with sdb version of named... Anyway, I would try to look into /etc/krb5.conf and double check that is contains likes like these: [libdefaults] default_realm = IPA.EXAMPLE Have a nice day! -- Petr^2 Spacek From abokovoy at redhat.com Thu Sep 11 17:16:41 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 11 Sep 2014 20:16:41 +0300 Subject: [Freeipa-users] FreeIPA Active directory Integration: ipa "unknown command trustdomain-fetch" In-Reply-To: References: <20140911133801.GD2541@redhat.com> Message-ID: <20140911171641.GE2541@redhat.com> On Thu, 11 Sep 2014, Traiano Welcome wrote: >>> This one is not usable. You need to enable debugging on the server side. >>> See http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup# >>> Debugging_trust >>> in the part where it talks about /usr/share/ipa/smb.conf.empty. >>> >>> >> >> I've attached the debug logs, I'd be thankful if you could find anything >> in them! Can you please keep debugging and re-establish the trust using AD credentials? I can see that AD DC does believe yet the trust is working: Ticket in credentials cache for @LINUX will expire in 86400 secs GSS client Update(krb5)(1) Update failed: Unspecified GSS failure. Minor code may provide more information: KDC policy rejects request "KDC policy rejects request" means AD-side of the trust is not set and verified. By running 'ipa trust-add ... --admin ..' you'll force AD DC to reset trust and verify it. -- / Alexander Bokovoy From pvoborni at redhat.com Thu Sep 11 17:17:04 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 11 Sep 2014 19:17:04 +0200 Subject: [Freeipa-users] FreeIPA Web UI error: Service Unavailable In-Reply-To: <5411894E.5000809@astron.yasar.com.tr> References: <54117873.4090205@astron.yasar.com.tr> <54118513.6090206@redhat.com> <5411894E.5000809@astron.yasar.com.tr> Message-ID: <5411D910.4030209@redhat.com> On 11.9.2014 13:36, Tevfik Ceydeliler wrote: > hi, > thnx for comment. > I really dont care sibgle sign on or something like that now :) > All I want I try to get back my ipa server :) > I check IPA status and : > [root at srv httpd]# ipactl status > Directory Service: RUNNING > KDC Service: RUNNING > KPASSWD Service: RUNNING > DNS Service: RUNNING > MEMCACHE Service: RUNNING > HTTP Service: RUNNING > CA Service: RUNNING > seems no problem ?n that side. > Now I will resert my httpd error log and restart server. > > [root at srv httpd]# more error_log > [Thu Sep 11 14:22:59 2014] [notice] caught SIGTERM, shutting down > [Thu Sep 11 14:24:18 2014] [notice] SELinux policy enabled; httpd running as > context system_u:system_r:httpd_t:s0 > [Thu Sep 11 14:24:18 2014] [notice] suEXEC mechanism enabled (wrapper: > /usr/sbin/suexec) > [Thu Sep 11 14:24:18 2014] [notice] Digest: generating secret for digest > authentication ... > [Thu Sep 11 14:24:18 2014] [notice] Digest: done > [Thu Sep 11 14:24:19 2014] [notice] Apache/2.2.15 (Unix) DAV/2 mod_auth_kerb/5.4 > mod_nss/2.2.15 NSS/3.15.1 Basic ECC mod_wsgi/3.2 Python/2.6.6 configure > d -- resuming normal operations > [Thu Sep 11 14:24:23 2014] [error] ipa: INFO: *** PROCESS START *** > [Thu Sep 11 14:24:23 2014] [error] ipa: INFO: *** PROCESS START *** > > And > > [root at srv httpd]# service iptables status > iptables: Firewall is not running > > Seems no problem here. > > Which service not available? The "Service not available" is a generic browser 503 error or is it displayed in FreeIPA Web UI (can you access Web UI, but it doesn't work). Does CLI work on the server? > > On 11-09-2014 14:18, Petr Vobornik wrote: >> Hello Tevfik, >> >> comments inline >> >> On 11.9.2014 12:24, Tevfik Ceydeliler wrote: >>> >>> Hi all, >>> I tried to do single sign on for FreeIPa Web UI according to "4.3.3. >>> Configuring the Browser" >>> I did browser side and then turn back to server side. And run those >>> command: >>> >>> # scp /etc/krb5.conf root at externalmachine.example.com:/etc/krb5_ipa.conf >>> and >> >> I assume that you want to configure the machine without enrolling it as >> FreeIPA client. If not, I would suggest you enrolling it as a client using >> ipa-client-install. Then you don't have to do anything else except browser >> config. >> >> Why /etc/krb5_ipa.conf ?, it should be /etc/krb5.conf >> >>> >>> vim /etc/httpd/conf.d/ipa.conf >>> >>> and change this: >>> >>> KrbMethodK5Passwd off --> to --> KrbMethodK5Passwd on >> >> FreeIPA's Web UI support forms-based auth so this is not usually needed. >> >>> >>> and restart httpd. >>> >>> Then nothing change. And then I rollback vim /etc/httpd/conf.d/ipa.conf >>> >>> Now when I try to open Web UI I get An popup error: >>> "Service Unavailable" >> >> run: >> >> ipactl status >> or >> systemctl status httpd.service >> >> or inspect >> >> /var/log/httpd/error_log >> >> to find out if web server is running - might not be the case because of >> invalid modifications in /etc/httpd/conf.d/ipa.conf , reason should be in the log >> >>> >>> Have you any idea? >>> -- Petr Vobornik From mlasevich at gmail.com Fri Sep 12 01:25:11 2014 From: mlasevich at gmail.com (Michael Lasevich) Date: Thu, 11 Sep 2014 18:25:11 -0700 Subject: [Freeipa-users] Use of SAN's with automatic certificates in FreeIPA 4 Message-ID: If I remember correctly, you could not use SAN (Subject Alternate Names) for certificates in FreeIPA 3.0 - is this still the case with 4? I have hosts that automatically receive two hostnames, a long proper name (like "service-i-12345678") and a simpler cname based on an index for ease of access (like "service-1") - however since OS hostname is the "proper" one, certs would typically be issued to that name. I want my users to be able to hit it via the simplex "index" names. Is that currently possible (esp given that the cnames are actualy in a different DNS domain)? Thanks, -M -------------- next part -------------- An HTML attachment was scrubbed... URL: From barrykfl at gmail.com Fri Sep 12 04:13:04 2014 From: barrykfl at gmail.com (barrykfl at gmail.com) Date: Fri, 12 Sep 2014 12:13:04 +0800 Subject: [Freeipa-users] Max life set 0 already but still promot admin rese tpassword every 3 months Message-ID: Hi: i set max life no expiry already but still pomt reset password every 3 month any idea to disable it ??? what happening Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From tevfik.ceydeliler at astron.yasar.com.tr Fri Sep 12 05:17:56 2014 From: tevfik.ceydeliler at astron.yasar.com.tr (Tevfik Ceydeliler) Date: Fri, 12 Sep 2014 08:17:56 +0300 Subject: [Freeipa-users] FreeIPA Web UI error: Service Unavailable In-Reply-To: <5411D910.4030209@redhat.com> References: <54117873.4090205@astron.yasar.com.tr> <54118513.6090206@redhat.com> <5411894E.5000809@astron.yasar.com.tr> <5411D910.4030209@redhat.com> Message-ID: <54128204.3060500@astron.yasar.com.tr> Yes I can use ipa on cli On 11-09-2014 20:17, Petr Vobornik wrote: > On 11.9.2014 13:36, Tevfik Ceydeliler wrote: >> hi, >> thnx for comment. >> I really dont care sibgle sign on or something like that now :) >> All I want I try to get back my ipa server :) >> I check IPA status and : >> [root at srv httpd]# ipactl status >> Directory Service: RUNNING >> KDC Service: RUNNING >> KPASSWD Service: RUNNING >> DNS Service: RUNNING >> MEMCACHE Service: RUNNING >> HTTP Service: RUNNING >> CA Service: RUNNING >> seems no problem ?n that side. >> Now I will resert my httpd error log and restart server. >> >> [root at srv httpd]# more error_log >> [Thu Sep 11 14:22:59 2014] [notice] caught SIGTERM, shutting down >> [Thu Sep 11 14:24:18 2014] [notice] SELinux policy enabled; httpd >> running as >> context system_u:system_r:httpd_t:s0 >> [Thu Sep 11 14:24:18 2014] [notice] suEXEC mechanism enabled (wrapper: >> /usr/sbin/suexec) >> [Thu Sep 11 14:24:18 2014] [notice] Digest: generating secret for digest >> authentication ... >> [Thu Sep 11 14:24:18 2014] [notice] Digest: done >> [Thu Sep 11 14:24:19 2014] [notice] Apache/2.2.15 (Unix) DAV/2 >> mod_auth_kerb/5.4 >> mod_nss/2.2.15 NSS/3.15.1 Basic ECC mod_wsgi/3.2 Python/2.6.6 configure >> d -- resuming normal operations >> [Thu Sep 11 14:24:23 2014] [error] ipa: INFO: *** PROCESS START *** >> [Thu Sep 11 14:24:23 2014] [error] ipa: INFO: *** PROCESS START *** >> >> And >> >> [root at srv httpd]# service iptables status >> iptables: Firewall is not running >> >> Seems no problem here. >> >> Which service not available? > > The "Service not available" is a generic browser 503 error or is it > displayed in FreeIPA Web UI (can you access Web UI, but it doesn't work). > > Does CLI work on the server? > >> >> On 11-09-2014 14:18, Petr Vobornik wrote: >>> Hello Tevfik, >>> >>> comments inline >>> >>> On 11.9.2014 12:24, Tevfik Ceydeliler wrote: >>>> >>>> Hi all, >>>> I tried to do single sign on for FreeIPa Web UI according to "4.3.3. >>>> Configuring the Browser" >>>> I did browser side and then turn back to server side. And run those >>>> command: >>>> >>>> # scp /etc/krb5.conf >>>> root at externalmachine.example.com:/etc/krb5_ipa.conf >>>> and >>> >>> I assume that you want to configure the machine without enrolling it as >>> FreeIPA client. If not, I would suggest you enrolling it as a client >>> using >>> ipa-client-install. Then you don't have to do anything else except >>> browser >>> config. >>> >>> Why /etc/krb5_ipa.conf ?, it should be /etc/krb5.conf >>> >>>> >>>> vim /etc/httpd/conf.d/ipa.conf >>>> >>>> and change this: >>>> >>>> KrbMethodK5Passwd off --> to --> KrbMethodK5Passwd on >>> >>> FreeIPA's Web UI support forms-based auth so this is not usually >>> needed. >>> >>>> >>>> and restart httpd. >>>> >>>> Then nothing change. And then I rollback vim >>>> /etc/httpd/conf.d/ipa.conf >>>> >>>> Now when I try to open Web UI I get An popup error: >>>> "Service Unavailable" >>> >>> run: >>> >>> ipactl status >>> or >>> systemctl status httpd.service >>> >>> or inspect >>> >>> /var/log/httpd/error_log >>> >>> to find out if web server is running - might not be the case because of >>> invalid modifications in /etc/httpd/conf.d/ipa.conf , reason should >>> be in the log >>> >>>> >>>> Have you any idea? >>>> --


Bu elektronik postada bulunan tum fikir ve gorusler ve ekindeki dosyalar sadece adres sahip/sahiplerine ait olup, Yasar Toplulugu Sirketleri bu mesajin icerigi ile ilgili olarak hic bir hukuksal sorumlulugu kabul etmez. Eger gonderilmesi dusunulen kisi veya kurulus degilseniz, lutfen gonderen kisiyi derhal haberdar ediniz ve mesaji sisteminizden siliniz.The information contained in this e-mail and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and Yasar Group Companies do not accept legal responsibility for the contents. If you are not the intended recipient, please immediately notify the sender and delete it from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.png Type: image/png Size: 15216 bytes Desc: not available URL: From renier.gertzen at adcock.com Fri Sep 12 07:16:56 2014 From: renier.gertzen at adcock.com (Renier Gertzen) Date: Fri, 12 Sep 2014 07:16:56 +0000 Subject: [Freeipa-users] BIND not starting after IPA install In-Reply-To: <5411D6FB.6020002@redhat.com> References: <1410438045.3686.29.camel@DV10MX1-Lin.adcock.com> <5411D6FB.6020002@redhat.com> Message-ID: Yes, I use IPA. I have checked /etc/krb5.conf and it does contain: [libdefaults] default_realm = IPA.EXAMPLE Versions are as follows: Name : bind-dyndb-ldap Relocations: (not relocatable) Version : 2.3 Vendor: Oracle America Release : 5.el6 Build Date: Fri 22 Nov 2013 01:29:26 AM SAST Install Date: Tue 09 Sep 2014 11:13:21 AM SAST Build Host: ca-build44.us.oracle.com Name : ipa-server-selinux Relocations: (not relocatable) Version : 3.0.0 Vendor: Oracle America Release : 37.el6 Build Date: Fri 22 Nov 2013 01:25:33 AM SAST Install Date: Wed 10 Sep 2014 04:40:05 PM SAST Build Host: ca-build44.us.oracle.com -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Petr Spacek Sent: 11 September 2014 07:08 PM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] BIND not starting after IPA install On 11.9.2014 14:20, Renier Gertzen wrote: > Hi, > > My bind server refuses to start. I get the following: > Sep 11 14:14:40 orpst named-sdb[4343]: generating session key for > dynamic DNS Sep 11 14:14:40 orpst named-sdb[4343]: sizing zone task > pool based on 6 zones Sep 11 14:14:40 orpst named-sdb[4343]: set up managed keys zone for view _default, file 'dynamic/managed-keys.bind' > Sep 11 14:15:30 orpst named-sdb[4343]: Failed to retrieve default > realm (Configuration file does not specify default realm) Sep 11 > 14:15:30 orpst named-sdb[4343]: Failed to init credentials > (Cryptosystem internal error) Sep 11 14:15:30 orpst named-sdb[4343]: > loading configuration: failure Sep 11 14:15:30 orpst named-sdb[4343]: > exiting (due to fatal error) > > System is running Oracle Linux 6.5 > > The following is my config: > dynamic-db "ipa" { > library "ldap.so"; > arg "uri ldapi://%2fvar%2frun%2fslapd-SUBDOM-EXAMPLE-COM.socket"; > arg "base cn=dns, dc=subdom,dc=example,dc=com"; > arg "fake_mname server.subdom.example.com."; > arg "auth_method sasl"; > arg "sasl_mech GSSAPI"; > arg "sasl_user DNS/server.subdom.example.com at SERVER.SUBDOM.COM"; > arg "zone_refresh 0"; > arg "psearch yes"; > arg "serial_autoincrement yes"; }; > > Any assistance would be appreciated. Hello! Do you use IPA or not? Which version of IPA and bind-dyndb-ldap do you have? AFAIK bind-dyndb-ldap was never tested with sdb version of named... Anyway, I would try to look into /etc/krb5.conf and double check that is contains likes like these: [libdefaults] default_realm = IPA.EXAMPLE Have a nice day! -- Petr^2 Spacek -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project -------------- next part -------------- An HTML attachment was scrubbed... URL: From renier.gertzen at adcock.com Fri Sep 12 07:39:29 2014 From: renier.gertzen at adcock.com (Renier Gertzen) Date: Fri, 12 Sep 2014 07:39:29 +0000 Subject: [Freeipa-users] BIND not starting after IPA install In-Reply-To: References: <1410438045.3686.29.camel@DV10MX1-Lin.adcock.com> <5411D6FB.6020002@redhat.com> Message-ID: Issue resolved in the following manner I saved copies of my named.conf. ran yum remove bind cd /var/named rm -Rf * (be carefull) ran yum install bind copied my named.conf file back service named start And it started and works now. Thanks for the SDB tip. From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Renier Gertzen Sent: 12 September 2014 09:17 AM To: Petr Spacek; freeipa-users at redhat.com Subject: Re: [Freeipa-users] BIND not starting after IPA install Yes, I use IPA. I have checked /etc/krb5.conf and it does contain: [libdefaults] default_realm = IPA.EXAMPLE Versions are as follows: Name : bind-dyndb-ldap Relocations: (not relocatable) Version : 2.3 Vendor: Oracle America Release : 5.el6 Build Date: Fri 22 Nov 2013 01:29:26 AM SAST Install Date: Tue 09 Sep 2014 11:13:21 AM SAST Build Host: ca-build44.us.oracle.com Name : ipa-server-selinux Relocations: (not relocatable) Version : 3.0.0 Vendor: Oracle America Release : 37.el6 Build Date: Fri 22 Nov 2013 01:25:33 AM SAST Install Date: Wed 10 Sep 2014 04:40:05 PM SAST Build Host: ca-build44.us.oracle.com -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Petr Spacek Sent: 11 September 2014 07:08 PM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] BIND not starting after IPA install On 11.9.2014 14:20, Renier Gertzen wrote: > Hi, > > My bind server refuses to start. I get the following: > Sep 11 14:14:40 orpst named-sdb[4343]: generating session key for > dynamic DNS Sep 11 14:14:40 orpst named-sdb[4343]: sizing zone task > pool based on 6 zones Sep 11 14:14:40 orpst named-sdb[4343]: set up managed keys zone for view _default, file 'dynamic/managed-keys.bind' > Sep 11 14:15:30 orpst named-sdb[4343]: Failed to retrieve default > realm (Configuration file does not specify default realm) Sep 11 > 14:15:30 orpst named-sdb[4343]: Failed to init credentials > (Cryptosystem internal error) Sep 11 14:15:30 orpst named-sdb[4343]: > loading configuration: failure Sep 11 14:15:30 orpst named-sdb[4343]: > exiting (due to fatal error) > > System is running Oracle Linux 6.5 > > The following is my config: > dynamic-db "ipa" { > library "ldap.so"; > arg "uri ldapi://%2fvar%2frun%2fslapd-SUBDOM-EXAMPLE-COM.socket"; > arg "base cn=dns, dc=subdom,dc=example,dc=com"; > arg "fake_mname server.subdom.example.com."; > arg "auth_method sasl"; > arg "sasl_mech GSSAPI"; > arg "sasl_user DNS/server.subdom.example.com at SERVER.SUBDOM.COM"; > arg "zone_refresh 0"; > arg "psearch yes"; > arg "serial_autoincrement yes"; }; > > Any assistance would be appreciated. Hello! Do you use IPA or not? Which version of IPA and bind-dyndb-ldap do you have? AFAIK bind-dyndb-ldap was never tested with sdb version of named... Anyway, I would try to look into /etc/krb5.conf and double check that is contains likes like these: [libdefaults] default_realm = IPA.EXAMPLE Have a nice day! -- Petr^2 Spacek -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project Disclaimer http://www.adcock.com/email-disclaimer.htm itevomcid -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Fri Sep 12 08:43:36 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 12 Sep 2014 10:43:36 +0200 Subject: [Freeipa-users] BIND not starting after IPA install In-Reply-To: References: <1410438045.3686.29.camel@DV10MX1-Lin.adcock.com> <5411D6FB.6020002@redhat.com> Message-ID: <5412B238.5070808@redhat.com> Hello! On 12.9.2014 09:39, Renier Gertzen wrote: > Issue resolved in the following manner > > I saved copies of my named.conf. > ran yum remove bind > cd /var/named > rm -Rf * (be carefull) > ran yum install bind > copied my named.conf file back > service named start > > And it started and works now. > Thanks for the SDB tip. Interesting. What did you change? Did you use plain "named" instead of "named-sdb"? How did you manage to install named-sdb? ipa-server-install doesn't do that. Also, I haven't seen ipa-server-selinux package before... Who knows what else was changed by Oracle repackaging? Petr^2 Spacek > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Renier Gertzen > Sent: 12 September 2014 09:17 AM > To: Petr Spacek; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] BIND not starting after IPA install > > Yes, I use IPA. I have checked /etc/krb5.conf and it does contain: > > [libdefaults] > default_realm = IPA.EXAMPLE > > > > Versions are as follows: > Name : bind-dyndb-ldap Relocations: (not relocatable) > Version : 2.3 Vendor: Oracle America > Release : 5.el6 Build Date: Fri 22 Nov 2013 01:29:26 AM SAST > Install Date: Tue 09 Sep 2014 11:13:21 AM SAST Build Host: ca-build44.us.oracle.com > > Name : ipa-server-selinux Relocations: (not relocatable) > Version : 3.0.0 Vendor: Oracle America > Release : 37.el6 Build Date: Fri 22 Nov 2013 01:25:33 AM SAST > Install Date: Wed 10 Sep 2014 04:40:05 PM SAST Build Host: ca-build44.us.oracle.com > > -----Original Message----- > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Petr Spacek > Sent: 11 September 2014 07:08 PM > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] BIND not starting after IPA install > > On 11.9.2014 14:20, Renier Gertzen wrote: >> Hi, >> >> My bind server refuses to start. I get the following: >> Sep 11 14:14:40 orpst named-sdb[4343]: generating session key for >> dynamic DNS Sep 11 14:14:40 orpst named-sdb[4343]: sizing zone task >> pool based on 6 zones Sep 11 14:14:40 orpst named-sdb[4343]: set up managed keys zone for view _default, file 'dynamic/managed-keys.bind' >> Sep 11 14:15:30 orpst named-sdb[4343]: Failed to retrieve default >> realm (Configuration file does not specify default realm) Sep 11 >> 14:15:30 orpst named-sdb[4343]: Failed to init credentials >> (Cryptosystem internal error) Sep 11 14:15:30 orpst named-sdb[4343]: >> loading configuration: failure Sep 11 14:15:30 orpst named-sdb[4343]: >> exiting (due to fatal error) >> >> System is running Oracle Linux 6.5 >> >> The following is my config: >> dynamic-db "ipa" { >> library "ldap.so"; >> arg "uri ldapi://%2fvar%2frun%2fslapd-SUBDOM-EXAMPLE-COM.socket"; >> arg "base cn=dns, dc=subdom,dc=example,dc=com"; >> arg "fake_mname server.subdom.example.com."; >> arg "auth_method sasl"; >> arg "sasl_mech GSSAPI"; >> arg "sasl_user DNS/server.subdom.example.com at SERVER.SUBDOM.COM"; >> arg "zone_refresh 0"; >> arg "psearch yes"; >> arg "serial_autoincrement yes"; }; >> >> Any assistance would be appreciated. > > > Hello! > > Do you use IPA or not? Which version of IPA and bind-dyndb-ldap do you have? > > AFAIK bind-dyndb-ldap was never tested with sdb version of named... > > Anyway, I would try to look into /etc/krb5.conf and double check that is contains likes like these: > > [libdefaults] > default_realm = IPA.EXAMPLE > > Have a nice day! > > -- > Petr^2 Spacek > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > > > Disclaimer > > http://www.adcock.com/email-disclaimer.htm itevomcid > -- Petr^2 Spacek From renier.gertzen at adcock.com Fri Sep 12 08:57:41 2014 From: renier.gertzen at adcock.com (Renier Gertzen) Date: Fri, 12 Sep 2014 08:57:41 +0000 Subject: [Freeipa-users] BIND not starting after IPA install In-Reply-To: <5412B238.5070808@redhat.com> References: <1410438045.3686.29.camel@DV10MX1-Lin.adcock.com> <5411D6FB.6020002@redhat.com> <5412B238.5070808@redhat.com> Message-ID: <1410512111.3686.36.camel@DV10MX1-Lin.adcock.com> Hi Before starting IPA install i did "yum -y intstall bind*". I think that did it. Regards, On Fri, 2014-09-12 at 10:43 +0200, Petr Spacek wrote: Hello! On 12.9.2014 09:39, Renier Gertzen wrote: > Issue resolved in the following manner > > I saved copies of my named.conf. > ran yum remove bind > cd /var/named > rm -Rf * (be carefull) > ran yum install bind > copied my named.conf file back > service named start > > And it started and works now. > Thanks for the SDB tip. Interesting. What did you change? Did you use plain "named" instead of "named-sdb"? How did you manage to install named-sdb? ipa-server-install doesn't do that. Also, I haven't seen ipa-server-selinux package before... Who knows what else was changed by Oracle repackaging? Petr^2 Spacek > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Renier Gertzen > Sent: 12 September 2014 09:17 AM > To: Petr Spacek; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] BIND not starting after IPA install > > Yes, I use IPA. I have checked /etc/krb5.conf and it does contain: > > [libdefaults] > default_realm = IPA.EXAMPLE > > > > Versions are as follows: > Name : bind-dyndb-ldap Relocations: (not relocatable) > Version : 2.3 Vendor: Oracle America > Release : 5.el6 Build Date: Fri 22 Nov 2013 01:29:26 AM SAST > Install Date: Tue 09 Sep 2014 11:13:21 AM SAST Build Host: ca-build44.us.oracle.com > > Name : ipa-server-selinux Relocations: (not relocatable) > Version : 3.0.0 Vendor: Oracle America > Release : 37.el6 Build Date: Fri 22 Nov 2013 01:25:33 AM SAST > Install Date: Wed 10 Sep 2014 04:40:05 PM SAST Build Host: ca-build44.us.oracle.com > > -----Original Message----- > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Petr Spacek > Sent: 11 September 2014 07:08 PM > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] BIND not starting after IPA install > > On 11.9.2014 14:20, Renier Gertzen wrote: >> Hi, >> >> My bind server refuses to start. I get the following: >> Sep 11 14:14:40 orpst named-sdb[4343]: generating session key for >> dynamic DNS Sep 11 14:14:40 orpst named-sdb[4343]: sizing zone task >> pool based on 6 zones Sep 11 14:14:40 orpst named-sdb[4343]: set up managed keys zone for view _default, file 'dynamic/managed-keys.bind' >> Sep 11 14:15:30 orpst named-sdb[4343]: Failed to retrieve default >> realm (Configuration file does not specify default realm) Sep 11 >> 14:15:30 orpst named-sdb[4343]: Failed to init credentials >> (Cryptosystem internal error) Sep 11 14:15:30 orpst named-sdb[4343]: >> loading configuration: failure Sep 11 14:15:30 orpst named-sdb[4343]: >> exiting (due to fatal error) >> >> System is running Oracle Linux 6.5 >> >> The following is my config: >> dynamic-db "ipa" { >> library "ldap.so"; >> arg "uri ldapi://%2fvar%2frun%2fslapd-SUBDOM-EXAMPLE-COM.socket"; >> arg "base cn=dns, dc=subdom,dc=example,dc=com"; >> arg "fake_mname server.subdom.example.com."; >> arg "auth_method sasl"; >> arg "sasl_mech GSSAPI"; >> arg "sasl_user DNS/server.subdom.example.com at SERVER.SUBDOM.COM"; >> arg "zone_refresh 0"; >> arg "psearch yes"; >> arg "serial_autoincrement yes"; }; >> >> Any assistance would be appreciated. > > > Hello! > > Do you use IPA or not? Which version of IPA and bind-dyndb-ldap do you have? > > AFAIK bind-dyndb-ldap was never tested with sdb version of named... > > Anyway, I would try to look into /etc/krb5.conf and double check that is contains likes like these: > > [libdefaults] > default_realm = IPA.EXAMPLE > > Have a nice day! > > -- > Petr^2 Spacek > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > > > Disclaimer > > http://www.adcock.com/email-disclaimer.htm itevomcid > -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri Sep 12 11:12:50 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 12 Sep 2014 07:12:50 -0400 Subject: [Freeipa-users] Use of SAN's with automatic certificates in FreeIPA 4 In-Reply-To: References: Message-ID: <5412D532.6080503@redhat.com> On 09/11/2014 09:25 PM, Michael Lasevich wrote: > If I remember correctly, you could not use SAN (Subject Alternate > Names) for certificates in FreeIPA 3.0 - is this still the case with 4? https://fedorahosted.org/freeipa/ticket/3977 < 4.0 is able. > > I have hosts that automatically receive two hostnames, a long proper > name (like "service-i-12345678") and a simpler cname based on an index > for ease of access (like "service-1") - however since OS hostname is > the "proper" one, certs would typically be issued to that name. I want > my users to be able to hit it via the simplex "index" names. Is that > currently possible (esp given that the cnames are actualy in a > different DNS domain)? > > Thanks, > > -M > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri Sep 12 11:13:45 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 12 Sep 2014 07:13:45 -0400 Subject: [Freeipa-users] Max life set 0 already but still promot admin rese tpassword every 3 months In-Reply-To: References: Message-ID: <5412D569.1010006@redhat.com> On 09/12/2014 12:13 AM, barrykfl at gmail.com wrote: > Hi: > > i set max life no expiry already but still pomt reset password every 3 > month > > any idea to disable it ??? what happening > > Regards > > > Where/how did you set it and what version do you run? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri Sep 12 11:18:29 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 12 Sep 2014 07:18:29 -0400 Subject: [Freeipa-users] Max life set 0 already but still promot admin rese tpassword every 3 months In-Reply-To: <5412D569.1010006@redhat.com> References: <5412D569.1010006@redhat.com> Message-ID: <5412D685.4000304@redhat.com> On 09/12/2014 07:13 AM, Dmitri Pal wrote: > On 09/12/2014 12:13 AM, barrykfl at gmail.com wrote: >> Hi: >> >> i set max life no expiry already but still pomt reset password every >> 3 month >> >> any idea to disable it ??? what happening >> >> Regards >> >> >> > Where/how did you set it and what version do you run? AFAIR the recommendation to set it to beginning of the last year of the 32 bit time epoch. "The original implementation of the Unix operating system stored system time as a 32-bit signed integer representing the number of seconds past the Unix epoch: midnight UTC, 1 January 1970. This value will roll over on *19 January 2038*." Kerberos still uses 32 time. So set it to Jan 1 2038. It is the best approximation of "never". I think if you set it to 0 it assumes the default which is 90 days. HTH Dmitri > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Fri Sep 12 11:22:32 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 12 Sep 2014 13:22:32 +0200 Subject: [Freeipa-users] Max life set 0 already but still promot admin rese tpassword every 3 months In-Reply-To: <5412D685.4000304@redhat.com> References: <5412D569.1010006@redhat.com> <5412D685.4000304@redhat.com> Message-ID: <5412D778.3010907@redhat.com> On 12.9.2014 13:18, Dmitri Pal wrote: > On 09/12/2014 07:13 AM, Dmitri Pal wrote: >> On 09/12/2014 12:13 AM, barrykfl at gmail.com wrote: >>> Hi: >>> >>> i set max life no expiry already but still pomt reset password every 3 month >>> >>> any idea to disable it ??? what happening >>> >>> Regards >>> >>> >>> >> Where/how did you set it and what version do you run? > > AFAIR the recommendation to set it to beginning of the last year of the 32 bit > time epoch. > "The original implementation of the Unix operating system stored system time > as a 32-bit signed integer representing the number of seconds past the Unix > epoch: midnight UTC, 1 January 1970. This value will roll over on *19 January > 2038*." > > Kerberos still uses 32 time. So set it to Jan 1 2038. It is the best > approximation of "never". > I think if you set it to 0 it assumes the default which is 90 days. This sounds like matter for a small improvement ticket. It could at least print warning that "0 = default = 90 days". -- Petr^2 Spacek From mkosek at redhat.com Fri Sep 12 12:38:48 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 12 Sep 2014 14:38:48 +0200 Subject: [Freeipa-users] freeipa server install fails on fedora 20 In-Reply-To: References: <540E24BA.3070803@redhat.com> <540E3EC5.7050203@redhat.com> <540F1183.3010607@redhat.com> Message-ID: <5412E958.8000305@redhat.com> On 09/09/2014 05:27 PM, Olga Kornievskaia wrote: > > > On Tue, Sep 9, 2014 at 10:41 AM, Rob Crittenden > wrote: > > Olga Kornievskaia wrote: > > > > > > On Mon, Sep 8, 2014 at 7:41 PM, Dmitri Pal > > >> wrote: > > > > On 09/08/2014 07:29 PM, Olga Kornievskaia wrote: > >> Thank you very much for your quick reply. > >> > >> It is a brand new fedora 20 vm. > > > > OK good. > > Can you send or share the ipa server installation log? > > > > > > Can you please suggest how I can do that? My original post was rejected > > by the administrator of this list because I've included the install log > > that compressed was over 5M. > > If you have a web/ftp server available you can put it there for download. > > > I have put the files in google drive and they should be accessible via this link: > freeipa-install-logs - > https://drive.google.com/folderview?id=0B7NX-2naBL7GWXVIOS11YnZLZWM&usp=sharing > > Please let me know if there are problems accessing it. > > > I'd look at the catalina.* logs in /var/log/pki/pki-tomcat and debug in > the ca subdirectory. Those are more likely to hold startup failures. > > > I have included the "debug", "ca-spawn", and snippet of "journalctl" output > files. Personally, I wasn't able to find any error messages in there. > > Thank you. I saw no updates to this thread - did you make any progress? I also did not see any obvious errors in the logs you provided. To see what happened I think you would need to zip whole /var/log/pki/pki-tomcat directory and share it with us. We may be also interested to see /var/log/httpd/error_log as it may also contain some hint why is this responder not available. It would be also nice to look for SELinux errors if you are running in enforcing mode. You can check for example with # ausearch -m AVC -ts today I am CCing PKI developers to be aware of this failure. HTH, Martin From mkosek at redhat.com Fri Sep 12 12:41:51 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 12 Sep 2014 14:41:51 +0200 Subject: [Freeipa-users] IPA Version 3.0.0 Allow Self-Signed Certificates In-Reply-To: References: Message-ID: <5412EA0F.8030405@redhat.com> On 09/09/2014 06:01 PM, Eric Hart wrote: > I'm trying to find a way to enable FreeIPA to allow Self-Signed Certificates. > I haven't found a way to enable that capability yet.. > > I've manually edited configuration files within /etc/dirsrv/slapd-EXAMPLE-COM, > specifically the nsslapd-ssl-check-hostname, nsslapd-validate-cert options set > to off and warn respectively. > > Not allowing self-signed certificates has caused me to not be able to establish > a replicated server or integrate a device for SSO that provides a self signed > certificate. > > Thanks for any input or insight, > Eric I do not entirely understand the use case. So you want to run FreeIPA without CA, with httpd+dirsrv running with self-signed certificates or you want FreeIPA CA to issue a self signed certificate for your service (which does not make much sense to me)? BTW relevant training material: http://www.freeipa.org/images/b/b3/FreeIPA33-blending-in-a-certificate-infrastructure.pdf HTH, Martin From mkosek at redhat.com Fri Sep 12 12:47:08 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 12 Sep 2014 14:47:08 +0200 Subject: [Freeipa-users] json api docs In-Reply-To: <5410E791.2090407@redhat.com> References: <5410DA78.2030802@martos.bme.hu> <5410E791.2090407@redhat.com> Message-ID: <5412EB4C.7010208@redhat.com> On 09/11/2014 02:06 AM, Dmitri Pal wrote: > On 09/10/2014 07:10 PM, Tamas Papp wrote: >> hi All, >> >> Is there an offficial API documentation available? > > Unfortunately not much. You can search archives and find some recommendations > that helped people in the past. > https://www.redhat.com/archives/freeipa-users/2013-January/msg00109.html > > We also have a ticket > https://fedorahosted.org/freeipa/ticket/3129 We also have a ticket https://fedorahosted.org/freeipa/ticket/4233 targeted on FreeIPA 4.1 to see the actual JSON queries that "ipa" command sends. It would make it easier to see how we use the API. > >> >> Also is there a simple way to logon and run commands through API without a >> kerberos ticket? > > Once you authenticated with Kerberos and negotiated GSSAPI the server will > issue a cookie that will be stored on the client and can be used to continue > operations. But Kerberos is needed for the first connection. It is a > requirement because it is a best practice. >> >> >> Thanks, >> tamas >> > > From mkosek at redhat.com Fri Sep 12 12:55:46 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 12 Sep 2014 14:55:46 +0200 Subject: [Freeipa-users] Max life set 0 already but still promot admin rese tpassword every 3 months In-Reply-To: <5412D778.3010907@redhat.com> References: <5412D569.1010006@redhat.com> <5412D685.4000304@redhat.com> <5412D778.3010907@redhat.com> Message-ID: <5412ED52.4010804@redhat.com> On 09/12/2014 01:22 PM, Petr Spacek wrote: > On 12.9.2014 13:18, Dmitri Pal wrote: >> On 09/12/2014 07:13 AM, Dmitri Pal wrote: >>> On 09/12/2014 12:13 AM, barrykfl at gmail.com wrote: >>>> Hi: >>>> >>>> i set max life no expiry already but still pomt reset password every 3 month >>>> >>>> any idea to disable it ??? what happening >>>> >>>> Regards >>>> >>>> >>>> >>> Where/how did you set it and what version do you run? >> >> AFAIR the recommendation to set it to beginning of the last year of the 32 bit >> time epoch. >> "The original implementation of the Unix operating system stored system time >> as a 32-bit signed integer representing the number of seconds past the Unix >> epoch: midnight UTC, 1 January 1970. This value will roll over on *19 January >> 2038*." >> >> Kerberos still uses 32 time. So set it to Jan 1 2038. It is the best >> approximation of "never". >> I think if you set it to 0 it assumes the default which is 90 days. > > This sounds like matter for a small improvement ticket. It could at least print > warning that "0 = default = 90 days". > We have that RFE ticket filed already: https://fedorahosted.org/freeipa/ticket/2795 Please add yourself to CC to show interest in the change + get updates (or even send a patch! :-) Martin From tompos at martos.bme.hu Fri Sep 12 13:36:28 2014 From: tompos at martos.bme.hu (Tamas Papp) Date: Fri, 12 Sep 2014 15:36:28 +0200 Subject: [Freeipa-users] json api docs In-Reply-To: <5412EB4C.7010208@redhat.com> References: <5410DA78.2030802@martos.bme.hu> <5410E791.2090407@redhat.com> <5412EB4C.7010208@redhat.com> Message-ID: <5412F6DC.1010707@martos.bme.hu> On 09/12/2014 02:47 PM, Martin Kosek wrote: > On 09/11/2014 02:06 AM, Dmitri Pal wrote: >> On 09/10/2014 07:10 PM, Tamas Papp wrote: >>> hi All, >>> >>> Is there an offficial API documentation available? >> >> Unfortunately not much. You can search archives and find some >> recommendations >> that helped people in the past. >> https://www.redhat.com/archives/freeipa-users/2013-January/msg00109.html >> >> We also have a ticket >> https://fedorahosted.org/freeipa/ticket/3129 > > We also have a ticket > https://fedorahosted.org/freeipa/ticket/4233 > targeted on FreeIPA 4.1 to see the actual JSON queries that "ipa" > command sends. It would make it easier to see how we use the API. Actually what is the recommended way to use ipa as a simple ldap backend for a service without kerberos? In fact the service does not need kerberos and things like that, but I like the helper tools of ipa, like ipa command, web UI, easy replication etc. Can I make trouble by writing the directory directly though ldap (add/delete/modify users + groups). 10x tamas From pviktori at redhat.com Fri Sep 12 13:47:36 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 12 Sep 2014 15:47:36 +0200 Subject: [Freeipa-users] json api docs In-Reply-To: <5412F6DC.1010707@martos.bme.hu> References: <5410DA78.2030802@martos.bme.hu> <5410E791.2090407@redhat.com> <5412EB4C.7010208@redhat.com> <5412F6DC.1010707@martos.bme.hu> Message-ID: <5412F978.4000702@redhat.com> On 09/12/2014 03:36 PM, Tamas Papp wrote: > > On 09/12/2014 02:47 PM, Martin Kosek wrote: >> On 09/11/2014 02:06 AM, Dmitri Pal wrote: >>> On 09/10/2014 07:10 PM, Tamas Papp wrote: >>>> hi All, >>>> >>>> Is there an offficial API documentation available? >>> >>> Unfortunately not much. You can search archives and find some >>> recommendations >>> that helped people in the past. >>> https://www.redhat.com/archives/freeipa-users/2013-January/msg00109.html >>> >>> We also have a ticket >>> https://fedorahosted.org/freeipa/ticket/3129 >> >> We also have a ticket >> https://fedorahosted.org/freeipa/ticket/4233 >> targeted on FreeIPA 4.1 to see the actual JSON queries that "ipa" >> command sends. It would make it easier to see how we use the API. > > Actually what is the recommended way to use ipa as a simple ldap backend > for a service without kerberos? > In fact the service does not need kerberos and things like that, but I > like the helper tools of ipa, like ipa command, web UI, easy replication > etc. IPA is an integrated solution. Kerberos is built in and the other parts assume it's there. There's no recommended way without Kerberos. > Can I make trouble by writing the directory directly though ldap > (add/delete/modify users + groups). Yes, this will cause trouble. The IPA commands do additional processing, e.g. creating user private groups. -- Petr? From traiano at gmail.com Fri Sep 12 13:55:15 2014 From: traiano at gmail.com (Traiano Welcome) Date: Fri, 12 Sep 2014 16:55:15 +0300 Subject: [Freeipa-users] FreeIPA Active directory Integration: ipa "unknown command trustdomain-fetch" In-Reply-To: <20140911171641.GE2541@redhat.com> References: <20140911133801.GD2541@redhat.com> <20140911171641.GE2541@redhat.com> Message-ID: Hi Alexander On Thu, Sep 11, 2014 at 8:16 PM, Alexander Bokovoy wrote: > On Thu, 11 Sep 2014, Traiano Welcome wrote: > >> This one is not usable. You need to enable debugging on the server side. >>>> See http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup# >>>> Debugging_trust >>>> in the part where it talks about /usr/share/ipa/smb.conf.empty. >>>> >>>> >>>> >>> I've attached the debug logs, I'd be thankful if you could find anything >>> in them! >>> >> Can you please keep debugging and re-establish the trust using AD > credentials? > > I can see that AD DC does believe yet the trust is working: > Ticket in credentials cache for @LINUX will expire in 86400 secs > GSS client Update(krb5)(1) Update failed: Unspecified GSS failure. > Minor code may provide more information: KDC policy rejects request > > "KDC policy rejects request" means AD-side of the trust is not set and > verified. > > By running 'ipa trust-add ... --admin ..' you'll force AD DC to reset trust > and verify it. > > Just to confirm: The guide says that Windows 2008 R2 should be used as an AD DC, and provides a link to a setup process for Windows 2008 R2. However later on in the doc there is animated gif of Windows 2012 ... Does this matter? Will different setups based on Win2K8 or Win2K12 DC affect the installation process in any way on the IdM side? > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Fri Sep 12 14:00:45 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 12 Sep 2014 17:00:45 +0300 Subject: [Freeipa-users] FreeIPA Active directory Integration: ipa "unknown command trustdomain-fetch" In-Reply-To: References: <20140911133801.GD2541@redhat.com> <20140911171641.GE2541@redhat.com> Message-ID: <20140912140045.GK2541@redhat.com> On Fri, 12 Sep 2014, Traiano Welcome wrote: >Hi Alexander > > > > >On Thu, Sep 11, 2014 at 8:16 PM, Alexander Bokovoy >wrote: > >> On Thu, 11 Sep 2014, Traiano Welcome wrote: >> >>> This one is not usable. You need to enable debugging on the server side. >>>>> See http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup# >>>>> Debugging_trust >>>>> in the part where it talks about /usr/share/ipa/smb.conf.empty. >>>>> >>>>> >>>>> >>>> I've attached the debug logs, I'd be thankful if you could find anything >>>> in them! >>>> >>> Can you please keep debugging and re-establish the trust using AD >> credentials? >> >> I can see that AD DC does believe yet the trust is working: >> Ticket in credentials cache for @LINUX will expire in 86400 secs >> GSS client Update(krb5)(1) Update failed: Unspecified GSS failure. >> Minor code may provide more information: KDC policy rejects request >> >> "KDC policy rejects request" means AD-side of the trust is not set and >> verified. >> >> By running 'ipa trust-add ... --admin ..' you'll force AD DC to reset trust >> and verify it. >> >> > >Just to confirm: The guide says that Windows 2008 R2 should be used as an >AD DC, and provides a link to a setup process for Windows 2008 R2. However >later on in the doc there is animated gif of Windows 2012 ... Does this >matter? > >Will different setups based on Win2K8 or Win2K12 DC affect the installation >process in any way on the IdM side? I have both Windows Server 2008 (actually, 2008 and 2008R2) and Windows Server 2012 working in my lab. Both have trusts established to FreeIPA domain and work fine. -- / Alexander Bokovoy From pspacek at redhat.com Fri Sep 12 14:11:02 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 12 Sep 2014 16:11:02 +0200 Subject: [Freeipa-users] json api docs In-Reply-To: <5412F978.4000702@redhat.com> References: <5410DA78.2030802@martos.bme.hu> <5410E791.2090407@redhat.com> <5412EB4C.7010208@redhat.com> <5412F6DC.1010707@martos.bme.hu> <5412F978.4000702@redhat.com> Message-ID: <5412FEF6.7090404@redhat.com> On 12.9.2014 15:47, Petr Viktorin wrote: > On 09/12/2014 03:36 PM, Tamas Papp wrote: >> >> On 09/12/2014 02:47 PM, Martin Kosek wrote: >>> On 09/11/2014 02:06 AM, Dmitri Pal wrote: >>>> On 09/10/2014 07:10 PM, Tamas Papp wrote: >>>>> hi All, >>>>> >>>>> Is there an offficial API documentation available? >>>> >>>> Unfortunately not much. You can search archives and find some >>>> recommendations >>>> that helped people in the past. >>>> https://www.redhat.com/archives/freeipa-users/2013-January/msg00109.html >>>> >>>> We also have a ticket >>>> https://fedorahosted.org/freeipa/ticket/3129 >>> >>> We also have a ticket >>> https://fedorahosted.org/freeipa/ticket/4233 >>> targeted on FreeIPA 4.1 to see the actual JSON queries that "ipa" >>> command sends. It would make it easier to see how we use the API. >> >> Actually what is the recommended way to use ipa as a simple ldap backend >> for a service without kerberos? >> In fact the service does not need kerberos and things like that, but I >> like the helper tools of ipa, like ipa command, web UI, easy replication >> etc. > > IPA is an integrated solution. Kerberos is built in and the other parts assume > it's there. There's no recommended way without Kerberos. Just for the case: If you want to use FreeIPA with a service which is able to use pure LDAP BIND as authentication method then sure - it will work. FreeIPA is still standard compliant LDAP server. >> Can I make trouble by writing the directory directly though ldap >> (add/delete/modify users + groups). > > Yes, this will cause trouble. > The IPA commands do additional processing, e.g. creating user private groups. -- Petr^2 Spacek From pspacek at redhat.com Fri Sep 12 14:25:11 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 12 Sep 2014 16:25:11 +0200 Subject: [Freeipa-users] [Freeipa-interest] Announcing bind-dyndb-ldap version 5.3 Message-ID: <54130247.50902@redhat.com> The FreeIPA team is proud to announce bind-dyndb-ldap version 5.3. It can be downloaded from https://fedorahosted.org/released/bind-dyndb-ldap/ The new version has also been built for Fedora 21+ and and is on its way to updates-testing: https://admin.fedoraproject.org/updates/bind-dyndb-ldap-5.3-1.fc21 This version is also available from FreeIPA COPR repo: http://copr.fedoraproject.org/coprs/mkosek/freeipa/ 5.3 ==== [1] Internal locking was reworked to prevent crashes and deadlocks. 5.2 ==== [1] Kerberos ticket expiration is now handled correctly. https://fedorahosted.org/bind-dyndb-ldap/ticket/131 [2] BIND no longer crashes after removing root zone from LDAP. https://fedorahosted.org/bind-dyndb-ldap/ticket/138 [3] Root zone handling was fixed to prevent accidental child zone removal. https://fedorahosted.org/bind-dyndb-ldap/ticket/122 [4] Temporary files for idnsZone objects are now inside master/ subdirectory. [5] Temporary directories are created with ug=rwx,o= permissions to enable POSIX ACL usage. [6] Naming rules for working directories have changed: See README section 6. [7] Documentation clearly states that idnsZoneActive attribute is not supported. == Upgrading == A server can be upgraded by installing updated RPM. BIND has to be restarted manually after the RPM installation. !!! CAUTION !!! idnsZone object class changed it's semantics in version 5.0. Please read https://git.fedorahosted.org/cgit/bind-dyndb-ldap.git/plain/README and update idnsForwarders and idnsForward policy attributes in your DNS zones accordingly. Transition from idnsZone to idnsForwardZone object class can be made seamless if you change data in LDAP before you upgrade to version 5.x. All bind-dyndb-ldap versions >= 3.0 support the idnsForwardZone object class. Users of FreeIPA < 4.0 should be careful when upgrading bind-dyndb-ldap to version >= 5.0 (if they do not upgrade to FreeIPA 4.x at the same time). Configuration semantics related to conditional (per-zone) forwarding has changed and FreeIPA < 4.0 doesn't have appropriate user interface and API. It is safe to upgrade if you use *only* global forwarders (shown by 'ipa dnsconfig-show') and *do not* use per-zone forwarders (shown by 'ipa dnszone-show'). Don't hesitate to ask freeipa-users mailing list if you need help with upgrade. !!! CAUTION !!! Downgrading back to any 4.x version is supported. == Feedback == Please provide comments, report bugs and send any other feedback via the freeipa-users mailing list: http://www.redhat.com/mailman/listinfo/freeipa-users -- Petr^2 Spacek From mkosek at redhat.com Fri Sep 12 14:30:28 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 12 Sep 2014 16:30:28 +0200 Subject: [Freeipa-users] json api docs In-Reply-To: <5412F6DC.1010707@martos.bme.hu> References: <5410DA78.2030802@martos.bme.hu> <5410E791.2090407@redhat.com> <5412EB4C.7010208@redhat.com> <5412F6DC.1010707@martos.bme.hu> Message-ID: <54130384.50208@redhat.com> On 09/12/2014 03:36 PM, Tamas Papp wrote: > > On 09/12/2014 02:47 PM, Martin Kosek wrote: >> On 09/11/2014 02:06 AM, Dmitri Pal wrote: >>> On 09/10/2014 07:10 PM, Tamas Papp wrote: >>>> hi All, >>>> >>>> Is there an offficial API documentation available? >>> >>> Unfortunately not much. You can search archives and find some recommendations >>> that helped people in the past. >>> https://www.redhat.com/archives/freeipa-users/2013-January/msg00109.html >>> >>> We also have a ticket >>> https://fedorahosted.org/freeipa/ticket/3129 >> >> We also have a ticket >> https://fedorahosted.org/freeipa/ticket/4233 >> targeted on FreeIPA 4.1 to see the actual JSON queries that "ipa" command >> sends. It would make it easier to see how we use the API. > > Actually what is the recommended way to use ipa as a simple ldap backend for a > service without kerberos? > In fact the service does not need kerberos and things like that, but I like the > helper tools of ipa, like ipa command, web UI, easy replication etc. > > Can I make trouble by writing the directory directly though ldap > (add/delete/modify users + groups). > > 10x > tamas You can of course use FreeIPA only as an LDAP backend to your app, even though Kerberos brings many advantages - but this is not what you asked :-) If you are lucky and you set all the attributes correctly, you could add users via ldapadd. But we do not recommend it as one can easily miss some change, attribute or objectclass that ipa command does and other tool expects. So using the API or ipa tool itself is a recommended way of communication. However, note that we have a work in progress exactly on this feature, i.e. an ability to add users via LDAP protocol and then have them processed by ipa tools adding all required attributes and stuff. See tickets https://fedorahosted.org/freeipa/ticket/3813 https://fedorahosted.org/freeipa/ticket/4445 and design page http://www.freeipa.org/page/V4/User_Life-Cycle_Management This work is planned for FreeIPA 4.2. Martin Martin From dpal at redhat.com Fri Sep 12 17:02:20 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 12 Sep 2014 13:02:20 -0400 Subject: [Freeipa-users] json api docs In-Reply-To: <5412F6DC.1010707@martos.bme.hu> References: <5410DA78.2030802@martos.bme.hu> <5410E791.2090407@redhat.com> <5412EB4C.7010208@redhat.com> <5412F6DC.1010707@martos.bme.hu> Message-ID: <5413271C.5010305@redhat.com> On 09/12/2014 09:36 AM, Tamas Papp wrote: > > On 09/12/2014 02:47 PM, Martin Kosek wrote: >> On 09/11/2014 02:06 AM, Dmitri Pal wrote: >>> On 09/10/2014 07:10 PM, Tamas Papp wrote: >>>> hi All, >>>> >>>> Is there an offficial API documentation available? >>> >>> Unfortunately not much. You can search archives and find some >>> recommendations >>> that helped people in the past. >>> https://www.redhat.com/archives/freeipa-users/2013-January/msg00109.html >>> >>> >>> We also have a ticket >>> https://fedorahosted.org/freeipa/ticket/3129 >> >> We also have a ticket >> https://fedorahosted.org/freeipa/ticket/4233 >> targeted on FreeIPA 4.1 to see the actual JSON queries that "ipa" >> command sends. It would make it easier to see how we use the API. > > Actually what is the recommended way to use ipa as a simple ldap > backend for a service without kerberos? You have seen other answers but I think a fair question to ask here is what does the service do and what kind of ldap info it needs? Is it read only or read write? > In fact the service does not need kerberos and things like that, but I > like the helper tools of ipa, like ipa command, web UI, easy > replication etc. > > Can I make trouble by writing the directory directly though ldap > (add/delete/modify users + groups). > > 10x > tamas > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From mlasevich at lasevich.net Fri Sep 12 18:43:54 2014 From: mlasevich at lasevich.net (Michael Lasevich) Date: Fri, 12 Sep 2014 11:43:54 -0700 Subject: [Freeipa-users] Use of SAN's with automatic certificates in FreeIPA 4 In-Reply-To: <5412D532.6080503@redhat.com> References: <5412D532.6080503@redhat.com> Message-ID: That is awesome, but I am clearly missing some insight as to how this is supposed to work. Can you point me to some more specific info on how to accomplish this. I tried using the ipa-getcert request with multiple -D's from the client, but got : ** Insufficient access: You need to be a member of the serviceadmin role to add services Unless I am missing something, I should probably not add each host to "serviceadmins" for security reasons. So I then I tried generating a csr via openssl with SANs on the client and then adding it using "ipa cert-request file.csr --prinicple host/${client_hostname}@DOMAIN" from ipa server as admin (just to be sure) and got this error (where is the first SAN): ** ipa: ERROR: The service principal for subject alt name in certificate request does not exist It sounds like I need to create service principal for each SAN, but I can't seem to figure out how to do it (only allows me to create service prinicpals for existing hosts) Any help or pointers would be greatly appreciated -M On Fri, Sep 12, 2014 at 4:12 AM, Dmitri Pal wrote: > On 09/11/2014 09:25 PM, Michael Lasevich wrote: > > If I remember correctly, you could not use SAN (Subject Alternate > Names) for certificates in FreeIPA 3.0 - is this still the case with 4? > > > https://fedorahosted.org/freeipa/ticket/3977 < 4.0 is able. > > > I have hosts that automatically receive two hostnames, a long proper name > (like "service-i-12345678") and a simpler cname based on an index for ease > of access (like "service-1") - however since OS hostname is the "proper" > one, certs would typically be issued to that name. I want my users to be > able to hit it via the simplex "index" names. Is that currently possible > (esp given that the cnames are actualy in a different DNS domain)? > > Thanks, > > -M > > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tompos at martos.bme.hu Fri Sep 12 19:16:43 2014 From: tompos at martos.bme.hu (Tamas Papp) Date: Fri, 12 Sep 2014 21:16:43 +0200 Subject: [Freeipa-users] json api docs In-Reply-To: <5413271C.5010305@redhat.com> References: <5410DA78.2030802@martos.bme.hu> <5410E791.2090407@redhat.com> <5412EB4C.7010208@redhat.com> <5412F6DC.1010707@martos.bme.hu> <5413271C.5010305@redhat.com> Message-ID: <5413469B.5030403@martos.bme.hu> On 09/12/2014 07:02 PM, Dmitri Pal wrote: > > You have seen other answers but I think a fair question to ask here is > what does the service do and what kind of ldap info it needs? > Is it read only or read write? Currently we have a forum, where users can register to a mysql database. W would like to migrate or use it together with ldap, so the registered customers could authenticate from a central user database. It would be like if I register to fedoraproject.org and with that I would get access to redhat bugzilla at the same time. The difference is that I need ldap backend for the targeted services. Cheers, tamas From dpal at redhat.com Fri Sep 12 19:19:47 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 12 Sep 2014 15:19:47 -0400 Subject: [Freeipa-users] Use of SAN's with automatic certificates in FreeIPA 4 In-Reply-To: References: <5412D532.6080503@redhat.com> Message-ID: <54134753.6040707@redhat.com> On 09/12/2014 02:43 PM, Michael Lasevich wrote: > That is awesome, but I am clearly missing some insight as to how this > is supposed to work. Can you point me to some more specific info on > how to accomplish this. > > I tried using the ipa-getcert request with multiple -D's from the > client, but got : > > ** Insufficient access: You need to be a member of the serviceadmin > role to add services > > Unless I am missing something, I should probably not add each host to > "serviceadmins" for security reasons. 4.0 has a new permissions system this might yet to be another use case that we might have overlooked. I will leave to developers to review this situation on Monday morning. > > So I then I tried generating a csr via openssl with SANs on the client > and then adding it using "ipa cert-request file.csr --prinicple > host/${client_hostname}@DOMAIN" from ipa server as admin (just to be > sure) and got this error (where is the first SAN): > > ** ipa: ERROR: The service principal for subject alt name in > certificate request does not exist > > It sounds like I need to create service principal for each SAN, but I > can't seem to figure out how to do it (only allows me to create > service prinicpals for existing hosts) > > Any help or pointers would be greatly appreciated > > -M > > On Fri, Sep 12, 2014 at 4:12 AM, Dmitri Pal > wrote: > > On 09/11/2014 09:25 PM, Michael Lasevich wrote: >> If I remember correctly, you could not use SAN (Subject Alternate >> Names) for certificates in FreeIPA 3.0 - is this still the case >> with 4? > > https://fedorahosted.org/freeipa/ticket/3977 < 4.0 is able. > >> >> I have hosts that automatically receive two hostnames, a long >> proper name (like "service-i-12345678") and a simpler cname based >> on an index for ease of access (like "service-1") - however since >> OS hostname is the "proper" one, certs would typically be issued >> to that name. I want my users to be able to hit it via the >> simplex "index" names. Is that currently possible (esp given that >> the cnames are actualy in a different DNS domain)? >> >> Thanks, >> >> -M >> >> > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Fri Sep 12 19:23:52 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 12 Sep 2014 22:23:52 +0300 Subject: [Freeipa-users] json api docs In-Reply-To: <5413469B.5030403@martos.bme.hu> References: <5410DA78.2030802@martos.bme.hu> <5410E791.2090407@redhat.com> <5412EB4C.7010208@redhat.com> <5412F6DC.1010707@martos.bme.hu> <5413271C.5010305@redhat.com> <5413469B.5030403@martos.bme.hu> Message-ID: <20140912192352.GN2541@redhat.com> On Fri, 12 Sep 2014, Tamas Papp wrote: > >On 09/12/2014 07:02 PM, Dmitri Pal wrote: >> >>You have seen other answers but I think a fair question to ask here >>is what does the service do and what kind of ldap info it needs? >>Is it read only or read write? > >Currently we have a forum, where users can register to a mysql >database. W would like to migrate or use it together with ldap, so the >registered customers could authenticate from a central user database. > >It would be like if I register to fedoraproject.org and with that I >would get access to redhat bugzilla at the same time. >The difference is that I need ldap backend for the targeted services. I'd recommend you to read http://www.freeipa.org/page/Web_App_Authentication This is our approach for secure and scalable authentication of web applications and management of additional user data. -- / Alexander Bokovoy From pviktori at redhat.com Fri Sep 12 20:26:53 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 12 Sep 2014 22:26:53 +0200 Subject: [Freeipa-users] Announcing FreeIPA 4.0.3 Message-ID: <5413570D.3040708@redhat.com> The FreeIPA team would like to announce FreeIPA v4.0.3 bugfix release! It can be downloaded from http://www.freeipa.org/page/Downloads. The builds will be available for Fedora 21 Beta. Builds for Fedora 20 are available in the official [https://copr.fedoraproject.org/coprs/mkosek/freeipa/ COPR repository]. == Bug fixes in 4.0.3 == * Several issues concerning integration with 389 Directory Server 1.3.3 were fixed. * An upgrade crash was fixed. == Known Issues == * On Fedora 21 Alpha, FreeIPA server configuration should be done after upgrading packages from updates-testing. == Upgrading == An IPA server can be upgraded simply by installing updated rpms. The server does not need to be shut down in advance. Please note that if you are doing the upgrade in special environment (e.g. FedUp) which does not allow running the LDAP server during upgrade process, upgrade scripts need to be run manually after the first boot: # ipa-ldap-updater --upgrade # ipa-upgradeconfig Also note that the performance improvements require an extended set of indexes to be configured. RPM update for an IPA server with a excessive number of users may require several minutes to finish. If you have multiple servers you may upgrade them one at a time. It is expected that all servers will be upgraded in a relatively short period (days or weeks, not months). They should be able to co-exist peacefully but new features will not be available on old servers and enrolling a new client against an old server will result in the SSH keys not being uploaded. Downgrading a server once upgraded is not supported. Upgrading from 3.3.0 and later versions is supported. Upgrading from previous versions is not supported and has not been tested. An enrolled client does not need the new packages installed unless you want to re-enroll it. SSH keys for already installed clients are not uploaded, you will have to re-enroll the client or manually upload the keys. == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list (http://www.redhat.com/mailman/listinfo/freeipa-users) or #freeipa channel on Freenode. == Detailed Changelog since 4.0.2 == === David Kupka (1) === * Fix typo causing ipa-upgradeconfig to fail. === Ludwig Krispenz (1) === * Update SSL ciphers configured in 389-ds-base === Nathaniel McCallum (1) === * Update qrcode support for newer python-qrcode === Petr Viktorin (4) === * Update referential integrity config for DS 1.3.3 * permission plugin: Auto-add operational atttributes to read permissions * Allow deleting obsolete permissions; remove operational attribute permissions * Become IPA 4.0.3 From traiano at gmail.com Fri Sep 12 20:36:19 2014 From: traiano at gmail.com (Traiano Welcome) Date: Fri, 12 Sep 2014 23:36:19 +0300 Subject: [Freeipa-users] FreeIPA ActiveDirectory Integration, Fedora and Windows 2008 R2 AD: "ipa: ERROR: an internal error has occurred" Message-ID: Hi List I'm following the guide at http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Assumptions , this time with Fedora 20.1. Everything proceeds smoothly until I try to establish trust with the AD domain controller, at which point IPA crashes: --- [root at idm001 ~]# ipa trust-add --type=ad mhatest.local --admin Administrator --password Active directory domain administrator's password: ipa: ERROR: an internal error has occurred [root at idm001 ~]# --- I've attached the exact, step by step process I used to arrive at this point. Attached also are the debug logs (as per the debugging guidelines). Many thanks in advance for any insight I could use to understand and fix this issue! I am also moving on to re/testing the same process on CentOS 7, CentOS 6.5 to rule out the possibility of subtle variations in package version bugs (or basically net any that might exist :-p) Regards, Traiano -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- 1. AD DC Details - Provides DNS via Windows DNS Server for MHATEST.LOCAL, ENGENEON.LOCAL, LINUX.MHATEST.LOCAL - Win2K8 R2 Enterprise (VM running on Hyper-V) - DNS hostname: kwttstaddc001.mhatest.local - IP Address: 172.16.107.109 2. IdM Server Details - Fedora 20.??? (Fedora-Live-Desktop-x86_64-20-1) - DNS hostname: idm001.engeneon.local - IP Address: 172.16.107.108 3. Linux Client machine: - 172.16.104.145 ronin.engeneon.local ronin - CentOS6.5 Summary: - IPA server IP address: 172.16.107.108 - IPA server hostname: idm001.engeneon.local - IPA domain: ipa_domain engeneon.local - IPA NetBIOS: ENGENEON - IPA Kerberos realm, IPA_DOMAIN, is equal to IPA domain: ENGENEON.LOCAL - AD DC IP address: ad_ip_address: 172.16.107.109 - AD DC hostname: ad_hostname: kwttstaddc001.mhatest.local - AD domain: ad_domain: MHATEST.LOCAL - AD NetBIOS: ad_netbios: MHATEST - AD admins group SID: 4. Windows 2008 R2 AD DC Configuration Settings (172.16.107.109) Printout summary from the "DCPROMO" configuration wizard: - Configure this server as the first Active Directory domain controller in a new forest. - The new domain name is "MHATEST.LOCAL". This is also the name of the new forest. - The NetBIOS name of the domain is "MHATEST". - Forest Functional Level: Windows Server 2008 R2 - Domain Functional Level: Windows Server 2008 R2 - Site: Default-First-Site-Name - Additional Options: Read-only domain controller: "No" Global catalog: Yes DNS Server: Yes - Create DNS Delegation: No - Database folder: C:\Windows\NTDS - Log file folder: C:\Windows\NTDS - SYSVOL folder: C:\Windows\SYSVOL - The DNS Server service will be installed on this computer. - The DNS Server service will be configured on this computer. - This computer will be configured to use this DNS server as its preferred DNS server. - The password of the new domain Administrator will be the same as the password of the local Administrator of this computer. A second AD integrated zone was created on the AD server for the IPA domain: Name: ENGENEON.LOCAL Type: Active Directory-Integrated Primary Lookup type: Forward 5. IDM Server Configuration Sequence: - Guide #1 (IPA Setup) http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Assumptions - Guide #2 (AD setup) http://stef.thewalter.net/2012/08/how-to-create-active-directory-domain.html - Guide #3 (NOT USED IN THIS SEQUENCE!!): Mark Heslin's guide: "Integrating OSE for IdMfor RHEL 1.0" 5.1 Installing the IPA server (Fedora 20.x, on VMware ESXI 5.5): [done] yum update -y Setup the local caching name-server: [DONE] yum install caching-nameserver [DONE] configure forwarders in /etc/named.conf: forwarders { 172.16.107.109; /* ... or the address of your ISP DNS server */ }; Zone configuration on the IPA server: --- zone "mhatest.local" { type stub; masters { 172.16.107.109; }; }; zone "engeneon.local" { type stub; masters { 172.16.107.109; }; }; --- - Testing that the IPA server can use the local caching dns servicet to resolve the test AD domain: --- [root at idm001 ~]# dig +short soa mhatest.local @127.0.0.1 kwttstaddc002.mhatest.local. hostmaster.mhatest.local. 23 900 600 86400 3600 --- [DONE] yum install -y "*ipa-server" "*ipa-server-trust-ad" samba4-winbind-clients samba4-winbind samba4-client bind bind-dyndb-ldap --- Package freeipa-server-3.3.5-1.fc20.x86_64 already installed and latest version Package freeipa-server-trust-ad-3.3.5-1.fc20.x86_64 already installed and latest version Package 2:samba-winbind-clients-4.1.9-4.fc20.x86_64 already installed and latest version Package 2:samba-winbind-4.1.9-4.fc20.x86_64 already installed and latest version Package 2:samba-client-4.1.9-4.fc20.x86_64 already installed and latest version Package 32:bind-9.9.4-15.P2.fc20.x86_64 already installed and latest version Package bind-dyndb-ldap-4.3-1.fc20.x86_64 already installed and latest version --- [DONE] Configure hostname and /etc/hosts: --- [root at idm001 ~]# cat /etc/hosts 127.0.0.1 localhost.localdomain localhost ::1 localhost6.localdomain6 localhost6 172.16.107.108 idm001.engeneon.local idm001 [root at idm001 ~]# hostname idm001.engeneon.local --- [DONE] Install the IPA server: ipa-server-install -a Cr4ckM0nk3y -p Cr4ckM0nk3y --domain=engeneon.local --realm=ENGENEON.LOCAL --setup-dns --no-forwarders -U --- . . . [9/11]: restarting named [10/11]: configuring named to start on boot [11/11]: changing resolv.conf to point to ourselves Done configuring DNS (named). Global DNS configuration in LDAP server is empty You can use 'dnsconfig-mod' command to set global DNS options that would override settings in local named.conf files Restarting the web server ============================================================================== Setup complete Next steps: 1. You must make sure these network ports are open: TCP Ports: * 80, 443: HTTP/HTTPS * 389, 636: LDAP/LDAPS * 88, 464: kerberos * 53: bind UDP Ports: * 88, 464: kerberos * 53: bind * 123: ntp 2. You can now obtain a kerberos ticket using the command: 'kinit admin' This ticket will allow you to use the IPA tools (e.g., ipa user-add) and the web user interface. Be sure to back up the CA certificate stored in /root/cacert.p12 This file is required to create replicas. The password for this file is the Directory Manager password --- [DONE] Verify IPA users available to IPA Services: --- [root at idm001 ~]# id admin uid=392600000(admin) gid=392600000(admins) groups=392600000(admins) [root at idm001 ~]# getent passwd admin admin:*:392600000:392600000:Administrator:/home/admin:/bin/bash [root at idm001 ~]# --- [] Configure IPA for Cross-Realm Trusts: ipa-adtrust-install --netbios-name=ENGENEON -a Cr4ckM0nk3y Output: --- [root at idm001 ~]# ipa-adtrust-install --netbios-name=ENGENEON -a Cr4ckM0nk3y The log file for this installation can be found in /var/log/ipaserver-install.log ============================================================================== This program will setup components needed to establish trust to AD domains for the FreeIPA Server. This includes: * Configure Samba * Add trust related objects to FreeIPA LDAP server To accept the default shown in brackets, press the Enter key. WARNING: The smb.conf already exists. Running ipa-adtrust-install will break your existing samba configuration. Do you wish to continue? [no]: yes WARNING: 3 existing users or groups do not have a SID identifier assigned. Installer can run a task to have ipa-sidgen Directory Server plugin generate the SID identifier for all these users. Please note, the in case of a high number of users and groups, the operation might lead to high replication traffic and performance degradation. Refer to ipa-adtrust-install(1) man page for details. Do you want to run the ipa-sidgen task? [no]: yes The following operations may take some minutes to complete. Please wait until the prompt is returned. Done configuring CIFS. ============================================================================= Setup complete You must make sure these network ports are open: TCP Ports: * 138: netbios-dgm * 139: netbios-ssn * 445: microsoft-ds UDP Ports: * 138: netbios-dgm * 139: netbios-ssn * 389: (C)LDAP * 445: microsoft-ds Additionally you have to make sure the FreeIPA LDAP server is not reachable by any domain controller in the Active Directory domain by closing down the following ports for these servers: TCP Ports: * 389, 636: LDAP/LDAPS You may want to choose to REJECT the network packets instead of DROPing them to avoid timeouts on the AD domain controllers. ============================================================================= [DONE] Open the firewall Wide: --- [root at idm001 ~]# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination [root at idm001 ~]# --- [DONE] Check TimeZone Settings on both the AD server and the IPA server: idm001.engeneon.net: --- [root at idm001 ~]# date Fri Sep 12 21:10:56 AST 2014 --- kwttstaddc002.mhatest.local: --- PS C:\Users\Administrator> date Friday, September 12, 2014 9:10:33 PM --- 5. DNS Configuration: (The scenario here is "domains are parallel") - AD DNS Zone : mhatest.local - IPA DNS Zone : engeneon.local 5.1 Configure conditional forwarder for IPA domain (engeneon.local): dnscmd 127.0.0.1 /ZoneAdd engeneon.local /Forwarder 172.16.107.108 Output: --- PS C:\Users\Administrator> dnscmd 127.0.0.1 /ZoneAdd engeneon.local /Forwarder 172.16.107.108 DNS Server 127.0.0.1 created zone engeneon.local: Command completed successfully. --- 5.2 On IPA server, add conditional forwarder for AD domain: ipa dnszone-add mhatest.local --name-server=KWTTSTADDC002.mhatest.local --admin-email='hostmaster at mhatest.local' --force --forwarder=172.16.107.109 --forward-policy=only --ip-address=172.16.107.109 Output: --- [root at idm001 ~]# ipa dnszone-add mhatest.local --name-server=KWTTSTADDC002.mhatest.local --admin-email='hostmaster at mhatest.local' --force --forwarder=172.16.107.109 --forward-policy=only --ip-address=172.16.107.109 Zone name: mhatest.local Authoritative nameserver: kwttstaddc002.mhatest.local Administrator e-mail address: hostmaster.mhatest.local. SOA serial: 1410546132 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 BIND update policy: grant ENGENEON.LOCAL krb5-self * A; grant ENGENEON.LOCAL krb5-self * AAAA; grant ENGENEON.LOCAL krb5-self * SSHFP; Active zone: TRUE Dynamic update: FALSE Allow query: any; Allow transfer: none; Zone forwarders: 172.16.107.109 Forward policy: only [root at idm001 ~]# --- - Dig tests: --- [root at idm001 ~]# dig +short SRV _ldap._tcp.engeneon.local 0 100 389 idm001.engeneon.local. --- --- [root at idm001 ~]# dig +short SRV _ldap._tcp.mhatest.local 0 100 389 kwttstaddc002.mhatest.local. --- 6.Establish and verify cross-realm trust: (A tcpdump capture of this part was also done with: tcpdump -nXvvvs 0 -i ens192 host 172.16.107.108 and host 172.16.107.109 -w ipa-ad-cross-realm-trust-argument.pcap) ipa trust-add --type=ad mhatest.local --admin Administrator --password Output: --- [root at idm001 ~]# [root at idm001 ~]# ipa trust-add --type=ad mhatest.local --admin Administrator --password Active directory domain administrator's password: ipa: ERROR: an internal error has occurred [root at idm001 ~]# --- The tcpdump for the entire exchange above looks like this: --- [root at idm001 ~]# tcpdump -i ens192 host 172.16.107.108 and host 172.16.107.109 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ens192, link-type EN10MB (Ethernet), capture size 65535 bytes 21:41:21.292056 IP idm001.engeneon.local.51159 > 172.16.107.109.ldap: UDP, length 83 21:41:21.292649 IP 172.16.107.109.ldap > idm001.engeneon.local.51159: UDP, length 190 21:41:26.236218 ARP, Request who-has idm001.engeneon.local (00:50:56:9c:67:a0 (oui Unknown)) tell 172.16.107.109, length 46 21:41:26.236246 ARP, Reply idm001.engeneon.local is-at 00:50:56:9c:67:a0 (oui Unknown), length 28 --- -------------- next part -------------- A non-text attachment was scrubbed... Name: debug_logs_idm001_120920142330.tar.gz Type: application/x-gzip Size: 10119 bytes Desc: not available URL: From abokovoy at redhat.com Fri Sep 12 21:07:16 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sat, 13 Sep 2014 00:07:16 +0300 Subject: [Freeipa-users] FreeIPA ActiveDirectory Integration, Fedora and Windows 2008 R2 AD: "ipa: ERROR: an internal error has occurred" In-Reply-To: References: Message-ID: <20140912210716.GO2541@redhat.com> On Fri, 12 Sep 2014, Traiano Welcome wrote: >Hi List > > >I'm following the guide at >http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Assumptions , this >time with Fedora 20.1. > > >Everything proceeds smoothly until I try to establish trust with the AD >domain controller, at which point IPA crashes: > >--- >[root at idm001 ~]# ipa trust-add --type=ad mhatest.local --admin >Administrator --password >Active directory domain administrator's password: >ipa: ERROR: an internal error has occurred >[root at idm001 ~]# >--- > >I've attached the exact, step by step process I used to arrive at this >point. Attached also are the debug logs (as per the debugging guidelines). Looks like you have connectivity problems (or firewall?): finddcs: Found matching DC 172.16.107.109 with server_type=0x000031fd [Fri Sep 12 23:30:00.471404 2014] [:error] [pid 3876] ipa: ERROR: LDAP error when connecting to KWTTSTADDC002: {'desc': "Can't contact LDAP server"} Anyway, please file a bug for Fedora and attach the logs there, we'll try to improve error messaging here. > > >Many thanks in advance for any insight I could use to understand and fix >this issue! I am also moving on to re/testing the same process on >CentOS 7, CentOS 6.5 to rule out the possibility of subtle variations in >package version bugs (or basically net any that might exist :-p) Yep. -- / Alexander Bokovoy From traiano at gmail.com Sat Sep 13 15:42:35 2014 From: traiano at gmail.com (Traiano Welcome) Date: Sat, 13 Sep 2014 18:42:35 +0300 Subject: [Freeipa-users] FreeIPA ActiveDirectory Integration, Fedora and Windows 2008 R2 AD: "ipa: ERROR: an internal error has occurred" In-Reply-To: <20140912210716.GO2541@redhat.com> References: <20140912210716.GO2541@redhat.com> Message-ID: Hi I've managed to get trusts working with CentOS 7 as an IdM server, Win2K8R2 AD DC and CentOS6.5 as a client, using the exact same series of steps as in the documentation. Attached is the process I used. I'll continue testing RHEL7 and Fedora 20.1 and submit a bug report if necessary. Thanks for the assistance all!! Traiano On Sat, Sep 13, 2014 at 12:07 AM, Alexander Bokovoy wrote: > On Fri, 12 Sep 2014, Traiano Welcome wrote: > >> Hi List >> >> >> I'm following the guide at >> http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Assumptions , this >> time with Fedora 20.1. >> >> >> Everything proceeds smoothly until I try to establish trust with the AD >> domain controller, at which point IPA crashes: >> >> --- >> [root at idm001 ~]# ipa trust-add --type=ad mhatest.local --admin >> Administrator --password >> Active directory domain administrator's password: >> ipa: ERROR: an internal error has occurred >> [root at idm001 ~]# >> --- >> >> I've attached the exact, step by step process I used to arrive at this >> point. Attached also are the debug logs (as per the debugging guidelines). >> > Looks like you have connectivity problems (or firewall?): > finddcs: Found matching DC 172.16.107.109 with server_type=0x000031fd > [Fri Sep 12 23:30:00.471404 2014] [:error] [pid 3876] ipa: ERROR: LDAP > error when connecting to KWTTSTADDC002: {'desc': "Can't contact LDAP > server"} > > Anyway, please file a bug for Fedora and attach the logs there, we'll > try to improve error messaging here. > > >> >> Many thanks in advance for any insight I could use to understand and fix >> this issue! I am also moving on to re/testing the same process on >> CentOS 7, CentOS 6.5 to rule out the possibility of subtle variations in >> package version bugs (or basically net any that might exist :-p) >> > Yep. > > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- 1. AD DC Details - Provides DNS via Windows DNS Server for MHATEST.LOCAL, ENGENEON.LOCAL, LINUX.MHATEST.LOCAL - Win2K8 R2 Enterprise (VM running on Hyper-V) - DNS hostname: kwttstaddc001.mhatest.local - IP Address: 172.16.107.109 2. IdM Server Details - CentOS Linux release 7.0.1406 (Core) - DNS hostname: idm003.engeneon.local - IP Address: 172.16.107.106 3. Linux Client machine: - 172.16.104.145 ronin.engeneon.local ronin - CentOS6.5 Summary: - IPA server IP address: 172.16.107.106 - IPA server hostname: idm003.engeneon.local - IPA domain: ipa_domain engeneon.local - IPA NetBIOS: ENGENEON - IPA Kerberos realm, IPA_DOMAIN, is equal to IPA domain: ENGENEON.LOCAL - AD DC IP address: ad_ip_address: 172.16.107.109 - AD DC hostname: ad_hostname: kwttstaddc001.mhatest.local - AD domain: ad_domain: MHATEST.LOCAL - AD NetBIOS: ad_netbios: MHATEST - AD admins group SID: 4. Windows 2008 R2 AD DC Configuration Settings (172.16.107.109) Printout summary from the "DCPROMO" configuration wizard: - Configure this server as the first Active Directory domain controller in a new forest. - The new domain name is "MHATEST.LOCAL". This is also the name of the new forest. - The NetBIOS name of the domain is "MHATEST". - Forest Functional Level: Windows Server 2008 R2 - Domain Functional Level: Windows Server 2008 R2 - Site: Default-First-Site-Name - Additional Options: Read-only domain controller: "No" Global catalog: Yes DNS Server: Yes - Create DNS Delegation: No - Database folder: C:\Windows\NTDS - Log file folder: C:\Windows\NTDS - SYSVOL folder: C:\Windows\SYSVOL - The DNS Server service will be installed on this computer. - The DNS Server service will be configured on this computer. - This computer will be configured to use this DNS server as its preferred DNS server. - The password of the new domain Administrator will be the same as the password of the local Administrator of this computer. A second AD integrated zone was created on the AD server for the IPA domain: Name: ENGENEON.LOCAL Type: Active Directory-Integrated Primary Lookup type: Forward 5. IDM Server Configuration Sequence: - Guide #1 (IPA Setup) http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Assumptions - Guide #2 (AD setup) http://stef.thewalter.net/2012/08/how-to-create-active-directory-domain.html - Guide #3 (NOT USED IN THIS SEQUENCE!!): Mark Heslin's guide: "Integrating OSE for IdMfor RHEL 1.0" 5.1 Installing the IPA server (CentOS 7, on VMware ESXI 5.5): [done] yum update -y Setup the local caching name-server: [DONE] yum install caching-nameserver [DONE] configure forwarders in /etc/named.conf: forwarders { 172.16.107.109; /* ... or the address of your ISP DNS server */ }; Zone configuration on the IPA server: --- zone "mhatest.local" { type stub; masters { 172.16.107.109; }; }; zone "engeneon.local" { type stub; masters { 172.16.107.109; }; }; --- - Testing that the IPA server can use the local caching dns servicet to resolve the test AD domain: --- [root at idm001 ~]# dig +short soa mhatest.local @127.0.0.1 Times out!!! SERVFAIL --- [DONE] yum install -y "*ipa-server" "*ipa-server-trust-ad" samba4-winbind-clients samba4-winbind samba4-client bind bind-dyndb-ldap [DONE] Configure hostname and /etc/hosts: --- [root at idm001 ~]# cat /etc/hosts 127.0.0.1 localhost.localdomain localhost ::1 localhost6.localdomain6 localhost6 172.16.107.108 idm001.engeneon.local idm001 [root at idm001 ~]# hostname idm001.engeneon.local --- [DONE] Install the IPA server: ipa-server-install -a XXXXXXXXX -p XXXXXXXXX --domain=engeneon.local --realm=ENGENEON.LOCAL --setup-dns --no-forwarders -U --- . . . [9/11]: restarting named [10/11]: configuring named to start on boot [11/11]: changing resolv.conf to point to ourselves Done configuring DNS (named). Global DNS configuration in LDAP server is empty You can use 'dnsconfig-mod' command to set global DNS options that would override settings in local named.conf files Restarting the web server ============================================================================== Setup complete Next steps: 1. You must make sure these network ports are open: TCP Ports: * 80, 443: HTTP/HTTPS * 389, 636: LDAP/LDAPS * 88, 464: kerberos * 53: bind UDP Ports: * 88, 464: kerberos * 53: bind * 123: ntp 2. You can now obtain a kerberos ticket using the command: 'kinit admin' This ticket will allow you to use the IPA tools (e.g., ipa user-add) and the web user interface. Be sure to back up the CA certificate stored in /root/cacert.p12 This file is required to create replicas. The password for this file is the Directory Manager password --- [DONE] Verify IPA users available to IPA Services: --- [root at idm001 ~]# id admin uid=392600000(admin) gid=392600000(admins) groups=392600000(admins) [root at idm001 ~]# getent passwd admin admin:*:392600000:392600000:Administrator:/home/admin:/bin/bash [root at idm001 ~]# --- [] Configure IPA for Cross-Realm Trusts: ipa-adtrust-install --netbios-name=ENGENEON -a XXXXXXXXX Output: --- [root at idm001 ~]# ipa-adtrust-install --netbios-name=ENGENEON -a XXXXXXXXX The log file for this installation can be found in /var/log/ipaserver-install.log ============================================================================== This program will setup components needed to establish trust to AD domains for the FreeIPA Server. This includes: * Configure Samba * Add trust related objects to FreeIPA LDAP server To accept the default shown in brackets, press the Enter key. WARNING: The smb.conf already exists. Running ipa-adtrust-install will break your existing samba configuration. Do you wish to continue? [no]: yes WARNING: 3 existing users or groups do not have a SID identifier assigned. Installer can run a task to have ipa-sidgen Directory Server plugin generate the SID identifier for all these users. Please note, the in case of a high number of users and groups, the operation might lead to high replication traffic and performance degradation. Refer to ipa-adtrust-install(1) man page for details. Do you want to run the ipa-sidgen task? [no]: yes The following operations may take some minutes to complete. Please wait until the prompt is returned. Done configuring CIFS. ============================================================================= Setup complete You must make sure these network ports are open: TCP Ports: * 138: netbios-dgm * 139: netbios-ssn * 445: microsoft-ds UDP Ports: * 138: netbios-dgm * 139: netbios-ssn * 389: (C)LDAP * 445: microsoft-ds Additionally you have to make sure the FreeIPA LDAP server is not reachable by any domain controller in the Active Directory domain by closing down the following ports for these servers: TCP Ports: * 389, 636: LDAP/LDAPS You may want to choose to REJECT the network packets instead of DROPing them to avoid timeouts on the AD domain controllers. ============================================================================= [DONE] Open the firewall Wide: --- [root at idm001 ~]# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination [root at idm001 ~]# --- [DONE] Check TimeZone Settings on both the AD server and the IPA server: idm001.engeneon.net: --- [root at idm001 ~]# date Fri Sep 12 21:10:56 AST 2014 --- kwttstaddc002.mhatest.local: --- PS C:\Users\Administrator> date Friday, September 12, 2014 9:10:33 PM --- 5. DNS Configuration: (The scenario here is "domains are parallel") - AD DNS Zone : mhatest.local - IPA DNS Zone : engeneon.local 5.1 Configure conditional forwarder for IPA domain (engeneon.local): dnscmd 127.0.0.1 /ZoneAdd engeneon.local /Forwarder 172.16.107.108 Output: --- PS C:\Users\Administrator> dnscmd 127.0.0.1 /ZoneAdd engeneon.local /Forwarder 172.16.107.108 DNS Server 127.0.0.1 created zone engeneon.local: Command completed successfully. --- 5.2 On IPA server, add conditional forwarder for AD domain: ipa dnszone-add mhatest.local --name-server=kwttstaddc002.mhatest.local --admin-email='hostmaster at mhatest.local' --force --forwarder=172.16.107.109 --forward-policy=only --ip-address=172.16.107.109 Output: --- [root at idm001 ~]# ipa dnszone-add mhatest.local --name-server=KWTTSTADDC002.mhatest.local --admin-email='hostmaster at mhatest.local' --force --forwarder=172.16.107.109 --forward-policy=only --ip-address=172.16.107.109 Zone name: mhatest.local Authoritative nameserver: kwttstaddc002.mhatest.local Administrator e-mail address: hostmaster.mhatest.local. SOA serial: 1410546132 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 BIND update policy: grant ENGENEON.LOCAL krb5-self * A; grant ENGENEON.LOCAL krb5-self * AAAA; grant ENGENEON.LOCAL krb5-self * SSHFP; Active zone: TRUE Dynamic update: FALSE Allow query: any; Allow transfer: none; Zone forwarders: 172.16.107.109 Forward policy: only [root at idm001 ~]# --- - Dig tests: --- [root at idm001 ~]# dig +short SRV _ldap._tcp.engeneon.local 0 100 389 idm001.engeneon.local. --- --- [root at idm001 ~]# dig +short SRV _ldap._tcp.mhatest.local 0 100 389 kwttstaddc002.mhatest.local. --- 6.Establish and verify cross-realm trust: ipa trust-add --type=ad mhatest.local --admin Administrator --password Output: --- [root at idm003 ~]# ipa trust-add --type=ad mhatest.local --admin Administrator --password Active directory domain administrator's password: ------------------------------------------------------ Added Active Directory trust for realm "MHATEST.LOCAL" ------------------------------------------------------ Realm name: MHATEST.LOCAL Domain NetBIOS name: MHATEST Domain Security Identifier: S-1-5-21-3779563847-208264455-1888173826 SID blacklist incoming: S-1-0, S-1-1, S-1-2, S-1-3, S-1-5-1, S-1-5-2, S-1-5-3, S-1-5-4, S-1-5-5, S-1-5-6, S-1-5-7, S-1-5-8, S-1-5-9, S-1-5-10, S-1-5-11, S-1-5-12, S-1-5-13, S-1-5-14, S-1-5-15, S-1-5-16, S-1-5-17, S-1-5-18, S-1-5-19, S-1-5-20 SID blacklist outgoing: S-1-0, S-1-1, S-1-2, S-1-3, S-1-5-1, S-1-5-2, S-1-5-3, S-1-5-4, S-1-5-5, S-1-5-6, S-1-5-7, S-1-5-8, S-1-5-9, S-1-5-10, S-1-5-11, S-1-5-12, S-1-5-13, S-1-5-14, S-1-5-15, S-1-5-16, S-1-5-17, S-1-5-18, S-1-5-19, S-1-5-20 Trust direction: Two-way trust Trust type: Active Directory domain Trust status: Established and verified [root at idm003 ~]# --- 7. Test if we can pull a list of trusted domains: ipa trustdomain-find "mhatest.local" --- [root at idm003 ~]# ipa trustdomain-find "mhatest.local" Domain name: MHATEST.LOCAL Domain NetBIOS name: MHATEST Domain Security Identifier: S-1-5-21-3779563847-208264455-1888173826 Domain enabled: True ---------------------------- Number of entries returned 1 ---------------------------- [root at idm003 ~]# --- 8. Modify /etc/krb5.conf [realms] ENGENEON.LOCAL = { kdc = idm003.engeneon.local:88 master_kdc = idm003.engeneon.local:88 admin_server = idm003.engeneon.local:749 default_domain = engeneon.local pkinit_anchors = FILE:/etc/ipa/ca.crt auth_to_local = RULE:[1:$1@$0](^.*@AD_DOMAIN$)s/@AD_DOMAIN/@ad_domain/ auth_to_local = DEFAULT } --- [root at idm003 ~]# service krb5kdc restart Redirecting to /bin/systemctl restart krb5kdc.service [root at idm003 ~]# service sssd restart Redirecting to /bin/systemctl restart sssd.service [root at idm003 ~]# --- 9. Allow access for users from AD domain to protected resources: ipa group-add --desc='mhatest.local admins external map' ad_admins_external --external ipa group-add --desc='mhatest.local admins' ad_admins ipa group-add-member ad_admins_external --external 'MHATEST\Domain Admins' Output: --- [root at idm003 ~]# ipa group-add --desc='mhatest.local admins external map' ad_admins_external --external -------------------------------- Added group "ad_admins_external" -------------------------------- Group name: ad_admins_external Description: mhatest.local admins external map [root at idm003 ~]# [root at idm003 ~]# [root at idm003 ~]# [root at idm003 ~]# ipa group-add --desc='mhatest.local admins' ad_admins ----------------------- Added group "ad_admins" ----------------------- Group name: ad_admins Description: mhatest.local admins GID: 563000004 [root at idm003 ~]# [root at idm003 ~]# ipa group-add-member ad_admins_external --external 'MHATEST\Domain Admins' [member user]: [member group]: Group name: ad_admins_external Description: mhatest.local admins external map External member: S-1-5-21-3779563847-208264455-1888173826-512 ------------------------- Number of members added 1 ------------------------- [root at idm003 ~]# --- [root at idm003 ~]# ipa group-add-member ad_admins --groups ad_admins_external Group name: ad_admins Description: mhatest.local admins GID: 563000004 Member groups: ad_admins_external ------------------------- Number of members added 1 ------------------------- [root at idm003 ~]# --- 9. Testing Cross Realm Trust: - Create a user in AD: - SSH in to the IPA server using user at mhatest.local REsult: Works fine :-) --- -sh-4.2$ -sh-4.2$ klist Ticket cache: KEYRING:persistent:734001104:krb_ccache_EIBqyEC Default principal: welcomet at MHATEST.LOCAL Valid starting Expires Service principal 09/13/2014 01:02:19 09/13/2014 11:02:19 krbtgt/MHATEST.LOCAL at MHATEST.LOCAL renew until 09/14/2014 01:02:19 -sh-4.2$ -sh-4.2$ -sh-4.2$ id uid=734001104(welcomet at mhatest.local) gid=734001104(welcomet at mhatest.local) groups=734001104(welcomet at mhatest.local),734000513(domain users at mhatest.local) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 -sh-4.2$ -sh-4.2$ --- 10. Enroll another linux host as a client to the IPA server: - CentOS 6.5 ipa-client-install --enable-dns-updates --ssh-trust-dns --mkhomedir ---- [root at ronin ~]# ipa-client-install --enable-dns-updates --ssh-trust-dns --mkhomedir Discovery was successful! Hostname: ronin.engeneon.local Realm: ENGENEON.LOCAL DNS Domain: engeneon.local IPA Server: idm003.engeneon.local BaseDN: dc=engeneon,dc=local Continue to configure the system with these values? [no]: yes User authorized to enroll computers: admin Synchronizing time with KDC... Password for admin at ENGENEON.LOCAL: Successfully retrieved CA cert Subject: CN=Certificate Authority,O=ENGENEON.LOCAL Issuer: CN=Certificate Authority,O=ENGENEON.LOCAL Valid From: Fri Sep 12 21:35:22 2014 UTC Valid Until: Tue Sep 12 21:35:22 2034 UTC Enrolled in IPA realm ENGENEON.LOCAL Created /etc/ipa/default.conf New SSSD config will be created Configured /etc/sssd/sssd.conf Configured /etc/krb5.conf for IPA realm ENGENEON.LOCAL trying https://idm003.engeneon.local/ipa/xml Forwarding 'env' to server u'https://idm003.engeneon.local/ipa/xml' DNS server record set to: ronin.engeneon.local -> 172.16.104.145 Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub Forwarding 'host_mod' to server u'https://idm003.engeneon.local/ipa/xml' SSSD enabled Configured /etc/openldap/ldap.conf NTP enabled Configured /etc/ssh/ssh_config Configured /etc/ssh/sshd_config Client configuration complete. [root at ronin ~]# ---- Check we can get KRB5 tickets: --- [root at ronin ~]# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: admin at ENGENEON.LOCAL Valid starting Expires Service principal 09/13/14 01:09:17 09/14/14 01:09:13 krbtgt/ENGENEON.LOCAL at ENGENEON.LOCAL [root at ronin ~]# --- Check the user id : --- -sh-4.1$ getent passwd welcomet at mhatest.local welcomet at mhatest.local:*:734001104:734001104:Traiano TG. Welcome:/home/MHATEST.LOCAL/welcomet: -sh-4.1$ --- Corresponsing traces from the krbkdc.log on the IPA server side: --- Sep 13 01:37:09 idm003.engeneon.local krb5kdc[19829](info): TGS_REQ (4 etypes {18 17 16 23}) 172.16.104.145: ISSUE: authtime 1410561429, etypes {rep=18 tkt=18 ses=18}, welcomet at MHATEST.LOCAL for host/ronin.engeneon.local at ENGENEON.LOCAL Sep 13 01:37:09 idm003.engeneon.local krb5kdc[19829](info): closing down fd 12 --- From abokovoy at redhat.com Sat Sep 13 16:03:54 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sat, 13 Sep 2014 19:03:54 +0300 Subject: [Freeipa-users] FreeIPA ActiveDirectory Integration, Fedora and Windows 2008 R2 AD: "ipa: ERROR: an internal error has occurred" In-Reply-To: References: <20140912210716.GO2541@redhat.com> Message-ID: <20140913160354.GQ2541@redhat.com> On Sat, 13 Sep 2014, Traiano Welcome wrote: >Hi > >I've managed to get trusts working with CentOS 7 as an IdM server, Win2K8R2 >AD DC and CentOS6.5 as a client, using the exact same series of steps as in >the documentation. Attached is the process I used. You got one step wrong: ============================================================================ 8. Modify /etc/krb5.conf [realms] ENGENEON.LOCAL = { kdc = idm003.engeneon.local:88 master_kdc = idm003.engeneon.local:88 admin_server = idm003.engeneon.local:749 default_domain = engeneon.local pkinit_anchors = FILE:/etc/ipa/ca.crt auth_to_local = RULE:[1:$1@$0](^.*@AD_DOMAIN$)s/@AD_DOMAIN/@ad_domain/ auth_to_local = DEFAULT } ============================================================================ Here you have to substitute AD_DOMAIN and ad_domain by your actual AD domain name. This change has to be done currently on every IPA machine where you are expecting AD users to log in. For each domain in the trusted AD forest, AD_DOMAIN should be its realm and ad_domain should be the same in low-case as SSSD normalizes user names to lower case. The rule tells Kerberos library how to transform a Kerberos principal (thus REALM has to be upper case as it is required in MIT Kerberos) to a POSIX user name (thus put domain name in lower case as SSSD will normalize the user name). OpenSSH and some other software actually checks that POSIX user name corresponds to the value Kerberos library will return to OpenSSH daemon after running through auth_to_local rules. I.e., in your case it would be auth_to_local = RULE:[1:$1@$0](^.*@MHATEST.LOCAL$)s/@MHATEST.LOCAL/@mhatest.local/ and if you have multiple subdomains, there should be multiple rules like this, each for the domain which users you want to be able to log in. We are improving this in MIT Kerberos 1.12 and SSSD 1.12.1 where all these rules will be replaced with a plugin that fetches list of domains from IPA servers and automatically manage it. However, it is currently not available in any released distribution. -- / Alexander Bokovoy From traiano at gmail.com Sat Sep 13 18:46:33 2014 From: traiano at gmail.com (Traiano Welcome) Date: Sat, 13 Sep 2014 21:46:33 +0300 Subject: [Freeipa-users] FreeIPA ActiveDirectory Integration, Fedora and Windows 2008 R2 AD: "ipa: ERROR: an internal error has occurred" In-Reply-To: <20140913160354.GQ2541@redhat.com> References: <20140912210716.GO2541@redhat.com> <20140913160354.GQ2541@redhat.com> Message-ID: On Sat, Sep 13, 2014 at 7:03 PM, Alexander Bokovoy wrote: > On Sat, 13 Sep 2014, Traiano Welcome wrote: > >> Hi >> >> I've managed to get trusts working with CentOS 7 as an IdM server, >> Win2K8R2 >> AD DC and CentOS6.5 as a client, using the exact same series of steps as >> in >> the documentation. Attached is the process I used. >> > You got one step wrong: > ============================================================ > ================ > 8. Modify /etc/krb5.conf > > [realms] > ENGENEON.LOCAL = { > kdc = idm003.engeneon.local:88 > master_kdc = idm003.engeneon.local:88 > admin_server = idm003.engeneon.local:749 > default_domain = engeneon.local > pkinit_anchors = FILE:/etc/ipa/ca.crt > auth_to_local = RULE:[1:$1@$0](^.*@AD_DOMAIN$)s/@AD_DOMAIN/@ad_domain/ > auth_to_local = DEFAULT > } > ============================================================ > ================ > > Here you have to substitute AD_DOMAIN and ad_domain by your actual > AD domain name. This change has to be done currently on every IPA > machine where you are expecting AD users to log in. > > Doh! ok, fixed. Although, I didn't notice any login failures testing with a bunch of users. Is it possible this behavior is already being adapted around in either one of PAM, OpenSSH or KRB5? > For each domain in the trusted AD forest, AD_DOMAIN should be its realm > and ad_domain should be the same in low-case as SSSD normalizes user > names to lower case. The rule tells Kerberos library how to transform a > Kerberos principal (thus REALM has to be upper case as it is required in > MIT Kerberos) to a POSIX user name (thus put domain name in lower case > as SSSD will normalize the user name). OpenSSH and some other software > actually checks that POSIX user name corresponds to the value Kerberos > library will return to OpenSSH daemon after running through > auth_to_local rules. > > I.e., in your case it would be > > auth_to_local = RULE:[1:$1@$0](^.*@MHATEST.LOCAL$)s/@MHATEST.LOCAL/@ > mhatest.local/ > > and if you have multiple subdomains, there should be multiple rules like > this, each for the domain which users you want to be able to log in. > We are improving this in MIT Kerberos 1.12 and SSSD 1.12.1 where all > these rules will be replaced with a plugin that fetches list of domains > from IPA servers and automatically manage it. However, it is currently > not available in any released distribution. > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Sat Sep 13 18:59:07 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sat, 13 Sep 2014 21:59:07 +0300 Subject: [Freeipa-users] FreeIPA ActiveDirectory Integration, Fedora and Windows 2008 R2 AD: "ipa: ERROR: an internal error has occurred" In-Reply-To: References: <20140912210716.GO2541@redhat.com> <20140913160354.GQ2541@redhat.com> Message-ID: <20140913185907.GR2541@redhat.com> On Sat, 13 Sep 2014, Traiano Welcome wrote: >On Sat, Sep 13, 2014 at 7:03 PM, Alexander Bokovoy >wrote: > >> On Sat, 13 Sep 2014, Traiano Welcome wrote: >> >>> Hi >>> >>> I've managed to get trusts working with CentOS 7 as an IdM server, >>> Win2K8R2 >>> AD DC and CentOS6.5 as a client, using the exact same series of steps as >>> in >>> the documentation. Attached is the process I used. >>> >> You got one step wrong: >> ============================================================ >> ================ >> 8. Modify /etc/krb5.conf >> >> [realms] >> ENGENEON.LOCAL = { >> kdc = idm003.engeneon.local:88 >> master_kdc = idm003.engeneon.local:88 >> admin_server = idm003.engeneon.local:749 >> default_domain = engeneon.local >> pkinit_anchors = FILE:/etc/ipa/ca.crt >> auth_to_local = RULE:[1:$1@$0](^.*@AD_DOMAIN$)s/@AD_DOMAIN/@ad_domain/ >> auth_to_local = DEFAULT >> } >> ============================================================ >> ================ >> >> Here you have to substitute AD_DOMAIN and ad_domain by your actual >> AD domain name. This change has to be done currently on every IPA >> machine where you are expecting AD users to log in. >> >> > > >Doh! ok, fixed. Although, I didn't notice any login failures testing with a >bunch of users. Is it possible this behavior is already being adapted >around in either one of PAM, OpenSSH or KRB5? This affects single sign-on logins, i.e. when you try to logon with Kerberos ticket. -- / Alexander Bokovoy From traiano at gmail.com Sat Sep 13 20:03:50 2014 From: traiano at gmail.com (Traiano Welcome) Date: Sat, 13 Sep 2014 23:03:50 +0300 Subject: [Freeipa-users] =?utf-8?q?FreeIPA_ActiveDire=E2=80=8Bctory_Integr?= =?utf-8?q?atio=E2=80=8Bn=3A_Managing_AD_Users_in_IPA?= Message-ID: Hi List Currently I have a stable trust relationship going between IPA and Windows AD. I create users and manage passwords in AD, but want to manage the rest in IPA, "the rest" being default shell, default home directory settings, RBAC, HBAC, Selinux etc .. What I'm expecting it to be able to log into the FreeIPA web interface, and see a synched list of users created in AD appear in the interface, after which I can modify the settings on a per user basis. If that level of granularity is not possible, I would then expect to be able to at least apply an IPA-imposed set of account defaults on and AD user group: - default shell - HBAC rules - Sudo rules - SELinux rules - RBAC Is this possible with FreeIPA? I can't find anything coherent in the documentation that describes an effective way of managing the POSIX attributes of AD users in FreeIPA. Thanks in advance! Traiano -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Sat Sep 13 21:10:00 2014 From: dpal at redhat.com (Dmitri Pal) Date: Sat, 13 Sep 2014 17:10:00 -0400 Subject: [Freeipa-users] =?utf-8?q?FreeIPA_ActiveDire=E2=80=8Bctory_Integr?= =?utf-8?q?atio=E2=80=8Bn=3A_Managing_AD_Users_in_IPA?= In-Reply-To: References: Message-ID: <5414B2A8.6050004@redhat.com> On 09/13/2014 04:03 PM, Traiano Welcome wrote: > Hi List > Currently I have a stable trust relationship going between IPA and > Windows AD. I create users and manage passwords in AD, but want to > manage the rest in IPA, "the rest" being default shell, default home > directory settings, RBAC, HBAC, Selinux etc .. > What I'm expecting it to be able to log into the FreeIPA web > interface, and see a synched list of users created in AD appear in the > interface, after which I can modify the settings on a per user basis. > If that level of granularity is not possible, I would then expect to > be able to at least apply an IPA-imposed set of account defaults > on and AD user group: > - default shell > - HBAC rules > - Sudo rules > - SELinux rules > - RBAC > Is this possible with FreeIPA? I can't find anything coherent in the > documentation that describes an effective way of managing the POSIX > attributes of AD users in FreeIPA. > Thanks in advance! > Traiano > > You are to some extent describing a feature that we call "views" that is currently in works. But there are two parts: a) Ability to overwrite POSIX attributes for AD users - this is views https://fedorahosted.org/freeipa/ticket/3318 https://fedorahosted.org/freeipa/ticket/4509 b) Ability to apply policies to AD users. It is already possible. This is done via group membership. So you create a group in IPA, make AD group an external member of that group and then use that IPA group to apply HBAC, SUDO and SELinux rules. As for RBAC what do you mean? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gregor.bregenzer at gmail.com Sat Sep 13 21:27:17 2014 From: gregor.bregenzer at gmail.com (Gregor Bregenzer) Date: Sat, 13 Sep 2014 23:27:17 +0200 Subject: [Freeipa-users] =?utf-8?q?FreeIPA_ActiveDire=E2=80=8Bctory_Integr?= =?utf-8?q?atio=E2=80=8Bn=3A_Managing_AD_Users_in_IPA?= In-Reply-To: References: Message-ID: Hi! There are two ways that you can use to integrate FreeIPA with AD: a.) trust b.) synchronization Here are the pros/cons for both of them: http://www.freeipa.org/docs/master/html-desktop/index.html#trust-sync If you want to manage POSIX attributes for each user can do that with either identity management for Unix at AD using the trust, or with the synchronzation at FreeIPA. With synchronization you see the users to in FreeIPA, but still have to two users to manage - in FreeIPA and AD. With the AD trust the sssd daemon running on FreeIPA is proxying all request from the client sssd directly to AD, so you see no users in FreeIPA, but you have to extend the AD schema using Identity Management for unix. Also the password policy from the group policy in AD is used when you use the AD trust, but on clients with sssd you can change the password using kpasswd from Kerberos. If you want to use a trust with AD and want to receive the correct GID set in AD then you have to use sssd >1.9.x, otherwise you get a different GID (see https://www.redhat.com/archives/freeipa-users/2014-September/msg00192.html) All other stuff such as HBAC etc. can be centrally managed on FreeIPA, no matter if you use a trust or synchronzation. Gregor 2014-09-13 22:03 GMT+02:00 Traiano Welcome : > Hi List > > Currently I have a stable trust relationship going between IPA and Windows > AD. I create users and manage passwords in AD, but want to manage the rest > in IPA, "the rest" being default shell, default home directory settings, > RBAC, HBAC, Selinux etc .. > > What I'm expecting it to be able to log into the FreeIPA web interface, and > see a synched list of users created in AD appear in the interface, after > which I can modify the settings on a per user basis. > > If that level of granularity is not possible, I would then expect to be able > to at least apply an IPA-imposed set of account defaults on and AD user > group: > > - default shell > - HBAC rules > - Sudo rules > - SELinux rules > - RBAC > > Is this possible with FreeIPA? I can't find anything coherent in the > documentation that describes an effective way of managing the POSIX > attributes of AD users in FreeIPA. > > Thanks in advance! > Traiano > > > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project From dpal at redhat.com Sat Sep 13 23:14:34 2014 From: dpal at redhat.com (Dmitri Pal) Date: Sat, 13 Sep 2014 19:14:34 -0400 Subject: [Freeipa-users] =?utf-8?q?FreeIPA_ActiveDire=E2=80=8Bctory_Integr?= =?utf-8?q?atio=E2=80=8Bn=3A_Managing_AD_Users_in_IPA?= In-Reply-To: References: Message-ID: <5414CFDA.9090904@redhat.com> On 09/13/2014 05:27 PM, Gregor Bregenzer wrote: > Hi! > > There are two ways that you can use to integrate FreeIPA with AD: a.) > trust b.) synchronization Here are the pros/cons for both of them: > http://www.freeipa.org/docs/master/html-desktop/index.html#trust-sync > > If you want to manage POSIX attributes for each user can do that with > either identity management for Unix at AD using the trust, or with the > synchronzation at FreeIPA. With synchronization you see the users to > in FreeIPA, but still have to two users to manage - in FreeIPA and AD. > With the AD trust the sssd daemon running on FreeIPA is proxying all > request from the client sssd directly to AD This is not exactly true. SSSD understands that IPA and AD are in trust relations. If you use user name and password to login SSSD will turn to AD directly without sending password over the wire. If you SSO into the linux box the kerberos library (on you windows client) will do all the ticket acquisition and redirects. The proxy is already done for older clients that does not understand that IPA is in trust relations with AD. http://www.freeipa.org/images/2/2e/FreeIPA33-trust.pdf > , so you see no users in > FreeIPA, but you have to extend the AD schema using Identity > Management for unix. You really have two options: let SSSD to map users dynamically, in this case you do not need AD schema extensions or you can extend schema as suggested. The third option that is under development is described in my other reply. > Also the password policy from the group policy in > AD is used when you use the AD trust, but on clients with sssd you can > change the password using kpasswd from Kerberos. If you want to use a > trust with AD and want to receive the correct GID set in AD then you > have to use sssd >1.9.x, otherwise you get a different GID (see > https://www.redhat.com/archives/freeipa-users/2014-September/msg00192.html) > > All other stuff such as HBAC etc. can be centrally managed on FreeIPA, > no matter if you use a trust or synchronzation. > > Gregor > > 2014-09-13 22:03 GMT+02:00 Traiano Welcome : >> Hi List >> >> Currently I have a stable trust relationship going between IPA and Windows >> AD. I create users and manage passwords in AD, but want to manage the rest >> in IPA, "the rest" being default shell, default home directory settings, >> RBAC, HBAC, Selinux etc .. >> >> What I'm expecting it to be able to log into the FreeIPA web interface, and >> see a synched list of users created in AD appear in the interface, after >> which I can modify the settings on a per user basis. >> >> If that level of granularity is not possible, I would then expect to be able >> to at least apply an IPA-imposed set of account defaults on and AD user >> group: >> >> - default shell >> - HBAC rules >> - Sudo rules >> - SELinux rules >> - RBAC >> >> Is this possible with FreeIPA? I can't find anything coherent in the >> documentation that describes an effective way of managing the POSIX >> attributes of AD users in FreeIPA. >> >> Thanks in advance! >> Traiano >> >> >> >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go To http://freeipa.org for more info on the project -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From gregor.bregenzer at gmail.com Sun Sep 14 07:42:10 2014 From: gregor.bregenzer at gmail.com (Gregor Bregenzer) Date: Sun, 14 Sep 2014 09:42:10 +0200 Subject: [Freeipa-users] =?utf-8?q?FreeIPA_ActiveDire=E2=80=8Bctory_Integr?= =?utf-8?q?atio=E2=80=8Bn=3A_Managing_AD_Users_in_IPA?= In-Reply-To: <5414CFDA.9090904@redhat.com> References: <5414CFDA.9090904@redhat.com> Message-ID: 2014-09-14 1:14 GMT+02:00 Dmitri Pal : > On 09/13/2014 05:27 PM, Gregor Bregenzer wrote: >> >> Hi! >> >> There are two ways that you can use to integrate FreeIPA with AD: a.) >> trust b.) synchronization Here are the pros/cons for both of them: >> http://www.freeipa.org/docs/master/html-desktop/index.html#trust-sync >> >> If you want to manage POSIX attributes for each user can do that with >> either identity management for Unix at AD using the trust, or with the >> synchronzation at FreeIPA. With synchronization you see the users to >> in FreeIPA, but still have to two users to manage - in FreeIPA and AD. >> With the AD trust the sssd daemon running on FreeIPA is proxying all >> request from the client sssd directly to AD > > This is not exactly true. SSSD understands that IPA and AD are in trust > relations. If you use user name and password to login SSSD will turn to AD > directly without sending password over the wire. If you SSO into the linux > box the kerberos library (on you windows client) will do all the ticket > acquisition and redirects. > > The proxy is already done for older clients that does not understand that > IPA is in trust relations with AD. > http://www.freeipa.org/images/2/2e/FreeIPA33-trust.pdf > Sorry, there are two things i did not mention a.) no SSO, b.) Linux Client SSSD requesting UID/GID. a.) if you ssh login from a Windows client that is _not_ joined in AD or a standalone Linux box - so no SSO. Because there the destination Linux clients with sssd (1.9.2 with AD trust compatibilty with ipa provider, or 1.11+ with full AD trust capability) still need SSSD on the FreeIPA Server that will forward the authentication requests to AD. In slide 30 of http://www.freeipa.org/images/2/2e/FreeIPA33-trust.pdf it states: "SSSD is used behind the scenes on the FreeIPA server to lookup up users in trusted AD domains SSSD on FreeIPA clients will forward resolution requests to FreeIPA servers through FreeIPA LDAP server plugin" b.) If you have a client that is authenticating using Kerberos and therefore SSO, the destination Linux sssd client still needs the sssd client on the FreeIPA server to lookup the UID/GID. So there's the authentication process either with SSO or without SSO, and there's the lookup process for the attributes - am i correct? >> , so you see no users in >> FreeIPA, but you have to extend the AD schema using Identity >> Management for unix. > > > You really have two options: let SSSD to map users dynamically, in this case > you do not need AD schema extensions or you can extend schema as suggested. > The third option that is under development is described in my other reply. What happens if you have already defined the UID/GID with the schema extension on AD and have legacy Linux clients using them, but you still want to use the exact UID/GID _and_ make use of all the great features offered in FreeIPA such as HBAC, sudorules, etc.? Then only the AD Trust with SSSD 1.11+ with full AD trust feature set is working - correct (because 1.9.2 with ipa provider cannot get the GID from AD)? >> Also the password policy from the group policy in >> AD is used when you use the AD trust, but on clients with sssd you can >> change the password using kpasswd from Kerberos. If you want to use a >> trust with AD and want to receive the correct GID set in AD then you >> have to use sssd >1.9.x, otherwise you get a different GID (see >> >> https://www.redhat.com/archives/freeipa-users/2014-September/msg00192.html) >> >> All other stuff such as HBAC etc. can be centrally managed on FreeIPA, >> no matter if you use a trust or synchronzation. >> >> Gregor >> >> 2014-09-13 22:03 GMT+02:00 Traiano Welcome : >>> >>> Hi List >>> >>> Currently I have a stable trust relationship going between IPA and >>> Windows >>> AD. I create users and manage passwords in AD, but want to manage the >>> rest >>> in IPA, "the rest" being default shell, default home directory settings, >>> RBAC, HBAC, Selinux etc .. >>> >>> What I'm expecting it to be able to log into the FreeIPA web interface, >>> and >>> see a synched list of users created in AD appear in the interface, after >>> which I can modify the settings on a per user basis. >>> >>> If that level of granularity is not possible, I would then expect to be >>> able >>> to at least apply an IPA-imposed set of account defaults on and AD user >>> group: >>> >>> - default shell >>> - HBAC rules >>> - Sudo rules >>> - SELinux rules >>> - RBAC >>> >>> Is this possible with FreeIPA? I can't find anything coherent in the >>> documentation that describes an effective way of managing the POSIX >>> attributes of AD users in FreeIPA. >>> >>> Thanks in advance! >>> Traiano >>> >>> >>> >>> >>> -- >>> Manage your subscription for the Freeipa-users mailing list: >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> Go To http://freeipa.org for more info on the project > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project From bnordgren at fs.fed.us Sun Sep 14 21:29:23 2014 From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS) Date: Sun, 14 Sep 2014 21:29:23 +0000 Subject: [Freeipa-users] =?utf-8?q?FreeIPA_ActiveDire=E2=80=8Bctory_Integr?= =?utf-8?q?atio=E2=80=8Bn=3A_Managing_AD_Users_in_IPA?= In-Reply-To: <5414B2A8.6050004@redhat.com> References: <5414B2A8.6050004@redhat.com> Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E726527@001FSN2MPN1-044.001f.mgd2.msft.net> Overwriting certain attributes may be more directly addressed by: https://fedorahosted.org/freeipa/ticket/3979 You are to some extent describing a feature that we call "views" that is currently in works. But there are two parts: a) Ability to overwrite POSIX attributes for AD users - this is views https://fedorahosted.org/freeipa/ticket/3318 https://fedorahosted.org/freeipa/ticket/4509 b) Ability to apply policies to AD users. It is already possible. This is done via group membership. So you create a group in IPA, make AD group an external member of that group and then use that IPA group to apply HBAC, SUDO and SELinux rules. As for RBAC what do you mean? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. -------------- next part -------------- An HTML attachment was scrubbed... URL: From uncommonkat at gmail.com Sun Sep 14 21:33:51 2014 From: uncommonkat at gmail.com (Kat) Date: Sun, 14 Sep 2014 14:33:51 -0700 Subject: [Freeipa-users] migrting just pws? Message-ID: <541609BF.8020804@gmail.com> Trying to figure out a way to migrate just the user PWs - since all the users were created with a script in the new layout, but I want to bring over their old PWs, hashed of course, to the new IPA server. Just thought I would check to see if anyone has tried to do that before? ~k From bnordgren at fs.fed.us Sun Sep 14 21:46:47 2014 From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS) Date: Sun, 14 Sep 2014 21:46:47 +0000 Subject: [Freeipa-users] migrting just pws? In-Reply-To: <541609BF.8020804@gmail.com> References: <541609BF.8020804@gmail.com> Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E72659E@001FSN2MPN1-044.001f.mgd2.msft.net> You can bring over password hashes for LDAP, but not Kerberos...provided your 389-ds is new enough to have a recently added configuration switch. If your system is in "migration mode", then authenticating via LDAP creates Kerberos hashes transparently. If you're running 4.0.x, see here for some details: https://fedorahosted.org/freeipa/ticket/4450 Bryce > -----Original Message----- > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- > bounces at redhat.com] On Behalf Of Kat > Sent: Sunday, September 14, 2014 3:34 PM > To: freeipa-users at redhat.com > Subject: [Freeipa-users] migrting just pws? > > Trying to figure out a way to migrate just the user PWs - since all the users > were created with a script in the new layout, but I want to bring over their > old PWs, hashed of course, to the new IPA server. > > Just thought I would check to see if anyone has tried to do that before? > > ~k > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. From natxo.asenjo at gmail.com Mon Sep 15 09:01:09 2014 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Mon, 15 Sep 2014 11:01:09 +0200 Subject: [Freeipa-users] [OT] ldap.conf settings with external CA Message-ID: hi, This might save some time to someone, so let me post it to the list. TLDR, when using php to connect to an AD ldaps host using ADCS from IPA joined hosts modify /etc/openldap/ldap.conf or $HOME/.ldaprc and change the TLS_CACERT environment variable to TLS_CACERT /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem We have, like many folks, an Active Directory (AD) windows environment running side by side our IPA environment. Our IPA joined apache web servers running centos 6.5 need to talk using php to the AD ldap servers for several applications. A business requirement is that the connection is secure, so we need to use ldaps or starttls ldap. After joining the webservers to our linux domain, a file is created: /etc/openldap/ldap.conf file with these settings: $ cat /etc/openldap/ldap.conf #File modified by ipa-client-install URI ldaps://kdc02.unix.domain.tld BASE dc=unix,dc=domain,dc=tld TLS_CACERT /etc/ipa/ca.crt Now, this is ok for most people. The problem we are having is that I "installed" our AD Certificate Services CA file by copying the file to /etc/pki/ca-trust/source/anchors/, running update-ca-trust enable && update-ca-trust (great tool by the way). Using openssl s_client I get to verify the certificate $ openssl s_client -connect dc04.domainl.ocal:636 -showcerts ... Verify return code: 0 (ok) So that works, but the php application does not accept the new CA unless I modify /etc/openldap/ldap.conf or create a $HOME/.ldaprc with these settings: TLS_CACERT /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem By the way, using Perl's Net::LDAP library just works without all these problems ..., gotta love php. -- -- Groeten, natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Mon Sep 15 11:24:55 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 15 Sep 2014 13:24:55 +0200 Subject: [Freeipa-users] BIND not starting after IPA install In-Reply-To: <1410512111.3686.36.camel@DV10MX1-Lin.adcock.com> References: <1410438045.3686.29.camel@DV10MX1-Lin.adcock.com> <5411D6FB.6020002@redhat.com> <5412B238.5070808@redhat.com> <1410512111.3686.36.camel@DV10MX1-Lin.adcock.com> Message-ID: <5416CC87.3080900@redhat.com> On 12.9.2014 10:57, Renier Gertzen wrote: > Hi > > Before starting IPA install i did "yum -y intstall bind*". I think that did it. > > Regards, > > On Fri, 2014-09-12 at 10:43 +0200, Petr Spacek wrote: > > > Hello! > > On 12.9.2014 09:39, Renier Gertzen wrote: >> Issue resolved in the following manner >> >> I saved copies of my named.conf. >> ran yum remove bind >> cd /var/named >> rm -Rf * (be carefull) >> ran yum install bind >> copied my named.conf file back >> service named start >> >> And it started and works now. >> Thanks for the SDB tip. > > Interesting. What did you change? Did you use plain "named" instead of > "named-sdb"? > > How did you manage to install named-sdb? ipa-server-install doesn't do that. > > Also, I haven't seen ipa-server-selinux package before... Who knows what else > was changed by Oracle repackaging? My bad, ipa-server-selinux package existed in the past and was removed later. Please ignore my previous e-mail. -- Petr^2 Spacek From dkopecek at redhat.com Mon Sep 15 11:06:33 2014 From: dkopecek at redhat.com (Daniel Kopecek) Date: Mon, 15 Sep 2014 13:06:33 +0200 Subject: [Freeipa-users] FreeIPA, SSSD, sudo and Local Users In-Reply-To: <20140911141240.GI20748@hendrix.brq.redhat.com> References: <20140911141240.GI20748@hendrix.brq.redhat.com> Message-ID: <20140915130633.77047a43@dhcp-2-122.brq.redhat.com> Hello, On Thu, 11 Sep 2014 16:12:40 +0200 Jakub Hrozek wrote: > On Wed, Sep 10, 2014 at 09:58:27PM +0000, Trevor T Kates (Services - > 6) wrote: > > Hi all: > > > > I'm using FreeIPA 3.0 under CentOS 6.5 and I'm trying to solve a > > bit of a quirky problem. From what I've read thus far, sudo under > > SSSD can't provide sudo rules for local users that are not part of > > the directory. To get around this, I've been using the > > sudo-ldap.conf file to provide sudo with direct access to the > > directory. This, however, can't make use of service discovery, so > > if the first server in the ldap_uri list is taken down, sudo delays > > for the length of the timeout set. My idea for getting around this > > has been to use sudo in SSSD for users that are in the directory > > and let sudo-ldap take care of local users with a line in > > nsswitch.conf like this: > > > > sudoers: files sss ldap > > I think this is more of a sudo question and I'm not too familiar with > the sudo code to answer this question well. I added the sudo Fedora > maintainer to CC, maybe he has some ideas? > > > > > My problem now seems to be that the ldap query is still run even if > > a successful hit is made to sssd. Changing the line in > > nsswitch.conf to: > > > > sudoers: files sss [success=return] ldap Yes, the "sudoers:" line is parsed by sudo and sudo does support the [SUCCESS=return] option. However, this applies only to queries for sudo rules. Is the LDAP query you're talking about a query for sudo rules or for users/groups? Sources for the user and groups dbs are not handled by sudo. Sudo just uses the usual glibc calls and they may result in queries to ldap and sss too. Dan K. > I don't think [success=return] will work here. Despite sudoers being > configured in nsswitch.conf, it's not actually a NSS map handled by > glibc. sudo itself parses the file.. > > > > > doesn't seem to actually work. > > > > Does anyone have pointers on how I can resolve this particular > > problem? > > > > Thanks! > > > > > > Trevor T. Kates > > > > > > > > > > CONFIDENTIALITY NOTICE: This electronic message contains > > information which may be legally confidential and or privileged and > > does not in any case represent a firm ENERGY COMMODITY bid or offer > > relating thereto which binds the sender without an additional > > express written confirmation to that effect. The information is > > intended solely for the individual or entity named above and access > > by anyone else is unauthorized. If you are not the intended > > recipient, any disclosure, copying, distribution, or use of the > > contents of this information is prohibited and may be unlawful. If > > you have received this electronic transmission in error, please > > reply immediately to the sender that you have received the message > > in error, and delete it. Thank you. > > > > -- > > Manage your subscription for the Freeipa-users mailing list: > > https://www.redhat.com/mailman/listinfo/freeipa-users > > Go To http://freeipa.org for more info on the project From natxo.asenjo at gmail.com Mon Sep 15 13:31:58 2014 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Mon, 15 Sep 2014 15:31:58 +0200 Subject: [Freeipa-users] ipa-getcert request problem Message-ID: hi, Centos 6.5. I want to create a certificate request for our mysql servers. I came up with this command line: $ sudo /usr/bin/ipa-getcert request -r -f /etc/pki/tls/certs/`hostname --fqdn`-mysql.crt -k /etc/pki/tls/private/`hostname --fqdn`-mysql.key -D `dnsdomainname` -U id-kp-serverAuth -K mysql/`hostname --fqdn` New signing request "20140915132335" added. But it gets rejected: Request ID '20140915132335': status: CA_REJECTED ca-error: Server denied our request, giving up: 2100 (RPC failed at server. Insufficient access: You need to be a member of the serviceadmin role to add services). stuck: yes key pair storage: type=FILE,location='/etc/pki/tls/private/hostname-mysql.key' certificate: type=FILE,location='/etc/pki/tls/certs/hostname-mysql.crt' CA: IPA issuer: subject: expires: unknown pre-save command: post-save command: track: yes auto-renew: yes I think I have the serviceadmin role: $ ipa role-show "it specialist" Role name: IT Specialist Description: IT Specialist Member groups: admins Privileges: Host Administrators, Host Group Administrators, Service Administrators, Automount Administrators The account is member of group admins. What am I doing wrong? Thanks! -- Groeten, natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From devel at jasonwoods.me.uk Mon Sep 15 13:48:18 2014 From: devel at jasonwoods.me.uk (Jason Woods) Date: Mon, 15 Sep 2014 14:48:18 +0100 Subject: [Freeipa-users] Lost access after password policy change Message-ID: Hi all, I wonder if anyone has any advice. We changed password policy to 20000 days a few weeks ago. Over the weekend, passwords expired and now we cannot login. All admin accounts are essentially unusable. Seems to be this issue: https://fedorahosted.org/freeipa/ticket/3312 Any ideas how to get the admin accounts working again? We can't even login to reverse the password policy change. When we attempt to use the commands we get: ipa: ERROR: did not receive Kerberos credentials Of course, we can't kinit. Fortunately, it's only a small network of machines, so it's fairly humorous. We'd rather not have to rebuild though or recover backups. I presume we just need to somehow get into LDAP without authentication and force change policy. Thanks, Jason From devel at jasonwoods.me.uk Mon Sep 15 14:06:32 2014 From: devel at jasonwoods.me.uk (Jason Woods) Date: Mon, 15 Sep 2014 15:06:32 +0100 Subject: [Freeipa-users] Lost access after password policy change In-Reply-To: References: Message-ID: <0950BC09-12C5-4DC3-B4B1-1DAA2FACE304@jasonwoods.me.uk> On 15 Sep 2014, at 14.48, Jason Woods wrote: > I wonder if anyone has any advice. We changed password policy to 20000 days a few weeks ago. > > Over the weekend, passwords expired and now we cannot login. All admin accounts are essentially unusable. > Seems to be this issue: https://fedorahosted.org/freeipa/ticket/3312 Just solved it by turned the clock back to around 1975, playing around with password change, and then returning to 2014. Eventually let me get in so I could kinit and fix the policy. Phew. Sorry to bother. Jason From npmccallum at redhat.com Mon Sep 15 14:45:05 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 15 Sep 2014 10:45:05 -0400 Subject: [Freeipa-users] [Freeipa-devel] Announcing FreeIPA 4.0.3 In-Reply-To: <5413570D.3040708@redhat.com> References: <5413570D.3040708@redhat.com> Message-ID: <1410792305.4238.3.camel@redhat.com> FYI, for any Fedora testers out there, we have updated to 4.0.3 in Fedora 21 in part because it substantially reduces the size of the install media for the upcoming Alpha release. If you'd like to test and provide feedback on the packages, the link is here: https://admin.fedoraproject.org/updates/FEDORA-2014-10811 On Fri, 2014-09-12 at 22:26 +0200, Petr Viktorin wrote: > The FreeIPA team would like to announce FreeIPA v4.0.3 bugfix release! > > It can be downloaded from http://www.freeipa.org/page/Downloads. The > builds will be available for Fedora 21 Beta. Builds for Fedora 20 are > available in the official > [https://copr.fedoraproject.org/coprs/mkosek/freeipa/ COPR repository]. > > == Bug fixes in 4.0.3 == > * Several issues concerning integration with 389 Directory Server 1.3.3 > were fixed. > * An upgrade crash was fixed. > > == Known Issues == > * On Fedora 21 Alpha, FreeIPA server configuration should be done after > upgrading packages from updates-testing. > > == Upgrading == > An IPA server can be upgraded simply by installing updated rpms. The > server does not need to be shut down in advance. > > Please note that if you are doing the upgrade in special environment > (e.g. FedUp) which does not allow running the LDAP server during upgrade > process, upgrade scripts need to be run manually after the first boot: > > # ipa-ldap-updater --upgrade > # ipa-upgradeconfig > > Also note that the performance improvements require an extended set of > indexes to be configured. RPM update for an IPA server with a excessive > number of users may require several minutes to finish. > > If you have multiple servers you may upgrade them one at a time. It is > expected that all servers will be upgraded in a relatively short period > (days or weeks, not months). They should be able to co-exist peacefully > but new features will not be available on old servers and enrolling a > new client against an old server will result in the SSH keys not being > uploaded. > > Downgrading a server once upgraded is not supported. > > Upgrading from 3.3.0 and later versions is supported. Upgrading from > previous versions is not supported and has not been tested. > > An enrolled client does not need the new packages installed unless you > want to re-enroll it. SSH keys for already installed clients are not > uploaded, you will have to re-enroll the client or manually upload the keys. > > == Feedback == > Please provide comments, bugs and other feedback via the freeipa-users > mailing list (http://www.redhat.com/mailman/listinfo/freeipa-users) or > #freeipa channel on Freenode. > > == Detailed Changelog since 4.0.2 == > === David Kupka (1) === > * Fix typo causing ipa-upgradeconfig to fail. > > === Ludwig Krispenz (1) === > * Update SSL ciphers configured in 389-ds-base > > === Nathaniel McCallum (1) === > * Update qrcode support for newer python-qrcode > > === Petr Viktorin (4) === > * Update referential integrity config for DS 1.3.3 > * permission plugin: Auto-add operational atttributes to read permissions > * Allow deleting obsolete permissions; remove operational attribute > permissions > * Become IPA 4.0.3 > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From mkosek at redhat.com Mon Sep 15 14:53:21 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 15 Sep 2014 16:53:21 +0200 Subject: [Freeipa-users] Use of SAN's with automatic certificates in FreeIPA 4 In-Reply-To: <54134753.6040707@redhat.com> References: <5412D532.6080503@redhat.com> <54134753.6040707@redhat.com> Message-ID: <5416FD61.7080806@redhat.com> On 09/12/2014 09:19 PM, Dmitri Pal wrote: > On 09/12/2014 02:43 PM, Michael Lasevich wrote: >> That is awesome, but I am clearly missing some insight as to how this is >> supposed to work. Can you point me to some more specific info on how to >> accomplish this. >> >> I tried using the ipa-getcert request with multiple -D's from the client, but >> got : >> >> ** Insufficient access: You need to be a member of the serviceadmin role to >> add services >> >> Unless I am missing something, I should probably not add each host to >> "serviceadmins" for security reasons. > > 4.0 has a new permissions system this might yet to be another use case that we > might have overlooked. Not, not really - this part works well with 4.0. > I will leave to developers to review this situation on Monday morning. > >> >> So I then I tried generating a csr via openssl with SANs on the client and >> then adding it using "ipa cert-request file.csr --prinicple >> host/${client_hostname}@DOMAIN" from ipa server as admin (just to be sure) >> and got this error (where is the first SAN): >> >> ** ipa: ERROR: The service principal for subject alt name in >> certificate request does not exist >> >> It sounds like I need to create service principal for each SAN, but I can't >> seem to figure out how to do it (only allows me to create service prinicpals >> for existing hosts) You need to create an (unused) host for the SAN service first. After that you can create the service. Dummy service/host entries with appropriate managedby attribute are used to authorize which host/service. I did a quick test with latest FreeIPA 4.0.3 and it worked for me: # ipa-getcert request -d /etc/httpd/nssdb -n Server-Cert -K test/`hostname` -N CN=`hostname`,O=EXAMPLE.COM -D san.host.example.test -g 2048 New signing request "20140915143901" added. # ipa-getcert list -i 20140915143901 Number of certificates and requests being tracked: 8. Request ID '20140915143901': status: CA_REJECTED ca-error: Server at https://ipa.mkosek-fedora20.test/ipa/xml denied our request, giving up: 2100 (RPC failed at server. Insufficient access: You need to be a member of the serviceadmin role to add services). stuck: yes key pair storage: type=NSSDB,location='/etc/httpd/nssdb',nickname='Server-Cert',token='NSS Certificate DB' certificate: type=NSSDB,location='/etc/httpd/nssdb',nickname='Server-Cert' CA: IPA issuer: subject: expires: unknown pre-save command: post-save command: track: yes auto-renew: yes This is expected, now the authorization needs to be added: # ipa service-add test/`hostname` # ipa service-add test/san.host.example.test --force # ipa service-add-host test/san.host.example.test --host `hostname` Principal: test/san.host.example.test at MKOSEK-FEDORA20.TEST Managed by: san.host.example.test, ipa.mkosek-fedora20.test ------------------------- Number of members added 1 ------------------------- # ipa-getcert resubmit -i 20140915143901 Resubmitting "20140915143901" to "IPA". # ipa-getcert list -i 20140915143901 Number of certificates and requests being tracked: 8. Request ID '20140915143901': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/httpd/nssdb',nickname='Server-Cert',token='NSS Certificate DB' certificate: type=NSSDB,location='/etc/httpd/nssdb',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=MKOSEK-FEDORA20.TEST subject: CN=ipa.mkosek-fedora20.test,O=MKOSEK-FEDORA20.TEST expires: 2016-09-15 14:48:01 UTC dns: san.host.example.test principal name: test/ipa.mkosek-fedora20.test at MKOSEK-FEDORA20.TEST key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes # certutil -L -d /etc/httpd/nssdb -n Server-Cert Certificate: Data: Version: 3 (0x2) Serial Number: 11 (0xb) Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption Issuer: "CN=Certificate Authority,O=MKOSEK-FEDORA20.TEST" Validity: Not Before: Mon Sep 15 14:48:01 2014 Not After : Thu Sep 15 14:48:01 2016 Subject: "CN=ipa.mkosek-fedora20.test,O=MKOSEK-FEDORA20.TEST" ... Name: Certificate Subject Alt Name DNS name: "san.host.example.test" ... I also updated http://www.freeipa.org/page/PKI#Automated_certificate_requests_with_Certmonger with couple hints how that works. HTH, Martin From mkosek at redhat.com Mon Sep 15 15:01:16 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 15 Sep 2014 17:01:16 +0200 Subject: [Freeipa-users] ipa-getcert request problem In-Reply-To: References: Message-ID: <5416FF3C.2070103@redhat.com> On 09/15/2014 03:31 PM, Natxo Asenjo wrote: > hi, > > Centos 6.5. > > I want to create a certificate request for our mysql servers. I came up > with this command line: > > $ sudo /usr/bin/ipa-getcert request -r -f /etc/pki/tls/certs/`hostname > --fqdn`-mysql.crt -k /etc/pki/tls/private/`hostname --fqdn`-mysql.key -D > `dnsdomainname` -U id-kp-serverAuth -K mysql/`hostname --fqdn` > New signing request "20140915132335" added. > > But it gets rejected: > > Request ID '20140915132335': > status: CA_REJECTED > ca-error: Server denied our request, giving up: 2100 (RPC failed at > server. Insufficient access: You need to be a member of the serviceadmin > role to add services). > stuck: yes > key pair storage: > type=FILE,location='/etc/pki/tls/private/hostname-mysql.key' > certificate: > type=FILE,location='/etc/pki/tls/certs/hostname-mysql.crt' > CA: IPA > issuer: > subject: > expires: unknown > pre-save command: > post-save command: > track: yes > auto-renew: yes > > I think I have the serviceadmin role: > > $ ipa role-show "it specialist" > Role name: IT Specialist > Description: IT Specialist > Member groups: admins > Privileges: Host Administrators, Host Group Administrators, Service > Administrators, Automount Administrators > > The account is member of group admins. > > What am I doing wrong? > > Thanks! > -- > Groeten, > natxo > > > It seems you hit the same issue as Michael. See my response: https://www.redhat.com/archives/freeipa-users/2014-September/msg00256.html You will need to 1) Create host `domainname` 2) Create services * mysql/`hostname` * mysql/`domainname` 3) Run ipa service-add-host mysql/`domainname` --host mysql/`hostname` 4) Resubmit certificate It looks like we need to do better in documentation&error message... Oh and BTW, this only works with FreeIPA 4.0+, details in ticket https://fedorahosted.org/freeipa/ticket/3977. Martin From rcritten at redhat.com Mon Sep 15 15:03:33 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 15 Sep 2014 11:03:33 -0400 Subject: [Freeipa-users] ipa-getcert request problem In-Reply-To: References: Message-ID: <5416FFC5.4060305@redhat.com> Natxo Asenjo wrote: > > hi, > > Centos 6.5. > > I want to create a certificate request for our mysql servers. I came up > with this command line: > > $ sudo /usr/bin/ipa-getcert request -r -f /etc/pki/tls/certs/`hostname > --fqdn`-mysql.crt -k /etc/pki/tls/private/`hostname --fqdn`-mysql.key -D > `dnsdomainname` -U id-kp-serverAuth -K mysql/`hostname --fqdn` > New signing request "20140915132335" added. > > But it gets rejected: > > Request ID '20140915132335': > status: CA_REJECTED > ca-error: Server denied our request, giving up: 2100 (RPC > failed at server. Insufficient access: You need to be a member of the > serviceadmin role to add services). > stuck: yes > key pair storage: > type=FILE,location='/etc/pki/tls/private/hostname-mysql.key' > certificate: > type=FILE,location='/etc/pki/tls/certs/hostname-mysql.crt' > CA: IPA > issuer: > subject: > expires: unknown > pre-save command: > post-save command: > track: yes > auto-renew: yes > > I think I have the serviceadmin role: > > $ ipa role-show "it specialist" > Role name: IT Specialist > Description: IT Specialist > Member groups: admins > Privileges: Host Administrators, Host Group Administrators, Service > Administrators, Automount Administrators > > The account is member of group admins. > > What am I doing wrong? ipa-getcert runs using the host credentials, not the current user's. A host cannot add services, even its own. So you need to pre-create the mysql service then run getcert resubmit -i 20140915132335 and IPA should issue the cert. rob From trevor.t.kates at dom.com Mon Sep 15 15:10:01 2014 From: trevor.t.kates at dom.com (Trevor T Kates (Services - 6)) Date: Mon, 15 Sep 2014 15:10:01 +0000 Subject: [Freeipa-users] Freeipa-users Digest, Vol 74, Issue 70 In-Reply-To: References: Message-ID: > Message: 1 > Date: Mon, 15 Sep 2014 13:06:33 +0200 > From: Daniel Kopecek > To: Jakub Hrozek > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] FreeIPA, SSSD, sudo and Local Users > Message-ID: <20140915130633.77047a43 at dhcp-2-122.brq.redhat.com> > Content-Type: text/plain; charset=US-ASCII > > Hello, > > On Thu, 11 Sep 2014 16:12:40 +0200 > Jakub Hrozek wrote: > > > On Wed, Sep 10, 2014 at 09:58:27PM +0000, Trevor T Kates (Services - > > 6) wrote: > > > Hi all: > > > > > > I'm using FreeIPA 3.0 under CentOS 6.5 and I'm trying to solve a > > > bit of a quirky problem. From what I've read thus far, sudo under > > > SSSD can't provide sudo rules for local users that are not part of > > > the directory. To get around this, I've been using the > > > sudo-ldap.conf file to provide sudo with direct access to the > > > directory. This, however, can't make use of service discovery, so > > > if the first server in the ldap_uri list is taken down, sudo delays > > > for the length of the timeout set. My idea for getting around this > > > has been to use sudo in SSSD for users that are in the directory > > > and let sudo-ldap take care of local users with a line in > > > nsswitch.conf like this: > > > > > > sudoers: files sss ldap > > > > I think this is more of a sudo question and I'm not too familiar with > > the sudo code to answer this question well. I added the sudo Fedora > > maintainer to CC, maybe he has some ideas? > > > > > > > > My problem now seems to be that the ldap query is still run even if > > > a successful hit is made to sssd. Changing the line in > > > nsswitch.conf to: > > > > > > sudoers: files sss [success=return] ldap > > Yes, the "sudoers:" line is parsed by sudo and sudo does support the > [SUCCESS=return] option. However, this applies only to queries for sudo > rules. > > Is the LDAP query you're talking about a query for sudo rules or for > users/groups? Sources for the user and groups dbs are not handled by > sudo. Sudo just uses the usual glibc calls and they may result in > queries to ldap and sss too. The LDAP query in question is a query for sudo rules. This can be seen when setting sudoers_debug in /etc/sudo-ldap.conf and running sudo -l. The query is run against sss and then ldap even when [SUCCESS=return] is present between sss and ldap in /etc/nsswitch.conf. The users/groups dbs are set to be handled by files/sss in /etc/nsswitch.conf. > Dan K. Thanks, Trevor T. Kates > > I don't think [success=return] will work here. Despite sudoers being > > configured in nsswitch.conf, it's not actually a NSS map handled by > > glibc. sudo itself parses the file.. > > > > > > > > doesn't seem to actually work. > > > > > > Does anyone have pointers on how I can resolve this particular > > > problem? > > > > > > Thanks! > > > > > > > > > Trevor T. Kates > > > > > > > > > > > > > > > CONFIDENTIALITY NOTICE: This electronic message contains > > > information which may be legally confidential and or privileged and > > > does not in any case represent a firm ENERGY COMMODITY bid or offer > > > relating thereto which binds the sender without an additional > > > express written confirmation to that effect. The information is > > > intended solely for the individual or entity named above and access > > > by anyone else is unauthorized. If you are not the intended > > > recipient, any disclosure, copying, distribution, or use of the > > > contents of this information is prohibited and may be unlawful. If > > > you have received this electronic transmission in error, please > > > reply immediately to the sender that you have received the message > > > in error, and delete it. Thank you. > > > > > > -- > > > Manage your subscription for the Freeipa-users mailing list: > > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > Go To http://freeipa.org for more info on the project CONFIDENTIALITY NOTICE: This electronic message contains information which may be legally confidential and or privileged and does not in any case represent a firm ENERGY COMMODITY bid or offer relating thereto which binds the sender without an additional express written confirmation to that effect. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. From rob.verduijn at gmail.com Mon Sep 15 15:16:39 2014 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Mon, 15 Sep 2014 17:16:39 +0200 Subject: [Freeipa-users] apache kerberized nfs4 /var/www/html access denied for apache user Message-ID: Hello, I've got a webserver whose default export is on a kerberized nfs4 export. The export works fine for regular ipa users However the apache user is not allowed to read anything from the export. What would be the best practice to allow the apache user access to the nfs4 export without switching to sec=sys ? Cheers Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Mon Sep 15 15:26:16 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 15 Sep 2014 17:26:16 +0200 Subject: [Freeipa-users] [Freeipa-devel] Announcing FreeIPA 4.0.3 In-Reply-To: <1410792305.4238.3.camel@redhat.com> References: <5413570D.3040708@redhat.com> <1410792305.4238.3.camel@redhat.com> Message-ID: <54170518.1060508@redhat.com> On 09/15/2014 04:45 PM, Nathaniel McCallum wrote: > FYI, for any Fedora testers out there, we have updated to 4.0.3 in > Fedora 21 in part because it substantially reduces the size of the > install media for the upcoming Alpha release. If you'd like to test and > provide feedback on the packages, the link is here: > > https://admin.fedoraproject.org/updates/FEDORA-2014-10811 Actually, this update came too late for the Alpha. It will be considered for Beta. Use the updates-testing repo if you want to test FreeIPA in f21 Alpha. -- Petr? From tbabej at redhat.com Mon Sep 15 15:36:35 2014 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 15 Sep 2014 17:36:35 +0200 Subject: [Freeipa-users] Lost access after password policy change In-Reply-To: <0950BC09-12C5-4DC3-B4B1-1DAA2FACE304@jasonwoods.me.uk> References: <0950BC09-12C5-4DC3-B4B1-1DAA2FACE304@jasonwoods.me.uk> Message-ID: <54170783.40409@redhat.com> Just for the record, this should be fixed since FreeIPA 3.2: https://fedorahosted.org/freeipa/ticket/3114 https://fedorahosted.org/freeipa/ticket/3114 On 09/15/2014 04:06 PM, Jason Woods wrote: > On 15 Sep 2014, at 14.48, Jason Woods wrote: > >> I wonder if anyone has any advice. We changed password policy to 20000 days a few weeks ago. >> >> Over the weekend, passwords expired and now we cannot login. All admin accounts are essentially unusable. >> Seems to be this issue: https://fedorahosted.org/freeipa/ticket/3312 > Just solved it by turned the clock back to around 1975, playing around with password change, and then returning to 2014. Eventually let me get in so I could kinit and fix the policy. > > Phew. Sorry to bother. > > Jason > -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From tbabej at redhat.com Mon Sep 15 15:40:53 2014 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 15 Sep 2014 17:40:53 +0200 Subject: [Freeipa-users] Lost access after password policy change In-Reply-To: <54170783.40409@redhat.com> References: <0950BC09-12C5-4DC3-B4B1-1DAA2FACE304@jasonwoods.me.uk> <54170783.40409@redhat.com> Message-ID: <54170885.5010407@redhat.com> Sorry, second ticket should have been https://fedorahosted.org/freeipa/ticket/3312 On 09/15/2014 05:36 PM, Tomas Babej wrote: > Just for the record, this should be fixed since FreeIPA 3.2: > > https://fedorahosted.org/freeipa/ticket/3114 > https://fedorahosted.org/freeipa/ticket/3114 > > On 09/15/2014 04:06 PM, Jason Woods wrote: >> On 15 Sep 2014, at 14.48, Jason Woods wrote: >> >>> I wonder if anyone has any advice. We changed password policy to 20000 days a few weeks ago. >>> >>> Over the weekend, passwords expired and now we cannot login. All admin accounts are essentially unusable. >>> Seems to be this issue: https://fedorahosted.org/freeipa/ticket/3312 >> Just solved it by turned the clock back to around 1975, playing around with password change, and then returning to 2014. Eventually let me get in so I could kinit and fix the policy. >> >> Phew. Sorry to bother. >> >> Jason >> -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From npmccallum at redhat.com Mon Sep 15 16:16:35 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 15 Sep 2014 12:16:35 -0400 Subject: [Freeipa-users] [Freeipa-devel] Announcing FreeIPA 4.0.3 In-Reply-To: <54170518.1060508@redhat.com> References: <5413570D.3040708@redhat.com> <1410792305.4238.3.camel@redhat.com> <54170518.1060508@redhat.com> Message-ID: <1410797795.4238.4.camel@redhat.com> On Mon, 2014-09-15 at 17:26 +0200, Petr Viktorin wrote: > On 09/15/2014 04:45 PM, Nathaniel McCallum wrote: > > FYI, for any Fedora testers out there, we have updated to 4.0.3 in > > Fedora 21 in part because it substantially reduces the size of the > > install media for the upcoming Alpha release. If you'd like to test and > > provide feedback on the packages, the link is here: > > > > https://admin.fedoraproject.org/updates/FEDORA-2014-10811 > > Actually, this update came too late for the Alpha. It will be considered > for Beta. > > > Use the updates-testing repo if you want to test FreeIPA in f21 Alpha. https://qa.fedoraproject.org/blockerbugs/milestone/21/alpha/buglist See bug: 1117432. From rcritten at redhat.com Mon Sep 15 16:56:38 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 15 Sep 2014 12:56:38 -0400 Subject: [Freeipa-users] migrting just pws? In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E72659E@001FSN2MPN1-044.001f.mgd2.msft.net> References: <541609BF.8020804@gmail.com> <82E7C9A01FD0764CACDD35D10F5DFB6E72659E@001FSN2MPN1-044.001f.mgd2.msft.net> Message-ID: <54171A46.8000101@redhat.com> Nordgren, Bryce L -FS wrote: > You can bring over password hashes for LDAP, but not Kerberos...provided your 389-ds is new enough to have a recently added configuration switch. If your system is in "migration mode", then authenticating via LDAP creates Kerberos hashes transparently. > > If you're running 4.0.x, see here for some details: https://fedorahosted.org/freeipa/ticket/4450 In his case the user's already exist so they'll be skipped over if you re-migrate. We sort of rely on the behavior of LDAP/389-ds when migrating users and passwords: on an add the password policy is not examined. Other than that it is difficult to insert a pre-hashed password, even in migration mode. You may be able to do it as Directory Manager. That's where I'd start anyway. rob > > Bryce > >> -----Original Message----- >> From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- >> bounces at redhat.com] On Behalf Of Kat >> Sent: Sunday, September 14, 2014 3:34 PM >> To: freeipa-users at redhat.com >> Subject: [Freeipa-users] migrting just pws? >> >> Trying to figure out a way to migrate just the user PWs - since all the users >> were created with a script in the new layout, but I want to bring over their >> old PWs, hashed of course, to the new IPA server. >> >> Just thought I would check to see if anyone has tried to do that before? >> >> ~k >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go To http://freeipa.org for more info on the project > > > > > This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. > From natxo.asenjo at gmail.com Mon Sep 15 17:03:17 2014 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Mon, 15 Sep 2014 19:03:17 +0200 Subject: [Freeipa-users] ipa-getcert request problem In-Reply-To: <5416FFC5.4060305@redhat.com> References: <5416FFC5.4060305@redhat.com> Message-ID: On Mon, Sep 15, 2014 at 5:03 PM, Rob Crittenden wrote: > Natxo Asenjo wrote: > >> >> hi, >> >> Centos 6.5. >> >> I want to create a certificate request for our mysql servers. I came up >> with this command line: >> >> $ sudo /usr/bin/ipa-getcert request -r -f /etc/pki/tls/certs/`hostname >> --fqdn`-mysql.crt -k /etc/pki/tls/private/`hostname --fqdn`-mysql.key -D >> `dnsdomainname` -U id-kp-serverAuth -K mysql/`hostname --fqdn` >> New signing request "20140915132335" added. >> >> But it gets rejected: >> >> Request ID '20140915132335': >> status: CA_REJECTED >> ca-error: Server denied our request, giving up: 2100 (RPC >> failed at server. Insufficient access: You need to be a member of the >> serviceadmin role to add services). >> stuck: yes >> key pair storage: >> type=FILE,location='/etc/pki/tls/private/hostname-mysql.key' >> certificate: >> type=FILE,location='/etc/pki/tls/certs/hostname-mysql.crt' >> CA: IPA >> issuer: >> subject: >> expires: unknown >> pre-save command: >> post-save command: >> track: yes >> auto-renew: yes >> >> I think I have the serviceadmin role: >> >> $ ipa role-show "it specialist" >> Role name: IT Specialist >> Description: IT Specialist >> Member groups: admins >> Privileges: Host Administrators, Host Group Administrators, Service >> Administrators, Automount Administrators >> >> The account is member of group admins. >> >> What am I doing wrong? >> > > ipa-getcert runs using the host credentials, not the current user's. A > host cannot add services, even its own. So you need to pre-create the mysql > service then run getcert resubmit -i 20140915132335 and IPA should issue > the cert. Yes! Thanks, I guess I had misunderstood how this should work. Now I have the cert and the key and they are in the right place. -- regards, natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From mlasevich at lasevich.net Mon Sep 15 17:52:37 2014 From: mlasevich at lasevich.net (Michael Lasevich) Date: Mon, 15 Sep 2014 10:52:37 -0700 Subject: [Freeipa-users] Use of SAN's with automatic certificates in FreeIPA 4 In-Reply-To: <5416FD61.7080806@redhat.com> References: <5412D532.6080503@redhat.com> <54134753.6040707@redhat.com> <5416FD61.7080806@redhat.com> Message-ID: Martin, this was extremely helpful. I got it to work manually, now all I need to do is automate the process :-) The only thing "missing" from this is that I needed to do "ipa host-add san.host.example.test" before your other "ipa service-add" commands . You mentioned it, but not shown the command, so for those who will want to follow the script, it is an essential part of the process. Thank you so much, -M On Mon, Sep 15, 2014 at 7:53 AM, Martin Kosek wrote: > On 09/12/2014 09:19 PM, Dmitri Pal wrote: > > On 09/12/2014 02:43 PM, Michael Lasevich wrote: > >> That is awesome, but I am clearly missing some insight as to how this is > >> supposed to work. Can you point me to some more specific info on how to > >> accomplish this. > >> > >> I tried using the ipa-getcert request with multiple -D's from the > client, but > >> got : > >> > >> ** Insufficient access: You need to be a member of the serviceadmin > role to > >> add services > >> > >> Unless I am missing something, I should probably not add each host to > >> "serviceadmins" for security reasons. > > > > 4.0 has a new permissions system this might yet to be another use case > that we > > might have overlooked. > > Not, not really - this part works well with 4.0. > > > I will leave to developers to review this situation on Monday morning. > > > >> > >> So I then I tried generating a csr via openssl with SANs on the client > and > >> then adding it using "ipa cert-request file.csr --prinicple > >> host/${client_hostname}@DOMAIN" from ipa server as admin (just to be > sure) > >> and got this error (where is the first SAN): > >> > >> ** ipa: ERROR: The service principal for subject alt name in > >> certificate request does not exist > >> > >> It sounds like I need to create service principal for each SAN, but I > can't > >> seem to figure out how to do it (only allows me to create service > prinicpals > >> for existing hosts) > > You need to create an (unused) host for the SAN service first. After that > you > can create the service. Dummy service/host entries with appropriate > managedby > attribute are used to authorize which host/service. > > I did a quick test with latest FreeIPA 4.0.3 and it worked for me: > > # ipa-getcert request -d /etc/httpd/nssdb -n Server-Cert -K > test/`hostname` -N > CN=`hostname`,O=EXAMPLE.COM -D san.host.example.test -g 2048 > New signing request "20140915143901" added. > > # ipa-getcert list -i 20140915143901 > Number of certificates and requests being tracked: 8. > Request ID '20140915143901': > status: CA_REJECTED > ca-error: Server at https://ipa.mkosek-fedora20.test/ipa/xml > denied our > request, giving up: 2100 (RPC failed at server. Insufficient access: You > need > to be a member of the serviceadmin role to add services). > stuck: yes > key pair storage: > type=NSSDB,location='/etc/httpd/nssdb',nickname='Server-Cert',token='NSS > Certificate DB' > certificate: > type=NSSDB,location='/etc/httpd/nssdb',nickname='Server-Cert' > CA: IPA > issuer: > subject: > expires: unknown > pre-save command: > post-save command: > track: yes > auto-renew: yes > > > This is expected, now the authorization needs to be added: > > # ipa service-add test/`hostname` > # ipa service-add test/san.host.example.test --force > # ipa service-add-host test/san.host.example.test --host `hostname` > Principal: test/san.host.example.test at MKOSEK-FEDORA20.TEST > Managed by: san.host.example.test, ipa.mkosek-fedora20.test > ------------------------- > Number of members added 1 > ------------------------- > > > # ipa-getcert resubmit -i 20140915143901 > Resubmitting "20140915143901" to "IPA". > > # ipa-getcert list -i 20140915143901 > Number of certificates and requests being tracked: 8. > Request ID '20140915143901': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/httpd/nssdb',nickname='Server-Cert',token='NSS > Certificate DB' > certificate: > type=NSSDB,location='/etc/httpd/nssdb',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=MKOSEK-FEDORA20.TEST > subject: CN=ipa.mkosek-fedora20.test,O=MKOSEK-FEDORA20.TEST > expires: 2016-09-15 14:48:01 UTC > dns: san.host.example.test > principal name: test/ipa.mkosek-fedora20.test at MKOSEK-FEDORA20.TEST > key usage: > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: > track: yes > auto-renew: yes > > # certutil -L -d /etc/httpd/nssdb -n Server-Cert > Certificate: > Data: > Version: 3 (0x2) > Serial Number: 11 (0xb) > Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption > Issuer: "CN=Certificate Authority,O=MKOSEK-FEDORA20.TEST" > Validity: > Not Before: Mon Sep 15 14:48:01 2014 > Not After : Thu Sep 15 14:48:01 2016 > Subject: "CN=ipa.mkosek-fedora20.test,O=MKOSEK-FEDORA20.TEST" > ... > Name: Certificate Subject Alt Name > DNS name: "san.host.example.test" > ... > > > I also updated > > http://www.freeipa.org/page/PKI#Automated_certificate_requests_with_Certmonger > with couple hints how that works. > > HTH, > Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bnordgren at fs.fed.us Mon Sep 15 18:10:13 2014 From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS) Date: Mon, 15 Sep 2014 18:10:13 +0000 Subject: [Freeipa-users] apache kerberized nfs4 /var/www/html access denied for apache user In-Reply-To: References: Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E7267D7@001FSN2MPN1-044.001f.mgd2.msft.net> Hi Rob, How does the NFS server map the apache user to ?something? it recognizes? I would suggest that the easiest solution may be to use an IPA account called ?apache?, so that the mappings would just work, but currently I?m having trouble running a service as a domain user via systemd. (https://lists.fedorahosted.org/pipermail/sssd-users/2014-September/002194.html) Beyond that, for kerberized NFS (local or domain user), you?ll need something to keep a fresh ticket on hand, so you may end up running something like k5start, and setting KRB5CCNAME in the environment where you?re running apache. Bryce From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Rob Verduijn Sent: Monday, September 15, 2014 9:17 AM To: freeipa-users at redhat.com Subject: [Freeipa-users] apache kerberized nfs4 /var/www/html access denied for apache user Hello, I've got a webserver whose default export is on a kerberized nfs4 export. The export works fine for regular ipa users However the apache user is not allowed to read anything from the export. What would be the best practice to allow the apache user access to the nfs4 export without switching to sec=sys ? Cheers Rob This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. -------------- next part -------------- An HTML attachment was scrubbed... URL: From genadipost at gmail.com Mon Sep 15 22:39:41 2014 From: genadipost at gmail.com (Genadi Postrilko) Date: Tue, 16 Sep 2014 01:39:41 +0300 Subject: [Freeipa-users] AD Trust - Cannot resolve servers for KDC after reboot Message-ID: Hello all ! I have deployed test environment for AD trust feature, the environment contains : Windows Server 2008 - AD Server. RHEL 7 - IPA 3.3 Server. RHEL 6.2 - IPA Client. I have established the trust as IPA in the sub domain of AD. AD DNS domain - blue.com IPA DNS domain - linux.blue.com All was working fine as i was able to kinit with AD users: [root at ipaserver1 ~]# kinit Yoni at BLUE.COM Password for Yoni at BLUE.COM: [root at ipaserver1 ~]# klist Ticket cache: KEYRING:persistent:0:krb_ccache_oi15FrE Default principal: Yoni at BLUE.COM Valid starting Expires Service principal 09/16/2014 01:00:25 09/16/2014 11:00:25 krbtgt/BLUE.COM at BLUE.COM renew until 09/17/2014 01:00:20 But after i rebooted the Windows Server Machine, i could not kinit with AD users anymore: [root at ipaserver1 ~]# kinit Yoni at BLUE.COM kinit: Cannot resolve servers for KDC in realm "BLUE.COM" while getting initial I have checked if all the IPA services where UP: [root at ipaserver1 ~]# ipactl status Directory Service: RUNNING krb5kdc Service: RUNNING kadmin Service: RUNNING named Service: RUNNING ipa_memcached Service: RUNNING httpd Service: RUNNING pki-tomcatd Service: RUNNING smb Service: RUNNING winbind Service: RUNNING ipa-otpd Service: RUNNING ipa: INFO: The ipactl command was successful After i restarted IPA services (ipactl restart), i was able to to kinit again. Restarting smb service would do the job as well (?). Just wanted to know if it is a know issue, or the AD should be re discovered if it reboots. I think i seen an issue about it in the mailing list some time ago (not sure). I did not increase the debug level and got the logs. But i can share the ipa and sssd version: rpm -qa | grep ipa ipa-server-3.3.3-28.el7_0.1.x86_64 python-iniparse-0.4-9.el7.noarch libipa_hbac-1.11.2-68.el7_0.5.x86_64 ipa-admintools-3.3.3-28.el7_0.1.x86_64 ipa-server-trust-ad-3.3.3-28.el7_0.1.x86_64 ipa-python-3.3.3-28.el7_0.1.x86_64 sssd-ipa-1.11.2-68.el7_0.5.x86_64 iniparser-3.1-5.el7.x86_64 libipa_hbac-python-1.11.2-68.el7_0.5.x86_64 ipa-client-3.3.3-28.el7_0.1.x86_64 rpm -qa | grep sssd sssd-krb5-common-1.11.2-68.el7_0.5.x86_64 sssd-ldap-1.11.2-68.el7_0.5.x86_64 sssd-common-1.11.2-68.el7_0.5.x86_64 sssd-common-pac-1.11.2-68.el7_0.5.x86_64 sssd-ad-1.11.2-68.el7_0.5.x86_64 sssd-krb5-1.11.2-68.el7_0.5.x86_64 sssd-1.11.2-68.el7_0.5.x86_64 python-sssdconfig-1.11.2-68.el7_0.5.noarch sssd-ipa-1.11.2-68.el7_0.5.x86_64 sssd-proxy-1.11.2-68.el7_0.5.x86_64 sssd-client-1.11.2-68.el7_0.5.x86_64 Thanks for all the helpers. -------------- next part -------------- An HTML attachment was scrubbed... URL: From amessina at messinet.com Mon Sep 15 22:41:16 2014 From: amessina at messinet.com (Anthony Messina) Date: Mon, 15 Sep 2014 17:41:16 -0500 Subject: [Freeipa-users] apache kerberized nfs4 /var/www/html access denied for apache user In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E7267D7@001FSN2MPN1-044.001f.mgd2.msft.net> References: <82E7C9A01FD0764CACDD35D10F5DFB6E7267D7@001FSN2MPN1-044.001f.mgd2.msft.net> Message-ID: <2332392.eAZbh8SOxa@linux-ws1.messinet.com> On Monday, September 15, 2014 06:10:13 PM Nordgren, Bryce L -FS wrote: > How does the NFS server map the apache user to ?something? it recognizes? I > would suggest that the easiest solution may be to use an IPA account called > ?apache?, so that the mappings would just work, but currently I?m having > trouble running a service as a domain user via systemd. > (https://lists.fedorahosted.org/pipermail/sssd-users/2014-September/002194. > html) Regarding your thread on the sssd-users list, this issue has to do with systemd not looking up non-local users (via nss/sssd) as these accounts are not usually available at boot. I had tried something similar using k5start (prior to using gssproxy) and found this out: https://bugzilla.redhat.com/show_bug.cgi?id=915912 > Beyond that, for kerberized NFS (local or domain user), you?ll need > something to keep a fresh ticket on hand, so you may end up running > something like k5start, and setting KRB5CCNAME in the environment where > you?re running apache. I now use gssproxy for this purpose -- maintaining NFS/KRB5 credentials for the "apache" user. But I can tell you that I haven't yet figured out what I need to do to have FreeIPA issue Kerberos credentials for the "apache" user, while restricting the "apache" user in FreeIPA, based on the security concerns mentioned by John Dennis in the following email: https://www.redhat.com/archives/freeipa-users/2013-February/msg00268.html. Not trying to hijack the thread, but it would be helpful to have some instruction on: What is the FreeIPA-recommended way to enable Kerberos functionality for a system account user, while restricting that system-account user? The "apache" user being one that seems to be brought up frequently. -A -- Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery 8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From mkosek at redhat.com Tue Sep 16 06:23:15 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 16 Sep 2014 08:23:15 +0200 Subject: [Freeipa-users] ipa-getcert request problem In-Reply-To: <5416FF3C.2070103@redhat.com> References: <5416FF3C.2070103@redhat.com> Message-ID: <5417D753.30106@redhat.com> On 09/15/2014 05:01 PM, Martin Kosek wrote: > On 09/15/2014 03:31 PM, Natxo Asenjo wrote: >> hi, >> >> Centos 6.5. >> >> I want to create a certificate request for our mysql servers. I came up >> with this command line: >> >> $ sudo /usr/bin/ipa-getcert request -r -f /etc/pki/tls/certs/`hostname >> --fqdn`-mysql.crt -k /etc/pki/tls/private/`hostname --fqdn`-mysql.key -D >> `dnsdomainname` -U id-kp-serverAuth -K mysql/`hostname --fqdn` >> New signing request "20140915132335" added. >> >> But it gets rejected: >> >> Request ID '20140915132335': >> status: CA_REJECTED >> ca-error: Server denied our request, giving up: 2100 (RPC failed at >> server. Insufficient access: You need to be a member of the serviceadmin >> role to add services). >> stuck: yes >> key pair storage: >> type=FILE,location='/etc/pki/tls/private/hostname-mysql.key' >> certificate: >> type=FILE,location='/etc/pki/tls/certs/hostname-mysql.crt' >> CA: IPA >> issuer: >> subject: >> expires: unknown >> pre-save command: >> post-save command: >> track: yes >> auto-renew: yes >> >> I think I have the serviceadmin role: >> >> $ ipa role-show "it specialist" >> Role name: IT Specialist >> Description: IT Specialist >> Member groups: admins >> Privileges: Host Administrators, Host Group Administrators, Service >> Administrators, Automount Administrators >> >> The account is member of group admins. >> >> What am I doing wrong? >> >> Thanks! >> -- >> Groeten, >> natxo >> >> >> > > It seems you hit the same issue as Michael. See my response: > https://www.redhat.com/archives/freeipa-users/2014-September/msg00256.html > > You will need to > > 1) Create host `domainname` > 2) Create services > * mysql/`hostname` > * mysql/`domainname` > 3) Run ipa service-add-host mysql/`domainname` --host mysql/`hostname` > 4) Resubmit certificate > > It looks like we need to do better in documentation&error message... FYI - I filed https://fedorahosted.org/freeipa/ticket/4540 to improve the message. > Oh and > BTW, this only works with FreeIPA 4.0+, details in ticket > https://fedorahosted.org/freeipa/ticket/3977. > > Martin > From rob.verduijn at gmail.com Tue Sep 16 07:12:53 2014 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Tue, 16 Sep 2014 09:12:53 +0200 Subject: [Freeipa-users] apache kerberized nfs4 /var/www/html access denied for apache user In-Reply-To: <2332392.eAZbh8SOxa@linux-ws1.messinet.com> References: <82E7C9A01FD0764CACDD35D10F5DFB6E7267D7@001FSN2MPN1-044.001f.mgd2.msft.net> <2332392.eAZbh8SOxa@linux-ws1.messinet.com> Message-ID: 2014-09-16 0:41 GMT+02:00 Anthony Messina : > On Monday, September 15, 2014 06:10:13 PM Nordgren, Bryce L -FS wrote: > > How does the NFS server map the apache user to ?something? it > recognizes? I > > would suggest that the easiest solution may be to use an IPA account > called > > ?apache?, so that the mappings would just work, but currently I?m having > > trouble running a service as a domain user via systemd. > > ( > https://lists.fedorahosted.org/pipermail/sssd-users/2014-September/002194. > > html) > > Regarding your thread on the sssd-users list, this issue has to do with > systemd not looking up non-local users (via nss/sssd) as these accounts are > not usually available at boot. I had tried something similar using k5start > (prior to using gssproxy) and found this out: > https://bugzilla.redhat.com/show_bug.cgi?id=915912 > > > Beyond that, for kerberized NFS (local or domain user), you?ll need > > something to keep a fresh ticket on hand, so you may end up running > > something like k5start, and setting KRB5CCNAME in the environment where > > you?re running apache. > > I now use gssproxy for this purpose -- maintaining NFS/KRB5 credentials for > the "apache" user. But I can tell you that I haven't yet figured out what > I > need to do to have FreeIPA issue Kerberos credentials for the "apache" > user, > while restricting the "apache" user in FreeIPA, based on the security > concerns > mentioned by John Dennis in the following email: > https://www.redhat.com/archives/freeipa-users/2013-February/msg00268.html. > > Not trying to hijack the thread, but it would be helpful to have some > instruction on: What is the FreeIPA-recommended way to enable Kerberos > functionality for a system account user, while restricting that > system-account > user? The "apache" user being one that seems to be brought up frequently. > > -A > > -- > Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery > 8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > Hello all, It seems after doing some more serious googling I found that using a system-account is problematic when using kerberized nfs4. Like Anthony mentioned it would be nice to have a 'general' howto on how to deal with this situation. Apache trying to use a document root on a kerberized nfs4 share being a very nice use case. btw after I posted this I spend some more time on google and found this old kb article on access.redhat.com com that deals with a kerberized nfs document root for apache: https://access.redhat.com/solutions/56581 I haven't tried it yet cause it feels a bit like a workaround to me and I hoped to find a more elegant solution using ipa, Cheers Rob Verduijn -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Tue Sep 16 07:28:31 2014 From: sbose at redhat.com (Sumit Bose) Date: Tue, 16 Sep 2014 09:28:31 +0200 Subject: [Freeipa-users] AD Trust - Cannot resolve servers for KDC after reboot In-Reply-To: References: Message-ID: <20140916072831.GY2947@localhost.localdomain> On Tue, Sep 16, 2014 at 01:39:41AM +0300, Genadi Postrilko wrote: > Hello all ! > > I have deployed test environment for AD trust feature, the environment > contains : > Windows Server 2008 - AD Server. > RHEL 7 - IPA 3.3 Server. > RHEL 6.2 - IPA Client. > > I have established the trust as IPA in the sub domain of AD. > AD DNS domain - blue.com > IPA DNS domain - linux.blue.com > > All was working fine as i was able to kinit with AD users: > > [root at ipaserver1 ~]# kinit Yoni at BLUE.COM > Password for Yoni at BLUE.COM: > > [root at ipaserver1 ~]# klist > Ticket cache: KEYRING:persistent:0:krb_ccache_oi15FrE > Default principal: Yoni at BLUE.COM > > Valid starting Expires Service principal > 09/16/2014 01:00:25 09/16/2014 11:00:25 krbtgt/BLUE.COM at BLUE.COM > renew until 09/17/2014 01:00:20 > > But after i rebooted the Windows Server Machine, i could not kinit with AD > users anymore: > [root at ipaserver1 ~]# kinit Yoni at BLUE.COM > kinit: Cannot resolve servers for KDC in realm "BLUE.COM" while getting > initial The only IPA component used for kinit is the DNS server. How did you configure DNS (glue records? forwarder?). To get more details about what is failing you can call: KRB5_TRACE=/dev/stdout kinit Yoni at BLUE.COM HTH bye, Sumit > > I have checked if all the IPA services where UP: > > [root at ipaserver1 ~]# ipactl status > Directory Service: RUNNING > krb5kdc Service: RUNNING > kadmin Service: RUNNING > named Service: RUNNING > ipa_memcached Service: RUNNING > httpd Service: RUNNING > pki-tomcatd Service: RUNNING > smb Service: RUNNING > winbind Service: RUNNING > ipa-otpd Service: RUNNING > ipa: INFO: The ipactl command was successful > > After i restarted IPA services (ipactl restart), i was able to to kinit > again. > Restarting smb service would do the job as well (?). > > Just wanted to know if it is a know issue, or the AD should be re > discovered if it reboots. > I think i seen an issue about it in the mailing list some time ago (not > sure). > > I did not increase the debug level and got the logs. > But i can share the ipa and sssd version: > > rpm -qa | grep ipa > ipa-server-3.3.3-28.el7_0.1.x86_64 > python-iniparse-0.4-9.el7.noarch > libipa_hbac-1.11.2-68.el7_0.5.x86_64 > ipa-admintools-3.3.3-28.el7_0.1.x86_64 > ipa-server-trust-ad-3.3.3-28.el7_0.1.x86_64 > ipa-python-3.3.3-28.el7_0.1.x86_64 > sssd-ipa-1.11.2-68.el7_0.5.x86_64 > iniparser-3.1-5.el7.x86_64 > libipa_hbac-python-1.11.2-68.el7_0.5.x86_64 > ipa-client-3.3.3-28.el7_0.1.x86_64 > > rpm -qa | grep sssd > sssd-krb5-common-1.11.2-68.el7_0.5.x86_64 > sssd-ldap-1.11.2-68.el7_0.5.x86_64 > sssd-common-1.11.2-68.el7_0.5.x86_64 > sssd-common-pac-1.11.2-68.el7_0.5.x86_64 > sssd-ad-1.11.2-68.el7_0.5.x86_64 > sssd-krb5-1.11.2-68.el7_0.5.x86_64 > sssd-1.11.2-68.el7_0.5.x86_64 > python-sssdconfig-1.11.2-68.el7_0.5.noarch > sssd-ipa-1.11.2-68.el7_0.5.x86_64 > sssd-proxy-1.11.2-68.el7_0.5.x86_64 > sssd-client-1.11.2-68.el7_0.5.x86_64 > > Thanks for all the helpers. > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project From passmossis at gmail.com Tue Sep 16 12:44:46 2014 From: passmossis at gmail.com (Eric Hart) Date: Tue, 16 Sep 2014 08:44:46 -0400 Subject: [Freeipa-users] IPA Version 3.0.0 Allow Self-Signed Certificates In-Reply-To: <5412EA0F.8030405@redhat.com> References: <5412EA0F.8030405@redhat.com> Message-ID: Hey Martin, I have FreeIPA currently operating with a self-signed certificate and my linux clients operating with FreeIPA do not have any issues. What I'm attempting to do is integrate a ZFS appliance in with the IPA server for LDAP services. I have examined the exchange between the ZFS appliance and the IPA server and the issue appeared to be related to the ZFS appliance providing a self-signed certificate, though I may be wrong in the nature of the failure. I'll re-create the exchange and capture the message and put it in-line of this messaging. V/r, Eric On Fri, Sep 12, 2014 at 8:41 AM, Martin Kosek wrote: > On 09/09/2014 06:01 PM, Eric Hart wrote: > >> I'm trying to find a way to enable FreeIPA to allow Self-Signed >> Certificates. >> I haven't found a way to enable that capability yet.. >> >> I've manually edited configuration files within >> /etc/dirsrv/slapd-EXAMPLE-COM, >> specifically the nsslapd-ssl-check-hostname, nsslapd-validate-cert >> options set >> to off and warn respectively. >> >> Not allowing self-signed certificates has caused me to not be able to >> establish >> a replicated server or integrate a device for SSO that provides a self >> signed >> certificate. >> >> Thanks for any input or insight, >> Eric >> > > I do not entirely understand the use case. So you want to run FreeIPA > without CA, with httpd+dirsrv running with self-signed certificates or you > want FreeIPA CA to issue a self signed certificate for your service (which > does not make much sense to me)? > > BTW relevant training material: > http://www.freeipa.org/images/b/b3/FreeIPA33-blending-in-a- > certificate-infrastructure.pdf > > HTH, > Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Tue Sep 16 14:25:53 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 16 Sep 2014 10:25:53 -0400 Subject: [Freeipa-users] =?utf-8?q?FreeIPA_ActiveDire=E2=80=8Bctory_Integr?= =?utf-8?q?atio=E2=80=8Bn=3A_Managing_AD_Users_in_IPA?= In-Reply-To: References: <5414CFDA.9090904@redhat.com> Message-ID: <54184871.6050302@redhat.com> On 09/14/2014 03:42 AM, Gregor Bregenzer wrote: > 2014-09-14 1:14 GMT+02:00 Dmitri Pal : >> On 09/13/2014 05:27 PM, Gregor Bregenzer wrote: >>> Hi! >>> >>> There are two ways that you can use to integrate FreeIPA with AD: a.) >>> trust b.) synchronization Here are the pros/cons for both of them: >>> http://www.freeipa.org/docs/master/html-desktop/index.html#trust-sync >>> >>> If you want to manage POSIX attributes for each user can do that with >>> either identity management for Unix at AD using the trust, or with the >>> synchronzation at FreeIPA. With synchronization you see the users to >>> in FreeIPA, but still have to two users to manage - in FreeIPA and AD. >>> With the AD trust the sssd daemon running on FreeIPA is proxying all >>> request from the client sssd directly to AD >> This is not exactly true. SSSD understands that IPA and AD are in trust >> relations. If you use user name and password to login SSSD will turn to AD >> directly without sending password over the wire. If you SSO into the linux >> box the kerberos library (on you windows client) will do all the ticket >> acquisition and redirects. >> >> The proxy is already done for older clients that does not understand that >> IPA is in trust relations with AD. >> http://www.freeipa.org/images/2/2e/FreeIPA33-trust.pdf >> > Sorry, there are two things i did not mention a.) no SSO, b.) Linux > Client SSSD requesting UID/GID. > > a.) if you ssh login from a Windows client that is _not_ joined in AD > or a standalone Linux box - so no SSO. Because there the destination > Linux clients with sssd (1.9.2 with AD trust compatibilty with ipa > provider, or 1.11+ with full AD trust capability) still need SSSD on > the FreeIPA Server that will forward the authentication requests to > AD. In slide 30 of > http://www.freeipa.org/images/2/2e/FreeIPA33-trust.pdf it states: > > "SSSD is used behind the scenes on the FreeIPA server > to lookup up users in trusted AD domains > SSSD on FreeIPA clients will forward resolution requests > to FreeIPA servers through FreeIPA LDAP server plugin" > > b.) If you have a client that is authenticating using Kerberos and > therefore SSO, the destination Linux sssd client still needs the sssd > client on the FreeIPA server to lookup the UID/GID. So there's the > authentication process either with SSO or without SSO, and there's the > lookup process for the attributes - am i correct? If the client is new i.e. 1.9+ it will know ho to use trusts and will support UID/GID coming from AD. These clients should be joined to IPA. Other older clients need to be handled following the guidelines re legacy clients. See below. > >>> , so you see no users in >>> FreeIPA, but you have to extend the AD schema using Identity >>> Management for unix. >> >> You really have two options: let SSSD to map users dynamically, in this case >> you do not need AD schema extensions or you can extend schema as suggested. >> The third option that is under development is described in my other reply. > What happens if you have already defined the UID/GID with the schema > extension on AD and have legacy Linux clients using them, but you > still want to use the exact UID/GID _and_ make use of all the great > features offered in FreeIPA such as HBAC, sudorules, etc.? Then only > the AD Trust with SSSD 1.11+ with full AD trust feature set is working > - correct (because 1.9.2 with ipa provider cannot get the GID from > AD)? SSSD 1.9 should work ok with IPA in trust relations. Earlier versions or other clients should be pointed to the IPA compat tree. http://www.freeipa.org/images/0/0d/FreeIPA33-legacy-clients.pdf Then you get exactly what you are looking for. >>> Also the password policy from the group policy in >>> AD is used when you use the AD trust, but on clients with sssd you can >>> change the password using kpasswd from Kerberos. If you want to use a >>> trust with AD and want to receive the correct GID set in AD then you >>> have to use sssd >1.9.x, otherwise you get a different GID (see >>> >>> https://www.redhat.com/archives/freeipa-users/2014-September/msg00192.html) >>> >>> All other stuff such as HBAC etc. can be centrally managed on FreeIPA, >>> no matter if you use a trust or synchronzation. >>> >>> Gregor >>> >>> 2014-09-13 22:03 GMT+02:00 Traiano Welcome : >>>> Hi List >>>> >>>> Currently I have a stable trust relationship going between IPA and >>>> Windows >>>> AD. I create users and manage passwords in AD, but want to manage the >>>> rest >>>> in IPA, "the rest" being default shell, default home directory settings, >>>> RBAC, HBAC, Selinux etc .. >>>> >>>> What I'm expecting it to be able to log into the FreeIPA web interface, >>>> and >>>> see a synched list of users created in AD appear in the interface, after >>>> which I can modify the settings on a per user basis. >>>> >>>> If that level of granularity is not possible, I would then expect to be >>>> able >>>> to at least apply an IPA-imposed set of account defaults on and AD user >>>> group: >>>> >>>> - default shell >>>> - HBAC rules >>>> - Sudo rules >>>> - SELinux rules >>>> - RBAC >>>> >>>> Is this possible with FreeIPA? I can't find anything coherent in the >>>> documentation that describes an effective way of managing the POSIX >>>> attributes of AD users in FreeIPA. >>>> >>>> Thanks in advance! >>>> Traiano >>>> >>>> >>>> >>>> >>>> -- >>>> Manage your subscription for the Freeipa-users mailing list: >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>> Go To http://freeipa.org for more info on the project >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go To http://freeipa.org for more info on the project -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From GregScott at infrasupport.com Tue Sep 16 14:28:54 2014 From: GregScott at infrasupport.com (Greg Scott) Date: Tue, 16 Sep 2014 14:28:54 +0000 Subject: [Freeipa-users] Two way A/D trust versus one way trust Message-ID: <0816e253e8d44bddb986e0e70bce13d1@mail2013.infrasupport.local> Hello - I went through this thread: https://www.redhat.com/archives/freeipa-users/2014-January/msg00177.html but I have some more questions. I have another situation where I need a one way AD trust. We have an IPA domain with a bunch of Linux servers and an AD domain for the corporate network. Typical scenario. We want IPA to trust AD but do not want AD to trust IPA. Access is availalbe to administrator/root accounts in both the AD and IPA domains. The IPA server is RHEL 7 running the IPA bundled with RHEL - I think that's IPA 3.3.5 right now? Reading through the thread above, when we set up cross forest trusts with this version, the IPA side does not yet have the equivalent of a Windows Global Catalog. So even though it says it's a 2-way trust, it's really not because IPA has no way to store the global catalog copies of what it needs for Windows to trust IPA. So with the version right now as it exists today, de-facto, IPA trusts AD, but AD has no way to trust IPA yet because IPA doesn't have all the pieces in place. So far so good. Here is the challenge. The AD group at this site is concerned that with some future version of IPA, since Windows already "thinks" it trusts IPA, that IPA will get the correct components and that suddenly IPA users will be able to authenticate in the AD domain. Ideally, they would like to set up an official one way trust today so that future possibility never happens. If that isn't possible, what other steps could they take to guard against that future possibility? Quoting from the earlier thread: > global catalog support is being worked on. As soon as it is implemented we will add more > granularity to the way the trusts are established and thus allow formal one way trusts Is there a time frame for this? I know it's tough to give completion dates and that's not what I'm asking for - just a feel for how active the development is around global catalog support. Is this something this site should expect in the next few months or is it 5+ years away or somewhere in the middle? Is there a projected version number where the support will land? Given what we have in place today, what is the best way to handle the situation where a site wants a one way trust but must set up a 2-way trust now with only one side of the trust functional? I suppose it is always possible in the future when all the pieces are in place to just destroy the 2 way trust and re-create a one way trust, but by that time, there will probably be lots of mapping between AD SIDs and Linux UID/GID pairs and destroying and recreating the trust could make a royal mess out of those. Would it be possible to modify an existing 2-way trust to only be a one-way trust when the time comes? Thanks - Greg From abokovoy at redhat.com Tue Sep 16 14:46:32 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 16 Sep 2014 17:46:32 +0300 Subject: [Freeipa-users] Two way A/D trust versus one way trust In-Reply-To: <0816e253e8d44bddb986e0e70bce13d1@mail2013.infrasupport.local> References: <0816e253e8d44bddb986e0e70bce13d1@mail2013.infrasupport.local> Message-ID: <20140916144632.GU2541@redhat.com> On Tue, 16 Sep 2014, Greg Scott wrote: >Hello - > >I went through this thread: >https://www.redhat.com/archives/freeipa-users/2014-January/msg00177.html > >but I have some more questions. > >I have another situation where I need a one way AD trust. We have an >IPA domain with a bunch of Linux servers and an AD domain for the >corporate network. Typical scenario. We want IPA to trust AD but do >not want AD to trust IPA. Access is availalbe to administrator/root >accounts in both the AD and IPA domains. > >The IPA server is RHEL 7 running the IPA bundled with RHEL - I think >that's IPA 3.3.5 right now? > >Reading through the thread above, when we set up cross forest trusts >with this version, the IPA side does not yet have the equivalent of a >Windows Global Catalog. So even though it says it's a 2-way trust, >it's really not because IPA has no way to store the global catalog >copies of what it needs for Windows to trust IPA. So with the version >right now as it exists today, de-facto, IPA trusts AD, but AD has no >way to trust IPA yet because IPA doesn't have all the pieces in place. > >So far so good. Here is the challenge. > >The AD group at this site is concerned that with some future version of >IPA, since Windows already "thinks" it trusts IPA, that IPA will get >the correct components and that suddenly IPA users will be able to >authenticate in the AD domain. Ideally, they would like to set up an >official one way trust today so that future possibility never happens. >If that isn't possible, what other steps could they take to guard >against that future possibility? Even when IPA implement GC support, nothing will change: by default any user that has no explicit permission in ACLs, gets what is given to all authenticated users, i.e. default read access. When GC is there all that will change is that there will be ability to resolve IPA users on AD side, thus allowing AD users to assign specific permissions to IPA users. > >Quoting from the earlier thread: > >> global catalog support is being worked on. As soon as it is >> implemented we will add more granularity to the way the trusts are >> established and thus allow formal one way trusts > >Is there a time frame for this? I know it's tough to give completion >dates and that's not what I'm asking for - just a feel for how active >the development is around global catalog support. Is this something >this site should expect in the next few months or is it 5+ years away >or somewhere in the middle? Is there a projected version number where >the support will land? I have plans to move to one-way trusts in 4.3 or so, given the time to implement necessary code changes. They are independent of GC support which may or may not come at same time. > >Given what we have in place today, what is the best way to handle the >situation where a site wants a one way trust but must set up a 2-way >trust now with only one side of the trust functional? I suppose it is >always possible in the future when all the pieces are in place to just >destroy the 2 way trust and re-create a one way trust, but by that >time, there will probably be lots of mapping between AD SIDs and Linux >UID/GID pairs and destroying and recreating the trust could make a >royal mess out of those. Would it be possible to modify an existing >2-way trust to only be a one-way trust when the time comes? id ranges is what matters here and we don't destroy ID ranges when you remove the trust. You can re-initiate the trust at that point without breaking ID mapping. -- / Alexander Bokovoy From renier.gertzen at adcock.com Tue Sep 16 14:52:56 2014 From: renier.gertzen at adcock.com (Renier Gertzen) Date: Tue, 16 Sep 2014 14:52:56 +0000 Subject: [Freeipa-users] Master and Replica out of sync Message-ID: Hi, I am in a situation where my Master IPA and Replica IPA servers are out of sync. How do I force the two server to exchange information? Regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From GregScott at infrasupport.com Tue Sep 16 15:39:38 2014 From: GregScott at infrasupport.com (Greg Scott) Date: Tue, 16 Sep 2014 15:39:38 +0000 Subject: [Freeipa-users] Two way A/D trust versus one way trust In-Reply-To: <20140916144632.GU2541@redhat.com> References: <0816e253e8d44bddb986e0e70bce13d1@mail2013.infrasupport.local> <20140916144632.GU2541@redhat.com> Message-ID: <9cc55575482641a0a04a9317b5ba405f@mail2013.infrasupport.local> > Even when IPA implement GC support, nothing will change: by default any user that has no explicit > permission in ACLs, gets what is given to all authenticated users, i.e. default read access. When GC > is there all that will change is that there will be ability to resolve IPA users on AD side, thus allowing > AD users to assign specific permissions to IPA users. Agreed. That's close to word for word what I told them. However, the perception that Windows AD trusts Linux IPA scares them, even though Windows admins still have total control over who can see what in their environment. It's all perception because Linux is foreign and Windows is well known on that side of the fence. Something to keep in mind when you build it. Perception drives lots of decisions and they're not always rational. Meantime, I can probably find some Microsoft documentation about what trusts really mean that might make them more comfortable. - Greg From abokovoy at redhat.com Tue Sep 16 15:49:52 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 16 Sep 2014 18:49:52 +0300 Subject: [Freeipa-users] Two way A/D trust versus one way trust In-Reply-To: <9cc55575482641a0a04a9317b5ba405f@mail2013.infrasupport.local> References: <0816e253e8d44bddb986e0e70bce13d1@mail2013.infrasupport.local> <20140916144632.GU2541@redhat.com> <9cc55575482641a0a04a9317b5ba405f@mail2013.infrasupport.local> Message-ID: <20140916154952.GW2541@redhat.com> On Tue, 16 Sep 2014, Greg Scott wrote: >> Even when IPA implement GC support, nothing will change: by default any user that has no explicit >> permission in ACLs, gets what is given to all authenticated users, i.e. default read access. When GC >> is there all that will change is that there will be ability to resolve IPA users on AD side, thus allowing >> AD users to assign specific permissions to IPA users. > >Agreed. That's close to word for word what I told them. However, the >perception that Windows AD trusts Linux IPA scares them, even though >Windows admins still have total control over who can see what in their >environment. It's all perception because Linux is foreign and Windows >is well known on that side of the fence. Something to keep in mind >when you build it. Perception drives lots of decisions and they're not >always rational. Meantime, I can probably find some Microsoft >documentation about what trusts really mean that might make them more >comfortable. My experience shows that many (by large, unfortunately) Windows administrators have scarce technical knowledge of how things actually work behind the scenes and facades of Windows UIs. You are absolutely spot on with the perception thing. On a brighter note, Microsoft protocol documentation team does wonderful job of maintaining specifications for AD protocols. There are occasional issues which require clarifications but collaboration with Samba Team over past seven years is tremendous. -- / Alexander Bokovoy From simo at redhat.com Tue Sep 16 15:58:46 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 16 Sep 2014 11:58:46 -0400 Subject: [Freeipa-users] apache kerberized nfs4 /var/www/html access denied for apache user In-Reply-To: References: <82E7C9A01FD0764CACDD35D10F5DFB6E7267D7@001FSN2MPN1-044.001f.mgd2.msft.net> <2332392.eAZbh8SOxa@linux-ws1.messinet.com> Message-ID: <20140916115846.6cf53fe8@willson.usersys.redhat.com> On Tue, 16 Sep 2014 09:12:53 +0200 Rob Verduijn wrote: > 2014-09-16 0:41 GMT+02:00 Anthony Messina : > > > On Monday, September 15, 2014 06:10:13 PM Nordgren, Bryce L -FS > > wrote: > > > How does the NFS server map the apache user to ?something? it > > recognizes? I > > > would suggest that the easiest solution may be to use an IPA > > > account > > called > > > ?apache?, so that the mappings would just work, but currently I?m > > > having trouble running a service as a domain user via systemd. > > > ( > > https://lists.fedorahosted.org/pipermail/sssd-users/2014-September/002194. > > > html) > > > > Regarding your thread on the sssd-users list, this issue has to do > > with systemd not looking up non-local users (via nss/sssd) as these > > accounts are not usually available at boot. I had tried something > > similar using k5start (prior to using gssproxy) and found this out: > > https://bugzilla.redhat.com/show_bug.cgi?id=915912 > > > > > Beyond that, for kerberized NFS (local or domain user), you?ll > > > need something to keep a fresh ticket on hand, so you may end up > > > running something like k5start, and setting KRB5CCNAME in the > > > environment where you?re running apache. > > > > I now use gssproxy for this purpose -- maintaining NFS/KRB5 > > credentials for the "apache" user. But I can tell you that I > > haven't yet figured out what I > > need to do to have FreeIPA issue Kerberos credentials for the > > "apache" user, > > while restricting the "apache" user in FreeIPA, based on the > > security concerns > > mentioned by John Dennis in the following email: > > https://www.redhat.com/archives/freeipa-users/2013-February/msg00268.html. > > > > Not trying to hijack the thread, but it would be helpful to have > > some instruction on: What is the FreeIPA-recommended way to enable > > Kerberos functionality for a system account user, while restricting > > that system-account > > user? The "apache" user being one that seems to be brought up > > frequently. > > > > -A > > > > -- > > Anthony - https://messinet.com/ - > > https://messinet.com/~amessina/gallery 8F89 5E72 8DF0 BCF0 10BE > > 9967 92DC 35DC B001 4A4E > > > > -- > > Manage your subscription for the Freeipa-users mailing list: > > https://www.redhat.com/mailman/listinfo/freeipa-users > > Go To http://freeipa.org for more info on the project > > > > Hello all, > > It seems after doing some more serious googling I found that using a > system-account is problematic when using kerberized nfs4. > > Like Anthony mentioned it would be nice to have a 'general' howto on > how to deal with this situation. > > Apache trying to use a document root on a kerberized nfs4 share being > a very nice use case. > > btw after I posted this I spend some more time on google and found > this old kb article on access.redhat.com com that deals with a > kerberized nfs document root for apache: > https://access.redhat.com/solutions/56581 > I haven't tried it yet cause it feels a bit like a workaround to me > and I hoped to find a more elegant solution using ipa, You will need some credentials for the apache process, but do not use host or nfs as shown in that aging article. The solution we've been working on for quite a while is called gss-proxy which interopsed to rpc.gssd can allow you to configure specific keytabs to be used to obtain credentials for unattended service. Unfortunately we are still in the process of writing documentation but here is the project page for reference: https://fedorahosted.org/gss-proxy/ Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Tue Sep 16 16:10:31 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 16 Sep 2014 12:10:31 -0400 Subject: [Freeipa-users] apache kerberized nfs4 /var/www/html access denied for apache user In-Reply-To: <20140916115846.6cf53fe8@willson.usersys.redhat.com> References: <82E7C9A01FD0764CACDD35D10F5DFB6E7267D7@001FSN2MPN1-044.001f.mgd2.msft.net> <2332392.eAZbh8SOxa@linux-ws1.messinet.com> <20140916115846.6cf53fe8@willson.usersys.redhat.com> Message-ID: <541860F7.1090602@redhat.com> On 09/16/2014 11:58 AM, Simo Sorce wrote: > On Tue, 16 Sep 2014 09:12:53 +0200 > Rob Verduijn wrote: > >> 2014-09-16 0:41 GMT+02:00 Anthony Messina : >> >>> On Monday, September 15, 2014 06:10:13 PM Nordgren, Bryce L -FS >>> wrote: >>>> How does the NFS server map the apache user to ?something? it >>> recognizes? I >>>> would suggest that the easiest solution may be to use an IPA >>>> account >>> called >>>> ?apache?, so that the mappings would just work, but currently I?m >>>> having trouble running a service as a domain user via systemd. >>>> ( >>> https://lists.fedorahosted.org/pipermail/sssd-users/2014-September/002194. >>>> html) >>> Regarding your thread on the sssd-users list, this issue has to do >>> with systemd not looking up non-local users (via nss/sssd) as these >>> accounts are not usually available at boot. I had tried something >>> similar using k5start (prior to using gssproxy) and found this out: >>> https://bugzilla.redhat.com/show_bug.cgi?id=915912 >>> >>>> Beyond that, for kerberized NFS (local or domain user), you?ll >>>> need something to keep a fresh ticket on hand, so you may end up >>>> running something like k5start, and setting KRB5CCNAME in the >>>> environment where you?re running apache. >>> I now use gssproxy for this purpose -- maintaining NFS/KRB5 >>> credentials for the "apache" user. But I can tell you that I >>> haven't yet figured out what I >>> need to do to have FreeIPA issue Kerberos credentials for the >>> "apache" user, >>> while restricting the "apache" user in FreeIPA, based on the >>> security concerns >>> mentioned by John Dennis in the following email: >>> https://www.redhat.com/archives/freeipa-users/2013-February/msg00268.html. >>> >>> Not trying to hijack the thread, but it would be helpful to have >>> some instruction on: What is the FreeIPA-recommended way to enable >>> Kerberos functionality for a system account user, while restricting >>> that system-account >>> user? The "apache" user being one that seems to be brought up >>> frequently. >>> >>> -A >>> >>> -- >>> Anthony - https://messinet.com/ - >>> https://messinet.com/~amessina/gallery 8F89 5E72 8DF0 BCF0 10BE >>> 9967 92DC 35DC B001 4A4E >>> >>> -- >>> Manage your subscription for the Freeipa-users mailing list: >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> Go To http://freeipa.org for more info on the project >>> >> Hello all, >> >> It seems after doing some more serious googling I found that using a >> system-account is problematic when using kerberized nfs4. >> >> Like Anthony mentioned it would be nice to have a 'general' howto on >> how to deal with this situation. >> >> Apache trying to use a document root on a kerberized nfs4 share being >> a very nice use case. >> >> btw after I posted this I spend some more time on google and found >> this old kb article on access.redhat.com com that deals with a >> kerberized nfs document root for apache: >> https://access.redhat.com/solutions/56581 >> I haven't tried it yet cause it feels a bit like a workaround to me >> and I hoped to find a more elegant solution using ipa, > You will need some credentials for the apache process, but do not use > host or nfs as shown in that aging article. > > The solution we've been working on for quite a while is called > gss-proxy which interopsed to rpc.gssd can allow you to configure > specific keytabs to be used to obtain credentials for unattended > service. > > Unfortunately we are still in the process of writing documentation but > here is the project page for reference: > https://fedorahosted.org/gss-proxy/ > > Simo. > Also opened https://fedorahosted.org/freeipa/ticket/4544 -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Tue Sep 16 16:13:07 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 16 Sep 2014 12:13:07 -0400 Subject: [Freeipa-users] Two way A/D trust versus one way trust In-Reply-To: <20140916154952.GW2541@redhat.com> References: <0816e253e8d44bddb986e0e70bce13d1@mail2013.infrasupport.local> <20140916144632.GU2541@redhat.com> <9cc55575482641a0a04a9317b5ba405f@mail2013.infrasupport.local> <20140916154952.GW2541@redhat.com> Message-ID: <54186193.5090109@redhat.com> On 09/16/2014 11:49 AM, Alexander Bokovoy wrote: > On Tue, 16 Sep 2014, Greg Scott wrote: >>> Even when IPA implement GC support, nothing will change: by default >>> any user that has no explicit >>> permission in ACLs, gets what is given to all authenticated users, >>> i.e. default read access. When GC >>> is there all that will change is that there will be ability to >>> resolve IPA users on AD side, thus allowing >>> AD users to assign specific permissions to IPA users. >> >> Agreed. That's close to word for word what I told them. However, the >> perception that Windows AD trusts Linux IPA scares them, even though >> Windows admins still have total control over who can see what in their >> environment. It's all perception because Linux is foreign and Windows >> is well known on that side of the fence. Something to keep in mind >> when you build it. Perception drives lots of decisions and they're not >> always rational. Meantime, I can probably find some Microsoft >> documentation about what trusts really mean that might make them more >> comfortable. > My experience shows that many (by large, unfortunately) Windows > administrators have scarce technical knowledge of how things > actually work behind the scenes and facades of Windows UIs. > > You are absolutely spot on with the perception thing. > > On a brighter note, Microsoft protocol documentation team does wonderful > job of maintaining specifications for AD protocols. There are occasional > issues which require clarifications but collaboration with Samba Team > over past seven years is tremendous. > http://technet.microsoft.com/en-us/library/cc773178%28v=ws.10%29.aspx -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From walid.shaari at gmail.com Tue Sep 16 16:40:03 2014 From: walid.shaari at gmail.com (Walid) Date: Tue, 16 Sep 2014 19:40:03 +0300 Subject: [Freeipa-users] Certs. In-Reply-To: <5410E664.6080602@redhat.com> References: <5410D5C3.7020805@cenic.org> <5410DE09.4050700@cenic.org> <5410E384.4070703@redhat.com> <5410E57C.5030204@cenic.org> <5410E664.6080602@redhat.com> Message-ID: Hi Dmitri, I am interested in the renewal process, how would that happen for clients, and when would it happen? On 11 September 2014 03:01, Dmitri Pal wrote: > On 09/10/2014 07:57 PM, William Graboyes wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> Hi Dmitri, >> >> Production Environment is going to be RH 6.5, We are still evaluating >> the usage of systemd. More like we are taking a wait and see approach >> to to systemd, while actively testing it. >> > The command line options for chaining are there from day one. > So you would need to chain your production environment when you deploy it. > In future when you migrate to later versions (in couple of years or so) > you will be able to change the chaining using the new tools. Right now it > is a vary hard multi step manual procedure. This is why we developed the > tool. > But you should be all set for now. You would not need to change anything > for several years. > > Thanks > Dmitri > > > > Thanks, >> Bill >> >> On Wed Sep 10 16:49:24 2014, Dmitri Pal wrote: >> >>> On 09/10/2014 07:26 PM, William Graboyes wrote: >>> >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA512 >>>> >>>> Hi Chris, >>>> >>>> Thank you for the suggestion. Looking at >>>> http://www.redhat.com/archives/freeipa-users/2014-August/msg00334.html >>>> >>>> Installing a new, third party cert requires a reinstall of IPA? IPA >>>> Devs, that is a bit silly don't you think? A year or two in the cert >>>> expires, now you have to start from scratch? I will wait for some form >>>> of response before I attempt at eating crow in front of management. >>>> >>>> I forgot to mention, free-ipa version ipa-server-3.0.0-37.el6.x86_64. >>>> >>> Since 3.0 internal certs are issued for 2 years and are renewed >>> automatically. The root cert is valid for more than two years (AFAIR >>> it is 20). >>> >>> >>> >>> >>>> >>>> On Wed Sep 10 15:55:56 2014, Chris Whittle wrote: >>>> >>>>> Search the list for a post by me and certs... Basically there is a >>>>> install >>>>> flag that will do all the work for you once you have it the cert in the >>>>> right format. >>>>> On Sep 10, 2014 5:53 PM, "William Graboyes" >>>>> wrote: >>>>> >>>>> ********* *BEGIN ENCRYPTED or SIGNED PART* ********* >>>>> >>>>> Hello list, >>>>> >>>>> I have been fruitlessly searching for some information, especially >>>>> related to Certs, namely how to replace the self signed certs with >>>>> certs from a trusted CA? As we are moving forward into >>>>> productionizing of our free-ipa install, I am finding information on >>>>> the net to be a bit lacking. There is also the possibility that I am >>>>> not looking in the right places, or using the correct search terms. >>>>> Any help on this front would be greatly appreciated. >>>>> >>>>> Thanks, >>>>> Bill >>>>> >>>>> >>>>> ********** *END ENCRYPTED or SIGNED PART* ********** >>>>> >>>>> -- >>>>>> Manage your subscription for the Freeipa-users mailing list: >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>> Go To http://freeipa.org for more info on the project >>>>>> >>>>>> >>>>> -----BEGIN PGP SIGNATURE----- >>>> Version: GnuPG/MacGPG2 v2.0.22 (Darwin) >>>> Comment: GPGTools - https://gpgtools.org >>>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >>>> >>>> iQIcBAEBCgAGBQJUEN4JAAoJEJFMz73A1+zrjNAP/1aZOjhp6c6JwWXUjBE4Pt4i >>>> u6Z1BRFNYgIc5/aNsPAKrdzMqQgTjgWJvSh5UCON0VdmuIx7pQLP7nIlaCCXTRRK >>>> pKx2Cez5Ho7Lwlsb87WW3bzjcyKGX5Wd3+VJdQ6ugYJTpVS4gMxh8atZCV613EY6 >>>> FuMk1RS6qlWM2Ut3SjmaAZK3jTw2pUsJzW3zzB271i6sJqAMZTh7Lrie6QcGqAON >>>> eLGlWBZuCaeULUuQmArVZiP3qPnH5NuccvXLFVbX7D1+SM8XeLWrTklN1bfX2HF0 >>>> QCFlizb+bBga/d5cEaCv7R8v6m46R4wS779KSUV1jn9PpHISNcmLafv6dTAb6F+5 >>>> RBADwBP6coh5LrOJJh0pIByx9dYRbdif/BSH4VMcvfvFMs/EO1PAsGLWQPwoNfYO >>>> 0SzUV1R47JW9NGzeTxja+byKz9hwGtAT2FIw0NibR+M1FydPD9k3LTjTnQWgeSro >>>> ks3AUPDy/hj+E72QDORj+/Zvy3sw8wDFVRw2LH/jaDmWbWhZUG4riC3w2egPjcSK >>>> KIYQ7L/fdeN6S9jt8UcUf1YDHgfLU+iTgqyssr54RufVuM9iBNOkoWxxI0Q9oyMF >>>> NDKiOY8rs2rBu6x09NiHG0BoX1LQzrrKQFQ4ao48w2RH3ocFCgQbsEHZ18uIfo4Y >>>> CB5M63nykETHkkR3ZFkd >>>> =8T1Y >>>> -----END PGP SIGNATURE----- >>>> >>>> >>> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG/MacGPG2 v2.0.22 (Darwin) >> Comment: GPGTools - https://gpgtools.org >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >> >> iQIcBAEBCgAGBQJUEOV8AAoJEJFMz73A1+zrgwAQAJkx74MPOVvbnrG+dmY8w7ok >> J/6NWt9Rb/pS9gRrN7iFopni3BoHuLFC6ltwD6KoWllYClwoXke4T0FQ/nU6Ar6M >> tsuQMYxP0boxhQua2uF/kZ/atMolxoNMShNixXd4dnWtBlpl+R+V58FtfjSGfy49 >> qX2Ge6g6wEFATwKReM1KpKCFIfO/yq/wM4NLvvBd6WShJXh6TQBE44y9aXLLJIlP >> DApoLnMHaopNZITSNKt1t7dgw6ne9O370nQwOxR5L0peH8bxla0FLJ57vX+RCC0f >> 3EV/tQHKiXET1RqWE927tfPf171Xcq7sdjLRUL2JTVCK3zPZUuVg9WmuqrLUArhW >> f1XRpn1MM2e0xn18rvHfuRZr2IIUuPE+RfVcQMgEcgtSYuDNlVYCO/ONyTQHxJ/E >> JRkN6nDOZ1nlItJlrrT0MVgdMKQLG7IxkvOndGsyOShD/XvvjQYlQbDvRvodnAlc >> JUIlcC3PbGZh+CRymXzu6M7DYceE5rJ/HzbR1UAPM/dep1P6zA3WyTS15tzIJ93f >> pjLYTciDvPbTOfRTV+1PQvvVDbHZve34wcjGZHaqV35qUQwXcd/DQK18L8S7EmDx >> BeBmii/cX2qBSyzDNGgSjtBTh0AT67tpJQPnH7brsVc9S75+E/MyDqXZjqiJv/9N >> i22XgsD/iTzkP3o0OTjs >> =FKVl >> -----END PGP SIGNATURE----- >> >> > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Sep 16 17:13:53 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 16 Sep 2014 13:13:53 -0400 Subject: [Freeipa-users] Certs. In-Reply-To: References: <5410D5C3.7020805@cenic.org> <5410DE09.4050700@cenic.org> <5410E384.4070703@redhat.com> <5410E57C.5030204@cenic.org> <5410E664.6080602@redhat.com> Message-ID: <54186FD1.8030908@redhat.com> Walid wrote: > Hi Dmitri, > > I am interested in the renewal process, how would that happen for > clients, and when would it happen? It depends on what scenario you're talking about (self-signed IPA cert, IPA as subordinate, user-provided certificates), and what certs you mean. rob > > On 11 September 2014 03:01, Dmitri Pal > wrote: > > On 09/10/2014 07:57 PM, William Graboyes wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hi Dmitri, > > Production Environment is going to be RH 6.5, We are still > evaluating > the usage of systemd. More like we are taking a wait and see > approach > to to systemd, while actively testing it. > > The command line options for chaining are there from day one. > So you would need to chain your production environment when you > deploy it. > In future when you migrate to later versions (in couple of years or > so) you will be able to change the chaining using the new tools. > Right now it is a vary hard multi step manual procedure. This is why > we developed the tool. > But you should be all set for now. You would not need to change > anything for several years. > > Thanks > Dmitri > > > > Thanks, > Bill > > On Wed Sep 10 16:49:24 2014, Dmitri Pal wrote: > > On 09/10/2014 07:26 PM, William Graboyes wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hi Chris, > > Thank you for the suggestion. Looking at > http://www.redhat.com/__archives/freeipa-users/2014-__August/msg00334.html > > > Installing a new, third party cert requires a reinstall > of IPA? IPA > Devs, that is a bit silly don't you think? A year or > two in the cert > expires, now you have to start from scratch? I will > wait for some form > of response before I attempt at eating crow in front of > management. > > I forgot to mention, free-ipa version > ipa-server-3.0.0-37.el6.x86___64. > > Since 3.0 internal certs are issued for 2 years and are renewed > automatically. The root cert is valid for more than two > years (AFAIR > it is 20). > > > > > > On Wed Sep 10 15:55:56 2014, Chris Whittle wrote: > > Search the list for a post by me and certs... > Basically there is a > install > flag that will do all the work for you once you have > it the cert in the > right format. > On Sep 10, 2014 5:53 PM, "William Graboyes" > > > wrote: > > ********* *BEGIN ENCRYPTED or SIGNED PART* ********* > > Hello list, > > I have been fruitlessly searching for some > information, especially > related to Certs, namely how to replace the self > signed certs with > certs from a trusted CA? As we are moving forward into > productionizing of our free-ipa install, I am > finding information on > the net to be a bit lacking. There is also the > possibility that I am > not looking in the right places, or using the > correct search terms. > Any help on this front would be greatly appreciated. > > Thanks, > Bill > > > ********** *END ENCRYPTED or SIGNED PART* ********** > > -- > Manage your subscription for the Freeipa-users > mailing list: > https://www.redhat.com/__mailman/listinfo/freeipa-users > > Go To http://freeipa.org for more info on the > project > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: GPGTools - https://gpgtools.org > Comment: Using GnuPG with Thunderbird - > http://www.enigmail.net/ > > iQIcBAEBCgAGBQJUEN4JAAoJEJFMz7__3A1+zrjNAP/__1aZOjhp6c6JwWXUjBE4Pt4i > u6Z1BRFNYgIc5/__aNsPAKrdzMqQgTjgWJvSh5UCON0Vdm__uIx7pQLP7nIlaCCXTRRK > pKx2Cez5Ho7Lwlsb87WW3bzjcyKGX5__Wd3+__VJdQ6ugYJTpVS4gMxh8atZCV613EY6 > FuMk1RS6qlWM2Ut3SjmaAZK3jTw2pU__sJzW3zzB271i6sJqAMZTh7Lrie6QcG__qAON > eLGlWBZuCaeULUuQmArVZiP3qPnH5N__uccvXLFVbX7D1+__SM8XeLWrTklN1bfX2HF0 > QCFlizb+bBga/__d5cEaCv7R8v6m46R4wS779KSUV1jn9__PpHISNcmLafv6dTAb6F+5 > RBADwBP6coh5LrOJJh0pIByx9dYRbd__if/BSH4VMcvfvFMs/__EO1PAsGLWQPwoNfYO > 0SzUV1R47JW9NGzeTxja+__byKz9hwGtAT2FIw0NibR+__M1FydPD9k3LTjTnQWgeSro > ks3AUPDy/hj+E72QDORj+/__Zvy3sw8wDFVRw2LH/__jaDmWbWhZUG4riC3w2egPjcSK > KIYQ7L/fdeN6S9jt8UcUf1YDHgfLU+__iTgqyssr54RufVuM9iBNOkoWxxI0Q9__oyMF > NDKiOY8rs2rBu6x09NiHG0BoX1LQzr__rKQFQ4ao48w2RH3ocFCgQbsEHZ18uI__fo4Y > CB5M63nykETHkkR3ZFkd > =8T1Y > -----END PGP SIGNATURE----- > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: GPGTools - https://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCgAGBQJUEOV8AAoJEJFMz7__3A1+zrgwAQAJkx74MPOVvbnrG+__dmY8w7ok > J/6NWt9Rb/__pS9gRrN7iFopni3BoHuLFC6ltwD6Ko__WllYClwoXke4T0FQ/nU6Ar6M > tsuQMYxP0boxhQua2uF/kZ/__atMolxoNMShNixXd4dnWtBlpl+R+__V58FtfjSGfy49 > qX2Ge6g6wEFATwKReM1KpKCFIfO/__yq/__wM4NLvvBd6WShJXh6TQBE44y9aXLLJ__IlP > DApoLnMHaopNZITSNKt1t7dgw6ne9O__370nQwOxR5L0peH8bxla0FLJ57vX+__RCC0f > 3EV/__tQHKiXET1RqWE927tfPf171Xcq7sdj__LRUL2JTVCK3zPZUuVg9WmuqrLUArhW > f1XRpn1MM2e0xn18rvHfuRZr2IIUuP__E+RfVcQMgEcgtSYuDNlVYCO/__ONyTQHxJ/E > JRkN6nDOZ1nlItJlrrT0MVgdMKQLG7__IxkvOndGsyOShD/__XvvjQYlQbDvRvodnAlc > JUIlcC3PbGZh+__CRymXzu6M7DYceE5rJ/HzbR1UAPM/__dep1P6zA3WyTS15tzIJ93f > pjLYTciDvPbTOfRTV+__1PQvvVDbHZve34wcjGZHaqV35qUQwX__cd/DQK18L8S7EmDx > BeBmii/__cX2qBSyzDNGgSjtBTh0AT67tpJQPnH__7brsVc9S75+E/MyDqXZjqiJv/9N > i22XgsD/iTzkP3o0OTjs > =FKVl > -----END PGP SIGNATURE----- > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/__mailman/listinfo/freeipa-users > > Go To http://freeipa.org for more info on the project > > > > From bnordgren at fs.fed.us Tue Sep 16 18:13:33 2014 From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS) Date: Tue, 16 Sep 2014 18:13:33 +0000 Subject: [Freeipa-users] Two way A/D trust versus one way trust In-Reply-To: <0816e253e8d44bddb986e0e70bce13d1@mail2013.infrasupport.local> References: <0816e253e8d44bddb986e0e70bce13d1@mail2013.infrasupport.local> Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E726AFB@001FSN2MPN1-044.001f.mgd2.msft.net> > -----Original Message----- > I went through this thread: > https://www.redhat.com/archives/freeipa-users/2014- > January/msg00177.html Since January, I've been turning this problem over and over. A good summary of my functional requirements is here: http://www.freeipa.org/page/External_Collaboration_Domains My current solution is described here: http://www.freeipa.org/page/V4/Use_Case_for_Views:_Collaboration > I have another situation where I need a one way AD trust. We have an IPA > domain with a bunch of Linux servers and an AD domain for the corporate > network. Typical scenario. We want IPA to trust AD but do not want AD to > trust IPA. Access is availalbe to administrator/root accounts in both the AD > and IPA domains. Mulling this over for the past nine months, I've settled on two important factors which may help navigate the muddy waters of fear, paranoia, and ignorance: * Is there a security boundary (firewall) separating your IPA domain from AD? Could you tolerate one if it made deployment more likely/acceptable? * How similar are the roles played by users on Linux servers vs the AD servers? These are both indicative of how tightly coupled your two domains really need to be, so you know how much AD-provided functionality you can agree to do without as you try to make the Windows admins feel safer. If there's no similarity at all between roles on the Linux systems and roles on the windows systems, you can just use AD for authentication and basic user attributes. This is if you're lucky enough to just be dealing with fearful people and not faceless, one size fits all policies designed by paranoid people for a windows environment within a single security boundary. > Reading through the thread above, when we set up cross forest trusts with > this version, the IPA side does not yet have the equivalent of a Windows > Global Catalog. So even though it says it's a 2-way trust, it's really not > because IPA has no way to store the global catalog copies of what it needs > for Windows to trust IPA. So with the version right now as it exists today, de- > facto, IPA trusts AD, but AD has no way to trust IPA yet because IPA doesn't > have all the pieces in place. Perhaps your chances of obtaining a cross-forest trust may go up if you agree to manage users and groups in AD, and Linux machines/services only in IPA (e.g., no users in IPA to infiltrate the windows environment). If politically necessary, AD can issue a "realm trust" (Kerberos only), which can be one-way. At least authentication will function. IPA does not officially support that yet, but there is a workaround: https://www.redhat.com/archives/freeipa-users/2014-August/msg00096.html All your machines will need access to port 88 on the AD servers so they can kinit, but they can be joined to IPA rather than AD. If you do this, write it up! Otherwise, I'll write it up after I do it (which is predicated on me obtaining a realm trust). The downside is that currently you really can only use IPA to manage machines and services in this context. IPA can manipulate groups defined in AD as atomic units, but I'm not sure even that will work if a cross-forest style trust has not been established. An in-progress feature called "views" provides the machinery to recognize and manage individual users defined externally. Things will get better. > The AD group at this site is concerned that with some future version of IPA, > since Windows already "thinks" it trusts IPA, that IPA will get the correct > components and that suddenly IPA users will be able to authenticate in the > AD domain. Ideally, they would like to set up an official one way trust today > so that future possibility never happens. If that isn't possible, what other > steps could they take to guard against that future possibility? 1] Don't manage users or groups in IPA. 2] Don't couple the domains more tightly than needed. 3] Create a security boundary to segregate the domains, particularly if it is appropriate to do so (i.e., protect business systems from crazy experimentation in R&D department). HTH Bryce This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. From bnordgren at fs.fed.us Tue Sep 16 18:57:15 2014 From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS) Date: Tue, 16 Sep 2014 18:57:15 +0000 Subject: [Freeipa-users] apache kerberized nfs4 /var/www/html access denied for apache user In-Reply-To: <541860F7.1090602@redhat.com> References: <82E7C9A01FD0764CACDD35D10F5DFB6E7267D7@001FSN2MPN1-044.001f.mgd2.msft.net> <2332392.eAZbh8SOxa@linux-ws1.messinet.com> <20140916115846.6cf53fe8@willson.usersys.redhat.com> <541860F7.1090602@redhat.com> Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E726B33@001FSN2MPN1-044.001f.mgd2.msft.net> > Also opened https://fedorahosted.org/freeipa/ticket/4544 Tried to summarize this thread on that ticket. Back to the OP's concern, whenever I use NFS as a documentroot for apache (even a WebDAV server), I make a separate mountpoint, fall back to sec=sys, set "all-squash", and specify the webserver's IP. It's not like individual user accounts need a presence on the filesystem. Do you need encryption for your application or is apache just going to spray the content out across the commodity internet via un-encrypted http? Bryce This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. From GregScott at infrasupport.com Wed Sep 17 04:38:15 2014 From: GregScott at infrasupport.com (Greg Scott) Date: Wed, 17 Sep 2014 04:38:15 +0000 Subject: [Freeipa-users] Two way A/D trust versus one way trust In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E726AFB@001FSN2MPN1-044.001f.mgd2.msft.net> References: <0816e253e8d44bddb986e0e70bce13d1@mail2013.infrasupport.local> <82E7C9A01FD0764CACDD35D10F5DFB6E726AFB@001FSN2MPN1-044.001f.mgd2.msft.net> Message-ID: <1f12fad24c324ba6b125ec228a6dc243@mail2013.infrasupport.local> Thanks everyone for the advice. Here's a sanitized version of what I put together for my end user customer. Feel free to use any of this text as you see fit. **************** Here's the scoop with IdM and AD trusts. It's an "official" 2-way trust with the currently shipping IdM version - I think it's 3.3.5 right now. It's an official 2-way trust, but de-facto it's only one way because IdM doesn't have all the pieces it needs yet to allow AD to trust IdM. So IdM can trust AD but right now AD cannot trust IdM. Red Hat Support told us that in the support case and I confirmed it with the upstream community. So even though it says it's a 2-way trust, it's really only one way. Somewhere in the future, around version 4.3 or so, so it's a long way away, the plan is for IdM to have the pieces it needs for AD to trust IdM. When that time comes, there are a number of options for ***?. One is to stick with today's current version. "If it ain't broke, don't fix it." Another is to continue upgrading to the current versions as they become available and redo the trust to be an official one way trust when the time comes. Another option - just leave it as a 2-way trust. The decision doesn't come up for a long time - if I had to guess, I'd put it sometime after 2015. That's just my guess because the people doing the development don't know themselves and they're the ones building this stuff. It's a long time out. And even then, it's not a huge decision. Let's say ***? decides to leave it as a 2-way trust. What are the consequences? Are there now suddenly 2 sources of truth? Is there a security hole? Is AD suddenly vulnerable? My answer would be no, no, and no. On sources of truth - There will always be a few unique users in the Linux IdM domain. User root, for example, and probably a few others. This is true whether there is no trust, a one-way trust, or a 2-way trust. IdM is like a Windows forest with one domain. And AD is a forest with at least one domain. By definition, both forests have their own individual entities. On security holes - with a 2-way trust, the AD Administrator now has the ability to regulate access to AD resources from IdM users and groups. If the AD Admin takes no action, then nobody on the IdM side can access anything on the AD side. Just because the AD administrator has this ability does not imply the he will use it. If he doesn't use it - the default action - nothing happens. Is AD suddenly vulnerable? No. Even with a 2-way trust, the AD Admin has to take specific actions in cooperation with others to allow anyone from IdM to access anything inside AD. My opinion isn't worth the disk space to store this text and free opinions are worth what you pay for them. So test it yourself. ***? has the tools right now. Build a Windows forest - independent of your Dev forest - and do some experiments with 2-way cross forest trusts. Set up and destroy a few trust relationships with your existing Dev domain/forest and my proposed test forest and grant permissions to a few groups from one side into the other side. You can do it with one Windows VM. Now substitute IdM for that test Windows forest when the time comes and the issues are exactly the same. One more point on vulnerability. I know the choice to copy AD users into IdM is well-known, safe, and comfortable at ***?. That's the way they did it last time. But this choice requires non Microsoft software on the ***? AD domain controllers. So thinking it through - which represents the most risk? Setting up a cross forest trust where the AD administrator retains total control over everything, or putting foreign software on the Windows domain controllers to copy user passwords to an untrusted entity? - Greg From rob.verduijn at gmail.com Wed Sep 17 07:15:27 2014 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Wed, 17 Sep 2014 09:15:27 +0200 Subject: [Freeipa-users] apache kerberized nfs4 /var/www/html access denied for apache user In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E726B33@001FSN2MPN1-044.001f.mgd2.msft.net> References: <82E7C9A01FD0764CACDD35D10F5DFB6E7267D7@001FSN2MPN1-044.001f.mgd2.msft.net> <2332392.eAZbh8SOxa@linux-ws1.messinet.com> <20140916115846.6cf53fe8@willson.usersys.redhat.com> <541860F7.1090602@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E726B33@001FSN2MPN1-044.001f.mgd2.msft.net> Message-ID: 2014-09-16 20:57 GMT+02:00 Nordgren, Bryce L -FS : > > > Also opened https://fedorahosted.org/freeipa/ticket/4544 > > Tried to summarize this thread on that ticket. > > Back to the OP's concern, whenever I use NFS as a documentroot for apache > (even a WebDAV server), I make a separate mountpoint, fall back to sec=sys, > set "all-squash", and specify the webserver's IP. It's not like individual > user accounts need a presence on the filesystem. Do you need encryption for > your application or is apache just going to spray the content out across > the commodity internet via un-encrypted http? > > Bryce > > > > > > > This electronic message contains information generated by the USDA solely > for the intended recipients. Any unauthorized interception of this message > or the use or disclosure of the information it contains may violate the law > and subject the violator to civil or criminal penalties. If you believe you > have received this message in error, please notify the sender and delete > the email immediately. > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > Hello, I've already implemented the share as 1.2.3.4(ro,sync,all-squash,sec=sys) It's not sensitive data and it's also internal, so it will do fine for now as a workaround. But there is going to be a situation that apache requires access to a document root containing sensitive data, in that case I would prefer a more secure method. I've been reading up a little on the gss-proxy, which would be the prefered way on the obtaining of the credentials from a keytab. Have gss-proxy do it or have gss-proxy use s4u2proxy to fetch the keytab ? (which might also solve some of my ssh anoyances but that's a bit off topic) Rob Verduijn -------------- next part -------------- An HTML attachment was scrubbed... URL: From tevfik.ceydeliler at astron.yasar.com.tr Wed Sep 17 10:57:45 2014 From: tevfik.ceydeliler at astron.yasar.com.tr (Tevfik Ceydeliler) Date: Wed, 17 Sep 2014 13:57:45 +0300 Subject: [Freeipa-users] How to use sudo rules on ubuntu In-Reply-To: <20140901160539.GJ8008@mail.corp.redhat.com> References: <20140901071217.GC8008@mail.corp.redhat.com> <5404352E.4060906@astron.yasar.com.tr> <20140901092021.GB3593@redhat.com> <5404505A.5090409@astron.yasar.com.tr> <20140901111858.GE3593@redhat.com> <540468D4.6020408@astron.yasar.com.tr> <20140901124231.GF8008@mail.corp.redhat.com> <54046B03.1030201@astron.yasar.com.tr> <20140901130410.GG8008@mail.corp.redhat.com> <5404881E.7050204@astron.yasar.com.tr> <20140901160539.GJ8008@mail.corp.redhat.com> Message-ID: <54196929.7@astron.yasar.com.tr> Hi Lukas, After you warned me, I reinstall IPA server and client, and replica. After that I did your directives shown below. Everything looked ok. I got output like you tell. But after couple of hours later I try to conenct client host by using ssh and test again. ANd suprise! client again cant use sudo. What happened?? On 01-09-2014 19:05, Lukas Slebodnik wrote: > On (01/09/14 17:52), Tevfik Ceydeliler wrote: >> 1. I think I configure instead of this document > Sorry you didn't. > >> 2. I can login with ordinary user > login and sudo are not the same think. > > My FreeIPA server is alredy properly configured with sudo rules. > I tried to install freipa-client on ubuntu 14.04 and it owrked without any > problem. > >>> Step 0: Install freipa-client on ubuntu 14.04 and configure sudo integration > root at ubuntu1404:/# ipa-client-install --no-ntp > root at ubuntu1404:/# echo "sudoers: files sss" >> /etc/nsswitch.conf > > root at ubuntu1404:/# grep services /etc/sssd/sssd.conf > services = nss, pam > root at ubuntu1404:/# sed -i -e 's/\(services.*\)/\1, sudo/' /etc/sssd/sssd.conf > root at ubuntu1404:/# grep services /etc/sssd/sssd.conf > services = nss, pam, sudo > >>> Step 1: configure sudo rules for ordinary user >>> Please follow the instructions from FreeIPA documentation. >>> http://www.freeipa.org/docs/master/html-desktop/index.html#sudo >>> > This step was skipped, becuase it was already done few months ago :-) > >>> Step 2: login to machine as ordinary user, which is allowed to use sudo. > $ su usersssd01 > Password: > $ id > uid=325600011(usersssd01) gid=325600011(usersssd01) groups=325600011(usersssd01),30011(biggroup1) > >>> Step 3: run command >>> sudo -l >>> // this command should show you which commands can be executed as root >>> // with sudo > $ sudo -l > sudo: unable to resolve host ubuntu1404.example.test > [sudo] password for usersssd01: > Matching Defaults entries for usersssd01 on ubuntu1404: > env_reset, mail_badpass, > secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin > > User usersssd01 may run the following commands on ubuntu1404: > (root) /usr/bin/less, /usr/bin/vim > >>> Step 4: If there weren't any problems then user will be able to run command. >>> sudo some_command_listed_in_step3 > $ sudo /usr/bin/less /etc/shadow | wc -l > 21 > $ echo $? > 0 > > $ sudo apt-get install mc > Sorry, user usersssd01 is not allowed to execute '/usr/bin/apt-get install mc' as root on ubuntu.example.test. > $ echo $? > 1 > > LS --


Bu elektronik postada bulunan tum fikir ve gorusler ve ekindeki dosyalar sadece adres sahip/sahiplerine ait olup, Yasar Toplulugu Sirketleri bu mesajin icerigi ile ilgili olarak hic bir hukuksal sorumlulugu kabul etmez. Eger gonderilmesi dusunulen kisi veya kurulus degilseniz, lutfen gonderen kisiyi derhal haberdar ediniz ve mesaji sisteminizden siliniz.The information contained in this e-mail and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and Yasar Group Companies do not accept legal responsibility for the contents. If you are not the intended recipient, please immediately notify the sender and delete it from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.png Type: image/png Size: 15216 bytes Desc: not available URL: From lslebodn at redhat.com Wed Sep 17 11:53:25 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Wed, 17 Sep 2014 13:53:25 +0200 Subject: [Freeipa-users] How to use sudo rules on ubuntu In-Reply-To: <54196929.7@astron.yasar.com.tr> References: <20140901092021.GB3593@redhat.com> <5404505A.5090409@astron.yasar.com.tr> <20140901111858.GE3593@redhat.com> <540468D4.6020408@astron.yasar.com.tr> <20140901124231.GF8008@mail.corp.redhat.com> <54046B03.1030201@astron.yasar.com.tr> <20140901130410.GG8008@mail.corp.redhat.com> <5404881E.7050204@astron.yasar.com.tr> <20140901160539.GJ8008@mail.corp.redhat.com> <54196929.7@astron.yasar.com.tr> Message-ID: <20140917115325.GC18821@mail.corp.redhat.com> On (17/09/14 13:57), Tevfik Ceydeliler wrote: > >Hi Lukas, >After you warned me, I reinstall IPA server and client, and replica. >After that I did your directives shown below. >Everything looked ok. >I got output like you tell. >But after couple of hours later I try to conenct client host by using ssh >and test again. >ANd suprise! client again cant use sudo. > >What happened?? I don't know. Please put "debug_level = 7" into sssd.conf (sections: sudo and domain) * restart sssd * login as sssd used which should be allowed to run sudo sommand(s) * execute command "truncate -s 0 /var/log/sssd/*" * call sudo -l * and provide log files from /var/log/sssd/* and also output from "sudo -l" I can take a loog to the log files and identify the problem. LS From tevfik.ceydeliler at astron.yasar.com.tr Wed Sep 17 12:07:45 2014 From: tevfik.ceydeliler at astron.yasar.com.tr (Tevfik Ceydeliler) Date: Wed, 17 Sep 2014 15:07:45 +0300 Subject: [Freeipa-users] How to use sudo rules on ubuntu In-Reply-To: <20140917115325.GC18821@mail.corp.redhat.com> References: <20140901092021.GB3593@redhat.com> <5404505A.5090409@astron.yasar.com.tr> <20140901111858.GE3593@redhat.com> <540468D4.6020408@astron.yasar.com.tr> <20140901124231.GF8008@mail.corp.redhat.com> <54046B03.1030201@astron.yasar.com.tr> <20140901130410.GG8008@mail.corp.redhat.com> <5404881E.7050204@astron.yasar.com.tr> <20140901160539.GJ8008@mail.corp.redhat.com> <54196929.7@astron.yasar.com.tr> <20140917115325.GC18821@mail.corp.redhat.com> Message-ID: <54197991.4000807@astron.yasar.com.tr> OK :) No panic for my self :) I found what was wrong. now ok. Thnx so much On 17-09-2014 14:53, Lukas Slebodnik wrote: > On (17/09/14 13:57), Tevfik Ceydeliler wrote: >> Hi Lukas, >> After you warned me, I reinstall IPA server and client, and replica. >> After that I did your directives shown below. >> Everything looked ok. >> I got output like you tell. >> But after couple of hours later I try to conenct client host by using ssh >> and test again. >> ANd suprise! client again cant use sudo. >> >> What happened?? > I don't know. > > Please put "debug_level = 7" into sssd.conf (sections: sudo and domain) > * restart sssd > * login as sssd used which should be allowed to run sudo sommand(s) > * execute command "truncate -s 0 /var/log/sssd/*" > * call sudo -l > * and provide log files from /var/log/sssd/* and also output from "sudo -l" > I can take a loog to the log files and identify the problem. > > LS --


Bu elektronik postada bulunan tum fikir ve gorusler ve ekindeki dosyalar sadece adres sahip/sahiplerine ait olup, Yasar Toplulugu Sirketleri bu mesajin icerigi ile ilgili olarak hic bir hukuksal sorumlulugu kabul etmez. Eger gonderilmesi dusunulen kisi veya kurulus degilseniz, lutfen gonderen kisiyi derhal haberdar ediniz ve mesaji sisteminizden siliniz.The information contained in this e-mail and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and Yasar Group Companies do not accept legal responsibility for the contents. If you are not the intended recipient, please immediately notify the sender and delete it from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.png Type: image/png Size: 15216 bytes Desc: not available URL: From sanju.a at tcs.com Wed Sep 17 13:54:00 2014 From: sanju.a at tcs.com (Sanju A) Date: Wed, 17 Sep 2014 19:24:00 +0530 Subject: [Freeipa-users] sudo setup in Ubuntu Message-ID: Dear All, I am able to configure the sudo settings in Centos clients by adding/modifying the entries in /etc/nsswitch.conf and /etc/sudo-ldap.conf. What is the exact steps for the configuration in Ubuntu as I am not able find the configuration file sudo-ldap.conf in Ubuntu. Regards Sanju Abraham IS - Network/System Administrator Tata Consultancy Services TCS Centre SEZ Unit, Infopark PO, Kochi - 682042,Kerala India Ph:- +91 484 6187490 Mailto: sanju.a at tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ =====-----=====-----===== 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tevfik.ceydeliler at astron.yasar.com.tr Wed Sep 17 13:58:00 2014 From: tevfik.ceydeliler at astron.yasar.com.tr (Tevfik Ceydeliler) Date: Wed, 17 Sep 2014 16:58:00 +0300 Subject: [Freeipa-users] sudo setup in Ubuntu In-Reply-To: References: Message-ID: <54199368.8010505@astron.yasar.com.tr> Thanks to Lukas: Step 0: Install freipa-client on ubuntu 14.04 and configure sudo integration root at ubuntu1404:/# ipa-client-install --no-ntp root at ubuntu1404:/# echo "sudoers: files sss" >> /etc/nsswitch.conf root at ubuntu1404:/# grep services /etc/sssd/sssd.conf services = nss, pam root at ubuntu1404:/# sed -i -e 's/\(services.*\)/\1, sudo/' /etc/sssd/sssd.conf root at ubuntu1404:/# grep services /etc/sssd/sssd.conf services = nss, pam, sudo >> Step 1: configure sudo rules for ordinary user >> Please follow the instructions from FreeIPA documentation. >> http://www.freeipa.org/docs/master/html-desktop/index.html#sudo >> This step was skipped, becuase it was already done few months ago >> Step 2: login to machine as ordinary user, which is allowed to use sudo. $ su usersssd01 Password: $ id uid=325600011(usersssd01) gid=325600011(usersssd01) groups=325600011(usersssd01),30011(biggroup1) >> Step 3: run command >> sudo -l >> // this command should show you which commands can be executed as root >> // with sudo $ sudo -l sudo: unable to resolve host ubuntu1404.example.test [sudo] password for usersssd01: Matching Defaults entries for usersssd01 on ubuntu1404: env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin User usersssd01 may run the following commands on ubuntu1404: (root) /usr/bin/less, /usr/bin/vim >> Step 4: If there weren't any problems then user will be able to run command. >> sudo some_command_listed_in_step3 $ sudo /usr/bin/less /etc/shadow | wc -l 21 $ echo $? 0 $ sudo apt-get install mc Sorry, user usersssd01 is not allowed to execute '/usr/bin/apt-get install mc' as root on ubuntu.example.test. $ echo $? 1 On 17-09-2014 16:54, Sanju A wrote: > Dear All, > > I am able to configure the sudo settings in Centos clients by > adding/modifying the entries in /etc/nsswitch.conf and > /etc/sudo-ldap.conf. What is the exact steps for the configuration in > Ubuntu as I am not able find the configuration file sudo-ldap.conf in > Ubuntu. > > > Regards > Sanju Abraham > IS - Network/System Administrator > Tata Consultancy Services > TCS Centre SEZ Unit, > Infopark PO, > Kochi - 682042,Kerala > India > Ph:- +91 484 6187490 > Mailto: sanju.a at tcs.com > Website: http://www.tcs.com > ____________________________________________ > Experience certainty. IT Services > Business Solutions > Consulting > ____________________________________________ > > =====-----=====-----===== > 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 > > > --


Bu elektronik postada bulunan tum fikir ve gorusler ve ekindeki dosyalar sadece adres sahip/sahiplerine ait olup, Yasar Toplulugu Sirketleri bu mesajin icerigi ile ilgili olarak hic bir hukuksal sorumlulugu kabul etmez. Eger gonderilmesi dusunulen kisi veya kurulus degilseniz, lutfen gonderen kisiyi derhal haberdar ediniz ve mesaji sisteminizden siliniz.The information contained in this e-mail and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and Yasar Group Companies do not accept legal responsibility for the contents. If you are not the intended recipient, please immediately notify the sender and delete it from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.png Type: image/png Size: 15216 bytes Desc: not available URL: From tbordaz at redhat.com Wed Sep 17 16:22:22 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 17 Sep 2014 18:22:22 +0200 Subject: [Freeipa-users] unhappy replication? In-Reply-To: <540F1139.8050604@gmail.com> References: <540F1139.8050604@gmail.com> Message-ID: <5419B53E.2070308@redhat.com> On 09/09/2014 04:39 PM, Kat wrote: > Anyone seen this before -- 2 freshly kicked CentOS 7 installs: > > On the replica from the ipa-replica-install : > > 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. > > and then the errors file for 389-ds > > "The remote replica has a different database generation ID than the > local database. You may have to reinitialize the remote replica, or > the local replica." > > ~K > Hello, Investigating a similar issue we suspected the logged RC to be invalid. Instead of Referral it could actually be CONN_TIMEOUT. If you are still able to reproduce, would you verify the value of 'nsds5ReplicaTimeout' on the replica Agreement on the master. If it is set to a "low" value like 120, there is a possible workaround by removing it (or set to a higher value). So it will wait for 10m (default) before ending with a failure. Then retry the full init. regards thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From rap at phas.ubc.ca Wed Sep 17 16:41:32 2014 From: rap at phas.ubc.ca (Ron) Date: Wed, 17 Sep 2014 09:41:32 -0700 Subject: [Freeipa-users] users in groups but user entry does not show groups Message-ID: <5419B9BC.70300@phas.ubc.ca> I have created user groups and entered users. When I view the groups under the "User Groups" heading, I see the group members. When I go to the "Users" heading, and click the "User Groups" sub-heading, IPA does not show any groups (says no entries at bottom). See attached png screenshots. Any ideas as to what is going on? This does not happen for all members of the group. For some users, there *are* entries for groups under "Users -> User groups" Thank you. -- Ron Parachoniak Systems Manager, Department of Physics & Astronomy University of British Columbia, Vancouver, B.C. V6T 1Z1 Phone: (604) 838-6437 -------------- next part -------------- A non-text attachment was scrubbed... Name: User_brog.png Type: image/png Size: 23463 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: UserGroup_p309-mm.png Type: image/png Size: 45637 bytes Desc: not available URL: From genadipost at gmail.com Wed Sep 17 17:08:34 2014 From: genadipost at gmail.com (Genadi Postrilko) Date: Wed, 17 Sep 2014 20:08:34 +0300 Subject: [Freeipa-users] AD Trust - Cannot resolve servers for KDC after reboot In-Reply-To: <20140916072831.GY2947@localhost.localdomain> References: <20140916072831.GY2947@localhost.localdomain> Message-ID: I have configured the DNS with the AD as a forwarder (ipa-server-install --forwarder), just as explaine in RHEL 7 Windows Integration guide - 5.3.1. Setting up Trust with IdM as a DNS Subdomain of Active Directory. To use KRB5_TRACE ill need to recreate the issue. 2014-09-16 10:28 GMT+03:00 Sumit Bose : > On Tue, Sep 16, 2014 at 01:39:41AM +0300, Genadi Postrilko wrote: > > Hello all ! > > > > I have deployed test environment for AD trust feature, the environment > > contains : > > Windows Server 2008 - AD Server. > > RHEL 7 - IPA 3.3 Server. > > RHEL 6.2 - IPA Client. > > > > I have established the trust as IPA in the sub domain of AD. > > AD DNS domain - blue.com > > IPA DNS domain - linux.blue.com > > > > All was working fine as i was able to kinit with AD users: > > > > [root at ipaserver1 ~]# kinit Yoni at BLUE.COM > > Password for Yoni at BLUE.COM: > > > > [root at ipaserver1 ~]# klist > > Ticket cache: KEYRING:persistent:0:krb_ccache_oi15FrE > > Default principal: Yoni at BLUE.COM > > > > Valid starting Expires Service principal > > 09/16/2014 01:00:25 09/16/2014 11:00:25 krbtgt/BLUE.COM at BLUE.COM > > renew until 09/17/2014 01:00:20 > > > > But after i rebooted the Windows Server Machine, i could not kinit with > AD > > users anymore: > > [root at ipaserver1 ~]# kinit Yoni at BLUE.COM > > kinit: Cannot resolve servers for KDC in realm "BLUE.COM" while getting > > initial > > The only IPA component used for kinit is the DNS server. How did you > configure DNS (glue records? forwarder?). To get more details about what > is failing you can call: > > KRB5_TRACE=/dev/stdout kinit Yoni at BLUE.COM > > HTH > > bye, > Sumit > > > > > I have checked if all the IPA services where UP: > > > > [root at ipaserver1 ~]# ipactl status > > Directory Service: RUNNING > > krb5kdc Service: RUNNING > > kadmin Service: RUNNING > > named Service: RUNNING > > ipa_memcached Service: RUNNING > > httpd Service: RUNNING > > pki-tomcatd Service: RUNNING > > smb Service: RUNNING > > winbind Service: RUNNING > > ipa-otpd Service: RUNNING > > ipa: INFO: The ipactl command was successful > > > > After i restarted IPA services (ipactl restart), i was able to to kinit > > again. > > Restarting smb service would do the job as well (?). > > > > Just wanted to know if it is a know issue, or the AD should be re > > discovered if it reboots. > > I think i seen an issue about it in the mailing list some time ago (not > > sure). > > > > I did not increase the debug level and got the logs. > > But i can share the ipa and sssd version: > > > > rpm -qa | grep ipa > > ipa-server-3.3.3-28.el7_0.1.x86_64 > > python-iniparse-0.4-9.el7.noarch > > libipa_hbac-1.11.2-68.el7_0.5.x86_64 > > ipa-admintools-3.3.3-28.el7_0.1.x86_64 > > ipa-server-trust-ad-3.3.3-28.el7_0.1.x86_64 > > ipa-python-3.3.3-28.el7_0.1.x86_64 > > sssd-ipa-1.11.2-68.el7_0.5.x86_64 > > iniparser-3.1-5.el7.x86_64 > > libipa_hbac-python-1.11.2-68.el7_0.5.x86_64 > > ipa-client-3.3.3-28.el7_0.1.x86_64 > > > > rpm -qa | grep sssd > > sssd-krb5-common-1.11.2-68.el7_0.5.x86_64 > > sssd-ldap-1.11.2-68.el7_0.5.x86_64 > > sssd-common-1.11.2-68.el7_0.5.x86_64 > > sssd-common-pac-1.11.2-68.el7_0.5.x86_64 > > sssd-ad-1.11.2-68.el7_0.5.x86_64 > > sssd-krb5-1.11.2-68.el7_0.5.x86_64 > > sssd-1.11.2-68.el7_0.5.x86_64 > > python-sssdconfig-1.11.2-68.el7_0.5.noarch > > sssd-ipa-1.11.2-68.el7_0.5.x86_64 > > sssd-proxy-1.11.2-68.el7_0.5.x86_64 > > sssd-client-1.11.2-68.el7_0.5.x86_64 > > > > Thanks for all the helpers. > > > -- > > Manage your subscription for the Freeipa-users mailing list: > > https://www.redhat.com/mailman/listinfo/freeipa-users > > Go To http://freeipa.org for more info on the project > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rap at phas.ubc.ca Wed Sep 17 18:18:42 2014 From: rap at phas.ubc.ca (Ron) Date: Wed, 17 Sep 2014 11:18:42 -0700 Subject: [Freeipa-users] users in groups but user entry does not show groups In-Reply-To: References: Message-ID: <5419D082.5010902@phas.ubc.ca> More information that I should have include before is below. Note that I use a perl script to add users to the IPA server using perl->LDAP commands (see below). Could this be the source of the problem? ======================== snippet from perl createid script: $mesg = $ldap->add("uid=$me,".$CONF{"dn_suffix"}, attrs => [ "objectclass" => $CONF{"obj_class"}, "uidNumber" => $uid, "gidNumber" => $gid, "cn" => $gecos, "gecos" => $gecos, "sn" => $lastname, "givenName" => $firstname, "homeDirectory" => $homedir, "loginShell" => $shell, "mail" => $mail, "userPassword" => $pass ]); ========================================================= This user does not show the memberof entries even though user brog is in the p309-mm group. [root at ipa ~]# ipa user-show --raw --all brog dn: uid=brog,cn=users,cn=accounts,dc=abc,dc=def,dc=gh uid: brog givenname: Bir sn: Roga cn: Bir Roga homedirectory: /home2/brog gecos: Bir Roga loginshell: /bin/bash mail: brog at xyz.gh uidnumber: 15520 gidnumber: 15520 nsaccountlock: False has_password: True has_keytab: False mepmanagedentry: cn=brog,cn=groups,cn=accounts,dc=abc,dc=def,dc=gh objectclass: posixAccount objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson objectclass: shadowAccount objectclass: mepOriginEntry ========================================================== this user shows the "memberof" entries as expected. [root at ipa ~]# ipa user-show --raw --all dwth dn: uid=dwth,cn=users,cn=accounts,dc=abc,dc=def,dc=gh uid: dwth givenname: Dev sn: Tho cn: Dev Tho homedirectory: /home2/dwth gecos: Devin Tho loginshell: /bin/bash krbprincipalname: dwth at ABC.DEF.GH mail: dwth at xyz.gh uidnumber: 15424 gidnumber: 400 nsaccountlock: False has_password: True has_keytab: True ipauniqueid: 44f17786-f95c-11e2-b3be-64700200e138 krbextradata: AAJP6ihScm9vdC9hZG1pbkBQSEFTLlVCQy5DQQA= krblastpwdchange: 20130905203215Z krbpasswordexpiration: 20131204203215Z memberof: cn=ipausers,cn=groups,cn=accounts,dc=abc,dc=def,dc=gh memberof: cn=p309-mm,cn=groups,cn=accounts,dc=abc,dc=def,dc=gh objectclass: krbticketpolicyaux objectclass: ipaobject objectclass: organizationalperson objectclass: top objectclass: ipasshuser objectclass: inetorgperson objectclass: person objectclass: inetuser objectclass: krbprincipalaux objectclass: shadowaccount objectclass: posixaccount objectclass: ipaSshGroupOfPubKeys ========================================================== [root at ipa ~]# ipa group-show --all p309-mm dn: cn=p309-mm,cn=groups,cn=accounts,dc=abc,dc=def,dc=gh Group name: p309-mm Description: p309 lab group mm GID: 462 Member users: halp, jfc, tpr, dwth, brog ipauniqueid: b4d0f16e-3a95-11e4-81df-64700200e138 objectclass: top, groupofnames, nestedgroup, ipausergroup, ipaobject, posixgroup ========================================================== From abokovoy at redhat.com Wed Sep 17 18:43:09 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 17 Sep 2014 21:43:09 +0300 Subject: [Freeipa-users] users in groups but user entry does not show groups In-Reply-To: <5419D082.5010902@phas.ubc.ca> References: <5419D082.5010902@phas.ubc.ca> Message-ID: <20140917184309.GZ2541@redhat.com> On Wed, 17 Sep 2014, Ron wrote: >More information that I should have include before is below. Note that >I use a perl script to add users to the IPA server using perl->LDAP >commands (see below). Could this be the source of the problem? Yes. If you are creating users not using IPA commands, you need to make sure you are adding required object classes. Your user below misses ipaObject and few more. > >======================== >snippet from perl createid script: > > $mesg = $ldap->add("uid=$me,".$CONF{"dn_suffix"}, > attrs => [ > "objectclass" => $CONF{"obj_class"}, > "uidNumber" => $uid, > "gidNumber" => $gid, > "cn" => $gecos, > "gecos" => $gecos, > "sn" => $lastname, > "givenName" => $firstname, > "homeDirectory" => $homedir, > "loginShell" => $shell, > "mail" => $mail, > "userPassword" => $pass > ]); > >========================================================= >This user does not show the memberof entries even though user brog is in >the p309-mm group. > >[root at ipa ~]# ipa user-show --raw --all brog > dn: uid=brog,cn=users,cn=accounts,dc=abc,dc=def,dc=gh > uid: brog > givenname: Bir > sn: Roga > cn: Bir Roga > homedirectory: /home2/brog > gecos: Bir Roga > loginshell: /bin/bash > mail: brog at xyz.gh > uidnumber: 15520 > gidnumber: 15520 > nsaccountlock: False > has_password: True > has_keytab: False > mepmanagedentry: cn=brog,cn=groups,cn=accounts,dc=abc,dc=def,dc=gh > objectclass: posixAccount > objectclass: top > objectclass: person > objectclass: organizationalPerson > objectclass: inetOrgPerson > objectclass: shadowAccount > objectclass: mepOriginEntry > >========================================================== >this user shows the "memberof" entries as expected. > >[root at ipa ~]# ipa user-show --raw --all dwth > dn: uid=dwth,cn=users,cn=accounts,dc=abc,dc=def,dc=gh > uid: dwth > givenname: Dev > sn: Tho > cn: Dev Tho > homedirectory: /home2/dwth > gecos: Devin Tho > loginshell: /bin/bash > krbprincipalname: dwth at ABC.DEF.GH > mail: dwth at xyz.gh > uidnumber: 15424 > gidnumber: 400 > nsaccountlock: False > has_password: True > has_keytab: True > ipauniqueid: 44f17786-f95c-11e2-b3be-64700200e138 > krbextradata: AAJP6ihScm9vdC9hZG1pbkBQSEFTLlVCQy5DQQA= > krblastpwdchange: 20130905203215Z > krbpasswordexpiration: 20131204203215Z > memberof: cn=ipausers,cn=groups,cn=accounts,dc=abc,dc=def,dc=gh > memberof: cn=p309-mm,cn=groups,cn=accounts,dc=abc,dc=def,dc=gh > objectclass: krbticketpolicyaux > objectclass: ipaobject > objectclass: organizationalperson > objectclass: top > objectclass: ipasshuser > objectclass: inetorgperson > objectclass: person > objectclass: inetuser > objectclass: krbprincipalaux > objectclass: shadowaccount > objectclass: posixaccount > objectclass: ipaSshGroupOfPubKeys > >========================================================== >[root at ipa ~]# ipa group-show --all p309-mm > dn: cn=p309-mm,cn=groups,cn=accounts,dc=abc,dc=def,dc=gh > Group name: p309-mm > Description: p309 lab group mm > GID: 462 > Member users: halp, jfc, tpr, dwth, brog > ipauniqueid: b4d0f16e-3a95-11e4-81df-64700200e138 > objectclass: top, groupofnames, nestedgroup, ipausergroup, ipaobject, >posixgroup > >========================================================== > > >-- >Manage your subscription for the Freeipa-users mailing list: >https://www.redhat.com/mailman/listinfo/freeipa-users >Go To http://freeipa.org for more info on the project -- / Alexander Bokovoy From rcritten at redhat.com Thu Sep 18 00:24:53 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 17 Sep 2014 20:24:53 -0400 Subject: [Freeipa-users] Certs. In-Reply-To: References: <5410D5C3.7020805@cenic.org> <5410DE09.4050700@cenic.org> <5410E384.4070703@redhat.com> <5410E57C.5030204@cenic.org> <5410E664.6080602@redhat.com> <54186FD1.8030908@redhat.com> Message-ID: <541A2655.5060600@redhat.com> Walid wrote: > Hi Rob, > > Self signed IPA certificate i saw it is 20 years, however how about the > client nodes renewal, i see here it is automated, how, and when For renewed CA certificate distribution, we are working on it in ticket https://fedorahosted.org/freeipa/ticket/4322 For any server certificates on a client then certmonger is the way to go, and is our recommended mechanism. It will monitor and automatically renew any certificates installed (well, any it has permission to renew). rob > > On 16 September 2014 20:13, Rob Crittenden > wrote: > > Walid wrote: > > Hi Dmitri, > > I am interested in the renewal process, how would that happen for > clients, and when would it happen? > > > It depends on what scenario you're talking about (self-signed IPA > cert, IPA as subordinate, user-provided certificates), and what > certs you mean. > > rob > > > On 11 September 2014 03:01, Dmitri Pal > >> wrote: > > On 09/10/2014 07:57 PM, William Graboyes wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hi Dmitri, > > Production Environment is going to be RH 6.5, We are still > evaluating > the usage of systemd. More like we are taking a wait > and see > approach > to to systemd, while actively testing it. > > The command line options for chaining are there from day one. > So you would need to chain your production environment when you > deploy it. > In future when you migrate to later versions (in couple of > years or > so) you will be able to change the chaining using the new > tools. > Right now it is a vary hard multi step manual procedure. > This is why > we developed the tool. > But you should be all set for now. You would not need to change > anything for several years. > > Thanks > Dmitri > > > > Thanks, > Bill > > On Wed Sep 10 16:49:24 2014, Dmitri Pal wrote: > > On 09/10/2014 07:26 PM, William Graboyes wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hi Chris, > > Thank you for the suggestion. Looking at > http://www.redhat.com/____archives/freeipa-users/2014-____August/msg00334.html > > > > > > Installing a new, third party cert requires a > reinstall > of IPA? IPA > Devs, that is a bit silly don't you think? A > year or > two in the cert > expires, now you have to start from scratch? I > will > wait for some form > of response before I attempt at eating crow in > front of > management. > > I forgot to mention, free-ipa version > ipa-server-3.0.0-37.el6.x86_____64. > > Since 3.0 internal certs are issued for 2 years and > are renewed > automatically. The root cert is valid for more than two > years (AFAIR > it is 20). > > > > > > On Wed Sep 10 15:55:56 2014, Chris Whittle wrote: > > Search the list for a post by me and certs... > Basically there is a > install > flag that will do all the work for you once > you have > it the cert in the > right format. > On Sep 10, 2014 5:53 PM, "William Graboyes" > >> > wrote: > > ********* *BEGIN ENCRYPTED or SIGNED PART* > ********* > > Hello list, > > I have been fruitlessly searching for some > information, especially > related to Certs, namely how to replace the > self > signed certs with > certs from a trusted CA? As we are moving > forward into > productionizing of our free-ipa install, I am > finding information on > the net to be a bit lacking. There is also the > possibility that I am > not looking in the right places, or using the > correct search terms. > Any help on this front would be greatly > appreciated. > > Thanks, > Bill > > > ********** *END ENCRYPTED or SIGNED PART* > ********** > > -- > Manage your subscription for the > Freeipa-users > mailing list: > https://www.redhat.com/____mailman/listinfo/freeipa-users > > > __> > Go To http://freeipa.org for more info > on the > project > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: GPGTools - https://gpgtools.org > Comment: Using GnuPG with Thunderbird - > http://www.enigmail.net/ > > > iQIcBAEBCgAGBQJUEN4JAAoJEJFMz7____3A1+zrjNAP/____1aZOjhp6c6JwWXUjBE4Pt4i > > u6Z1BRFNYgIc5/____aNsPAKrdzMqQgTjgWJvSh5UCON0Vdm____uIx7pQLP7nIlaCCXTRRK > > pKx2Cez5Ho7Lwlsb87WW3bzjcyKGX5____Wd3+____VJdQ6ugYJTpVS4gMxh8atZCV613EY6 > > FuMk1RS6qlWM2Ut3SjmaAZK3jTw2pU______sJzW3zzB271i6sJqAMZTh7Lrie6QcG____qAON > > eLGlWBZuCaeULUuQmArVZiP3qPnH5N____uccvXLFVbX7D1+____SM8XeLWrTklN1bfX2HF0 > > QCFlizb+bBga/____d5cEaCv7R8v6m46R4wS779KSUV1jn9____PpHISNcmLafv6dTAb6F+5 > > RBADwBP6coh5LrOJJh0pIByx9dYRbd____if/BSH4VMcvfvFMs/____EO1PAsGLWQPwoNfYO > > 0SzUV1R47JW9NGzeTxja+____byKz9hwGtAT2FIw0NibR+____M1FydPD9k3LTjTnQWgeSro > > ks3AUPDy/hj+E72QDORj+/____Zvy3sw8wDFVRw2LH/____jaDmWbWhZUG4riC3w2egPjcSK > > KIYQ7L/fdeN6S9jt8UcUf1YDHgfLU+______iTgqyssr54RufVuM9iBNOkoWxxI0Q9____oyMF > > NDKiOY8rs2rBu6x09NiHG0BoX1LQzr______rKQFQ4ao48w2RH3ocFCgQbsEHZ18uI____fo4Y > CB5M63nykETHkkR3ZFkd > =8T1Y > -----END PGP SIGNATURE----- > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: GPGTools - https://gpgtools.org > Comment: Using GnuPG with Thunderbird - > http://www.enigmail.net/ > > > iQIcBAEBCgAGBQJUEOV8AAoJEJFMz7____3A1+zrgwAQAJkx74MPOVvbnrG+____dmY8w7ok > > J/6NWt9Rb/____pS9gRrN7iFopni3BoHuLFC6ltwD6Ko____WllYClwoXke4T0FQ/nU6Ar6M > > tsuQMYxP0boxhQua2uF/kZ/____atMolxoNMShNixXd4dnWtBlpl+R+____V58FtfjSGfy49 > > qX2Ge6g6wEFATwKReM1KpKCFIfO/____yq/____wM4NLvvBd6WShJXh6TQBE44y9aXLLJ____IlP > > DApoLnMHaopNZITSNKt1t7dgw6ne9O______370nQwOxR5L0peH8bxla0FLJ57vX+____RCC0f > > 3EV/____tQHKiXET1RqWE927tfPf171Xcq7sdj______LRUL2JTVCK3zPZUuVg9WmuqrLUArhW > > f1XRpn1MM2e0xn18rvHfuRZr2IIUuP____E+RfVcQMgEcgtSYuDNlVYCO/____ONyTQHxJ/E > > JRkN6nDOZ1nlItJlrrT0MVgdMKQLG7____IxkvOndGsyOShD/____XvvjQYlQbDvRvodnAlc > > JUIlcC3PbGZh+____CRymXzu6M7DYceE5rJ/HzbR1UAPM/____dep1P6zA3WyTS15tzIJ93f > > pjLYTciDvPbTOfRTV+____1PQvvVDbHZve34wcjGZHaqV35qUQwX____cd/DQK18L8S7EmDx > > BeBmii/____cX2qBSyzDNGgSjtBTh0AT67tpJQPnH____7brsVc9S75+E/MyDqXZjqiJv/9N > i22XgsD/iTzkP3o0OTjs > =FKVl > -----END PGP SIGNATURE----- > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/____mailman/listinfo/freeipa-users > > __> > Go To http://freeipa.org for more info on the project > > > > > > From danofsatx at gmail.com Thu Sep 18 02:56:36 2014 From: danofsatx at gmail.com (Dan Mossor) Date: Wed, 17 Sep 2014 21:56:36 -0500 Subject: [Freeipa-users] Suggested Upgrade Path Message-ID: <541A49E4.2030105@gmail.com> Good day, folks. I am curious what the suggested upgrade path is for FreeIPA. Currently, I am running freeipa-server-3.3.5-1.fc20.x86_64 on a virtual Fedora 20 server and am planning my upgrade to FreeIPA 4.0.3 on Fedora 21 Server. My current thought is to just build the F21 server and set it up as a replication server, then destroy the F20 VM. Will that be a seamless migration, or am I missing something? -- Dan Mossor, RHCSA Systems Engineer at Large Fedora KDE WG | Fedora QA Team | Fedora Server SIG Fedora Infrastructure Apprentice FAS: dmossor IRC: danofsatx San Antonio, Texas, USA From dpal at redhat.com Thu Sep 18 04:12:57 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 18 Sep 2014 00:12:57 -0400 Subject: [Freeipa-users] Suggested Upgrade Path In-Reply-To: <541A49E4.2030105@gmail.com> References: <541A49E4.2030105@gmail.com> Message-ID: <541A5BC9.5000402@redhat.com> On 09/17/2014 10:56 PM, Dan Mossor wrote: > Good day, folks. > > I am curious what the suggested upgrade path is for FreeIPA. > Currently, I am running freeipa-server-3.3.5-1.fc20.x86_64 on a > virtual Fedora 20 server and am planning my upgrade to FreeIPA 4.0.3 > on Fedora 21 Server. > > My current thought is to just build the F21 server and set it up as a > replication server, then destroy the F20 VM. Will that be a seamless > migration, or am I missing something? Make sure you install the replica with full CA and reconfigure this replica to be the CRL publisher and cert renewal tracker. Search this list archives and wiki on how to do it. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Thu Sep 18 04:19:17 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 18 Sep 2014 00:19:17 -0400 Subject: [Freeipa-users] Two way A/D trust versus one way trust In-Reply-To: <1f12fad24c324ba6b125ec228a6dc243@mail2013.infrasupport.local> References: <0816e253e8d44bddb986e0e70bce13d1@mail2013.infrasupport.local> <82E7C9A01FD0764CACDD35D10F5DFB6E726AFB@001FSN2MPN1-044.001f.mgd2.msft.net> <1f12fad24c324ba6b125ec228a6dc243@mail2013.infrasupport.local> Message-ID: <541A5D45.70105@redhat.com> On 09/17/2014 12:38 AM, Greg Scott wrote: > Thanks everyone for the advice. Here's a sanitized version of what I put together for my end user customer. Feel free to use any of this text as you see fit. > > **************** > > Here's the scoop with IdM and AD trusts. It's an "official" 2-way trust with the currently shipping IdM version - I think it's 3.3.5 right now. It's an official 2-way trust, but de-facto it's only one way because IdM doesn't have all the pieces it needs yet to allow AD to trust IdM. So IdM can trust AD but right now AD cannot trust IdM. Red Hat Support told us that in the support case and I confirmed it with the upstream community. So even though it says it's a 2-way trust, it's really only one way. > > Somewhere in the future, around version 4.3 or so, so it's a long way away, the plan is for IdM to have the pieces it needs for AD to trust IdM. When that time comes, there are a number of options for ***?. One is to stick with today's current version. "If it ain't broke, don't fix it." Another is to continue upgrading to the current versions as they become available and redo the trust to be an official one way trust when the time comes. Another option - just leave it as a 2-way trust. > > The decision doesn't come up for a long time - if I had to guess, I'd put it sometime after 2015. That's just my guess because the people doing the development don't know themselves and they're the ones building this stuff. It's a long time out. And even then, it's not a huge decision. Let's say ***? decides to leave it as a 2-way trust. What are the consequences? Are there now suddenly 2 sources of truth? Is there a security hole? Is AD suddenly vulnerable? > > My answer would be no, no, and no. > > On sources of truth - There will always be a few unique users in the Linux IdM domain. User root, for example, and probably a few others. This is true whether there is no trust, a one-way trust, or a 2-way trust. IdM is like a Windows forest with one domain. And AD is a forest with at least one domain. By definition, both forests have their own individual entities. > > On security holes - with a 2-way trust, the AD Administrator now has the ability to regulate access to AD resources from IdM users and groups. If the AD Admin takes no action, then nobody on the IdM side can access anything on the AD side. Just because the AD administrator has this ability does not imply the he will use it. If he doesn't use it - the default action - nothing happens. > > Is AD suddenly vulnerable? No. Even with a 2-way trust, the AD Admin has to take specific actions in cooperation with others to allow anyone from IdM to access anything inside AD. > > My opinion isn't worth the disk space to store this text and free opinions are worth what you pay for them. So test it yourself. ***? has the tools right now. Build a Windows forest - independent of your Dev forest - and do some experiments with 2-way cross forest trusts. Set up and destroy a few trust relationships with your existing Dev domain/forest and my proposed test forest and grant permissions to a few groups from one side into the other side. You can do it with one Windows VM. Now substitute IdM for that test Windows forest when the time comes and the issues are exactly the same. > > One more point on vulnerability. I know the choice to copy AD users into IdM is well-known, safe, and comfortable at ***?. That's the way they did it last time. But this choice requires non Microsoft software on the ***? AD domain controllers. So thinking it through - which represents the most risk? Setting up a cross forest trust where the AD administrator retains total control over everything, or putting foreign software on the Windows domain controllers to copy user passwords to an untrusted entity? > > - Greg > Bravo! This deserves a wiki page, blog and a keynote at a couple conferences. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From danofsatx at gmail.com Thu Sep 18 04:57:16 2014 From: danofsatx at gmail.com (Dan Mossor) Date: Wed, 17 Sep 2014 23:57:16 -0500 Subject: [Freeipa-users] Kerberized NFS and automount Message-ID: <541A662C.9010206@gmail.com> I have been fighting with getting my NFS servers kerberized since I first installed FreeIPA back in April - I still cannot create a secured NFS mount, and have exhausted all my resources in troublshooting, so I am reaching out to the list since I see many of you have it working. The next step in the puzzle will be to make this work with automount - which again, I can't get this working either. I am missing one key step here, but I can't find it. The documentation for both issues is confusing, especially to someone new to FreeIPA. So first, let's tackle the Kerberized NFS mounts. On the server doing the exporting, here are the pertinent files. /etc/sysconfig/nfs: RPCNFSDARGS="" RPCNFSDCOUNT=8 RPCMOUNTDOPTS="--debug all" STATDARG="" RPCIDMAPDARGS="" RPCGSSDARGS="--debug all" GSS_USE_PROXY="no" RPCSVCGSSDARGS="" My last attempt at an /etc/exports file before I gave up: /home/repo gss/krb5p(rw,no_root_squash,subtree_check,fsid=0) What other information do y'all need to help me get this working? -- Dan Mossor Systems Engineer at Large Fedora QA Team | Fedora KDE SIG | Fedora Server SIG Fedora Infrastructure Apprentice FAS: dmossor IRC: danofsatx San Antonio, Texas, USA From sanju.a at tcs.com Thu Sep 18 05:02:31 2014 From: sanju.a at tcs.com (Sanju A) Date: Thu, 18 Sep 2014 10:32:31 +0530 Subject: [Freeipa-users] sudo setup in Ubuntu In-Reply-To: <54199368.8010505@astron.yasar.com.tr> References: <54199368.8010505@astron.yasar.com.tr> Message-ID: Dear All, I have tried with the settings as mentioned here. But still the issue persists. Regards Sanju Abraham IS - Network/System Administrator Tata Consultancy Services TCS Centre SEZ Unit, Infopark PO, Kochi - 682042,Kerala India Ph:- +91 484 6187490 Mailto: sanju.a at tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ From: Tevfik Ceydeliler To: Date: 17-09-2014 19:46 Subject: Re: [Freeipa-users] sudo setup in Ubuntu Sent by: freeipa-users-bounces at redhat.com Thanks to Lukas: Step 0: Install freipa-client on ubuntu 14.04 and configure sudo integration root at ubuntu1404:/# ipa-client-install --no-ntp root at ubuntu1404:/# echo "sudoers: files sss" >> /etc/nsswitch.conf root at ubuntu1404:/# grep services /etc/sssd/sssd.conf services = nss, pam root at ubuntu1404:/# sed -i -e 's/\(services.*\)/\1, sudo/' /etc/sssd/sssd.conf root at ubuntu1404:/# grep services /etc/sssd/sssd.conf services = nss, pam, sudo Step 1: configure sudo rules for ordinary user Please follow the instructions from FreeIPA documentation. http://www.freeipa.org/docs/master/html-desktop/index.html#sudo This step was skipped, becuase it was already done few months ago Step 2: login to machine as ordinary user, which is allowed to use sudo. $ su usersssd01 Password: $ id uid=325600011(usersssd01) gid=325600011(usersssd01) groups=325600011(usersssd01),30011(biggroup1) Step 3: run command sudo -l // this command should show you which commands can be executed as root // with sudo $ sudo -l sudo: unable to resolve host ubuntu1404.example.test [sudo] password for usersssd01: Matching Defaults entries for usersssd01 on ubuntu1404: env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin User usersssd01 may run the following commands on ubuntu1404: (root) /usr/bin/less, /usr/bin/vim Step 4: If there weren't any problems then user will be able to run command. sudo some_command_listed_in_step3 $ sudo /usr/bin/less /etc/shadow | wc -l 21 $ echo $? 0 $ sudo apt-get install mc Sorry, user usersssd01 is not allowed to execute '/usr/bin/apt-get install mc' as root on ubuntu.example.test. $ echo $? 1 On 17-09-2014 16:54, Sanju A wrote: Dear All, I am able to configure the sudo settings in Centos clients by adding/modifying the entries in /etc/nsswitch.conf and /etc/sudo-ldap.conf. What is the exact steps for the configuration in Ubuntu as I am not able find the configuration file sudo-ldap.conf in Ubuntu. Regards Sanju Abraham IS - Network/System Administrator Tata Consultancy Services TCS Centre SEZ Unit, Infopark PO, Kochi - 682042,Kerala India Ph:- +91 484 6187490 Mailto: sanju.a at tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ =====-----=====-----===== 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 -- Bu elektronik postada bulunan tum fikir ve gorusler ve ekindeki dosyalar sadece adres sahip/sahiplerine ait olup, Yasar Toplulugu Sirketleri bu mesajin icerigi ile ilgili olarak hic bir hukuksal sorumlulugu kabul etmez. Eger gonderilmesi dusunulen kisi veya kurulus degilseniz, lutfen gonderen kisiyi derhal haberdar ediniz ve mesaji sisteminizden siliniz.The information contained in this e-mail and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and Yasar Group Companies do not accept legal responsibility for the contents. If you are not the intended recipient, please immediately notify the sender and delete it from your system. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 7833 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 15216 bytes Desc: not available URL: From tevfik.ceydeliler at astron.yasar.com.tr Thu Sep 18 05:08:29 2014 From: tevfik.ceydeliler at astron.yasar.com.tr (Tevfik Ceydeliler) Date: Thu, 18 Sep 2014 08:08:29 +0300 Subject: [Freeipa-users] sudo setup in Ubuntu In-Reply-To: References: <54199368.8010505@astron.yasar.com.tr> Message-ID: <541A68CD.6080009@astron.yasar.com.tr> Hi, Did u add this user to sudo rule/users ? On 18-09-2014 08:02, Sanju A wrote: > Dear All, > > I have tried with the settings as mentioned here. But still the issue > persists. > > > > > Regards > Sanju Abraham > IS - Network/System Administrator > Tata Consultancy Services > TCS Centre SEZ Unit, > Infopark PO, > Kochi - 682042,Kerala > India > Ph:- +91 484 6187490 > Mailto: sanju.a at tcs.com > Website: http://www.tcs.com > ____________________________________________ > Experience certainty. IT Services > Business Solutions > Consulting > ____________________________________________ > > > > From: Tevfik Ceydeliler > To: > Date: 17-09-2014 19:46 > Subject: Re: [Freeipa-users] sudo setup in Ubuntu > Sent by: freeipa-users-bounces at redhat.com > ------------------------------------------------------------------------ > > > > Thanks to Lukas: > Step 0: Install freipa-client on ubuntu 14.04 and configure sudo > integration > > root at ubuntu1404:/# ipa-client-install --no-ntp > root at ubuntu1404:/# echo "sudoers: files sss" >> /etc/nsswitch.conf > > root at ubuntu1404:/# grep services /etc/sssd/sssd.conf > services = nss, pam > root at ubuntu1404:/# sed -i -e 's/\(services.*\)/\1, sudo/' > /etc/sssd/sssd.conf > root at ubuntu1404:/# grep services /etc/sssd/sssd.conf > services = nss, pam, sudo > > > Step 1: configure sudo rules for ordinary user > Please follow the instructions from FreeIPA documentation. > _http://www.freeipa.org/docs/master/html-desktop/index.html#sudo_ > > > This step was skipped, becuase it was already done few months ago > > > Step 2: login to machine as ordinary user, which is allowed to use sudo. > > $ su usersssd01 > Password: > $ id > uid=325600011(usersssd01) gid=325600011(usersssd01) > groups=325600011(usersssd01),30011(biggroup1) > > > Step 3: run command > sudo -l > // this command should show you which commands can be executed as root > // with sudo > > $ sudo -l > sudo: unable to resolve host ubuntu1404.example.test > [sudo] password for usersssd01: > Matching Defaults entries for usersssd01 on ubuntu1404: > env_reset, mail_badpass, > secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin > > User usersssd01 may run the following commands on ubuntu1404: > (root) /usr/bin/less, /usr/bin/vim > > > Step 4: If there weren't any problems then user will be able to run > command. > sudo some_command_listed_in_step3 > > $ sudo /usr/bin/less /etc/shadow | wc -l > 21 > $ echo $? > 0 > > $ sudo apt-get install mc > Sorry, user usersssd01 is not allowed to execute '/usr/bin/apt-get > install mc' as root on ubuntu.example.test. > $ echo $? > 1 > > On 17-09-2014 16:54, Sanju A wrote: > Dear All, > > I am able to configure the sudo settings in Centos clients by > adding/modifying the entries in /etc/nsswitch.conf and > /etc/sudo-ldap.conf. What is the exact steps for the configuration in > Ubuntu as I am not able find the configuration file sudo-ldap.conf in > Ubuntu. > > > Regards > Sanju Abraham > IS - Network/System Administrator > Tata Consultancy Services > TCS Centre SEZ Unit, > Infopark PO, > Kochi - 682042,Kerala > India > Ph:- +91 484 6187490 > Mailto: _sanju.a at tcs.com_ > Website: _http://www.tcs.com_ > ____________________________________________ > Experience certainty. IT Services > Business Solutions > Consulting > ____________________________________________ > > =====-----=====-----===== > 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 > > > > > -- > > > > > > > Bu elektronik postada bulunan tum fikir ve gorusler ve ekindeki > dosyalar sadece adres sahip/sahiplerine ait olup, Yasar Toplulugu > Sirketleri bu mesajin icerigi ile ilgili olarak hic bir hukuksal > sorumlulugu kabul etmez. Eger gonderilmesi dusunulen kisi veya kurulus > degilseniz, lutfen gonderen kisiyi derhal haberdar ediniz ve mesaji > sisteminizden siliniz.The information contained in this e-mail and any > files transmitted with it are intended solely for the use of the > individual or entity to whom they are addressed and Yasar Group > Companies do not accept legal responsibility for the contents. If you > are not the intended recipient, please immediately notify the sender > and delete it from your system. > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the > project > --


Bu elektronik postada bulunan tum fikir ve gorusler ve ekindeki dosyalar sadece adres sahip/sahiplerine ait olup, Yasar Toplulugu Sirketleri bu mesajin icerigi ile ilgili olarak hic bir hukuksal sorumlulugu kabul etmez. Eger gonderilmesi dusunulen kisi veya kurulus degilseniz, lutfen gonderen kisiyi derhal haberdar ediniz ve mesaji sisteminizden siliniz.The information contained in this e-mail and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and Yasar Group Companies do not accept legal responsibility for the contents. If you are not the intended recipient, please immediately notify the sender and delete it from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 7833 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 15216 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.png Type: image/png Size: 15216 bytes Desc: not available URL: From Johan.Petersson at sscspace.com Thu Sep 18 06:03:41 2014 From: Johan.Petersson at sscspace.com (Johan Petersson) Date: Thu, 18 Sep 2014 06:03:41 +0000 Subject: [Freeipa-users] Kerberized NFS and automount In-Reply-To: <541A662C.9010206@gmail.com> References: <541A662C.9010206@gmail.com> Message-ID: <558C15177F5E714F83334217C9A197DF016C59AE74@SSC-MBX2.ssc.internal> I do not know what OS you are using but if it is RHEL 6 or CentOS 6 you would need to do the following: In /etc/idmapd.conf: Domain = your.domain Add this to /etc/sysconfig/nfs SECURE_NFS="yes" In /etc/exports: /home/repo *(rw,sync,sec=krb5p) Make sure that you use NTP for every server/client and that the time is synced. Add the server to the IPA Domain Create a NFS Service for the server in IPA: ipa service-add nfs/your.server.name Generate a key using ipa-getkeytab -s ipa.server -p nfs/your.nfs.server -k /tmp/nfsserver.keytab # Do this on the nfs server and you can add the key directly to /etc/krb5.keytab. Add a firewall rule for tcp 2049. iptables -I INPUT 5 -p tcp -m state --state NEW,ESTABLISHED --dport 2049 -j ACCEPT Save and restart firewall + the other services and it should work. For RHEL 7 or Fedora it is essentially the same except that you do not add the line to /etc/sysconfig/nfs. Instead you need to enable and start nfs-server and nfs-secure-server using systemctl. For autofs you just need to add a proper direct or indirect map in IPA and on the IPA client run ipa-client-automount. Make sure that the nfs 4 kerberos share is working first before starting with autofs config. mount -t nfs4 -v -o sec=krb5p nfs.server:/home/repo /mnt Hope this could help you get it working. :-) Regards, Johan ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Dan Mossor [danofsatx at gmail.com] Sent: Thursday, September 18, 2014 06:57 To: freeipa-users at redhat.com Subject: [Freeipa-users] Kerberized NFS and automount I have been fighting with getting my NFS servers kerberized since I first installed FreeIPA back in April - I still cannot create a secured NFS mount, and have exhausted all my resources in troublshooting, so I am reaching out to the list since I see many of you have it working. The next step in the puzzle will be to make this work with automount - which again, I can't get this working either. I am missing one key step here, but I can't find it. The documentation for both issues is confusing, especially to someone new to FreeIPA. So first, let's tackle the Kerberized NFS mounts. On the server doing the exporting, here are the pertinent files. /etc/sysconfig/nfs: RPCNFSDARGS="" RPCNFSDCOUNT=8 RPCMOUNTDOPTS="--debug all" STATDARG="" RPCIDMAPDARGS="" RPCGSSDARGS="--debug all" GSS_USE_PROXY="no" RPCSVCGSSDARGS="" My last attempt at an /etc/exports file before I gave up: /home/repo gss/krb5p(rw,no_root_squash,subtree_check,fsid=0) What other information do y'all need to help me get this working? -- Dan Mossor Systems Engineer at Large Fedora QA Team | Fedora KDE SIG | Fedora Server SIG Fedora Infrastructure Apprentice FAS: dmossor IRC: danofsatx San Antonio, Texas, USA -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project This e-mail is private and confidential between the sender and the addressee. In the event of misdirection, the recipient is prohibited from using, copying or disseminating it or any information in it. Please notify the above if any misdirection. From pvoborni at redhat.com Thu Sep 18 08:04:08 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 18 Sep 2014 10:04:08 +0200 Subject: [Freeipa-users] users in groups but user entry does not show groups In-Reply-To: <5419B9BC.70300@phas.ubc.ca> References: <5419B9BC.70300@phas.ubc.ca> Message-ID: <541A91F8.3020401@redhat.com> On 17.9.2014 18:41, Ron wrote: > I have created user groups and entered users. > > When I view the groups under the "User Groups" heading, I see the group > members. > > When I go to the "Users" heading, and click the "User Groups" > sub-heading, IPA does not show any groups (says no entries at bottom). > > See attached png screenshots. > > Any ideas as to what is going on? > > This does not happen for all members of the group. For some users, > there *are* entries for groups under "Users -> User groups" > > Thank you. > Hello Ron, this is indeed a weird behavior. First, let's figure out whether the problem is in Web UI or somewhere else. When you run CLI command: ipa user-show brogOBFUSCATED Does it list 'p309-mm' or any other group name in 'Member of groups' line? On the second screenshot the obfuscated user login looks like it has space in it. I hope it's just an illusion. HTH -- Petr Vobornik From mkosek at redhat.com Thu Sep 18 10:56:52 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 18 Sep 2014 12:56:52 +0200 Subject: [Freeipa-users] Suggested Upgrade Path In-Reply-To: <541A5BC9.5000402@redhat.com> References: <541A49E4.2030105@gmail.com> <541A5BC9.5000402@redhat.com> Message-ID: <541ABA74.5070407@redhat.com> On 09/18/2014 06:12 AM, Dmitri Pal wrote: > On 09/17/2014 10:56 PM, Dan Mossor wrote: >> Good day, folks. >> >> I am curious what the suggested upgrade path is for FreeIPA. Currently, I am >> running freeipa-server-3.3.5-1.fc20.x86_64 on a virtual Fedora 20 server and >> am planning my upgrade to FreeIPA 4.0.3 on Fedora 21 Server. >> >> My current thought is to just build the F21 server and set it up as a >> replication server, then destroy the F20 VM. Will that be a seamless >> migration, or am I missing something? > Make sure you install the replica with full CA and reconfigure this replica to > be the CRL publisher and cert renewal tracker. Search this list archives and > wiki on how to do it. > ... or check the upstream wiki page with detailed instructions: http://www.freeipa.org/page/Howto/Migration#Migrating_existing_FreeIPA_deployment HTH, Martin From andreas.ladanyi at kit.edu Thu Sep 18 12:15:06 2014 From: andreas.ladanyi at kit.edu (Andreas Ladanyi) Date: Thu, 18 Sep 2014 14:15:06 +0200 Subject: [Freeipa-users] Extending FreeIPA 3 Message-ID: <541ACCCA.5080900@kit.edu> Hi, i'am using centos 6.5 and ipa-server 3.0.0, 37.el6 package. I want to expose a ldap attribute in the Web UI and red the following slides: https://www.freeipa.org/images/5/5b/FreeIPA33-extending-freeipa.pdf My problem ist that i cant find a plugin location path /usr/share/ipa/ui/js/plugins , the /js/plugins part does not exist. The slides are for version 3.3. Iam using 3.0.0. Was the plugin subdir changed / renamed ? regards, Andreas From pvoborni at redhat.com Thu Sep 18 12:31:00 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 18 Sep 2014 14:31:00 +0200 Subject: [Freeipa-users] Extending FreeIPA 3 In-Reply-To: <541ACCCA.5080900@kit.edu> References: <541ACCCA.5080900@kit.edu> Message-ID: <541AD084.9080709@redhat.com> On 18.9.2014 14:15, Andreas Ladanyi wrote: > Hi, > > i'am using centos 6.5 and ipa-server 3.0.0, 37.el6 package. > > > I want to expose a ldap attribute in the Web UI and red the following > slides: > https://www.freeipa.org/images/5/5b/FreeIPA33-extending-freeipa.pdf > > My problem ist that i cant find a plugin location path > /usr/share/ipa/ui/js/plugins , the /js/plugins part does not exist. > > The slides are for version 3.3. Iam using 3.0.0. Was the plugin subdir > changed / renamed ? > > regards, > Andreas > Hello Andreas, the described plugin support was added in FreeIPA 3.2 [1] Web UI in IPA 3.0 has very limited extensibility support. User can add his own code to /share/ipa/ui/ext/extension.js but usually it's more easy to edit webui code in /share/ipa/ui/ directly. This approach brings other issues so use at your own risk. [1] https://fedorahosted.org/freeipa/ticket/3235 HTH -- Petr Vobornik From dpal at redhat.com Thu Sep 18 13:39:54 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 18 Sep 2014 09:39:54 -0400 Subject: [Freeipa-users] Kerberized NFS and automount In-Reply-To: <558C15177F5E714F83334217C9A197DF016C59AE74@SSC-MBX2.ssc.internal> References: <541A662C.9010206@gmail.com> <558C15177F5E714F83334217C9A197DF016C59AE74@SSC-MBX2.ssc.internal> Message-ID: <541AE0AA.8040005@redhat.com> On 09/18/2014 02:03 AM, Johan Petersson wrote: > I do not know what OS you are using but if it is RHEL 6 or CentOS 6 you would need to do the following: > > In /etc/idmapd.conf: > > Domain = your.domain > > Add this to /etc/sysconfig/nfs > > SECURE_NFS="yes" > > In /etc/exports: > > /home/repo *(rw,sync,sec=krb5p) > > Make sure that you use NTP for every server/client and that the time is synced. > > Add the server to the IPA Domain > > Create a NFS Service for the server in IPA: > > ipa service-add nfs/your.server.name > > Generate a key using ipa-getkeytab -s ipa.server -p nfs/your.nfs.server -k /tmp/nfsserver.keytab # Do this on the nfs server and you can add the key directly to /etc/krb5.keytab. > > Add a firewall rule for tcp 2049. > > iptables -I INPUT 5 -p tcp -m state --state NEW,ESTABLISHED --dport 2049 -j ACCEPT > > Save and restart firewall + the other services and it should work. > > For RHEL 7 or Fedora it is essentially the same except that you do not add the line to /etc/sysconfig/nfs. > > Instead you need to enable and start nfs-server and nfs-secure-server using systemctl. > > For autofs you just need to add a proper direct or indirect map in IPA and on the IPA client run ipa-client-automount. > > Make sure that the nfs 4 kerberos share is working first before starting with autofs config. > > mount -t nfs4 -v -o sec=krb5p nfs.server:/home/repo /mnt > > Hope this could help you get it working. :-) > > Regards, > Johan > > ________________________________________ > From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Dan Mossor [danofsatx at gmail.com] > Sent: Thursday, September 18, 2014 06:57 > To: freeipa-users at redhat.com > Subject: [Freeipa-users] Kerberized NFS and automount > > I have been fighting with getting my NFS servers kerberized since I > first installed FreeIPA back in April - I still cannot create a secured > NFS mount, and have exhausted all my resources in troublshooting, so I > am reaching out to the list since I see many of you have it working. > > The next step in the puzzle will be to make this work with automount - > which again, I can't get this working either. I am missing one key step > here, but I can't find it. The documentation for both issues is > confusing, especially to someone new to FreeIPA. > > So first, let's tackle the Kerberized NFS mounts. On the server doing > the exporting, here are the pertinent files. > /etc/sysconfig/nfs: > RPCNFSDARGS="" > RPCNFSDCOUNT=8 > RPCMOUNTDOPTS="--debug all" > STATDARG="" > RPCIDMAPDARGS="" > RPCGSSDARGS="--debug all" > GSS_USE_PROXY="no" > RPCSVCGSSDARGS="" > > My last attempt at an /etc/exports file before I gave up: > /home/repo gss/krb5p(rw,no_root_squash,subtree_check,fsid=0) > > What other information do y'all need to help me get this working? > -- > Dan Mossor > Systems Engineer at Large > Fedora QA Team | Fedora KDE SIG | Fedora Server SIG > Fedora Infrastructure Apprentice > FAS: dmossor IRC: danofsatx > San Antonio, Texas, USA > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > This e-mail is private and confidential between the sender and the addressee. > In the event of misdirection, the recipient is prohibited from using, copying or disseminating it or any information in it. Please notify the above if any misdirection. > > There are also couple resources on the wiki: http://www.freeipa.org/page/HowTos -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From walid.shaari at linux.com Thu Sep 18 14:12:01 2014 From: walid.shaari at linux.com (Walid A. Shaari) Date: Thu, 18 Sep 2014 17:12:01 +0300 Subject: [Freeipa-users] Client Certificate Message-ID: Hi, we are going to have a use case of diskless HPC clients that will use the IPA for lookups, I was wondering if i can get rid of the state-fulness of the client configuration as much as possible as it is more of a cattle than pets use case. that is i do not need to know that the client is part of the domain, no need to enroll a node with a certificate. and services will be mostly hpc mpi and ssh, not required to have an SSL certificate for secure communication. is it possible to get rid of the client certificate and the requirements for clients to enroll? or there are other uses for the certificate that i am not aware of ? regards Walid -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Sep 18 14:43:22 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 18 Sep 2014 10:43:22 -0400 Subject: [Freeipa-users] Client Certificate In-Reply-To: References: Message-ID: <541AEF8A.3050807@redhat.com> Walid A. Shaari wrote: > Hi, > > we are going to have a use case of diskless HPC clients that will use > the IPA for lookups, I was wondering if i can get rid of the > state-fulness of the client configuration as much as possible as it is > more of a cattle than pets use case. that is i do not need to know that > the client is part of the domain, no need to enroll a node with a > certificate. and services will be mostly hpc mpi and ssh, not required > to have an SSL certificate for secure communication. is it possible to > get rid of the client certificate and the requirements for clients to > enroll? or there are other uses for the certificate that i am not aware of ? Yes, you don't need to obtain a machine certificate. In fact we have stopped doing this upstream. rob From simo at redhat.com Thu Sep 18 14:55:20 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 18 Sep 2014 10:55:20 -0400 Subject: [Freeipa-users] Kerberized NFS and automount In-Reply-To: <558C15177F5E714F83334217C9A197DF016C59AE74@SSC-MBX2.ssc.internal> References: <541A662C.9010206@gmail.com> <558C15177F5E714F83334217C9A197DF016C59AE74@SSC-MBX2.ssc.internal> Message-ID: <20140918105520.4ddc0ccd@willson.usersys.redhat.com> On Thu, 18 Sep 2014 06:03:41 +0000 Johan Petersson wrote: > ipa service-add nfs/your.server.name > > Generate a key using ipa-getkeytab -s ipa.server -p > nfs/your.nfs.server -k /tmp/nfsserver.keytab # Do this on the nfs > server and you can add the key directly to /etc/krb5.keytab. Note that you may want to do the same on clients. Create a nfs service key for clients and stick it in /etc/krb5.keytab It should work using the host key if you don't though. Simo. -- Simo Sorce * Red Hat, Inc * New York From walid.shaari at linux.com Thu Sep 18 15:49:44 2014 From: walid.shaari at linux.com (Walid A. Shaari) Date: Thu, 18 Sep 2014 18:49:44 +0300 Subject: [Freeipa-users] Client Certificate In-Reply-To: <541AEF8A.3050807@redhat.com> References: <541AEF8A.3050807@redhat.com> Message-ID: Great Rob, would that be still doable with RHEL5 and RHEL6 ipa 2, and 3 clients? On 18 September 2014 17:43, Rob Crittenden wrote: > Walid A. Shaari wrote: > > Hi, > > > > we are going to have a use case of diskless HPC clients that will use > > the IPA for lookups, I was wondering if i can get rid of the > > state-fulness of the client configuration as much as possible as it is > > more of a cattle than pets use case. that is i do not need to know that > > the client is part of the domain, no need to enroll a node with a > > certificate. and services will be mostly hpc mpi and ssh, not required > > to have an SSL certificate for secure communication. is it possible to > > get rid of the client certificate and the requirements for clients to > > enroll? or there are other uses for the certificate that i am not aware > of ? > > Yes, you don't need to obtain a machine certificate. In fact we have > stopped doing this upstream. > > rob > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Thu Sep 18 16:13:50 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 18 Sep 2014 12:13:50 -0400 Subject: [Freeipa-users] Client Certificate In-Reply-To: References: <541AEF8A.3050807@redhat.com> Message-ID: <20140918121350.32218860@willson.usersys.redhat.com> On Thu, 18 Sep 2014 18:49:44 +0300 "Walid A. Shaari" wrote: > Great Rob, would that be still doable with RHEL5 and RHEL6 ipa 2, and > 3 clients? The X509 certificate has always been provided as a commodity but never required. Keytabs are the only thing we require. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Thu Sep 18 16:21:49 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 18 Sep 2014 12:21:49 -0400 Subject: [Freeipa-users] Client Certificate In-Reply-To: References: <541AEF8A.3050807@redhat.com> Message-ID: <541B069D.4020005@redhat.com> Walid A. Shaari wrote: > Great Rob, would that be still doable with RHEL5 and RHEL6 ipa 2, and 3 > clients? Sure, the cert isn't used anyway but it isn't optional to have certmonger try to get one. If you really care you can run a command to tell certmonger to stop tracking the cert though: # ipa-getcert stop-tracking -d /etc/pki/nssdb -n 'IPA Machine Certificate - client.example.com' That doesn't remove the certificate from the database. If you want to do that do: # certutil -D -d /etc/pki/nssdb/ -n 'IPA Machine Certificate - client.example.com' And you might to revoke the cert. To do that you'd use ipa cert-revoke . You need pretty high privileges to do that though (admin has them). rob > > On 18 September 2014 17:43, Rob Crittenden > wrote: > > Walid A. Shaari wrote: > > Hi, > > > > we are going to have a use case of diskless HPC clients that will use > > the IPA for lookups, I was wondering if i can get rid of the > > state-fulness of the client configuration as much as possible as it is > > more of a cattle than pets use case. that is i do not need to know > that > > the client is part of the domain, no need to enroll a node with a > > certificate. and services will be mostly hpc mpi and ssh, not required > > to have an SSL certificate for secure communication. is it possible to > > get rid of the client certificate and the requirements for clients to > > enroll? or there are other uses for the certificate that i am not > aware of ? > > Yes, you don't need to obtain a machine certificate. In fact we have > stopped doing this upstream. > > rob > > From natxo.asenjo at gmail.com Thu Sep 18 16:35:16 2014 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Thu, 18 Sep 2014 18:35:16 +0200 Subject: [Freeipa-users] Client Certificate In-Reply-To: <541AEF8A.3050807@redhat.com> References: <541AEF8A.3050807@redhat.com> Message-ID: hi, On Thu, Sep 18, 2014 at 4:43 PM, Rob Crittenden wrote: > > Yes, you don't need to obtain a machine certificate. In fact we have > stopped doing this upstream. > > Do you mean ipa will not have a CA in the future? Or will it be optional? Or am I misunderstanding this :-) ? I quite like the CA stuff in ipa, actually. -- Groeten, natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Thu Sep 18 17:04:19 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 18 Sep 2014 20:04:19 +0300 Subject: [Freeipa-users] Client Certificate In-Reply-To: References: <541AEF8A.3050807@redhat.com> Message-ID: <20140918170419.GB2541@redhat.com> On Thu, 18 Sep 2014, Natxo Asenjo wrote: >hi, > >On Thu, Sep 18, 2014 at 4:43 PM, Rob Crittenden wrote: > >> >> Yes, you don't need to obtain a machine certificate. In fact we have >> stopped doing this upstream. >> >> >Do you mean ipa will not have a CA in the future? Or will it be optional? >Or am I misunderstanding this :-) ? I quite like the CA stuff in ipa, >actually. host certificate is not used for anything right now, so it is removed in 4.x. All the rest is in place and CA can be external one. -- / Alexander Bokovoy From rcritten at redhat.com Thu Sep 18 19:05:49 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 18 Sep 2014 15:05:49 -0400 Subject: [Freeipa-users] Client Certificate In-Reply-To: References: <541AEF8A.3050807@redhat.com> Message-ID: <541B2D0D.6090304@redhat.com> Natxo Asenjo wrote: > hi, > > On Thu, Sep 18, 2014 at 4:43 PM, Rob Crittenden > wrote: > > > Yes, you don't need to obtain a machine certificate. In fact we have > stopped doing this upstream. > > > Do you mean ipa will not have a CA in the future? Or will it be > optional? Or am I misunderstanding this :-) ? I quite like the CA stuff > in ipa, actually. > No, don't worry, the CA isn't going anywhere :-) On the client right now we retrieve a certificate for host identity and store it in /etc/pki/nssdb. We did this for future proofing and here we are, pretty far in the future, and we've never used it. So we decided to stop generating it. If on the off chance it turns out we're wrong and someone has actually found a use for that certificate it can be quite easily generated using ipa-getcert after the client is enrolled. rob From dpal at redhat.com Thu Sep 18 20:04:46 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 18 Sep 2014 16:04:46 -0400 Subject: [Freeipa-users] Client Certificate In-Reply-To: References: Message-ID: <541B3ADE.7000706@redhat.com> On 09/18/2014 10:12 AM, Walid A. Shaari wrote: > Hi, > > we are going to have a use case of diskless HPC clients that will use > the IPA for lookups, I was wondering if i can get rid of the > state-fulness of the client configuration as much as possible as it is > more of a cattle than pets use case. that is i do not need to know > that the client is part of the domain, no need to enroll a node with a > certificate. and services will be mostly hpc mpi and ssh, not required > to have an SSL certificate for secure communication. is it possible to > get rid of the client certificate and the requirements for clients to > enroll? or there are other uses for the certificate that i am not > aware of ? > > regards > > Walid > > I think the main problem is making sure that the client can connect to IPA server. You can elect to not use ipa-client and just copy configuration files. The problem is that SSSD requires some type of the authentication to get to IPA as a host to do the lookups. So this connection must be authenticated. Since you want it to be stateless you do not want to manage keys or certs the only option (which I really do not like) is to use bind password in a file for LDAP connection. You would probably use the same unprivileged account for this bind. However when we get to 4.x you would need to adjust permissions on the server side to make sure that proper read permissions are granted. Having a password in a file is a security risk so make sure it is not leaked. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From natxo.asenjo at gmail.com Thu Sep 18 20:20:54 2014 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Thu, 18 Sep 2014 22:20:54 +0200 Subject: [Freeipa-users] Client Certificate In-Reply-To: <541B2D0D.6090304@redhat.com> References: <541AEF8A.3050807@redhat.com> <541B2D0D.6090304@redhat.com> Message-ID: hi, On Thu, Sep 18, 2014 at 9:05 PM, Rob Crittenden wrote: > Natxo Asenjo wrote: > > hi, > > > > On Thu, Sep 18, 2014 at 4:43 PM, Rob Crittenden > > wrote: > > > > > > Yes, you don't need to obtain a machine certificate. In fact we have > > stopped doing this upstream. > > > > > > Do you mean ipa will not have a CA in the future? Or will it be > > optional? Or am I misunderstanding this :-) ? I quite like the CA stuff > > in ipa, actually. > > > > No, don't worry, the CA isn't going anywhere :-) > > On the client right now we retrieve a certificate for host identity and > store it in /etc/pki/nssdb. We did this for future proofing and here we > are, pretty far in the future, and we've never used it. So we decided to > stop generating it. > > If on the off chance it turns out we're wrong and someone has actually > found a use for that certificate it can be quite easily generated using > ipa-getcert after the client is enrolled. > > ok. I was thinking on starting a pilot with dot1.x and hosts certificates are usually used for this, so it would be nice to have a cli switch during enrollment. -- groet, natxo -- -- Groeten, natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Sep 18 20:51:35 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 18 Sep 2014 16:51:35 -0400 Subject: [Freeipa-users] Client Certificate In-Reply-To: References: <541AEF8A.3050807@redhat.com> <541B2D0D.6090304@redhat.com> Message-ID: <541B45D7.5090800@redhat.com> Natxo Asenjo wrote: > hi, > > On Thu, Sep 18, 2014 at 9:05 PM, Rob Crittenden > wrote: > > Natxo Asenjo wrote: > > hi, > > > > On Thu, Sep 18, 2014 at 4:43 PM, Rob Crittenden > > >> wrote: > > > > > > Yes, you don't need to obtain a machine certificate. In fact we have > > stopped doing this upstream. > > > > > > Do you mean ipa will not have a CA in the future? Or will it be > > optional? Or am I misunderstanding this :-) ? I quite like the CA stuff > > in ipa, actually. > > > > No, don't worry, the CA isn't going anywhere :-) > > On the client right now we retrieve a certificate for host identity and > store it in /etc/pki/nssdb. We did this for future proofing and here we > are, pretty far in the future, and we've never used it. So we decided to > stop generating it. > > If on the off chance it turns out we're wrong and someone has actually > found a use for that certificate it can be quite easily generated using > ipa-getcert after the client is enrolled. > > > ok. I was thinking on starting a pilot with dot1.x and hosts > certificates are usually used for this, so it would be nice to have a > cli switch during enrollment. Ok, do you have a preference on where the cert would be installed? Currently it is added to /etc/pki/nssdb but we were going to move it to /etc/ipa/nssdb before deciding to drop it altogether. I think if we restore the functionality we'll use the later database. I filed https://fedorahosted.org/freeipa/ticket/4550 rob From natxo.asenjo at gmail.com Thu Sep 18 21:12:28 2014 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Thu, 18 Sep 2014 23:12:28 +0200 Subject: [Freeipa-users] Client Certificate In-Reply-To: <541B45D7.5090800@redhat.com> References: <541AEF8A.3050807@redhat.com> <541B2D0D.6090304@redhat.com> <541B45D7.5090800@redhat.com> Message-ID: On Thu, Sep 18, 2014 at 10:51 PM, Rob Crittenden wrote: > Natxo Asenjo wrote: > > ok. I was thinking on starting a pilot with dot1.x and hosts > > certificates are usually used for this, so it would be nice to have a > > cli switch during enrollment. > > Ok, do you have a preference on where the cert would be installed? > Currently it is added to /etc/pki/nssdb but we were going to move it to > /etc/ipa/nssdb before deciding to drop it altogether. I think if we > restore the functionality we'll use the later database. > > I filed https://fedorahosted.org/freeipa/ticket/4550 > rob Not really, although having all kind of certificates in /etc/pki is convenient or is where we all expect them to be ... Thanks for taking the time to file the RFE, by the way. -- Groeten, natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri Sep 19 20:14:54 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 19 Sep 2014 16:14:54 -0400 Subject: [Freeipa-users] Client Certificate In-Reply-To: References: <541B3ADE.7000706@redhat.com> Message-ID: <541C8EBE.7070108@redhat.com> On 09/19/2014 04:03 PM, Walid wrote: > Thank you all, will investigate the requirements of host keytabs, and > if there is a way around it by having it shared but secure for our > context. Couple hints. 1. If you have a keytab stashed and the system was rebuilt you can now rerun ipa-client-install using this keytab to get a new one and configure the client system. It can run and then die but if you store the keytab after running ipa-client-install you would be able to revive it next time 2. In 4.1 you will be able to retrieve same keytab using ipa-getkeytab command. It is implemented to allow clusters that have to share the same key but it might be applicable to your use case too. Thanks Dmitri > > On 18 September 2014 23:04, Dmitri Pal > wrote: > > On 09/18/2014 10:12 AM, Walid A. Shaari wrote: >> Hi, >> >> we are going to have a use case of diskless HPC clients that will >> use the IPA for lookups, I was wondering if i can get rid of the >> state-fulness of the client configuration as much as possible as >> it is more of a cattle than pets use case. that is i do not need >> to know that the client is part of the domain, no need to enroll >> a node with a certificate. and services will be mostly hpc mpi >> and ssh, not required to have an SSL certificate for secure >> communication. is it possible to get rid of the client >> certificate and the requirements for clients to enroll? or there >> are other uses for the certificate that i am not aware of ? >> >> regards >> >> Walid >> >> > I think the main problem is making sure that the client can > connect to IPA server. > You can elect to not use ipa-client and just copy configuration > files. The problem is that SSSD requires some type of the > authentication to get to IPA as a host to do the lookups. > So this connection must be authenticated. Since you want it to be > stateless you do not want to manage keys or certs the only option > (which I really do not like) is to use bind password in a file for > LDAP connection. You would probably use the same unprivileged > account for this bind. However when we get to 4.x you would need > to adjust permissions on the server side to make sure that proper > read permissions are granted. Having a password in a file is a > security risk so make sure it is not leaked. > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From genadipost at gmail.com Fri Sep 19 20:17:00 2014 From: genadipost at gmail.com (Genadi Postrilko) Date: Fri, 19 Sep 2014 23:17:00 +0300 Subject: [Freeipa-users] AD Trust - Cannot resolve servers for KDC after reboot In-Reply-To: <20140916072831.GY2947@localhost.localdomain> References: <20140916072831.GY2947@localhost.localdomain> Message-ID: I have recreated the "problem". Rebooted the AD and now cannot kinit with AD users. [root at ipaserver1 ~]# KRB5_TRACE=/dev/stdout kinit Yoni at BLUE.COM [22865] 1411157693.26121: Resolving unique ccache of type KEYRING [22865] 1411157693.26167: Getting initial credentials for Yoni at BLUE.COM [22865] 1411157693.28577: Sending request (156 bytes) to BLUE.COM kinit: Cannot resolve servers for KDC in realm "BLUE.COM" while getting initial credentials The AD configured as forwarder: [root at ipaserver1 ~]# ipa dnsconfig-show Global forwarders: 192.168.227.60 i can ping the AD machine. 2014-09-16 10:28 GMT+03:00 Sumit Bose : > On Tue, Sep 16, 2014 at 01:39:41AM +0300, Genadi Postrilko wrote: > > Hello all ! > > > > I have deployed test environment for AD trust feature, the environment > > contains : > > Windows Server 2008 - AD Server. > > RHEL 7 - IPA 3.3 Server. > > RHEL 6.2 - IPA Client. > > > > I have established the trust as IPA in the sub domain of AD. > > AD DNS domain - blue.com > > IPA DNS domain - linux.blue.com > > > > All was working fine as i was able to kinit with AD users: > > > > [root at ipaserver1 ~]# kinit Yoni at BLUE.COM > > Password for Yoni at BLUE.COM: > > > > [root at ipaserver1 ~]# klist > > Ticket cache: KEYRING:persistent:0:krb_ccache_oi15FrE > > Default principal: Yoni at BLUE.COM > > > > Valid starting Expires Service principal > > 09/16/2014 01:00:25 09/16/2014 11:00:25 krbtgt/BLUE.COM at BLUE.COM > > renew until 09/17/2014 01:00:20 > > > > But after i rebooted the Windows Server Machine, i could not kinit with > AD > > users anymore: > > [root at ipaserver1 ~]# kinit Yoni at BLUE.COM > > kinit: Cannot resolve servers for KDC in realm "BLUE.COM" while getting > > initial > > The only IPA component used for kinit is the DNS server. How did you > configure DNS (glue records? forwarder?). To get more details about what > is failing you can call: > > KRB5_TRACE=/dev/stdout kinit Yoni at BLUE.COM > > HTH > > bye, > Sumit > > > > > I have checked if all the IPA services where UP: > > > > [root at ipaserver1 ~]# ipactl status > > Directory Service: RUNNING > > krb5kdc Service: RUNNING > > kadmin Service: RUNNING > > named Service: RUNNING > > ipa_memcached Service: RUNNING > > httpd Service: RUNNING > > pki-tomcatd Service: RUNNING > > smb Service: RUNNING > > winbind Service: RUNNING > > ipa-otpd Service: RUNNING > > ipa: INFO: The ipactl command was successful > > > > After i restarted IPA services (ipactl restart), i was able to to kinit > > again. > > Restarting smb service would do the job as well (?). > > > > Just wanted to know if it is a know issue, or the AD should be re > > discovered if it reboots. > > I think i seen an issue about it in the mailing list some time ago (not > > sure). > > > > I did not increase the debug level and got the logs. > > But i can share the ipa and sssd version: > > > > rpm -qa | grep ipa > > ipa-server-3.3.3-28.el7_0.1.x86_64 > > python-iniparse-0.4-9.el7.noarch > > libipa_hbac-1.11.2-68.el7_0.5.x86_64 > > ipa-admintools-3.3.3-28.el7_0.1.x86_64 > > ipa-server-trust-ad-3.3.3-28.el7_0.1.x86_64 > > ipa-python-3.3.3-28.el7_0.1.x86_64 > > sssd-ipa-1.11.2-68.el7_0.5.x86_64 > > iniparser-3.1-5.el7.x86_64 > > libipa_hbac-python-1.11.2-68.el7_0.5.x86_64 > > ipa-client-3.3.3-28.el7_0.1.x86_64 > > > > rpm -qa | grep sssd > > sssd-krb5-common-1.11.2-68.el7_0.5.x86_64 > > sssd-ldap-1.11.2-68.el7_0.5.x86_64 > > sssd-common-1.11.2-68.el7_0.5.x86_64 > > sssd-common-pac-1.11.2-68.el7_0.5.x86_64 > > sssd-ad-1.11.2-68.el7_0.5.x86_64 > > sssd-krb5-1.11.2-68.el7_0.5.x86_64 > > sssd-1.11.2-68.el7_0.5.x86_64 > > python-sssdconfig-1.11.2-68.el7_0.5.noarch > > sssd-ipa-1.11.2-68.el7_0.5.x86_64 > > sssd-proxy-1.11.2-68.el7_0.5.x86_64 > > sssd-client-1.11.2-68.el7_0.5.x86_64 > > > > Thanks for all the helpers. > > > -- > > Manage your subscription for the Freeipa-users mailing list: > > https://www.redhat.com/mailman/listinfo/freeipa-users > > Go To http://freeipa.org for more info on the project > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From walid.shaari at gmail.com Fri Sep 19 20:03:06 2014 From: walid.shaari at gmail.com (Walid) Date: Fri, 19 Sep 2014 23:03:06 +0300 Subject: [Freeipa-users] Client Certificate In-Reply-To: <541B3ADE.7000706@redhat.com> References: <541B3ADE.7000706@redhat.com> Message-ID: Thank you all, will investigate the requirements of host keytabs, and if there is a way around it by having it shared but secure for our context. On 18 September 2014 23:04, Dmitri Pal wrote: > On 09/18/2014 10:12 AM, Walid A. Shaari wrote: > > Hi, > > we are going to have a use case of diskless HPC clients that will use > the IPA for lookups, I was wondering if i can get rid of the state-fulness > of the client configuration as much as possible as it is more of a cattle > than pets use case. that is i do not need to know that the client is part > of the domain, no need to enroll a node with a certificate. and services > will be mostly hpc mpi and ssh, not required to have an SSL certificate for > secure communication. is it possible to get rid of the client certificate > and the requirements for clients to enroll? or there are other uses for the > certificate that i am not aware of ? > > regards > > Walid > > > I think the main problem is making sure that the client can connect to > IPA server. > You can elect to not use ipa-client and just copy configuration files. The > problem is that SSSD requires some type of the authentication to get to IPA > as a host to do the lookups. > So this connection must be authenticated. Since you want it to be > stateless you do not want to manage keys or certs the only option (which I > really do not like) is to use bind password in a file for LDAP connection. > You would probably use the same unprivileged account for this bind. However > when we get to 4.x you would need to adjust permissions on the server side > to make sure that proper read permissions are granted. Having a password in > a file is a security risk so make sure it is not leaked. > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Fri Sep 19 20:40:09 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 19 Sep 2014 23:40:09 +0300 Subject: [Freeipa-users] AD Trust - Cannot resolve servers for KDC after reboot In-Reply-To: References: <20140916072831.GY2947@localhost.localdomain> Message-ID: <20140919204009.GG2541@redhat.com> On Fri, 19 Sep 2014, Genadi Postrilko wrote: >I have recreated the "problem". >Rebooted the AD and now cannot kinit with AD users. > >[root at ipaserver1 ~]# KRB5_TRACE=/dev/stdout kinit Yoni at BLUE.COM >[22865] 1411157693.26121: Resolving unique ccache of type KEYRING >[22865] 1411157693.26167: Getting initial credentials for Yoni at BLUE.COM >[22865] 1411157693.28577: Sending request (156 bytes) to BLUE.COM >kinit: Cannot resolve servers for KDC in realm "BLUE.COM" while getting >initial credentials > >The AD configured as forwarder: > >[root at ipaserver1 ~]# ipa dnsconfig-show > Global forwarders: 192.168.227.60 > >i can ping the AD machine. If you rebooted AD DC, it takes time to start up its services. If Kerberos library cannot resolve SRV records for BLUE.COM, it means DNS service on AD DC didn't start up yet and cannot respond to DNS queries. > >2014-09-16 10:28 GMT+03:00 Sumit Bose : > >> On Tue, Sep 16, 2014 at 01:39:41AM +0300, Genadi Postrilko wrote: >> > Hello all ! >> > >> > I have deployed test environment for AD trust feature, the environment >> > contains : >> > Windows Server 2008 - AD Server. >> > RHEL 7 - IPA 3.3 Server. >> > RHEL 6.2 - IPA Client. >> > >> > I have established the trust as IPA in the sub domain of AD. >> > AD DNS domain - blue.com >> > IPA DNS domain - linux.blue.com >> > >> > All was working fine as i was able to kinit with AD users: >> > >> > [root at ipaserver1 ~]# kinit Yoni at BLUE.COM >> > Password for Yoni at BLUE.COM: >> > >> > [root at ipaserver1 ~]# klist >> > Ticket cache: KEYRING:persistent:0:krb_ccache_oi15FrE >> > Default principal: Yoni at BLUE.COM >> > >> > Valid starting Expires Service principal >> > 09/16/2014 01:00:25 09/16/2014 11:00:25 krbtgt/BLUE.COM at BLUE.COM >> > renew until 09/17/2014 01:00:20 >> > >> > But after i rebooted the Windows Server Machine, i could not kinit with >> AD >> > users anymore: >> > [root at ipaserver1 ~]# kinit Yoni at BLUE.COM >> > kinit: Cannot resolve servers for KDC in realm "BLUE.COM" while getting >> > initial >> >> The only IPA component used for kinit is the DNS server. How did you >> configure DNS (glue records? forwarder?). To get more details about what >> is failing you can call: >> >> KRB5_TRACE=/dev/stdout kinit Yoni at BLUE.COM >> >> HTH >> >> bye, >> Sumit >> >> > >> > I have checked if all the IPA services where UP: >> > >> > [root at ipaserver1 ~]# ipactl status >> > Directory Service: RUNNING >> > krb5kdc Service: RUNNING >> > kadmin Service: RUNNING >> > named Service: RUNNING >> > ipa_memcached Service: RUNNING >> > httpd Service: RUNNING >> > pki-tomcatd Service: RUNNING >> > smb Service: RUNNING >> > winbind Service: RUNNING >> > ipa-otpd Service: RUNNING >> > ipa: INFO: The ipactl command was successful >> > >> > After i restarted IPA services (ipactl restart), i was able to to kinit >> > again. >> > Restarting smb service would do the job as well (?). >> > >> > Just wanted to know if it is a know issue, or the AD should be re >> > discovered if it reboots. >> > I think i seen an issue about it in the mailing list some time ago (not >> > sure). >> > >> > I did not increase the debug level and got the logs. >> > But i can share the ipa and sssd version: >> > >> > rpm -qa | grep ipa >> > ipa-server-3.3.3-28.el7_0.1.x86_64 >> > python-iniparse-0.4-9.el7.noarch >> > libipa_hbac-1.11.2-68.el7_0.5.x86_64 >> > ipa-admintools-3.3.3-28.el7_0.1.x86_64 >> > ipa-server-trust-ad-3.3.3-28.el7_0.1.x86_64 >> > ipa-python-3.3.3-28.el7_0.1.x86_64 >> > sssd-ipa-1.11.2-68.el7_0.5.x86_64 >> > iniparser-3.1-5.el7.x86_64 >> > libipa_hbac-python-1.11.2-68.el7_0.5.x86_64 >> > ipa-client-3.3.3-28.el7_0.1.x86_64 >> > >> > rpm -qa | grep sssd >> > sssd-krb5-common-1.11.2-68.el7_0.5.x86_64 >> > sssd-ldap-1.11.2-68.el7_0.5.x86_64 >> > sssd-common-1.11.2-68.el7_0.5.x86_64 >> > sssd-common-pac-1.11.2-68.el7_0.5.x86_64 >> > sssd-ad-1.11.2-68.el7_0.5.x86_64 >> > sssd-krb5-1.11.2-68.el7_0.5.x86_64 >> > sssd-1.11.2-68.el7_0.5.x86_64 >> > python-sssdconfig-1.11.2-68.el7_0.5.noarch >> > sssd-ipa-1.11.2-68.el7_0.5.x86_64 >> > sssd-proxy-1.11.2-68.el7_0.5.x86_64 >> > sssd-client-1.11.2-68.el7_0.5.x86_64 >> > >> > Thanks for all the helpers. >> >> > -- >> > Manage your subscription for the Freeipa-users mailing list: >> > https://www.redhat.com/mailman/listinfo/freeipa-users >> > Go To http://freeipa.org for more info on the project >> >> >-- >Manage your subscription for the Freeipa-users mailing list: >https://www.redhat.com/mailman/listinfo/freeipa-users >Go To http://freeipa.org for more info on the project -- / Alexander Bokovoy From genadipost at gmail.com Fri Sep 19 21:15:44 2014 From: genadipost at gmail.com (Genadi Postrilko) Date: Sat, 20 Sep 2014 00:15:44 +0300 Subject: [Freeipa-users] AD Trust - Cannot resolve servers for KDC after reboot In-Reply-To: <20140919204009.GG2541@redhat.com> References: <20140916072831.GY2947@localhost.localdomain> <20140919204009.GG2541@redhat.com> Message-ID: The DNS server service of AD is running. I am able to resolve with nslookup command. I have just restarted the named service and i am able to kinit again. It looks like the named deamon, cannot recognize that the forwarder is back online. Is there some caching mechanism implemented for the forwarders? 2014-09-19 23:40 GMT+03:00 Alexander Bokovoy : > On Fri, 19 Sep 2014, Genadi Postrilko wrote: > >> I have recreated the "problem". >> Rebooted the AD and now cannot kinit with AD users. >> >> [root at ipaserver1 ~]# KRB5_TRACE=/dev/stdout kinit Yoni at BLUE.COM >> [22865] 1411157693.26121: Resolving unique ccache of type KEYRING >> [22865] 1411157693.26167: Getting initial credentials for Yoni at BLUE.COM >> [22865] 1411157693.28577: Sending request (156 bytes) to BLUE.COM >> kinit: Cannot resolve servers for KDC in realm "BLUE.COM" while getting >> initial credentials >> >> The AD configured as forwarder: >> >> [root at ipaserver1 ~]# ipa dnsconfig-show >> Global forwarders: 192.168.227.60 >> >> i can ping the AD machine. >> > If you rebooted AD DC, it takes time to start up its services. If > Kerberos library cannot resolve SRV records for BLUE.COM, it means DNS > service on AD DC didn't start up yet and cannot respond to DNS queries. > > > > >> 2014-09-16 10:28 GMT+03:00 Sumit Bose : >> >> On Tue, Sep 16, 2014 at 01:39:41AM +0300, Genadi Postrilko wrote: >>> > Hello all ! >>> > >>> > I have deployed test environment for AD trust feature, the environment >>> > contains : >>> > Windows Server 2008 - AD Server. >>> > RHEL 7 - IPA 3.3 Server. >>> > RHEL 6.2 - IPA Client. >>> > >>> > I have established the trust as IPA in the sub domain of AD. >>> > AD DNS domain - blue.com >>> > IPA DNS domain - linux.blue.com >>> > >>> > All was working fine as i was able to kinit with AD users: >>> > >>> > [root at ipaserver1 ~]# kinit Yoni at BLUE.COM >>> > Password for Yoni at BLUE.COM: >>> > >>> > [root at ipaserver1 ~]# klist >>> > Ticket cache: KEYRING:persistent:0:krb_ccache_oi15FrE >>> > Default principal: Yoni at BLUE.COM >>> > >>> > Valid starting Expires Service principal >>> > 09/16/2014 01:00:25 09/16/2014 11:00:25 krbtgt/BLUE.COM at BLUE.COM >>> > renew until 09/17/2014 01:00:20 >>> > >>> > But after i rebooted the Windows Server Machine, i could not kinit with >>> AD >>> > users anymore: >>> > [root at ipaserver1 ~]# kinit Yoni at BLUE.COM >>> > kinit: Cannot resolve servers for KDC in realm "BLUE.COM" while >>> getting >>> > initial >>> >>> The only IPA component used for kinit is the DNS server. How did you >>> configure DNS (glue records? forwarder?). To get more details about what >>> is failing you can call: >>> >>> KRB5_TRACE=/dev/stdout kinit Yoni at BLUE.COM >>> >>> HTH >>> >>> bye, >>> Sumit >>> >>> > >>> > I have checked if all the IPA services where UP: >>> > >>> > [root at ipaserver1 ~]# ipactl status >>> > Directory Service: RUNNING >>> > krb5kdc Service: RUNNING >>> > kadmin Service: RUNNING >>> > named Service: RUNNING >>> > ipa_memcached Service: RUNNING >>> > httpd Service: RUNNING >>> > pki-tomcatd Service: RUNNING >>> > smb Service: RUNNING >>> > winbind Service: RUNNING >>> > ipa-otpd Service: RUNNING >>> > ipa: INFO: The ipactl command was successful >>> > >>> > After i restarted IPA services (ipactl restart), i was able to to kinit >>> > again. >>> > Restarting smb service would do the job as well (?). >>> > >>> > Just wanted to know if it is a know issue, or the AD should be re >>> > discovered if it reboots. >>> > I think i seen an issue about it in the mailing list some time ago (not >>> > sure). >>> > >>> > I did not increase the debug level and got the logs. >>> > But i can share the ipa and sssd version: >>> > >>> > rpm -qa | grep ipa >>> > ipa-server-3.3.3-28.el7_0.1.x86_64 >>> > python-iniparse-0.4-9.el7.noarch >>> > libipa_hbac-1.11.2-68.el7_0.5.x86_64 >>> > ipa-admintools-3.3.3-28.el7_0.1.x86_64 >>> > ipa-server-trust-ad-3.3.3-28.el7_0.1.x86_64 >>> > ipa-python-3.3.3-28.el7_0.1.x86_64 >>> > sssd-ipa-1.11.2-68.el7_0.5.x86_64 >>> > iniparser-3.1-5.el7.x86_64 >>> > libipa_hbac-python-1.11.2-68.el7_0.5.x86_64 >>> > ipa-client-3.3.3-28.el7_0.1.x86_64 >>> > >>> > rpm -qa | grep sssd >>> > sssd-krb5-common-1.11.2-68.el7_0.5.x86_64 >>> > sssd-ldap-1.11.2-68.el7_0.5.x86_64 >>> > sssd-common-1.11.2-68.el7_0.5.x86_64 >>> > sssd-common-pac-1.11.2-68.el7_0.5.x86_64 >>> > sssd-ad-1.11.2-68.el7_0.5.x86_64 >>> > sssd-krb5-1.11.2-68.el7_0.5.x86_64 >>> > sssd-1.11.2-68.el7_0.5.x86_64 >>> > python-sssdconfig-1.11.2-68.el7_0.5.noarch >>> > sssd-ipa-1.11.2-68.el7_0.5.x86_64 >>> > sssd-proxy-1.11.2-68.el7_0.5.x86_64 >>> > sssd-client-1.11.2-68.el7_0.5.x86_64 >>> > >>> > Thanks for all the helpers. >>> >>> > -- >>> > Manage your subscription for the Freeipa-users mailing list: >>> > https://www.redhat.com/mailman/listinfo/freeipa-users >>> > Go To http://freeipa.org for more info on the project >>> >>> >>> > -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go To http://freeipa.org for more info on the project >> > > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From netvent at gmail.com Fri Sep 19 23:02:11 2014 From: netvent at gmail.com (swartz) Date: Fri, 19 Sep 2014 17:02:11 -0600 Subject: [Freeipa-users] PKI-CA fails to start (broken config after update?) Message-ID: <541CB5F3.7060107@gmail.com> Hello, Encountered same issue as described here: https://www.redhat.com/archives/freeipa-users/2013-July/msg00133.html https://www.redhat.com/archives/freeipa-users/2014-August/msg00224.html Plain vanilla IPA setup. No changes, no customizations. Recently IPA fails to start. Error happened right after a 'yum update' and reboot. --------------------------------------- Starting pki-ca: [ OK ] Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. ... Failed to start CA Service Shutting down ---------------------------------------- Digging into the matter further... The line that causes the error above is in /usr/share/pki/scripts/functions (which is loaded by pki-ca init script): netstat -antl | grep ${port} > /dev/null The $port variable is blank so call to grep is without a search parameter. Hence invalid call to grep and subsequent error msg I'm seeing as above. $port is defined just a few lines above as port=`grep '^pkicreate.unsecure_port=' ${pki_instance_configuration_file} | cut -b25- -` BUT! For whatever reason there is no line that starts with "pkicreate.unsecure_port" in $pki_instance_configuration_file (/var/lib/pki-ca/conf/CS.cfg). Thus no port info is ever obtained for use in grep. Why there is no such line in config file where one is expected is unknown to me... Versions currently installed ipa-server-3.0.0-37.el6.x86_64 pki-ca-9.0.3-32.el6.noarch Did updates to pki packages clobber the configs? What got broken? How do I resolve it? Thank you. From rob.verduijn at gmail.com Sat Sep 20 14:53:48 2014 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Sat, 20 Sep 2014 16:53:48 +0200 Subject: [Freeipa-users] apache kerberized nfs4 /var/www/html access denied for apache user In-Reply-To: References: <82E7C9A01FD0764CACDD35D10F5DFB6E7267D7@001FSN2MPN1-044.001f.mgd2.msft.net> <2332392.eAZbh8SOxa@linux-ws1.messinet.com> <20140916115846.6cf53fe8@willson.usersys.redhat.com> <541860F7.1090602@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E726B33@001FSN2MPN1-044.001f.mgd2.msft.net> Message-ID: Hello all, I've managed to get the gssproxy to work on my installation. I can now mount my apache document root using sec=krb5p and apache automagically mounts the share when needed. However I noticed that now all nfs credentials are going through gssproxy. Is there a way to disable this for regular users (or only enable it for apache) Below is the gssproxy.conf I used Cheers Rob [gssproxy] [service/nfs-client] mechs = krb5 cred_store = keytab:/etc/krb5.keytab cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U cred_store = client_keytab:/etc/gssproxy/%U.keytab cred_usage = initiate allow_any_uid = yes trusted = yes euid = 0 2014-09-17 9:15 GMT+02:00 Rob Verduijn : > > > 2014-09-16 20:57 GMT+02:00 Nordgren, Bryce L -FS : > > >> > Also opened https://fedorahosted.org/freeipa/ticket/4544 >> >> Tried to summarize this thread on that ticket. >> >> Back to the OP's concern, whenever I use NFS as a documentroot for apache >> (even a WebDAV server), I make a separate mountpoint, fall back to sec=sys, >> set "all-squash", and specify the webserver's IP. It's not like individual >> user accounts need a presence on the filesystem. Do you need encryption for >> your application or is apache just going to spray the content out across >> the commodity internet via un-encrypted http? >> >> Bryce >> >> >> >> >> >> >> This electronic message contains information generated by the USDA solely >> for the intended recipients. Any unauthorized interception of this message >> or the use or disclosure of the information it contains may violate the law >> and subject the violator to civil or criminal penalties. If you believe you >> have received this message in error, please notify the sender and delete >> the email immediately. >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go To http://freeipa.org for more info on the project >> > > > Hello, > > I've already implemented the share as 1.2.3.4(ro,sync,all-squash,sec=sys) > It's not sensitive data and it's also internal, so it will do fine for now > as a workaround. > But there is going to be a situation that apache requires access to a > document root containing sensitive data, in that case I would prefer a more > secure method. > > I've been reading up a little on the gss-proxy, which would be the > prefered way on the obtaining of the credentials from a keytab. > Have gss-proxy do it or have gss-proxy use s4u2proxy to fetch the keytab > ? (which might also solve some of my ssh anoyances but that's a bit off > topic) > > Rob Verduijn > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Sat Sep 20 16:15:04 2014 From: simo at redhat.com (Simo Sorce) Date: Sat, 20 Sep 2014 12:15:04 -0400 Subject: [Freeipa-users] apache kerberized nfs4 /var/www/html access denied for apache user In-Reply-To: References: <82E7C9A01FD0764CACDD35D10F5DFB6E7267D7@001FSN2MPN1-044.001f.mgd2.msft.net> <2332392.eAZbh8SOxa@linux-ws1.messinet.com> <20140916115846.6cf53fe8@willson.usersys.redhat.com> <541860F7.1090602@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E726B33@001FSN2MPN1-044.001f.mgd2.msft.net> Message-ID: <20140920121504.32401242@willson.usersys.redhat.com> On Sat, 20 Sep 2014 16:53:48 +0200 Rob Verduijn wrote: > Hello all, > > I've managed to get the gssproxy to work on my installation. > I can now mount my apache document root using sec=krb5p and apache > automagically mounts the share when needed. > > However I noticed that now all nfs credentials are going through > gssproxy. Is there a way to disable this for regular users (or only > enable it for apache) > > Below is the gssproxy.conf I used I assume you mean that gssproxy is used for all users when rpc.gssd is used ? You cannot pick and choose this way, but gss-proxy can be configured to user regular user's caches so that it preserve proper authorization for access. > Cheers > Rob > > > > [gssproxy] > > [service/nfs-client] > mechs = krb5 > cred_store = keytab:/etc/krb5.keytab > cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U > cred_store = client_keytab:/etc/gssproxy/%U.keytab > cred_usage = initiate > allow_any_uid = yes > trusted = yes > euid = 0 You do not need allow_any_uid in your case as rpc.gssd always runs as root. You can also remove the keytab:/etc/krb5.keytab option as you are only going to initiate with explicit client keytabs. If you only have the apache keytab in /etc/gssproxy then for any other user will fall back to local resolution. You may also experiment with setting ccache to the default for your system so that gss-proxy can find actual user's ccaches, though that may comport some minor risk and will force you to run gss-proxy as root. HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York From amessina at messinet.com Sat Sep 20 16:38:16 2014 From: amessina at messinet.com (Anthony Messina) Date: Sat, 20 Sep 2014 11:38:16 -0500 Subject: [Freeipa-users] apache kerberized nfs4 /var/www/html access denied for apache user In-Reply-To: <20140920121504.32401242@willson.usersys.redhat.com> References: <20140920121504.32401242@willson.usersys.redhat.com> Message-ID: <30688767.i0bHi9ilgj@linux-ws1.messinet.com> On Saturday, September 20, 2014 12:15:04 PM Simo Sorce wrote: > > [service/nfs-client] > > > > mechs = krb5 > > cred_store = keytab:/etc/krb5.keytab > > cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U > > cred_store = client_keytab:/etc/gssproxy/%U.keytab > > cred_usage = initiate > > allow_any_uid = yes > > trusted = yes > > euid = 0 > > You do not need allow_any_uid in your case as rpc.gssd always runs as > root. > > You can also remove the keytab:/etc/krb5.keytab option as you are only > going to initiate with explicit client keytabs. > > If you only have the apache keytab in /etc/gssproxy then for any other > user will fall back to local resolution. > > You may also experiment with setting ccache to the default for your > system so that gss-proxy can find actual user's ccaches, though that > may comport some minor risk and will force you to run gss-proxy as root. Simo, Rob's [service/nfs-client] configuration looks identical to mine, which appears to be the default, at least in Fedora 20: https://git.fedorahosted.org/cgit/gss-proxy.git/tree/proxy/examples/gssproxy.conf.in -- Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery 8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From rob.verduijn at gmail.com Sat Sep 20 17:44:28 2014 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Sat, 20 Sep 2014 19:44:28 +0200 Subject: [Freeipa-users] apache kerberized nfs4 /var/www/html access denied for apache user In-Reply-To: <20140920121504.32401242@willson.usersys.redhat.com> References: <82E7C9A01FD0764CACDD35D10F5DFB6E7267D7@001FSN2MPN1-044.001f.mgd2.msft.net> <2332392.eAZbh8SOxa@linux-ws1.messinet.com> <20140916115846.6cf53fe8@willson.usersys.redhat.com> <541860F7.1090602@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E726B33@001FSN2MPN1-044.001f.mgd2.msft.net> <20140920121504.32401242@willson.usersys.redhat.com> Message-ID: Hi again, Thank you for the quick response. I've removed the credstore entries that are not necessary for the nfs access. Now the users no longer go through gssproxy, but apache does. I've googled around quite a bit and and it seems that your presentation on youtube and the gssproxy page together with a bit on the fedora site are about it concerning documentation. The below gssproxy.conf works fine for apache accessing a kerberized nfs share without having to authenticate against ipa. If I were to create another share for say an tftp directory do I need to create another entry like the one below or can I simply say : euid = 48,1,2,3,4 Or maybe this if you won't mind that any service with a keytab gets nfs access. euid = %U Thanx for the quick help. [gssproxy] [service/nfs-client] mechs = krb5 cred_store = client_keytab:/etc/gssproxy/%U.keytab cred_usage = initiate allow_any_uid = no trusted = yes euid = 48 2014-09-20 18:15 GMT+02:00 Simo Sorce : > On Sat, 20 Sep 2014 16:53:48 +0200 > Rob Verduijn wrote: > > > Hello all, > > > > I've managed to get the gssproxy to work on my installation. > > I can now mount my apache document root using sec=krb5p and apache > > automagically mounts the share when needed. > > > > However I noticed that now all nfs credentials are going through > > gssproxy. Is there a way to disable this for regular users (or only > > enable it for apache) > > > > Below is the gssproxy.conf I used > > I assume you mean that gssproxy is used for all users when rpc.gssd is > used ? You cannot pick and choose this way, but gss-proxy can be > configured to user regular user's caches so that it preserve proper > authorization for access. > > > Cheers > > Rob > > > > > > > > [gssproxy] > > > > [service/nfs-client] > > mechs = krb5 > > cred_store = keytab:/etc/krb5.keytab > > cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U > > cred_store = client_keytab:/etc/gssproxy/%U.keytab > > cred_usage = initiate > > allow_any_uid = yes > > trusted = yes > > euid = 0 > > You do not need allow_any_uid in your case as rpc.gssd always runs as > root. > > You can also remove the keytab:/etc/krb5.keytab option as you are only > going to initiate with explicit client keytabs. > > If you only have the apache keytab in /etc/gssproxy then for any other > user will fall back to local resolution. > > You may also experiment with setting ccache to the default for your > system so that gss-proxy can find actual user's ccaches, though that > may comport some minor risk and will force you to run gss-proxy as root. > > > HTH, > Simo. > > > -- > Simo Sorce * Red Hat, Inc * New York > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Sat Sep 20 19:10:33 2014 From: simo at redhat.com (Simo Sorce) Date: Sat, 20 Sep 2014 15:10:33 -0400 Subject: [Freeipa-users] apache kerberized nfs4 /var/www/html access denied for apache user In-Reply-To: <30688767.i0bHi9ilgj@linux-ws1.messinet.com> References: <20140920121504.32401242@willson.usersys.redhat.com> <30688767.i0bHi9ilgj@linux-ws1.messinet.com> Message-ID: <20140920151033.279c75f9@willson.usersys.redhat.com> On Sat, 20 Sep 2014 11:38:16 -0500 Anthony Messina wrote: > On Saturday, September 20, 2014 12:15:04 PM Simo Sorce wrote: > > > [service/nfs-client] > > > > > > mechs = krb5 > > > cred_store = keytab:/etc/krb5.keytab > > > cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U > > > cred_store = client_keytab:/etc/gssproxy/%U.keytab > > > cred_usage = initiate > > > allow_any_uid = yes > > > trusted = yes > > > euid = 0 > > > > You do not need allow_any_uid in your case as rpc.gssd always runs > > as root. > > > > You can also remove the keytab:/etc/krb5.keytab option as you are > > only going to initiate with explicit client keytabs. > > > > If you only have the apache keytab in /etc/gssproxy then for any > > other user will fall back to local resolution. > > > > You may also experiment with setting ccache to the default for your > > system so that gss-proxy can find actual user's ccaches, though that > > may comport some minor risk and will force you to run gss-proxy as > > root. > > Simo, Rob's [service/nfs-client] configuration looks identical to > mine, which appears to be the default, at least in Fedora 20: > > https://git.fedorahosted.org/cgit/gss-proxy.git/tree/proxy/examples/gssproxy.conf.in Oh it is and I forgot why we put allow_any_uid in, it's because now rpc.gssd drops privileges before checking ccaches ... doh, I had forgotten. I wonder if we should remove the keytab from the default configuration though ... Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Sat Sep 20 21:19:31 2014 From: simo at redhat.com (Simo Sorce) Date: Sat, 20 Sep 2014 17:19:31 -0400 Subject: [Freeipa-users] apache kerberized nfs4 /var/www/html access denied for apache user In-Reply-To: References: <82E7C9A01FD0764CACDD35D10F5DFB6E7267D7@001FSN2MPN1-044.001f.mgd2.msft.net> <2332392.eAZbh8SOxa@linux-ws1.messinet.com> <20140916115846.6cf53fe8@willson.usersys.redhat.com> <541860F7.1090602@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E726B33@001FSN2MPN1-044.001f.mgd2.msft.net> <20140920121504.32401242@willson.usersys.redhat.com> Message-ID: <20140920171931.4c4c8eaa@willson.usersys.redhat.com> On Sat, 20 Sep 2014 19:44:28 +0200 Rob Verduijn wrote: > Hi again, > > Thank you for the quick response. > I've removed the credstore entries that are not necessary for the nfs > access. > Now the users no longer go through gssproxy, but apache does. > > I've googled around quite a bit and and it seems that your > presentation on youtube and the gssproxy page together with a bit on > the fedora site are about it concerning documentation. We do not have a lot of docs yet, indeed. > The below gssproxy.conf works fine for apache accessing a kerberized > nfs share without having to authenticate against ipa. > > If I were to create another share for say an tftp directory do I need > to create another entry like the one below or can I simply say : > euid = 48,1,2,3,4 Nope, euid is singlevalued. > Or maybe this if you won't mind that any service with a keytab gets > nfs access. > euid = %U Setting %U in euid does not work, that's why we have allow_any_uid. > Thanx for the quick help. Glad you got it working to your liking, and feel free to ask questions directly on the gss-proxy mailing list if you want. Btw in the conf below you can also remove completely the allow_any_uid (no is the default) and the trusted options (you should not really trust apache to impersonate any user, w/o trusted it will just be itself). Simo. > > [gssproxy] > > [service/nfs-client] > mechs = krb5 > cred_store = client_keytab:/etc/gssproxy/%U.keytab > cred_usage = initiate > allow_any_uid = no > trusted = yes > euid = 48 > > > > 2014-09-20 18:15 GMT+02:00 Simo Sorce : > > > On Sat, 20 Sep 2014 16:53:48 +0200 > > Rob Verduijn wrote: > > > > > Hello all, > > > > > > I've managed to get the gssproxy to work on my installation. > > > I can now mount my apache document root using sec=krb5p and apache > > > automagically mounts the share when needed. > > > > > > However I noticed that now all nfs credentials are going through > > > gssproxy. Is there a way to disable this for regular users (or > > > only enable it for apache) > > > > > > Below is the gssproxy.conf I used > > > > I assume you mean that gssproxy is used for all users when rpc.gssd > > is used ? You cannot pick and choose this way, but gss-proxy can be > > configured to user regular user's caches so that it preserve proper > > authorization for access. > > > > > Cheers > > > Rob > > > > > > > > > > > > [gssproxy] > > > > > > [service/nfs-client] > > > mechs = krb5 > > > cred_store = keytab:/etc/krb5.keytab > > > cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U > > > cred_store = client_keytab:/etc/gssproxy/%U.keytab > > > cred_usage = initiate > > > allow_any_uid = yes > > > trusted = yes > > > euid = 0 > > > > You do not need allow_any_uid in your case as rpc.gssd always runs > > as root. > > > > You can also remove the keytab:/etc/krb5.keytab option as you are > > only going to initiate with explicit client keytabs. > > > > If you only have the apache keytab in /etc/gssproxy then for any > > other user will fall back to local resolution. > > > > You may also experiment with setting ccache to the default for your > > system so that gss-proxy can find actual user's ccaches, though that > > may comport some minor risk and will force you to run gss-proxy as > > root. > > > > > > HTH, > > Simo. > > > > > > -- > > Simo Sorce * Red Hat, Inc * New York > > -- Simo Sorce * Red Hat, Inc * New York From traiano at gmail.com Sat Sep 20 21:25:45 2014 From: traiano at gmail.com (Traiano Welcome) Date: Sun, 21 Sep 2014 00:25:45 +0300 Subject: [Freeipa-users] =?utf-8?q?FreeIPA_ActiveDire=E2=80=8Bctory_Integr?= =?utf-8?q?atio=E2=80=8Bn=3A_Managing_AD_Users_in_IPA?= In-Reply-To: <5414B2A8.6050004@redhat.com> References: <5414B2A8.6050004@redhat.com> Message-ID: (belated response) On Sun, Sep 14, 2014 at 12:10 AM, Dmitri Pal wrote: > On 09/13/2014 04:03 PM, Traiano Welcome wrote: > > Hi List > > Currently I have a stable trust relationship going between IPA and Windows > AD. I create users and manage passwords in AD, but want to manage the rest > in IPA, "the rest" being default shell, default home directory settings, > RBAC, HBAC, Selinux etc .. > > What I'm expecting it to be able to log into the FreeIPA web interface, > and see a synched list of users created in AD appear in the interface, > after which I can modify the settings on a per user basis. > > If that level of granularity is not possible, I would then expect to be > able to at least apply an IPA-imposed set of account defaults on and AD > user group: > > - default shell > - HBAC rules > - Sudo rules > - SELinux rules > - RBAC > > Is this possible with FreeIPA? I can't find anything coherent in the > documentation that describes an effective way of managing the POSIX > attributes of AD users in FreeIPA. > > Thanks in advance! > Traiano > > > > > > You are to some extent describing a feature that we call "views" that is > currently in works. > But there are two parts: > a) Ability to overwrite POSIX attributes for AD users - this is views > https://fedorahosted.org/freeipa/ticket/3318 > https://fedorahosted.org/freeipa/ticket/4509 > This is exactly the feature I had in mind! > b) Ability to apply policies to AD users. It is already possible. > This is done via group membership. > So you create a group in IPA, make AD group an external member of that > group and then use that IPA group to apply HBAC, SUDO and SELinux rules. > > For the interim, this seems to meet the need. Seems to work reliably in tests as long as one keeps a spreadsheet of AD group mappings to IdM user rights. Requires some coordination with the local AD administrator :-) > As for RBAC what do you mean? > By RBAC, I mean to define linux server user "roles" with a certain profile of sudo rights, selinux policies and host access rules which one could apply to individual users without grouping them. Although, conceptually it appears that there's little difference in using user groups to represent the same type of "container" as a role would. However, I suppose the user groups mechanism essentially achieves the same objective. > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Mon Sep 22 06:29:19 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 22 Sep 2014 08:29:19 +0200 Subject: [Freeipa-users] AD Trust - Cannot resolve servers for KDC after reboot In-Reply-To: References: <20140916072831.GY2947@localhost.localdomain> <20140919204009.GG2541@redhat.com> Message-ID: <541FC1BF.5070603@redhat.com> On 19.9.2014 23:15, Genadi Postrilko wrote: > The DNS server service of AD is running. > I am able to resolve with nslookup command. > > I have just restarted the named service and i am able to kinit again. > It looks like the named deamon, cannot recognize that the forwarder is back > online. > Is there some caching mechanism implemented for the forwarders? 'IPA forwarders' are exactly the same as normal 'BIND forward zone' so they involve normal DNS cache. Which type of forwarder do you have configured? Is your 'forwarding policy' set to 'first' (default) or 'only'? Forwarding policy 'first' (combined with cache) could be the cause of your problem. 'First' policy instructs BIND to contact the configured server and if it fails (because of timeout) BIND will re-try the same query using normal recursion. Depending on your network configuration, the normal DNS recursion can return different results than forwarding(^1). In this case BIND can cache e.g. NXDOMAIN answer from some other server and this answer will stay in cache for TTL value in the given answer. As a result, IPA could get cached NXDOMAIN instead of correct SRV records for AD until the TTL in cache expires. This is of course a wild guess. Detailed logs from named (log level 5 or higher+querylog) could tell us what exactly happened. Have a nice day! (^1) I would argue that this points to a flaw in network configuration... Petr^2 Spacek > 2014-09-19 23:40 GMT+03:00 Alexander Bokovoy : > >> On Fri, 19 Sep 2014, Genadi Postrilko wrote: >> >>> I have recreated the "problem". >>> Rebooted the AD and now cannot kinit with AD users. >>> >>> [root at ipaserver1 ~]# KRB5_TRACE=/dev/stdout kinit Yoni at BLUE.COM >>> [22865] 1411157693.26121: Resolving unique ccache of type KEYRING >>> [22865] 1411157693.26167: Getting initial credentials for Yoni at BLUE.COM >>> [22865] 1411157693.28577: Sending request (156 bytes) to BLUE.COM >>> kinit: Cannot resolve servers for KDC in realm "BLUE.COM" while getting >>> initial credentials >>> >>> The AD configured as forwarder: >>> >>> [root at ipaserver1 ~]# ipa dnsconfig-show >>> Global forwarders: 192.168.227.60 >>> >>> i can ping the AD machine. >>> >> If you rebooted AD DC, it takes time to start up its services. If >> Kerberos library cannot resolve SRV records for BLUE.COM, it means DNS >> service on AD DC didn't start up yet and cannot respond to DNS queries. >> >> >> >> >>> 2014-09-16 10:28 GMT+03:00 Sumit Bose : >>> >>> On Tue, Sep 16, 2014 at 01:39:41AM +0300, Genadi Postrilko wrote: >>>>> Hello all ! >>>>> >>>>> I have deployed test environment for AD trust feature, the environment >>>>> contains : >>>>> Windows Server 2008 - AD Server. >>>>> RHEL 7 - IPA 3.3 Server. >>>>> RHEL 6.2 - IPA Client. >>>>> >>>>> I have established the trust as IPA in the sub domain of AD. >>>>> AD DNS domain - blue.com >>>>> IPA DNS domain - linux.blue.com >>>>> >>>>> All was working fine as i was able to kinit with AD users: >>>>> >>>>> [root at ipaserver1 ~]# kinit Yoni at BLUE.COM >>>>> Password for Yoni at BLUE.COM: >>>>> >>>>> [root at ipaserver1 ~]# klist >>>>> Ticket cache: KEYRING:persistent:0:krb_ccache_oi15FrE >>>>> Default principal: Yoni at BLUE.COM >>>>> >>>>> Valid starting Expires Service principal >>>>> 09/16/2014 01:00:25 09/16/2014 11:00:25 krbtgt/BLUE.COM at BLUE.COM >>>>> renew until 09/17/2014 01:00:20 >>>>> >>>>> But after i rebooted the Windows Server Machine, i could not kinit with >>>> AD >>>>> users anymore: >>>>> [root at ipaserver1 ~]# kinit Yoni at BLUE.COM >>>>> kinit: Cannot resolve servers for KDC in realm "BLUE.COM" while >>>> getting >>>>> initial >>>> >>>> The only IPA component used for kinit is the DNS server. How did you >>>> configure DNS (glue records? forwarder?). To get more details about what >>>> is failing you can call: >>>> >>>> KRB5_TRACE=/dev/stdout kinit Yoni at BLUE.COM >>>> >>>> HTH >>>> >>>> bye, >>>> Sumit >>>> >>>>> >>>>> I have checked if all the IPA services where UP: >>>>> >>>>> [root at ipaserver1 ~]# ipactl status >>>>> Directory Service: RUNNING >>>>> krb5kdc Service: RUNNING >>>>> kadmin Service: RUNNING >>>>> named Service: RUNNING >>>>> ipa_memcached Service: RUNNING >>>>> httpd Service: RUNNING >>>>> pki-tomcatd Service: RUNNING >>>>> smb Service: RUNNING >>>>> winbind Service: RUNNING >>>>> ipa-otpd Service: RUNNING >>>>> ipa: INFO: The ipactl command was successful >>>>> >>>>> After i restarted IPA services (ipactl restart), i was able to to kinit >>>>> again. >>>>> Restarting smb service would do the job as well (?). >>>>> >>>>> Just wanted to know if it is a know issue, or the AD should be re >>>>> discovered if it reboots. >>>>> I think i seen an issue about it in the mailing list some time ago (not >>>>> sure). >>>>> >>>>> I did not increase the debug level and got the logs. >>>>> But i can share the ipa and sssd version: >>>>> >>>>> rpm -qa | grep ipa >>>>> ipa-server-3.3.3-28.el7_0.1.x86_64 >>>>> python-iniparse-0.4-9.el7.noarch >>>>> libipa_hbac-1.11.2-68.el7_0.5.x86_64 >>>>> ipa-admintools-3.3.3-28.el7_0.1.x86_64 >>>>> ipa-server-trust-ad-3.3.3-28.el7_0.1.x86_64 >>>>> ipa-python-3.3.3-28.el7_0.1.x86_64 >>>>> sssd-ipa-1.11.2-68.el7_0.5.x86_64 >>>>> iniparser-3.1-5.el7.x86_64 >>>>> libipa_hbac-python-1.11.2-68.el7_0.5.x86_64 >>>>> ipa-client-3.3.3-28.el7_0.1.x86_64 >>>>> >>>>> rpm -qa | grep sssd >>>>> sssd-krb5-common-1.11.2-68.el7_0.5.x86_64 >>>>> sssd-ldap-1.11.2-68.el7_0.5.x86_64 >>>>> sssd-common-1.11.2-68.el7_0.5.x86_64 >>>>> sssd-common-pac-1.11.2-68.el7_0.5.x86_64 >>>>> sssd-ad-1.11.2-68.el7_0.5.x86_64 >>>>> sssd-krb5-1.11.2-68.el7_0.5.x86_64 >>>>> sssd-1.11.2-68.el7_0.5.x86_64 >>>>> python-sssdconfig-1.11.2-68.el7_0.5.noarch >>>>> sssd-ipa-1.11.2-68.el7_0.5.x86_64 >>>>> sssd-proxy-1.11.2-68.el7_0.5.x86_64 >>>>> sssd-client-1.11.2-68.el7_0.5.x86_64 >>>>> >>>>> Thanks for all the helpers. From mkosek at redhat.com Mon Sep 22 08:50:56 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 22 Sep 2014 10:50:56 +0200 Subject: [Freeipa-users] PKI-CA fails to start (broken config after update?) In-Reply-To: <541CB5F3.7060107@gmail.com> References: <541CB5F3.7060107@gmail.com> Message-ID: <541FE2F0.3050904@redhat.com> On 09/20/2014 01:02 AM, swartz wrote: > Hello, > > Encountered same issue as described here: > https://www.redhat.com/archives/freeipa-users/2013-July/msg00133.html > https://www.redhat.com/archives/freeipa-users/2014-August/msg00224.html > > Plain vanilla IPA setup. No changes, no customizations. > Recently IPA fails to start. Error happened right after a 'yum update' and reboot. > > --------------------------------------- > Starting pki-ca: [ OK ] > Usage: grep [OPTION]... PATTERN [FILE]... > Try `grep --help' for more information. > Usage: grep [OPTION]... PATTERN [FILE]... > Try `grep --help' for more information. > Usage: grep [OPTION]... PATTERN [FILE]... > Try `grep --help' for more information. > ... > Failed to start CA Service > Shutting down > ---------------------------------------- > > Digging into the matter further... > The line that causes the error above is in /usr/share/pki/scripts/functions > (which is loaded by pki-ca init script): > netstat -antl | grep ${port} > /dev/null > > The $port variable is blank so call to grep is without a search parameter. > Hence invalid call to grep and subsequent error msg I'm seeing as above. > > $port is defined just a few lines above as > port=`grep '^pkicreate.unsecure_port=' ${pki_instance_configuration_file} | cut > -b25- -` > > BUT! For whatever reason there is no line that starts with > "pkicreate.unsecure_port" in $pki_instance_configuration_file > (/var/lib/pki-ca/conf/CS.cfg). Thus no port info is ever obtained for use in grep. > > Why there is no such line in config file where one is expected is unknown to me... > > Versions currently installed > ipa-server-3.0.0-37.el6.x86_64 > pki-ca-9.0.3-32.el6.noarch > > Did updates to pki packages clobber the configs? What got broken? How do I > resolve it? > > Thank you. Also please see another PKI crash on EL6 reported on freeipa-users: https://www.redhat.com/archives/freeipa-users/2014-September/msg00331.html This is not the first time this issue was reported, but we got no response from PKI team, even though I CCed several members (maybe that was actually the root case). The PKI installation errors are piling up (7.1 too), I would like to resolve that very soon so that we are not seen as too unstable software. Thanks for help, Martin From amurty at deloitte.com Mon Sep 22 12:03:47 2014 From: amurty at deloitte.com (Murty, Ajeet (US - Arlington)) Date: Mon, 22 Sep 2014 12:03:47 +0000 Subject: [Freeipa-users] weak and null ciphers detected on ldap ports Message-ID: <013068C38BB187448B7AB350AE98B35B38D3AD93@USNDC1453.us.deloitte.com> Security scan of FreeIPA server ports uncovered weak, medium and null ciphers on port 389 and 636. We are running ?ipa-server-3.0.0-37.el6.i686?. How can I disable/remove these ciphers in my existing setup? Ciphers Discovered - TLSv1 EXP-RC2-CBC-MD5 Kx=RSA(512) Au=RSA Enc=RC2-CBC(40) Mac=MD5 export EXP-RC4-MD5 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export TLSv1 EXP1024-DES-CBC-SHA Kx=RSA(1024) Au=RSA Enc=DES-CBC(56) Mac=SHA1 export EXP1024-RC4-SHA Kx=RSA(1024) Au=RSA Enc=RC4(56) Mac=SHA1 export DES-CBC-SHA Kx=RSA Au=RSA Enc=DES-CBC(56) Mac=SHA1 TLSv1 NULL-SHA Kx=RSA Au=RSA Enc=None Mac=SHA1 Thanks, Amb. This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and any disclosure, copying, or distribution of this message, or the taking of any action based on it, by you is strictly prohibited. v.E.1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From alee at redhat.com Mon Sep 22 14:43:03 2014 From: alee at redhat.com (Ade Lee) Date: Mon, 22 Sep 2014 10:43:03 -0400 Subject: [Freeipa-users] PKI-CA fails to start (broken config after update?) In-Reply-To: <541FE2F0.3050904@redhat.com> References: <541CB5F3.7060107@gmail.com> <541FE2F0.3050904@redhat.com> Message-ID: <1411396983.11730.35.camel@aleeredhat.laptop> On Mon, 2014-09-22 at 10:50 +0200, Martin Kosek wrote: > On 09/20/2014 01:02 AM, swartz wrote: > > Hello, > > > > Encountered same issue as described here: > > https://www.redhat.com/archives/freeipa-users/2013-July/msg00133.html > > https://www.redhat.com/archives/freeipa-users/2014-August/msg00224.html > > > > Plain vanilla IPA setup. No changes, no customizations. > > Recently IPA fails to start. Error happened right after a 'yum update' and reboot. > > > > --------------------------------------- > > Starting pki-ca: [ OK ] > > Usage: grep [OPTION]... PATTERN [FILE]... > > Try `grep --help' for more information. > > Usage: grep [OPTION]... PATTERN [FILE]... > > Try `grep --help' for more information. > > Usage: grep [OPTION]... PATTERN [FILE]... > > Try `grep --help' for more information. > > ... > > Failed to start CA Service > > Shutting down > > ---------------------------------------- > > > > Digging into the matter further... > > The line that causes the error above is in /usr/share/pki/scripts/functions > > (which is loaded by pki-ca init script): > > netstat -antl | grep ${port} > /dev/null > > > > The $port variable is blank so call to grep is without a search parameter. > > Hence invalid call to grep and subsequent error msg I'm seeing as above. > > > > $port is defined just a few lines above as > > port=`grep '^pkicreate.unsecure_port=' ${pki_instance_configuration_file} | cut > > -b25- -` > > > > BUT! For whatever reason there is no line that starts with > > "pkicreate.unsecure_port" in $pki_instance_configuration_file > > (/var/lib/pki-ca/conf/CS.cfg). Thus no port info is ever obtained for use in grep. > > > > Why there is no such line in config file where one is expected is unknown to me... > > > > Versions currently installed > > ipa-server-3.0.0-37.el6.x86_64 > > pki-ca-9.0.3-32.el6.noarch > > > > Did updates to pki packages clobber the configs? What got broken? How do I > > resolve it? > > There have been no updates recently on rhel 6 to the pki packages. There has, however, been an update to tomcat - which broke dogtag startups. What version of tomcat6 is on your system? > > Thank you. > > Also please see another PKI crash on EL6 reported on freeipa-users: > > https://www.redhat.com/archives/freeipa-users/2014-September/msg00331.html > > This is not the first time this issue was reported, but we got no response from > PKI team, even though I CCed several members (maybe that was actually the root > case). > > The PKI installation errors are piling up (7.1 too), I would like to resolve > that very soon so that we are not seen as too unstable software. > The issues on 7.1 are tomcat related too. Builds were completed last week to address these. > Thanks for help, > Martin From alee at redhat.com Mon Sep 22 15:14:29 2014 From: alee at redhat.com (Ade Lee) Date: Mon, 22 Sep 2014 11:14:29 -0400 Subject: [Freeipa-users] PKI-CA fails to start (broken config after update?) In-Reply-To: <1411396983.11730.35.camel@aleeredhat.laptop> References: <541CB5F3.7060107@gmail.com> <541FE2F0.3050904@redhat.com> <1411396983.11730.35.camel@aleeredhat.laptop> Message-ID: <1411398869.11730.38.camel@aleeredhat.laptop> On Mon, 2014-09-22 at 10:43 -0400, Ade Lee wrote: > On Mon, 2014-09-22 at 10:50 +0200, Martin Kosek wrote: > > On 09/20/2014 01:02 AM, swartz wrote: > > > Hello, > > > > > > Encountered same issue as described here: > > > https://www.redhat.com/archives/freeipa-users/2013-July/msg00133.html > > > https://www.redhat.com/archives/freeipa-users/2014-August/msg00224.html > > > > > > Plain vanilla IPA setup. No changes, no customizations. > > > Recently IPA fails to start. Error happened right after a 'yum update' and reboot. > > > > > > --------------------------------------- > > > Starting pki-ca: [ OK ] > > > Usage: grep [OPTION]... PATTERN [FILE]... > > > Try `grep --help' for more information. > > > Usage: grep [OPTION]... PATTERN [FILE]... > > > Try `grep --help' for more information. > > > Usage: grep [OPTION]... PATTERN [FILE]... > > > Try `grep --help' for more information. > > > ... > > > Failed to start CA Service > > > Shutting down > > > ---------------------------------------- > > > > > > Digging into the matter further... > > > The line that causes the error above is in /usr/share/pki/scripts/functions > > > (which is loaded by pki-ca init script): > > > netstat -antl | grep ${port} > /dev/null > > > > > > The $port variable is blank so call to grep is without a search parameter. > > > Hence invalid call to grep and subsequent error msg I'm seeing as above. > > > > > > $port is defined just a few lines above as > > > port=`grep '^pkicreate.unsecure_port=' ${pki_instance_configuration_file} | cut > > > -b25- -` > > > > > > BUT! For whatever reason there is no line that starts with > > > "pkicreate.unsecure_port" in $pki_instance_configuration_file > > > (/var/lib/pki-ca/conf/CS.cfg). Thus no port info is ever obtained for use in grep. > > > > > > Why there is no such line in config file where one is expected is unknown to me... > > > > > > Versions currently installed > > > ipa-server-3.0.0-37.el6.x86_64 > > > pki-ca-9.0.3-32.el6.noarch > > > > > > Did updates to pki packages clobber the configs? What got broken? How do I > > > resolve it? > > > > Another question - what is the output of ls -l /etc/pki-ca/CS.cfg ? > There have been no updates recently on rhel 6 to the pki packages. > There has, however, been an update to tomcat - which broke dogtag > startups. > > What version of tomcat6 is on your system? > > > > Thank you. > > > > Also please see another PKI crash on EL6 reported on freeipa-users: > > > > https://www.redhat.com/archives/freeipa-users/2014-September/msg00331.html > > > > This is not the first time this issue was reported, but we got no response from > > PKI team, even though I CCed several members (maybe that was actually the root > > case). > > > > The PKI installation errors are piling up (7.1 too), I would like to resolve > > that very soon so that we are not seen as too unstable software. > > > The issues on 7.1 are tomcat related too. Builds were completed last > week to address these. > > > Thanks for help, > > Martin > From rap at phas.ubc.ca Mon Sep 22 18:23:31 2014 From: rap at phas.ubc.ca (Ron) Date: Mon, 22 Sep 2014 11:23:31 -0700 Subject: [Freeipa-users] copy encrypted password into IPA? Message-ID: <54206923.1050601@phas.ubc.ca> We would like to add some users that are currently in the password/shadow files on some servers into IPA. Is there any way to copy (preferably via a script) the encrypted password into IPA so that we do not have to have them reset their passwords? Our idea is to use the "IPA user-add" command to create the user then insert their encrypted password into their IPA entry. Regards, Ron From dpal at redhat.com Mon Sep 22 19:09:42 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 22 Sep 2014 15:09:42 -0400 Subject: [Freeipa-users] apache kerberized nfs4 /var/www/html access denied for apache user In-Reply-To: <20140920171931.4c4c8eaa@willson.usersys.redhat.com> References: <82E7C9A01FD0764CACDD35D10F5DFB6E7267D7@001FSN2MPN1-044.001f.mgd2.msft.net> <2332392.eAZbh8SOxa@linux-ws1.messinet.com> <20140916115846.6cf53fe8@willson.usersys.redhat.com> <541860F7.1090602@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E726B33@001FSN2MPN1-044.001f.mgd2.msft.net> <20140920121504.32401242@willson.usersys.redhat.com> <20140920171931.4c4c8eaa@willson.usersys.redhat.com> Message-ID: <542073F6.6030003@redhat.com> On 09/20/2014 05:19 PM, Simo Sorce wrote: > On Sat, 20 Sep 2014 19:44:28 +0200 > Rob Verduijn wrote: > >> Hi again, >> >> Thank you for the quick response. >> I've removed the credstore entries that are not necessary for the nfs >> access. >> Now the users no longer go through gssproxy, but apache does. >> >> I've googled around quite a bit and and it seems that your >> presentation on youtube and the gssproxy page together with a bit on >> the fedora site are about it concerning documentation. > We do not have a lot of docs yet, indeed. Is there any chance we can publish this setup somewhere as a HOWTO? May be on GSS proxy or IPA wiki? That would help others coming after you. If you have a fedora account you can add content to FreeIPA wiki. > >> The below gssproxy.conf works fine for apache accessing a kerberized >> nfs share without having to authenticate against ipa. >> >> If I were to create another share for say an tftp directory do I need >> to create another entry like the one below or can I simply say : >> euid = 48,1,2,3,4 > Nope, euid is singlevalued. Should we open RFE for it? ding-libs can return you a list of numbers. > >> Or maybe this if you won't mind that any service with a keytab gets >> nfs access. >> euid = %U > Setting %U in euid does not work, that's why we have allow_any_uid. > >> Thanx for the quick help. > Glad you got it working to your liking, and feel free to ask questions > directly on the gss-proxy mailing list if you want. > > Btw in the conf below you can also remove completely the allow_any_uid > (no is the default) and the trusted options (you should not really > trust apache to impersonate any user, w/o trusted it will just be > itself). > > Simo. > >> [gssproxy] >> >> [service/nfs-client] >> mechs = krb5 >> cred_store = client_keytab:/etc/gssproxy/%U.keytab >> cred_usage = initiate >> allow_any_uid = no >> trusted = yes >> euid = 48 >> >> >> >> 2014-09-20 18:15 GMT+02:00 Simo Sorce : >> >>> On Sat, 20 Sep 2014 16:53:48 +0200 >>> Rob Verduijn wrote: >>> >>>> Hello all, >>>> >>>> I've managed to get the gssproxy to work on my installation. >>>> I can now mount my apache document root using sec=krb5p and apache >>>> automagically mounts the share when needed. >>>> >>>> However I noticed that now all nfs credentials are going through >>>> gssproxy. Is there a way to disable this for regular users (or >>>> only enable it for apache) >>>> >>>> Below is the gssproxy.conf I used >>> I assume you mean that gssproxy is used for all users when rpc.gssd >>> is used ? You cannot pick and choose this way, but gss-proxy can be >>> configured to user regular user's caches so that it preserve proper >>> authorization for access. >>> >>>> Cheers >>>> Rob >>>> >>>> >>>> >>>> [gssproxy] >>>> >>>> [service/nfs-client] >>>> mechs = krb5 >>>> cred_store = keytab:/etc/krb5.keytab >>>> cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U >>>> cred_store = client_keytab:/etc/gssproxy/%U.keytab >>>> cred_usage = initiate >>>> allow_any_uid = yes >>>> trusted = yes >>>> euid = 0 >>> You do not need allow_any_uid in your case as rpc.gssd always runs >>> as root. >>> >>> You can also remove the keytab:/etc/krb5.keytab option as you are >>> only going to initiate with explicit client keytabs. >>> >>> If you only have the apache keytab in /etc/gssproxy then for any >>> other user will fall back to local resolution. >>> >>> You may also experiment with setting ccache to the default for your >>> system so that gss-proxy can find actual user's ccaches, though that >>> may comport some minor risk and will force you to run gss-proxy as >>> root. >>> >>> >>> HTH, >>> Simo. >>> >>> >>> -- >>> Simo Sorce * Red Hat, Inc * New York >>> > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Mon Sep 22 19:21:07 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 22 Sep 2014 15:21:07 -0400 Subject: [Freeipa-users] copy encrypted password into IPA? In-Reply-To: <54206923.1050601@phas.ubc.ca> References: <54206923.1050601@phas.ubc.ca> Message-ID: <542076A3.3080503@redhat.com> On 09/22/2014 02:23 PM, Ron wrote: > We would like to add some users that are currently in the > password/shadow files on some servers into IPA. > > Is there any way to copy (preferably via a script) the encrypted > password into IPA so that we do not have to have them reset their > passwords? > > Our idea is to use the "IPA user-add" command to create the user then > insert their encrypted password into their IPA entry. > > Regards, > Ron > > The most probably answer is no since the hash types would not match between what you have in the files and what LDAP server expects. If you by any chance configured your files to use other hashes than default it might match. You can go the other way and reconfigure the LDAP server but AFAIR it is not recommended. The user-add command would not work anyways as it does not accept hash as an input. Or I should say it would allow you to add users without passwords in a script. You can set a random password, send it to account owner in a script and make account owners to change passwords (default) on the first use. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From rcritten at redhat.com Mon Sep 22 19:31:37 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 22 Sep 2014 15:31:37 -0400 Subject: [Freeipa-users] copy encrypted password into IPA? In-Reply-To: <542076A3.3080503@redhat.com> References: <54206923.1050601@phas.ubc.ca> <542076A3.3080503@redhat.com> Message-ID: <54207919.7080303@redhat.com> Dmitri Pal wrote: > On 09/22/2014 02:23 PM, Ron wrote: >> We would like to add some users that are currently in the >> password/shadow files on some servers into IPA. >> >> Is there any way to copy (preferably via a script) the encrypted >> password into IPA so that we do not have to have them reset their >> passwords? >> >> Our idea is to use the "IPA user-add" command to create the user then >> insert their encrypted password into their IPA entry. >> >> Regards, >> Ron >> >> > > The most probably answer is no since the hash types would not match > between what you have in the files and what LDAP server expects. > If you by any chance configured your files to use other hashes than > default it might match. You can go the other way and reconfigure the > LDAP server but AFAIR it is not recommended. > The user-add command would not work anyways as it does not accept hash > as an input. Or I should say it would allow you to add users without > passwords in a script. > You can set a random password, send it to account owner in a script and > make account owners to change passwords (default) on the first use. If you put IPA into migration mode then you can set a password on user-add via --setattr userPassword= . Note that it is important to do it in one step and not add user, then set password. You'll then need to migrate the password to create Kerberos credentials either by authenticating via SSSD or on the IPA web page. The trick is having the hash in a format acceptable to 389-ds. I know it works with crypt, you just need to prefix it with {crypt}. For other formats, I don't know. rob From netvent at gmail.com Mon Sep 22 19:39:37 2014 From: netvent at gmail.com (swartz) Date: Mon, 22 Sep 2014 13:39:37 -0600 Subject: [Freeipa-users] PKI-CA fails to start (broken config after update?) In-Reply-To: <1411398869.11730.38.camel@aleeredhat.laptop> References: <541CB5F3.7060107@gmail.com> <541FE2F0.3050904@redhat.com> <1411396983.11730.35.camel@aleeredhat.laptop> <1411398869.11730.38.camel@aleeredhat.laptop> Message-ID: <54207AF9.6020905@gmail.com> On 9/22/2014 9:14 AM, Ade Lee wrote: > Another question - what is the output of ls -l /etc/pki-ca/CS.cfg ? >ls -l /etc/pki-ca/CS.cfg -rw-r-----. 1 pkiuser pkiuser 49196 Sep 19 11:29 /etc/pki-ca/CS.cfg I know that I did NOT change the configs myself. But something certainly did during 'yum update'. There are no .rpmsave or .rpmnew files that would typically be created if configs are properly marked in RPM spec file. There are two other files that exist though: -rw-r-----. 1 pkiuser pkiuser 65869 Sep 19 11:30 CS.cfg.in.p21 -rw-rw----. 1 pkiuser pkiuser 65955 Sep 5 2013 CS.cfg.in.p33 However, they are not usable either in place of current CS.cfg. >> There have been no updates recently on rhel 6 to the pki packages. >> There has, however, been an update to tomcat - which broke dogtag >> startups. >> >> What version of tomcat6 is on your system? >rpm -qa tomcat6 tomcat6-6.0.24-78.el6_5.noarch From simo at redhat.com Mon Sep 22 19:50:24 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 22 Sep 2014 15:50:24 -0400 Subject: [Freeipa-users] apache kerberized nfs4 /var/www/html access denied for apache user In-Reply-To: <542073F6.6030003@redhat.com> References: <82E7C9A01FD0764CACDD35D10F5DFB6E7267D7@001FSN2MPN1-044.001f.mgd2.msft.net> <2332392.eAZbh8SOxa@linux-ws1.messinet.com> <20140916115846.6cf53fe8@willson.usersys.redhat.com> <541860F7.1090602@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E726B33@001FSN2MPN1-044.001f.mgd2.msft.net> <20140920121504.32401242@willson.usersys.redhat.com> <20140920171931.4c4c8eaa@willson.usersys.redhat.com> <542073F6.6030003@redhat.com> Message-ID: <20140922155024.57c6335f@willson.usersys.redhat.com> On Mon, 22 Sep 2014 15:09:42 -0400 Dmitri Pal wrote: > On 09/20/2014 05:19 PM, Simo Sorce wrote: > > On Sat, 20 Sep 2014 19:44:28 +0200 > > Rob Verduijn wrote: > > > >> Hi again, > >> > >> Thank you for the quick response. > >> I've removed the credstore entries that are not necessary for the > >> nfs access. > >> Now the users no longer go through gssproxy, but apache does. > >> > >> I've googled around quite a bit and and it seems that your > >> presentation on youtube and the gssproxy page together with a bit > >> on the fedora site are about it concerning documentation. > > We do not have a lot of docs yet, indeed. > > > Is there any chance we can publish this setup somewhere as a HOWTO? > May be on GSS proxy or IPA wiki? > That would help others coming after you. > > If you have a fedora account you can add content to FreeIPA wiki. With a Fedora account you can also write to the GSS-Proxy wiki which may be more appropriate. > > > > >> The below gssproxy.conf works fine for apache accessing a > >> kerberized nfs share without having to authenticate against ipa. > >> > >> If I were to create another share for say an tftp directory do I > >> need to create another entry like the one below or can I simply > >> say : euid = 48,1,2,3,4 > > Nope, euid is singlevalued. > > > Should we open RFE for it? > ding-libs can return you a list of numbers. No, it rarely if ever would make sense to do so, And we want to move the conf to have multiple conf snippets instead of a single file, in that case you'll want to have multiple snippets one per user. Simo. -- Simo Sorce * Red Hat, Inc * New York From nkinder at redhat.com Mon Sep 22 20:07:03 2014 From: nkinder at redhat.com (Nathan Kinder) Date: Mon, 22 Sep 2014 13:07:03 -0700 Subject: [Freeipa-users] weak and null ciphers detected on ldap ports In-Reply-To: <013068C38BB187448B7AB350AE98B35B38D3AD93@USNDC1453.us.deloitte.com> References: <013068C38BB187448B7AB350AE98B35B38D3AD93@USNDC1453.us.deloitte.com> Message-ID: <54208167.2040508@redhat.com> On 09/22/2014 05:03 AM, Murty, Ajeet (US - Arlington) wrote: > Security scan of FreeIPA server ports uncovered weak, medium and null > ciphers on port 389 and 636. We are running ?ipa-server-3.0.0-37.el6.i686?. > > How can I disable/remove these ciphers in my existing setup? This has recently been worked on in this 389-ds-base ticket: https://fedorahosted.org/389/ticket/47838 As mentioned in the initial description of that ticket, you can configure the allowed ciphers in the "cn=config" entry in 389-ds-base. You can edit this over LDAP, or by stopping 389-ds-base and editing /etc/dirsrv/slapd-/dse.ldif. Thanks, -NGK > > > > Ciphers Discovered - > > TLSv1 > > EXP-RC2-CBC-MD5 Kx=RSA(512) Au=RSA > Enc=RC2-CBC(40) Mac=MD5 export > > EXP-RC4-MD5 Kx=RSA(512) Au=RSA > Enc=RC4(40) Mac=MD5 export > > > > TLSv1 > > EXP1024-DES-CBC-SHA Kx=RSA(1024) Au=RSA > Enc=DES-CBC(56) Mac=SHA1 export > > EXP1024-RC4-SHA Kx=RSA(1024) Au=RSA > Enc=RC4(56) Mac=SHA1 export > > DES-CBC-SHA Kx=RSA Au=RSA > Enc=DES-CBC(56) Mac=SHA1 > > > > TLSv1 > > NULL-SHA Kx=RSA Au=RSA > Enc=None Mac=SHA1 > > > > Thanks, > > Amb. > > > > > > > This message (including any attachments) contains confidential > information intended for a specific individual and purpose, and is > protected by law. If you are not the intended recipient, you should > delete this message and any disclosure, copying, or distribution of this > message, or the taking of any action based on it, by you is strictly > prohibited. > > v.E.1 > > > > > > > > > > From rob.verduijn at gmail.com Mon Sep 22 20:15:23 2014 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Mon, 22 Sep 2014 22:15:23 +0200 Subject: [Freeipa-users] apache kerberized nfs4 /var/www/html access denied for apache user In-Reply-To: <20140922155024.57c6335f@willson.usersys.redhat.com> References: <82E7C9A01FD0764CACDD35D10F5DFB6E7267D7@001FSN2MPN1-044.001f.mgd2.msft.net> <2332392.eAZbh8SOxa@linux-ws1.messinet.com> <20140916115846.6cf53fe8@willson.usersys.redhat.com> <541860F7.1090602@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E726B33@001FSN2MPN1-044.001f.mgd2.msft.net> <20140920121504.32401242@willson.usersys.redhat.com> <20140920171931.4c4c8eaa@willson.usersys.redhat.com> <542073F6.6030003@redhat.com> <20140922155024.57c6335f@willson.usersys.redhat.com> Message-ID: 2014-09-22 21:50 GMT+02:00 Simo Sorce : > On Mon, 22 Sep 2014 15:09:42 -0400 > Dmitri Pal wrote: > > > On 09/20/2014 05:19 PM, Simo Sorce wrote: > > > On Sat, 20 Sep 2014 19:44:28 +0200 > > > Rob Verduijn wrote: > > > > > >> Hi again, > > >> > > >> Thank you for the quick response. > > >> I've removed the credstore entries that are not necessary for the > > >> nfs access. > > >> Now the users no longer go through gssproxy, but apache does. > > >> > > >> I've googled around quite a bit and and it seems that your > > >> presentation on youtube and the gssproxy page together with a bit > > >> on the fedora site are about it concerning documentation. > > > We do not have a lot of docs yet, indeed. > > > > > > Is there any chance we can publish this setup somewhere as a HOWTO? > > May be on GSS proxy or IPA wiki? > > That would help others coming after you. > > > > If you have a fedora account you can add content to FreeIPA wiki. > > With a Fedora account you can also write to the GSS-Proxy wiki which > may be more appropriate. > I've got no problem in writing a howto on what I did. But I have to find some time to sit down for it, and create a fedora account first. > > > > > > > > >> The below gssproxy.conf works fine for apache accessing a > > >> kerberized nfs share without having to authenticate against ipa. > > >> > > >> If I were to create another share for say an tftp directory do I > > >> need to create another entry like the one below or can I simply > > >> say : euid = 48,1,2,3,4 > > > Nope, euid is singlevalued. > > > > > > Should we open RFE for it? > > ding-libs can return you a list of numbers. > > No, it rarely if ever would make sense to do so, And we want to move > the conf to have multiple conf snippets instead of a single file, in > that case you'll want to have multiple snippets one per user. > I did indeed create a second snippet for the other service. :P Rob > > Simo. > > > -- > Simo Sorce * Red Hat, Inc * New York > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jitseklomp at gmail.com Mon Sep 22 20:47:03 2014 From: jitseklomp at gmail.com (Jitse Klomp) Date: Mon, 22 Sep 2014 22:47:03 +0200 Subject: [Freeipa-users] copy encrypted password into IPA? In-Reply-To: <54207919.7080303@redhat.com> References: <54206923.1050601@phas.ubc.ca> <542076A3.3080503@redhat.com> <54207919.7080303@redhat.com> Message-ID: 2014-09-22 21:31 GMT+02:00 Rob Crittenden : > The trick is having the hash in a format acceptable to 389-ds. I know it > works with crypt, you just need to prefix it with {crypt}. For > other formats, I don't know. ?{SHA} works as well - Jitse? -------------- next part -------------- An HTML attachment was scrubbed... URL: From alee at redhat.com Tue Sep 23 01:59:47 2014 From: alee at redhat.com (Ade Lee) Date: Mon, 22 Sep 2014 21:59:47 -0400 Subject: [Freeipa-users] PKI-CA fails to start (broken config after update?) In-Reply-To: <54207AF9.6020905@gmail.com> References: <541CB5F3.7060107@gmail.com> <541FE2F0.3050904@redhat.com> <1411396983.11730.35.camel@aleeredhat.laptop> <1411398869.11730.38.camel@aleeredhat.laptop> <54207AF9.6020905@gmail.com> Message-ID: <1411437587.11730.66.camel@aleeredhat.laptop> On Mon, 2014-09-22 at 13:39 -0600, swartz wrote: > On 9/22/2014 9:14 AM, Ade Lee wrote: > > Another question - what is the output of ls -l /etc/pki-ca/CS.cfg ? > >ls -l /etc/pki-ca/CS.cfg > -rw-r-----. 1 pkiuser pkiuser 49196 Sep 19 11:29 /etc/pki-ca/CS.cfg > In very rare cases, I've seen cases where the CS.cfg becomes truncated during an update. Unfortunately, we have not been able to reproduce the event. In later versions of dogtag, we make sure to save the CS.cfg just in case. Your instance sounds like a truncated CS.cfg instance, but the size is a lot larger than cases I've seen before, so I don't want to jump to that conclusion yet. If you scroll to the end of the CS.cfg, does it look like it has been truncated? If you have backups of the CS.cfg, that will help. Also, you could look for backups that we have created: find /var/lib/pki-ca -name CS.cfg* find /var/log -name CS.cfg* Also, do you have a replica CA? Ade > I know that I did NOT change the configs myself. But something certainly > did during 'yum update'. > There are no .rpmsave or .rpmnew files that would typically be created > if configs are properly marked in RPM spec file. > > There are two other files that exist though: > -rw-r-----. 1 pkiuser pkiuser 65869 Sep 19 11:30 CS.cfg.in.p21 > -rw-rw----. 1 pkiuser pkiuser 65955 Sep 5 2013 CS.cfg.in.p33 > > However, they are not usable either in place of current CS.cfg. > The above files are templates only. They are modified during instance configuration. > > >> There have been no updates recently on rhel 6 to the pki packages. > >> There has, however, been an update to tomcat - which broke dogtag > >> startups. > >> > >> What version of tomcat6 is on your system? > >rpm -qa tomcat6 > tomcat6-6.0.24-78.el6_5.noarch > > This tomcat version should still be a working one. The tomcat6 then broke things has not made it out yet, having been discovered in QE testing. From mkosek at redhat.com Tue Sep 23 06:35:43 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 23 Sep 2014 08:35:43 +0200 Subject: [Freeipa-users] PKI-CA fails to start (broken config after update?) In-Reply-To: <1411437587.11730.66.camel@aleeredhat.laptop> References: <541CB5F3.7060107@gmail.com> <541FE2F0.3050904@redhat.com> <1411396983.11730.35.camel@aleeredhat.laptop> <1411398869.11730.38.camel@aleeredhat.laptop> <54207AF9.6020905@gmail.com> <1411437587.11730.66.camel@aleeredhat.laptop> Message-ID: <542114BF.4040508@redhat.com> On 09/23/2014 03:59 AM, Ade Lee wrote: > On Mon, 2014-09-22 at 13:39 -0600, swartz wrote: >> On 9/22/2014 9:14 AM, Ade Lee wrote: >>> Another question - what is the output of ls -l /etc/pki-ca/CS.cfg ? >> >ls -l /etc/pki-ca/CS.cfg >> -rw-r-----. 1 pkiuser pkiuser 49196 Sep 19 11:29 /etc/pki-ca/CS.cfg >> > In very rare cases, I've seen cases where the CS.cfg becomes truncated > during an update. Unfortunately, we have not been able to reproduce the > event. In later versions of dogtag, we make sure to save the CS.cfg > just in case. > > Your instance sounds like a truncated CS.cfg instance, but the size is a > lot larger than cases I've seen before, so I don't want to jump to that > conclusion yet. JFTR, FreeIPA may have been involved as well, we had a related fix in FreeIPA 4.0.2: https://fedorahosted.org/freeipa/ticket/4166 > > If you scroll to the end of the CS.cfg, does it look like it has been > truncated? > > If you have backups of the CS.cfg, that will help. Also, you could look > for backups that we have created: > > find /var/lib/pki-ca -name CS.cfg* > find /var/log -name CS.cfg* > > Also, do you have a replica CA? > > Ade > >> I know that I did NOT change the configs myself. But something certainly >> did during 'yum update'. >> There are no .rpmsave or .rpmnew files that would typically be created >> if configs are properly marked in RPM spec file. >> >> There are two other files that exist though: >> -rw-r-----. 1 pkiuser pkiuser 65869 Sep 19 11:30 CS.cfg.in.p21 >> -rw-rw----. 1 pkiuser pkiuser 65955 Sep 5 2013 CS.cfg.in.p33 >> >> However, they are not usable either in place of current CS.cfg. >> > The above files are templates only. They are modified during instance > configuration. >> >>>> There have been no updates recently on rhel 6 to the pki packages. >>>> There has, however, been an update to tomcat - which broke dogtag >>>> startups. >>>> >>>> What version of tomcat6 is on your system? >> >rpm -qa tomcat6 >> tomcat6-6.0.24-78.el6_5.noarch >> >> > This tomcat version should still be a working one. The tomcat6 then > broke things has not made it out yet, having been discovered in QE > testing. > > > From pspacek at redhat.com Tue Sep 23 11:24:21 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 23 Sep 2014 13:24:21 +0200 Subject: [Freeipa-users] Announcing bind-dyndb-ldap version 6.0 Message-ID: <54215865.7010004@redhat.com> The FreeIPA team is proud to announce bind-dyndb-ldap version 6.0. It can be downloaded from https://fedorahosted.org/released/bind-dyndb-ldap/ The new version has also been built for Fedora 21+ and and is on its way to updates-testing: https://admin.fedoraproject.org/updates/bind-dyndb-ldap-6.0-1.fc21 This version is also available from FreeIPA COPR repo: http://copr.fedoraproject.org/coprs/mkosek/freeipa/ 6.0 ==== [1] idnsZoneActive attribute is supported again and zones can be activated and deactivated at run-time. https://fedorahosted.org/bind-dyndb-ldap/ticket/127 == Upgrading == A server can be upgraded by installing updated RPM. BIND has to be restarted manually after the RPM installation. Downgrading back to any 5.x version is supported if idnsZoneActive is always set to TRUE. == Feedback == Please provide comments, report bugs and send any other feedback via the freeipa-users mailing list: http://www.redhat.com/mailman/listinfo/freeipa-users -- Petr^2 Spacek From baghery.jone at gmail.com Tue Sep 23 12:44:10 2014 From: baghery.jone at gmail.com (alireza baghery) Date: Tue, 23 Sep 2014 16:14:10 +0330 Subject: [Freeipa-users] syslog Message-ID: hi i have configured ipa (ipa on centos 6.5) and configure rsyslog for send log to syslog server (juniper strm) in strm get error unknown generic log event or log linux (on server install ipa client) but with another server linux not problem -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Tue Sep 23 15:06:46 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 23 Sep 2014 17:06:46 +0200 Subject: [Freeipa-users] What should we do with upstream guide? Message-ID: <54218C86.3000901@redhat.com> Hello everyone! It's been over a year now since we announced [1] that the Technical Writer working on FreeIPA upstream guide [2] can no longer maintain the upstream version of it. FreeIPA project developers wanted to carry the torch and forked the outdated documentation in a new repository [3] and started the work on reviving it again [4][5]. Unfortunately, over the past year it became apparent that despite several brave contributors (special thanks to Gabe Alford and Martin Basti) helping with the guide, the project simply does not have resources to develop both FreeIPA and comprehensive documentation for it. The current FreeIPA guide is already way behind the RHEL-7 downstream guides [6][7] maintained by a new Technical Writer. In addition, old Fedora released documentation often pops up and clobbers FreeIPA upstream documentation in search engine results. This needs to change so that our users are not confused with obsolete information. Writing documentation is enormous task in itself. Currently, until a team of upstream Technical Writers joins the project to contribute alongside the developers the only viable option is to stop maintaining and reviving the upstream guide and keep only 2 main sources of documentation - design documents and articles of FreeIPA.org community wiki, and downstream documentation, from which the RHEL one [6][7] is the most complete. Upstream documentation tickets would be closed or transferred into the downstream doc Bugzillas, existing patches in [3] will be merged with the downstream RHEL documentation effort. This is the proposal. What do you think? Is it a reasonable move? Does anyone have time to be an upstream technical writer and carry the torch or should we move on with this plan? A sustainable documentation effort is needed and FreeIPA project is very much open to long term contributions. We are looking forward to your feedback, Your FreeIPA developers. [1] https://www.redhat.com/archives/freeipa-users/2013-August/msg00044.html [2] http://docs.fedoraproject.org/en-US/Fedora/18/html-single/FreeIPA_Guide/index.html [3] https://git.fedorahosted.org/cgit/freeipa-docs.git [4] https://fedorahosted.org/freeipa/milestone/Revive%20FreeIPA%20guide [5] https://fedorahosted.org/freeipa/milestone/FreeIPA%203.x%20Documentation [6] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html [7] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/index.html [8] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/ln-idp9643248.html -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From mkosek at redhat.com Tue Sep 23 15:15:21 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 23 Sep 2014 17:15:21 +0200 Subject: [Freeipa-users] weak and null ciphers detected on ldap ports In-Reply-To: <54208167.2040508@redhat.com> References: <013068C38BB187448B7AB350AE98B35B38D3AD93@USNDC1453.us.deloitte.com> <54208167.2040508@redhat.com> Message-ID: <54218E89.2060800@redhat.com> On 09/22/2014 10:07 PM, Nathan Kinder wrote: > > > On 09/22/2014 05:03 AM, Murty, Ajeet (US - Arlington) wrote: >> Security scan of FreeIPA server ports uncovered weak, medium and null >> ciphers on port 389 and 636. We are running ?ipa-server-3.0.0-37.el6.i686?. >> >> How can I disable/remove these ciphers in my existing setup? > > This has recently been worked on in this 389-ds-base ticket: > > https://fedorahosted.org/389/ticket/47838 > > As mentioned in the initial description of that ticket, you can > configure the allowed ciphers in the "cn=config" entry in 389-ds-base. > You can edit this over LDAP, or by stopping 389-ds-base and editing > /etc/dirsrv/slapd-/dse.ldif. > > Thanks, > -NGK You can also check the FreeIPA counterpart: https://fedorahosted.org/freeipa/ticket/4395 This issue is fixed in FreeIPA 4.0.3 (available in Copr build and Fedora 21+), we would very much welcome if you can verify that this setup works for you! Thanks, Martin From loris at lgs.com.ve Tue Sep 23 15:35:31 2014 From: loris at lgs.com.ve (Loris Santamaria) Date: Tue, 23 Sep 2014 11:05:31 -0430 Subject: [Freeipa-users] Compat tree and group membership in a trust environment Message-ID: <1411486531.3489.20.camel@toron.pzo.lgs.com.ve> Querying for group membership in the compat tree within a trust environment seems to be rather flaky: * userA and userB are members of admins at ad. admins at ad is member of internet_access at ad * internet_access at ad is member of internet_access_external at ad * internet_access_external at ad is member of internet_access at ad * I restart ipa and clear sssd cache on the master to start with a clean compat tree * searching for (&(objectClass=posixGroup)(memberUid=userA at ad)) returns that he is a member of internet_access at ipa (expected result) * searching for (&(objectClass=posixGroup)(memberUid=userB at ad)) doesn't return him as a member of internet_access at ipa (unexpected) If I restart ipa and clean sssd cache on the master and query first for userB he gets the correct memberships, queries for subsequent users (userA, userC) won't show if they are members of ipa groups. IPA version is 3.3.3-28.el7 on Centos 7, AD is Server 2008. Should I file a bug? -- Loris Santamaria linux user #70506 xmpp:loris at lgs.com.ve Links Global Services, C.A. http://www.lgs.com.ve Tel: 0286 952.06.87 Cel: 0414 095.00.10 sip:103 at lgs.com.ve ------------------------------------------------------------ "If I'd asked my customers what they wanted, they'd have said a faster horse" - Henry Ford -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5720 bytes Desc: not available URL: From loris at lgs.com.ve Tue Sep 23 15:54:41 2014 From: loris at lgs.com.ve (Loris Santamaria) Date: Tue, 23 Sep 2014 11:24:41 -0430 Subject: [Freeipa-users] Squid negotiate auth and trust relationship Message-ID: <1411487681.3489.27.camel@toron.pzo.lgs.com.ve> Hi, I'm setting up a squid proxy in a environment with a trust relationship between IPA and AD. The machine where squid is running belongs to the IPA domain, users may belong to AD or to IPA and in each one of the domains there are groups that define the level of internet access of their members. For simplicity's sake, let's say that there is only one group in each domain called "internet_access". Its member should be granted permission by squid. In IPA I created an external group called internet_access_ad, whose member is internet_access at ad.domain.com, so if the user is a member of internet_access in AD it should be a member of internet_access in IPA, thanks to the trust relationship. The authentication part works beautifully, IPA and AD users are recognized by the squid proxy via negotiate auth, but the authorization part is another story. Since the remote user hasn't logged in v?a console or ssh on the server where squid is running, SSSD ignores its group membership, so one can't use squid's pam_group helper to determine if the user is in the internet_access at ipa.domain.com group. Trying to lookup for membership via ldap in the compat tree doesn't really work (see my previous mail on the subject). Also, it won't work when the realm name is in upper case, although this should be really easy to solve in the squid helper. For the time being I will resort to make two ldap queries, one on IPA and one on AD, but it seems to me that the proper way to go would be to decode the PAC and get authorization info from there, or have a way to query SSSD for complete group membership of a user even if he or she hasn't logged in on a server. How could SSSD/IPA could help to solve this fairly common need (querying user membership from an app)? -- Loris Santamaria linux user #70506 xmpp:loris at lgs.com.ve Links Global Services, C.A. http://www.lgs.com.ve Tel: 0286 952.06.87 Cel: 0414 095.00.10 sip:103 at lgs.com.ve ------------------------------------------------------------ "If I'd asked my customers what they wanted, they'd have said a faster horse" - Henry Ford -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5720 bytes Desc: not available URL: From jhrozek at redhat.com Tue Sep 23 16:03:45 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 23 Sep 2014 18:03:45 +0200 Subject: [Freeipa-users] Compat tree and group membership in a trust environment In-Reply-To: <1411486531.3489.20.camel@toron.pzo.lgs.com.ve> References: <1411486531.3489.20.camel@toron.pzo.lgs.com.ve> Message-ID: <20140923160345.GZ7002@hendrix.redhat.com> On Tue, Sep 23, 2014 at 11:05:31AM -0430, Loris Santamaria wrote: > Querying for group membership in the compat tree within a trust > environment seems to be rather flaky: > > * userA and userB are members of admins at ad. admins at ad is member of > internet_access at ad > * internet_access at ad is member of internet_access_external at ad > * internet_access_external at ad is member of internet_access at ad > * I restart ipa and clear sssd cache on the master to start with a > clean compat tree > * searching for (&(objectClass=posixGroup)(memberUid=userA at ad)) > returns that he is a member of internet_access at ipa (expected > result) > * searching for (&(objectClass=posixGroup)(memberUid=userB at ad)) > doesn't return him as a member of internet_access at ipa > (unexpected) > > If I restart ipa and clean sssd cache on the master and query first for > userB he gets the correct memberships, queries for subsequent users > (userA, userC) won't show if they are members of ipa groups. Can you check the logs first for a sign of any sssd problems? Recently we've troubleshooted another setup with a customer who saw sssd crashes on the server itself when a group was requested by SID, I wonder if this might be the same problem. From abokovoy at redhat.com Tue Sep 23 18:54:37 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 23 Sep 2014 21:54:37 +0300 Subject: [Freeipa-users] Compat tree and group membership in a trust environment In-Reply-To: <1411486531.3489.20.camel@toron.pzo.lgs.com.ve> References: <1411486531.3489.20.camel@toron.pzo.lgs.com.ve> Message-ID: <20140923185437.GE11503@redhat.com> On Tue, 23 Sep 2014, Loris Santamaria wrote: >Querying for group membership in the compat tree within a trust >environment seems to be rather flaky: > > * userA and userB are members of admins at ad. admins at ad is member of > internet_access at ad > * internet_access at ad is member of internet_access_external at ad > * internet_access_external at ad is member of internet_access at ad > * I restart ipa and clear sssd cache on the master to start with a > clean compat tree > * searching for (&(objectClass=posixGroup)(memberUid=userA at ad)) > returns that he is a member of internet_access at ipa (expected > result) > * searching for (&(objectClass=posixGroup)(memberUid=userB at ad)) > doesn't return him as a member of internet_access at ipa > (unexpected) slapi-nis doesn't fully support the latter case yet, it is known issue, though in the https://fedorahosted.org/freeipa/ticket/4403 it is manifested a bit differently. -- / Alexander Bokovoy From walid.shaari at gmail.com Tue Sep 23 19:55:43 2014 From: walid.shaari at gmail.com (Walid) Date: Tue, 23 Sep 2014 22:55:43 +0300 Subject: [Freeipa-users] Client Certificate In-Reply-To: <541C8EBE.7070108@redhat.com> References: <541B3ADE.7000706@redhat.com> <541C8EBE.7070108@redhat.com> Message-ID: Yes Dmitri these two hints would definitely help, the servers are not 4.x yet though. On 19 September 2014 23:14, Dmitri Pal wrote: > On 09/19/2014 04:03 PM, Walid wrote: > > Thank you all, will investigate the requirements of host keytabs, and if > there is a way around it by having it shared but secure for our context. > > > Couple hints. > > 1. If you have a keytab stashed and the system was rebuilt you can now > rerun ipa-client-install using this keytab to get a new one and configure > the client system. It can run and then die but if you store the keytab > after running ipa-client-install you would be able to revive it next time > 2. In 4.1 you will be able to retrieve same keytab using ipa-getkeytab > command. It is implemented to allow clusters that have to share the same > key but it might be applicable to your use case too. > > Thanks > Dmitri > > > > On 18 September 2014 23:04, Dmitri Pal wrote: > >> On 09/18/2014 10:12 AM, Walid A. Shaari wrote: >> >> Hi, >> >> we are going to have a use case of diskless HPC clients that will use >> the IPA for lookups, I was wondering if i can get rid of the state-fulness >> of the client configuration as much as possible as it is more of a cattle >> than pets use case. that is i do not need to know that the client is part >> of the domain, no need to enroll a node with a certificate. and services >> will be mostly hpc mpi and ssh, not required to have an SSL certificate for >> secure communication. is it possible to get rid of the client certificate >> and the requirements for clients to enroll? or there are other uses for the >> certificate that i am not aware of ? >> >> regards >> >> Walid >> >> >> I think the main problem is making sure that the client can connect to >> IPA server. >> You can elect to not use ipa-client and just copy configuration files. >> The problem is that SSSD requires some type of the authentication to get to >> IPA as a host to do the lookups. >> So this connection must be authenticated. Since you want it to be >> stateless you do not want to manage keys or certs the only option (which I >> really do not like) is to use bind password in a file for LDAP connection. >> You would probably use the same unprivileged account for this bind. However >> when we get to 4.x you would need to adjust permissions on the server side >> to make sure that proper read permissions are granted. Having a password in >> a file is a security risk so make sure it is not leaked. >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go To http://freeipa.org for more info on the project >> > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tommythekid at gmail.com Tue Sep 23 23:11:10 2014 From: tommythekid at gmail.com (Tommy McNeely) Date: Tue, 23 Sep 2014 17:11:10 -0600 Subject: [Freeipa-users] Disable Anonymous LDAP another way... Message-ID: Hi all, I have seen the documentation on how to disable anonymous access *completely* at http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/disabling-anon-binds.html However, I think that those base rootdse queries are probably important. I originally thought they only happened when running "ipa-client-install" but some quick tailing of the access log indicates to me that they happen a lot. So, instead of flipping the big switch in cn=config, has anyone considered just removing anonymous access to the *directory* data like: # Remove Anonymous Access to main directory dn: dc=example,dc=com changetype: modify delete: aci aci: (target != "ldap:///idnsname=*,cn=dns,dc=example,dc=com")(targetatt r != "userPassword || krbPrincipalKey || sambaLMPassword || sambaNTPassword | | passwordHistory || krbMKey || userPKCS12 || ipaNTHash || ipaNTTrustAuthOutg oing || ipaNTTrustAuthIncoming")(version 3.0; acl "Enable Anonymous access"; allow (read, search, compare) userdn = "ldap:///anyone";) Would that work without breaking things? Do we have any information on what "broken" systems require anonymous LDAP binds and which ones do not? Thanks in advance, Tommy -------------- next part -------------- An HTML attachment was scrubbed... URL: From netvent at gmail.com Tue Sep 23 23:35:59 2014 From: netvent at gmail.com (swartz) Date: Tue, 23 Sep 2014 17:35:59 -0600 Subject: [Freeipa-users] PKI-CA fails to start (broken config after update?) In-Reply-To: <1411396983.11730.35.camel@aleeredhat.laptop> References: <541CB5F3.7060107@gmail.com> <541FE2F0.3050904@redhat.com> <1411396983.11730.35.camel@aleeredhat.laptop> Message-ID: <542203DF.9020203@gmail.com> On 9/22/2014 7:59 PM, Ade Lee wrote: > If you scroll to the end of the CS.cfg, does it look like it has been > truncated? I'd have to say no. It doesn't look truncated to me. At least there are no obvious signs. But then again I don't know everything that is suppose to be there. I know that the line starting with "pkicreate.unsecure_port=" isn't there, that's for sure. Hence why init script fails to start PKI-CA. > If you have backups of the CS.cfg, that will help. Also, you could look > for backups that we have created: Sadly there were no backups. This was a test/dev VM with no backup policy. > find /var/lib/pki-ca -name CS.cfg* > find /var/log -name CS.cfg* I've replied to you directly with all CS.cfg* files I could find. Most appear to be templates and not backups as per your message. > Also, do you have a replica CA? Yes and no. The master was originally configured with a replica but the test replica VM was not used after that and was shutdown and removed. From netvent at gmail.com Tue Sep 23 23:37:53 2014 From: netvent at gmail.com (swartz) Date: Tue, 23 Sep 2014 17:37:53 -0600 Subject: [Freeipa-users] PKI-CA fails to start (broken config after update?) In-Reply-To: <1411437587.11730.66.camel@aleeredhat.laptop> References: <541CB5F3.7060107@gmail.com> <541FE2F0.3050904@redhat.com> <1411396983.11730.35.camel@aleeredhat.laptop> <1411398869.11730.38.camel@aleeredhat.laptop> <54207AF9.6020905@gmail.com> <1411437587.11730.66.camel@aleeredhat.laptop> Message-ID: <54220451.1030801@gmail.com> On 9/22/2014 7:59 PM, Ade Lee wrote: > If you scroll to the end of the CS.cfg, does it look like it has been > truncated? I'd have to say no. It doesn't look truncated to me. At least there are no obvious signs. But then again I don't know everything that is suppose to be there. I know that the line starting with "pkicreate.unsecure_port=" isn't there, that's for sure. Hence why init script fails to start PKI-CA. > If you have backups of the CS.cfg, that will help. Also, you could look > for backups that we have created: Sadly there were no backups. This was a test/dev VM with no backup policy. > find /var/lib/pki-ca -name CS.cfg* > find /var/log -name CS.cfg* I've replied to you directly with all CS.cfg* files I could find. Most appear to be templates and not backups as per your message. > Also, do you have a replica CA? Yes and no. The master was originally configured with a replica but the test replica VM was not used after that and was shutdown and removed. PS. I replied to the wrong email. Ooops, sorry. From tommythekid at gmail.com Tue Sep 23 23:49:18 2014 From: tommythekid at gmail.com (Tommy McNeely) Date: Tue, 23 Sep 2014 17:49:18 -0600 Subject: [Freeipa-users] Disable Anonymous LDAP another way... In-Reply-To: References: Message-ID: DISREGARD! Sorry all, do not actually try my query, it makes authentication not work at least on CentOS6. Here is the doc I actually read the first time: http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/disabling-anon-binds.html (google search led me here) ... which says to turn it off, while the one I linked above: http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/disabling-anon-binds.html says to set it to "rootdse" which allows the necessary access for detecting configuration, but blocks access to directory data. I just mis-read it on the F18 docs. Sorry for the noise :) On Tue, Sep 23, 2014 at 5:11 PM, Tommy McNeely wrote: > Hi all, > > I have seen the documentation on how to disable anonymous access > *completely* at > http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/disabling-anon-binds.html > > However, I think that those base rootdse queries are probably important. I > originally thought they only happened when running "ipa-client-install" but > some quick tailing of the access log indicates to me that they happen a lot. > > So, instead of flipping the big switch in cn=config, has anyone considered > just removing anonymous access to the *directory* data like: > > # Remove Anonymous Access to main directory > dn: dc=example,dc=com > changetype: modify > delete: aci > aci: (target != "ldap:///idnsname=*,cn=dns,dc=example,dc=com")(targetatt > r != "userPassword || krbPrincipalKey || sambaLMPassword || > sambaNTPassword | > | passwordHistory || krbMKey || userPKCS12 || ipaNTHash || > ipaNTTrustAuthOutg > oing || ipaNTTrustAuthIncoming")(version 3.0; acl "Enable Anonymous > access"; > allow (read, search, compare) userdn = "ldap:///anyone";) > > > > Would that work without breaking things? Do we have any information on > what "broken" systems require anonymous LDAP binds and which ones do not? > > Thanks in advance, > Tommy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Sep 24 01:18:53 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 23 Sep 2014 21:18:53 -0400 Subject: [Freeipa-users] Client Certificate In-Reply-To: References: <541B3ADE.7000706@redhat.com> <541C8EBE.7070108@redhat.com> Message-ID: <54221BFD.1010108@redhat.com> On 09/23/2014 03:55 PM, Walid wrote: > Yes Dmitri these two hints would definitely help, the servers are not > 4.x yet though. The first one is available in FreeIPA 3.3 which ships with RHEL7. > > On 19 September 2014 23:14, Dmitri Pal > wrote: > > On 09/19/2014 04:03 PM, Walid wrote: >> Thank you all, will investigate the requirements of host keytabs, >> and if there is a way around it by having it shared but secure >> for our context. > > Couple hints. > > 1. If you have a keytab stashed and the system was rebuilt you can > now rerun ipa-client-install using this keytab to get a new one > and configure the client system. It can run and then die but if > you store the keytab after running ipa-client-install you would be > able to revive it next time > 2. In 4.1 you will be able to retrieve same keytab using > ipa-getkeytab command. It is implemented to allow clusters that > have to share the same key but it might be applicable to your use > case too. > > Thanks > Dmitri > > >> >> On 18 September 2014 23:04, Dmitri Pal > > wrote: >> >> On 09/18/2014 10:12 AM, Walid A. Shaari wrote: >>> Hi, >>> >>> we are going to have a use case of diskless HPC clients that >>> will use the IPA for lookups, I was wondering if i can get >>> rid of the state-fulness of the client configuration as much >>> as possible as it is more of a cattle than pets use case. >>> that is i do not need to know that the client is part of the >>> domain, no need to enroll a node with a certificate. and >>> services will be mostly hpc mpi and ssh, not required to >>> have an SSL certificate for secure communication. is it >>> possible to get rid of the client certificate and the >>> requirements for clients to enroll? or there are other uses >>> for the certificate that i am not aware of ? >>> >>> regards >>> >>> Walid >>> >>> >> I think the main problem is making sure that the client can >> connect to IPA server. >> You can elect to not use ipa-client and just copy >> configuration files. The problem is that SSSD requires some >> type of the authentication to get to IPA as a host to do the >> lookups. >> So this connection must be authenticated. Since you want it >> to be stateless you do not want to manage keys or certs the >> only option (which I really do not like) is to use bind >> password in a file for LDAP connection. You would probably >> use the same unprivileged account for this bind. However when >> we get to 4.x you would need to adjust permissions on the >> server side to make sure that proper read permissions are >> granted. Having a password in a file is a security risk so >> make sure it is not leaked. >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go To http://freeipa.org for more info on the project >> >> > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Sep 24 01:24:40 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 23 Sep 2014 21:24:40 -0400 Subject: [Freeipa-users] Squid negotiate auth and trust relationship In-Reply-To: <1411487681.3489.27.camel@toron.pzo.lgs.com.ve> References: <1411487681.3489.27.camel@toron.pzo.lgs.com.ve> Message-ID: <54221D58.9020109@redhat.com> On 09/23/2014 11:54 AM, Loris Santamaria wrote: > Hi, I'm setting up a squid proxy in a environment with a trust > relationship between IPA and AD. > > The machine where squid is running belongs to the IPA domain, users may > belong to AD or to IPA and in each one of the domains there are groups > that define the level of internet access of their members. > > For simplicity's sake, let's say that there is only one group in each > domain called "internet_access". Its member should be granted permission > by squid. > > In IPA I created an external group called internet_access_ad, whose > member is internet_access at ad.domain.com, so if the user is a member of > internet_access in AD it should be a member of internet_access in IPA, > thanks to the trust relationship. > > The authentication part works beautifully, IPA and AD users are > recognized by the squid proxy via negotiate auth, but the authorization > part is another story. > > Since the remote user hasn't logged in v?a console or ssh on the server > where squid is running, SSSD ignores its group membership, so one can't > use squid's pam_group helper to determine if the user is in the > internet_access at ipa.domain.com group. > > Trying to lookup for membership via ldap in the compat tree doesn't > really work (see my previous mail on the subject). Also, it won't work > when the realm name is in upper case, although this should be really > easy to solve in the squid helper. > > For the time being I will resort to make two ldap queries, one on IPA > and one on AD, but it seems to me that the proper way to go would be to > decode the PAC and get authorization info from there, or have a way to > query SSSD for complete group membership of a user even if he or she > hasn't logged in on a server. > > How could SSSD/IPA could help to solve this fairly common need (querying > user membership from an app)? I think this is the issue that you are describing. Patches are on the list and targeting 4.1.x and 1.12.x https://fedorahosted.org/freeipa/ticket/4031 > > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From baghery.jone at gmail.com Wed Sep 24 05:14:35 2014 From: baghery.jone at gmail.com (alireza baghery) Date: Wed, 24 Sep 2014 08:44:35 +0330 Subject: [Freeipa-users] problem with log in ipa Message-ID: hi i have configured ipa (ipa on centos 6.5) and configure rsyslog for send log to syslog server (juniper strm) in strm get error unknown generic log event (log's ipa clients ) but with another server linux not problem -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Wed Sep 24 06:52:16 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 24 Sep 2014 08:52:16 +0200 Subject: [Freeipa-users] Disable Anonymous LDAP another way... In-Reply-To: References: Message-ID: <54226A20.3070804@redhat.com> On 09/24/2014 01:11 AM, Tommy McNeely wrote: > Hi all, > > I have seen the documentation on how to disable anonymous access > *completely* at > http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/disabling-anon-binds.html > > However, I think that those base rootdse queries are probably important. I > originally thought they only happened when running "ipa-client-install" but > some quick tailing of the access log indicates to me that they happen a lot. > > So, instead of flipping the big switch in cn=config, has anyone considered > just removing anonymous access to the *directory* data like: Oh yes, "somebody" indeed considered another way! This was one of the core feature of FreeIPA 4.0 which removed ACI you mentioned and replaced it with set of very targeted Read ACIs so that admin will get a fine grained control who can read what. This is the feature page: http://www.freeipa.org/page/V4/Permissions_V2 This is where you can try the new version: http://www.freeipa.org/page/Downloads#Latest_Release_-_FreeIPA_4.0.3 HTH, Martin From traiano at gmail.com Wed Sep 24 11:06:33 2014 From: traiano at gmail.com (Traiano Welcome) Date: Wed, 24 Sep 2014 14:06:33 +0300 Subject: [Freeipa-users] FreeIPA 3.3 and Solaris 10 Client Integration: Message-ID: Hi List I'm currently running IPA 3.3 on Centos 7, and successfully authenticating Linux clients (Centos 6.5). I'd like to setup Solaris 10 as an IPA client, but this seems problematic. I am following this guide: http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html#Configuring_an_IPA_Client_on_Solaris_10 I have the following setup: Solaris client: - Solaris 10u11 (SunOS 5.10 Generic_147148-26 i86pc i386 i86pc) IdM Server: - Linux kwtpocipa001.orion.local 3.10.0-123.el7.x86_64 #1 SMP Mon Jun 30 12:09:22 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux Going through the steps in the guide: at step 3 ("Create the cn=proxyagent account"), ldapadd fails with the following error: "ldapadd: invalid format (line 6) entry: "cn=proxyagent,ou=profile,dc=orion,dc=local"" --- [root at kwtpocipa001 ~]# ldapadd -h 172.16.107.102 -p 389 -D "cn=directory manager" -w Cr4ckM0nk3y dn: cn=proxyagent,ou=profile,dc=orion,dc=local objectClass: top objectClass: person sn: proxyagent cn: proxyagent userPassword:: e1NTSEF9Mm53KytGeU81Z1dka1FLNUZlaDdXOHJkK093TEppY2NjRmt6Wnc9PQ= ldapadd: invalid format (line 6) entry: "cn=proxyagent,ou=profile,dc=orion,dc=local" --- I've made the assumption that the extra ":" is a typo in the documentation and removed it, so the command runs successfully as follows: --- [root at kwtpocipa001 ~]# ldapadd -h 172.16.107.102 -p 389 -D "cn=directory manager" -w Cr4ckM0nk3y dn: cn=proxyagent,ou=profile,dc=orion,dc=local objectClass: top objectClass: person sn: proxyagent cn: proxyagent userPassword: e1NTSEF9Mm53KytGeU81Z1dka1FLNUZlaDdXOHJkK093TEppY2NjRmt6Wnc9PQ= adding new entry "cn=proxyagent,ou=profile,dc=orion,dc=local" --- At step 9 (Configure NFS ), I get an error, seems to indicate the "des-cbc-crc" encryption type is unsupported: --- [root at kwtpocipa001 ~]# ipa-getkeytab -s kwtpocipa001.orion.local -p nfs/kwtpocipasol10u11.orion.local -k /tmp/kwtpocipasol10u11.keytab -e des-cbc-crc Operation failed! All enctypes provided are unsupported [root at kwtpocipa001 ~]# --- (Question: How would I add support for des-cbc-crc encryption in freeipa?). I've now worked around this by not specifying any encryption type: --- [root at kwtpocipa001 ~]# ipa-getkeytab -s kwtpocipa001.orion.local -p nfs/kwtpocipasol10u11.orion.local -k /tmp/kwtpocipasol10u11.keytab Keytab successfully retrieved and stored in: /tmp/kwtpocipasol10u11.keytab [root at kwtpocipa001 ~]# --- Testing that I can see nfs mounts on the centos IPA server from the solaris machine: --- bash-3.2# showmount -e kwtpocipa001.orion.local export list for kwtpocipa001.orion.local: /data/centos-repo 172.16.0.0/24 bash-3.2# ---- Checking we can kinit: --- bash-3.2# bash-3.2# kinit admin Password for admin at ORION.LOCAL: bash-3.2# bash-3.2# bash-3.2# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: admin at ORION.LOCAL Valid starting Expires Service principal 09/24/14 11:20:36 09/24/14 12:20:36 krbtgt/ORION.LOCAL at ORION.LOCAL renew until 10/01/14 11:20:36 bash-3.2# bash-3.2# bash-3.2# bash-3.2# uname -a SunOS kwtpocipasol10u11 5.10 Generic_147148-26 i86pc i386 i86pc bash-3.2# --- Testing I can mount the remote FS (without Kerberos auth). This is successful (when not using kerberos5 authentication): --- bash-3.2# mount -F nfs 172.16.107.102:/data/centos-repo /remote/ bash-3.2# mount |grep remote /remote on 172.16.107.102:/data/centos-repo remote/read/write/setuid/devices/rstchown/xattr/dev=4f0000a on Wed Sep 24 13:45:32 2014 bash-3.2# --- Testing with KRB5: --- bash-3.2# mount -F nfs -o sec=krb5 172.16.107.102:/data/centos-repo /remote/ nfs mount: mount: /remote: Permission denied bash-3.2# --- Looking at the krbkdc logs on the IPA master server, I get the following error: --- Sep 24 13:48:17 kwtpocipa001.orion.local krb5kdc[2371](info): AS_REQ (6 etypes {18 17 16 23 3 1}) 172.16.107.107: NEEDED_PREAUTH: host/kwtpocipasol10u11.orion.local at ORION.LOCAL for krbtgt/ORION.LOCAL at ORION.LOCAL, Additional pre-authentication required Sep 24 13:48:17 kwtpocipa001.orion.local krb5kdc[2373](info): DISPATCH: repeated (retransmitted?) request from 172.16.107.107, resending previous response Sep 24 13:48:17 kwtpocipa001.orion.local krb5kdc[2374](info): DISPATCH: repeated (retransmitted?) request from 172.16.107.107, resending previous response . . . Sep 24 13:48:18 kwtpocipa001.orion.local krb5kdc[2373](info): AS_REQ (6 etypes {18 17 16 23 3 1}) 172.16.107.107: CLIENT_NOT_FOUND: root/kwtpocipasol10u11.orion.local at ORION.LOCAL for krbtgt/ORION.LOCAL at ORION.LOCAL, Client not found in Kerberos database --- So it seems the host is not correctly registered. NOTE: Via the interface ,I can see the solaris client is not properly enrolled (" Kerberos Key Not Present"), however the documentation doesn't seem to indicate clearly how this should be done for a Solaris client. I have regenerated the certificate though, so it shows "valid certificate present". My question is: Is the process described in this guide still correct/functional for integrating Solaris 10 clients? If so, is there some way I could debug further to pinpoint why the solaris client is not being registered in the Kerberos DB? Many thanks in advance! Traiano -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Wed Sep 24 11:18:33 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 24 Sep 2014 13:18:33 +0200 Subject: [Freeipa-users] FreeIPA 3.3 and Solaris 10 Client Integration: In-Reply-To: References: Message-ID: <5422A889.3040907@redhat.com> On 09/24/2014 01:06 PM, Traiano Welcome wrote: > Hi List > > I'm currently running IPA 3.3 on Centos 7, and successfully authenticating > Linux clients (Centos 6.5). > > I'd like to setup Solaris 10 as an IPA client, but this seems > problematic. I am following this guide: > > http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html#Configuring_an_IPA_Client_on_Solaris_10 > > I have the following setup: > > Solaris client: > > - Solaris 10u11 (SunOS 5.10 Generic_147148-26 i86pc i386 i86pc) > > IdM Server: > > - Linux kwtpocipa001.orion.local 3.10.0-123.el7.x86_64 #1 SMP Mon Jun 30 > 12:09:22 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux > > > > Going through the steps in the guide: at step 3 ("Create the cn=proxyagent > account"), ldapadd fails with the following error: > > > > "ldapadd: invalid format (line 6) entry: > "cn=proxyagent,ou=profile,dc=orion,dc=local"" > > --- > > [root at kwtpocipa001 ~]# ldapadd -h 172.16.107.102 -p 389 -D "cn=directory > manager" -w Cr4ckM0nk3y > dn: cn=proxyagent,ou=profile,dc=orion,dc=local > objectClass: top > objectClass: person > sn: proxyagent > cn: proxyagent > userPassword:: > e1NTSEF9Mm53KytGeU81Z1dka1FLNUZlaDdXOHJkK093TEppY2NjRmt6Wnc9PQ= > > ldapadd: invalid format (line 6) entry: > "cn=proxyagent,ou=profile,dc=orion,dc=local" > --- > > I've made the assumption that the extra ":" is a typo in the documentation > and removed it, so the command runs successfully as follows: > > > --- > [root at kwtpocipa001 ~]# ldapadd -h 172.16.107.102 -p 389 -D "cn=directory > manager" -w Cr4ckM0nk3y > > dn: cn=proxyagent,ou=profile,dc=orion,dc=local > objectClass: top > objectClass: person > sn: proxyagent > cn: proxyagent > userPassword: > e1NTSEF9Mm53KytGeU81Z1dka1FLNUZlaDdXOHJkK093TEppY2NjRmt6Wnc9PQ= > adding new entry "cn=proxyagent,ou=profile,dc=orion,dc=local" > --- > > > At step 9 (Configure NFS ), I get an error, seems to indicate the > "des-cbc-crc" encryption type is unsupported: > > --- > [root at kwtpocipa001 ~]# ipa-getkeytab -s kwtpocipa001.orion.local -p > nfs/kwtpocipasol10u11.orion.local -k /tmp/kwtpocipasol10u11.keytab -e > des-cbc-crc > Operation failed! All enctypes provided are unsupported > [root at kwtpocipa001 ~]# > --- > > (Question: How would I add support for des-cbc-crc encryption in > freeipa?). I've now worked around this by not specifying any encryption > type: > > --- > [root at kwtpocipa001 ~]# ipa-getkeytab -s kwtpocipa001.orion.local -p > nfs/kwtpocipasol10u11.orion.local -k /tmp/kwtpocipasol10u11.keytab > Keytab successfully retrieved and stored in: /tmp/kwtpocipasol10u11.keytab > [root at kwtpocipa001 ~]# > --- > > Testing that I can see nfs mounts on the centos IPA server from the solaris > machine: > > --- > bash-3.2# showmount -e kwtpocipa001.orion.local > export list for kwtpocipa001.orion.local: > /data/centos-repo 172.16.0.0/24 > bash-3.2# > ---- > > > Checking we can kinit: > > --- > bash-3.2# > bash-3.2# kinit admin > Password for admin at ORION.LOCAL: > bash-3.2# > bash-3.2# > bash-3.2# klist > Ticket cache: FILE:/tmp/krb5cc_0 > Default principal: admin at ORION.LOCAL > Valid starting Expires Service principal > 09/24/14 11:20:36 09/24/14 12:20:36 krbtgt/ORION.LOCAL at ORION.LOCAL > renew until 10/01/14 11:20:36 > bash-3.2# > bash-3.2# > bash-3.2# > bash-3.2# uname -a > SunOS kwtpocipasol10u11 5.10 Generic_147148-26 i86pc i386 i86pc > bash-3.2# > --- > > Testing I can mount the remote FS (without Kerberos auth). This is > successful (when not using kerberos5 authentication): > > --- > bash-3.2# mount -F nfs 172.16.107.102:/data/centos-repo /remote/ > bash-3.2# mount |grep remote > /remote on 172.16.107.102:/data/centos-repo > remote/read/write/setuid/devices/rstchown/xattr/dev=4f0000a on Wed Sep 24 > 13:45:32 2014 > bash-3.2# > --- > > Testing with KRB5: > > --- > bash-3.2# mount -F nfs -o sec=krb5 172.16.107.102:/data/centos-repo /remote/ > nfs mount: mount: /remote: Permission denied > bash-3.2# > --- > > Looking at the krbkdc logs on the IPA master server, I get the following > error: > > --- > Sep 24 13:48:17 kwtpocipa001.orion.local krb5kdc[2371](info): AS_REQ (6 > etypes {18 17 16 23 3 1}) 172.16.107.107: NEEDED_PREAUTH: > host/kwtpocipasol10u11.orion.local at ORION.LOCAL for > krbtgt/ORION.LOCAL at ORION.LOCAL, Additional pre-authentication required > Sep 24 13:48:17 kwtpocipa001.orion.local krb5kdc[2373](info): DISPATCH: > repeated (retransmitted?) request from 172.16.107.107, resending previous > response > Sep 24 13:48:17 kwtpocipa001.orion.local krb5kdc[2374](info): DISPATCH: > repeated (retransmitted?) request from 172.16.107.107, resending previous > response > . > . > . > Sep 24 13:48:18 kwtpocipa001.orion.local krb5kdc[2373](info): AS_REQ (6 > etypes {18 17 16 23 3 1}) 172.16.107.107: CLIENT_NOT_FOUND: > root/kwtpocipasol10u11.orion.local at ORION.LOCAL for > krbtgt/ORION.LOCAL at ORION.LOCAL, Client not found in Kerberos database > > --- > > So it seems the host is not correctly registered. > > NOTE: Via the interface ,I can see the solaris client is > not properly enrolled (" Kerberos Key Not Present"), however the > documentation doesn't seem to indicate clearly how this should be done for > a Solaris client. I have regenerated the certificate though, so it shows > "valid certificate present". > > My question is: Is the process described in this guide still > correct/functional for integrating Solaris 10 clients? > If so, is there some way I could debug further to pinpoint why the solaris > client is not being registered in the Kerberos DB? > > Many thanks in advance! > Traiano Hello Traiano, This part of the documentation is wrong, as reported by ldapadd, userpassword is not correct. If you specify the entry with clear text password, it would work. I.e.: dn: cn=proxyagent,ou=profile,dc=orion,dc=local objectClass: top objectClass: person sn: proxyagent cn: proxyagent userPassword: agentpassword Note that Solaris related documentation is (unfortunately) known to be off: https://fedorahosted.org/freeipa/ticket/3731 Also please note that the guide you are referring to is also pretty old (from Fedora 18 times) and not updated. There is a related thread: https://www.redhat.com/archives/freeipa-users/2014-September/msg00357.html Martin From mkosek at redhat.com Wed Sep 24 11:20:10 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 24 Sep 2014 13:20:10 +0200 Subject: [Freeipa-users] Disable Anonymous LDAP another way... In-Reply-To: References: Message-ID: <5422A8EA.9050605@redhat.com> On 09/24/2014 01:49 AM, Tommy McNeely wrote: > DISREGARD! > > Sorry all, do not actually try my query, it makes authentication not work > at least on CentOS6. > > Here is the doc I actually read the first time: > http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/disabling-anon-binds.html > (google search led me here) > ... which says to turn it off, while the one I linked above: > http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/disabling-anon-binds.html > says to set it to "rootdse" which allows the necessary access for detecting > configuration, but blocks access to directory data. > > I just mis-read it on the F18 docs. > > Sorry for the noise :) One more note - there is a related proposal wrt to upstream guide (as you probably noticed, you are referring to guide from Fedora 15/18 times: https://www.redhat.com/archives/freeipa-users/2014-September/msg00357.html Martin From tevfik.ceydeliler at astron.yasar.com.tr Wed Sep 24 11:23:28 2014 From: tevfik.ceydeliler at astron.yasar.com.tr (Tevfik Ceydeliler) Date: Wed, 24 Sep 2014 14:23:28 +0300 Subject: [Freeipa-users] New version Freeipa when? Message-ID: <5422A9B0.1000106@astron.yasar.com.tr> Hi, Do you know when new version Freeipa (v4) places on redhat or centos repository?


Bu elektronik postada bulunan tum fikir ve gorusler ve ekindeki dosyalar sadece adres sahip/sahiplerine ait olup, Yasar Toplulugu Sirketleri bu mesajin icerigi ile ilgili olarak hic bir hukuksal sorumlulugu kabul etmez. Eger gonderilmesi dusunulen kisi veya kurulus degilseniz, lutfen gonderen kisiyi derhal haberdar ediniz ve mesaji sisteminizden siliniz.The information contained in this e-mail and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and Yasar Group Companies do not accept legal responsibility for the contents. If you are not the intended recipient, please immediately notify the sender and delete it from your system. From mkosek at redhat.com Wed Sep 24 11:31:40 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 24 Sep 2014 13:31:40 +0200 Subject: [Freeipa-users] New version Freeipa when? In-Reply-To: <5422A9B0.1000106@astron.yasar.com.tr> References: <5422A9B0.1000106@astron.yasar.com.tr> Message-ID: <5422AB9C.2060502@redhat.com> On 09/24/2014 01:23 PM, Tevfik Ceydeliler wrote: > > Hi, Do you know when new version Freeipa (v4) places on redhat or centos > repository? Please define "new version" - do you mean FreeIPA 4.0.3? Or FreeIPA 4.1? Also, by "repository", you mean "official CentOS/RHEL" repository or would a FreeIPA upstream repository be enough for you? Note that the latest FreeIPA stable upstream version is available as a Copr build that is also built for RHEL/CentOS 7.0: http://copr.fedoraproject.org/coprs/mkosek/freeipa/ The RHEL/CentOS version is still not completely working, though we are very close. See related thread: http://www.redhat.com/archives/freeipa-devel/2014-September/msg00530.html This is the reason why we did not announce the RHEL/CentOS build more publicly yet. HTH, Martin From tevfik.ceydeliler at astron.yasar.com.tr Wed Sep 24 11:33:30 2014 From: tevfik.ceydeliler at astron.yasar.com.tr (Tevfik Ceydeliler) Date: Wed, 24 Sep 2014 14:33:30 +0300 Subject: [Freeipa-users] New version Freeipa when? In-Reply-To: <5422AB9C.2060502@redhat.com> References: <5422A9B0.1000106@astron.yasar.com.tr> <5422AB9C.2060502@redhat.com> Message-ID: <5422AC0A.2020101@astron.yasar.com.tr> Let me be more specific, I want to know that when FreeIPA 4.0.3 or above place in RHEL/CentOS official repository. (Not COPR) On 24-09-2014 14:31, Martin Kosek wrote: > On 09/24/2014 01:23 PM, Tevfik Ceydeliler wrote: >> Hi, Do you know when new version Freeipa (v4) places on redhat or centos >> repository? > Please define "new version" - do you mean FreeIPA 4.0.3? Or FreeIPA 4.1? Also, > by "repository", you mean "official CentOS/RHEL" repository or would a FreeIPA > upstream repository be enough for you? > > Note that the latest FreeIPA stable upstream version is available as a Copr > build that is also built for RHEL/CentOS 7.0: > > http://copr.fedoraproject.org/coprs/mkosek/freeipa/ > > The RHEL/CentOS version is still not completely working, though we are very > close. See related thread: > > http://www.redhat.com/archives/freeipa-devel/2014-September/msg00530.html > > This is the reason why we did not announce the RHEL/CentOS build more publicly yet. > > HTH, > Martin --


Bu elektronik postada bulunan tum fikir ve gorusler ve ekindeki dosyalar sadece adres sahip/sahiplerine ait olup, Yasar Toplulugu Sirketleri bu mesajin icerigi ile ilgili olarak hic bir hukuksal sorumlulugu kabul etmez. Eger gonderilmesi dusunulen kisi veya kurulus degilseniz, lutfen gonderen kisiyi derhal haberdar ediniz ve mesaji sisteminizden siliniz.The information contained in this e-mail and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and Yasar Group Companies do not accept legal responsibility for the contents. If you are not the intended recipient, please immediately notify the sender and delete it from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.png Type: image/png Size: 15216 bytes Desc: not available URL: From mkosek at redhat.com Wed Sep 24 11:37:15 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 24 Sep 2014 13:37:15 +0200 Subject: [Freeipa-users] New version Freeipa when? In-Reply-To: <5422AC0A.2020101@astron.yasar.com.tr> References: <5422A9B0.1000106@astron.yasar.com.tr> <5422AB9C.2060502@redhat.com> <5422AC0A.2020101@astron.yasar.com.tr> Message-ID: <5422ACEB.3040806@redhat.com> In that case you can look forward to RHEL-7.1! Related rebase bug: https://bugzilla.redhat.com/show_bug.cgi?id=1109726 Martin On 09/24/2014 01:33 PM, Tevfik Ceydeliler wrote: > Let me be more specific, > I want to know that when FreeIPA 4.0.3 or above place in RHEL/CentOS official > repository. (Not COPR) > > On 24-09-2014 14:31, Martin Kosek wrote: >> On 09/24/2014 01:23 PM, Tevfik Ceydeliler wrote: >>> Hi, Do you know when new version Freeipa (v4) places on redhat or centos >>> repository? >> Please define "new version" - do you mean FreeIPA 4.0.3? Or FreeIPA 4.1? Also, >> by "repository", you mean "official CentOS/RHEL" repository or would a FreeIPA >> upstream repository be enough for you? >> >> Note that the latest FreeIPA stable upstream version is available as a Copr >> build that is also built for RHEL/CentOS 7.0: >> >> http://copr.fedoraproject.org/coprs/mkosek/freeipa/ >> >> The RHEL/CentOS version is still not completely working, though we are very >> close. See related thread: >> >> http://www.redhat.com/archives/freeipa-devel/2014-September/msg00530.html >> >> This is the reason why we did not announce the RHEL/CentOS build more publicly yet. >> >> HTH, >> Martin > > -- > > > > > > > Bu elektronik postada bulunan tum fikir ve gorusler ve ekindeki dosyalar sadece > adres sahip/sahiplerine ait olup, Yasar Toplulugu Sirketleri bu mesajin icerigi > ile ilgili olarak hic bir hukuksal sorumlulugu kabul etmez. Eger gonderilmesi > dusunulen kisi veya kurulus degilseniz, lutfen gonderen kisiyi derhal haberdar > ediniz ve mesaji sisteminizden siliniz.The information contained in this e-mail > and any files transmitted with it are intended solely for the use of the > individual or entity to whom they are addressed and Yasar Group Companies do not > accept legal responsibility for the contents. If you are not the intended > recipient, please immediately notify the sender and delete it from your system. > From rcritten at redhat.com Wed Sep 24 14:15:48 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 24 Sep 2014 10:15:48 -0400 Subject: [Freeipa-users] problem with log in ipa In-Reply-To: References: Message-ID: <5422D214.8030508@redhat.com> alireza baghery wrote: > hi > i have configured ipa (ipa on centos 6.5) and configure rsyslog for send > log to syslog server (juniper strm) > in strm get error unknown generic log event (log's ipa clients ) > but with another server linux not problem > > I think more details are needed, like how you configured the client for syslog, the error on the syslog server, etc. rob From genadipost at gmail.com Wed Sep 24 16:00:00 2014 From: genadipost at gmail.com (Genadi Postrilko) Date: Wed, 24 Sep 2014 19:00:00 +0300 Subject: [Freeipa-users] AD Trust - Cannot resolve servers for KDC after reboot In-Reply-To: <541FC1BF.5070603@redhat.com> References: <20140916072831.GY2947@localhost.localdomain> <20140919204009.GG2541@redhat.com> <541FC1BF.5070603@redhat.com> Message-ID: 2014-09-22 9:29 GMT+03:00 Petr Spacek : > 'IPA forwarders' are exactly the same as normal 'BIND forward zone' so > they involve normal DNS cache. > Which type of forwarder do you have configured? Is your 'forwarding policy' > set to 'first' (default) or 'only'? > > I have default forwarding policy: [root at ipaserver1 ~]# ipa dnsconfig-show Global forwarders: 192.168.227.60 > Forwarding policy 'first' (combined with cache) could be the cause of your > problem. 'First' policy instructs BIND to contact the configured server and > if it fails (because of timeout) BIND will re-try the same query using > normal recursion. > > Depending on your network configuration, the normal DNS recursion can > return different results than forwarding(^1). In this case BIND can cache > e.g. NXDOMAIN answer from some other server and this answer will stay in > cache for TTL value in the given answer. > > As a result, IPA could get cached NXDOMAIN instead of correct SRV records > for AD until the TTL in cache expires. > > This is of course a wild guess. Detailed logs from named (log level 5 or > higher+querylog) could tell us what exactly happened. > > This the named log after i increased the debug level to 5 and enabled querylog: https://gist.github.com/anonymous/89308cbca3b07252674c > Have a nice day! > > (^1) I would argue that this points to a flaw in network configuration... > > The test involvement is just bunch of VMs in NAT configurations. Petr^2 Spacek > > Thank you for the help. -------------- next part -------------- An HTML attachment was scrubbed... URL: From edewata at redhat.com Wed Sep 24 16:53:26 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 24 Sep 2014 11:53:26 -0500 Subject: [Freeipa-users] PKI-CA fails to start (broken config after update?) In-Reply-To: <542203DF.9020203@gmail.com> References: <541CB5F3.7060107@gmail.com> <541FE2F0.3050904@redhat.com> <1411396983.11730.35.camel@aleeredhat.laptop> <542203DF.9020203@gmail.com> Message-ID: <5422F706.5030006@redhat.com> On 9/23/2014 6:35 PM, swartz wrote: > On 9/22/2014 7:59 PM, Ade Lee wrote: >> If you scroll to the end of the CS.cfg, does it look like it has been >> truncated? > I'd have to say no. It doesn't look truncated to me. At least there are > no obvious signs. But then again I don't know everything that is suppose > to be there. I know that the line starting with > "pkicreate.unsecure_port=" isn't there, that's for sure. Hence why init > script fails to start PKI-CA. Hi, Ade and I looked at the file that you sent, and I sent you an updated CS.cfg based on my system (and you indicated that it's working now). I noticed that your original file contains the following line: cloning.ocsp_signing.dn=CN=OCSP Subsys where it probably should have been something like this: cloning.ocsp_signing.dn=CN=OCSP Subsysstem,O=CS.MYDOMAIN.CA Also, it's missing the next ~400 lines which seem to have been replaced with these lines: proxy.securePort=443 proxy.unsecurePort=80 So we're suspecting that something was adding these proxy parameters directly to CS.cfg while the CA is saving configuration changes to CS.cfg too. Luckily your original CS.cfg still contains enough information to fully restore the file. I guess we need someone who's more familiar with the IPA & CA upgrade process to take a look at this more closely. The CS.cfg is actually owned by the CA server, but sometimes people are advised to change the file directly, and maybe some codes are written that way too. There are some ways to avoid this kind of problems in the future: 1. Require CA to be shutdown before changing CS.cfg directly. 2. Prohibit direct access to the file and require the use of tools that send the changes to the CA server (e.g. via CLI/REST). 3. Break CS.cfg into user-owned and server-owned parameters, and move mostly-static parameters into a separate default file. 4. Replace CS.cfg with LDAP-based configuration. In the short term we might be limited to #1, but in the long term we might be able to implement the other options. -- Endi S. Dewata From netvent at gmail.com Wed Sep 24 18:07:40 2014 From: netvent at gmail.com (swartz) Date: Wed, 24 Sep 2014 12:07:40 -0600 Subject: [Freeipa-users] PKI-CA fails to start (broken config after update?) In-Reply-To: <1411437587.11730.66.camel@aleeredhat.laptop> References: <541CB5F3.7060107@gmail.com> <541FE2F0.3050904@redhat.com> <1411396983.11730.35.camel@aleeredhat.laptop> <1411398869.11730.38.camel@aleeredhat.laptop> <54207AF9.6020905@gmail.com> <1411437587.11730.66.camel@aleeredhat.laptop> Message-ID: <5423086C.2070906@gmail.com> On 9/24/2014 9:05 AM, Ade Lee wrote: > Forwarding to a couple of colleagues of mine who will be taking point on > this. > > From what I can see, the CS.cfg is truncated. Fortunately, I believe it > is reparable. > > Ade I've been in contact with Endi and Ade. It was a truncated config file as per msg above. Endi had emailed me a restored config. I can happily say that my IPA instance is back in operation. Thank you all. For anyone else reading this: For me this config truncation happened after a 'yum update'. Perhaps shutting down the IPA stack before doing package updates might be more advisable. From tobereplaced at gmail.com Wed Sep 24 19:02:34 2014 From: tobereplaced at gmail.com (ToBeReplaced) Date: Wed, 24 Sep 2014 13:02:34 -0600 Subject: [Freeipa-users] 3.3.3 - Unable to install remote client Message-ID: <1411585354.2137.15.camel@localhost.localdomain> Hi! I've had an issue trying to install a client on a new server installation. Version 3.3.3 on CentOS 7 for both client and server. In details below, the domain name, server host name, and ip address has been changed. The server is sitting behind a router with ip 12.34.56.78. The server was configured with `--enable-dns` and `192.168.1.100 ipa.example.com ipa` in /etc/hosts. firewalld has been set to open up ports for ldap, ldaps, kerberos, kpasswd, dns, ntp, http, https on both the client and server. Port 7389 is also open on the server. The router has been configured to forward all of the above ports through 12.34.56.78 to 192.168.1.100. The client is sitting on a different network (say, behind a router with ip 98.76.54.32). Its /etc/hosts includes `12.34.56.78 ipa.example.com ipa`. Its /etc/resolv.conf includes `nameserver 12.34.56.78` ipa-client-install fails with: Discovery was successful! Hostname: laptop-1.example.com Realm: EXAMPLE.COM DNS Domain: example.com IPA Server: ipa.example.com BaseDN: dc=example,dc=com Synchronizing time with KDC... Successfully retrieved CA cert Subject: CN=Certificate Authority,O=EXAMPLE.COM Issuer: CN=Certificate Authority,O=EXAMPLE.COM Valid From: Wed Sep 24 17:44:28 2014 UTC Valid Until: Sun Sep 24 17:44:28 2034 UTC Enrolled in IPA realm EXAMPLE.COM Created /etc/ipa/default.conf New SSSD config will be created Configured /etc/sssd/sssd.conf Configured /etc/krb5.conf for IPA realm EXAMPLE.COM trying https://ipa.example.com/ipa/xml Forwarding 'ping' to server 'https://ipa.example.com/ipa/xml' Cannot connect to the server due to Kerberos error: Kerberos error: ('Unspecified GSS failure. Minor code may provide more information', 851968)/("Cannot contact any KDC for realm 'EXAMPLE.COM'", -1765328228). Trying with delegate=True trying https://ipa.example.com/ipa/xml Forwarding 'ping' to server 'https://ipa.example.com/ipa/xml' Second connect with delegate=True also failed: Kerberos error: ('Unspecified GSS failure. Minor code may provide more information', 851968)/("Cannot contact any KDC for realm 'EXAMPLE.COM'", -1765328228) Cannot connect to the IPA server XML-RPC interface: Kerberos error: ('Unspecified GSS failure. Minor code may provide more information', 851968)/("Cannot contact any KDC for realm 'EXAMPLE.COM'", -1765328228) Installation failed. Rolling back changes. Unenrolling client from IPA server Unenrolling host failed: Error obtaining initial credentials: Cannot contact any KDC for requested realm. Removing Kerberos service principals from /etc/krb5.keytab Disabling client Kerberos and LDAP configurations Redundant SSSD configuration file /etc/sssd/sssd.conf was moved to /etc/sssd/sssd.conf.deleted Restoring client configuration files nscd daemon is not installed, skip configuration nslcd daemon is not installed, skip configuration Client uninstall complete. `cat /var/log/ipaclient-install.log | grep ERROR -C 25 -m 1` 2014-09-24T18:11:49Z INFO Configured /etc/krb5.conf for IPA realm EXAMPLE.COM 2014-09-24T18:11:49Z DEBUG Starting external process 2014-09-24T18:11:49Z DEBUG args=keyctl search @s user ipa_session_cookie:host/laptop-1.example.com at EXAMPLE.COM 2014-09-24T18:11:49Z DEBUG Process finished, return code=1 2014-09-24T18:11:49Z DEBUG stdout= 2014-09-24T18:11:49Z DEBUG stderr=keyctl_search: Required key not available 2014-09-24T18:11:49Z DEBUG Starting external process 2014-09-24T18:11:49Z DEBUG args=keyctl search @s user ipa_session_cookie:host/laptop-1.example.com at EXAMPLE.COM 2014-09-24T18:11:49Z DEBUG Process finished, return code=1 2014-09-24T18:11:49Z DEBUG stdout= 2014-09-24T18:11:49Z DEBUG stderr=keyctl_search: Required key not available 2014-09-24T18:11:49Z DEBUG failed to find session_cookie in persistent storage for principal 'host/laptop-1.example.com at EXAMPLE.COM' 2014-09-24T18:11:49Z INFO trying https://ipa.example.com/ipa/xml 2014-09-24T18:11:49Z DEBUG Created connection context.xmlclient 2014-09-24T18:11:49Z DEBUG Try RPC connection 2014-09-24T18:11:49Z INFO Forwarding 'ping' to server 'https://ipa.example.com/ipa/xml' 2014-09-24T18:12:07Z DEBUG Destroyed connection context.xmlclient 2014-09-24T18:12:07Z INFO Cannot connect to the server due to Kerberos error: Kerberos error: ('Unspecified GSS failure. Minor code may provide more information', 851968)/("Cannot contact any KDC for realm 'EXAMPLE.COM'", -1765328228). Trying with delegate=True 2014-09-24T18:12:07Z INFO trying https://ipa.example.com/ipa/xml 2014-09-24T18:12:07Z DEBUG Created connection context.xmlclient 2014-09-24T18:12:07Z DEBUG Try RPC connection 2014-09-24T18:12:07Z INFO Forwarding 'ping' to server 'https://ipa.example.com/ipa/xml' 2014-09-24T18:12:25Z WARNING Second connect with delegate=True also failed: Kerberos error: ('Unspecified GSS failure. Minor code may provide more information', 851968)/("Cannot contact any KDC for realm 'EXAMPLE.COM'", -1765328228) 2014-09-24T18:12:25Z ERROR Cannot connect to the IPA server XML-RPC interface: Kerberos error: ('Unspecified GSS failure. Minor code may provide more information', 851968)/("Cannot contact any KDC for realm 'EXAMPLE.COM'", -1765328228) One possibly worthwhile note is that running tcpdump shows that the client (local IP 192.168.0.102) is trying to connect to 192.168.1.100, the local IP of the server, which is on a different network and thus inaccessible. 14:11:49.611009 IP 192.168.0.102.57552 > 192.168.1.100.kerberos: 14:11:50.645238 IP 192.168.0.102.37952 > 192.168.1.100.kerberos: Flags [S], seq 1224109057, win 14600, op tions [mss 1460,sackOK,TS val 5701517 ecr 0,nop,wscale 7], length 0 14:11:51.648218 IP 192.168.0.102.37952 > 192.168.1.100.kerberos: Flags [S], seq 1224109057, win 14600, op tions [mss 1460,sackOK,TS val 5702520 ecr 0,nop,wscale 7], length 0 etc. etc. Cheers, ToBeReplaced From dpal at redhat.com Wed Sep 24 19:21:03 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 24 Sep 2014 15:21:03 -0400 Subject: [Freeipa-users] PKI-CA fails to start (broken config after update?) In-Reply-To: <5423086C.2070906@gmail.com> References: <541CB5F3.7060107@gmail.com> <541FE2F0.3050904@redhat.com> <1411396983.11730.35.camel@aleeredhat.laptop> <1411398869.11730.38.camel@aleeredhat.laptop> <54207AF9.6020905@gmail.com> <1411437587.11730.66.camel@aleeredhat.laptop> <5423086C.2070906@gmail.com> Message-ID: <5423199F.6050200@redhat.com> On 09/24/2014 02:07 PM, swartz wrote: > On 9/24/2014 9:05 AM, Ade Lee wrote: >> Forwarding to a couple of colleagues of mine who will be taking point on >> this. >> >> From what I can see, the CS.cfg is truncated. Fortunately, I >> believe it >> is reparable. >> >> Ade > > I've been in contact with Endi and Ade. It was a truncated config file > as per msg above. > Endi had emailed me a restored config. > > I can happily say that my IPA instance is back in operation. > > Thank you all. > > For anyone else reading this: > For me this config truncation happened after a 'yum update'. > Perhaps shutting down the IPA stack before doing package updates might > be more advisable. > > Is there any chance to detect which package caused this truncation? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From rcritten at redhat.com Wed Sep 24 19:29:34 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 24 Sep 2014 15:29:34 -0400 Subject: [Freeipa-users] PKI-CA fails to start (broken config after update?) In-Reply-To: <5423199F.6050200@redhat.com> References: <541CB5F3.7060107@gmail.com> <541FE2F0.3050904@redhat.com> <1411396983.11730.35.camel@aleeredhat.laptop> <1411398869.11730.38.camel@aleeredhat.laptop> <54207AF9.6020905@gmail.com> <1411437587.11730.66.camel@aleeredhat.laptop> <5423086C.2070906@gmail.com> <5423199F.6050200@redhat.com> Message-ID: <54231B9E.2080500@redhat.com> Dmitri Pal wrote: > On 09/24/2014 02:07 PM, swartz wrote: >> On 9/24/2014 9:05 AM, Ade Lee wrote: >>> Forwarding to a couple of colleagues of mine who will be taking point on >>> this. >>> >>> From what I can see, the CS.cfg is truncated. Fortunately, I >>> believe it >>> is reparable. >>> >>> Ade >> >> I've been in contact with Endi and Ade. It was a truncated config file >> as per msg above. >> Endi had emailed me a restored config. >> >> I can happily say that my IPA instance is back in operation. >> >> Thank you all. >> >> For anyone else reading this: >> For me this config truncation happened after a 'yum update'. >> Perhaps shutting down the IPA stack before doing package updates might >> be more advisable. >> >> > Is there any chance to detect which package caused this truncation? > It was almost certainly related to IPA, if not ipa-upgradeconfig directly. For any number of reasons it may write directly to CS.cfg without stopping the service first. It may also call the dogtag-provided pki-setup-proxy which also doesn't stop the service before touching CS.cfg. The upgrader will then determine if any changes were made and restart the service. rob From dpal at redhat.com Wed Sep 24 19:34:49 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 24 Sep 2014 15:34:49 -0400 Subject: [Freeipa-users] PKI-CA fails to start (broken config after update?) In-Reply-To: <54231B9E.2080500@redhat.com> References: <541CB5F3.7060107@gmail.com> <541FE2F0.3050904@redhat.com> <1411396983.11730.35.camel@aleeredhat.laptop> <1411398869.11730.38.camel@aleeredhat.laptop> <54207AF9.6020905@gmail.com> <1411437587.11730.66.camel@aleeredhat.laptop> <5423086C.2070906@gmail.com> <5423199F.6050200@redhat.com> <54231B9E.2080500@redhat.com> Message-ID: <54231CD9.9030709@redhat.com> On 09/24/2014 03:29 PM, Rob Crittenden wrote: > Dmitri Pal wrote: >> On 09/24/2014 02:07 PM, swartz wrote: >>> On 9/24/2014 9:05 AM, Ade Lee wrote: >>>> Forwarding to a couple of colleagues of mine who will be taking point on >>>> this. >>>> >>>> From what I can see, the CS.cfg is truncated. Fortunately, I >>>> believe it >>>> is reparable. >>>> >>>> Ade >>> I've been in contact with Endi and Ade. It was a truncated config file >>> as per msg above. >>> Endi had emailed me a restored config. >>> >>> I can happily say that my IPA instance is back in operation. >>> >>> Thank you all. >>> >>> For anyone else reading this: >>> For me this config truncation happened after a 'yum update'. >>> Perhaps shutting down the IPA stack before doing package updates might >>> be more advisable. >>> >>> >> Is there any chance to detect which package caused this truncation? >> > It was almost certainly related to IPA, if not ipa-upgradeconfig > directly. For any number of reasons it may write directly to CS.cfg > without stopping the service first. It may also call the dogtag-provided > pki-setup-proxy which also doesn't stop the service before touching CS.cfg. > > The upgrader will then determine if any changes were made and restart > the service. > > rob So is it a race condition? Something does not sound right. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From rcritten at redhat.com Wed Sep 24 20:24:46 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 24 Sep 2014 16:24:46 -0400 Subject: [Freeipa-users] PKI-CA fails to start (broken config after update?) In-Reply-To: <54231CD9.9030709@redhat.com> References: <541CB5F3.7060107@gmail.com> <541FE2F0.3050904@redhat.com> <1411396983.11730.35.camel@aleeredhat.laptop> <1411398869.11730.38.camel@aleeredhat.laptop> <54207AF9.6020905@gmail.com> <1411437587.11730.66.camel@aleeredhat.laptop> <5423086C.2070906@gmail.com> <5423199F.6050200@redhat.com> <54231B9E.2080500@redhat.com> <54231CD9.9030709@redhat.com> Message-ID: <5423288E.6070701@redhat.com> Dmitri Pal wrote: > On 09/24/2014 03:29 PM, Rob Crittenden wrote: >> Dmitri Pal wrote: >>> On 09/24/2014 02:07 PM, swartz wrote: >>>> On 9/24/2014 9:05 AM, Ade Lee wrote: >>>>> Forwarding to a couple of colleagues of mine who will be taking >>>>> point on >>>>> this. >>>>> >>>>> From what I can see, the CS.cfg is truncated. Fortunately, I >>>>> believe it >>>>> is reparable. >>>>> >>>>> Ade >>>> I've been in contact with Endi and Ade. It was a truncated config file >>>> as per msg above. >>>> Endi had emailed me a restored config. >>>> >>>> I can happily say that my IPA instance is back in operation. >>>> >>>> Thank you all. >>>> >>>> For anyone else reading this: >>>> For me this config truncation happened after a 'yum update'. >>>> Perhaps shutting down the IPA stack before doing package updates might >>>> be more advisable. >>>> >>>> >>> Is there any chance to detect which package caused this truncation? >>> >> It was almost certainly related to IPA, if not ipa-upgradeconfig >> directly. For any number of reasons it may write directly to CS.cfg >> without stopping the service first. It may also call the dogtag-provided >> pki-setup-proxy which also doesn't stop the service before touching >> CS.cfg. >> >> The upgrader will then determine if any changes were made and restart >> the service. >> >> rob > So is it a race condition? Something does not sound right. > What I don't understand is: if dogtag always writes CS.cfg on exit, why does this work the majority of the time? But anyway, it sounds like we need to shut down dogtag every time we touch CS.cfg which isn't a big deal but it will change the way we do some things. rob From alee at redhat.com Wed Sep 24 20:33:35 2014 From: alee at redhat.com (Ade Lee) Date: Wed, 24 Sep 2014 16:33:35 -0400 Subject: [Freeipa-users] PKI-CA fails to start (broken config after update?) In-Reply-To: <5423288E.6070701@redhat.com> References: <541CB5F3.7060107@gmail.com> <541FE2F0.3050904@redhat.com> <1411396983.11730.35.camel@aleeredhat.laptop> <1411398869.11730.38.camel@aleeredhat.laptop> <54207AF9.6020905@gmail.com> <1411437587.11730.66.camel@aleeredhat.laptop> <5423086C.2070906@gmail.com> <5423199F.6050200@redhat.com> <54231B9E.2080500@redhat.com> <54231CD9.9030709@redhat.com> <5423288E.6070701@redhat.com> Message-ID: <1411590815.29684.34.camel@aleeredhat.laptop> On Wed, 2014-09-24 at 16:24 -0400, Rob Crittenden wrote: > Dmitri Pal wrote: > > On 09/24/2014 03:29 PM, Rob Crittenden wrote: > >> Dmitri Pal wrote: > >>> On 09/24/2014 02:07 PM, swartz wrote: > >>>> On 9/24/2014 9:05 AM, Ade Lee wrote: > >>>>> Forwarding to a couple of colleagues of mine who will be taking > >>>>> point on > >>>>> this. > >>>>> > >>>>> From what I can see, the CS.cfg is truncated. Fortunately, I > >>>>> believe it > >>>>> is reparable. > >>>>> > >>>>> Ade > >>>> I've been in contact with Endi and Ade. It was a truncated config file > >>>> as per msg above. > >>>> Endi had emailed me a restored config. > >>>> > >>>> I can happily say that my IPA instance is back in operation. > >>>> > >>>> Thank you all. > >>>> > >>>> For anyone else reading this: > >>>> For me this config truncation happened after a 'yum update'. > >>>> Perhaps shutting down the IPA stack before doing package updates might > >>>> be more advisable. > >>>> > >>>> > >>> Is there any chance to detect which package caused this truncation? > >>> > >> It was almost certainly related to IPA, if not ipa-upgradeconfig > >> directly. For any number of reasons it may write directly to CS.cfg > >> without stopping the service first. It may also call the dogtag-provided > >> pki-setup-proxy which also doesn't stop the service before touching > >> CS.cfg. > >> > >> The upgrader will then determine if any changes were made and restart > >> the service. > >> > >> rob > > So is it a race condition? Something does not sound right. > > > > What I don't understand is: if dogtag always writes CS.cfg on exit, why > does this work the majority of the time? Dogtag does not write CS.cfg on exit (like 389). Rather, if there are changes to CS.cfg, they will be committed and the file will be changed and the in-memory version of CS.cfg will be written at that time. I think what we're seeing is two different things modifying the CS,cfg at the same time (or at least within the time frame of whatever file buffering is going on). In other cases where I've seen this, I see CS.cfg end up the size of n * file buffer. Shutting down CA before changing CS.cfg is a way of preventing access by more than one source at the same time. > > But anyway, it sounds like we need to shut down dogtag every time we > touch CS.cfg which isn't a big deal but it will change the way we do > some things. > > rob > From alee at redhat.com Wed Sep 24 20:35:50 2014 From: alee at redhat.com (Ade Lee) Date: Wed, 24 Sep 2014 16:35:50 -0400 Subject: [Freeipa-users] PKI-CA fails to start (broken config after update?) In-Reply-To: <1411590815.29684.34.camel@aleeredhat.laptop> References: <541CB5F3.7060107@gmail.com> <541FE2F0.3050904@redhat.com> <1411396983.11730.35.camel@aleeredhat.laptop> <1411398869.11730.38.camel@aleeredhat.laptop> <54207AF9.6020905@gmail.com> <1411437587.11730.66.camel@aleeredhat.laptop> <5423086C.2070906@gmail.com> <5423199F.6050200@redhat.com> <54231B9E.2080500@redhat.com> <54231CD9.9030709@redhat.com> <5423288E.6070701@redhat.com> <1411590815.29684.34.camel@aleeredhat.laptop> Message-ID: <1411590950.29684.36.camel@aleeredhat.laptop> On Wed, 2014-09-24 at 16:33 -0400, Ade Lee wrote: > On Wed, 2014-09-24 at 16:24 -0400, Rob Crittenden wrote: > > Dmitri Pal wrote: > > > On 09/24/2014 03:29 PM, Rob Crittenden wrote: > > >> Dmitri Pal wrote: > > >>> On 09/24/2014 02:07 PM, swartz wrote: > > >>>> On 9/24/2014 9:05 AM, Ade Lee wrote: > > >>>>> Forwarding to a couple of colleagues of mine who will be taking > > >>>>> point on > > >>>>> this. > > >>>>> > > >>>>> From what I can see, the CS.cfg is truncated. Fortunately, I > > >>>>> believe it > > >>>>> is reparable. > > >>>>> > > >>>>> Ade > > >>>> I've been in contact with Endi and Ade. It was a truncated config file > > >>>> as per msg above. > > >>>> Endi had emailed me a restored config. > > >>>> > > >>>> I can happily say that my IPA instance is back in operation. > > >>>> > > >>>> Thank you all. > > >>>> > > >>>> For anyone else reading this: > > >>>> For me this config truncation happened after a 'yum update'. > > >>>> Perhaps shutting down the IPA stack before doing package updates might > > >>>> be more advisable. > > >>>> > > >>>> > > >>> Is there any chance to detect which package caused this truncation? > > >>> > > >> It was almost certainly related to IPA, if not ipa-upgradeconfig > > >> directly. For any number of reasons it may write directly to CS.cfg > > >> without stopping the service first. It may also call the dogtag-provided > > >> pki-setup-proxy which also doesn't stop the service before touching > > >> CS.cfg. > > >> > > >> The upgrader will then determine if any changes were made and restart > > >> the service. > > >> > > >> rob > > > So is it a race condition? Something does not sound right. > > > > > > > What I don't understand is: if dogtag always writes CS.cfg on exit, why > > does this work the majority of the time? > > Dogtag does not write CS.cfg on exit (like 389). Rather, if there are > changes to CS.cfg, they will be committed and the file will be changed > and the in-memory version of CS.cfg will be written at that time. > > I think what we're seeing is two different things modifying the CS,cfg > at the same time (or at least within the time frame of whatever file > buffering is going on). In other cases where I've seen this, I see > CS.cfg end up the size of n * file buffer. > > Shutting down CA before changing CS.cfg is a way of preventing access by > more than one source at the same time. > In the long term of course, we need to provide an interface to dogtag to allow these types of changes by the dogtag server. > > > > But anyway, it sounds like we need to shut down dogtag every time we > > touch CS.cfg which isn't a big deal but it will change the way we do > > some things. > > > > rob > > > > From alexharv074 at gmail.com Thu Sep 25 02:11:06 2014 From: alexharv074 at gmail.com (Alex Harvey) Date: Thu, 25 Sep 2014 12:11:06 +1000 Subject: [Freeipa-users] ipa host-del not authorised Message-ID: Hi all I'm new to IPA and struggling a bit to automate some tasks. I am unable to delete hosts from the command line although have no problem doing this using the GUI, e.g. [root at myipaserver ~]# ipa host-del myhost.example.com ipa: ERROR: Insufficient access: not allowed to perform this command I guess I need to somehow pass the admin user's username and password? However the man page doesn't seem to provide any option for doing this. Thanks Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From netvent at gmail.com Thu Sep 25 02:16:16 2014 From: netvent at gmail.com (Net Vent) Date: Wed, 24 Sep 2014 20:16:16 -0600 Subject: [Freeipa-users] ipa host-del not authorised In-Reply-To: References: Message-ID: Did you try executing this first: kinit admin On Sep 24, 2014 8:13 PM, "Alex Harvey" wrote: > Hi all > > I'm new to IPA and struggling a bit to automate some tasks. > > I am unable to delete hosts from the command line although have no problem > doing this using the GUI, e.g. > > [root at myipaserver ~]# ipa host-del myhost.example.com > > ipa: ERROR: Insufficient access: not allowed to perform this command > > I guess I need to somehow pass the admin user's username and password? > However the man page doesn't seem to provide any option for doing this. > > Thanks > Alex > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Thu Sep 25 07:44:33 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 25 Sep 2014 09:44:33 +0200 Subject: [Freeipa-users] AD Trust - Cannot resolve servers for KDC after reboot In-Reply-To: References: <20140916072831.GY2947@localhost.localdomain> <20140919204009.GG2541@redhat.com> <541FC1BF.5070603@redhat.com> Message-ID: <5423C7E1.6060907@redhat.com> On 24.9.2014 18:00, Genadi Postrilko wrote: > 2014-09-22 9:29 GMT+03:00 Petr Spacek : > >> 'IPA forwarders' are exactly the same as normal 'BIND forward zone' so >> they involve normal DNS cache. >> > Which type of forwarder do you have configured? Is your 'forwarding policy' >> set to 'first' (default) or 'only'? >> >> I have default forwarding policy: > > [root at ipaserver1 ~]# ipa dnsconfig-show > Global forwarders: 192.168.227.60 Okay, your configuration is using default forwarding policy 'first'. You can set it to 'only' using command $ ipa dnsconfig-mod --forward-policy=only I guess that it will fix the problem. >> Forwarding policy 'first' (combined with cache) could be the cause of your >> problem. 'First' policy instructs BIND to contact the configured server and >> if it fails (because of timeout) BIND will re-try the same query using >> normal recursion. >> >> Depending on your network configuration, the normal DNS recursion can >> return different results than forwarding(^1). In this case BIND can cache >> e.g. NXDOMAIN answer from some other server and this answer will stay in >> cache for TTL value in the given answer. >> >> As a result, IPA could get cached NXDOMAIN instead of correct SRV records >> for AD until the TTL in cache expires. >> >> This is of course a wild guess. Detailed logs from named (log level 5 or >> higher+querylog) could tell us what exactly happened. >> >> > This the named log after i increased the debug level to 5 and enabled > querylog: > > https://gist.github.com/anonymous/89308cbca3b07252674c Unfortunately the log doesn't contain any information. I guess that you did not reproduce the problem after changing the debug level ... -- Petr^2 Spacek From mkosek at redhat.com Thu Sep 25 08:41:10 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 25 Sep 2014 10:41:10 +0200 Subject: [Freeipa-users] ipa host-del not authorised In-Reply-To: References: Message-ID: <5423D526.3040900@redhat.com> On 09/25/2014 04:11 AM, Alex Harvey wrote: > Hi all > > I'm new to IPA and struggling a bit to automate some tasks. > > I am unable to delete hosts from the command line although have no problem > doing this using the GUI, e.g. > > [root at myipaserver ~]# ipa host-del myhost.example.com > > ipa: ERROR: Insufficient access: not allowed to perform this command > > I guess I need to somehow pass the admin user's username and password? > However the man page doesn't seem to provide any option for doing this. > > Thanks > Alex Hello Alex, I assume you created a non-admin user with some permissions allow deleting a host. This error message is thrown when a virtual operation check fails. This is raised for example when a user is trying to do unathorized operation with certificates, like if user having host deletion permission does not also have permission to revoke certificates for deleted users. Does the privileged user has "Revoke Certificate" permission assigned through some privilege/role? The mismatch of behavior between CLI and UI is strange. They call the same code, maybe you run it with different users. Also, what is your FreeIPA version? Martin From genadipost at gmail.com Thu Sep 25 10:24:55 2014 From: genadipost at gmail.com (Genadi Postrilko) Date: Thu, 25 Sep 2014 13:24:55 +0300 Subject: [Freeipa-users] AD Trust - Cannot resolve servers for KDC after reboot [SOLVED] Message-ID: The NetworkManager service was overriding the /etc/resolv.conf, so kinit couldn't resolve with the right DNS server. After stopping the NetworkManager and canceling its start up on boot, i can kinit with no problem. Didn't even had to change to forward-policy=only. Thank you for the help, and sorry i haven't noticed it sooner. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sjuhasz at chemaxon.com Thu Sep 25 11:08:07 2014 From: sjuhasz at chemaxon.com (Sandor Juhasz) Date: Thu, 25 Sep 2014 13:08:07 +0200 (CEST) Subject: [Freeipa-users] Virtual DIT view howto In-Reply-To: <1082300231.1105105.1411643144997.JavaMail.zimbra@chemaxon.com> Message-ID: <750226301.1105213.1411643287844.JavaMail.zimbra@chemaxon.com> Hello, i need a bit of help on how to create virtual dit structure on an existing ipa. I need it to create separate structure to authenticate users for services which don't support ldap search filters. I did not find anything in the manual or any howto to start with. S?ndor Juh?sz System Administrator ChemAxon Ltd . Building Hx, GraphiSoft Park, Z?hony utca 7, Budapest, Hungary, H-1031 Cell: +36704258964 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Thu Sep 25 11:15:49 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 25 Sep 2014 13:15:49 +0200 Subject: [Freeipa-users] Virtual DIT view howto In-Reply-To: <750226301.1105213.1411643287844.JavaMail.zimbra@chemaxon.com> References: <750226301.1105213.1411643287844.JavaMail.zimbra@chemaxon.com> Message-ID: <5423F965.8010108@redhat.com> On 09/25/2014 01:08 PM, Sandor Juhasz wrote: > Hello, > > i need a bit of help on how to create virtual dit structure on an existing ipa. > I need it to create separate structure to authenticate users for services which > don't support ldap search filters. Ah, I think you want to do what FreeIPA already does in cn=compat,dc=example,dc=com, i.e. usage of Schema Compatibility plugin (slapi-nis package). > I did not find anything in the manual or any howto to start with. I would start here: https://fedorahosted.org/slapi-nis/ https://git.fedorahosted.org/cgit/slapi-nis.git/plain/doc/sch-getting-started.txt https://git.fedorahosted.org/cgit/slapi-nis.git/plain/doc/examples/sch-plugin-example.ldif.in HTH, Martin From abokovoy at redhat.com Thu Sep 25 12:58:55 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 25 Sep 2014 15:58:55 +0300 Subject: [Freeipa-users] AD Trust - Cannot resolve servers for KDC after reboot [SOLVED] In-Reply-To: References: Message-ID: <20140925125855.GJ11503@redhat.com> On Thu, 25 Sep 2014, Genadi Postrilko wrote: >The NetworkManager service was overriding the /etc/resolv.conf, so kinit >couldn't resolve with the right DNS server. > >After stopping the NetworkManager and canceling its start up on boot, i can >kinit with no problem. >Didn't even had to change to forward-policy=only. > >Thank you for the help, and sorry i haven't noticed it sooner. I'd recommend you to switch NetworkManager into using dnsmasq backend for resolver. Then you can define additional parameters and even redefine where to look at for specific zones. I'm using this to get home networks accessible properly even when there are multiple VPN sessions opened and number of servers in resolv.conf would otherwise be out of proportion. #?cat /etc/NetworkManager/NetworkManager.conf [main] plugins=ifcfg-rh dns=dnsmasq #?cat /etc/NetworkManager/dnsmasq.d/interfaces interface=lo except-interface=virbr0,vnet0,vnet1,vnet2,tun0,tun1,tun2 bind-interfaces # cat /etc/NetworkManager/dnsmasq.d/fixed-servers server=/ipa.example.com/1.2.3.4 server=/ad.example.com/3.4.2.1 -- / Alexander Bokovoy From abokovoy at redhat.com Thu Sep 25 13:24:50 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 25 Sep 2014 16:24:50 +0300 Subject: [Freeipa-users] Virtual DIT view howto In-Reply-To: <750226301.1105213.1411643287844.JavaMail.zimbra@chemaxon.com> References: <1082300231.1105105.1411643144997.JavaMail.zimbra@chemaxon.com> <750226301.1105213.1411643287844.JavaMail.zimbra@chemaxon.com> Message-ID: <20140925132450.GK11503@redhat.com> On Thu, 25 Sep 2014, Sandor Juhasz wrote: >Hello, > >i need a bit of help on how to create virtual dit structure on an existing ipa. >I need it to create separate structure to authenticate users for services which >don't support ldap search filters. >I did not find anything in the manual or any howto to start with. Look into slapi-nis documentation. You can use examples of compat tree as configured by IPA already. Note though that slapi-nis has support for authentication in RHEL 7 and Fedora 20 only. Earlier versions don't have proper support for LDAP BIND over compat tree. -- / Alexander Bokovoy From nalin at redhat.com Thu Sep 25 15:27:08 2014 From: nalin at redhat.com (Nalin Dahyabhai) Date: Thu, 25 Sep 2014 11:27:08 -0400 Subject: [Freeipa-users] 3.3.3 - Unable to install remote client In-Reply-To: <1411585354.2137.15.camel@localhost.localdomain> References: <1411585354.2137.15.camel@localhost.localdomain> Message-ID: <20140925152708.GD5015@redhat.com> On Wed, Sep 24, 2014 at 01:02:34PM -0600, ToBeReplaced wrote: > In details below, the domain name, server host name, and ip address has > been changed. > > The server is sitting behind a router with ip 12.34.56.78. The server > was configured with `--enable-dns` and `192.168.1.100 ipa.example.com > ipa` in /etc/hosts. > > firewalld has been set to open up ports for ldap, ldaps, kerberos, > kpasswd, dns, ntp, http, https on both the client and server. Port 7389 > is also open on the server. > > The router has been configured to forward all of the above ports through > 12.34.56.78 to 192.168.1.100. > > The client is sitting on a different network (say, behind a router with > ip 98.76.54.32). > > Its /etc/hosts includes `12.34.56.78 ipa.example.com ipa`. > Its /etc/resolv.conf includes `nameserver 12.34.56.78` > > ipa-client-install fails with: > > Discovery was successful! > Hostname: laptop-1.example.com > Realm: EXAMPLE.COM > DNS Domain: example.com > IPA Server: ipa.example.com > BaseDN: dc=example,dc=com > Synchronizing time with KDC... > Successfully retrieved CA cert > Subject: CN=Certificate Authority,O=EXAMPLE.COM > Issuer: CN=Certificate Authority,O=EXAMPLE.COM > Valid From: Wed Sep 24 17:44:28 2014 UTC > Valid Until: Sun Sep 24 17:44:28 2034 UTC > > Enrolled in IPA realm EXAMPLE.COM > Created /etc/ipa/default.conf > New SSSD config will be created > Configured /etc/sssd/sssd.conf > Configured /etc/krb5.conf for IPA realm EXAMPLE.COM > trying https://ipa.example.com/ipa/xml > Forwarding 'ping' to server 'https://ipa.example.com/ipa/xml' > Cannot connect to the server due to Kerberos error: Kerberos > error: ('Unspecified GSS failure. Minor code may provide more > information', 851968)/("Cannot contact any KDC for realm > 'EXAMPLE.COM'", -1765328228). Trying with delegate=True > trying https://ipa.example.com/ipa/xml > Forwarding 'ping' to server 'https://ipa.example.com/ipa/xml' > Second connect with delegate=True also failed: Kerberos error: > ('Unspecified GSS failure. Minor code may provide more > information', 851968)/("Cannot contact any KDC for realm > 'EXAMPLE.COM'", -1765328228) > Cannot connect to the IPA server XML-RPC interface: Kerberos > error: ('Unspecified GSS failure. Minor code may provide more > information', 851968)/("Cannot contact any KDC for realm > 'EXAMPLE.COM'", -1765328228) > Installation failed. Rolling back changes. > Unenrolling client from IPA server > Unenrolling host failed: Error obtaining initial credentials: > Cannot contact any KDC for requested realm. > Removing Kerberos service principals from /etc/krb5.keytab > Disabling client Kerberos and LDAP configurations > Redundant SSSD configuration file /etc/sssd/sssd.conf was moved > to /etc/sssd/sssd.conf.deleted > Restoring client configuration files > nscd daemon is not installed, skip configuration > nslcd daemon is not installed, skip configuration > Client uninstall complete. > > `cat /var/log/ipaclient-install.log | grep ERROR -C 25 -m 1` > 2014-09-24T18:11:49Z INFO Configured /etc/krb5.conf for IPA > realm EXAMPLE.COM > 2014-09-24T18:11:49Z DEBUG Starting external process > 2014-09-24T18:11:49Z DEBUG args=keyctl search @s user > ipa_session_cookie:host/laptop-1.example.com at EXAMPLE.COM > 2014-09-24T18:11:49Z DEBUG Process finished, return code=1 > 2014-09-24T18:11:49Z DEBUG stdout= > 2014-09-24T18:11:49Z DEBUG stderr=keyctl_search: Required key > not available > > 2014-09-24T18:11:49Z DEBUG Starting external process > 2014-09-24T18:11:49Z DEBUG args=keyctl search @s user > ipa_session_cookie:host/laptop-1.example.com at EXAMPLE.COM > 2014-09-24T18:11:49Z DEBUG Process finished, return code=1 > 2014-09-24T18:11:49Z DEBUG stdout= > 2014-09-24T18:11:49Z DEBUG stderr=keyctl_search: Required key > not available > > 2014-09-24T18:11:49Z DEBUG failed to find session_cookie in > persistent storage for principal > 'host/laptop-1.example.com at EXAMPLE.COM' > 2014-09-24T18:11:49Z INFO trying https://ipa.example.com/ipa/xml > 2014-09-24T18:11:49Z DEBUG Created connection context.xmlclient > 2014-09-24T18:11:49Z DEBUG Try RPC connection > 2014-09-24T18:11:49Z INFO Forwarding 'ping' to server > 'https://ipa.example.com/ipa/xml' > 2014-09-24T18:12:07Z DEBUG Destroyed connection > context.xmlclient > 2014-09-24T18:12:07Z INFO Cannot connect to the server due to > Kerberos error: Kerberos error: ('Unspecified GSS failure. > Minor code may provide more information', 851968)/("Cannot > contact any KDC for realm 'EXAMPLE.COM'", -1765328228). Trying > with delegate=True > 2014-09-24T18:12:07Z INFO trying https://ipa.example.com/ipa/xml > 2014-09-24T18:12:07Z DEBUG Created connection context.xmlclient > 2014-09-24T18:12:07Z DEBUG Try RPC connection > 2014-09-24T18:12:07Z INFO Forwarding 'ping' to server > 'https://ipa.example.com/ipa/xml' > 2014-09-24T18:12:25Z WARNING Second connect with delegate=True > also failed: Kerberos error: ('Unspecified GSS failure. Minor > code may provide more information', 851968)/("Cannot contact any > KDC for realm 'EXAMPLE.COM'", -1765328228) > 2014-09-24T18:12:25Z ERROR Cannot connect to the IPA server > XML-RPC interface: Kerberos error: ('Unspecified GSS failure. > Minor code may provide more information', 851968)/("Cannot > contact any KDC for realm 'EXAMPLE.COM'", -1765328228) > > One possibly worthwhile note is that running tcpdump shows that the > client (local IP 192.168.0.102) is trying to connect to 192.168.1.100, > the local IP of the server, which is on a different network and thus > inaccessible. > > 14:11:49.611009 IP 192.168.0.102.57552 > > 192.168.1.100.kerberos: > 14:11:50.645238 IP 192.168.0.102.37952 > 192.168.1.100.kerberos: > Flags [S], seq 1224109057, win 14600, op > tions [mss 1460,sackOK,TS val 5701517 ecr 0,nop,wscale 7], > length 0 > 14:11:51.648218 IP 192.168.0.102.37952 > 192.168.1.100.kerberos: > Flags [S], seq 1224109057, win 14600, op > tions [mss 1460,sackOK,TS val 5702520 ecr 0,nop,wscale 7], > length 0 > > etc. etc. Any chance the /etc/krb5.conf that the install script created is still around? Based on your tcpdump data, my first guess would be that the Kerberos client bits ended up looking up the KDC (the Kerberos service) location using DNS, which would have pointed it at the non-tunneled address. If it's around, running env KRB5_CONFIG=/path/to/krb5.conf KRB5_TRACE=/dev/stderr kinit admin should provide information about how it's locating servers, allowing us to confirm if that's what's happening here. HTH, Nalin From traiano at gmail.com Thu Sep 25 15:35:54 2014 From: traiano at gmail.com (Traiano Welcome) Date: Thu, 25 Sep 2014 18:35:54 +0300 Subject: [Freeipa-users] FreeIPA 3.3 and Solaris 10 Client Integration: In-Reply-To: <5422A889.3040907@redhat.com> References: <5422A889.3040907@redhat.com> Message-ID: Hi Martin On Wed, Sep 24, 2014 at 2:18 PM, Martin Kosek wrote: > On 09/24/2014 01:06 PM, Traiano Welcome wrote: > > Hi List > > > > I'm currently running IPA 3.3 on Centos 7, and successfully > authenticating > > Linux clients (Centos 6.5). > > > > I'd like to setup Solaris 10 as an IPA client, but this seems > > problematic. I am following this guide: > > > > > http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html#Configuring_an_IPA_Client_on_Solaris_10 > > > > I have the following setup: > > > > Solaris client: > > > > - Solaris 10u11 (SunOS 5.10 Generic_147148-26 i86pc i386 i86pc) > > > > IdM Server: > > > > - Linux kwtpocipa001.orion.local 3.10.0-123.el7.x86_64 #1 SMP Mon Jun 30 > > 12:09:22 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux > > > > > > > > Going through the steps in the guide: at step 3 ("Create the > cn=proxyagent > > account"), ldapadd fails with the following error: > > > > > > > > "ldapadd: invalid format (line 6) entry: > > "cn=proxyagent,ou=profile,dc=orion,dc=local"" > > > > --- > > > > [root at kwtpocipa001 ~]# ldapadd -h 172.16.107.102 -p 389 -D "cn=directory > > manager" -w Cr4ckM0nk3y > > dn: cn=proxyagent,ou=profile,dc=orion,dc=local > > objectClass: top > > objectClass: person > > sn: proxyagent > > cn: proxyagent > > userPassword:: > > e1NTSEF9Mm53KytGeU81Z1dka1FLNUZlaDdXOHJkK093TEppY2NjRmt6Wnc9PQ= > > > > ldapadd: invalid format (line 6) entry: > > "cn=proxyagent,ou=profile,dc=orion,dc=local" > > --- > > > > I've made the assumption that the extra ":" is a typo in the > documentation > > and removed it, so the command runs successfully as follows: > > > > > > --- > > [root at kwtpocipa001 ~]# ldapadd -h 172.16.107.102 -p 389 -D "cn=directory > > manager" -w Cr4ckM0nk3y > > > > dn: cn=proxyagent,ou=profile,dc=orion,dc=local > > objectClass: top > > objectClass: person > > sn: proxyagent > > cn: proxyagent > > userPassword: > > e1NTSEF9Mm53KytGeU81Z1dka1FLNUZlaDdXOHJkK093TEppY2NjRmt6Wnc9PQ= > > adding new entry "cn=proxyagent,ou=profile,dc=orion,dc=local" > > --- > > > > > > At step 9 (Configure NFS ), I get an error, seems to indicate the > > "des-cbc-crc" encryption type is unsupported: > > > > --- > > [root at kwtpocipa001 ~]# ipa-getkeytab -s kwtpocipa001.orion.local -p > > nfs/kwtpocipasol10u11.orion.local -k /tmp/kwtpocipasol10u11.keytab -e > > des-cbc-crc > > Operation failed! All enctypes provided are unsupported > > [root at kwtpocipa001 ~]# > > --- > > > > (Question: How would I add support for des-cbc-crc encryption in > > freeipa?). I've now worked around this by not specifying any encryption > > type: > > > > --- > > [root at kwtpocipa001 ~]# ipa-getkeytab -s kwtpocipa001.orion.local -p > > nfs/kwtpocipasol10u11.orion.local -k /tmp/kwtpocipasol10u11.keytab > > Keytab successfully retrieved and stored in: > /tmp/kwtpocipasol10u11.keytab > > [root at kwtpocipa001 ~]# > > --- > > > > Testing that I can see nfs mounts on the centos IPA server from the > solaris > > machine: > > > > --- > > bash-3.2# showmount -e kwtpocipa001.orion.local > > export list for kwtpocipa001.orion.local: > > /data/centos-repo 172.16.0.0/24 > > bash-3.2# > > ---- > > > > > > Checking we can kinit: > > > > --- > > bash-3.2# > > bash-3.2# kinit admin > > Password for admin at ORION.LOCAL: > > bash-3.2# > > bash-3.2# > > bash-3.2# klist > > Ticket cache: FILE:/tmp/krb5cc_0 > > Default principal: admin at ORION.LOCAL > > Valid starting Expires Service principal > > 09/24/14 11:20:36 09/24/14 12:20:36 krbtgt/ORION.LOCAL at ORION.LOCAL > > renew until 10/01/14 11:20:36 > > bash-3.2# > > bash-3.2# > > bash-3.2# > > bash-3.2# uname -a > > SunOS kwtpocipasol10u11 5.10 Generic_147148-26 i86pc i386 i86pc > > bash-3.2# > > --- > > > > Testing I can mount the remote FS (without Kerberos auth). This is > > successful (when not using kerberos5 authentication): > > > > --- > > bash-3.2# mount -F nfs 172.16.107.102:/data/centos-repo /remote/ > > bash-3.2# mount |grep remote > > /remote on 172.16.107.102:/data/centos-repo > > remote/read/write/setuid/devices/rstchown/xattr/dev=4f0000a on Wed Sep 24 > > 13:45:32 2014 > > bash-3.2# > > --- > > > > Testing with KRB5: > > > > --- > > bash-3.2# mount -F nfs -o sec=krb5 172.16.107.102:/data/centos-repo > /remote/ > > nfs mount: mount: /remote: Permission denied > > bash-3.2# > > --- > > > > Looking at the krbkdc logs on the IPA master server, I get the following > > error: > > > > --- > > Sep 24 13:48:17 kwtpocipa001.orion.local krb5kdc[2371](info): AS_REQ (6 > > etypes {18 17 16 23 3 1}) 172.16.107.107: NEEDED_PREAUTH: > > host/kwtpocipasol10u11.orion.local at ORION.LOCAL for > > krbtgt/ORION.LOCAL at ORION.LOCAL, Additional pre-authentication required > > Sep 24 13:48:17 kwtpocipa001.orion.local krb5kdc[2373](info): DISPATCH: > > repeated (retransmitted?) request from 172.16.107.107, resending previous > > response > > Sep 24 13:48:17 kwtpocipa001.orion.local krb5kdc[2374](info): DISPATCH: > > repeated (retransmitted?) request from 172.16.107.107, resending previous > > response > > . > > . > > . > > Sep 24 13:48:18 kwtpocipa001.orion.local krb5kdc[2373](info): AS_REQ (6 > > etypes {18 17 16 23 3 1}) 172.16.107.107: CLIENT_NOT_FOUND: > > root/kwtpocipasol10u11.orion.local at ORION.LOCAL for > > krbtgt/ORION.LOCAL at ORION.LOCAL, Client not found in Kerberos database > > > > --- > > > > So it seems the host is not correctly registered. > > > > NOTE: Via the interface ,I can see the solaris client is > > not properly enrolled (" Kerberos Key Not Present"), however the > > documentation doesn't seem to indicate clearly how this should be done > for > > a Solaris client. I have regenerated the certificate though, so it shows > > "valid certificate present". > > > > My question is: Is the process described in this guide still > > correct/functional for integrating Solaris 10 clients? > > If so, is there some way I could debug further to pinpoint why the > solaris > > client is not being registered in the Kerberos DB? > > > > Many thanks in advance! > > Traiano > > Hello Traiano, > > This part of the documentation is wrong, as reported by ldapadd, > userpassword > is not correct. > > If you specify the entry with clear text password, it would work. I.e.: > > dn: cn=proxyagent,ou=profile,dc=orion,dc=local > objectClass: top > objectClass: person > sn: proxyagent > cn: proxyagent > userPassword: agentpassword > > Note that Solaris related documentation is (unfortunately) known to be off: > https://fedorahosted.org/freeipa/ticket/3731 > > Also please note that the guide you are referring to is also pretty old > (from > Fedora 18 times) and not updated. There is a related thread: > > https://www.redhat.com/archives/freeipa-users/2014-September/msg00357.html > Indeed. There are some minor errata as well like the use of the "-t" flag with Solaris' version of the mount command: bash-3.2# mount -t nfs -o sec=krb5 172.16.107.102:/data/centos-repo /remote/ mount: illegal option -- t "-F" works. I've adjusted the steps I've used to include the changes you mentioned in https://fedorahosted.org/freeipa/ticket/3731, attached is a step by step listing of the process with my output up to step 9, where mounting NFS fails. Hopefully by a process of iteration I can document the updated process for configuring Solaris 10 clients. Here is what I'm seeing at step 9 (referencing the old Fedora 18 docs with adjusted steps)L h) Mount the NFS share. [FAILS] --- bash-3.2# mount -F nfs -o sec=krb5 172.16.107.102:/data/centos-repo /remote/ nfs mount: mount: /remote: Permission denied bash-3.2# --- /var/log/krbkdc.Log entries: --- krb5kdc: Cannot determine realm for numeric host address - unable to find realm of host Sep 25 18:18:20 kwtpocipa001.orion.local krb5kdc[2373](info): TGS_REQ (6 etypes {18 17 16 23 3 1}) 172.16.107.107: LOOKING_UP_SERVER: authtime 0, admin at ORION.LOCAL for , Server not found in Kerberos database Sep 25 18:18:20 kwtpocipa001.orion.local krb5kdc[2373](info): TGS_REQ (6 etypes {18 17 16 23 3 1}) 172.16.107.107: LOOKING_UP_SERVER: authtime 0, admin at ORION.LOCAL for , Server not found in Kerberos database krb5kdc: Cannot determine realm for numeric host address - unable to find realm of host Sep 25 18:18:20 kwtpocipa001.orion.local krb5kdc[2373](info): TGS_REQ (6 etypes {18 17 16 23 3 1}) 172.16.107.107: LOOKING_UP_SERVER: authtime 0, admin at ORION.LOCAL for , Server not found in Kerberos database Sep 25 18:18:20 kwtpocipa001.orion.local krb5kdc[2373](info): TGS_REQ (6 etypes {18 17 16 23 3 1}) 172.16.107.107: LOOKING_UP_SERVER: authtime 0, admin at ORION.LOCAL for , Server not found in Kerberos database krb5kdc: Cannot determine realm for numeric host address - unable to find realm of host Sep 25 18:18:20 kwtpocipa001.orion.local krb5kdc[2373](info): TGS_REQ (6 etypes {18 17 16 23 3 1}) 172.16.107.107: LOOKING_UP_SERVER: authtime 0, admin at ORION.LOCAL for , Server not found in Kerberos database Sep 25 18:18:20 kwtpocipa001.orion.local krb5kdc[2373](info): TGS_REQ (6 etypes {18 17 16 23 3 1}) 172.16.107.107: LOOKING_UP_SERVER: authtime 0, admin at ORION.LOCAL for , Server not found in Kerberos database --- However DNS forward and reverse records DO seem to resolve: --- [root at kwtpocipa001 ~]# host 172.16.107.107 107.107.16.172.in-addr.arpa domain name pointer kwtpocipasol10u11.orion.local. [root at kwtpocipa001 ~]# host kwtpocipasol10u11.orion.local kwtpocipasol10u11.orion.local has address 172.16.107.107 --- And we can kinit and get a ticket: --- bash-3.2# kinit admin at ORION.LOCAL Password for admin at ORION.LOCAL: bash-3.2# bash-3.2# bash-3.2# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: admin at ORION.LOCAL Valid starting Expires Service principal 09/25/14 18:31:49 09/25/14 19:31:49 krbtgt/ORION.LOCAL at ORION.LOCAL renew until 10/02/14 18:31:49 bash-3.2# --- Regards, Traiano > > Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- 1. Initialise: ldapclient -v init -a profileName=default kwtpocipa001.orion.local --- bash-3.2# ldapclient -v init -a profileName=default kwtpocipa001.orion.local Parsing profileName=default Arguments parsed: profileName: default defaultServerList: kwtpocipa001.orion.local Handling init option About to configure machine by downloading a profile Proxy DN: NULL Proxy password: NULL Authentication method: 0 No proxyDN/proxyPassword required Shadow Update is not enabled, no adminDN/adminPassword is required. About to modify this machines configuration by writing the files Stopping network services sendmail not running nscd not running autofs not running Stopping ldap stop: sleep 100000 microseconds stop: network/ldap/client:default... success nisd not running nis(yp) not running Removing existing restore directory file_backup: stat(/etc/nsswitch.conf)=0 file_backup: (/etc/nsswitch.conf -> /var/ldap/restore/nsswitch.conf) file_backup: stat(/etc/defaultdomain)=0 file_backup: (/etc/defaultdomain -> /var/ldap/restore/defaultdomain) file_backup: stat(/var/nis/NIS_COLD_START)=-1 file_backup: No /var/nis/NIS_COLD_START file. file_backup: nis domain is "orion.local" file_backup: stat(/var/yp/binding/orion.local)=-1 file_backup: No /var/yp/binding/orion.local directory. file_backup: stat(/var/ldap/ldap_client_file)=0 file_backup: (/var/ldap/ldap_client_file -> /var/ldap/restore/ldap_client_file) file_backup: (/var/ldap/ldap_client_cred -> /var/ldap/restore/ldap_client_cred) Starting network services start: /usr/bin/domainname orion.local... success start: sleep 100000 microseconds start: network/ldap/client:default... success restart: sleep 100000 microseconds restart: milestone/name-services:default... success System successfully configured --- 2.Create a Solaris profile in the FreeIPA Directory Server Optional: --- ldapmodify -h 172.16.107.102 -p 389 -D "cn=directory manager" -w Cr4ckM0nk3y -f modprofile.ldif LDIF as follows: dn: cn=default,ou=profile,dc=orion,dc=local changetype: modify replace: defaultServerList defaultServerList: kwtpocipa001.orion.local --- 3. Create the cn=proxyagent account in the FreeIPA Directory Server instance. Example output: --- dn: fqdn=kwtpocipasol10u11.orion.local,cn=computers,cn=accounts,dc=orion,dc=lo cal userCertificate:: MIIEGzCCAwOgAwIBAgIBEjANBgkqhkiG9w0BAQsFADA2MRQwEgYDVQQKEwt PUklPTi5MT0NBTDEeMBwGA1UEAxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE0MDkyNDEwNTE 0NloXDTE2MDkyNDEwNTE0NlowPjEUMBIGA1UEChMLT1JJT04uTE9DQUwxJjAkBgNVBAMTHWt3dHB vY2lwYXNvbDEwdTExLm9yaW9uLmxvY2FsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQE AmkQnGWP0ZkqKGWe6ooE1C8A+UzE120PJQTYkCLgE86Ospe4HY0LcwBwBnBF5j2ubS3sbywtkT7/ //LVxo8xcrzGCTBEQ3MDVuSqIl8oFw299jHTkjOrVURJqyJQc3Cl6ygrhMNRRtNNn4Kit1Y6hnae bWidO2TRSnRCy80vcyk+9iAB0Y4mGCHHPOFvYtOaySp3nLGH1szveIufEcwQKl03vttJq2wyqy1U EUrPapXbT6E+0Pu+ZtmVYLl1s5RNeU4PIMQ3Yst0jD8PwSLznlXVwwPpBUWdC3VEXghp9CgFmCDX IpDJHVLYYTxmKOn4VfRoE898Hb3+jsda+lU7rhwIDAQABo4IBKjCCASYwHwYDVR0jBBgwFoAU1bo kQI+yxnZjtPRdV/AGQjUBKbgwPQYIKwYBBQUHAQEEMTAvMC0GCCsGAQUFBzABhiFodHRwOi8vaXB hLWNhLm9yaW9uLmxvY2FsL2NhL29jc3AwDgYDVR0PAQH/BAQDAgTwMB0GA1UdJQQWMBQGCCsGAQU FBwMBBggrBgEFBQcDAjB2BgNVHR8EbzBtMGugM6Axhi9odHRwOi8vaXBhLWNhLm9yaW9uLmxvY2F sL2lwYS9jcmwvTWFzdGVyQ1JMLmJpbqI0pDIwMDEOMAwGA1UEChMFaXBhY2ExHjAcBgNVBAMTFUN lcnRpZmljYXRlIEF1dGhvcml0eTAdBgNVHQ4EFgQUvq4Xd4bruqJo1h06/27WLXbf4oIwDQYJKoZ IhvcNAQELBQADggEBAGvESNiGJ5wYum075bHvLFkAglWsnbDwK0CQDYqM9/LAbSPHZAbZL20fn4z 3Xt4bOqBNJXSIX5tmSFBS73Yx9mK+Fb5GOZ71YffK+xaXyRsnqKtDktqi/KJp5ugOeZOc11rg+rB +/sn0wNbGsm/b0h9xy0prUZKyNWgDMq0OBkOu25m4OrorVVxqDoi6FqGA0KQ2W+8EbBBF404zo0E xG0U4dZ/aCudnO8SZC0VobxjE9ZLqu7pAUaVdiTEcPJEzM4X4v9J5aLvT0QRdwrNiL+yyMQlA9Il AAtRWcHHKhuyGrVDKUjdfx+FNvWxtGt6zzrzG2oTMoXAKkxHvnK0XScc= cn: kwtpocipasol10u11.orion.local objectClass: ipaobject objectClass: nshost objectClass: ipahost objectClass: pkiuser objectClass: ipaservice objectClass: krbprincipalaux objectClass: krbprincipal objectClass: ieee802device objectClass: ipasshhost objectClass: top objectClass: ipaSshGroupOfPubKeys fqdn: kwtpocipasol10u11.orion.local managedBy: fqdn=kwtpocipasol10u11.orion.local,cn=computers,cn=accounts,dc=orion,dc=local krbPrincipalName: host/kwtpocipasol10u11.orion.local at ORION.LOCAL serverHostName: kwtpocipasol10u11 ipaUniqueID: b9911b94-434a-11e4-9966-0050569c5510 --- 4. Add the host to the IPA server and request a keytab for the host: ipa host-add kwtpocipasol10u11.orion.local [root at kwtpocipa001 ~]# ipa-getkeytab -s kwtpocipa001.orion.local -p host/kwtpocipasol10u11.orion.local -k /tmp/kwtpocipasol10u11.orion.local.keytab Keytab successfully retrieved and stored in: /tmp/kwtpocipasol10u11.orion.local.keytab 5. On the FreeIPA server, use the certutil command to create cert8.db and key3.db databases. Example output: --- [root at kwtpocipa001 ~]# certutil -N -d . Enter a password which will be used to encrypt your keys. The password should be at least 8 characters long, and should contain at least one non-alphabetic character. Enter new password: Re-enter password: [root at kwtpocipa001 ~]# --- NOTE: The password is left blank in the dialogue above. SCP the cert files to the solaris client: --- scp cert8.db root at kwtpocipasol10u11.orion.local:/var/ldap/ scp key3.db root at kwtpocipasol10u11.orion.local:/var/ldap/ --- 5. Remove the ldap option from all entries in /etc/nsswitch.conf except for the passwd, group, shadow, netgroup, and sudoers entries. --- bash-3.2# grep "ldap" /etc/nsswitch.conf| grep -v "^#" passwd: files ldap group: files ldap shadow: files ldap sudoers: files ldap netgroup: ldap --- 6. Configure and enable NTP and synchronize the time between the client and the FreeIPA server. Example output: -- [root at kwtpocipa001 ~]# ntpdate 172.16.100.13 25 Sep 15:50:51 ntpdate[13751]: the NTP socket is in use, exiting [root at kwtpocipa001 ~]# [root at kwtpocipa001 ~]# date Thu Sep 25 15:50:56 AST 2014 [root at kwtpocipa001 ~]# . . . bash-3.2# ntpdate 172.16.100.13 25 Sep 15:50:35 ntpdate[989]: step time server 172.16.100.13 offset 0.843696 sec bash-3.2# date Thu Sep 25 15:50:42 AST 2014 --- 7. Configure the Kerberos client. The Kerberos configuration includes specifying the realm and domain details and default ticket attributes bash-3.2# cat /etc/krb5/krb5.conf --- [libdefaults] default_realm = ORION.LOCAL verify_ap_req_nofail = false [realms] ORION.LOCAL = { kdc = kwtpocipa001.orion.local admin_server = kwtpocipa001.orion.local } [domain_realm] orion.local = ORION.LOCAL .orion.local = ORION.LOCAL [logging] default = FILE:/var/krb5/kdc.log kdc = FILE:/var/krb5/kdc.log [appdefaults] kinit = { renewable = true forwardable= true } --- 8. Configure PAM to use Kerberos authentication. For example: bash-3.2# grep -v "^#" /etc/pam.conf --- login auth requisite pam_authtok_get.so.1 login auth required pam_dhkeys.so.3 login auth sufficient pam_krb5.so.1 try_first_pass debug login auth required pam_unix_cred.so.1 login auth required pam_unix_auth.so.1 login auth required pam_dial_auth.so.1 krlogin auth required pam_unix_cred.so.1 krlogin auth required pam_krb5.so.1 debug ktelnet auth required pam_unix_cred.so.1 ktelnet auth required pam_krb5.so.1 debug other auth requisite pam_authtok_get.so.1 other auth required pam_dhkeys.so.1 login auth sufficient pam_krb5.so.1 try_first_pass debug other auth required pam_unix_cred.so.1 other auth sufficient pam_krb5.so.1 debug other auth required pam_unix_auth.so.1 passwd auth required pam_passwd_auth.so.1 cron account required pam_unix_account.so.1 other account requisite pam_roles.so.1 other account required pam_unix_account.so.1 other account required pam_krb5.so.1 debug other session required pam_unix_session.so.1 other password required pam_dhkeys.so.1 other password requisite pam_authtok_get.so.1 other password requisite pam_authtok_check.so.1 force_check other password sufficient pam_krb5.so.1 debug other password required pam_authtok_store.so.1 --- 9. Configure NFS to work with the Kerberos domain a) ipa service-add nfs/kwtpocipasol10u11.orion.local b) Verify that the pkcs11_softtoken_extra.so provider has been installed and enabled for AES256 support: solarishost $ cryptoadm list If pkcs11_softtoken_extra.so is missing, use the "-e" option with ipa-getkeytab to limit the encryption type to aes128, or install and enable the provider. See the Solaris documentation for details. b) ipa-getkeytab -s kwtpocipasol10u11.orion.local -p nfs/kwtpocipasol10u11.orion.local -k /tmp/krb5.keytab -e aes128 (alternatively: ipa-getkeytab -s kwtpocipasol10u11.orion.local -p nfs/kwtpocipasol10u11.orion.local -k /tmp/krb5.keytab -e des-cbc-crc" if this is supported) [lame workaround for when none of the encryption types seem to be supported]: ipa-getkeytab -s `hostname` -p nfs/kwtpocipasol10u11.orion.local -k /tmp/kwtpocipasol10u11.orion.local.keytab Checking what encryption types are supported on the client side: --- bash-3.2# cryptoadm list User-level providers: Provider: /usr/lib/security/$ISA/pkcs11_kernel.so Provider: /usr/lib/security/$ISA/pkcs11_softtoken_extra.so Kernel software providers: des aes256 arcfour2048 blowfish448 sha1 sha2 md5 rsa swrand Kernel hardware providers: bash-3.2# --- c) scp cert8.db and key3.db to the client d) On the FreeIPA client, use the ktutil command to import the contents into the main host keytab -- bash-3.2# ktutil ktutil: read_kt /tmp/kwtpocipasol10u11.orion.local.keytab ktutil: write_kt /etc/krb5/krb5.keytab ktutil: q -- e) Verify that the NFS service Keytab was created: --- Keytab name: FILE:/etc/krb5/krb5.keytab KVNO Timestamp Principal ---- ----------------- --------------------------------------------------------- 1 09/25/14 17:58:55 host/kwtpocipasol10u11.orion.local at ORION.LOCAL (AES-256 CTS mode with 96-bit SHA-1 HMAC) 1 09/25/14 17:58:55 host/kwtpocipasol10u11.orion.local at ORION.LOCAL (AES-128 CTS mode with 96-bit SHA-1 HMAC) 1 09/25/14 17:58:55 host/kwtpocipasol10u11.orion.local at ORION.LOCAL (Triple DES cbc mode with HMAC/sha1) 1 09/25/14 17:58:55 host/kwtpocipasol10u11.orion.local at ORION.LOCAL (ArcFour with HMAC/md5) 1 09/25/14 17:58:55 host/kwtpocipasol10u11.orion.local at ORION.LOCAL (unsupported encryption type 25) 1 09/25/14 17:58:55 host/kwtpocipasol10u11.orion.local at ORION.LOCAL (unsupported encryption type 26) 1 09/25/14 18:16:24 host/kwtpocipasol10u11.orion.local at ORION.LOCAL (AES-256 CTS mode with 96-bit SHA-1 HMAC) 1 09/25/14 18:16:24 host/kwtpocipasol10u11.orion.local at ORION.LOCAL (AES-128 CTS mode with 96-bit SHA-1 HMAC) 1 09/25/14 18:16:24 host/kwtpocipasol10u11.orion.local at ORION.LOCAL (Triple DES cbc mode with HMAC/sha1) 1 09/25/14 18:16:24 host/kwtpocipasol10u11.orion.local at ORION.LOCAL (ArcFour with HMAC/md5) 1 09/25/14 18:16:24 host/kwtpocipasol10u11.orion.local at ORION.LOCAL (unsupported encryption type 25) 1 09/25/14 18:16:24 host/kwtpocipasol10u11.orion.local at ORION.LOCAL (unsupported encryption type 26) 4 09/25/14 18:16:24 nfs/kwtpocipasol10u11.orion.local at ORION.LOCAL (AES-256 CTS mode with 96-bit SHA-1 HMAC) 4 09/25/14 18:16:24 nfs/kwtpocipasol10u11.orion.local at ORION.LOCAL (AES-128 CTS mode with 96-bit SHA-1 HMAC) 4 09/25/14 18:16:24 nfs/kwtpocipasol10u11.orion.local at ORION.LOCAL (Triple DES cbc mode with HMAC/sha1) 4 09/25/14 18:16:24 nfs/kwtpocipasol10u11.orion.local at ORION.LOCAL (ArcFour with HMAC/md5) 4 09/25/14 18:16:24 nfs/kwtpocipasol10u11.orion.local at ORION.LOCAL (unsupported encryption type 25) 4 09/25/14 18:16:24 nfs/kwtpocipasol10u11.orion.local at ORION.LOCAL (unsupported encryption type 26) --- f) Verify that the NFS server is accessible: --- bash-3.2# bash-3.2# showmount -e kwtpocipa001.orion.local export list for kwtpocipa001.orion.local: /data/centos-repo 172.16.0.0/16 bash-3.2# --- g) Make sure that this line is uncommented in the /etc/nfssec.conf file krb5 390003 kerberos_v5 default - # RPCSEC_GSS -- bash-3.2# grep krb5 /etc/nfssec.conf krb5 390003 kerberos_v5 default - # RPCSEC_GSS -- h) Mount the NFS share. [FAILS] --- bash-3.2# mount -F nfs -o sec=krb5 172.16.107.102:/data/centos-repo /remote/ nfs mount: mount: /remote: Permission denied bash-3.2# --- /var/log/krbkdc.Log entries: --- krb5kdc: Cannot determine realm for numeric host address - unable to find realm of host Sep 25 18:18:20 kwtpocipa001.orion.local krb5kdc[2373](info): TGS_REQ (6 etypes {18 17 16 23 3 1}) 172.16.107.107: LOOKING_UP_SERVER: authtime 0, admin at ORION.LOCAL for , Server not found in Kerberos database Sep 25 18:18:20 kwtpocipa001.orion.local krb5kdc[2373](info): TGS_REQ (6 etypes {18 17 16 23 3 1}) 172.16.107.107: LOOKING_UP_SERVER: authtime 0, admin at ORION.LOCAL for , Server not found in Kerberos database krb5kdc: Cannot determine realm for numeric host address - unable to find realm of host Sep 25 18:18:20 kwtpocipa001.orion.local krb5kdc[2373](info): TGS_REQ (6 etypes {18 17 16 23 3 1}) 172.16.107.107: LOOKING_UP_SERVER: authtime 0, admin at ORION.LOCAL for , Server not found in Kerberos database Sep 25 18:18:20 kwtpocipa001.orion.local krb5kdc[2373](info): TGS_REQ (6 etypes {18 17 16 23 3 1}) 172.16.107.107: LOOKING_UP_SERVER: authtime 0, admin at ORION.LOCAL for , Server not found in Kerberos database krb5kdc: Cannot determine realm for numeric host address - unable to find realm of host Sep 25 18:18:20 kwtpocipa001.orion.local krb5kdc[2373](info): TGS_REQ (6 etypes {18 17 16 23 3 1}) 172.16.107.107: LOOKING_UP_SERVER: authtime 0, admin at ORION.LOCAL for , Server not found in Kerberos database Sep 25 18:18:20 kwtpocipa001.orion.local krb5kdc[2373](info): TGS_REQ (6 etypes {18 17 16 23 3 1}) 172.16.107.107: LOOKING_UP_SERVER: authtime 0, admin at ORION.LOCAL for , Server not found in Kerberos database --- However DNS forward and reverse records DO seem to resolve: --- [root at kwtpocipa001 ~]# host 172.16.107.107 107.107.16.172.in-addr.arpa domain name pointer kwtpocipasol10u11.orion.local. [root at kwtpocipa001 ~]# host kwtpocipasol10u11.orion.local kwtpocipasol10u11.orion.local has address 172.16.107.107 [root at kwtpocipa001 ~]# --- From mkosek at redhat.com Fri Sep 26 07:17:36 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 26 Sep 2014 09:17:36 +0200 Subject: [Freeipa-users] FreeIPA 3.3 and Solaris 10 Client Integration: In-Reply-To: References: <5422A889.3040907@redhat.com> Message-ID: <54251310.2030502@redhat.com> On 09/25/2014 05:35 PM, Traiano Welcome wrote: > Hi Martin > > On Wed, Sep 24, 2014 at 2:18 PM, Martin Kosek > wrote: > > On 09/24/2014 01:06 PM, Traiano Welcome wrote: > > Hi List > > > > I'm currently running IPA 3.3 on Centos 7, and successfully authenticating > > Linux clients (Centos 6.5). > > > > I'd like to setup Solaris 10 as an IPA client, but this seems > > problematic. I am following this guide: > > > > > http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html#Configuring_an_IPA_Client_on_Solaris_10 > > > > I have the following setup: > > > > Solaris client: > > > > - Solaris 10u11 (SunOS 5.10 Generic_147148-26 i86pc i386 i86pc) > > > > IdM Server: > > > > - Linux kwtpocipa001.orion.local 3.10.0-123.el7.x86_64 #1 SMP Mon Jun 30 > > 12:09:22 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux > > > > > > > > Going through the steps in the guide: at step 3 ("Create the cn=proxyagent > > account"), ldapadd fails with the following error: > > > > > > > > "ldapadd: invalid format (line 6) entry: > > "cn=proxyagent,ou=profile,dc=orion,dc=local"" > > > > --- > > > > [root at kwtpocipa001 ~]# ldapadd -h 172.16.107.102 -p 389 -D "cn=directory > > manager" -w Cr4ckM0nk3y > > dn: cn=proxyagent,ou=profile,dc=orion,dc=local > > objectClass: top > > objectClass: person > > sn: proxyagent > > cn: proxyagent > > userPassword:: > > e1NTSEF9Mm53KytGeU81Z1dka1FLNUZlaDdXOHJkK093TEppY2NjRmt6Wnc9PQ= > > > > ldapadd: invalid format (line 6) entry: > > "cn=proxyagent,ou=profile,dc=orion,dc=local" > > --- > > > > I've made the assumption that the extra ":" is a typo in the documentation > > and removed it, so the command runs successfully as follows: > > > > > > --- > > [root at kwtpocipa001 ~]# ldapadd -h 172.16.107.102 -p 389 -D "cn=directory > > manager" -w Cr4ckM0nk3y > > > > dn: cn=proxyagent,ou=profile,dc=orion,dc=local > > objectClass: top > > objectClass: person > > sn: proxyagent > > cn: proxyagent > > userPassword: > > e1NTSEF9Mm53KytGeU81Z1dka1FLNUZlaDdXOHJkK093TEppY2NjRmt6Wnc9PQ= > > adding new entry "cn=proxyagent,ou=profile,dc=orion,dc=local" > > --- > > > > > > At step 9 (Configure NFS ), I get an error, seems to indicate the > > "des-cbc-crc" encryption type is unsupported: > > > > --- > > [root at kwtpocipa001 ~]# ipa-getkeytab -s kwtpocipa001.orion.local -p > > nfs/kwtpocipasol10u11.orion.local -k /tmp/kwtpocipasol10u11.keytab -e > > des-cbc-crc > > Operation failed! All enctypes provided are unsupported > > [root at kwtpocipa001 ~]# > > --- > > > > (Question: How would I add support for des-cbc-crc encryption in > > freeipa?). I've now worked around this by not specifying any encryption > > type: > > > > --- > > [root at kwtpocipa001 ~]# ipa-getkeytab -s kwtpocipa001.orion.local -p > > nfs/kwtpocipasol10u11.orion.local -k /tmp/kwtpocipasol10u11.keytab > > Keytab successfully retrieved and stored in: /tmp/kwtpocipasol10u11.keytab > > [root at kwtpocipa001 ~]# > > --- > > > > Testing that I can see nfs mounts on the centos IPA server from the solaris > > machine: > > > > --- > > bash-3.2# showmount -e kwtpocipa001.orion.local > > export list for kwtpocipa001.orion.local: > > /data/centos-repo 172.16.0.0/24 > > bash-3.2# > > ---- > > > > > > Checking we can kinit: > > > > --- > > bash-3.2# > > bash-3.2# kinit admin > > Password for admin at ORION.LOCAL: > > bash-3.2# > > bash-3.2# > > bash-3.2# klist > > Ticket cache: FILE:/tmp/krb5cc_0 > > Default principal: admin at ORION.LOCAL > > Valid starting Expires Service principal > > 09/24/14 11:20:36 09/24/14 12:20:36 krbtgt/ORION.LOCAL at ORION.LOCAL > > renew until 10/01/14 11:20:36 > > bash-3.2# > > bash-3.2# > > bash-3.2# > > bash-3.2# uname -a > > SunOS kwtpocipasol10u11 5.10 Generic_147148-26 i86pc i386 i86pc > > bash-3.2# > > --- > > > > Testing I can mount the remote FS (without Kerberos auth). This is > > successful (when not using kerberos5 authentication): > > > > --- > > bash-3.2# mount -F nfs 172.16.107.102:/data/centos-repo /remote/ > > bash-3.2# mount |grep remote > > /remote on 172.16.107.102:/data/centos-repo > > remote/read/write/setuid/devices/rstchown/xattr/dev=4f0000a on Wed Sep 24 > > 13:45:32 2014 > > bash-3.2# > > --- > > > > Testing with KRB5: > > > > --- > > bash-3.2# mount -F nfs -o sec=krb5 172.16.107.102:/data/centos-repo /remote/ > > nfs mount: mount: /remote: Permission denied > > bash-3.2# > > --- > > > > Looking at the krbkdc logs on the IPA master server, I get the following > > error: > > > > --- > > Sep 24 13:48:17 kwtpocipa001.orion.local krb5kdc[2371](info): AS_REQ (6 > > etypes {18 17 16 23 3 1}) 172.16.107.107 : > NEEDED_PREAUTH: > > host/kwtpocipasol10u11.orion.local at ORION.LOCAL for > > krbtgt/ORION.LOCAL at ORION.LOCAL, Additional pre-authentication required > > Sep 24 13:48:17 kwtpocipa001.orion.local krb5kdc[2373](info): DISPATCH: > > repeated (retransmitted?) request from 172.16.107.107, resending previous > > response > > Sep 24 13:48:17 kwtpocipa001.orion.local krb5kdc[2374](info): DISPATCH: > > repeated (retransmitted?) request from 172.16.107.107, resending previous > > response > > . > > . > > . > > Sep 24 13:48:18 kwtpocipa001.orion.local krb5kdc[2373](info): AS_REQ (6 > > etypes {18 17 16 23 3 1}) 172.16.107.107 : > CLIENT_NOT_FOUND: > > root/kwtpocipasol10u11.orion.local at ORION.LOCAL for > > krbtgt/ORION.LOCAL at ORION.LOCAL, Client not found in Kerberos database > > > > --- > > > > So it seems the host is not correctly registered. > > > > NOTE: Via the interface ,I can see the solaris client is > > not properly enrolled (" Kerberos Key Not Present"), however the > > documentation doesn't seem to indicate clearly how this should be done for > > a Solaris client. I have regenerated the certificate though, so it shows > > "valid certificate present". > > > > My question is: Is the process described in this guide still > > correct/functional for integrating Solaris 10 clients? > > If so, is there some way I could debug further to pinpoint why the solaris > > client is not being registered in the Kerberos DB? > > > > Many thanks in advance! > > Traiano > > Hello Traiano, > > This part of the documentation is wrong, as reported by ldapadd, userpassword > is not correct. > > If you specify the entry with clear text password, it would work. I.e.: > > dn: cn=proxyagent,ou=profile,dc=orion,dc=local > objectClass: top > objectClass: person > sn: proxyagent > cn: proxyagent > userPassword: agentpassword > > Note that Solaris related documentation is (unfortunately) known to be off: > https://fedorahosted.org/freeipa/ticket/3731 > > Also please note that the guide you are referring to is also pretty old (from > Fedora 18 times) and not updated. There is a related thread: > > https://www.redhat.com/archives/freeipa-users/2014-September/msg00357.html > > Indeed. There are some minor errata as well like the use of the "-t" flag with > Solaris' version of the mount command: > bash-3.2# mount -t nfs -o sec=krb5 172.16.107.102:/data/centos-repo /remote/ > mount: illegal option -- t > "-F" works. > I've adjusted the steps I've used to include the changes you mentioned in > https://fedorahosted.org/freeipa/ticket/3731, attached is a step by step > listing of the process with my output up to step 9, where mounting NFS fails. > Hopefully by a process of iteration I can document the updated process for > configuring Solaris 10 clients. Thank you, that helps - I would hand over the updated steps to downstream RHEL guide maintainer. > Here is what I'm seeing at step 9 (referencing the old Fedora 18 docs with > adjusted steps)L > h) Mount the NFS share. [FAILS] > --- > bash-3.2# mount -F nfs -o sec=krb5 172.16.107.102:/data/centos-repo /remote/ > nfs mount: mount: /remote: Permission denied > bash-3.2# > --- > /var/log/krbkdc.Log entries: > --- > krb5kdc: Cannot determine realm for numeric host address - unable to find > realm of host > Sep 25 18:18:20 kwtpocipa001.orion.local krb5kdc[2373](info): TGS_REQ (6 > etypes {18 17 16 23 3 1}) 172.16.107.107 : > LOOKING_UP_SERVER: authtime 0, > admin at ORION.LOCAL for , Server not > found in Kerberos database > Sep 25 18:18:20 kwtpocipa001.orion.local krb5kdc[2373](info): TGS_REQ (6 > etypes {18 17 16 23 3 1}) 172.16.107.107 : > LOOKING_UP_SERVER: authtime 0, > admin at ORION.LOCAL for , Server not > found in Kerberos database > krb5kdc: Cannot determine realm for numeric host address - unable to find > realm of host > Sep 25 18:18:20 kwtpocipa001.orion.local krb5kdc[2373](info): TGS_REQ (6 > etypes {18 17 16 23 3 1}) 172.16.107.107 : > LOOKING_UP_SERVER: authtime 0, > admin at ORION.LOCAL for , Server not > found in Kerberos database > Sep 25 18:18:20 kwtpocipa001.orion.local krb5kdc[2373](info): TGS_REQ (6 > etypes {18 17 16 23 3 1}) 172.16.107.107 : > LOOKING_UP_SERVER: authtime 0, > admin at ORION.LOCAL for , Server not > found in Kerberos database > krb5kdc: Cannot determine realm for numeric host address - unable to find > realm of host > Sep 25 18:18:20 kwtpocipa001.orion.local krb5kdc[2373](info): TGS_REQ (6 > etypes {18 17 16 23 3 1}) 172.16.107.107 : > LOOKING_UP_SERVER: authtime 0, > admin at ORION.LOCAL for , Server not > found in Kerberos database > Sep 25 18:18:20 kwtpocipa001.orion.local krb5kdc[2373](info): TGS_REQ (6 > etypes {18 17 16 23 3 1}) 172.16.107.107 : > LOOKING_UP_SERVER: authtime 0, > admin at ORION.LOCAL for , Server not > found in Kerberos database > --- > > However DNS forward and reverse records DO seem to resolve: > --- > [root at kwtpocipa001 ~]# host 172.16.107.107 > 107.107.16.172.in-addr.arpa domain name pointer kwtpocipasol10u11.orion.local. > [root at kwtpocipa001 ~]# host kwtpocipasol10u11.orion.local > kwtpocipasol10u11.orion.local has address 172.16.107.107 > --- I assume this is being run from your IPA server - it looks OK. > > And we can kinit and get a ticket: > --- > bash-3.2# kinit admin at ORION.LOCAL > Password for admin at ORION.LOCAL : > bash-3.2# > bash-3.2# > bash-3.2# klist > Ticket cache: FILE:/tmp/krb5cc_0 > Default principal: admin at ORION.LOCAL > Valid starting Expires Service principal > 09/25/14 18:31:49 09/25/14 19:31:49 krbtgt/ORION.LOCAL at ORION.LOCAL > > renew until 10/02/14 18:31:49 > bash-3.2# > --- > Regards, > Traiano Hmm, not sure what is the problem. Simo, do you know? I would just make sure that /etc/krb5.keytab on the NFS server (klist -kt /etc/krb5.keytab) has keys for both NFS and host service and all use the right fully qualified hostname. Martin From sjuhasz at chemaxon.com Fri Sep 26 09:19:43 2014 From: sjuhasz at chemaxon.com (Sandor Juhasz) Date: Fri, 26 Sep 2014 11:19:43 +0200 (CEST) Subject: [Freeipa-users] Virtual DIT view howto In-Reply-To: <20140925132450.GK11503@redhat.com> References: <1082300231.1105105.1411643144997.JavaMail.zimbra@chemaxon.com> <750226301.1105213.1411643287844.JavaMail.zimbra@chemaxon.com> <20140925132450.GK11503@redhat.com> Message-ID: <427178664.1179787.1411723183911.JavaMail.zimbra@chemaxon.com> Hello, i want to bind applications to the ldap, via ldap connector, so this should be fine. I have made the ldif, but i have no idea how to apply it, because simple ldapmodify gives and error. S?ndor Juh?sz System Administrator ChemAxon Ltd . Building Hx, GraphiSoft Park, Z?hony utca 7, Budapest, Hungary, H-1031 Cell: +36704258964 ----- Original Message ----- From: "Alexander Bokovoy" To: "Sandor Juhasz" Cc: freeipa-users at redhat.com Sent: Thursday, September 25, 2014 3:24:50 PM Subject: Re: [Freeipa-users] Virtual DIT view howto On Thu, 25 Sep 2014, Sandor Juhasz wrote: >Hello, > >i need a bit of help on how to create virtual dit structure on an existing ipa. >I need it to create separate structure to authenticate users for services which >don't support ldap search filters. >I did not find anything in the manual or any howto to start with. Look into slapi-nis documentation. You can use examples of compat tree as configured by IPA already. Note though that slapi-nis has support for authentication in RHEL 7 and Fedora 20 only. Earlier versions don't have proper support for LDAP BIND over compat tree. -- / Alexander Bokovoy -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Fri Sep 26 11:00:37 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 26 Sep 2014 13:00:37 +0200 Subject: [Freeipa-users] Virtual DIT view howto In-Reply-To: <427178664.1179787.1411723183911.JavaMail.zimbra@chemaxon.com> References: <1082300231.1105105.1411643144997.JavaMail.zimbra@chemaxon.com> <750226301.1105213.1411643287844.JavaMail.zimbra@chemaxon.com> <20140925132450.GK11503@redhat.com> <427178664.1179787.1411723183911.JavaMail.zimbra@chemaxon.com> Message-ID: <54254755.4010800@redhat.com> On 09/26/2014 11:19 AM, Sandor Juhasz wrote: > Hello, > > i want to bind applications to the ldap, via ldap connector, so this should be > fine. > > I have made the ldif, but i have no idea how to apply it, because simple > ldapmodify gives and error. I would then start with sharing the LDIF and the error with freeipa-users :-) Martin From sjuhasz at chemaxon.com Fri Sep 26 11:13:09 2014 From: sjuhasz at chemaxon.com (Sandor Juhasz) Date: Fri, 26 Sep 2014 13:13:09 +0200 (CEST) Subject: [Freeipa-users] Virtual DIT view howto In-Reply-To: <54254755.4010800@redhat.com> References: <1082300231.1105105.1411643144997.JavaMail.zimbra@chemaxon.com> <750226301.1105213.1411643287844.JavaMail.zimbra@chemaxon.com> <20140925132450.GK11503@redhat.com> <427178664.1179787.1411723183911.JavaMail.zimbra@chemaxon.com> <54254755.4010800@redhat.com> Message-ID: <1426272214.1190954.1411729989710.JavaMail.zimbra@chemaxon.com> mycompany.ldif: dn: ou=mycompany,cn=Schema Compatibility, cn=plugins, cn=config objectclass: top objectclass: extensibleObject ou: mycompany schema-compat-container-group: cn=compat,cn=accounts,dc=mydc schema-compat-container-rdn: ou=mycompany schema-compat-search-base: cn=users,cn=accounts,dc=cxusers schema-compat-search-filter: (&(objectClass=posixAccount)(memberOf=cn=mycompany,cn=groups,cn=accounts,dc=mydc)) schema-compat-entry-rdn: uid=%{uid} schema-compat-entry-attribute: objectClass=account schema-compat-entry-attribute: objectClass=posixAccount schema-compat-entry-attribute: objectClass=inetOrgPerson schema-compat-entry-attribute: objectClass=kerberosPrincipalAux schema-compat-entry-attribute: homeDirectory=%{homeDirectory} schema-compat-entry-attribute: uidNumber=%{uidNumber} schema-compat-entry-attribute: gidNumber=%{gidNumber} schema-compat-entry-attribute: loginShell=%{loginShell} schema-compat-entry-attribute: userPassword=* schema-compat-entry-attribute: mail=%{mail} schema-compat-entry-attribute: krbPrincipalName=%{krbPrincipalName} schema-compat-entry-attribute: cn=%{cn} schema-compat-entry-attribute: gecos=%{gecos} schema-compat-entry-attribute: givenName=%{givenName} schema-compat-entry-attribute: sn=%{sn} error: [root at mydc ~]# ldapmodify -Y GSSAPI -f mycompany.ldif SASL/GSSAPI authentication started SASL username: admin at MYDC SASL SSF: 56 SASL data security layer installed. ldapmodify: modify operation type is missing at line 2, entry "ou=mycompany,cn=Schema Compatibility, cn=plugins, cn=config" S?ndor Juh?sz System Administrator ChemAxon Ltd . Building Hx, GraphiSoft Park, Z?hony utca 7, Budapest, Hungary, H-1031 Cell: +36704258964 ----- Original Message ----- From: "Martin Kosek" To: "Sandor Juhasz" , freeipa-users at redhat.com Sent: Friday, September 26, 2014 1:00:37 PM Subject: Re: [Freeipa-users] Virtual DIT view howto On 09/26/2014 11:19 AM, Sandor Juhasz wrote: > Hello, > > i want to bind applications to the ldap, via ldap connector, so this should be > fine. > > I have made the ldif, but i have no idea how to apply it, because simple > ldapmodify gives and error. I would then start with sharing the LDIF and the error with freeipa-users :-) Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Fri Sep 26 11:17:01 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 26 Sep 2014 13:17:01 +0200 Subject: [Freeipa-users] Virtual DIT view howto In-Reply-To: <1426272214.1190954.1411729989710.JavaMail.zimbra@chemaxon.com> References: <1082300231.1105105.1411643144997.JavaMail.zimbra@chemaxon.com> <750226301.1105213.1411643287844.JavaMail.zimbra@chemaxon.com> <20140925132450.GK11503@redhat.com> <427178664.1179787.1411723183911.JavaMail.zimbra@chemaxon.com> <54254755.4010800@redhat.com> <1426272214.1190954.1411729989710.JavaMail.zimbra@chemaxon.com> Message-ID: <54254B2D.2000202@redhat.com> On 09/26/2014 01:13 PM, Sandor Juhasz wrote: > mycompany.ldif: > > dn: ou=mycompany,cn=Schema Compatibility, cn=plugins, cn=config > objectclass: top > objectclass: extensibleObject > ou: mycompany > schema-compat-container-group: cn=compat,cn=accounts,dc=mydc > schema-compat-container-rdn: ou=mycompany > schema-compat-search-base: cn=users,cn=accounts,dc=cxusers > schema-compat-search-filter: > (&(objectClass=posixAccount)(memberOf=cn=mycompany,cn=groups,cn=accounts,dc=mydc)) > schema-compat-entry-rdn: uid=%{uid} > schema-compat-entry-attribute: objectClass=account > schema-compat-entry-attribute: objectClass=posixAccount > schema-compat-entry-attribute: objectClass=inetOrgPerson > schema-compat-entry-attribute: objectClass=kerberosPrincipalAux > schema-compat-entry-attribute: homeDirectory=%{homeDirectory} > schema-compat-entry-attribute: uidNumber=%{uidNumber} > schema-compat-entry-attribute: gidNumber=%{gidNumber} > schema-compat-entry-attribute: loginShell=%{loginShell} > schema-compat-entry-attribute: userPassword=* > schema-compat-entry-attribute: mail=%{mail} > schema-compat-entry-attribute: krbPrincipalName=%{krbPrincipalName} > schema-compat-entry-attribute: cn=%{cn} > schema-compat-entry-attribute: gecos=%{gecos} > schema-compat-entry-attribute: givenName=%{givenName} > schema-compat-entry-attribute: sn=%{sn} > > > error: > > [root at mydc ~]# ldapmodify -Y GSSAPI -f mycompany.ldif > SASL/GSSAPI authentication started > SASL username: admin at MYDC > SASL SSF: 56 > SASL data security layer installed. > ldapmodify: modify operation type is missing at line 2, entry > "ou=mycompany,cn=Schema Compatibility, cn=plugins, cn=config" You either need to add changetype: add to the second line or use ldapadd. You can check the doc here: https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Creating_Directory_Entries-LDIF_Update_Statements.html#LDIF_Update_Statements-Adding_an_Entry_Using_LDIF Martin From tobereplaced at gmail.com Fri Sep 26 05:45:16 2014 From: tobereplaced at gmail.com (ToBeReplaced) Date: Thu, 25 Sep 2014 23:45:16 -0600 Subject: [Freeipa-users] 3.3.3 - Unable to install remote client In-Reply-To: <20140925152708.GD5015@redhat.com> References: <1411585354.2137.15.camel@localhost.localdomain> <20140925152708.GD5015@redhat.com> Message-ID: <1411710316.2113.8.camel@localhost.localdomain> It doesn't hang around, but I was able to make the install "work" by hacking iptables via: iptables -t nat -A OUTPUT -d 192.168.1.100 -j DNAT --to-destination 12.34.56.78 Here's the generated /etc/krb5.conf on client: #File modified by ipa-client-install includedir /var/lib/sss/pubconf/krb5.include.d/ [libdefaults] default_realm = EXAMPLE.COM dns_lookup_realm = true dns_lookup_kdc = true rdns = false ticket_lifetime = 24h forwardable = yes default_ccache_name = KEYRING:persistent:%{uid} [realms] EXAMPLE.COM = { pkinit_anchors = FILE:/etc/ipa/ca.crt } [domain_realm] .example.com = EXAMPLE.COM example.com = EXAMPLE.COM Running kinit admin as suggested yields no errors, and the only ip address listed is the correct one (12.34.56.78). Of course, this is after the iptables hack from install, but it is also post reboot so the iptables hack is gone. Cheers, ToBeReplaced On Thu, 2014-09-25 at 11:27 -0400, Nalin Dahyabhai wrote: > On Wed, Sep 24, 2014 at 01:02:34PM -0600, ToBeReplaced wrote: > > In details below, the domain name, server host name, and ip address has > > been changed. > > > > The server is sitting behind a router with ip 12.34.56.78. The server > > was configured with `--enable-dns` and `192.168.1.100 ipa.example.com > > ipa` in /etc/hosts. > > > > firewalld has been set to open up ports for ldap, ldaps, kerberos, > > kpasswd, dns, ntp, http, https on both the client and server. Port 7389 > > is also open on the server. > > > > The router has been configured to forward all of the above ports through > > 12.34.56.78 to 192.168.1.100. > > > > The client is sitting on a different network (say, behind a router with > > ip 98.76.54.32). > > > > Its /etc/hosts includes `12.34.56.78 ipa.example.com ipa`. > > Its /etc/resolv.conf includes `nameserver 12.34.56.78` > > > > ipa-client-install fails with: > > > > Discovery was successful! > > Hostname: laptop-1.example.com > > Realm: EXAMPLE.COM > > DNS Domain: example.com > > IPA Server: ipa.example.com > > BaseDN: dc=example,dc=com > > Synchronizing time with KDC... > > Successfully retrieved CA cert > > Subject: CN=Certificate Authority,O=EXAMPLE.COM > > Issuer: CN=Certificate Authority,O=EXAMPLE.COM > > Valid From: Wed Sep 24 17:44:28 2014 UTC > > Valid Until: Sun Sep 24 17:44:28 2034 UTC > > > > Enrolled in IPA realm EXAMPLE.COM > > Created /etc/ipa/default.conf > > New SSSD config will be created > > Configured /etc/sssd/sssd.conf > > Configured /etc/krb5.conf for IPA realm EXAMPLE.COM > > trying https://ipa.example.com/ipa/xml > > Forwarding 'ping' to server 'https://ipa.example.com/ipa/xml' > > Cannot connect to the server due to Kerberos error: Kerberos > > error: ('Unspecified GSS failure. Minor code may provide more > > information', 851968)/("Cannot contact any KDC for realm > > 'EXAMPLE.COM'", -1765328228). Trying with delegate=True > > trying https://ipa.example.com/ipa/xml > > Forwarding 'ping' to server 'https://ipa.example.com/ipa/xml' > > Second connect with delegate=True also failed: Kerberos error: > > ('Unspecified GSS failure. Minor code may provide more > > information', 851968)/("Cannot contact any KDC for realm > > 'EXAMPLE.COM'", -1765328228) > > Cannot connect to the IPA server XML-RPC interface: Kerberos > > error: ('Unspecified GSS failure. Minor code may provide more > > information', 851968)/("Cannot contact any KDC for realm > > 'EXAMPLE.COM'", -1765328228) > > Installation failed. Rolling back changes. > > Unenrolling client from IPA server > > Unenrolling host failed: Error obtaining initial credentials: > > Cannot contact any KDC for requested realm. > > Removing Kerberos service principals from /etc/krb5.keytab > > Disabling client Kerberos and LDAP configurations > > Redundant SSSD configuration file /etc/sssd/sssd.conf was moved > > to /etc/sssd/sssd.conf.deleted > > Restoring client configuration files > > nscd daemon is not installed, skip configuration > > nslcd daemon is not installed, skip configuration > > Client uninstall complete. > > > > `cat /var/log/ipaclient-install.log | grep ERROR -C 25 -m 1` > > 2014-09-24T18:11:49Z INFO Configured /etc/krb5.conf for IPA > > realm EXAMPLE.COM > > 2014-09-24T18:11:49Z DEBUG Starting external process > > 2014-09-24T18:11:49Z DEBUG args=keyctl search @s user > > ipa_session_cookie:host/laptop-1.example.com at EXAMPLE.COM > > 2014-09-24T18:11:49Z DEBUG Process finished, return code=1 > > 2014-09-24T18:11:49Z DEBUG stdout= > > 2014-09-24T18:11:49Z DEBUG stderr=keyctl_search: Required key > > not available > > > > 2014-09-24T18:11:49Z DEBUG Starting external process > > 2014-09-24T18:11:49Z DEBUG args=keyctl search @s user > > ipa_session_cookie:host/laptop-1.example.com at EXAMPLE.COM > > 2014-09-24T18:11:49Z DEBUG Process finished, return code=1 > > 2014-09-24T18:11:49Z DEBUG stdout= > > 2014-09-24T18:11:49Z DEBUG stderr=keyctl_search: Required key > > not available > > > > 2014-09-24T18:11:49Z DEBUG failed to find session_cookie in > > persistent storage for principal > > 'host/laptop-1.example.com at EXAMPLE.COM' > > 2014-09-24T18:11:49Z INFO trying https://ipa.example.com/ipa/xml > > 2014-09-24T18:11:49Z DEBUG Created connection context.xmlclient > > 2014-09-24T18:11:49Z DEBUG Try RPC connection > > 2014-09-24T18:11:49Z INFO Forwarding 'ping' to server > > 'https://ipa.example.com/ipa/xml' > > 2014-09-24T18:12:07Z DEBUG Destroyed connection > > context.xmlclient > > 2014-09-24T18:12:07Z INFO Cannot connect to the server due to > > Kerberos error: Kerberos error: ('Unspecified GSS failure. > > Minor code may provide more information', 851968)/("Cannot > > contact any KDC for realm 'EXAMPLE.COM'", -1765328228). Trying > > with delegate=True > > 2014-09-24T18:12:07Z INFO trying https://ipa.example.com/ipa/xml > > 2014-09-24T18:12:07Z DEBUG Created connection context.xmlclient > > 2014-09-24T18:12:07Z DEBUG Try RPC connection > > 2014-09-24T18:12:07Z INFO Forwarding 'ping' to server > > 'https://ipa.example.com/ipa/xml' > > 2014-09-24T18:12:25Z WARNING Second connect with delegate=True > > also failed: Kerberos error: ('Unspecified GSS failure. Minor > > code may provide more information', 851968)/("Cannot contact any > > KDC for realm 'EXAMPLE.COM'", -1765328228) > > 2014-09-24T18:12:25Z ERROR Cannot connect to the IPA server > > XML-RPC interface: Kerberos error: ('Unspecified GSS failure. > > Minor code may provide more information', 851968)/("Cannot > > contact any KDC for realm 'EXAMPLE.COM'", -1765328228) > > > > One possibly worthwhile note is that running tcpdump shows that the > > client (local IP 192.168.0.102) is trying to connect to 192.168.1.100, > > the local IP of the server, which is on a different network and thus > > inaccessible. > > > > 14:11:49.611009 IP 192.168.0.102.57552 > > > 192.168.1.100.kerberos: > > 14:11:50.645238 IP 192.168.0.102.37952 > 192.168.1.100.kerberos: > > Flags [S], seq 1224109057, win 14600, op > > tions [mss 1460,sackOK,TS val 5701517 ecr 0,nop,wscale 7], > > length 0 > > 14:11:51.648218 IP 192.168.0.102.37952 > 192.168.1.100.kerberos: > > Flags [S], seq 1224109057, win 14600, op > > tions [mss 1460,sackOK,TS val 5702520 ecr 0,nop,wscale 7], > > length 0 > > > > etc. etc. > > Any chance the /etc/krb5.conf that the install script created is still > around? Based on your tcpdump data, my first guess would be that the > Kerberos client bits ended up looking up the KDC (the Kerberos service) > location using DNS, which would have pointed it at the non-tunneled > address. If it's around, running > env KRB5_CONFIG=/path/to/krb5.conf KRB5_TRACE=/dev/stderr kinit admin > should provide information about how it's locating servers, allowing us > to confirm if that's what's happening here. > > HTH, > > Nalin From ssorce at redhat.com Fri Sep 26 14:07:24 2014 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 26 Sep 2014 10:07:24 -0400 Subject: [Freeipa-users] FreeIPA 3.3 and Solaris 10 Client Integration: In-Reply-To: <54251310.2030502@redhat.com> References: <5422A889.3040907@redhat.com> <54251310.2030502@redhat.com> Message-ID: <20140926100724.77214c2f@willson.usersys.redhat.com> On Fri, 26 Sep 2014 09:17:36 +0200 Martin Kosek wrote: > On 09/25/2014 05:35 PM, Traiano Welcome wrote: > > Hi Martin > > > > On Wed, Sep 24, 2014 at 2:18 PM, Martin Kosek > > wrote: > > > > On 09/24/2014 01:06 PM, Traiano Welcome wrote: > > > Hi List > > > > > > I'm currently running IPA 3.3 on Centos 7, and successfully > > > authenticating Linux clients (Centos 6.5). > > > > > > I'd like to setup Solaris 10 as an IPA client, but this seems > > > problematic. I am following this guide: > > > > > > > > http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html#Configuring_an_IPA_Client_on_Solaris_10 > > > > > > I have the following setup: > > > > > > Solaris client: > > > > > > - Solaris 10u11 (SunOS 5.10 Generic_147148-26 i86pc i386 > > > i86pc) > > > > > > IdM Server: > > > > > > - Linux kwtpocipa001.orion.local 3.10.0-123.el7.x86_64 #1 > > > SMP Mon Jun 30 12:09:22 UTC 2014 x86_64 x86_64 x86_64 > > > GNU/Linux > > > > > > > > > > > > Going through the steps in the guide: at step 3 ("Create the > > > cn=proxyagent account"), ldapadd fails with the following > > > error: > > > > > > > > > > > > "ldapadd: invalid format (line 6) entry: > > > "cn=proxyagent,ou=profile,dc=orion,dc=local"" > > > > > > --- > > > > > > [root at kwtpocipa001 ~]# ldapadd -h 172.16.107.102 -p 389 -D > > > "cn=directory manager" -w Cr4ckM0nk3y > > > dn: cn=proxyagent,ou=profile,dc=orion,dc=local > > > objectClass: top > > > objectClass: person > > > sn: proxyagent > > > cn: proxyagent > > > userPassword:: > > > e1NTSEF9Mm53KytGeU81Z1dka1FLNUZlaDdXOHJkK093TEppY2NjRmt6Wnc9PQ= > > > > > > ldapadd: invalid format (line 6) entry: > > > "cn=proxyagent,ou=profile,dc=orion,dc=local" > > > --- > > > > > > I've made the assumption that the extra ":" is a typo in > > > the documentation and removed it, so the command runs > > > successfully as follows: > > > > > > > > > --- > > > [root at kwtpocipa001 ~]# ldapadd -h 172.16.107.102 -p 389 -D > > > "cn=directory manager" -w Cr4ckM0nk3y > > > > > > dn: cn=proxyagent,ou=profile,dc=orion,dc=local > > > objectClass: top > > > objectClass: person > > > sn: proxyagent > > > cn: proxyagent > > > userPassword: > > > e1NTSEF9Mm53KytGeU81Z1dka1FLNUZlaDdXOHJkK093TEppY2NjRmt6Wnc9PQ= > > > adding new entry "cn=proxyagent,ou=profile,dc=orion,dc=local" > > > --- > > > > > > > > > At step 9 (Configure NFS ), I get an error, seems to > > > indicate the "des-cbc-crc" encryption type is unsupported: > > > > > > --- > > > [root at kwtpocipa001 ~]# ipa-getkeytab -s > > > kwtpocipa001.orion.local -p > > > nfs/kwtpocipasol10u11.orion.local > > > -k /tmp/kwtpocipasol10u11.keytab -e des-cbc-crc Operation > > > failed! All enctypes provided are unsupported > > > [root at kwtpocipa001 ~]# --- > > > > > > (Question: How would I add support for des-cbc-crc > > > encryption in freeipa?). I've now worked around this by not > > > specifying any encryption type: > > > > > > --- > > > [root at kwtpocipa001 ~]# ipa-getkeytab -s > > > kwtpocipa001.orion.local -p > > > nfs/kwtpocipasol10u11.orion.local > > > -k /tmp/kwtpocipasol10u11.keytab Keytab successfully > > > retrieved and stored in: /tmp/kwtpocipasol10u11.keytab > > > [root at kwtpocipa001 ~]# --- > > > > > > Testing that I can see nfs mounts on the centos IPA server > > > from the solaris machine: > > > > > > --- > > > bash-3.2# showmount -e kwtpocipa001.orion.local > > > export list for kwtpocipa001.orion.local: > > > /data/centos-repo 172.16.0.0/24 > > > bash-3.2# > > > ---- > > > > > > > > > Checking we can kinit: > > > > > > --- > > > bash-3.2# > > > bash-3.2# kinit admin > > > Password for admin at ORION.LOCAL: > > > bash-3.2# > > > bash-3.2# > > > bash-3.2# klist > > > Ticket cache: FILE:/tmp/krb5cc_0 > > > Default principal: admin at ORION.LOCAL > > > Valid starting Expires Service > > > principal 09/24/14 11:20:36 09/24/14 12:20:36 > > > krbtgt/ORION.LOCAL at ORION.LOCAL renew until 10/01/14 11:20:36 > > > bash-3.2# > > > bash-3.2# > > > bash-3.2# > > > bash-3.2# uname -a > > > SunOS kwtpocipasol10u11 5.10 Generic_147148-26 i86pc i386 > > > i86pc bash-3.2# > > > --- > > > > > > Testing I can mount the remote FS (without Kerberos auth). > > > This is successful (when not using kerberos5 authentication): > > > > > > --- > > > bash-3.2# mount -F nfs > > > 172.16.107.102:/data/centos-repo /remote/ bash-3.2# mount > > > |grep remote /remote on 172.16.107.102:/data/centos-repo > > > remote/read/write/setuid/devices/rstchown/xattr/dev=4f0000a > > > on Wed Sep 24 13:45:32 2014 > > > bash-3.2# > > > --- > > > > > > Testing with KRB5: > > > > > > --- > > > bash-3.2# mount -F nfs -o sec=krb5 > > > 172.16.107.102:/data/centos-repo /remote/ nfs mount: > > > mount: /remote: Permission denied bash-3.2# > > > --- > > > > > > Looking at the krbkdc logs on the IPA master server, I get > > > the following error: > > > > > > --- > > > Sep 24 13:48:17 kwtpocipa001.orion.local > > > krb5kdc[2371](info): AS_REQ (6 etypes {18 17 16 23 3 1}) > > > 172.16.107.107 : > > NEEDED_PREAUTH: > > > host/kwtpocipasol10u11.orion.local at ORION.LOCAL for > > > krbtgt/ORION.LOCAL at ORION.LOCAL, Additional > > > pre-authentication required Sep 24 13:48:17 > > > kwtpocipa001.orion.local krb5kdc[2373](info): DISPATCH: > > > repeated (retransmitted?) request from 172.16.107.107, > > > resending previous response Sep 24 13:48:17 > > > kwtpocipa001.orion.local krb5kdc[2374](info): DISPATCH: > > > repeated (retransmitted?) request from 172.16.107.107, > > > resending previous response . > > > . > > > . > > > Sep 24 13:48:18 kwtpocipa001.orion.local > > > krb5kdc[2373](info): AS_REQ (6 etypes {18 17 16 23 3 1}) > > > 172.16.107.107 : > > CLIENT_NOT_FOUND: > > > root/kwtpocipasol10u11.orion.local at ORION.LOCAL for > > > krbtgt/ORION.LOCAL at ORION.LOCAL, Client not found in Kerberos > > > database > > > > > > --- > > > > > > So it seems the host is not correctly registered. > > > > > > NOTE: Via the interface ,I can see the solaris client is > > > not properly enrolled (" Kerberos Key Not Present"), however > > > the documentation doesn't seem to indicate clearly how this > > > should be done for a Solaris client. I have regenerated the > > > certificate though, so it shows "valid certificate present". > > > > > > My question is: Is the process described in this guide still > > > correct/functional for integrating Solaris 10 clients? > > > If so, is there some way I could debug further to pinpoint > > > why the solaris client is not being registered in the > > > Kerberos DB? > > > > > > Many thanks in advance! > > > Traiano > > > > Hello Traiano, > > > > This part of the documentation is wrong, as reported by > > ldapadd, userpassword is not correct. > > > > If you specify the entry with clear text password, it would > > work. I.e.: > > > > dn: cn=proxyagent,ou=profile,dc=orion,dc=local > > objectClass: top > > objectClass: person > > sn: proxyagent > > cn: proxyagent > > userPassword: agentpassword > > > > Note that Solaris related documentation is (unfortunately) > > known to be off: https://fedorahosted.org/freeipa/ticket/3731 > > > > Also please note that the guide you are referring to is also > > pretty old (from Fedora 18 times) and not updated. There is a > > related thread: > > > > https://www.redhat.com/archives/freeipa-users/2014-September/msg00357.html > > > > Indeed. There are some minor errata as well like the use of the > > "-t" flag with Solaris' version of the mount command: > > bash-3.2# mount -t nfs -o sec=krb5 > > 172.16.107.102:/data/centos-repo /remote/ mount: illegal option -- t > > "-F" works. > > I've adjusted the steps I've used to include the changes you > > mentioned in https://fedorahosted.org/freeipa/ticket/3731, attached > > is a step by step listing of the process with my output up to step > > 9, where mounting NFS fails. Hopefully by a process of iteration I > > can document the updated process for configuring Solaris 10 clients. > > Thank you, that helps - I would hand over the updated steps to > downstream RHEL guide maintainer. > > > Here is what I'm seeing at step 9 (referencing the old Fedora 18 > > docs with adjusted steps)L > > h) Mount the NFS share. [FAILS] > > --- > > bash-3.2# mount -F nfs -o sec=krb5 > > 172.16.107.102:/data/centos-repo /remote/ nfs mount: > > mount: /remote: Permission denied bash-3.2# > > --- > > /var/log/krbkdc.Log entries: > > --- > > krb5kdc: Cannot determine realm for numeric host address - unable > > to find realm of host > > Sep 25 18:18:20 kwtpocipa001.orion.local krb5kdc[2373](info): > > TGS_REQ (6 etypes {18 17 16 23 3 1}) 172.16.107.107 > > : LOOKING_UP_SERVER: authtime 0, > > admin at ORION.LOCAL for , > > Server not found in Kerberos database > > Sep 25 18:18:20 kwtpocipa001.orion.local krb5kdc[2373](info): > > TGS_REQ (6 etypes {18 17 16 23 3 1}) 172.16.107.107 > > : LOOKING_UP_SERVER: authtime 0, > > admin at ORION.LOCAL for , > > Server not found in Kerberos database > > krb5kdc: Cannot determine realm for numeric host address - unable > > to find realm of host > > Sep 25 18:18:20 kwtpocipa001.orion.local krb5kdc[2373](info): > > TGS_REQ (6 etypes {18 17 16 23 3 1}) 172.16.107.107 > > : LOOKING_UP_SERVER: authtime 0, > > admin at ORION.LOCAL for , > > Server not found in Kerberos database > > Sep 25 18:18:20 kwtpocipa001.orion.local krb5kdc[2373](info): > > TGS_REQ (6 etypes {18 17 16 23 3 1}) 172.16.107.107 > > : LOOKING_UP_SERVER: authtime 0, > > admin at ORION.LOCAL for , > > Server not found in Kerberos database > > krb5kdc: Cannot determine realm for numeric host address - unable > > to find realm of host > > Sep 25 18:18:20 kwtpocipa001.orion.local krb5kdc[2373](info): > > TGS_REQ (6 etypes {18 17 16 23 3 1}) 172.16.107.107 > > : LOOKING_UP_SERVER: authtime 0, > > admin at ORION.LOCAL for , > > Server not found in Kerberos database > > Sep 25 18:18:20 kwtpocipa001.orion.local krb5kdc[2373](info): > > TGS_REQ (6 etypes {18 17 16 23 3 1}) 172.16.107.107 > > : LOOKING_UP_SERVER: authtime 0, > > admin at ORION.LOCAL for , > > Server not found in Kerberos database > > --- > > > > However DNS forward and reverse records DO seem to resolve: > > --- > > [root at kwtpocipa001 ~]# host 172.16.107.107 > > 107.107.16.172.in-addr.arpa domain name pointer > > kwtpocipasol10u11.orion.local. [root at kwtpocipa001 ~]# host > > kwtpocipasol10u11.orion.local kwtpocipasol10u11.orion.local has > > address 172.16.107.107 --- > > I assume this is being run from your IPA server - it looks OK. > > > > > And we can kinit and get a ticket: > > --- > > bash-3.2# kinit admin at ORION.LOCAL > > Password for admin at ORION.LOCAL : > > bash-3.2# > > bash-3.2# > > bash-3.2# klist > > Ticket cache: FILE:/tmp/krb5cc_0 > > Default principal: admin at ORION.LOCAL > > Valid starting Expires Service > > principal 09/25/14 18:31:49 09/25/14 19:31:49 > > krbtgt/ORION.LOCAL at ORION.LOCAL > > renew until 10/02/14 > > 18:31:49 bash-3.2# > > --- > > Regards, > > Traiano > > Hmm, not sure what is the problem. Simo, do you know? Use a fully qualified name of the nfs server on the mount command, not an IP address. > I would just make sure that /etc/krb5.keytab on the NFS server (klist > -kt /etc/krb5.keytab) has keys for both NFS and host service and all > use the right fully qualified hostname. Yes, having a nfs/fqdn at REALM key on the client is recommended and necessary in some cases. Simo. -- Simo Sorce * Red Hat, Inc * New York From tevfik.ceydeliler at astron.yasar.com.tr Fri Sep 26 14:12:05 2014 From: tevfik.ceydeliler at astron.yasar.com.tr (Tevfik Ceydeliler) Date: Fri, 26 Sep 2014 17:12:05 +0300 Subject: [Freeipa-users] authentication log Message-ID: <54257435.4080607@astron.yasar.com.tr> Sorry maybe too newbie question but, where is ipa authentication logs? who logs in who logs out etc? --


Bu elektronik postada bulunan tum fikir ve gorusler ve ekindeki dosyalar sadece adres sahip/sahiplerine ait olup, Yasar Toplulugu Sirketleri bu mesajin icerigi ile ilgili olarak hic bir hukuksal sorumlulugu kabul etmez. Eger gonderilmesi dusunulen kisi veya kurulus degilseniz, lutfen gonderen kisiyi derhal haberdar ediniz ve mesaji sisteminizden siliniz.The information contained in this e-mail and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and Yasar Group Companies do not accept legal responsibility for the contents. If you are not the intended recipient, please immediately notify the sender and delete it from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.png Type: image/png Size: 15216 bytes Desc: not available URL: From dpal at redhat.com Fri Sep 26 14:23:19 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 26 Sep 2014 10:23:19 -0400 Subject: [Freeipa-users] authentication log In-Reply-To: <54257435.4080607@astron.yasar.com.tr> References: <54257435.4080607@astron.yasar.com.tr> Message-ID: <542576D7.3080400@redhat.com> On 09/26/2014 10:12 AM, Tevfik Ceydeliler wrote: > Sorry maybe too newbie question but, where is ipa authentication logs? > who logs in who logs out etc? There are many logs and it depends on the configuration of the clients too. You can see LDAP authentication in the 389 DS logs You can see Kerberos authentication in Kerberos log The log in will be reflected on the client (if it is SSSD then in its logs and in syslog). Server usually does not know about "logout", this is a client side information. Syslog, auditd will be helpful here. Also see logs mentioned on the page: http://www.freeipa.org/page/Troubleshooting > > -- > > > > > > > Bu elektronik postada bulunan tum fikir ve gorusler ve ekindeki > dosyalar sadece adres sahip/sahiplerine ait olup, Yasar Toplulugu > Sirketleri bu mesajin icerigi ile ilgili olarak hic bir hukuksal > sorumlulugu kabul etmez. Eger gonderilmesi dusunulen kisi veya kurulus > degilseniz, lutfen gonderen kisiyi derhal haberdar ediniz ve mesaji > sisteminizden siliniz.The information contained in this e-mail and any > files transmitted with it are intended solely for the use of the > individual or entity to whom they are addressed and Yasar Group > Companies do not accept legal responsibility for the contents. If you > are not the intended recipient, please immediately notify the sender > and delete it from your system. > > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 15216 bytes Desc: not available URL: From Johan.Petersson at sscspace.com Fri Sep 26 16:30:55 2014 From: Johan.Petersson at sscspace.com (Johan Petersson) Date: Fri, 26 Sep 2014 16:30:55 +0000 Subject: [Freeipa-users] FreeIPA 3.3 and Solaris 10 Client Integration: In-Reply-To: <20140926100724.77214c2f@willson.usersys.redhat.com> References: <5422A889.3040907@redhat.com> <54251310.2030502@redhat.com>, <20140926100724.77214c2f@willson.usersys.redhat.com> Message-ID: <558C15177F5E714F83334217C9A197DF01840474AA@SSC-MBX2.ssc.internal> Hi, I have earlier posted a guide on how to set up Solaris 11 and 11.1 as a client to IPA with NFS 4 with Kerberos and autofs on freeipa-users and the difference for Solaris 10 should be minor adjustments. I will add that guide to the Freeipa-wiki during this weekend and if you can not find the guide by searching through earlier posts i can post it again. Regards, Johan ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Simo Sorce [ssorce at redhat.com] Sent: Friday, September 26, 2014 16:07 To: Martin Kosek Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] FreeIPA 3.3 and Solaris 10 Client Integration: On Fri, 26 Sep 2014 09:17:36 +0200 Martin Kosek wrote: > On 09/25/2014 05:35 PM, Traiano Welcome wrote: > > Hi Martin > > > > On Wed, Sep 24, 2014 at 2:18 PM, Martin Kosek > > wrote: > > > > On 09/24/2014 01:06 PM, Traiano Welcome wrote: > > > Hi List > > > > > > I'm currently running IPA 3.3 on Centos 7, and successfully > > > authenticating Linux clients (Centos 6.5). > > > > > > I'd like to setup Solaris 10 as an IPA client, but this seems > > > problematic. I am following this guide: > > > > > > > > http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html#Configuring_an_IPA_Client_on_Solaris_10 > > > > > > I have the following setup: > > > > > > Solaris client: > > > > > > - Solaris 10u11 (SunOS 5.10 Generic_147148-26 i86pc i386 > > > i86pc) > > > > > > IdM Server: > > > > > > - Linux kwtpocipa001.orion.local 3.10.0-123.el7.x86_64 #1 > > > SMP Mon Jun 30 12:09:22 UTC 2014 x86_64 x86_64 x86_64 > > > GNU/Linux > > > > > > > > > > > > Going through the steps in the guide: at step 3 ("Create the > > > cn=proxyagent account"), ldapadd fails with the following > > > error: > > > > > > > > > > > > "ldapadd: invalid format (line 6) entry: > > > "cn=proxyagent,ou=profile,dc=orion,dc=local"" > > > > > > --- > > > > > > [root at kwtpocipa001 ~]# ldapadd -h 172.16.107.102 -p 389 -D > > > "cn=directory manager" -w Cr4ckM0nk3y > > > dn: cn=proxyagent,ou=profile,dc=orion,dc=local > > > objectClass: top > > > objectClass: person > > > sn: proxyagent > > > cn: proxyagent > > > userPassword:: > > > e1NTSEF9Mm53KytGeU81Z1dka1FLNUZlaDdXOHJkK093TEppY2NjRmt6Wnc9PQ= > > > > > > ldapadd: invalid format (line 6) entry: > > > "cn=proxyagent,ou=profile,dc=orion,dc=local" > > > --- > > > > > > I've made the assumption that the extra ":" is a typo in > > > the documentation and removed it, so the command runs > > > successfully as follows: > > > > > > > > > --- > > > [root at kwtpocipa001 ~]# ldapadd -h 172.16.107.102 -p 389 -D > > > "cn=directory manager" -w Cr4ckM0nk3y > > > > > > dn: cn=proxyagent,ou=profile,dc=orion,dc=local > > > objectClass: top > > > objectClass: person > > > sn: proxyagent > > > cn: proxyagent > > > userPassword: > > > e1NTSEF9Mm53KytGeU81Z1dka1FLNUZlaDdXOHJkK093TEppY2NjRmt6Wnc9PQ= > > > adding new entry "cn=proxyagent,ou=profile,dc=orion,dc=local" > > > --- > > > > > > > > > At step 9 (Configure NFS ), I get an error, seems to > > > indicate the "des-cbc-crc" encryption type is unsupported: > > > > > > --- > > > [root at kwtpocipa001 ~]# ipa-getkeytab -s > > > kwtpocipa001.orion.local -p > > > nfs/kwtpocipasol10u11.orion.local > > > -k /tmp/kwtpocipasol10u11.keytab -e des-cbc-crc Operation > > > failed! All enctypes provided are unsupported > > > [root at kwtpocipa001 ~]# --- > > > > > > (Question: How would I add support for des-cbc-crc > > > encryption in freeipa?). I've now worked around this by not > > > specifying any encryption type: > > > > > > --- > > > [root at kwtpocipa001 ~]# ipa-getkeytab -s > > > kwtpocipa001.orion.local -p > > > nfs/kwtpocipasol10u11.orion.local > > > -k /tmp/kwtpocipasol10u11.keytab Keytab successfully > > > retrieved and stored in: /tmp/kwtpocipasol10u11.keytab > > > [root at kwtpocipa001 ~]# --- > > > > > > Testing that I can see nfs mounts on the centos IPA server > > > from the solaris machine: > > > > > > --- > > > bash-3.2# showmount -e kwtpocipa001.orion.local > > > export list for kwtpocipa001.orion.local: > > > /data/centos-repo 172.16.0.0/24 > > > bash-3.2# > > > ---- > > > > > > > > > Checking we can kinit: > > > > > > --- > > > bash-3.2# > > > bash-3.2# kinit admin > > > Password for admin at ORION.LOCAL: > > > bash-3.2# > > > bash-3.2# > > > bash-3.2# klist > > > Ticket cache: FILE:/tmp/krb5cc_0 > > > Default principal: admin at ORION.LOCAL > > > Valid starting Expires Service > > > principal 09/24/14 11:20:36 09/24/14 12:20:36 > > > krbtgt/ORION.LOCAL at ORION.LOCAL renew until 10/01/14 11:20:36 > > > bash-3.2# > > > bash-3.2# > > > bash-3.2# > > > bash-3.2# uname -a > > > SunOS kwtpocipasol10u11 5.10 Generic_147148-26 i86pc i386 > > > i86pc bash-3.2# > > > --- > > > > > > Testing I can mount the remote FS (without Kerberos auth). > > > This is successful (when not using kerberos5 authentication): > > > > > > --- > > > bash-3.2# mount -F nfs > > > 172.16.107.102:/data/centos-repo /remote/ bash-3.2# mount > > > |grep remote /remote on 172.16.107.102:/data/centos-repo > > > remote/read/write/setuid/devices/rstchown/xattr/dev=4f0000a > > > on Wed Sep 24 13:45:32 2014 > > > bash-3.2# > > > --- > > > > > > Testing with KRB5: > > > > > > --- > > > bash-3.2# mount -F nfs -o sec=krb5 > > > 172.16.107.102:/data/centos-repo /remote/ nfs mount: > > > mount: /remote: Permission denied bash-3.2# > > > --- > > > > > > Looking at the krbkdc logs on the IPA master server, I get > > > the following error: > > > > > > --- > > > Sep 24 13:48:17 kwtpocipa001.orion.local > > > krb5kdc[2371](info): AS_REQ (6 etypes {18 17 16 23 3 1}) > > > 172.16.107.107 : > > NEEDED_PREAUTH: > > > host/kwtpocipasol10u11.orion.local at ORION.LOCAL for > > > krbtgt/ORION.LOCAL at ORION.LOCAL, Additional > > > pre-authentication required Sep 24 13:48:17 > > > kwtpocipa001.orion.local krb5kdc[2373](info): DISPATCH: > > > repeated (retransmitted?) request from 172.16.107.107, > > > resending previous response Sep 24 13:48:17 > > > kwtpocipa001.orion.local krb5kdc[2374](info): DISPATCH: > > > repeated (retransmitted?) request from 172.16.107.107, > > > resending previous response . > > > . > > > . > > > Sep 24 13:48:18 kwtpocipa001.orion.local > > > krb5kdc[2373](info): AS_REQ (6 etypes {18 17 16 23 3 1}) > > > 172.16.107.107 : > > CLIENT_NOT_FOUND: > > > root/kwtpocipasol10u11.orion.local at ORION.LOCAL for > > > krbtgt/ORION.LOCAL at ORION.LOCAL, Client not found in Kerberos > > > database > > > > > > --- > > > > > > So it seems the host is not correctly registered. > > > > > > NOTE: Via the interface ,I can see the solaris client is > > > not properly enrolled (" Kerberos Key Not Present"), however > > > the documentation doesn't seem to indicate clearly how this > > > should be done for a Solaris client. I have regenerated the > > > certificate though, so it shows "valid certificate present". > > > > > > My question is: Is the process described in this guide still > > > correct/functional for integrating Solaris 10 clients? > > > If so, is there some way I could debug further to pinpoint > > > why the solaris client is not being registered in the > > > Kerberos DB? > > > > > > Many thanks in advance! > > > Traiano > > > > Hello Traiano, > > > > This part of the documentation is wrong, as reported by > > ldapadd, userpassword is not correct. > > > > If you specify the entry with clear text password, it would > > work. I.e.: > > > > dn: cn=proxyagent,ou=profile,dc=orion,dc=local > > objectClass: top > > objectClass: person > > sn: proxyagent > > cn: proxyagent > > userPassword: agentpassword > > > > Note that Solaris related documentation is (unfortunately) > > known to be off: https://fedorahosted.org/freeipa/ticket/3731 > > > > Also please note that the guide you are referring to is also > > pretty old (from Fedora 18 times) and not updated. There is a > > related thread: > > > > https://www.redhat.com/archives/freeipa-users/2014-September/msg00357.html > > > > Indeed. There are some minor errata as well like the use of the > > "-t" flag with Solaris' version of the mount command: > > bash-3.2# mount -t nfs -o sec=krb5 > > 172.16.107.102:/data/centos-repo /remote/ mount: illegal option -- t > > "-F" works. > > I've adjusted the steps I've used to include the changes you > > mentioned in https://fedorahosted.org/freeipa/ticket/3731, attached > > is a step by step listing of the process with my output up to step > > 9, where mounting NFS fails. Hopefully by a process of iteration I > > can document the updated process for configuring Solaris 10 clients. > > Thank you, that helps - I would hand over the updated steps to > downstream RHEL guide maintainer. > > > Here is what I'm seeing at step 9 (referencing the old Fedora 18 > > docs with adjusted steps)L > > h) Mount the NFS share. [FAILS] > > --- > > bash-3.2# mount -F nfs -o sec=krb5 > > 172.16.107.102:/data/centos-repo /remote/ nfs mount: > > mount: /remote: Permission denied bash-3.2# > > --- > > /var/log/krbkdc.Log entries: > > --- > > krb5kdc: Cannot determine realm for numeric host address - unable > > to find realm of host > > Sep 25 18:18:20 kwtpocipa001.orion.local krb5kdc[2373](info): > > TGS_REQ (6 etypes {18 17 16 23 3 1}) 172.16.107.107 > > : LOOKING_UP_SERVER: authtime 0, > > admin at ORION.LOCAL for , > > Server not found in Kerberos database > > Sep 25 18:18:20 kwtpocipa001.orion.local krb5kdc[2373](info): > > TGS_REQ (6 etypes {18 17 16 23 3 1}) 172.16.107.107 > > : LOOKING_UP_SERVER: authtime 0, > > admin at ORION.LOCAL for , > > Server not found in Kerberos database > > krb5kdc: Cannot determine realm for numeric host address - unable > > to find realm of host > > Sep 25 18:18:20 kwtpocipa001.orion.local krb5kdc[2373](info): > > TGS_REQ (6 etypes {18 17 16 23 3 1}) 172.16.107.107 > > : LOOKING_UP_SERVER: authtime 0, > > admin at ORION.LOCAL for , > > Server not found in Kerberos database > > Sep 25 18:18:20 kwtpocipa001.orion.local krb5kdc[2373](info): > > TGS_REQ (6 etypes {18 17 16 23 3 1}) 172.16.107.107 > > : LOOKING_UP_SERVER: authtime 0, > > admin at ORION.LOCAL for , > > Server not found in Kerberos database > > krb5kdc: Cannot determine realm for numeric host address - unable > > to find realm of host > > Sep 25 18:18:20 kwtpocipa001.orion.local krb5kdc[2373](info): > > TGS_REQ (6 etypes {18 17 16 23 3 1}) 172.16.107.107 > > : LOOKING_UP_SERVER: authtime 0, > > admin at ORION.LOCAL for , > > Server not found in Kerberos database > > Sep 25 18:18:20 kwtpocipa001.orion.local krb5kdc[2373](info): > > TGS_REQ (6 etypes {18 17 16 23 3 1}) 172.16.107.107 > > : LOOKING_UP_SERVER: authtime 0, > > admin at ORION.LOCAL for , > > Server not found in Kerberos database > > --- > > > > However DNS forward and reverse records DO seem to resolve: > > --- > > [root at kwtpocipa001 ~]# host 172.16.107.107 > > 107.107.16.172.in-addr.arpa domain name pointer > > kwtpocipasol10u11.orion.local. [root at kwtpocipa001 ~]# host > > kwtpocipasol10u11.orion.local kwtpocipasol10u11.orion.local has > > address 172.16.107.107 --- > > I assume this is being run from your IPA server - it looks OK. > > > > > And we can kinit and get a ticket: > > --- > > bash-3.2# kinit admin at ORION.LOCAL > > Password for admin at ORION.LOCAL : > > bash-3.2# > > bash-3.2# > > bash-3.2# klist > > Ticket cache: FILE:/tmp/krb5cc_0 > > Default principal: admin at ORION.LOCAL > > Valid starting Expires Service > > principal 09/25/14 18:31:49 09/25/14 19:31:49 > > krbtgt/ORION.LOCAL at ORION.LOCAL > > renew until 10/02/14 > > 18:31:49 bash-3.2# > > --- > > Regards, > > Traiano > > Hmm, not sure what is the problem. Simo, do you know? Use a fully qualified name of the nfs server on the mount command, not an IP address. > I would just make sure that /etc/krb5.keytab on the NFS server (klist > -kt /etc/krb5.keytab) has keys for both NFS and host service and all > use the right fully qualified hostname. Yes, having a nfs/fqdn at REALM key on the client is recommended and necessary in some cases. Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project This e-mail is private and confidential between the sender and the addressee. In the event of misdirection, the recipient is prohibited from using, copying or disseminating it or any information in it. Please notify the above if any misdirection. From jreg2k at gmail.com Sat Sep 27 07:21:27 2014 From: jreg2k at gmail.com (James James) Date: Sat, 27 Sep 2014 09:21:27 +0200 Subject: [Freeipa-users] freeipa-client on Debian Wheezy In-Reply-To: <514753AE-EB70-4497-897F-F80C08192FD8@numeezy.com> References: <6351F8CF-6D73-48B7-89FB-0D243969AEE9@numeezy.com> <20130712173610.GY18587@redhat.com> <77440F51-D592-4248-A0C0-65DA05CF69B8@numeezy.com> <51E39897.5080907@redhat.com> <514753AE-EB70-4497-897F-F80C08192FD8@numeezy.com> Message-ID: Hi Alexandre, Thanks for your effort. I am facing some issues with the numeezy freeipa debian client. 1 ) When I use ipa-client-install I can't specify the ca-cert path and I have to import my CA cert in /etc/pki/nssdb 2 ) When I try to make ipa-client-automount, the rpc.idmapd, rpc.gssd deamons can't be restarted : rpcidmapd failed to restart: Command '/usr/sbin/service rpcidmapd restart ' returned non-zero exit status 1 Failed to configure automatic startup of the rpcidmapd daemon Failed to enable automatic startup of the rpcidmapd daemon: Command '/sbin/chkconfig rpcidmapd on' returned non-zero exit status 1 rpcgssd failed to restart: Command '/usr/sbin/service rpcgssd restart ' returned non-zero exit status 1 Failed to configure automatic startup of the rpcgssd daemon Failed to enable automatic startup of the rpcgssd daemon: Command '/sbin/chkconfig rpcgssd on' returned non-zero exit status 1 Can you help me ? Best. 2013-07-18 19:20 GMT+02:00 Alexandre Ellert : > I've made packages from Debian Wheezy (actually only amd64). The goal is > ti have a full functional and compatible client with Centos/RHEL 6.4 > freeipa server 3.0.0. > Actually join domain, ssh key upload, certificate enrollment and sudo > integration works in my environment. > > If you want to test, just add this to /etc/apt/sources.list : > deb http://apt.numeezy.fr wheezy main > deb-src http://apt.numeezy.fr wheezy main > and import my GPG key : > # wget -qO - http://apt.numeezy.fr/numeezy.asc | sudo apt-key add - > Then, install package named freeipa-client. > You can also download source using : apt-get source freeipa. > > Feel free to contact me if you have any issue using this package. > > PS : I've based my work on package done by Timo Aaltonen for Ubuntu. > Thanks to him for his excellent work ! > > Alexandre > > Le 15 juil. 2013 ? 08:37, Petr Spacek a ?crit : > > > On 12.7.2013 19:57, Alexandre Ellert wrote: > >> Thanks for pointing that bug, compilation succeeded if adding > "X-Python-Version: 2.7" to debian/control file. > >> Now, testing functionality... > >> I can give you some feedback if you want (i'm new here. Is there only > RHEL/Fedora users on this mailing list ?) > > > > This list is not Fedora/RHEL specific. We are glad to hear about ports > to another distributions, please continue! :-) > > > > -- > > Petr^2 Spacek > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexharv074 at gmail.com Mon Sep 29 02:57:37 2014 From: alexharv074 at gmail.com (Alex Harvey) Date: Mon, 29 Sep 2014 12:57:37 +1000 Subject: [Freeipa-users] ipa host-del not authorised In-Reply-To: <5423D526.3040900@redhat.com> References: <5423D526.3040900@redhat.com> Message-ID: Hi all Many thanks for the replies here - As it turned out I just needed to run kinit admin and enter the password, as Net Vent suggested, and that resolved the issue. For that matter, I found I could also simply run su - admin and then run the ipa host-del command and also achieve the same result. On 25 September 2014 18:41, Martin Kosek wrote: > On 09/25/2014 04:11 AM, Alex Harvey wrote: > > Hi all > > > > I'm new to IPA and struggling a bit to automate some tasks. > > > > I am unable to delete hosts from the command line although have no > problem > > doing this using the GUI, e.g. > > > > [root at myipaserver ~]# ipa host-del myhost.example.com > > > > ipa: ERROR: Insufficient access: not allowed to perform this command > > > > I guess I need to somehow pass the admin user's username and password? > > However the man page doesn't seem to provide any option for doing this. > > > > Thanks > > Alex > > Hello Alex, > > I assume you created a non-admin user with some permissions allow deleting > a host. > > This error message is thrown when a virtual operation check fails. This is > raised for example when a user is trying to do unathorized operation with > certificates, like if user having host deletion permission does not also > have > permission to revoke certificates for deleted users. > > Does the privileged user has "Revoke Certificate" permission assigned > through > some privilege/role? > > The mismatch of behavior between CLI and UI is strange. They call the same > code, maybe you run it with different users. > > Also, what is your FreeIPA version? > > Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tompos at martos.bme.hu Mon Sep 29 09:51:47 2014 From: tompos at martos.bme.hu (Tamas Papp) Date: Mon, 29 Sep 2014 11:51:47 +0200 Subject: [Freeipa-users] gravatar image, IM fields In-Reply-To: <54292104.7020901@rtfm.co.hu> References: <54292104.7020901@rtfm.co.hu> Message-ID: <54292BB3.2040801@martos.bme.hu> hi All, Is there a solution to integrate gravatar images and IPA? Something like a field for the gravatar url or actually I am not sure, what the right solution would be. Also is there a solution the add IM details to users, like skype id, hangouts id..etc? 10x tamas From mkosek at redhat.com Mon Sep 29 10:35:52 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 29 Sep 2014 12:35:52 +0200 Subject: [Freeipa-users] gravatar image, IM fields In-Reply-To: <54292BB3.2040801@martos.bme.hu> References: <54292104.7020901@rtfm.co.hu> <54292BB3.2040801@martos.bme.hu> Message-ID: <54293608.60303@redhat.com> On 09/29/2014 11:51 AM, Tamas Papp wrote: > > > hi All, > > Is there a solution to integrate gravatar images and IPA? Something like > a field for the gravatar url or actually I am not sure, what the right > solution would be. > > Also is there a solution the add IM details to users, like skype id, > hangouts id..etc? > > > 10x > tamas > Hello Tamas, For the custom user fields, I think the best way will be to simply write a plugin extending the User object allowing these attribute in new objectClass. You can check an example with "favoriteColorName" in this presentation: http://www.freeipa.org/images/5/5b/FreeIPA33-extending-freeipa.pdf HTH, Martin From mheslin at redhat.com Mon Sep 29 20:17:56 2014 From: mheslin at redhat.com (Mark Heslin) Date: Mon, 29 Sep 2014 16:17:56 -0400 Subject: [Freeipa-users] Services and Keytabs for load-balanced hostnames Message-ID: <5429BE74.6090402@redhat.com> Folks, I'm looking for the best approach to take for configuring IdM clients to access web services (HTTP) with keytabs when a front-end load-balanced hostname is in place. I have a distributed OpenShift Enterprise configuration with three broker hosts (broker1, broker2, broker3) with all three configured as IdM clients. IdM is configured with one server (idm-srv1.example.com), one replica (idm-srv2.example.com); an HTTP service has been created for each broker host: # ipa service-add HTTP/broker1.example.com # ipa service-add HTTP/broker2.example.com # ipa service-add HTTP/broker3.example.com A DNS round-robin hostname called '*broker**.example.com*' has also been configured to distribute broker requests across the three brokers: # ipa dnsrecord-add example.com broker --a-ip-address=10.0.0.11 # ipa dnsrecord-add example.com broker --a-ip-address=10.0.0.12 # ipa dnsrecord-add example.com broker --a-ip-address=10.0.0.13 Effectively, this creates a DNS A record that acts as a pseudo DNS load-balancer. To access the HTTP services, we have been creating keytabs for for the first broker host: # ipa-getkeytab -s idm-srv1.example.com -p HTTP/*broker1*.example.com at EXAMPLE.COM -k /var/www/openshift/broker/httpd/conf.d/http.keytab and copying the keytab over to the other two OpenShift broker hosts. This all works fine but in the event that *broker1* should go down, the other broker hosts will lose access to the web service. Ideally, we would like to have web services use the more generic, "load balanced" hostname (*broker.example.com*) and in turn have the keytabs use this name as well. I tried creating an HTTP service using the "load balanced" hostname (*broker.example.com*) but that appears to fail due to *broker.example.com* not being a valid host within IdM: # ipa service-add HTTP/broker.example.com ipa: ERROR: The host 'broker.example.com' does not exist to add a service to. In the F18 FreeIPA guide it discusses creating a combined keytab file (Section 6.5.4) using ktutil: http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/managing-services.html#Using_the_Same_Service_Principal_for_Multiple_Services but would that still work as intended should a broker host go down? The next section (6.5.5) mentions creating a keytab to create a service principal that can be used across multiple hosts: # ipa-getkeytab -s kdc.example.com -p HTTP/server.example.com -k /etc/httpd/conf/krb5.keytab -e des-cbc-crc Which seems more in-line with my thinking and exactly what we've been doing but again, if I try to do that using the "load balanced" hostname (*broker.example.com*) it fails sicne it's not a valid host within IdM. What is the best method to doing this? Thank you, -m -- Red Hat Reference Architectures Follow Us: https://twitter.com/RedHatRefArch Plus Us: https://plus.google.com/u/0/b/114152126783830728030/ Like Us: https://www.facebook.com/rhrefarch -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Mon Sep 29 20:25:08 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 29 Sep 2014 23:25:08 +0300 Subject: [Freeipa-users] Services and Keytabs for load-balanced hostnames In-Reply-To: <5429BE74.6090402@redhat.com> References: <5429BE74.6090402@redhat.com> Message-ID: <20140929202508.GN11503@redhat.com> On Mon, 29 Sep 2014, Mark Heslin wrote: >Folks, > >I'm looking for the best approach to take for configuring IdM clients >to access web services (HTTP) >with keytabs when a front-end load-balanced hostname is in place. > >I have a distributed OpenShift Enterprise configuration with three >broker hosts (broker1, broker2, broker3) >with all three configured as IdM clients. > >IdM is configured with one server (idm-srv1.example.com), one replica >(idm-srv2.example.com); an HTTP service >has been created for each broker host: > > # ipa service-add HTTP/broker1.example.com > # ipa service-add HTTP/broker2.example.com > # ipa service-add HTTP/broker3.example.com > >A DNS round-robin hostname called '*broker**.example.com*' has also >been configured to distribute broker requests >across the three brokers: > > # ipa dnsrecord-add example.com broker --a-ip-address=10.0.0.11 > # ipa dnsrecord-add example.com broker --a-ip-address=10.0.0.12 > # ipa dnsrecord-add example.com broker --a-ip-address=10.0.0.13 > >Effectively, this creates a DNS A record that acts as a pseudo DNS >load-balancer. > >To access the HTTP services, we have been creating keytabs for for the >first broker host: > > # ipa-getkeytab -s idm-srv1.example.com -p >HTTP/*broker1*.example.com at EXAMPLE.COM > -k >/var/www/openshift/broker/httpd/conf.d/http.keytab > >and copying the keytab over to the other two OpenShift broker hosts. > >This all works fine but in the event that *broker1* should go down, >the other broker hosts will lose access >to the web service. Ideally, we would like to have web services use >the more generic, "load balanced" >hostname (*broker.example.com*) and in turn have the keytabs use this >name as well. > >I tried creating an HTTP service using the "load balanced" hostname >(*broker.example.com*) but that appears to fail >due to *broker.example.com* not being a valid host within IdM: > > # ipa service-add HTTP/broker.example.com > ipa: ERROR: The host 'broker.example.com' does not exist to add a >service to. > >In the F18 FreeIPA guide it discusses creating a combined keytab file >(Section 6.5.4) using ktutil: > >http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/managing-services.html#Using_the_Same_Service_Principal_for_Multiple_Services > >but would that still work as intended should a broker host go down? > >The next section (6.5.5) mentions creating a keytab to create a >service principal that can be used across multiple hosts: > > # ipa-getkeytab -s kdc.example.com -p HTTP/server.example.com -k >/etc/httpd/conf/krb5.keytab -e des-cbc-crc > >Which seems more in-line with my thinking and exactly what we've been >doing but again, if I try to do that >using the "load balanced" hostname (*broker.example.com*) it fails >sicne it's not a valid host within IdM. > >What is the best method to doing this? Make a host named broker.example.com ipa host-add broker.example.com --force --force will make sure to create the host object even if there is no such name in the DNS. Then create services for this host. You'll need to set up your balancer hosts to use the proper service principal instead of allowing them to construct the principal themselves based on the hostname. -- / Alexander Bokovoy From mheslin at redhat.com Mon Sep 29 20:30:05 2014 From: mheslin at redhat.com (Mark Heslin) Date: Mon, 29 Sep 2014 16:30:05 -0400 Subject: [Freeipa-users] Services and Keytabs for load-balanced hostnames In-Reply-To: <20140929202508.GN11503@redhat.com> References: <5429BE74.6090402@redhat.com> <20140929202508.GN11503@redhat.com> Message-ID: <5429C14D.3040000@redhat.com> On 09/29/2014 04:25 PM, Alexander Bokovoy wrote: > On Mon, 29 Sep 2014, Mark Heslin wrote: >> Folks, >> >> I'm looking for the best approach to take for configuring IdM clients >> to access web services (HTTP) >> with keytabs when a front-end load-balanced hostname is in place. >> >> I have a distributed OpenShift Enterprise configuration with three >> broker hosts (broker1, broker2, broker3) >> with all three configured as IdM clients. >> >> IdM is configured with one server (idm-srv1.example.com), one replica >> (idm-srv2.example.com); an HTTP service >> has been created for each broker host: >> >> # ipa service-add HTTP/broker1.example.com >> # ipa service-add HTTP/broker2.example.com >> # ipa service-add HTTP/broker3.example.com >> >> A DNS round-robin hostname called '*broker**.example.com*' has also >> been configured to distribute broker requests >> across the three brokers: >> >> # ipa dnsrecord-add example.com broker --a-ip-address=10.0.0.11 >> # ipa dnsrecord-add example.com broker --a-ip-address=10.0.0.12 >> # ipa dnsrecord-add example.com broker --a-ip-address=10.0.0.13 >> >> Effectively, this creates a DNS A record that acts as a pseudo DNS >> load-balancer. >> >> To access the HTTP services, we have been creating keytabs for for >> the first broker host: >> >> # ipa-getkeytab -s idm-srv1.example.com -p >> HTTP/*broker1*.example.com at EXAMPLE.COM >> -k >> /var/www/openshift/broker/httpd/conf.d/http.keytab >> >> and copying the keytab over to the other two OpenShift broker hosts. >> >> This all works fine but in the event that *broker1* should go down, >> the other broker hosts will lose access >> to the web service. Ideally, we would like to have web services use >> the more generic, "load balanced" >> hostname (*broker.example.com*) and in turn have the keytabs use this >> name as well. >> >> I tried creating an HTTP service using the "load balanced" hostname >> (*broker.example.com*) but that appears to fail >> due to *broker.example.com* not being a valid host within IdM: >> >> # ipa service-add HTTP/broker.example.com >> ipa: ERROR: The host 'broker.example.com' does not exist to add a >> service to. >> >> In the F18 FreeIPA guide it discusses creating a combined keytab file >> (Section 6.5.4) using ktutil: >> >> http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/managing-services.html#Using_the_Same_Service_Principal_for_Multiple_Services >> >> >> but would that still work as intended should a broker host go down? >> >> The next section (6.5.5) mentions creating a keytab to create a >> service principal that can be used across multiple hosts: >> >> # ipa-getkeytab -s kdc.example.com -p HTTP/server.example.com -k >> /etc/httpd/conf/krb5.keytab -e des-cbc-crc >> >> Which seems more in-line with my thinking and exactly what we've been >> doing but again, if I try to do that >> using the "load balanced" hostname (*broker.example.com*) it fails >> sicne it's not a valid host within IdM. >> >> What is the best method to doing this? > Make a host named broker.example.com > ipa host-add broker.example.com --force > > --force will make sure to create the host object even if there is no > such name in the DNS. > > Then create services for this host. Nice - just what we were looking for! > > You'll need to set up your balancer hosts to use the proper service > principal instead of allowing them to construct the principal themselves > based on the hostname. > Thank you Alexander :-) -m -- Red Hat Reference Architectures Follow Us: https://twitter.com/RedHatRefArch Plus Us: https://plus.google.com/u/0/b/114152126783830728030/ Like Us: https://www.facebook.com/rhrefarch From simo at redhat.com Mon Sep 29 21:12:06 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 29 Sep 2014 17:12:06 -0400 Subject: [Freeipa-users] Services and Keytabs for load-balanced hostnames In-Reply-To: <20140929202508.GN11503@redhat.com> References: <5429BE74.6090402@redhat.com> <20140929202508.GN11503@redhat.com> Message-ID: <20140929171206.3eb8e5f7@willson.usersys.redhat.com> On Mon, 29 Sep 2014 23:25:08 +0300 Alexander Bokovoy wrote: > On Mon, 29 Sep 2014, Mark Heslin wrote: > >Folks, > > > >I'm looking for the best approach to take for configuring IdM > >clients to access web services (HTTP) > >with keytabs when a front-end load-balanced hostname is in place. > > > >I have a distributed OpenShift Enterprise configuration with three > >broker hosts (broker1, broker2, broker3) > >with all three configured as IdM clients. > > > >IdM is configured with one server (idm-srv1.example.com), one > >replica (idm-srv2.example.com); an HTTP service > >has been created for each broker host: > > > > # ipa service-add HTTP/broker1.example.com > > # ipa service-add HTTP/broker2.example.com > > # ipa service-add HTTP/broker3.example.com > > > >A DNS round-robin hostname called '*broker**.example.com*' has also > >been configured to distribute broker requests > >across the three brokers: > > > > # ipa dnsrecord-add example.com broker --a-ip-address=10.0.0.11 > > # ipa dnsrecord-add example.com broker --a-ip-address=10.0.0.12 > > # ipa dnsrecord-add example.com broker --a-ip-address=10.0.0.13 > > > >Effectively, this creates a DNS A record that acts as a pseudo DNS > >load-balancer. > > > >To access the HTTP services, we have been creating keytabs for for > >the first broker host: > > > > # ipa-getkeytab -s idm-srv1.example.com -p > >HTTP/*broker1*.example.com at EXAMPLE.COM > > -k > >/var/www/openshift/broker/httpd/conf.d/http.keytab > > > >and copying the keytab over to the other two OpenShift broker hosts. > > > >This all works fine but in the event that *broker1* should go down, > >the other broker hosts will lose access > >to the web service. Ideally, we would like to have web services use > >the more generic, "load balanced" > >hostname (*broker.example.com*) and in turn have the keytabs use > >this name as well. > > > >I tried creating an HTTP service using the "load balanced" hostname > >(*broker.example.com*) but that appears to fail > >due to *broker.example.com* not being a valid host within IdM: > > > > # ipa service-add HTTP/broker.example.com > > ipa: ERROR: The host 'broker.example.com' does not exist to add a > >service to. > > > >In the F18 FreeIPA guide it discusses creating a combined keytab > >file (Section 6.5.4) using ktutil: > > > >http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/managing-services.html#Using_the_Same_Service_Principal_for_Multiple_Services > > > >but would that still work as intended should a broker host go down? > > > >The next section (6.5.5) mentions creating a keytab to create a > >service principal that can be used across multiple hosts: > > > > # ipa-getkeytab -s kdc.example.com -p HTTP/server.example.com -k > >/etc/httpd/conf/krb5.keytab -e des-cbc-crc > > > >Which seems more in-line with my thinking and exactly what we've > >been doing but again, if I try to do that > >using the "load balanced" hostname (*broker.example.com*) it fails > >sicne it's not a valid host within IdM. > > > >What is the best method to doing this? > Make a host named broker.example.com > ipa host-add broker.example.com --force > > --force will make sure to create the host object even if there is no > such name in the DNS. > > Then create services for this host. > > You'll need to set up your balancer hosts to use the proper service > principal instead of allowing them to construct the principal > themselves based on the hostname. Even better tell them to not assume any name if the server name is NULL GSSAPI will try every key in the keytab. YUou can even force that behavior with a krb5 config hack even if the app insist setting a name by adding "ignore_acceptor_hostname true" in [libdefaults] Simo. -- Simo Sorce * Red Hat, Inc * New York From genadipost at gmail.com Mon Sep 29 21:16:22 2014 From: genadipost at gmail.com (Genadi Postrilko) Date: Mon, 29 Sep 2014 23:16:22 +0200 Subject: [Freeipa-users] Firewall rules for AD TRUST Message-ID: Hello all again. I am trying to make sense of the documentation on firewall rules for in IPA/AD Trust relationship. The official RHEL 7 Windows Integration Guide states in section - 5.2.6 Firewalls And Ports, that: *"For a trust relationship, the Active Directory server and IdM server must have almost all of the required system ports open that are required for an IdM server installation, with the exception of the LDAP ports."* So the following ports should be open (on the side of the IPA) : 80, 443, 88, 464, 53 - TCP 88, 464, 53, 123 - UDP And also : *"The IdM backend LDAP server must not be reachable by the Active Directory domain controller. The associated ports ? 389 and 636 ? on the IdM server host must be shut down for the Active Directory domain controller."* https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Windows_Integration_Guide/index.html#trust-requirements After searching the mail archives i found the next post: https://www.redhat.com/archives/freeipa-users/2014-August/msg00032.html *"LDAP over UDP is required for trusts as connectionless LDAP (CLDAP) is part of discovery protocol that AD machines expect to work. Blocking TCP/389 and TCP/636 between AD DCs and IPA servers should not hurt."* But the HowTo documentation (on trust) in FreeIPA site states the following: *"Previously we recommended that you should make sure that IPA LDAP server is not reachable by AD DC by closing down TCP ports 389 and 636 for AD DC. Our current tests lead to the assumption that this is not necessary anymore."* http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Firewall_configuration Also after the ipa-adtrust-install script completes it outputs the following message: *Setup complete* *You must make sure these network ports are open: * *TCP Ports: * ** 138: netbios-dgm * ** 139: netbios-ssn * ** 445: microsoft-ds * *UDP Ports: * ** 138: netbios-dgm * ** 139: netbios-ssn * 389: (C)LDAP * 445: microsoft-ds * Those ports need to be opened between the AD and IPA server? Finally i would like to understand if all the ports that should to be opened on the side of the IPA server, also should be opened at the AD on the both directions (Incoming, outgoing)? I can see that the firewall configuration for AD not yet documented in the HowTo guide. Thanks, Genadi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Tue Sep 30 07:01:56 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 30 Sep 2014 09:01:56 +0200 Subject: [Freeipa-users] Services and Keytabs for load-balanced hostnames In-Reply-To: <20140929171206.3eb8e5f7@willson.usersys.redhat.com> References: <5429BE74.6090402@redhat.com> <20140929202508.GN11503@redhat.com> <20140929171206.3eb8e5f7@willson.usersys.redhat.com> Message-ID: <542A5564.4070205@redhat.com> On 29.9.2014 23:12, Simo Sorce wrote: > On Mon, 29 Sep 2014 23:25:08 +0300 > Alexander Bokovoy wrote: > >> On Mon, 29 Sep 2014, Mark Heslin wrote: >>> Folks, >>> >>> I'm looking for the best approach to take for configuring IdM >>> clients to access web services (HTTP) >>> with keytabs when a front-end load-balanced hostname is in place. >>> >>> I have a distributed OpenShift Enterprise configuration with three >>> broker hosts (broker1, broker2, broker3) >>> with all three configured as IdM clients. >>> >>> IdM is configured with one server (idm-srv1.example.com), one >>> replica (idm-srv2.example.com); an HTTP service >>> has been created for each broker host: >>> >>> # ipa service-add HTTP/broker1.example.com >>> # ipa service-add HTTP/broker2.example.com >>> # ipa service-add HTTP/broker3.example.com >>> >>> A DNS round-robin hostname called '*broker**.example.com*' has also >>> been configured to distribute broker requests >>> across the three brokers: >>> >>> # ipa dnsrecord-add example.com broker --a-ip-address=10.0.0.11 >>> # ipa dnsrecord-add example.com broker --a-ip-address=10.0.0.12 >>> # ipa dnsrecord-add example.com broker --a-ip-address=10.0.0.13 >>> >>> Effectively, this creates a DNS A record that acts as a pseudo DNS >>> load-balancer. >>> >>> To access the HTTP services, we have been creating keytabs for for >>> the first broker host: >>> >>> # ipa-getkeytab -s idm-srv1.example.com -p >>> HTTP/*broker1*.example.com at EXAMPLE.COM >>> -k >>> /var/www/openshift/broker/httpd/conf.d/http.keytab >>> >>> and copying the keytab over to the other two OpenShift broker hosts. >>> >>> This all works fine but in the event that *broker1* should go down, >>> the other broker hosts will lose access >>> to the web service. Ideally, we would like to have web services use >>> the more generic, "load balanced" >>> hostname (*broker.example.com*) and in turn have the keytabs use >>> this name as well. >>> >>> I tried creating an HTTP service using the "load balanced" hostname >>> (*broker.example.com*) but that appears to fail >>> due to *broker.example.com* not being a valid host within IdM: >>> >>> # ipa service-add HTTP/broker.example.com >>> ipa: ERROR: The host 'broker.example.com' does not exist to add a >>> service to. >>> >>> In the F18 FreeIPA guide it discusses creating a combined keytab >>> file (Section 6.5.4) using ktutil: >>> >>> http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/managing-services.html#Using_the_Same_Service_Principal_for_Multiple_Services >>> >>> but would that still work as intended should a broker host go down? >>> >>> The next section (6.5.5) mentions creating a keytab to create a >>> service principal that can be used across multiple hosts: >>> >>> # ipa-getkeytab -s kdc.example.com -p HTTP/server.example.com -k >>> /etc/httpd/conf/krb5.keytab -e des-cbc-crc >>> >>> Which seems more in-line with my thinking and exactly what we've >>> been doing but again, if I try to do that >>> using the "load balanced" hostname (*broker.example.com*) it fails >>> sicne it's not a valid host within IdM. >>> >>> What is the best method to doing this? >> Make a host named broker.example.com >> ipa host-add broker.example.com --force >> >> --force will make sure to create the host object even if there is no >> such name in the DNS. >> >> Then create services for this host. >> >> You'll need to set up your balancer hosts to use the proper service >> principal instead of allowing them to construct the principal >> themselves based on the hostname. > > Even better tell them to not assume any name if the server name is NULL > GSSAPI will try every key in the keytab. YUou can even force that > behavior with a krb5 config hack even if the app insist setting a name > by adding "ignore_acceptor_hostname true" in [libdefaults] I consider this as a 'workaround'. Even better option is to teach your client application to use DNS SRV records instead of plain A records. SRV records allow you to do more fancy things like non-equal load balancing etc. -- Petr^2 Spacek From tompos at martos.bme.hu Tue Sep 30 08:59:29 2014 From: tompos at martos.bme.hu (Tamas Papp) Date: Tue, 30 Sep 2014 10:59:29 +0200 Subject: [Freeipa-users] gravatar image, IM fields In-Reply-To: <54293608.60303@redhat.com> References: <54292104.7020901@rtfm.co.hu> <54292BB3.2040801@martos.bme.hu> <54293608.60303@redhat.com> Message-ID: <542A70F1.5080908@martos.bme.hu> On 09/29/2014 12:35 PM, Martin Kosek wrote: > On 09/29/2014 11:51 AM, Tamas Papp wrote: >> >> hi All, >> >> Is there a solution to integrate gravatar images and IPA? Something like >> a field for the gravatar url or actually I am not sure, what the right >> solution would be. >> >> Also is there a solution the add IM details to users, like skype id, >> hangouts id..etc? >> >> >> 10x >> tamas >> > Hello Tamas, > > For the custom user fields, I think the best way will be to simply write a > plugin extending the User object allowing these attribute in new objectClass. > > You can check an example with "favoriteColorName" in this presentation: > > http://www.freeipa.org/images/5/5b/FreeIPA33-extending-freeipa.pdf Thanks Martin. Is there any plan to officially integrate such a fields? Just out of curiosity any plan to add fields easier (from gui or with ipa command)? Can a plugin make a server future upgrade broken? Thanks, tamas From janellenicole80 at gmail.com Tue Sep 30 13:19:37 2014 From: janellenicole80 at gmail.com (Janelle) Date: Tue, 30 Sep 2014 06:19:37 -0700 Subject: [Freeipa-users] Fedora 21 and 4.0.3 Message-ID: <542AADE9.8040906@gmail.com> Hi, I'm new to IPA - and was trying out the newest version of 4.0.3 with Fedora Server 21 testing -- it continues to die during the install at: Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds [1/26]: creating certificate server user [2/26]: configuring certificate server instance [3/26]: stopping certificate server instance to update CS.cfg [4/26]: backing up CS.cfg [5/26]: disabling nonces [6/26]: set up CRL publishing [7/26]: starting certificate server instance <--- consistently dies at step 7 and checking install log show: 2014-09-29T21:14:30Z DEBUG wait_for_open_ports: localhost [8080, 8443] timeout 300 2014-09-29T21:19:31Z DEBUG File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 639, in run_script return_value = main_function() File "/usr/sbin/ipa-server-install", line 1095, in main dm_password, subject_base=options.subject) File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 484, in configure_instance self.start_creation(runtime=210) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 367, in start_creation method() File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 490, in __start self.start() File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 282, in start self.service.start(instance_name, capture_output=capture_output, wait=wait) File "/usr/lib/python2.7/site-packages/ipaplatform/services.py", line 193, in start instance_name, capture_output=capture_output, wait=wait) File "/usr/lib/python2.7/site-packages/ipaplatform/base/services.py", line 262, in start self.wait_for_open_ports(self.service_instance(instance_name)) File "/usr/lib/python2.7/site-packages/ipaplatform/base/services.py", line 228, in wait_for_open_ports self.api.env.startup_timeout) File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 1153, in wait_for_open_ports raise socket.timeout() Would anyone have any ideas on finding out what is going on here? I see the timeout of 5 minutes - but why waiting on ports that are not part of IPA? Thank you Janelle -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpazdziora at redhat.com Tue Sep 30 13:32:11 2014 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Tue, 30 Sep 2014 15:32:11 +0200 Subject: [Freeipa-users] Fedora 21 and 4.0.3 In-Reply-To: <542AADE9.8040906@gmail.com> References: <542AADE9.8040906@gmail.com> Message-ID: <20140930133211.GC12773@redhat.com> On Tue, Sep 30, 2014 at 06:19:37AM -0700, Janelle wrote: > Hi, > > I'm new to IPA - and was trying out the newest version of 4.0.3 with Fedora > Server 21 testing -- it continues to die during the install at: > > Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 > seconds > [1/26]: creating certificate server user > [2/26]: configuring certificate server instance > [3/26]: stopping certificate server instance to update CS.cfg > [4/26]: backing up CS.cfg > [5/26]: disabling nonces > [6/26]: set up CRL publishing > [7/26]: starting certificate server instance <--- consistently dies at > step 7 > > and checking install log show: > > 2014-09-29T21:14:30Z DEBUG wait_for_open_ports: localhost [8080, 8443] > timeout 300 [...] > Would anyone have any ideas on finding out what is going on here? I see the > timeout of 5 minutes - but why waiting on ports that are not part of IPA? I strongly suspect you are hitting https://bugzilla.redhat.com/show_bug.cgi?id=1117673 Is there a particular reason why you want to go with unreleased Fedora? -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From rcritten at redhat.com Tue Sep 30 13:49:11 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 30 Sep 2014 09:49:11 -0400 Subject: [Freeipa-users] Fedora 21 and 4.0.3 In-Reply-To: <20140930133211.GC12773@redhat.com> References: <542AADE9.8040906@gmail.com> <20140930133211.GC12773@redhat.com> Message-ID: <542AB4D7.1000406@redhat.com> Jan Pazdziora wrote: > On Tue, Sep 30, 2014 at 06:19:37AM -0700, Janelle wrote: >> Hi, >> >> I'm new to IPA - and was trying out the newest version of 4.0.3 with Fedora >> Server 21 testing -- it continues to die during the install at: >> >> Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 >> seconds >> [1/26]: creating certificate server user >> [2/26]: configuring certificate server instance >> [3/26]: stopping certificate server instance to update CS.cfg >> [4/26]: backing up CS.cfg >> [5/26]: disabling nonces >> [6/26]: set up CRL publishing >> [7/26]: starting certificate server instance <--- consistently dies at >> step 7 >> >> and checking install log show: >> >> 2014-09-29T21:14:30Z DEBUG wait_for_open_ports: localhost [8080, 8443] >> timeout 300 > > [...] > >> Would anyone have any ideas on finding out what is going on here? I see the >> timeout of 5 minutes - but why waiting on ports that are not part of IPA? But it *is* part of IPA, hence we wait for it to come up and fail if it doesn't. The installer would just blow up later without dogtag running. > I strongly suspect you are hitting > > https://bugzilla.redhat.com/show_bug.cgi?id=1117673 > > Is there a particular reason why you want to go with unreleased > Fedora? > Probably because it's the only place one can (easily) test 4.0.3 right now due to missing dependencies. rob From abokovoy at redhat.com Tue Sep 30 13:56:42 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 30 Sep 2014 16:56:42 +0300 Subject: [Freeipa-users] Fedora 21 and 4.0.3 In-Reply-To: <542AADE9.8040906@gmail.com> References: <542AADE9.8040906@gmail.com> Message-ID: <20140930135641.GC4909@redhat.com> On Tue, 30 Sep 2014, Janelle wrote: >Hi, > >I'm new to IPA - and was trying out the newest version of 4.0.3 with >Fedora Server 21 testing -- it continues to die during the install at: > >Configuring certificate server (pki-tomcatd): Estimated time 3 minutes >30 seconds > [1/26]: creating certificate server user > [2/26]: configuring certificate server instance > [3/26]: stopping certificate server instance to update CS.cfg > [4/26]: backing up CS.cfg > [5/26]: disabling nonces > [6/26]: set up CRL publishing > [7/26]: starting certificate server instance <--- consistently dies >at step 7 You need to update selinux-policy to the latest one. https://admin.fedoraproject.org/updates/selinux-policy-3.13.1-84.fc21 -- / Alexander Bokovoy From abokovoy at redhat.com Tue Sep 30 13:59:46 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 30 Sep 2014 16:59:46 +0300 Subject: [Freeipa-users] Fedora 21 and 4.0.3 In-Reply-To: <542AB4D7.1000406@redhat.com> References: <542AADE9.8040906@gmail.com> <20140930133211.GC12773@redhat.com> <542AB4D7.1000406@redhat.com> Message-ID: <20140930135946.GD4909@redhat.com> On Tue, 30 Sep 2014, Rob Crittenden wrote: >Jan Pazdziora wrote: >> On Tue, Sep 30, 2014 at 06:19:37AM -0700, Janelle wrote: >>> Hi, >>> >>> I'm new to IPA - and was trying out the newest version of 4.0.3 with Fedora >>> Server 21 testing -- it continues to die during the install at: >>> >>> Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 >>> seconds >>> [1/26]: creating certificate server user >>> [2/26]: configuring certificate server instance >>> [3/26]: stopping certificate server instance to update CS.cfg >>> [4/26]: backing up CS.cfg >>> [5/26]: disabling nonces >>> [6/26]: set up CRL publishing >>> [7/26]: starting certificate server instance <--- consistently dies at >>> step 7 >>> >>> and checking install log show: >>> >>> 2014-09-29T21:14:30Z DEBUG wait_for_open_ports: localhost [8080, 8443] >>> timeout 300 >> >> [...] >> >>> Would anyone have any ideas on finding out what is going on here? I see the >>> timeout of 5 minutes - but why waiting on ports that are not part of IPA? > >But it *is* part of IPA, hence we wait for it to come up and fail if it >doesn't. The installer would just blow up later without dogtag running. Dogtag messes up with SELinux labels when copying CS.cfg to back it up, then SELinux AVC prevents it to do so, then a failure to copy causes Dogtag to complain but the code in /usr/share/pki/scripts/operations is syntactically incorrect and shell breaks its execution. This all results in dogtag not being able to start. I've filed a bug for the syntax error for pki-server and SELinux policy fix is on its way to updates-testing. With that fix (https://admin.fedoraproject.org/updates/selinux-policy-3.13.1-84.fc21) you can get over the issue and never trigger the syntax error in the shell script. -- / Alexander Bokovoy From janellenicole80 at gmail.com Tue Sep 30 15:42:16 2014 From: janellenicole80 at gmail.com (Janelle) Date: Tue, 30 Sep 2014 08:42:16 -0700 Subject: [Freeipa-users] Fedora 21 and 4.0.3 In-Reply-To: <20140930135641.GC4909@redhat.com> References: <542AADE9.8040906@gmail.com> <20140930135641.GC4909@redhat.com> Message-ID: <542ACF58.8090504@gmail.com> Hi again, Ok, so that fixed the issues with Fedora - and 4.0.3 is working fine. A related question - would the COPR repo have 4.0.3 for Fedora 20? Maybe that would be the way to go for more solid testing of supported IPA than running it on Alpha of Fedora? Your thoughts/suggestions? Janelle On 9/30/14 6:56 AM, Alexander Bokovoy wrote: > On Tue, 30 Sep 2014, Janelle wrote: >> Hi, >> >> I'm new to IPA - and was trying out the newest version of 4.0.3 with >> Fedora Server 21 testing -- it continues to die during the install at: >> >> Configuring certificate server (pki-tomcatd): Estimated time 3 >> minutes 30 seconds >> [1/26]: creating certificate server user >> [2/26]: configuring certificate server instance >> [3/26]: stopping certificate server instance to update CS.cfg >> [4/26]: backing up CS.cfg >> [5/26]: disabling nonces >> [6/26]: set up CRL publishing >> [7/26]: starting certificate server instance <--- consistently dies >> at step 7 > You need to update selinux-policy to the latest one. > https://admin.fedoraproject.org/updates/selinux-policy-3.13.1-84.fc21 > From pspacek at redhat.com Tue Sep 30 16:16:23 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 30 Sep 2014 18:16:23 +0200 Subject: [Freeipa-users] Fedora 21 and 4.0.3 In-Reply-To: <542ACF58.8090504@gmail.com> References: <542AADE9.8040906@gmail.com> <20140930135641.GC4909@redhat.com> <542ACF58.8090504@gmail.com> Message-ID: <542AD757.4040603@redhat.com> On 30.9.2014 17:42, Janelle wrote: > Hi again, > > Ok, so that fixed the issues with Fedora - and 4.0.3 is working fine. A > related question - would the COPR repo have 4.0.3 for Fedora 20? Maybe that > would be the way to go for more solid testing of supported IPA than running it > on Alpha of Fedora? > > Your thoughts/suggestions? Feel free to use https://copr.fedoraproject.org/coprs/mkosek/freeipa/ Have a nice day! -- Petr^2 Spacek From dpal at redhat.com Tue Sep 30 18:00:11 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 30 Sep 2014 14:00:11 -0400 Subject: [Freeipa-users] gravatar image, IM fields In-Reply-To: <542A70F1.5080908@martos.bme.hu> References: <54292104.7020901@rtfm.co.hu> <54292BB3.2040801@martos.bme.hu> <54293608.60303@redhat.com> <542A70F1.5080908@martos.bme.hu> Message-ID: <542AEFAB.4080508@redhat.com> On 09/30/2014 04:59 AM, Tamas Papp wrote: > > On 09/29/2014 12:35 PM, Martin Kosek wrote: >> On 09/29/2014 11:51 AM, Tamas Papp wrote: >>> >>> hi All, >>> >>> Is there a solution to integrate gravatar images and IPA? Something >>> like >>> a field for the gravatar url or actually I am not sure, what the right >>> solution would be. >>> >>> Also is there a solution the add IM details to users, like skype id, >>> hangouts id..etc? >>> >>> >>> 10x >>> tamas >>> >> Hello Tamas, >> >> For the custom user fields, I think the best way will be to simply >> write a >> plugin extending the User object allowing these attribute in new >> objectClass. >> >> You can check an example with "favoriteColorName" in this presentation: >> >> http://www.freeipa.org/images/5/5b/FreeIPA33-extending-freeipa.pdf > > Thanks Martin. > Is there any plan to officially integrate such a fields? > > Just out of curiosity any plan to add fields easier (from gui or with > ipa command)? > > Can a plugin make a server future upgrade broken? > > > Thanks, > tamas > I think if you contribute the patch back we will be able to include it into the project. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc.