From sbingram at gmail.com Thu Nov 1 05:07:31 2012 From: sbingram at gmail.com (Stephen Ingram) Date: Wed, 31 Oct 2012 22:07:31 -0700 Subject: [Freeipa-users] Getting virtual aliases and domains via freeipa with Postfix In-Reply-To: References: Message-ID: On Wed, Oct 31, 2012 at 6:25 PM, Peter Brown wrote: > On 1 November 2012 08:20, Stephen Ingram wrote: >> >> On Tue, Oct 30, 2012 at 6:34 PM, Peter Brown wrote: >> > Hi everyone, >> > >> > I have been trying to work out how to achieve this. >> > I have freeipa 3.0.0 setup on a Fedora 18 server and I have postfix and >> > dovecot on my new mail server authenticating against Freeipa. >> > One last thing I would love to do it pull down the virtual users and >> > aliases >> > for the domains my mailserver will be serving from freeipa. >> > Is this possible? >> > Is this all automatic due to sssd looking up the user details in the ds? >> > Does it do the same for domains and email aliases or will I need extra >> > lookups to achieve this. >> >> I've recently built an entire mail system around FreeIPA and it works >> great. There are two parts to be concerned with: >> >> 1. Authentication - With Postfix, this is handled by saslauthd which >> can authenticate against Kerberos (using or not using sssd). I used >> Cyrus-IMAP for the mailstore which also uses saslauthd. Doveccot has >> it's own sasl built in which can authenticate against Kerberos or >> LDAP, thus it should work with IPA. > > > I have dovecot authing against freeipa (via pam)and I setup a sasl auth > instance in dovecot and have postfix authing against that. > I figured why setup another sasl auth daemon when dovecot can do it for me > so they effectively use the same authentication source. > >> 2. Configuration - With Postfix, you can set all different areas (e.g. >> virtual, aliases, etc.) to use LDAP lookup of configuration >> information. You are typically searching for the email address (mail >> attribute in IPA) and your search will generally return the userid >> (uid attribute) of where the mail is to be stored. I don't believe >> that Dovecot or Cyrus-IMAP have any way of maintaining any >> configuration in LDAP so you generally have to setup mailboxes and >> authorization information by hand using their tools. > > > I have most of that worked out but getting delivery addresses for domains > that aren't the base is proving tricky. > It's looking like I will need to add some extra schemas to the ds so i can > add the delivery domain to each user and somehow use that to construct the > delivery address. > I am not sure I can do that though. I didn't really have to add anything except for one extra attribute. You can group your users into user groups representing the domains they belong to such that Postfix can query whether or not to accept for a domain or not. I added mailAlternateAddress for aliases rather than user multi-value attribute mail so I can have a "master" email address for each user. It was easy to do with the existing schema (mailRecipient objectclass). BTW if you haven't already figured it out, postmap -q is your friend when setting up your LDAP config in Postfix. Just keep adjusting everything until you get the answer you (and Postfix) expect. > I am half tempted to add the extra components of 389-ds and see it that will > let me do what I need. > > On a side note the freeipa lads seem to be working out how to add > multitenancy support so it will be capable of serving multiple separate > Kerberos principals. > That would help a lot but I need to cobble something together now. Yes, if you want unique uid's within each domain you'll have to wait for that. I gave up on that notion and simply require unique uids for every user regardless of domain and deliver to single domain style mail store setup. Steve From rendhalver at gmail.com Thu Nov 1 05:21:35 2012 From: rendhalver at gmail.com (Peter Brown) Date: Thu, 1 Nov 2012 15:21:35 +1000 Subject: [Freeipa-users] Getting virtual aliases and domains via freeipa with Postfix In-Reply-To: References: Message-ID: On 1 November 2012 15:07, Stephen Ingram wrote: > On Wed, Oct 31, 2012 at 6:25 PM, Peter Brown wrote: > > On 1 November 2012 08:20, Stephen Ingram wrote: > >> > >> On Tue, Oct 30, 2012 at 6:34 PM, Peter Brown > wrote: > >> > Hi everyone, > >> > > >> > I have been trying to work out how to achieve this. > >> > I have freeipa 3.0.0 setup on a Fedora 18 server and I have postfix > and > >> > dovecot on my new mail server authenticating against Freeipa. > >> > One last thing I would love to do it pull down the virtual users and > >> > aliases > >> > for the domains my mailserver will be serving from freeipa. > >> > Is this possible? > >> > Is this all automatic due to sssd looking up the user details in the > ds? > >> > Does it do the same for domains and email aliases or will I need extra > >> > lookups to achieve this. > >> > >> I've recently built an entire mail system around FreeIPA and it works > >> great. There are two parts to be concerned with: > >> > >> 1. Authentication - With Postfix, this is handled by saslauthd which > >> can authenticate against Kerberos (using or not using sssd). I used > >> Cyrus-IMAP for the mailstore which also uses saslauthd. Doveccot has > >> it's own sasl built in which can authenticate against Kerberos or > >> LDAP, thus it should work with IPA. > > > > > > I have dovecot authing against freeipa (via pam)and I setup a sasl auth > > instance in dovecot and have postfix authing against that. > > I figured why setup another sasl auth daemon when dovecot can do it for > me > > so they effectively use the same authentication source. > > > >> 2. Configuration - With Postfix, you can set all different areas (e.g. > >> virtual, aliases, etc.) to use LDAP lookup of configuration > >> information. You are typically searching for the email address (mail > >> attribute in IPA) and your search will generally return the userid > >> (uid attribute) of where the mail is to be stored. I don't believe > >> that Dovecot or Cyrus-IMAP have any way of maintaining any > >> configuration in LDAP so you generally have to setup mailboxes and > >> authorization information by hand using their tools. > > > > > > I have most of that worked out but getting delivery addresses for domains > > that aren't the base is proving tricky. > > It's looking like I will need to add some extra schemas to the ds so i > can > > add the delivery domain to each user and somehow use that to construct > the > > delivery address. > > I am not sure I can do that though. > > I didn't really have to add anything except for one extra attribute. > You can group your users into user groups representing the domains > they belong to such that Postfix can query whether or not to accept > for a domain or not. I added mailAlternateAddress for aliases rather > than user multi-value attribute mail so I can have a "master" email > address for each user. It was easy to do with the existing schema > (mailRecipient objectclass). BTW if you haven't already figured it > out, postmap -q is your friend when setting up your LDAP config in > Postfix. Just keep adjusting everything until you get the answer you > (and Postfix) expect. > I discovered that attribute when I was digging around in the ldif files and I was just wondering why they didn't use that for setting aliases. It would certainly make my ldap queries for postfix a lot simpler. I added the mailRecipient class to the defaults for users and tried to use the ipa user-mod --setattr=mailAlternateAddress= and it is telling me ipa: ERROR: attribute "mailAlternateAddress" not allowed I have also trying to set a few other non standard attributes that seem to be in the default schemas already and they all give me the same error. Am I missing something? > I am half tempted to add the extra components of 389-ds and see it that > will > > let me do what I need. > > > > On a side note the freeipa lads seem to be working out how to add > > multitenancy support so it will be capable of serving multiple separate > > Kerberos principals. > > That would help a lot but I need to cobble something together now. > > Yes, if you want unique uid's within each domain you'll have to wait > for that. I gave up on that notion and simply require unique uids for > every user regardless of domain and deliver to single domain style > mail store setup. > yeah that's tempting but I need to have separate domains. > Steve > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbingram at gmail.com Thu Nov 1 05:35:56 2012 From: sbingram at gmail.com (Stephen Ingram) Date: Wed, 31 Oct 2012 22:35:56 -0700 Subject: [Freeipa-users] Getting virtual aliases and domains via freeipa with Postfix In-Reply-To: References: Message-ID: On Wed, Oct 31, 2012 at 10:21 PM, Peter Brown wrote: > On 1 November 2012 15:07, Stephen Ingram wrote: >> >> On Wed, Oct 31, 2012 at 6:25 PM, Peter Brown wrote: >> > On 1 November 2012 08:20, Stephen Ingram wrote: >> >> >> >> On Tue, Oct 30, 2012 at 6:34 PM, Peter Brown >> >> wrote: >> >> > Hi everyone, >> >> > >> >> > I have been trying to work out how to achieve this. >> >> > I have freeipa 3.0.0 setup on a Fedora 18 server and I have postfix >> >> > and >> >> > dovecot on my new mail server authenticating against Freeipa. >> >> > One last thing I would love to do it pull down the virtual users and >> >> > aliases >> >> > for the domains my mailserver will be serving from freeipa. >> >> > Is this possible? >> >> > Is this all automatic due to sssd looking up the user details in the >> >> > ds? >> >> > Does it do the same for domains and email aliases or will I need >> >> > extra >> >> > lookups to achieve this. >> >> >> >> I've recently built an entire mail system around FreeIPA and it works >> >> great. There are two parts to be concerned with: >> >> >> >> 1. Authentication - With Postfix, this is handled by saslauthd which >> >> can authenticate against Kerberos (using or not using sssd). I used >> >> Cyrus-IMAP for the mailstore which also uses saslauthd. Doveccot has >> >> it's own sasl built in which can authenticate against Kerberos or >> >> LDAP, thus it should work with IPA. >> > >> > >> > I have dovecot authing against freeipa (via pam)and I setup a sasl auth >> > instance in dovecot and have postfix authing against that. >> > I figured why setup another sasl auth daemon when dovecot can do it for >> > me >> > so they effectively use the same authentication source. >> > >> >> 2. Configuration - With Postfix, you can set all different areas (e.g. >> >> virtual, aliases, etc.) to use LDAP lookup of configuration >> >> information. You are typically searching for the email address (mail >> >> attribute in IPA) and your search will generally return the userid >> >> (uid attribute) of where the mail is to be stored. I don't believe >> >> that Dovecot or Cyrus-IMAP have any way of maintaining any >> >> configuration in LDAP so you generally have to setup mailboxes and >> >> authorization information by hand using their tools. >> > >> > >> > I have most of that worked out but getting delivery addresses for >> > domains >> > that aren't the base is proving tricky. >> > It's looking like I will need to add some extra schemas to the ds so i >> > can >> > add the delivery domain to each user and somehow use that to construct >> > the >> > delivery address. >> > I am not sure I can do that though. >> >> I didn't really have to add anything except for one extra attribute. >> You can group your users into user groups representing the domains >> they belong to such that Postfix can query whether or not to accept >> for a domain or not. I added mailAlternateAddress for aliases rather >> than user multi-value attribute mail so I can have a "master" email >> address for each user. It was easy to do with the existing schema >> (mailRecipient objectclass). BTW if you haven't already figured it >> out, postmap -q is your friend when setting up your LDAP config in >> Postfix. Just keep adjusting everything until you get the answer you >> (and Postfix) expect. > > > I discovered that attribute when I was digging around in the ldif files and > I was just wondering why they didn't use that for setting aliases. > It would certainly make my ldap queries for postfix a lot simpler. > > I added the mailRecipient class to the defaults for users and tried to use > the ipa user-mod --setattr=mailAlternateAddress= and it is telling me > > ipa: ERROR: attribute "mailAlternateAddress" not allowed > > I have also trying to set a few other non standard attributes that seem to > be in the default schemas already and they all give me the same error. > Am I missing something? Yes. You need to add the objectclass first, then the attribute will be available. We add the objectclass to each mail user (some of our users don't have mail) and also to the user group (the domain) such that Postfix can easily find by using the objectclass as a filter. So: ipa user-mod --addattr=objectclass=mailRecipient I've patched IPA to include the mailAlternateAddress so when I add an alias that attribute is added automatically. If you don't want to patch then you'll need to also: ipa user-mod --addattr=mailAlternateAddress > > >> > I am half tempted to add the extra components of 389-ds and see it that >> > will >> > let me do what I need. >> > >> > On a side note the freeipa lads seem to be working out how to add >> > multitenancy support so it will be capable of serving multiple separate >> > Kerberos principals. >> > That would help a lot but I need to cobble something together now. >> >> Yes, if you want unique uid's within each domain you'll have to wait >> for that. I gave up on that notion and simply require unique uids for >> every user regardless of domain and deliver to single domain style >> mail store setup. > > > > yeah that's tempting but I need to have separate domains. We do have separate domains, but they share uid space. If you use email address as login and are not using Kerberos for auth then the one domain per user group also works really well. You can search the for the email address instead of the uid. Steve From pavel at zhukoff.net Thu Nov 1 04:27:11 2012 From: pavel at zhukoff.net (Pavel Zhukov) Date: Thu, 1 Nov 2012 08:27:11 +0400 Subject: [Freeipa-users] FreeIPA for AMM users management Message-ID: <20121101042710.GC8238@work.zhukoff.net> Hi all. I'd like to use FreeIPA for AMM (advanced management module) user management using this instruction [1]. I enabled option "use DNS for find LDAP servers" and set root DN and Binding method "w/ Login Credentials" but cannot login with IPA credentials. Logs of dirsrv and kerberos are empty. DNS server works correctly. [1] - http://publib.boulder.ibm.com/infocenter/bladectr/documentation/index.jsp?topic=/com.ibm.bladecenter.advmgtmod.doc/kp1bb_bc_mmug_configldap_ADrolebasedauthen.html -- Best regards, Pavel Zhukov mailto:pavel at zhukoff.net From pbrezina at redhat.com Thu Nov 1 09:12:24 2012 From: pbrezina at redhat.com (=?UTF-8?B?UGF2ZWwgQsWZZXppbmE=?=) Date: Thu, 01 Nov 2012 10:12:24 +0100 Subject: [Freeipa-users] Sudo not working In-Reply-To: <50916BD0.2080608@redhat.com> References: <509160E6.4070304@redhat.com> <50916819.8070905@redhat.com> <50916BD0.2080608@redhat.com> Message-ID: <50923CF8.3020506@redhat.com> On 10/31/2012 07:20 PM, Rob Crittenden wrote: > Bret Wortman wrote: >> F17. > > I think you want /etc/ldap.conf then. The easiest way to be sure the > right file is being used is to add sudoers_debug 1 to the file. This > will present a lot of extra output so you'll know the file is being read. > > rob Hi, I think the easiest way to determine the config file is: # sudo -V | grep ldap.conf ldap.conf path: /etc/ldap.conf (sudo must be executed under root account) > >> >> On Wed, Oct 31, 2012 at 2:04 PM, Rob Crittenden > > wrote: >> >> Bret Wortman wrote: >> >> I had enabled debugging of sudo but am not clear on where that >> debugging >> is going. It's not stdout, and I'm not seeing anything in >> /var/log/messages. >> >> I'll try switching to SSS and see what that gets me. >> >> >> What distro is this? If it is RHEL 6.3 then put the configuration >> into /etc/sudo-ldap.conf instead of /etc/nslcd. The docs are >> incorrect (we are working on getting them fixed). >> >> rob >> >> >> >> On Wed, Oct 31, 2012 at 1:33 PM, Stephen Gallagher >> >> >> wrote: >> >> On Wed 31 Oct 2012 11:53:15 AM EDT, Bret Wortman wrote: >> >> I'm pretty certain there's a painfully simple solution >> to this that >> I'm not seeing, but my current configuration isn't >> picking up the >> freeipa sudoer rule that I've set. >> >> /etc/nsswitch.conf specifies: >> sudoers: files ldap >> >> /etc/nslcd.conf contains: >> >> binddn >> uid=sudo,cn=sysaccounts,cn=____etc,dc=wedgeofli,dc=me >> >> bindpw password >> >> ssl start_tls >> tls_cacertfile /etc/ipa/ca.crt >> tls_checkpeer yes >> >> bind_timelimit 5 >> timelimit 15 >> >> uri ldap://fs1.wedgeofli.me >> >> >> >> sudoers_base ou=SUDOers,dc=wedgeofli,dc=me >> >> >> The sssd_DOMAIN.log file contains this when I try to >> sudo: >> >> >> >> >> The SSSD logs aren't showing anything wrong because they >> have >> nothing to do with the execution of the SUDO rules in this >> situation. All the SSSD is doing is verifying the >> authentication >> (when sudo prompts you for your password). >> >> The problem with the rule is most likely happening inside >> SUDO >> itself. When you specify 'sudoers: files, ldap' in >> nsswitch.conf, >> it's telling SUDO to use its own internal LDAP driver to >> look up the >> rules. So you need to check sudo logs to see what's >> happening >> (probably you will need to enable debug logging in >> /etc/sudo.conf). >> >> Recent versions of SUDO (1.8.6 and later) have support for >> setting >> 'sudoers: files, sss' in nsswitch.conf which DOES use SSSD >> (1.9.0 >> and later) for lookups (and caching) of sudo rules. >> >> >> >> >> -- >> Bret Wortman >> The Damascus Group >> Fairfax, VA >> http://bretwortman.com/ >> http://twitter.com/BretWortman >> >> >> >> >> -- >> Bret Wortman >> The Damascus Group >> Fairfax, VA >> http://bretwortman.com/ >> http://twitter.com/BretWortman >> >> >> >> _________________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/__mailman/listinfo/freeipa-users >> >> >> >> >> >> >> -- >> Bret Wortman >> The Damascus Group >> Fairfax, VA >> http://bretwortman.com/ >> http://twitter.com/BretWortman >> >> >> >> _______________________________________________ >> 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 From bret.wortman at damascusgrp.com Thu Nov 1 11:58:53 2012 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Thu, 1 Nov 2012 07:58:53 -0400 Subject: [Freeipa-users] Sudo not working In-Reply-To: <50917060.2080601@redhat.com> References: <509160E6.4070304@redhat.com> <50916819.8070905@redhat.com> <50916BD0.2080608@redhat.com> <50917060.2080601@redhat.com> Message-ID: That's got me closer now, as I'm at least getting an error message on stdout: [root at fs1 etc]# more nslcd.conf binddn uid=sudo,cn=sysaccounts,cn=etc,dc=wedgeofli,dc=me bindpw password ssl start_tls tls_cacertfile /etc/ipa/ca.crt tls_checkpeer yes bind_timelimit 5 timelimit 15 uri ldap://fs1.wedgeofli.me sudoers_base ou=SUDOers,dc=wedgeofli,dc=me [root at fs1 etc]# sudo su - sudo: ldap_sasl_bind_s(): Invalid credentials [root at fs1 ~]# So I'm off to figure out where my credentials are wrong. Thanks again, Rob, Stephen & Pavel. Bret On Wed, Oct 31, 2012 at 2:39 PM, Rob Crittenden wrote: > Bret Wortman wrote: > >> [root at fs1 etc]# more /etc/ldap.conf >> sudoers_debug: 1 >> [root at fs1 etc]# ls -l /etc/ldap.conf >> -rw-r--r--. 1 root root 17 Oct 19 14:54 /etc/ldap.conf >> >> Where should I see the extra output? I've had this set since last Friday >> and I'm not seeing any difference. >> > > Move the contents of /etc/nslcd.conf to this file and add ldap to sudoers > in /etc/nsswitch.conf. > > rob > > >> On Wed, Oct 31, 2012 at 2:20 PM, Rob Crittenden > > wrote: >> >> Bret Wortman wrote: >> >> F17. >> >> >> I think you want /etc/ldap.conf then. The easiest way to be sure the >> right file is being used is to add sudoers_debug 1 to the file. This >> will present a lot of extra output so you'll know the file is being >> read. >> >> rob >> >> >> On Wed, Oct 31, 2012 at 2:04 PM, Rob Crittenden >> >> >> wrote: >> >> Bret Wortman wrote: >> >> I had enabled debugging of sudo but am not clear on >> where that >> debugging >> is going. It's not stdout, and I'm not seeing anything in >> /var/log/messages. >> >> I'll try switching to SSS and see what that gets me. >> >> >> What distro is this? If it is RHEL 6.3 then put the >> configuration >> into /etc/sudo-ldap.conf instead of /etc/nslcd. The docs are >> incorrect (we are working on getting them fixed). >> >> rob >> >> >> >> On Wed, Oct 31, 2012 at 1:33 PM, Stephen Gallagher >> >> > >> > > >>**> wrote: >> >> On Wed 31 Oct 2012 11:53:15 AM EDT, Bret Wortman >> wrote: >> >> I'm pretty certain there's a painfully simple >> solution >> to this that >> I'm not seeing, but my current configuration >> isn't >> picking up the >> freeipa sudoer rule that I've set. >> >> /etc/nsswitch.conf specifies: >> sudoers: files ldap >> >> /etc/nslcd.conf contains: >> >> binddn >> uid=sudo,cn=sysaccounts,cn=___** >> ___etc,dc=wedgeofli,dc=me >> >> >> >> bindpw password >> >> ssl start_tls >> tls_cacertfile /etc/ipa/ca.crt >> tls_checkpeer yes >> >> bind_timelimit 5 >> timelimit 15 >> >> uri ldap://fs1.wedgeofli.me >> >> >> >> >> sudoers_base ou=SUDOers,dc=wedgeofli,dc=me >> >> >> The sssd_DOMAIN.log file contains this when I >> try to sudo: >> >> >> >> >> The SSSD logs aren't showing anything wrong >> because they have >> nothing to do with the execution of the SUDO rules >> in this >> situation. All the SSSD is doing is verifying the >> authentication >> (when sudo prompts you for your password). >> >> The problem with the rule is most likely happening >> inside SUDO >> itself. When you specify 'sudoers: files, ldap' in >> nsswitch.conf, >> it's telling SUDO to use its own internal LDAP >> driver to >> look up the >> rules. So you need to check sudo logs to see >> what's happening >> (probably you will need to enable debug logging in >> /etc/sudo.conf). >> >> Recent versions of SUDO (1.8.6 and later) have >> support for >> setting >> 'sudoers: files, sss' in nsswitch.conf which DOES >> use SSSD >> (1.9.0 >> and later) for lookups (and caching) of sudo rules. >> >> >> >> >> -- >> Bret Wortman >> The Damascus Group >> Fairfax, VA >> http://bretwortman.com/ >> http://twitter.com/BretWortman >> >> >> >> >> -- >> Bret Wortman >> The Damascus Group >> Fairfax, VA >> http://bretwortman.com/ >> http://twitter.com/BretWortman >> >> >> >> ______________________________**_____________________ >> >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> > >> > >> >> https://www.redhat.com/____**mailman/listinfo/freeipa-users >> >> **> >> >> >> >> >> **>__> >> >> >> >> >> >> >> -- >> Bret Wortman >> The Damascus Group >> Fairfax, VA >> http://bretwortman.com/ >> http://twitter.com/BretWortman >> >> >> >> ______________________________**___________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> > >> https://www.redhat.com/__**mailman/listinfo/freeipa-users >> >> **> >> >> >> >> >> >> -- >> Bret Wortman >> The Damascus Group >> Fairfax, VA >> http://bretwortman.com/ >> http://twitter.com/BretWortman >> >> >> >> ______________________________**_________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/**mailman/listinfo/freeipa-users >> >> > -- Bret Wortman The Damascus Group Fairfax, VA http://bretwortman.com/ http://twitter.com/BretWortman -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret.wortman at damascusgrp.com Thu Nov 1 12:26:50 2012 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Thu, 1 Nov 2012 08:26:50 -0400 Subject: [Freeipa-users] Sudo not working In-Reply-To: References: <509160E6.4070304@redhat.com> <50916819.8070905@redhat.com> <50916BD0.2080608@redhat.com> <50917060.2080601@redhat.com> Message-ID: To close the loop: I did the following to clear the credential problem. I suspect that I hadn't properly run kinit before doing these steps the first time: -sh-4.2$ kinit Password for bretw at WEDGEOFLI.ME: -sh-4.2$ sudo su - sudo: ldap_sasl_bind_s(): Invalid credentials [sudo] password for bretw: bretw is not in the sudoers file. This incident will be reported. -sh-4.2$ ldapsearch -x ou=SUDOers,dc=wedgeofli,dc=me # extended LDIF # # LDAPv3 # base (default) with scope subtree # filter: ou=SUDOers,dc=wedgeofli,dc=me # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 -sh-4.2$ ldapsearch ou=SUDOers,dc=wedgeofli,dc=me SASL/EXTERNAL authentication started ldap_sasl_interactive_bind_s: Unknown authentication method (-6) additional info: SASL(-4): no mechanism available: -sh-4.2$ ldapsearch -x ou=SUDOers,dc=wedgeofli,dc=me # extended LDIF # # LDAPv3 # base (default) with scope subtree # filter: ou=SUDOers,dc=wedgeofli,dc=me # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 -sh-4.2$ ldapsearch -D uid=sudo,cn=sysaccounts,cn=etc,dc=wedgeofli,dc=me -w password ou=SUDOers,dc=wedgeofli,dc=me ldap_bind: Invalid credentials (49) -sh-4.2$ ldappasswd -Y GSSAPI -S -h fs1.wedgeofli.meuid=sudo,cn=sysaccounts,cn=etc,dc=wedgeofli,dc=me New password: Re-enter new password: SASL/GSSAPI authentication started SASL username: bretw at WEDGEOFLI.ME SASL SSF: 56 SASL data security layer installed. -sh-4.2$ ldapsearch -D uid=sudo,cn=sysaccounts,cn=etc,dc=wedgeofli,dc=me -w password ou=SUDOers,dc=wedgeofli,dc=me # extended LDIF # # LDAPv3 # base (default) with scope subtree # filter: ou=SUDOers,dc=wedgeofli,dc=me # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 -sh-4.2$ sudo su - [sudo] password for bretw: [root at fs1 ~]# On Thu, Nov 1, 2012 at 7:58 AM, Bret Wortman wrote: > That's got me closer now, as I'm at least getting an error message on > stdout: > > [root at fs1 etc]# more nslcd.conf > binddn uid=sudo,cn=sysaccounts,cn=etc,dc=wedgeofli,dc=me > bindpw password > > ssl start_tls > tls_cacertfile /etc/ipa/ca.crt > tls_checkpeer yes > > bind_timelimit 5 > timelimit 15 > > uri ldap://fs1.wedgeofli.me > sudoers_base ou=SUDOers,dc=wedgeofli,dc=me > [root at fs1 etc]# sudo su - > sudo: ldap_sasl_bind_s(): Invalid credentials > [root at fs1 ~]# > > So I'm off to figure out where my credentials are wrong. Thanks again, > Rob, Stephen & Pavel. > > > Bret > > On Wed, Oct 31, 2012 at 2:39 PM, Rob Crittenden wrote: > >> Bret Wortman wrote: >> >>> [root at fs1 etc]# more /etc/ldap.conf >>> sudoers_debug: 1 >>> [root at fs1 etc]# ls -l /etc/ldap.conf >>> -rw-r--r--. 1 root root 17 Oct 19 14:54 /etc/ldap.conf >>> >>> Where should I see the extra output? I've had this set since last Friday >>> and I'm not seeing any difference. >>> >> >> Move the contents of /etc/nslcd.conf to this file and add ldap to sudoers >> in /etc/nsswitch.conf. >> >> rob >> >> >>> On Wed, Oct 31, 2012 at 2:20 PM, Rob Crittenden >> > wrote: >>> >>> Bret Wortman wrote: >>> >>> F17. >>> >>> >>> I think you want /etc/ldap.conf then. The easiest way to be sure the >>> right file is being used is to add sudoers_debug 1 to the file. This >>> will present a lot of extra output so you'll know the file is being >>> read. >>> >>> rob >>> >>> >>> On Wed, Oct 31, 2012 at 2:04 PM, Rob Crittenden >>> >>> >> >>> wrote: >>> >>> Bret Wortman wrote: >>> >>> I had enabled debugging of sudo but am not clear on >>> where that >>> debugging >>> is going. It's not stdout, and I'm not seeing anything >>> in >>> /var/log/messages. >>> >>> I'll try switching to SSS and see what that gets me. >>> >>> >>> What distro is this? If it is RHEL 6.3 then put the >>> configuration >>> into /etc/sudo-ldap.conf instead of /etc/nslcd. The docs are >>> incorrect (we are working on getting them fixed). >>> >>> rob >>> >>> >>> >>> On Wed, Oct 31, 2012 at 1:33 PM, Stephen Gallagher >>> >>> > >>> >> >> >>**> wrote: >>> >>> On Wed 31 Oct 2012 11:53:15 AM EDT, Bret Wortman >>> wrote: >>> >>> I'm pretty certain there's a painfully simple >>> solution >>> to this that >>> I'm not seeing, but my current configuration >>> isn't >>> picking up the >>> freeipa sudoer rule that I've set. >>> >>> /etc/nsswitch.conf specifies: >>> sudoers: files ldap >>> >>> /etc/nslcd.conf contains: >>> >>> binddn >>> uid=sudo,cn=sysaccounts,cn=___** >>> ___etc,dc=wedgeofli,dc=me >>> >>> >>> >>> bindpw password >>> >>> ssl start_tls >>> tls_cacertfile /etc/ipa/ca.crt >>> tls_checkpeer yes >>> >>> bind_timelimit 5 >>> timelimit 15 >>> >>> uri ldap://fs1.wedgeofli.me >>> >>> >>> >>> >>> sudoers_base ou=SUDOers,dc=wedgeofli,dc=me >>> >>> >>> The sssd_DOMAIN.log file contains this when I >>> try to sudo: >>> >>> >>> >>> >>> The SSSD logs aren't showing anything wrong >>> because they have >>> nothing to do with the execution of the SUDO rules >>> in this >>> situation. All the SSSD is doing is verifying the >>> authentication >>> (when sudo prompts you for your password). >>> >>> The problem with the rule is most likely happening >>> inside SUDO >>> itself. When you specify 'sudoers: files, ldap' in >>> nsswitch.conf, >>> it's telling SUDO to use its own internal LDAP >>> driver to >>> look up the >>> rules. So you need to check sudo logs to see >>> what's happening >>> (probably you will need to enable debug logging in >>> /etc/sudo.conf). >>> >>> Recent versions of SUDO (1.8.6 and later) have >>> support for >>> setting >>> 'sudoers: files, sss' in nsswitch.conf which DOES >>> use SSSD >>> (1.9.0 >>> and later) for lookups (and caching) of sudo rules. >>> >>> >>> >>> >>> -- >>> Bret Wortman >>> The Damascus Group >>> Fairfax, VA >>> http://bretwortman.com/ >>> http://twitter.com/BretWortman >>> >>> >>> >>> >>> -- >>> Bret Wortman >>> The Damascus Group >>> Fairfax, VA >>> http://bretwortman.com/ >>> http://twitter.com/BretWortman >>> >>> >>> >>> ______________________________**_____________________ >>> >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> > >>> >> >> >>> https://www.redhat.com/____**mailman/listinfo/freeipa-users >>> >>> **> >>> >>> >>> >>> >>> **>__> >>> >>> >>> >>> >>> >>> >>> -- >>> Bret Wortman >>> The Damascus Group >>> Fairfax, VA >>> http://bretwortman.com/ >>> http://twitter.com/BretWortman >>> >>> >>> >>> ______________________________**___________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> > >>> https://www.redhat.com/__**mailman/listinfo/freeipa-users >>> >>> **> >>> >>> >>> >>> >>> >>> -- >>> Bret Wortman >>> The Damascus Group >>> Fairfax, VA >>> http://bretwortman.com/ >>> http://twitter.com/BretWortman >>> >>> >>> >>> ______________________________**_________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/**mailman/listinfo/freeipa-users >>> >>> >> > > > -- > Bret Wortman > The Damascus Group > Fairfax, VA > http://bretwortman.com/ > http://twitter.com/BretWortman > > -- Bret Wortman The Damascus Group Fairfax, VA http://bretwortman.com/ http://twitter.com/BretWortman -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Nov 1 15:14:09 2012 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 01 Nov 2012 11:14:09 -0400 Subject: [Freeipa-users] Sudo not working In-Reply-To: References: <509160E6.4070304@redhat.com> <50916819.8070905@redhat.com> <50916BD0.2080608@redhat.com> <50917060.2080601@redhat.com> Message-ID: <509291C1.9020307@redhat.com> On 11/01/2012 08:26 AM, Bret Wortman wrote: > To close the loop: > > I did the following to clear the credential problem. I suspect that I > hadn't properly run kinit before doing these steps the first time: > > -sh-4.2$ kinit > Password for bretw at WEDGEOFLI.ME : > -sh-4.2$ sudo su - > sudo: ldap_sasl_bind_s(): Invalid credentials > [sudo] password for bretw: > bretw is not in the sudoers file. This incident will be reported. This seems to suggest that it tries to use sudoers file instead of LDAP. > -sh-4.2$ ldapsearch -x ou=SUDOers,dc=wedgeofli,dc=me > # extended LDIF > # > # LDAPv3 > # base (default) with scope subtree > # filter: ou=SUDOers,dc=wedgeofli,dc=me > # requesting: ALL > # > > # search result > search: 2 > result: 0 Success > > # numResponses: 1 If you used kinit you then can use -Y GSSAPI to use kerberos credential for the authentication. > -sh-4.2$ ldapsearch ou=SUDOers,dc=wedgeofli,dc=me > SASL/EXTERNAL authentication started > ldap_sasl_interactive_bind_s: Unknown authentication method (-6) > additional info: SASL(-4): no mechanism available: > -sh-4.2$ ldapsearch -x ou=SUDOers,dc=wedgeofli,dc=me > # extended LDIF > # > # LDAPv3 > # base (default) with scope subtree > # filter: ou=SUDOers,dc=wedgeofli,dc=me > # requesting: ALL > # > > # search result > search: 2 > result: 0 Success > > # numResponses: 1 > -sh-4.2$ ldapsearch -D > uid=sudo,cn=sysaccounts,cn=etc,dc=wedgeofli,dc=me -w password > ou=SUDOers,dc=wedgeofli,dc=me > ldap_bind: Invalid credentials (49) > > -sh-4.2$ ldappasswd -Y GSSAPI -S -h fs1.wedgeofli.me > > uid=sudo,cn=sysaccounts,cn=etc,dc=wedgeofli,dc=me > New password: > Re-enter new password: > SASL/GSSAPI authentication started > SASL username: bretw at WEDGEOFLI.ME > SASL SSF: 56 > SASL data security layer installed. > -sh-4.2$ ldapsearch -D > uid=sudo,cn=sysaccounts,cn=etc,dc=wedgeofli,dc=me -w password > ou=SUDOers,dc=wedgeofli,dc=me > # extended LDIF > # > # LDAPv3 > # base (default) with scope subtree > # filter: ou=SUDOers,dc=wedgeofli,dc=me > # requesting: ALL > # > > # search result > search: 2 > result: 0 Success > > # numResponses: 1 > -sh-4.2$ sudo su - > [sudo] password for bretw: > [root at fs1 ~]# > > On Thu, Nov 1, 2012 at 7:58 AM, Bret Wortman > > > wrote: > > That's got me closer now, as I'm at least getting an error message > on stdout: > > [root at fs1 etc]# more nslcd.conf > binddn uid=sudo,cn=sysaccounts,cn=etc,dc=wedgeofli,dc=me > bindpw password > > ssl start_tls > tls_cacertfile /etc/ipa/ca.crt > tls_checkpeer yes > > bind_timelimit 5 > timelimit 15 > > uri ldap://fs1.wedgeofli.me > sudoers_base ou=SUDOers,dc=wedgeofli,dc=me > [root at fs1 etc]# sudo su - > sudo: ldap_sasl_bind_s(): Invalid credentials > [root at fs1 ~]# > > So I'm off to figure out where my credentials are wrong. Thanks > again, Rob, Stephen & Pavel. > > > Bret > > On Wed, Oct 31, 2012 at 2:39 PM, Rob Crittenden > > wrote: > > Bret Wortman wrote: > > [root at fs1 etc]# more /etc/ldap.conf > sudoers_debug: 1 > [root at fs1 etc]# ls -l /etc/ldap.conf > -rw-r--r--. 1 root root 17 Oct 19 14:54 /etc/ldap.conf > > Where should I see the extra output? I've had this set > since last Friday > and I'm not seeing any difference. > > > Move the contents of /etc/nslcd.conf to this file and add ldap > to sudoers in /etc/nsswitch.conf. > > rob > > > On Wed, Oct 31, 2012 at 2:20 PM, Rob Crittenden > > >> > wrote: > > Bret Wortman wrote: > > F17. > > > I think you want /etc/ldap.conf then. The easiest way > to be sure the > right file is being used is to add sudoers_debug 1 to > the file. This > will present a lot of extra output so you'll know the > file is being > read. > > rob > > > On Wed, Oct 31, 2012 at 2:04 PM, Rob Crittenden > > > > >>> wrote: > > Bret Wortman wrote: > > I had enabled debugging of sudo but am > not clear on > where that > debugging > is going. It's not stdout, and I'm not > seeing anything in > /var/log/messages. > > I'll try switching to SSS and see what > that gets me. > > > What distro is this? If it is RHEL 6.3 then > put the > configuration > into /etc/sudo-ldap.conf instead of > /etc/nslcd. The docs are > incorrect (we are working on getting them fixed). > > rob > > > > On Wed, Oct 31, 2012 at 1:33 PM, Stephen > Gallagher > > > >> > > > > >>>> wrote: > > On Wed 31 Oct 2012 11:53:15 AM EDT, > Bret Wortman > wrote: > > I'm pretty certain there's a > painfully simple > solution > to this that > I'm not seeing, but my current > configuration isn't > picking up the > freeipa sudoer rule that I've set. > > /etc/nsswitch.conf specifies: > sudoers: files ldap > > /etc/nslcd.conf contains: > > binddn > > uid=sudo,cn=sysaccounts,cn=______etc,dc=wedgeofli,dc=me > > > > bindpw password > > ssl start_tls > tls_cacertfile /etc/ipa/ca.crt > tls_checkpeer yes > > bind_timelimit 5 > timelimit 15 > > uri ldap://fs1.wedgeofli.me > > > > > > sudoers_base > ou=SUDOers,dc=wedgeofli,dc=me > > > The sssd_DOMAIN.log file > contains this when I > try to sudo: > > > > > The SSSD logs aren't showing > anything wrong > because they have > nothing to do with the execution of > the SUDO rules > in this > situation. All the SSSD is doing is > verifying the > authentication > (when sudo prompts you for your > password). > > The problem with the rule is most > likely happening > inside SUDO > itself. When you specify 'sudoers: > files, ldap' in > nsswitch.conf, > it's telling SUDO to use its own > internal LDAP > driver to > look up the > rules. So you need to check sudo > logs to see > what's happening > (probably you will need to enable > debug logging in > /etc/sudo.conf). > > Recent versions of SUDO (1.8.6 and > later) have > support for > setting > 'sudoers: files, sss' in > nsswitch.conf which DOES > use SSSD > (1.9.0 > and later) for lookups (and caching) > of sudo rules. > > > > > -- > Bret Wortman > The Damascus Group > Fairfax, VA > http://bretwortman.com/ > http://twitter.com/BretWortman > > > > > -- > Bret Wortman > The Damascus Group > Fairfax, VA > http://bretwortman.com/ > http://twitter.com/BretWortman > > > > > ___________________________________________________ > > Freeipa-users mailing list > Freeipa-users at redhat.com > > > > __com > >> > > https://www.redhat.com/____mailman/listinfo/freeipa-users > > > > > > > __> > > > > > > > -- > Bret Wortman > The Damascus Group > Fairfax, VA > http://bretwortman.com/ > http://twitter.com/BretWortman > > > > _________________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > > > > > https://www.redhat.com/__mailman/listinfo/freeipa-users > > > > > > > > -- > Bret Wortman > The Damascus Group > Fairfax, VA > http://bretwortman.com/ > http://twitter.com/BretWortman > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > > -- > Bret Wortman > The Damascus Group > Fairfax, VA > http://bretwortman.com/ > http://twitter.com/BretWortman > > > > > -- > Bret Wortman > The Damascus Group > Fairfax, VA > http://bretwortman.com/ > http://twitter.com/BretWortman > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Nov 1 16:19:52 2012 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 01 Nov 2012 12:19:52 -0400 Subject: [Freeipa-users] FreeIPA for AMM users management In-Reply-To: <20121101042710.GC8238@work.zhukoff.net> References: <20121101042710.GC8238@work.zhukoff.net> Message-ID: <5092A128.5070704@redhat.com> On 11/01/2012 12:27 AM, Pavel Zhukov wrote: > Hi all. > I'd like to use FreeIPA for AMM (advanced management module) user > management using this instruction [1]. I enabled option "use DNS for > find LDAP servers" and set root DN and Binding method "w/ Login > Credentials" but cannot login with IPA credentials. Logs of dirsrv > and kerberos are empty. DNS server works correctly. > > [1] - http://publib.boulder.ibm.com/infocenter/bladectr/documentation/index.jsp?topic=/com.ibm.bladecenter.advmgtmod.doc/kp1bb_bc_mmug_configldap_ADrolebasedauthen.html > Firewall? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From pavel at zhukoff.net Thu Nov 1 14:19:23 2012 From: pavel at zhukoff.net (Pavel Zhukov) Date: Thu, 1 Nov 2012 18:19:23 +0400 Subject: [Freeipa-users] FreeIPA for AMM users management In-Reply-To: <5092A128.5070704@redhat.com> References: <20121101042710.GC8238@work.zhukoff.net> <5092A128.5070704@redhat.com> Message-ID: <20121101141923.GA1558@work.zhukoff.net> No, because authentication of Alfresco and RHEV users works fine for example. -- Best regards, Pavel Zhukov mailto:pavel at zhukoff.net On Thu, 01 Nov 2012, Dmitri Pal wrote: > On 11/01/2012 12:27 AM, Pavel Zhukov wrote: > > Hi all. > > I'd like to use FreeIPA for AMM (advanced management module) user > > management using this instruction [1]. I enabled option "use DNS for > > find LDAP servers" and set root DN and Binding method "w/ Login > > Credentials" but cannot login with IPA credentials. Logs of dirsrv > > and kerberos are empty. DNS server works correctly. > > > > [1] - http://publib.boulder.ibm.com/infocenter/bladectr/documentation/index.jsp?topic=/com.ibm.bladecenter.advmgtmod.doc/kp1bb_bc_mmug_configldap_ADrolebasedauthen.html > > > Firewall? > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From simo at redhat.com Thu Nov 1 19:55:30 2012 From: simo at redhat.com (Simo Sorce) Date: Thu, 01 Nov 2012 15:55:30 -0400 Subject: [Freeipa-users] FreeIPA for AMM users management In-Reply-To: <20121101042710.GC8238@work.zhukoff.net> References: <20121101042710.GC8238@work.zhukoff.net> Message-ID: <1351799730.18469.138.camel@willson.li.ssimo.org> On Thu, 2012-11-01 at 08:27 +0400, Pavel Zhukov wrote: > Hi all. > I'd like to use FreeIPA for AMM (advanced management module) user > management using this instruction [1]. I enabled option "use DNS for > find LDAP servers" and set root DN and Binding method "w/ Login > Credentials" but cannot login with IPA credentials. Logs of dirsrv > and kerberos are empty. DNS server works correctly. > > [1] - http://publib.boulder.ibm.com/infocenter/bladectr/documentation/index.jsp?topic=/com.ibm.bladecenter.advmgtmod.doc/kp1bb_bc_mmug_configldap_ADrolebasedauthen.html I am not sure that bind w/ Login Credentials will work properly if they assume Active Directory. AD has a non standard authentication method that allows to not use a DN to identify a user. We do not support that authentication method. However you should at least see the bind attempt and an error message in the dirsrv access log. If you do not see that then something else is broken before a bind is even attempted, perhaps DNS discovery ? Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Thu Nov 1 21:09:45 2012 From: simo at redhat.com (Simo Sorce) Date: Thu, 01 Nov 2012 17:09:45 -0400 Subject: [Freeipa-users] FreeIPA for AMM users management In-Reply-To: <1351799730.18469.138.camel@willson.li.ssimo.org> References: <20121101042710.GC8238@work.zhukoff.net> <1351799730.18469.138.camel@willson.li.ssimo.org> Message-ID: <1351804185.18469.146.camel@willson.li.ssimo.org> On Thu, 2012-11-01 at 15:55 -0400, Simo Sorce wrote: > On Thu, 2012-11-01 at 08:27 +0400, Pavel Zhukov wrote: > > Hi all. > > I'd like to use FreeIPA for AMM (advanced management module) user > > management using this instruction [1]. I enabled option "use DNS for > > find LDAP servers" and set root DN and Binding method "w/ Login > > Credentials" but cannot login with IPA credentials. Logs of dirsrv > > and kerberos are empty. DNS server works correctly. > > > > [1] - http://publib.boulder.ibm.com/infocenter/bladectr/documentation/index.jsp?topic=/com.ibm.bladecenter.advmgtmod.doc/kp1bb_bc_mmug_configldap_ADrolebasedauthen.html > > I am not sure that bind w/ Login Credentials will work properly if they > assume Active Directory. > AD has a non standard authentication method that allows to not use a DN > to identify a user. We do not support that authentication method. > > However you should at least see the bind attempt and an error message in > the dirsrv access log. > > If you do not see that then something else is broken before a bind is > even attempted, perhaps DNS discovery ? Ah btw, have you enabled SSL ? FreeIPA enforces that simple binds be done on an encrypted channel.If you try to bind with plain text credentials on an unencrypted channel FreeIPA simply returns an error. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Thu Nov 1 21:30:58 2012 From: simo at redhat.com (Simo Sorce) Date: Thu, 01 Nov 2012 17:30:58 -0400 Subject: [Freeipa-users] FreeIPA for AMM users management In-Reply-To: <1351804185.18469.146.camel@willson.li.ssimo.org> References: <20121101042710.GC8238@work.zhukoff.net> <1351799730.18469.138.camel@willson.li.ssimo.org> <1351804185.18469.146.camel@willson.li.ssimo.org> Message-ID: <1351805458.18469.147.camel@willson.li.ssimo.org> On Thu, 2012-11-01 at 17:09 -0400, Simo Sorce wrote: > On Thu, 2012-11-01 at 15:55 -0400, Simo Sorce wrote: > > On Thu, 2012-11-01 at 08:27 +0400, Pavel Zhukov wrote: > > > Hi all. > > > I'd like to use FreeIPA for AMM (advanced management module) user > > > management using this instruction [1]. I enabled option "use DNS for > > > find LDAP servers" and set root DN and Binding method "w/ Login > > > Credentials" but cannot login with IPA credentials. Logs of dirsrv > > > and kerberos are empty. DNS server works correctly. > > > > > > [1] - http://publib.boulder.ibm.com/infocenter/bladectr/documentation/index.jsp?topic=/com.ibm.bladecenter.advmgtmod.doc/kp1bb_bc_mmug_configldap_ADrolebasedauthen.html > > > > I am not sure that bind w/ Login Credentials will work properly if they > > assume Active Directory. > > AD has a non standard authentication method that allows to not use a DN > > to identify a user. We do not support that authentication method. > > > > However you should at least see the bind attempt and an error message in > > the dirsrv access log. > > > > If you do not see that then something else is broken before a bind is > > even attempted, perhaps DNS discovery ? > > Ah btw, have you enabled SSL ? > FreeIPA enforces that simple binds be done on an encrypted channel.If > you try to bind with plain text credentials on an unencrypted channel > FreeIPA simply returns an error. Uhmm sorry this is not true for binds, it is true only for password changes (and SSSD enforces auth only via SSL, but it is client side enforcement). Sorry for the noise. Simo. -- Simo Sorce * Red Hat, Inc * New York From erinn.looneytriggs at gmail.com Thu Nov 1 22:15:18 2012 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Thu, 01 Nov 2012 14:15:18 -0800 Subject: [Freeipa-users] Process open FD table is full. Message-ID: <5092F476.6090903@gmail.com> Have any folks run into this: PR_Accept() failed, Netscape Portable Runtime error -5971 (Process open FD table is full.) From the dirsrv logs. It appears that this may have been what killed IPA in total on one server for me last night. I can't turn up anything via Google. After a restart of all the IPA processes everything started working again. I have looked into FD limits on the system and it doesn't seem like that is a likely cause. Found info here: https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/8.2/html/Performance_Tuning_Guide/system-tuning.html This is on a RHEL 6.3 system fully updated. Any ideas? -Erinn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 551 bytes Desc: OpenPGP digital signature URL: From rmeggins at redhat.com Fri Nov 2 00:47:22 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 01 Nov 2012 18:47:22 -0600 Subject: [Freeipa-users] Process open FD table is full. In-Reply-To: <5092F476.6090903@gmail.com> References: <5092F476.6090903@gmail.com> Message-ID: <5093181A.7030707@redhat.com> On 11/01/2012 04:15 PM, Erinn Looney-Triggs wrote: > Have any folks run into this: > > PR_Accept() failed, Netscape Portable Runtime error -5971 (Process open > FD table is full.) > > From the dirsrv logs. It appears that this may have been what killed IPA > in total on one server for me last night. I can't turn up anything via > Google. > > After a restart of all the IPA processes everything started working again. > > I have looked into FD limits on the system and it doesn't seem like that > is a likely cause. Found info here: > https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/8.2/html/Performance_Tuning_Guide/system-tuning.html > > This is on a RHEL 6.3 system fully updated. > > Any ideas? https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/9.0/html/Performance_Tuning_Guide/system-tuning.html#file-descriptors > > -Erinn > > > > _______________________________________________ > 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 erinn.looneytriggs at gmail.com Fri Nov 2 00:57:51 2012 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Thu, 01 Nov 2012 16:57:51 -0800 Subject: [Freeipa-users] Process open FD table is full. In-Reply-To: <5093181A.7030707@redhat.com> References: <5092F476.6090903@gmail.com> <5093181A.7030707@redhat.com> Message-ID: <50931A8F.70701@gmail.com> On 11/01/12 16:47, Rich Megginson wrote: > On 11/01/2012 04:15 PM, Erinn Looney-Triggs wrote: >> Have any folks run into this: >> >> PR_Accept() failed, Netscape Portable Runtime error -5971 (Process open >> FD table is full.) >> >> From the dirsrv logs. It appears that this may have been what killed IPA >> in total on one server for me last night. I can't turn up anything via >> Google. >> >> After a restart of all the IPA processes everything started working again. >> >> I have looked into FD limits on the system and it doesn't seem like that >> is a likely cause. Found info here: >> https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/8.2/html/Performance_Tuning_Guide/system-tuning.html >> >> This is on a RHEL 6.3 system fully updated. >> >> Any ideas? > https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/9.0/html/Performance_Tuning_Guide/system-tuning.html#file-descriptors > > Yeah thanks but to my untrained eye it doesn't exactly fit: erinn at ipa ~ $ cat /proc/sys/fs/file-max 1199770 erinn at ipa ~ $ cat /etc/security/limits.conf dirsrv - nofile 8192 and, session required pam_limits.so in system-auth This was all there before and yet I hit on that problem. Am I reading things incorrectly or not understanding them, I have a very small environment (~40 systems) and it doesn't seem like I should be having this problem. -Erinn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 551 bytes Desc: OpenPGP digital signature URL: From rmeggins at redhat.com Fri Nov 2 01:57:52 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 01 Nov 2012 19:57:52 -0600 Subject: [Freeipa-users] Process open FD table is full. In-Reply-To: <50931A8F.70701@gmail.com> References: <5092F476.6090903@gmail.com> <5093181A.7030707@redhat.com> <50931A8F.70701@gmail.com> Message-ID: <509328A0.8070400@redhat.com> On 11/01/2012 06:57 PM, Erinn Looney-Triggs wrote: > On 11/01/12 16:47, Rich Megginson wrote: >> On 11/01/2012 04:15 PM, Erinn Looney-Triggs wrote: >>> Have any folks run into this: >>> >>> PR_Accept() failed, Netscape Portable Runtime error -5971 (Process open >>> FD table is full.) >>> >>> From the dirsrv logs. It appears that this may have been what killed IPA >>> in total on one server for me last night. I can't turn up anything via >>> Google. >>> >>> After a restart of all the IPA processes everything started working again. >>> >>> I have looked into FD limits on the system and it doesn't seem like that >>> is a likely cause. Found info here: >>> https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/8.2/html/Performance_Tuning_Guide/system-tuning.html >>> >>> This is on a RHEL 6.3 system fully updated. >>> >>> Any ideas? >> https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/9.0/html/Performance_Tuning_Guide/system-tuning.html#file-descriptors >> >> > Yeah thanks but to my untrained eye it doesn't exactly fit: > > erinn at ipa ~ $ cat /proc/sys/fs/file-max > 1199770 > > erinn at ipa ~ $ cat /etc/security/limits.conf > dirsrv - nofile 8192 > > and, > session required pam_limits.so > in system-auth Did you look at section 3.3.2. Setting Directory Server File Descriptor Values > > This was all there before and yet I hit on that problem. Am I reading > things incorrectly or not understanding them, I have a very small > environment (~40 systems) and it doesn't seem like I should be having > this problem. That does seem strange. > > -Erinn > > > > From pavel at zhukoff.net Fri Nov 2 04:12:46 2012 From: pavel at zhukoff.net (Pavel Zhukov) Date: Fri, 2 Nov 2012 08:12:46 +0400 Subject: [Freeipa-users] FreeIPA for AMM users management In-Reply-To: <1351804185.18469.146.camel@willson.li.ssimo.org> References: <20121101042710.GC8238@work.zhukoff.net> <1351799730.18469.138.camel@willson.li.ssimo.org> <1351804185.18469.146.camel@willson.li.ssimo.org> Message-ID: <20121102041246.GB1558@work.zhukoff.net> Thanks Simo. I've downloaded ca.crt from FreeIPA, converted it to der format, imported to AMM and enabled SSL. But nothing happened, I cannot login to AMM with FreeIPA credentials and cannot see any errors or access records still... DNS has been checked and works (integrated with IPA). -- Best regards, Pavel Zhukov mailto:pavel at zhukoff.net On Thu, 01 Nov 2012, Simo Sorce wrote: > On Thu, 2012-11-01 at 15:55 -0400, Simo Sorce wrote: > > On Thu, 2012-11-01 at 08:27 +0400, Pavel Zhukov wrote: > > > Hi all. > > > I'd like to use FreeIPA for AMM (advanced management module) user > > > management using this instruction [1]. I enabled option "use DNS for > > > find LDAP servers" and set root DN and Binding method "w/ Login > > > Credentials" but cannot login with IPA credentials. Logs of dirsrv > > > and kerberos are empty. DNS server works correctly. > > > > > > [1] - http://publib.boulder.ibm.com/infocenter/bladectr/documentation/index.jsp?topic=/com.ibm.bladecenter.advmgtmod.doc/kp1bb_bc_mmug_configldap_ADrolebasedauthen.html > > > > I am not sure that bind w/ Login Credentials will work properly if they > > assume Active Directory. > > AD has a non standard authentication method that allows to not use a DN > > to identify a user. We do not support that authentication method. > > > > However you should at least see the bind attempt and an error message in > > the dirsrv access log. > > > > If you do not see that then something else is broken before a bind is > > even attempted, perhaps DNS discovery ? > > Ah btw, have you enabled SSL ? > FreeIPA enforces that simple binds be done on an encrypted channel.If > you try to bind with plain text credentials on an unencrypted channel > FreeIPA simply returns an error. > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > From dpal at redhat.com Fri Nov 2 13:01:24 2012 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 02 Nov 2012 09:01:24 -0400 Subject: [Freeipa-users] FreeIPA for AMM users management In-Reply-To: <20121102041246.GB1558@work.zhukoff.net> References: <20121101042710.GC8238@work.zhukoff.net> <1351799730.18469.138.camel@willson.li.ssimo.org> <1351804185.18469.146.camel@willson.li.ssimo.org> <20121102041246.GB1558@work.zhukoff.net> Message-ID: <5093C424.5010506@redhat.com> On 11/02/2012 12:12 AM, Pavel Zhukov wrote: > Thanks Simo. > I've downloaded ca.crt from FreeIPA, converted it to der format, > imported to AMM and enabled SSL. But nothing happened, I cannot login > to AMM with FreeIPA credentials and cannot see any errors or access > records still... > DNS has been checked and works (integrated with IPA). > OK lets us start with heavy lifting now. Can you do NS lookup of the IPA server from the AMM box? Can you do kinit from the AMM box against IPA? Can you do ldapsearch from the AMM box against IPA? Do you see anything in the logs from such activity? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jsunn at nets.eu Fri Nov 2 08:38:50 2012 From: jsunn at nets.eu (Johan Sunnerstig) Date: Fri, 2 Nov 2012 08:38:50 +0000 Subject: [Freeipa-users] Process open FD table is full. In-Reply-To: <5092F476.6090903@gmail.com> References: <5092F476.6090903@gmail.com> Message-ID: Looks a lot like a problem I have as well. Check out the /proc/xxx/fd directory of the dirsrv process for your IPA realm, in my case it's full of dead pointers to /var/tmp/ldap_xxx where xxx will be the same on one IPA server(I have two in a multi-master setup). These don't clear out until I restart the dirsrv process, so eventually they'll fill up to the FD limit. For now I have a cron job performing a staggered IPA restart on the two servers and a case open with RH, but I haven't gotten any solution yet. This is also RHEL 6.3 by the way, though the problem appeared in 6.2 for me. Regards Johan -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Erinn Looney-Triggs Sent: den 1 november 2012 23:15 To: FreeIPAUsers Subject: [Freeipa-users] Process open FD table is full. Have any folks run into this: PR_Accept() failed, Netscape Portable Runtime error -5971 (Process open FD table is full.) >From the dirsrv logs. It appears that this may have been what killed IPA in total on one server for me last night. I can't turn up anything via Google. After a restart of all the IPA processes everything started working again. I have looked into FD limits on the system and it doesn't seem like that is a likely cause. Found info here: https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/8.2/html/Performance_Tuning_Guide/system-tuning.html This is on a RHEL 6.3 system fully updated. Any ideas? -Erinn From simo at redhat.com Fri Nov 2 15:06:47 2012 From: simo at redhat.com (Simo Sorce) Date: Fri, 02 Nov 2012 11:06:47 -0400 Subject: [Freeipa-users] Process open FD table is full. In-Reply-To: References: <5092F476.6090903@gmail.com> Message-ID: <1351868807.18469.174.camel@willson.li.ssimo.org> On Fri, 2012-11-02 at 08:38 +0000, Johan Sunnerstig wrote: > Looks a lot like a problem I have as well. > Check out the /proc/xxx/fd directory of the dirsrv process for your IPA realm, in my case it's full of dead pointers to /var/tmp/ldap_xxx where xxx will be the same on one IPA server(I have two in a multi-master setup). > These don't clear out until I restart the dirsrv process, so eventually they'll fill up to the FD limit. For now I have a cron job performing a staggered IPA restart on the two servers and a case open with RH, but I haven't gotten any solution yet. > This is also RHEL 6.3 by the way, though the problem appeared in 6.2 for me. This looks a memory leak in libkrb5 or dirsrv leaving around so krb context. Those files are replay caches. Rich, can you investigate the use of libkrb5 in dirsrv ? Simo. -- Simo Sorce * Red Hat, Inc * New York From rmeggins at redhat.com Fri Nov 2 15:28:46 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 02 Nov 2012 09:28:46 -0600 Subject: [Freeipa-users] Process open FD table is full. In-Reply-To: <1351868807.18469.174.camel@willson.li.ssimo.org> References: <5092F476.6090903@gmail.com> <1351868807.18469.174.camel@willson.li.ssimo.org> Message-ID: <5093E6AE.40902@redhat.com> On 11/02/2012 09:06 AM, Simo Sorce wrote: > On Fri, 2012-11-02 at 08:38 +0000, Johan Sunnerstig wrote: >> Looks a lot like a problem I have as well. >> Check out the /proc/xxx/fd directory of the dirsrv process for your IPA realm, in my case it's full of dead pointers to /var/tmp/ldap_xxx where xxx will be the same on one IPA server(I have two in a multi-master setup). >> These don't clear out until I restart the dirsrv process, so eventually they'll fill up to the FD limit. For now I have a cron job performing a staggered IPA restart on the two servers and a case open with RH, but I haven't gotten any solution yet. >> This is also RHEL 6.3 by the way, though the problem appeared in 6.2 for me. > This looks a memory leak in libkrb5 or dirsrv leaving around so krb > context. > > Those files are replay caches. > > Rich, can you investigate the use of libkrb5 in dirsrv ? https://bugzilla.redhat.com/show_bug.cgi?id=825863 > > Simo. > From erinn.looneytriggs at gmail.com Fri Nov 2 16:36:48 2012 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Fri, 02 Nov 2012 08:36:48 -0800 Subject: [Freeipa-users] Process open FD table is full. In-Reply-To: References: <5092F476.6090903@gmail.com> Message-ID: <5093F6A0.9000307@gmail.com> On 11/02/12 00:38, Johan Sunnerstig wrote: > Looks a lot like a problem I have as well. > Check out the /proc/xxx/fd directory of the dirsrv process for your IPA realm, in my case it's full of dead pointers to /var/tmp/ldap_xxx where xxx will be the same on one IPA server(I have two in a multi-master setup). > These don't clear out until I restart the dirsrv process, so eventually they'll fill up to the FD limit. For now I have a cron job performing a staggered IPA restart on the two servers and a case open with RH, but I haven't gotten any solution yet. > This is also RHEL 6.3 by the way, though the problem appeared in 6.2 for me. > > Regards > Johan > > > -----Original Message----- > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Erinn Looney-Triggs > Sent: den 1 november 2012 23:15 > To: FreeIPAUsers > Subject: [Freeipa-users] Process open FD table is full. > > Have any folks run into this: > > PR_Accept() failed, Netscape Portable Runtime error -5971 (Process open FD table is full.) > > From the dirsrv logs. It appears that this may have been what killed IPA in total on one server for me last night. I can't turn up anything via Google. > > After a restart of all the IPA processes everything started working again. > > I have looked into FD limits on the system and it doesn't seem like that is a likely cause. Found info here: > https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/8.2/html/Performance_Tuning_Guide/system-tuning.html > > This is on a RHEL 6.3 system fully updated. > > Any ideas? > > -Erinn > > Spot on! That is exactly what is going on, my second ipa server just died this morning, checked /proc/ out before I restarted, full of dead links. Do they have a bugzilla open for your issue that I could attach to? Or could you give me your case number so I can get RH support to reference it and track it? Thanks again, -Erinn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 551 bytes Desc: OpenPGP digital signature URL: From erinn.looneytriggs at gmail.com Fri Nov 2 16:41:47 2012 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Fri, 02 Nov 2012 08:41:47 -0800 Subject: [Freeipa-users] Process open FD table is full. In-Reply-To: <5093E6AE.40902@redhat.com> References: <5092F476.6090903@gmail.com> <1351868807.18469.174.camel@willson.li.ssimo.org> <5093E6AE.40902@redhat.com> Message-ID: <5093F7CB.8010707@gmail.com> On 11/02/12 07:28, Rich Megginson wrote: > On 11/02/2012 09:06 AM, Simo Sorce wrote: >> On Fri, 2012-11-02 at 08:38 +0000, Johan Sunnerstig wrote: >>> Looks a lot like a problem I have as well. >>> Check out the /proc/xxx/fd directory of the dirsrv process for your >>> IPA realm, in my case it's full of dead pointers to /var/tmp/ldap_xxx >>> where xxx will be the same on one IPA server(I have two in a >>> multi-master setup). >>> These don't clear out until I restart the dirsrv process, so >>> eventually they'll fill up to the FD limit. For now I have a cron job >>> performing a staggered IPA restart on the two servers and a case open >>> with RH, but I haven't gotten any solution yet. >>> This is also RHEL 6.3 by the way, though the problem appeared in 6.2 >>> for me. >> This looks a memory leak in libkrb5 or dirsrv leaving around so krb >> context. >> >> Those files are replay caches. >> >> Rich, can you investigate the use of libkrb5 in dirsrv ? > https://bugzilla.redhat.com/show_bug.cgi?id=825863 >> >> Simo. >> > Oops missed this, though this is a private bug so I will have to take y'alls word for it being the thing. I hate private bugs. I am going to open a RH support case, just in case that helps in any way. -Erinn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 551 bytes Desc: OpenPGP digital signature URL: From rmeggins at redhat.com Fri Nov 2 16:43:35 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 02 Nov 2012 10:43:35 -0600 Subject: [Freeipa-users] Process open FD table is full. In-Reply-To: <5093F7CB.8010707@gmail.com> References: <5092F476.6090903@gmail.com> <1351868807.18469.174.camel@willson.li.ssimo.org> <5093E6AE.40902@redhat.com> <5093F7CB.8010707@gmail.com> Message-ID: <5093F837.6050705@redhat.com> On 11/02/2012 10:41 AM, Erinn Looney-Triggs wrote: > On 11/02/12 07:28, Rich Megginson wrote: >> On 11/02/2012 09:06 AM, Simo Sorce wrote: >>> On Fri, 2012-11-02 at 08:38 +0000, Johan Sunnerstig wrote: >>>> Looks a lot like a problem I have as well. >>>> Check out the /proc/xxx/fd directory of the dirsrv process for your >>>> IPA realm, in my case it's full of dead pointers to /var/tmp/ldap_xxx >>>> where xxx will be the same on one IPA server(I have two in a >>>> multi-master setup). >>>> These don't clear out until I restart the dirsrv process, so >>>> eventually they'll fill up to the FD limit. For now I have a cron job >>>> performing a staggered IPA restart on the two servers and a case open >>>> with RH, but I haven't gotten any solution yet. >>>> This is also RHEL 6.3 by the way, though the problem appeared in 6.2 >>>> for me. >>> This looks a memory leak in libkrb5 or dirsrv leaving around so krb >>> context. >>> >>> Those files are replay caches. >>> >>> Rich, can you investigate the use of libkrb5 in dirsrv ? >> https://bugzilla.redhat.com/show_bug.cgi?id=825863 >>> Simo. >>> > Oops missed this, though this is a private bug so I will have to take > y'alls word for it being the thing. Sorry about that. It appears to be a problem with either krb5 or selinux, and there is a proposed fix for RHEL 6.4 > > I hate private bugs. I am going to open a RH support case, just in case > that helps in any way. Yes, please. > > -Erinn > From pavel at zhukoff.net Sat Nov 3 12:12:43 2012 From: pavel at zhukoff.net (Pavel Zhukov) Date: Sat, 3 Nov 2012 16:12:43 +0400 Subject: [Freeipa-users] FreeIPA for AMM users management In-Reply-To: <5093C424.5010506@redhat.com> References: <20121101042710.GC8238@work.zhukoff.net> <1351799730.18469.138.camel@willson.li.ssimo.org> <1351804185.18469.146.camel@willson.li.ssimo.org> <20121102041246.GB1558@work.zhukoff.net> <5093C424.5010506@redhat.com> Message-ID: <20121103121243.GC1558@work.zhukoff.net> > Can you do NS lookup of the IPA server from the AMM box? yes > Can you do kinit from the AMM box against IPA? > Can you do ldapsearch from the AMM box against IPA? no, AMM has restricted shell and web GUI. > Do you see anything in the logs from such activity? -- Best regards, Pavel Zhukov mailto:pavel at zhukoff.net On Fri, 02 Nov 2012, Dmitri Pal wrote: > On 11/02/2012 12:12 AM, Pavel Zhukov wrote: > > Thanks Simo. > > I've downloaded ca.crt from FreeIPA, converted it to der format, > > imported to AMM and enabled SSL. But nothing happened, I cannot login > > to AMM with FreeIPA credentials and cannot see any errors or access > > records still... > > DNS has been checked and works (integrated with IPA). > > > OK lets us start with heavy lifting now. > > Can you do NS lookup of the IPA server from the AMM box? > Can you do kinit from the AMM box against IPA? > Can you do ldapsearch from the AMM box against IPA? > Do you see anything in the logs from such activity? > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From william.muriithi at gmail.com Sun Nov 4 19:23:39 2012 From: william.muriithi at gmail.com (William Muriithi) Date: Sun, 4 Nov 2012 14:23:39 -0500 Subject: [Freeipa-users] FreeIPA v 2.2 in an AD environment Message-ID: Hi all, I am in the process of deploying freeIPA 2.2 to authenticate Linux systems and have been able to setup everything nicely with separate domain. I mean users are currently using separate password to access Linux system and another set of password from AD for desktop stuff. On Friday, I came across an article on freeIPA v 3 and noticed one can use the same username & password for both Linux and Windows systems. I have since felt this would be a better setup and but feel like the documentation are not clear on how to achieve the above. Would anyone be able to clarify this: - Can I be able to synchronize the current AD user credentials with FreeIPA 2.2 or do I have to upgrade to FreeIPA 3.0 ? - If upgrading is necessary, is there an RPM that can run on RHEL 6.2 ? I can only seem to find freeIPA v3 RPM for Fedora 17. Was hoping to use a blessed RPM instead of rolling one which mean be incompatible with the distribution RPM once it comes around Regards, William From Steven.Jones at vuw.ac.nz Sun Nov 4 20:25:20 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Sun, 4 Nov 2012 20:25:20 +0000 Subject: [Freeipa-users] FreeIPA v 2.2 in an AD environment In-Reply-To: References: Message-ID: <833D8E48405E064EBC54C84EC6B36E4054716A9B@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, Yes you can winsync and passsync RHEL6.3 IPA from win2k3 r2 + AD, it should be in your RH supported channel tree? The passsync.msi has to go on each AD box and is a MSI supplied by RH, I think that's also in the RH support channel but for some strange reason I think it might be in the workstation tree and not server tree. >From what I can read there are some caveats, 1) Only one AD domain, so if you have a AD "forest" you can only do one sub-domain. So if the root is "example.com" and you have "staff.example.com" and "clients.example.com" you can do only one, say staff.example.com to IPA. Possible issues, 2) There is a bug in the setup where you have to be careful that you specify the right OU= IF your users are not in the expected default (cn=users?), otherwise the IPA users get deleted rather than ignored, you end up with an empty IPA....frightened me senseless! So, a) If you have users in multiple ou's then only one set is synced the rest in IPA will go bye bye, unless they are unique to IPA. b) If some users have a smartphone to exchange setup the winsync agreement sees that as the user having 2 ous's and first adds and then deletes those users......oops.....I lost 20% of my users that way.... These are with RH support, I have a hot fix, I am testing. c) Its really hard to make sure all users have been transferred as you can only see 2000 users in IPA so something like an external tool like xplorer seem to be the only way for simpletons like myself to look at and compare. This is with RH support. 3) Also with 6.2 or 6.2 upgraded to 6.3 you may find that when the winsync syncs, the IPA users lose all their groups. I have tested a 6.2 upgraded to 6.3 several times and this happens each time but a clean 6.3 IPA seems fine....we dont know why that is yet. This is with RH support, So if you are going to do this you need an isolated test setup to test for un-expected "features" that could really spoil your day. :( My main advice would be restart with a clean 6.3 setup and not an upgraded from 6.2. Ive rebuilt 2 of my three IPA servers and teh 6.3 clean builds seem a lot more stable. Also use db2ldif to make backups of your database before you do it....also you might want to halt and turn off any IPA replicas when you do it until after you are happy its stable and OK. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of William Muriithi [william.muriithi at gmail.com] Sent: Monday, 5 November 2012 8:23 a.m. To: freeipa-users at redhat.com Subject: [Freeipa-users] FreeIPA v 2.2 in an AD environment Hi all, I am in the process of deploying freeIPA 2.2 to authenticate Linux systems and have been able to setup everything nicely with separate domain. I mean users are currently using separate password to access Linux system and another set of password from AD for desktop stuff. On Friday, I came across an article on freeIPA v 3 and noticed one can use the same username & password for both Linux and Windows systems. I have since felt this would be a better setup and but feel like the documentation are not clear on how to achieve the above. Would anyone be able to clarify this: - Can I be able to synchronize the current AD user credentials with FreeIPA 2.2 or do I have to upgrade to FreeIPA 3.0 ? - If upgrading is necessary, is there an RPM that can run on RHEL 6.2 ? I can only seem to find freeIPA v3 RPM for Fedora 17. Was hoping to use a blessed RPM instead of rolling one which mean be incompatible with the distribution RPM once it comes around Regards, William _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From pspacek at redhat.com Mon Nov 5 08:32:42 2012 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 05 Nov 2012 09:32:42 +0100 Subject: [Freeipa-users] FreeIPA for AMM users management In-Reply-To: <20121103121243.GC1558@work.zhukoff.net> References: <20121101042710.GC8238@work.zhukoff.net> <1351799730.18469.138.camel@willson.li.ssimo.org> <1351804185.18469.146.camel@willson.li.ssimo.org> <20121102041246.GB1558@work.zhukoff.net> <5093C424.5010506@redhat.com> <20121103121243.GC1558@work.zhukoff.net> Message-ID: <509779AA.6010409@redhat.com> On 11/03/2012 01:12 PM, Pavel Zhukov wrote: >> Can you do NS lookup of the IPA server from the AMM box? > yes >> Can you do kinit from the AMM box against IPA? >> Can you do ldapsearch from the AMM box against IPA? > no, AMM has restricted shell and web GUI. Hmm, that is unfortunate. Can you run tcpdump (or sniffer provided on AMM) on the link between AMM and IPA server? Because there are no records in access log I will bet on some name resolution or firewall problem. Do AMM get right DNS responses (i.e. name and IP address of the IPA server)? Do AMM established TCP connection with the IPA server? -- Petr^2 Spacek >> Do you see anything in the logs from such activity? From rmeggins at redhat.com Mon Nov 5 15:17:34 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 05 Nov 2012 08:17:34 -0700 Subject: [Freeipa-users] FreeIPA v 2.2 in an AD environment In-Reply-To: <833D8E48405E064EBC54C84EC6B36E4054716A9B@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E4054716A9B@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <5097D88E.1020508@redhat.com> On 11/04/2012 01:25 PM, Steven Jones wrote: > Hi, > > Yes you can winsync and passsync RHEL6.3 IPA from win2k3 r2 + AD, it should be in your RH supported channel tree? > > The passsync.msi has to go on each AD box Each Domain Controller. Also note that you asked if "Can I be able to synchronize the current AD user credentials with FreeIPA 2.2 or do I have to upgrade to FreeIPA 3.0" You cannot synchronize already existing passwords with IPA 2.x. You would have to force AD users to change their passwords in order to get the clear text password to send to IPA. > and is a MSI supplied by RH, I think that's also in the RH support channel but for some strange reason I think it might be in the workstation tree and not server tree. > > > From what I can read there are some caveats, > > 1) Only one AD domain, so if you have a AD "forest" you can only do one sub-domain. So if the root is "example.com" and you have "staff.example.com" and "clients.example.com" you can do only one, say staff.example.com to IPA. > > Possible issues, > > 2) There is a bug in the setup where you have to be careful that you specify the right OU= IF your users are not in the expected default (cn=users?), otherwise the IPA users get deleted rather than ignored, you end up with an empty IPA....frightened me senseless! https://fedorahosted.org/freeipa/ticket/2688 and https://fedorahosted.org/389/ticket/355 The problem is caused when you have a user ID in IPA that has the same user ID as a user in AD, but you didn't want them to be synced, and the AD user entry is outside the scope of the windows sync agreement. This may or may not be a problem in your deployment. > > So, > > a) If you have users in multiple ou's then only one set is synced the rest in IPA will go bye bye, unless they are unique to IPA. See above. > b) If some users have a smartphone to exchange setup the winsync agreement sees that as the user having 2 ous's and first adds and then deletes those users......oops.....I lost 20% of my users that way.... Is there a ticket/bz for this issue, or is this the same issue as above? > > These are with RH support, I have a hot fix, I am testing. > > c) Its really hard to make sure all users have been transferred as you can only see 2000 users in IPA so something like an external tool like xplorer seem to be the only way for simpletons like myself to look at and compare. > > This is with RH support. There are workarounds. > > 3) Also with 6.2 or 6.2 upgraded to 6.3 you may find that when the winsync syncs, the IPA users lose all their groups. I have tested a 6.2 upgraded to 6.3 several times and this happens each time but a clean 6.3 IPA seems fine....we dont know why that is yet. > > This is with RH support, > > So if you are going to do this you need an isolated test setup to test for un-expected "features" that could really spoil your day. > > :( > > My main advice would be restart with a clean 6.3 setup and not an upgraded from 6.2. Ive rebuilt 2 of my three IPA servers and teh 6.3 clean builds seem a lot more stable. > > Also use db2ldif to make backups of your database before you do it....also you might want to halt and turn off any IPA replicas when you do it until after you are happy its stable and OK. You can also use db2ldif to get around the 2000 user limit mentioned above. > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of William Muriithi [william.muriithi at gmail.com] > Sent: Monday, 5 November 2012 8:23 a.m. > To: freeipa-users at redhat.com > Subject: [Freeipa-users] FreeIPA v 2.2 in an AD environment > > Hi all, > > I am in the process of deploying freeIPA 2.2 to authenticate Linux > systems and have been able to setup everything nicely with separate > domain. I mean users are currently using separate password to access > Linux system and another set of password from AD for desktop stuff. On > Friday, I came across an article on freeIPA v 3 and noticed one can > use the same username& password for both Linux and Windows systems. > I have since felt this would be a better setup and but feel like the > documentation are not clear on how to achieve the above. > > Would anyone be able to clarify this: > > - Can I be able to synchronize the current AD user credentials with > FreeIPA 2.2 or do I have to upgrade to FreeIPA 3.0 ? > - If upgrading is necessary, is there an RPM that can run on RHEL 6.2 > ? I can only seem to find freeIPA v3 RPM for Fedora 17. Was hoping > to use a blessed RPM instead of rolling one which mean be incompatible > with the distribution RPM once it comes around > > Regards, > > William > > _______________________________________________ > 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 From dpal at redhat.com Mon Nov 5 15:48:26 2012 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 05 Nov 2012 10:48:26 -0500 Subject: [Freeipa-users] FreeIPA v 2.2 in an AD environment In-Reply-To: References: Message-ID: <5097DFCA.60607@redhat.com> On 11/04/2012 02:23 PM, William Muriithi wrote: > Hi all, > > I am in the process of deploying freeIPA 2.2 to authenticate Linux > systems and have been able to setup everything nicely with separate > domain. I mean users are currently using separate password to access > Linux system and another set of password from AD for desktop stuff. On > Friday, I came across an article on freeIPA v 3 and noticed one can > use the same username & password for both Linux and Windows systems. > I have since felt this would be a better setup and but feel like the > documentation are not clear on how to achieve the above. > > Would anyone be able to clarify this: > > - Can I be able to synchronize the current AD user credentials with > FreeIPA 2.2 or do I have to upgrade to FreeIPA 3.0 ? > - If upgrading is necessary, is there an RPM that can run on RHEL 6.2 > ? I can only seem to find freeIPA v3 RPM for Fedora 17. Was hoping > to use a blessed RPM instead of rolling one which mean be incompatible > with the distribution RPM once it comes around > > Regards, > > William In addition to other comments I want to step back and give a bit of a bigger picture. 1) Regardless of what approach you choose we recommend using the latest available version at the moment of deployment. 2) There are two different approached to dealing with AD - sync or trust. You need to chose what approach you want to use. Down the road there might be some hybrid solutions but so far they are not supported. Sync: available starting the beginning of the IPA life. It has some limitations and we indeed had some issues with the corner cases that Steve's environment has. They are not common but you have been warned anyways. Trust: a) Trusts are targeting RHEL 6.4 b) There is no upgrade from Sync to Trust solution. If you want trusts you need to upgrade what you have to 6.4 (or start over) and implement trusts there and not do Sync. c) To take advantage of trusts your clients must be SSSD 1.9.x otherwise the trusts would not work. This also means that if you have other UNIXes the trusts would not work there. If you have UNIX clients that need to be accessed by AD users you might explore some hybrid solutions that might work but we can't say for sure. For example the sync might actually work in parallel to trusts to some extent. There is also PAM pass through capability that comes with 6.4 as a tech preview. That would allow pass through LDAP auth for the non SSSD 1.9 clients. But this needs to be tried out and there might be dragons. > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From mbarr at snap-interactive.com Mon Nov 5 17:51:31 2012 From: mbarr at snap-interactive.com (Matthew Barr) Date: Mon, 5 Nov 2012 12:51:31 -0500 Subject: [Freeipa-users] FreeIPA start dependencies Message-ID: So, we're in a datacenter that lost power over sandy. (It's not our only one, so the app was fine.) I'm now trying to bring the DC back online, and IPA is having issues with it's inability to reach other replicas. * We're using IPA for DNS as well as the kerberos & LDAP services. Does anyone have any documentation on which services are required for bringing up IPA? named is having trouble coming up, since it can't reach it's peers. resolv.conf points to the local IP, then to the replicas.. but those aren't reachable yet. We're getting: Failed to init credentials (Cannot resolve network address for KDC in realm "XXXXYYYY.COM") As an aside, we're not having issues starting dirsrv, KDC, or the other IPA services, just named. Named's failure then causes everything else to shut down, though.. Matthew Barr Technical Architect E: mbarr at snap-interactive.com AIM: matthewbarr1 c: (646) 727-0535 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Mon Nov 5 18:08:34 2012 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 05 Nov 2012 13:08:34 -0500 Subject: [Freeipa-users] FreeIPA start dependencies In-Reply-To: References: Message-ID: <509800A2.3000808@redhat.com> On 11/05/2012 12:51 PM, Matthew Barr wrote: > So, we're in a datacenter that lost power over sandy. (It's not our > only one, so the app was fine.) > > I'm now trying to bring the DC back online, and IPA is having issues > with it's inability to reach other replicas. > > * We're using IPA for DNS as well as the kerberos & LDAP services. Is it installed with forwarders to some other DNS server? Is that server alive and running? It is reachable? If not you might want to add host name and IP of the IPA server into the /etc/hosts > > Does anyone have any documentation on which services are required for > bringing up IPA? > > named is having trouble coming up, since it can't reach it's peers. > > resolv.conf points to the local IP, then to the replicas.. but those > aren't reachable yet. > > > We're getting: > Failed to init credentials (Cannot resolve network address for KDC in > realm "XXXXYYYY.COM ") > > As an aside, we're not having issues starting dirsrv, KDC, or the > other IPA services, just named. Named's failure then causes > everything else to shut down, though.. You actually might have problems with others too. Some logs would be helpful. > > > > Matthew Barr > Technical Architect > E: mbarr at snap-interactive.com > AIM: matthewbarr1 > c: (646) 727-0535 > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From william.muriithi at gmail.com Mon Nov 5 18:13:01 2012 From: william.muriithi at gmail.com (William Muriithi) Date: Mon, 5 Nov 2012 13:13:01 -0500 Subject: [Freeipa-users] FreeIPA v 2.2 in an AD environment Message-ID: Steve, thanks > Hi, > > Yes you can winsync and passsync RHEL6.3 IPA from win2k3 r2 + AD, it should be in your RH supported channel tree? > Nope, using Centos 6.3. I checked and looks like I can find passsync.msi from here. I am hoping its the same Windows binaries supplied to RedHat paying customers http://directory.fedoraproject.org/wiki/Download > > 1) Only one AD domain, so if you have a AD "forest" you can only do one sub-domain. So if the root is "example.com" and you have "staff.example.com" and "clients.example.com" you can do only one, say staff.example.com to IPA. > > Possible issues, > > 2) There is a bug in the setup where you have to be careful that you specify the right OU= IF your users are not in the expected default (cn=users?), otherwise the IPA users get deleted rather than ignored, you end up with an empty IPA....frightened me senseless! Do you mind explaining this further please? Where are you specifying this? On the passsync.msi application "search base" field? on AD side or on "ipa-replica-manage --win-subtree" ? Expected default users CN, on which side, AD or FreeIPA? Sorry, I tried to google for the bug and I can't seem to pick it, so the question. > > So, > > a) If you have users in multiple ou's then only one set is synced the rest in IPA will go bye bye, unless they are unique to IPA. > b) If some users have a smartphone to exchange setup the winsync agreement sees that as the user having 2 ous's and first adds and then deletes those users......oops.....I lost 20% of my users that way.... Yikes, that would have sucked, hope you had a backup. I don't have sub-domain (Forest = domain), but would have been caught by the smartphone issue. Thanks for the heads up, really appreciates. > > This is with RH support. Hmm, hopefully their response will get to us none customers somehow. > > 3) Also with 6.2 or 6.2 upgraded to 6.3 you may find that when the winsync syncs, the IPA users lose all their groups. I have tested a 6.2 upgraded to 6.3 several times and this happens each time but a clean 6.3 IPA seems fine....we dont know why that is yet. > > This is with RH support, > > So if you are going to do this you need an isolated test setup to test for un-expected "features" that could really spoil your day. > > :( Yes, I am really grateful for asking before diving in. Looks like I would have got hurt really bad. > > My main advice would be restart with a clean 6.3 setup and not an upgraded from 6.2. Ive rebuilt 2 of my three IPA servers and teh 6.3 clean builds seem a lot more stable. > > Also use db2ldif to make backups of your database before you do it....also you might want to halt and turn off any IPA replicas when you do it until after you are happy its stable and OK. > Will use 6.3. Thank you again for the advice William > > ________________________________________ > From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of William Muriithi [william.muriithi at gmail.com] > Sent: Monday, 5 November 2012 8:23 a.m. > To: freeipa-users at redhat.com > Subject: [Freeipa-users] FreeIPA v 2.2 in an AD environment > > Hi all, > > I am in the process of deploying freeIPA 2.2 to authenticate Linux > systems and have been able to setup everything nicely with separate > domain. I mean users are currently using separate password to access > Linux system and another set of password from AD for desktop stuff. On > Friday, I came across an article on freeIPA v 3 and noticed one can > use the same username & password for both Linux and Windows systems. > I have since felt this would be a better setup and but feel like the > documentation are not clear on how to achieve the above. > > Would anyone be able to clarify this: > > - Can I be able to synchronize the current AD user credentials with > FreeIPA 2.2 or do I have to upgrade to FreeIPA 3.0 ? > - If upgrading is necessary, is there an RPM that can run on RHEL 6.2 > ? I can only seem to find freeIPA v3 RPM for Fedora 17. Was hoping > to use a blessed RPM instead of rolling one which mean be incompatible > with the distribution RPM once it comes around > > Regards, > > William > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > > ------------------------------ > > Message: 3 > Date: Mon, 05 Nov 2012 09:32:42 +0100 > From: Petr Spacek > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] FreeIPA for AMM users management > Message-ID: <509779AA.6010409 at redhat.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 11/03/2012 01:12 PM, Pavel Zhukov wrote: >>> Can you do NS lookup of the IPA server from the AMM box? >> yes >>> Can you do kinit from the AMM box against IPA? >>> Can you do ldapsearch from the AMM box against IPA? >> no, AMM has restricted shell and web GUI. > > Hmm, that is unfortunate. Can you run tcpdump (or sniffer provided on AMM) on > the link between AMM and IPA server? Because there are no records in access > log I will bet on some name resolution or firewall problem. > > Do AMM get right DNS responses (i.e. name and IP address of the IPA server)? > > Do AMM established TCP connection with the IPA server? > > -- > Petr^2 Spacek > >>> Do you see anything in the logs from such activity? > > > > ------------------------------ > > Message: 4 > Date: Mon, 05 Nov 2012 08:17:34 -0700 > From: Rich Megginson > To: Steven Jones > Cc: "freeipa-users at redhat.com" > Subject: Re: [Freeipa-users] FreeIPA v 2.2 in an AD environment > Message-ID: <5097D88E.1020508 at redhat.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 11/04/2012 01:25 PM, Steven Jones wrote: >> Hi, >> >> Yes you can winsync and passsync RHEL6.3 IPA from win2k3 r2 + AD, it should be in your RH supported channel tree? >> >> The passsync.msi has to go on each AD box > Each Domain Controller. > > Also note that you asked if "Can I be able to synchronize the current AD > user credentials with > FreeIPA 2.2 or do I have to upgrade to FreeIPA 3.0" > > You cannot synchronize already existing passwords with IPA 2.x. You > would have to force AD users to change their passwords in order to get > the clear text password to send to IPA. > >> and is a MSI supplied by RH, I think that's also in the RH support channel but for some strange reason I think it might be in the workstation tree and not server tree. >> >> > From what I can read there are some caveats, >> >> 1) Only one AD domain, so if you have a AD "forest" you can only do one sub-domain. So if the root is "example.com" and you have "staff.example.com" and "clients.example.com" you can do only one, say staff.example.com to IPA. >> >> Possible issues, >> >> 2) There is a bug in the setup where you have to be careful that you specify the right OU= IF your users are not in the expected default (cn=users?), otherwise the IPA users get deleted rather than ignored, you end up with an empty IPA....frightened me senseless! > https://fedorahosted.org/freeipa/ticket/2688 > and > https://fedorahosted.org/389/ticket/355 > > The problem is caused when you have a user ID in IPA that has the same > user ID as a user in AD, but you didn't want them to be synced, and the > AD user entry is outside the scope of the windows sync agreement. This > may or may not be a problem in your deployment. > >> >> So, >> >> a) If you have users in multiple ou's then only one set is synced the rest in IPA will go bye bye, unless they are unique to IPA. > See above. >> b) If some users have a smartphone to exchange setup the winsync agreement sees that as the user having 2 ous's and first adds and then deletes those users......oops.....I lost 20% of my users that way.... > Is there a ticket/bz for this issue, or is this the same issue as above? >> >> These are with RH support, I have a hot fix, I am testing. >> >> c) Its really hard to make sure all users have been transferred as you can only see 2000 users in IPA so something like an external tool like xplorer seem to be the only way for simpletons like myself to look at and compare. >> >> This is with RH support. > There are workarounds. >> >> 3) Also with 6.2 or 6.2 upgraded to 6.3 you may find that when the winsync syncs, the IPA users lose all their groups. I have tested a 6.2 upgraded to 6.3 several times and this happens each time but a clean 6.3 IPA seems fine....we dont know why that is yet. >> >> This is with RH support, >> >> So if you are going to do this you need an isolated test setup to test for un-expected "features" that could really spoil your day. >> >> :( >> >> My main advice would be restart with a clean 6.3 setup and not an upgraded from 6.2. Ive rebuilt 2 of my three IPA servers and teh 6.3 clean builds seem a lot more stable. >> >> Also use db2ldif to make backups of your database before you do it....also you might want to halt and turn off any IPA replicas when you do it until after you are happy its stable and OK. > You can also use db2ldif to get around the 2000 user limit mentioned above. >> >> regards >> >> Steven Jones >> >> Technical Specialist - Linux RHCE >> >> Victoria University, Wellington, NZ >> >> 0064 4 463 6272 >> >> ________________________________________ >> From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of William Muriithi [william.muriithi at gmail.com] >> Sent: Monday, 5 November 2012 8:23 a.m. >> To: freeipa-users at redhat.com >> Subject: [Freeipa-users] FreeIPA v 2.2 in an AD environment >> >> Hi all, >> >> I am in the process of deploying freeIPA 2.2 to authenticate Linux >> systems and have been able to setup everything nicely with separate >> domain. I mean users are currently using separate password to access >> Linux system and another set of password from AD for desktop stuff. On >> Friday, I came across an article on freeIPA v 3 and noticed one can >> use the same username& password for both Linux and Windows systems. >> I have since felt this would be a better setup and but feel like the >> documentation are not clear on how to achieve the above. >> >> Would anyone be able to clarify this: >> >> - Can I be able to synchronize the current AD user credentials with >> FreeIPA 2.2 or do I have to upgrade to FreeIPA 3.0 ? >> - If upgrading is necessary, is there an RPM that can run on RHEL 6.2 >> ? I can only seem to find freeIPA v3 RPM for Fedora 17. Was hoping >> to use a blessed RPM instead of rolling one which mean be incompatible >> with the distribution RPM once it comes around >> >> Regards, >> >> William >> >> _______________________________________________ >> 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 > > > > ------------------------------ > > Message: 5 > Date: Mon, 05 Nov 2012 10:48:26 -0500 > From: Dmitri Pal > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] FreeIPA v 2.2 in an AD environment > Message-ID: <5097DFCA.60607 at redhat.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On 11/04/2012 02:23 PM, William Muriithi wrote: >> Hi all, >> >> I am in the process of deploying freeIPA 2.2 to authenticate Linux >> systems and have been able to setup everything nicely with separate >> domain. I mean users are currently using separate password to access >> Linux system and another set of password from AD for desktop stuff. On >> Friday, I came across an article on freeIPA v 3 and noticed one can >> use the same username & password for both Linux and Windows systems. >> I have since felt this would be a better setup and but feel like the >> documentation are not clear on how to achieve the above. >> >> Would anyone be able to clarify this: >> >> - Can I be able to synchronize the current AD user credentials with >> FreeIPA 2.2 or do I have to upgrade to FreeIPA 3.0 ? >> - If upgrading is necessary, is there an RPM that can run on RHEL 6.2 >> ? I can only seem to find freeIPA v3 RPM for Fedora 17. Was hoping >> to use a blessed RPM instead of rolling one which mean be incompatible >> with the distribution RPM once it comes around >> >> Regards, >> >> William > > In addition to other comments I want to step back and give a bit of a > bigger picture. > 1) Regardless of what approach you choose we recommend using the latest > available version at the moment of deployment. > 2) There are two different approached to dealing with AD - sync or > trust. You need to chose what approach you want to use. Down the road > there might be some hybrid solutions but so far they are not supported. > > Sync: available starting the beginning of the IPA life. It has some > limitations and we indeed had some issues with the corner cases that > Steve's environment has. They are not common but you have been warned > anyways. > > Trust: > a) Trusts are targeting RHEL 6.4 > b) There is no upgrade from Sync to Trust solution. If you want trusts > you need to upgrade what you have to 6.4 (or start over) and implement > trusts there and not do Sync. > c) To take advantage of trusts your clients must be SSSD 1.9.x otherwise > the trusts would not work. This also means that if you have other UNIXes > the trusts would not work there. > > If you have UNIX clients that need to be accessed by AD users you might > explore some hybrid solutions that might work but we can't say for sure. > For example the sync might actually work in parallel to trusts to some > extent. There is also PAM pass through capability that comes with 6.4 as > a tech preview. That would allow pass through LDAP auth for the non > SSSD 1.9 clients. But this needs to be tried out and there might be dragons. > > > >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > > > ------------------------------ > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > End of Freeipa-users Digest, Vol 52, Issue 9 > ******************************************** From Steven.Jones at vuw.ac.nz Mon Nov 5 18:13:31 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Mon, 5 Nov 2012 18:13:31 +0000 Subject: [Freeipa-users] FreeIPA v 2.2 in an AD environment In-Reply-To: <5097D88E.1020508@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E4054716A9B@STAWINCOX10MBX1.staff.vuw.ac.nz>, <5097D88E.1020508@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E4054719746@STAWINCOX10MBX1.staff.vuw.ac.nz> "Also note that you asked if "Can I be able to synchronize the current AD user credentials with FreeIPA 2.2 or do I have to upgrade to FreeIPA 3.0" You cannot synchronize already existing passwords with IPA 2.x. You would have to force AD users to change their passwords in order to get the clear text password to send to IPA." Given the password in AD is encrypted I would assume that this will apply to any version of IPA? Unless 3+ goes back to AD to confirm the password there? regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 From Steven.Jones at vuw.ac.nz Mon Nov 5 18:34:15 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Mon, 5 Nov 2012 18:34:15 +0000 Subject: [Freeipa-users] FreeIPA v 2.2 in an AD environment In-Reply-To: <5097DFCA.60607@redhat.com> References: , <5097DFCA.60607@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E4054719774@STAWINCOX10MBX1.staff.vuw.ac.nz> nice (and nice its in 6.4) :) I need to read up on trusts. However from limited experience in an AD forests with trusts they get very complex and the security can go bye bye. Ive seen pen tests that come in from a trusted domain, using an account with too many privaledges a bad password in a poorly implimented AD get across to the root and rainbow the password table (and hence domain admin) via a trust of a well set up one...own AD own IPA. "poorly" also of course windows admins dont understand IPA or linux and linux admins dont understand AD or windows both are really specialists of complex environments in their own right. (Which cracks me up when I see adverts for linux gurus and must have 3 to 5 years experience with AD....and paying peanuts....doh....clueless). So if inter-domian trusts are a problem just consider AD to IPA! The advantage of a win and pass sync is its a very limited and controlable choke point. Indeed having winsync only capable of looking at one ou in AD means with your admins in a different ou its impossible for them to be mirrored into IPA....sort of high security by accident! ;] I guess its the age old battle between user usablity, their freedom and security....hackers really dont care.... So could I have a win/passsync to one AD and trusts to other IPAs and ADs? 1.9 sssd will be back ported to rhel5? regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ In addition to other comments I want to step back and give a bit of a bigger picture. 1) Regardless of what approach you choose we recommend using the latest available version at the moment of deployment. 2) There are two different approached to dealing with AD - sync or trust. You need to chose what approach you want to use. Down the road there might be some hybrid solutions but so far they are not supported. Sync: available starting the beginning of the IPA life. It has some limitations and we indeed had some issues with the corner cases that Steve's environment has. They are not common but you have been warned anyways. Trust: a) Trusts are targeting RHEL 6.4 b) There is no upgrade from Sync to Trust solution. If you want trusts you need to upgrade what you have to 6.4 (or start over) and implement trusts there and not do Sync. c) To take advantage of trusts your clients must be SSSD 1.9.x otherwise the trusts would not work. This also means that if you have other UNIXes the trusts would not work there. If you have UNIX clients that need to be accessed by AD users you might explore some hybrid solutions that might work but we can't say for sure. For example the sync might actually work in parallel to trusts to some extent. There is also PAM pass through capability that comes with 6.4 as a tech preview. That would allow pass through LDAP auth for the non SSSD 1.9 clients. But this needs to be tried out and there might be dragons. ========== dragons....lol...........my armour is well singed if not a bit runny....... regards From william.muriithi at gmail.com Mon Nov 5 18:40:29 2012 From: william.muriithi at gmail.com (William Muriithi) Date: Mon, 5 Nov 2012 13:40:29 -0500 Subject: [Freeipa-users] FreeIPA v 2.2 in an AD environment Message-ID: Rich, > > In addition to other comments I want to step back and give a bit of a > bigger picture. > 1) Regardless of what approach you choose we recommend using the latest > available version at the moment of deployment. Good suggestion. This mean I should use version 3. Problem that would have to run Fedora 17 and not happy with that option. Think I may have to wait for 6.4 before changing current setup as I like the trust setup more than the sync alternative > 2) There are two different approached to dealing with AD - sync or > trust. You need to chose what approach you want to use. Down the road > there might be some hybrid solutions but so far they are not supported. > > Sync: available starting the beginning of the IPA life. It has some > limitations and we indeed had some issues with the corner cases that > Steve's environment has. They are not common but you have been warned > anyways. Ok > > Trust: > a) Trusts are targeting RHEL 6.4 > b) There is no upgrade from Sync to Trust solution. If you want trusts > you need to upgrade what you have to 6.4 (or start over) and implement > trusts there and not do Sync. > c) To take advantage of trusts your clients must be SSSD 1.9.x otherwise > the trusts would not work. This also means that if you have other UNIXes > the trusts would not work there. That sucks. Would have been better if it only affected IPA server. Hopes there will not be too many dependencies that would make it impossible of updating to SSSD 1.9.x. why is this necessary if I may ask? Though most of the changes would be limited to the server side? Actually, a better question is, whats the difference between sync and trust? To me, sync mean pushing the username password pair through the passsync while trust mean pushing the username and password through samba4. Is this correct? > > If you have UNIX clients that need to be accessed by AD users you might > explore some hybrid solutions that might work but we can't say for sure. > For example the sync might actually work in parallel to trusts to some > extent. There is also PAM pass through capability that comes with 6.4 as > a tech preview. That would allow pass through LDAP auth for the non > SSSD 1.9 clients. But this needs to be tried out and there might be dragons. > Interesting, sound scarily to go there. Thank you > > William >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > > > ------------------------------ > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > End of Freeipa-users Digest, Vol 52, Issue 9 > ******************************************** From thughes at thegoldfish.org Mon Nov 5 18:51:39 2012 From: thughes at thegoldfish.org (Tim Hughes) Date: Mon, 5 Nov 2012 18:51:39 +0000 Subject: [Freeipa-users] Can't contact LDAP server: TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user Message-ID: I am trying to migrate from a fedora-ds-1.1.2-1.fc6 server to ipa-server-2.2.0-16.el6.x86_64 with the following command ipa migrate-ds ldaps://fedora-ds-server.internal --continue --with-compat --base-dn=dc=custsvc,dc=mycompany --user-container=ou=People,ou=custsvc,dc=co,dc=mycompany --group-container=ou=Groups,ou=custsvc,dc=co,dc=mycompany I get the following response. ipa: DEBUG: approved_usage = SSLServer intended_usage = SSLServer ipa: DEBUG: cert valid True for "CN=ipa-server.internal,O=CO.MYCOMPANY" ipa: DEBUG: handshake complete, peer = 192.168.10.6:443 ipa: DEBUG: Caught fault 4203 from server http://ipa-server.internal/ipa/xml: Can't contact LDAP server: TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user. ipa: DEBUG: Destroyed connection context.xmlclient ipa: ERROR: Can't contact LDAP server: TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user. I am trying to work out which certificate is not trusted and how I should make it trusted. Any help would be appreciated. Tim Hughes mailto:thughes at thegoldfish.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steven.Jones at vuw.ac.nz Mon Nov 5 18:52:38 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Mon, 5 Nov 2012 18:52:38 +0000 Subject: [Freeipa-users] FreeIPA v 2.2 in an AD environment In-Reply-To: References: Message-ID: <833D8E48405E064EBC54C84EC6B36E405471979B@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, Im not at work yet but the default is something like cn=users,dc=example,dc=com, its not needed to be specified though (maybe it should be to encourage ppl to check) so I did my first sync and wiped all my users out of IPA! oops.... So you have specify it with something like --win-subtree ou=staff_folder,dc=example,dc=com. Note its ou=staff_folder and not cn=staff_folder, I did that oops as well, doh.....also make sure the case is right...not sure if that matters.... So the command to winsync is done on the IPA server TO AD, the above tells the winsync script/command where to find the group to sync in AD. "sucked" Our AD and IPA is VMware'd so I had clones in an isolated environment....make sure you do a db2ldif of your IPA setup thats saved my test bed at least once. "smartphone issue" I have a hot fix, it seems OK, apparantly its fixed "proper" in the 6.4 release....which I think is either December or the new year.... Your very brave using centos....ie no support LOL.....its very complex and hard to fault find when things dont work... regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of William Muriithi [william.muriithi at gmail.com] Sent: Tuesday, 6 November 2012 7:13 a.m. To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] FreeIPA v 2.2 in an AD environment Steve, thanks > Hi, > > Yes you can winsync and passsync RHEL6.3 IPA from win2k3 r2 + AD, it should be in your RH supported channel tree? > Nope, using Centos 6.3. I checked and looks like I can find passsync.msi from here. I am hoping its the same Windows binaries supplied to RedHat paying customers http://directory.fedoraproject.org/wiki/Download > > 1) Only one AD domain, so if you have a AD "forest" you can only do one sub-domain. So if the root is "example.com" and you have "staff.example.com" and "clients.example.com" you can do only one, say staff.example.com to IPA. > > Possible issues, > > 2) There is a bug in the setup where you have to be careful that you specify the right OU= IF your users are not in the expected default (cn=users?), otherwise the IPA users get deleted rather than ignored, you end up with an empty IPA....frightened me senseless! Do you mind explaining this further please? Where are you specifying this? On the passsync.msi application "search base" field? on AD side or on "ipa-replica-manage --win-subtree" ? Expected default users CN, on which side, AD or FreeIPA? Sorry, I tried to google for the bug and I can't seem to pick it, so the question. > > So, > > a) If you have users in multiple ou's then only one set is synced the rest in IPA will go bye bye, unless they are unique to IPA. > b) If some users have a smartphone to exchange setup the winsync agreement sees that as the user having 2 ous's and first adds and then deletes those users......oops.....I lost 20% of my users that way.... Yikes, that would have sucked, hope you had a backup. I don't have sub-domain (Forest = domain), but would have been caught by the smartphone issue. Thanks for the heads up, really appreciates. > > This is with RH support. Hmm, hopefully their response will get to us none customers somehow. > > 3) Also with 6.2 or 6.2 upgraded to 6.3 you may find that when the winsync syncs, the IPA users lose all their groups. I have tested a 6.2 upgraded to 6.3 several times and this happens each time but a clean 6.3 IPA seems fine....we dont know why that is yet. > > This is with RH support, > > So if you are going to do this you need an isolated test setup to test for un-expected "features" that could really spoil your day. > > :( Yes, I am really grateful for asking before diving in. Looks like I would have got hurt really bad. > > My main advice would be restart with a clean 6.3 setup and not an upgraded from 6.2. Ive rebuilt 2 of my three IPA servers and teh 6.3 clean builds seem a lot more stable. > > Also use db2ldif to make backups of your database before you do it....also you might want to halt and turn off any IPA replicas when you do it until after you are happy its stable and OK. > Will use 6.3. Thank you again for the advice William > > ________________________________________ > From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of William Muriithi [william.muriithi at gmail.com] > Sent: Monday, 5 November 2012 8:23 a.m. > To: freeipa-users at redhat.com > Subject: [Freeipa-users] FreeIPA v 2.2 in an AD environment > > Hi all, > > I am in the process of deploying freeIPA 2.2 to authenticate Linux > systems and have been able to setup everything nicely with separate > domain. I mean users are currently using separate password to access > Linux system and another set of password from AD for desktop stuff. On > Friday, I came across an article on freeIPA v 3 and noticed one can > use the same username & password for both Linux and Windows systems. > I have since felt this would be a better setup and but feel like the > documentation are not clear on how to achieve the above. > > Would anyone be able to clarify this: > > - Can I be able to synchronize the current AD user credentials with > FreeIPA 2.2 or do I have to upgrade to FreeIPA 3.0 ? > - If upgrading is necessary, is there an RPM that can run on RHEL 6.2 > ? I can only seem to find freeIPA v3 RPM for Fedora 17. Was hoping > to use a blessed RPM instead of rolling one which mean be incompatible > with the distribution RPM once it comes around > > Regards, > > William > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > > ------------------------------ > > Message: 3 > Date: Mon, 05 Nov 2012 09:32:42 +0100 > From: Petr Spacek > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] FreeIPA for AMM users management > Message-ID: <509779AA.6010409 at redhat.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 11/03/2012 01:12 PM, Pavel Zhukov wrote: >>> Can you do NS lookup of the IPA server from the AMM box? >> yes >>> Can you do kinit from the AMM box against IPA? >>> Can you do ldapsearch from the AMM box against IPA? >> no, AMM has restricted shell and web GUI. > > Hmm, that is unfortunate. Can you run tcpdump (or sniffer provided on AMM) on > the link between AMM and IPA server? Because there are no records in access > log I will bet on some name resolution or firewall problem. > > Do AMM get right DNS responses (i.e. name and IP address of the IPA server)? > > Do AMM established TCP connection with the IPA server? > > -- > Petr^2 Spacek > >>> Do you see anything in the logs from such activity? > > > > ------------------------------ > > Message: 4 > Date: Mon, 05 Nov 2012 08:17:34 -0700 > From: Rich Megginson > To: Steven Jones > Cc: "freeipa-users at redhat.com" > Subject: Re: [Freeipa-users] FreeIPA v 2.2 in an AD environment > Message-ID: <5097D88E.1020508 at redhat.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 11/04/2012 01:25 PM, Steven Jones wrote: >> Hi, >> >> Yes you can winsync and passsync RHEL6.3 IPA from win2k3 r2 + AD, it should be in your RH supported channel tree? >> >> The passsync.msi has to go on each AD box > Each Domain Controller. > > Also note that you asked if "Can I be able to synchronize the current AD > user credentials with > FreeIPA 2.2 or do I have to upgrade to FreeIPA 3.0" > > You cannot synchronize already existing passwords with IPA 2.x. You > would have to force AD users to change their passwords in order to get > the clear text password to send to IPA. > >> and is a MSI supplied by RH, I think that's also in the RH support channel but for some strange reason I think it might be in the workstation tree and not server tree. >> >> > From what I can read there are some caveats, >> >> 1) Only one AD domain, so if you have a AD "forest" you can only do one sub-domain. So if the root is "example.com" and you have "staff.example.com" and "clients.example.com" you can do only one, say staff.example.com to IPA. >> >> Possible issues, >> >> 2) There is a bug in the setup where you have to be careful that you specify the right OU= IF your users are not in the expected default (cn=users?), otherwise the IPA users get deleted rather than ignored, you end up with an empty IPA....frightened me senseless! > https://fedorahosted.org/freeipa/ticket/2688 > and > https://fedorahosted.org/389/ticket/355 > > The problem is caused when you have a user ID in IPA that has the same > user ID as a user in AD, but you didn't want them to be synced, and the > AD user entry is outside the scope of the windows sync agreement. This > may or may not be a problem in your deployment. > >> >> So, >> >> a) If you have users in multiple ou's then only one set is synced the rest in IPA will go bye bye, unless they are unique to IPA. > See above. >> b) If some users have a smartphone to exchange setup the winsync agreement sees that as the user having 2 ous's and first adds and then deletes those users......oops.....I lost 20% of my users that way.... > Is there a ticket/bz for this issue, or is this the same issue as above? >> >> These are with RH support, I have a hot fix, I am testing. >> >> c) Its really hard to make sure all users have been transferred as you can only see 2000 users in IPA so something like an external tool like xplorer seem to be the only way for simpletons like myself to look at and compare. >> >> This is with RH support. > There are workarounds. >> >> 3) Also with 6.2 or 6.2 upgraded to 6.3 you may find that when the winsync syncs, the IPA users lose all their groups. I have tested a 6.2 upgraded to 6.3 several times and this happens each time but a clean 6.3 IPA seems fine....we dont know why that is yet. >> >> This is with RH support, >> >> So if you are going to do this you need an isolated test setup to test for un-expected "features" that could really spoil your day. >> >> :( >> >> My main advice would be restart with a clean 6.3 setup and not an upgraded from 6.2. Ive rebuilt 2 of my three IPA servers and teh 6.3 clean builds seem a lot more stable. >> >> Also use db2ldif to make backups of your database before you do it....also you might want to halt and turn off any IPA replicas when you do it until after you are happy its stable and OK. > You can also use db2ldif to get around the 2000 user limit mentioned above. >> >> regards >> >> Steven Jones >> >> Technical Specialist - Linux RHCE >> >> Victoria University, Wellington, NZ >> >> 0064 4 463 6272 >> >> ________________________________________ >> From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of William Muriithi [william.muriithi at gmail.com] >> Sent: Monday, 5 November 2012 8:23 a.m. >> To: freeipa-users at redhat.com >> Subject: [Freeipa-users] FreeIPA v 2.2 in an AD environment >> >> Hi all, >> >> I am in the process of deploying freeIPA 2.2 to authenticate Linux >> systems and have been able to setup everything nicely with separate >> domain. I mean users are currently using separate password to access >> Linux system and another set of password from AD for desktop stuff. On >> Friday, I came across an article on freeIPA v 3 and noticed one can >> use the same username& password for both Linux and Windows systems. >> I have since felt this would be a better setup and but feel like the >> documentation are not clear on how to achieve the above. >> >> Would anyone be able to clarify this: >> >> - Can I be able to synchronize the current AD user credentials with >> FreeIPA 2.2 or do I have to upgrade to FreeIPA 3.0 ? >> - If upgrading is necessary, is there an RPM that can run on RHEL 6.2 >> ? I can only seem to find freeIPA v3 RPM for Fedora 17. Was hoping >> to use a blessed RPM instead of rolling one which mean be incompatible >> with the distribution RPM once it comes around >> >> Regards, >> >> William >> >> _______________________________________________ >> 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 > > > > ------------------------------ > > Message: 5 > Date: Mon, 05 Nov 2012 10:48:26 -0500 > From: Dmitri Pal > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] FreeIPA v 2.2 in an AD environment > Message-ID: <5097DFCA.60607 at redhat.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On 11/04/2012 02:23 PM, William Muriithi wrote: >> Hi all, >> >> I am in the process of deploying freeIPA 2.2 to authenticate Linux >> systems and have been able to setup everything nicely with separate >> domain. I mean users are currently using separate password to access >> Linux system and another set of password from AD for desktop stuff. On >> Friday, I came across an article on freeIPA v 3 and noticed one can >> use the same username & password for both Linux and Windows systems. >> I have since felt this would be a better setup and but feel like the >> documentation are not clear on how to achieve the above. >> >> Would anyone be able to clarify this: >> >> - Can I be able to synchronize the current AD user credentials with >> FreeIPA 2.2 or do I have to upgrade to FreeIPA 3.0 ? >> - If upgrading is necessary, is there an RPM that can run on RHEL 6.2 >> ? I can only seem to find freeIPA v3 RPM for Fedora 17. Was hoping >> to use a blessed RPM instead of rolling one which mean be incompatible >> with the distribution RPM once it comes around >> >> Regards, >> >> William > > In addition to other comments I want to step back and give a bit of a > bigger picture. > 1) Regardless of what approach you choose we recommend using the latest > available version at the moment of deployment. > 2) There are two different approached to dealing with AD - sync or > trust. You need to chose what approach you want to use. Down the road > there might be some hybrid solutions but so far they are not supported. > > Sync: available starting the beginning of the IPA life. It has some > limitations and we indeed had some issues with the corner cases that > Steve's environment has. They are not common but you have been warned > anyways. > > Trust: > a) Trusts are targeting RHEL 6.4 > b) There is no upgrade from Sync to Trust solution. If you want trusts > you need to upgrade what you have to 6.4 (or start over) and implement > trusts there and not do Sync. > c) To take advantage of trusts your clients must be SSSD 1.9.x otherwise > the trusts would not work. This also means that if you have other UNIXes > the trusts would not work there. > > If you have UNIX clients that need to be accessed by AD users you might > explore some hybrid solutions that might work but we can't say for sure. > For example the sync might actually work in parallel to trusts to some > extent. There is also PAM pass through capability that comes with 6.4 as > a tech preview. That would allow pass through LDAP auth for the non > SSSD 1.9 clients. But this needs to be tried out and there might be dragons. > > > >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > > > ------------------------------ > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > End of Freeipa-users Digest, Vol 52, Issue 9 > ******************************************** _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From Steven.Jones at vuw.ac.nz Mon Nov 5 19:01:26 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Mon, 5 Nov 2012 19:01:26 +0000 Subject: [Freeipa-users] FreeIPA v 2.2 in an AD environment In-Reply-To: References: Message-ID: <833D8E48405E064EBC54C84EC6B36E40547197DC@STAWINCOX10MBX1.staff.vuw.ac.nz> corner case? as in not very standard? In which case, yes I suppose so. AD is a very complex thing and you can customise it it seems. As a Linux person wandering into such a thing as a non-standard AD and not knowing this its a bit of a minefield.....but of course you dont know you are in one! so dont know what to ask....experience the hard way. Dragons, yes my armour is definately a bit runny.... regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 8><---------- > Sync: available starting the beginning of the IPA life. It has some > limitations and we indeed had some issues with the corner cases that > Steve's environment has. They are not common but you have been warned > anyways. 8><----------- From mbarr at snap-interactive.com Mon Nov 5 19:13:09 2012 From: mbarr at snap-interactive.com (Matthew Barr) Date: Mon, 5 Nov 2012 14:13:09 -0500 Subject: [Freeipa-users] FreeIPA start dependencies In-Reply-To: <509800A2.3000808@redhat.com> References: <509800A2.3000808@redhat.com> Message-ID: <2863A0B7-4174-46E5-8590-0B49E0C46DB0@snap-interactive.com> >> * We're using IPA for DNS as well as the kerberos & LDAP services. > > Is it installed with forwarders to some other DNS server? Is that server alive and running? It is reachable? > If not you might want to add host name and IP of the IPA server into the /etc/hosts Yep, that was the ticket. Host file entry is the key.. Thanks! From rcritten at redhat.com Mon Nov 5 19:16:33 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 05 Nov 2012 14:16:33 -0500 Subject: [Freeipa-users] FreeIPA v 2.2 in an AD environment In-Reply-To: <833D8E48405E064EBC54C84EC6B36E4054719746@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E4054716A9B@STAWINCOX10MBX1.staff.vuw.ac.nz>, <5097D88E.1020508@redhat.com> <833D8E48405E064EBC54C84EC6B36E4054719746@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <50981091.4070605@redhat.com> Steven Jones wrote: > "Also note that you asked if "Can I be able to synchronize the current AD > user credentials with > FreeIPA 2.2 or do I have to upgrade to FreeIPA 3.0" > You cannot synchronize already existing passwords with IPA 2.x. You > would have to force AD users to change their passwords in order to get > the clear text password to send to IPA." > > Given the password in AD is encrypted I would assume that this will apply to any version of IPA? Right. We aren't in the business of cracking existing passwords. When using PassSync the only way for us to get the password is for it to be changed. With trust the users don't exist on the IPA side, so this isn't an issue. > Unless 3+ goes back to AD to confirm the password there? With trust, tickets from the AD server are accepted as-is. With winsync the same rules apply as with 2.x (and 1.x for that matter). rob From erinn.looneytriggs at gmail.com Mon Nov 5 19:19:54 2012 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Mon, 05 Nov 2012 10:19:54 -0900 Subject: [Freeipa-users] Updating the CA certificate Message-ID: <5098115A.9050301@gmail.com> I hope I haven't missed it in searching around, but how does one update the CA certificate in IPA? Though it is a year out from expiring I would rather know sooner than later when it comes to this. -Erinn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 551 bytes Desc: OpenPGP digital signature URL: From rcritten at redhat.com Mon Nov 5 19:25:37 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 05 Nov 2012 14:25:37 -0500 Subject: [Freeipa-users] Updating the CA certificate In-Reply-To: <5098115A.9050301@gmail.com> References: <5098115A.9050301@gmail.com> Message-ID: <509812B1.6060402@redhat.com> Erinn Looney-Triggs wrote: > I hope I haven't missed it in searching around, but how does one update > the CA certificate in IPA? > > Though it is a year out from expiring I would rather know sooner than > later when it comes to this. Kudos for planning ahead! What kind of CA do you have installed. Are you using a dogtag backend CA or did you install with the selfsign method? rob From erinn.looneytriggs at gmail.com Mon Nov 5 19:27:14 2012 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Mon, 05 Nov 2012 10:27:14 -0900 Subject: [Freeipa-users] Updating the CA certificate In-Reply-To: <509812B1.6060402@redhat.com> References: <5098115A.9050301@gmail.com> <509812B1.6060402@redhat.com> Message-ID: <50981312.70308@gmail.com> On 11/05/12 10:25, Rob Crittenden wrote: > Erinn Looney-Triggs wrote: >> I hope I haven't missed it in searching around, but how does one update >> the CA certificate in IPA? >> >> Though it is a year out from expiring I would rather know sooner than >> later when it comes to this. > > Kudos for planning ahead! > > What kind of CA do you have installed. Are you using a dogtag backend CA > or did you install with the selfsign method? > > rob > Using dogtag CA and it is replicated, though, and I am not sure if this makes an difference, it is a subordinate CA that has been issued by an AD PKI setup. -Erinn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 551 bytes Desc: OpenPGP digital signature URL: From rcritten at redhat.com Mon Nov 5 19:42:06 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 05 Nov 2012 14:42:06 -0500 Subject: [Freeipa-users] Updating the CA certificate In-Reply-To: <50981312.70308@gmail.com> References: <5098115A.9050301@gmail.com> <509812B1.6060402@redhat.com> <50981312.70308@gmail.com> Message-ID: <5098168E.40603@redhat.com> Erinn Looney-Triggs wrote: > On 11/05/12 10:25, Rob Crittenden wrote: >> Erinn Looney-Triggs wrote: >>> I hope I haven't missed it in searching around, but how does one update >>> the CA certificate in IPA? >>> >>> Though it is a year out from expiring I would rather know sooner than >>> later when it comes to this. >> >> Kudos for planning ahead! >> >> What kind of CA do you have installed. Are you using a dogtag backend CA >> or did you install with the selfsign method? >> >> rob >> > > Using dogtag CA and it is replicated, though, and I am not sure if this > makes an difference, it is a subordinate CA that has been issued by an > AD PKI setup. You'll need to start with your AD PKI. I'm assuming it is expiring as well since the IPA CA validity period is limited by its issuer. Are you going to rekey the AD CA or renew the current CA cert? rob From erinn.looneytriggs at gmail.com Mon Nov 5 19:50:06 2012 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Mon, 05 Nov 2012 10:50:06 -0900 Subject: [Freeipa-users] Updating the CA certificate In-Reply-To: <5098168E.40603@redhat.com> References: <5098115A.9050301@gmail.com> <509812B1.6060402@redhat.com> <50981312.70308@gmail.com> <5098168E.40603@redhat.com> Message-ID: <5098186E.8070401@gmail.com> On 11/05/12 10:42, Rob Crittenden wrote: > Erinn Looney-Triggs wrote: >> On 11/05/12 10:25, Rob Crittenden wrote: >>> Erinn Looney-Triggs wrote: >>>> I hope I haven't missed it in searching around, but how does one update >>>> the CA certificate in IPA? >>>> >>>> Though it is a year out from expiring I would rather know sooner than >>>> later when it comes to this. >>> >>> Kudos for planning ahead! >>> >>> What kind of CA do you have installed. Are you using a dogtag backend CA >>> or did you install with the selfsign method? >>> >>> rob >>> >> >> Using dogtag CA and it is replicated, though, and I am not sure if this >> makes an difference, it is a subordinate CA that has been issued by an >> AD PKI setup. > > You'll need to start with your AD PKI. I'm assuming it is expiring as > well since the IPA CA validity period is limited by its issuer. Are you > going to rekey the AD CA or renew the current CA cert? > > rob > Subordinate CAs from the AD by default are only valid for two years, whereas by default the CA for the AD is valid for 10 years. So only the subordinate cert is being reissued. The key won't be changing on the IPA end, just the cert. Normally this would just be an import new cert type thing, but I am unsure in the IPA environment. Make sense? -Erinn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 551 bytes Desc: OpenPGP digital signature URL: From mmercier at gmail.com Mon Nov 5 21:35:37 2012 From: mmercier at gmail.com (Michael Mercier) Date: Mon, 5 Nov 2012 16:35:37 -0500 Subject: [Freeipa-users] DNS / Allow PTR sync Message-ID: <4322F5FE-3B82-48D6-8D3E-E4298A32F278@gmail.com> Hello, A couple of questions regarding DNS / Allow PTR sync. 1. If you have a zone 'example.com' and you enable "Allow PTR sync", should you also enable the option in the reverse zone (e.g. 168.192.in-addr-arpa.)? 2. Do you have to wait a specified amount of time for the PTR record to be removed after you remove a host? e.g. 1. Add 'testhost', 192.168.10.10 to 'example.com' (with Allow PTR sync enabled on the zone) with 'Create reverse' enabled. 2. Remove 'testhost' from 'example.com' 3. Check 168.192.in-addr.arpa. zone and host 'testhost' still exists. Thanks, Mike From dpal at redhat.com Mon Nov 5 22:32:08 2012 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 05 Nov 2012 17:32:08 -0500 Subject: [Freeipa-users] Can't contact LDAP server: TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user In-Reply-To: References: Message-ID: <50983E68.1050508@redhat.com> On 11/05/2012 01:51 PM, Tim Hughes wrote: > > I am trying to migrate from a fedora-ds-1.1.2-1.fc6 server to > ipa-server-2.2.0-16.el6.x86_64 with the following command > > > ipa migrate-ds ldaps://fedora-ds-server.internal --continue > --with-compat --base-dn=dc=custsvc,dc=mycompany > --user-container=ou=People,ou=custsvc,dc=co,dc=mycompany > --group-container=ou=Groups,ou=custsvc,dc=co,dc=mycompany > You are using ldaps but there is no cert info defined to connect to fedora-DS with SSL. Did you mean ldap://... ? > > I get the following response. > > > ipa: DEBUG: approved_usage = SSLServer intended_usage = SSLServer > ipa: DEBUG: cert valid True for "CN=ipa-server.internal,O=CO.MYCOMPANY" > ipa: DEBUG: handshake complete, peer = 192.168.10.6:443 > > ipa: DEBUG: Caught fault 4203 from server > http://ipa-server.internal/ipa/xml: Can't contact LDAP server: TLS > error -8172:Peer's certificate issuer has been marked as not trusted > by the user. > ipa: DEBUG: Destroyed connection context.xmlclient > ipa: ERROR: Can't contact LDAP server: TLS error -8172:Peer's > certificate issuer has been marked as not trusted by the user. > > > I am trying to work out which certificate is not trusted and how I > should make it trusted. Any help would be appreciated. > > > Tim Hughes > mailto:thughes at thegoldfish.org > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcello.giannoni at ucla.edu Mon Nov 5 22:57:37 2012 From: marcello.giannoni at ucla.edu (Marcello Giannoni UCLA) Date: Mon, 5 Nov 2012 14:57:37 -0800 Subject: [Freeipa-users] Restrict user access Message-ID: <5FEC8271-D709-4D32-B569-07B9F3750648@ucla.edu> Hi, I defined some users that are not members of the ipausers group, for some reason this users are able to login to the server using the ipa client tools and the web interface https://myipaserver/ipa/ui I don't want any users look at other users information, is there a way to deny access to the ipa client tools and Web UI to his non ipausers? Thank you Marcello From dpal at redhat.com Mon Nov 5 23:45:15 2012 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 05 Nov 2012 18:45:15 -0500 Subject: [Freeipa-users] FreeIPA v 2.2 in an AD environment In-Reply-To: References: Message-ID: <50984F8B.2090907@redhat.com> On 11/05/2012 01:40 PM, William Muriithi wrote: > Rich, > >> In addition to other comments I want to step back and give a bit of a >> bigger picture. >> 1) Regardless of what approach you choose we recommend using the latest >> available version at the moment of deployment. > Good suggestion. This mean I should use version 3. Problem that would > have to run Fedora 17 and not happy with that option. Think I may > have to wait for 6.4 before changing current setup as I like the trust > setup more than the sync alternative > >> 2) There are two different approached to dealing with AD - sync or >> trust. You need to chose what approach you want to use. Down the road >> there might be some hybrid solutions but so far they are not supported. >> >> Sync: available starting the beginning of the IPA life. It has some >> limitations and we indeed had some issues with the corner cases that >> Steve's environment has. They are not common but you have been warned >> anyways. > Ok > >> Trust: >> a) Trusts are targeting RHEL 6.4 >> b) There is no upgrade from Sync to Trust solution. If you want trusts >> you need to upgrade what you have to 6.4 (or start over) and implement >> trusts there and not do Sync. >> c) To take advantage of trusts your clients must be SSSD 1.9.x otherwise >> the trusts would not work. This also means that if you have other UNIXes >> the trusts would not work there. > That sucks. Would have been better if it only affected IPA server. > Hopes there will not be too many dependencies that would make it > impossible of updating to SSSD 1.9.x. why is this necessary if I may > ask? Though most of the changes would be limited to the server side? Unfortunately know. The client does a lot of heavy lifting. Client needs to understand that the ticket the user is using to access the system is coming from AD thus has authorization data in the form of MS-PAC. This data need to be extracted and processed. The remapping of the MSFT ids called SIDs needs to be conducted, the SIDs need to be resolved to names so that when you say id you can get user name from AD. The interactions happen with IPA since some of the information is provided and controlled by IPA while some other things need to be looked up in AD. Trust is a very complex environment. There was a lot of development that IPA and SSSD project teams worked on jointly. > > Actually, a better question is, whats the difference between sync and > trust? To me, sync mean pushing the username password pair through > the passsync while trust mean pushing the username and password > through samba4. Is this correct? No. The trust means no pushing. Once you establish trust between IPA and AD users will remain in AD and would be able to access systems and resources managed by IPA without any push of the accounts and passwords from AD to IPA or any other place. That is the beauty. All AD users still authenticate against AD, get Kerberos ticket and then using this ticket can contact systems and services on the IPA side. > >> If you have UNIX clients that need to be accessed by AD users you might >> explore some hybrid solutions that might work but we can't say for sure. >> For example the sync might actually work in parallel to trusts to some >> extent. There is also PAM pass through capability that comes with 6.4 as >> a tech preview. That would allow pass through LDAP auth for the non >> SSSD 1.9 clients. But this needs to be tried out and there might be dragons. >> > Interesting, sound scarily to go there. Thank you Not that scary. Just depends on you level of comfort about experimenting with your test environment and proving something works. We have seen on multiple occasions when people asked us something and we said "it might work, we are not sure" and people tried and were successful. Such experiments have a benefit of once being tried and recorded they (if not absolutely crazy) pave a way for future support of the feature in RHEL. >> > William >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager for IdM portfolio >> Red Hat Inc. >> >> >> ------------------------------- >> Looking to carve out IT costs? >> www.redhat.com/carveoutcosts/ >> >> >> >> >> >> ------------------------------ >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> End of Freeipa-users Digest, Vol 52, Issue 9 >> ******************************************** > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Mon Nov 5 23:55:28 2012 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 05 Nov 2012 18:55:28 -0500 Subject: [Freeipa-users] FreeIPA v 2.2 in an AD environment In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40547197DC@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E40547197DC@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <509851F0.4040700@redhat.com> On 11/05/2012 02:01 PM, Steven Jones wrote: > corner case? > > as in not very standard? > > In which case, yes I suppose so. AD is a very complex thing and you can customise it it seems. As a Linux person wandering into such a thing as a non-standard AD and not knowing this its a bit of a minefield.....but of course you dont know you are in one! so dont know what to ask....experience the hard way. Dragons, yes my armour is definately a bit runny.... Steven, let me put this way: you were unlucky to be the first to produce the configuration we never seen before (AD sync is a part of DS for ages). Things evolve on the AD side and we are not the first to know or experience new changes and configurations that AD adds. AD in fact big and complex. I am sorry about what you have been through but we unfortunately did not anticipate the scenarios and configuration that you presented. For us they were the corner cases at the moment. Now they are not since you hit them, we learned the details of those issues and addressed them. > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > 8><---------- > >> Sync: available starting the beginning of the IPA life. It has some >> limitations and we indeed had some issues with the corner cases that >> Steve's environment has. They are not common but you have been warned >> anyways. > 8><----------- > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Tue Nov 6 00:04:51 2012 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 05 Nov 2012 19:04:51 -0500 Subject: [Freeipa-users] Restrict user access In-Reply-To: <5FEC8271-D709-4D32-B569-07B9F3750648@ucla.edu> References: <5FEC8271-D709-4D32-B569-07B9F3750648@ucla.edu> Message-ID: <50985423.6060102@redhat.com> On 11/05/2012 05:57 PM, Marcello Giannoni UCLA wrote: > Hi, > > I defined some users that are not members of the ipausers group, for some reason this users are able to login to the server using the ipa client tools and the web interface https://myipaserver/ipa/ui > I don't want any users look at other users information, is there a way to deny access to the ipa client tools and Web UI to his non ipausers? > > Thank you > Marcello > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users What do you mean access? You mean read or modify? In general the LDAP is usually open for read for anyone. In the past it was open even to anonymous i.e unauthenticated user. In recent years the requirement to expose LDAP to only authenticated users have become popular (and that is what IPA supports) but not to the extent of limiting what one can read once authenticated. By default all the readable attributes are readable to everybody. So before moving forward please make sure that you realize that most of the software that uses LDAP as a central repository expects at least read only access after authenticated bind. Now the solution. You need to explore the privileges and permissions and define those to prevent access to the specific attributes. The things that you are trying to do might be so advanced that it might require you to get under the hood and work directly with DS ACIs rather than with the IPA commands. Are you trying to close read access to specific private attributes in the user entry? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Tue Nov 6 00:12:25 2012 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 05 Nov 2012 19:12:25 -0500 Subject: [Freeipa-users] DNS / Allow PTR sync In-Reply-To: <4322F5FE-3B82-48D6-8D3E-E4298A32F278@gmail.com> References: <4322F5FE-3B82-48D6-8D3E-E4298A32F278@gmail.com> Message-ID: <509855E9.7090204@redhat.com> On 11/05/2012 04:35 PM, Michael Mercier wrote: > Hello, > > A couple of questions regarding DNS / Allow PTR sync. > > 1. If you have a zone 'example.com' and you enable "Allow PTR sync", should you also enable the option in the reverse zone (e.g. 168.192.in-addr-arpa.)? > 2. Do you have to wait a specified amount of time for the PTR record to be removed after you remove a host? > > e.g. > > 1. Add 'testhost', 192.168.10.10 to 'example.com' (with Allow PTR sync enabled on the zone) with 'Create reverse' enabled. > 2. Remove 'testhost' from 'example.com' > 3. Check 168.192.in-addr.arpa. zone and host 'testhost' still exists. Which version you are using? Do you use #ipa host-del --updatedns when delete host? > > Thanks, > Mike > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Tue Nov 6 00:19:46 2012 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 05 Nov 2012 19:19:46 -0500 Subject: [Freeipa-users] FreeIPA v 2.2 in an AD environment In-Reply-To: <833D8E48405E064EBC54C84EC6B36E4054719774@STAWINCOX10MBX1.staff.vuw.ac.nz> References: , <5097DFCA.60607@redhat.com> <833D8E48405E064EBC54C84EC6B36E4054719774@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <509857A2.9010800@redhat.com> On 11/05/2012 01:34 PM, Steven Jones wrote: > nice (and nice its in 6.4) > > :) > > I need to read up on trusts. > > However from limited experience in an AD forests with trusts they get very complex and the security can go bye bye. Ive seen pen tests that come in from a trusted domain, using an account with too many privaledges a bad password in a poorly implimented AD get across to the root and rainbow the password table (and hence domain admin) via a trust of a well set up one...own AD own IPA. > > "poorly" also of course windows admins dont understand IPA or linux and linux admins dont understand AD or windows both are really specialists of complex environments in their own right. (Which cracks me up when I see adverts for linux gurus and must have 3 to 5 years experience with AD....and paying peanuts....doh....clueless). So if inter-domian trusts are a problem just consider AD to IPA! > > The advantage of a win and pass sync is its a very limited and controlable choke point. Indeed having winsync only capable of looking at one ou in AD means with your admins in a different ou its impossible for them to be mirrored into IPA....sort of high security by accident! > > ;] > > I guess its the age old battle between user usablity, their freedom and security....hackers really dont care.... > > So could I have a win/passsync to one AD and trusts to other IPAs and ADs? May be. You know about dragons though. ;-) > > 1.9 sssd will be back ported to rhel5? Mnnnn... Sorry. No. It is too big and complex in terms of dependencies to backport. There have been many improvments to different packages that make possible for SSSD to perform its magic. > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > > > In addition to other comments I want to step back and give a bit of a > bigger picture. > 1) Regardless of what approach you choose we recommend using the latest > available version at the moment of deployment. > 2) There are two different approached to dealing with AD - sync or > trust. You need to chose what approach you want to use. Down the road > there might be some hybrid solutions but so far they are not supported. > > Sync: available starting the beginning of the IPA life. It has some > limitations and we indeed had some issues with the corner cases that > Steve's environment has. They are not common but you have been warned > anyways. > > Trust: > a) Trusts are targeting RHEL 6.4 > b) There is no upgrade from Sync to Trust solution. If you want trusts > you need to upgrade what you have to 6.4 (or start over) and implement > trusts there and not do Sync. > c) To take advantage of trusts your clients must be SSSD 1.9.x otherwise > the trusts would not work. This also means that if you have other UNIXes > the trusts would not work there. > > If you have UNIX clients that need to be accessed by AD users you might > explore some hybrid solutions that might work but we can't say for sure. > For example the sync might actually work in parallel to trusts to some > extent. There is also PAM pass through capability that comes with 6.4 as > a tech preview. That would allow pass through LDAP auth for the non > SSSD 1.9 clients. But this needs to be tried out and there might be dragons. > > ========== > > dragons....lol...........my armour is well singed if not a bit runny....... > > regards > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From Steven.Jones at vuw.ac.nz Tue Nov 6 00:35:09 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 6 Nov 2012 00:35:09 +0000 Subject: [Freeipa-users] FreeIPA v 2.2 in an AD environment In-Reply-To: <509851F0.4040700@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E40547197DC@STAWINCOX10MBX1.staff.vuw.ac.nz>, <509851F0.4040700@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E405471B5BB@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, Yes.....In hindsight its pretty obvious when you have a new product connecting to another complex product in a "foreign way" in a enterprise / complex environment that some shake-out is going to happen. I guess I didnt know what I didnt know and I got accelerated in deploying IPA faster and further than I'd said was what I wanted....hence some Dragons...(quite like that).... The only issue Ive had really is the speed of solving, not the solving....but RH support has definitely stepped up to the plate and is now significantly better, huge learning curve. Hopefully my successors will have that benefit. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Dmitri Pal [dpal at redhat.com] Sent: Tuesday, 6 November 2012 12:55 p.m. To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] FreeIPA v 2.2 in an AD environment On 11/05/2012 02:01 PM, Steven Jones wrote: > corner case? > > as in not very standard? > > In which case, yes I suppose so. AD is a very complex thing and you can customise it it seems. As a Linux person wandering into such a thing as a non-standard AD and not knowing this its a bit of a minefield.....but of course you dont know you are in one! so dont know what to ask....experience the hard way. Dragons, yes my armour is definately a bit runny.... Steven, let me put this way: you were unlucky to be the first to produce the configuration we never seen before (AD sync is a part of DS for ages). Things evolve on the AD side and we are not the first to know or experience new changes and configurations that AD adds. AD in fact big and complex. I am sorry about what you have been through but we unfortunately did not anticipate the scenarios and configuration that you presented. For us they were the corner cases at the moment. Now they are not since you hit them, we learned the details of those issues and addressed them. > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > 8><---------- > >> Sync: available starting the beginning of the IPA life. It has some >> limitations and we indeed had some issues with the corner cases that >> Steve's environment has. They are not common but you have been warned >> anyways. > 8><----------- > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From pspacek at redhat.com Tue Nov 6 09:38:25 2012 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 06 Nov 2012 10:38:25 +0100 Subject: [Freeipa-users] DNS / Allow PTR sync In-Reply-To: <4322F5FE-3B82-48D6-8D3E-E4298A32F278@gmail.com> References: <4322F5FE-3B82-48D6-8D3E-E4298A32F278@gmail.com> Message-ID: <5098DA91.7040205@redhat.com> Hello Mike, are you talking about IPA WebUI or CLI or DNS dynamic update mechanism? On which distribution and IPA version? On 11/05/2012 10:35 PM, Michael Mercier wrote: > Hello, > > A couple of questions regarding DNS / Allow PTR sync. > > 1. If you have a zone 'example.com' and you enable "Allow PTR sync", should you also enable the option in the reverse zone (e.g. 168.192.in-addr-arpa.)? In webUI - just check the box "Create reverse" while adding a new A record. "Allow PTR sync" affects only DNS dynamic update. > 2. Do you have to wait a specified amount of time for the PTR record to be removed after you remove a host? No, you don't. Change in webUI should be done immediately. For some time you can see old data on DNS clients because DNS caches all the data extensively. > > e.g. > > 1. Add 'testhost', 192.168.10.10 to 'example.com' (with Allow PTR sync enabled on the zone) with 'Create reverse' enabled. > 2. Remove 'testhost' from 'example.com' > 3. Check 168.192.in-addr.arpa. zone and host 'testhost' still exists. Seems like a bug to me, please file a ticket: https://fedorahosted.org/freeipa/newticket You will be prompted for Fedora account, registration link is: https://admin.fedoraproject.org/accounts/user/new Also, please note limitations of syncPTR on DNS server - it affects DNS dynamic updates: * If the change was made through IPA CLI/WebUI/LDAP directly - it does nothing in any case. * If idnsAllowSyncPTR = true and any A or AAAA record was changed through DNS dynamic update mechanism - PTR is automatically updated. * Change is synchronized only if reverse zone is part of LDAP and have dynamic updates allowed (idnsAllowDynUpdate = TRUE). * Enabling idnsAllowSyncPTR will not affect existing records as long as they are not updated though DNS dynamic updates. -- Petr^2 Spacek From mkosek at redhat.com Tue Nov 6 09:45:10 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 06 Nov 2012 10:45:10 +0100 Subject: [Freeipa-users] DNS / Allow PTR sync In-Reply-To: <5098DA91.7040205@redhat.com> References: <4322F5FE-3B82-48D6-8D3E-E4298A32F278@gmail.com> <5098DA91.7040205@redhat.com> Message-ID: <5098DC26.1020608@redhat.com> On 11/06/2012 10:38 AM, Petr Spacek wrote: > Hello Mike, > > are you talking about IPA WebUI or CLI or DNS dynamic update mechanism? On > which distribution and IPA version? > > On 11/05/2012 10:35 PM, Michael Mercier wrote: >> Hello, >> >> A couple of questions regarding DNS / Allow PTR sync. >> >> 1. If you have a zone 'example.com' and you enable "Allow PTR sync", should >> you also enable the option in the reverse zone (e.g. 168.192.in-addr-arpa.)? > In webUI - just check the box "Create reverse" while adding a new A record. > "Allow PTR sync" affects only DNS dynamic update. > >> 2. Do you have to wait a specified amount of time for the PTR record to be >> removed after you remove a host? > No, you don't. Change in webUI should be done immediately. For some time you > can see old data on DNS clients because DNS caches all the data extensively. > >> >> e.g. >> >> 1. Add 'testhost', 192.168.10.10 to 'example.com' (with Allow PTR sync >> enabled on the zone) with 'Create reverse' enabled. >> 2. Remove 'testhost' from 'example.com' >> 3. Check 168.192.in-addr.arpa. zone and host 'testhost' still exists. Did you have "Remove entries from DNS" checkbox checked when removing a host? Alternatively, you would need to use --updatedns option if you were running it via CLI. If yes, then please file a ticket as Petr suggested. Thank you, Martin From mmercier at gmail.com Tue Nov 6 11:33:48 2012 From: mmercier at gmail.com (Michael Mercier) Date: Tue, 6 Nov 2012 06:33:48 -0500 Subject: [Freeipa-users] Fwd: DNS / Allow PTR sync References: Message-ID: Hello, I missed the reply all button. See my response to Dmitri inline below. Thanks, Mike Begin forwarded message: > From: Michael Mercier > Date: November 5, 2012 8:10:53 PM GMT-05:00 > To: dpal at redhat.com > Subject: Re: [Freeipa-users] DNS / Allow PTR sync > > Hello, > > On 5-Nov-12, at 7:12 PM, Dmitri Pal wrote: > >> On 11/05/2012 04:35 PM, Michael Mercier wrote: >>> Hello, >>> >>> A couple of questions regarding DNS / Allow PTR sync. >>> >>> 1. If you have a zone 'example.com' and you enable "Allow PTR >>> sync", should you also enable the option in the reverse zone (e.g. >>> 168.192.in-addr-arpa.)? >>> 2. Do you have to wait a specified amount of time for the PTR >>> record to be removed after you remove a host? >>> >>> e.g. >>> >>> 1. Add 'testhost', 192.168.10.10 to 'example.com' (with Allow PTR >>> sync enabled on the zone) with 'Create reverse' enabled. >>> 2. Remove 'testhost' from 'example.com' >>> 3. Check 168.192.in-addr.arpa. zone and host 'testhost' still >>> exists. >> >> Which version you are using? > > I knew this question was coming as soon as I pressed 'send'... :D > > IPA 2.2 on CentOS 6.3 (latest RPM's) > >> >> Do you use >> >> #ipa host-del --updatedns > > The DNS entries are not IPA hosts (i.e. not added with ipa host- > add). Most of the DNS entries were added by performing the following: > > ipa dnsrecord-add example.com --a-rec=x.x.x.x --a-create- > reverse > > My example above was done using the GUI using the DNS page. > > Thanks, > Mike > >> >> when delete host? >> >>> >>> Thanks, >>> Mike >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager for IdM portfolio >> Red Hat Inc. >> >> >> ------------------------------- >> Looking to carve out IT costs? >> www.redhat.com/carveoutcosts/ >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Nov 6 13:07:38 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 06 Nov 2012 08:07:38 -0500 Subject: [Freeipa-users] Can't contact LDAP server: TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user In-Reply-To: References: Message-ID: <50990B9A.7040205@redhat.com> Tim Hughes wrote: > > I am trying to migrate from a fedora-ds-1.1.2-1.fc6 server to > ipa-server-2.2.0-16.el6.x86_64 with the following command > > > ipa migrate-ds ldaps://fedora-ds-server.internal --continue > --with-compat --base-dn=dc=custsvc,dc=mycompany > --user-container=ou=People,ou=custsvc,dc=co,dc=mycompany > --group-container=ou=Groups,ou=custsvc,dc=co,dc=mycompany > > > I get the following response. > > > ipa: DEBUG: approved_usage = SSLServer intended_usage = SSLServer > ipa: DEBUG: cert valid True for "CN=ipa-server.internal,O=CO.MYCOMPANY" > ipa: DEBUG: handshake complete, peer = 192.168.10.6:443 > > ipa: DEBUG: Caught fault 4203 from server > http://ipa-server.internal/ipa/xml: Can't contact LDAP server: TLS error > -8172:Peer's certificate issuer has been marked as not trusted by the user. > ipa: DEBUG: Destroyed connection context.xmlclient > ipa: ERROR: Can't contact LDAP server: TLS error -8172:Peer's > certificate issuer has been marked as not trusted by the user. > > > I am trying to work out which certificate is not trusted and how I > should make it trusted. Any help would be appreciated. I suspect you're going to need to add the CA that issued your LDAP server certificate to the IPA Apache NSS certificate database (where our admin framework runs). You'd add it something like this: # certutil -A -d /etc/httpd/alias -n 'LDAP CA' -t CT,C,C -a < /path/to/ca.crt The -n 'LDAP CA' adds a nickname to the CA. There is nothing special about this, it just needs to be unique. Use something meaningful to you. Then restart the httpd service and try the migration again. I don't know if we've tested using ldaps, so if my suggestion works can you let us know? rob From jsunn at nets.eu Tue Nov 6 06:33:07 2012 From: jsunn at nets.eu (Johan Sunnerstig) Date: Tue, 6 Nov 2012 06:33:07 +0000 Subject: [Freeipa-users] Process open FD table is full. In-Reply-To: <5093F837.6050705@redhat.com> References: <5092F476.6090903@gmail.com> <1351868807.18469.174.camel@willson.li.ssimo.org> <5093E6AE.40902@redhat.com> <5093F7CB.8010707@gmail.com> <5093F837.6050705@redhat.com> Message-ID: Thanks, I can't view the bug either but I'll pass it on in my support case. Erinn, in case it helps my support case # is 00646841. Oh and sorry for the mail formatting, Outlook at work... Regards Johan -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Rich Megginson Sent: den 2 november 2012 17:44 To: Erinn Looney-Triggs Cc: FreeIPAUsers Subject: Re: [Freeipa-users] Process open FD table is full. On 11/02/2012 10:41 AM, Erinn Looney-Triggs wrote: > On 11/02/12 07:28, Rich Megginson wrote: >> On 11/02/2012 09:06 AM, Simo Sorce wrote: >>> On Fri, 2012-11-02 at 08:38 +0000, Johan Sunnerstig wrote: >>>> Looks a lot like a problem I have as well. >>>> Check out the /proc/xxx/fd directory of the dirsrv process for your >>>> IPA realm, in my case it's full of dead pointers to >>>> /var/tmp/ldap_xxx where xxx will be the same on one IPA server(I >>>> have two in a multi-master setup). >>>> These don't clear out until I restart the dirsrv process, so >>>> eventually they'll fill up to the FD limit. For now I have a cron >>>> job performing a staggered IPA restart on the two servers and a >>>> case open with RH, but I haven't gotten any solution yet. >>>> This is also RHEL 6.3 by the way, though the problem appeared in >>>> 6.2 for me. >>> This looks a memory leak in libkrb5 or dirsrv leaving around so krb >>> context. >>> >>> Those files are replay caches. >>> >>> Rich, can you investigate the use of libkrb5 in dirsrv ? >> https://bugzilla.redhat.com/show_bug.cgi?id=825863 >>> Simo. >>> > Oops missed this, though this is a private bug so I will have to take > y'alls word for it being the thing. Sorry about that. It appears to be a problem with either krb5 or selinux, and there is a proposed fix for RHEL 6.4 > > I hate private bugs. I am going to open a RH support case, just in > case that helps in any way. Yes, please. > > -Erinn > _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From dpal at redhat.com Tue Nov 6 16:42:36 2012 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 06 Nov 2012 11:42:36 -0500 Subject: [Freeipa-users] Can't contact LDAP server: TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user In-Reply-To: <50990B9A.7040205@redhat.com> References: <50990B9A.7040205@redhat.com> Message-ID: <50993DFC.9000505@redhat.com> On 11/06/2012 08:07 AM, Rob Crittenden wrote: > Tim Hughes wrote: >> >> I am trying to migrate from a fedora-ds-1.1.2-1.fc6 server to >> ipa-server-2.2.0-16.el6.x86_64 with the following command >> >> >> ipa migrate-ds ldaps://fedora-ds-server.internal --continue >> --with-compat --base-dn=dc=custsvc,dc=mycompany >> --user-container=ou=People,ou=custsvc,dc=co,dc=mycompany >> --group-container=ou=Groups,ou=custsvc,dc=co,dc=mycompany >> >> >> I get the following response. >> >> >> ipa: DEBUG: approved_usage = SSLServer intended_usage = SSLServer >> ipa: DEBUG: cert valid True for "CN=ipa-server.internal,O=CO.MYCOMPANY" >> ipa: DEBUG: handshake complete, peer = 192.168.10.6:443 >> >> ipa: DEBUG: Caught fault 4203 from server >> http://ipa-server.internal/ipa/xml: Can't contact LDAP server: TLS error >> -8172:Peer's certificate issuer has been marked as not trusted by the >> user. >> ipa: DEBUG: Destroyed connection context.xmlclient >> ipa: ERROR: Can't contact LDAP server: TLS error -8172:Peer's >> certificate issuer has been marked as not trusted by the user. >> >> >> I am trying to work out which certificate is not trusted and how I >> should make it trusted. Any help would be appreciated. > > I suspect you're going to need to add the CA that issued your LDAP > server certificate to the IPA Apache NSS certificate database (where > our admin framework runs). > > You'd add it something like this: > > # certutil -A -d /etc/httpd/alias -n 'LDAP CA' -t CT,C,C -a < > /path/to/ca.crt > > The -n 'LDAP CA' adds a nickname to the CA. There is nothing special > about this, it just needs to be unique. Use something meaningful to you. > > Then restart the httpd service and try the migration again. > > I don't know if we've tested using ldaps, so if my suggestion works > can you let us know? IMO the migrate-ds command should have additional argument to point to the cert file to use for connection. Then the framework should get the cert and import it into the store itself. Rob, do you agree that this would be a valid RFE? > > rob > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Tue Nov 6 16:58:01 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 06 Nov 2012 11:58:01 -0500 Subject: [Freeipa-users] Can't contact LDAP server: TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user In-Reply-To: <50993DFC.9000505@redhat.com> References: <50990B9A.7040205@redhat.com> <50993DFC.9000505@redhat.com> Message-ID: <50994199.1070308@redhat.com> Dmitri Pal wrote: > On 11/06/2012 08:07 AM, Rob Crittenden wrote: >> Tim Hughes wrote: >>> >>> I am trying to migrate from a fedora-ds-1.1.2-1.fc6 server to >>> ipa-server-2.2.0-16.el6.x86_64 with the following command >>> >>> >>> ipa migrate-ds ldaps://fedora-ds-server.internal --continue >>> --with-compat --base-dn=dc=custsvc,dc=mycompany >>> --user-container=ou=People,ou=custsvc,dc=co,dc=mycompany >>> --group-container=ou=Groups,ou=custsvc,dc=co,dc=mycompany >>> >>> >>> I get the following response. >>> >>> >>> ipa: DEBUG: approved_usage = SSLServer intended_usage = SSLServer >>> ipa: DEBUG: cert valid True for "CN=ipa-server.internal,O=CO.MYCOMPANY" >>> ipa: DEBUG: handshake complete, peer = 192.168.10.6:443 >>> >>> ipa: DEBUG: Caught fault 4203 from server >>> http://ipa-server.internal/ipa/xml: Can't contact LDAP server: TLS error >>> -8172:Peer's certificate issuer has been marked as not trusted by the >>> user. >>> ipa: DEBUG: Destroyed connection context.xmlclient >>> ipa: ERROR: Can't contact LDAP server: TLS error -8172:Peer's >>> certificate issuer has been marked as not trusted by the user. >>> >>> >>> I am trying to work out which certificate is not trusted and how I >>> should make it trusted. Any help would be appreciated. >> >> I suspect you're going to need to add the CA that issued your LDAP >> server certificate to the IPA Apache NSS certificate database (where >> our admin framework runs). >> >> You'd add it something like this: >> >> # certutil -A -d /etc/httpd/alias -n 'LDAP CA' -t CT,C,C -a < >> /path/to/ca.crt >> >> The -n 'LDAP CA' adds a nickname to the CA. There is nothing special >> about this, it just needs to be unique. Use something meaningful to you. >> >> Then restart the httpd service and try the migration again. >> >> I don't know if we've tested using ldaps, so if my suggestion works >> can you let us know? > > IMO the migrate-ds command should have additional argument to point to > the cert file to use for connection. > Then the framework should get the cert and import it into the store itself. > > Rob, do you agree that this would be a valid RFE? Yup, certainly something that would make things easier. rob From dpal at redhat.com Tue Nov 6 18:19:11 2012 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 06 Nov 2012 13:19:11 -0500 Subject: [Freeipa-users] Can't contact LDAP server: TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user In-Reply-To: <50994199.1070308@redhat.com> References: <50990B9A.7040205@redhat.com> <50993DFC.9000505@redhat.com> <50994199.1070308@redhat.com> Message-ID: <5099549F.5060001@redhat.com> On 11/06/2012 11:58 AM, Rob Crittenden wrote: > Dmitri Pal wrote: >> On 11/06/2012 08:07 AM, Rob Crittenden wrote: >>> Tim Hughes wrote: >>>> >>>> I am trying to migrate from a fedora-ds-1.1.2-1.fc6 server to >>>> ipa-server-2.2.0-16.el6.x86_64 with the following command >>>> >>>> >>>> ipa migrate-ds ldaps://fedora-ds-server.internal --continue >>>> --with-compat --base-dn=dc=custsvc,dc=mycompany >>>> --user-container=ou=People,ou=custsvc,dc=co,dc=mycompany >>>> --group-container=ou=Groups,ou=custsvc,dc=co,dc=mycompany >>>> >>>> >>>> I get the following response. >>>> >>>> >>>> ipa: DEBUG: approved_usage = SSLServer intended_usage = SSLServer >>>> ipa: DEBUG: cert valid True for >>>> "CN=ipa-server.internal,O=CO.MYCOMPANY" >>>> ipa: DEBUG: handshake complete, peer = 192.168.10.6:443 >>>> >>>> ipa: DEBUG: Caught fault 4203 from server >>>> http://ipa-server.internal/ipa/xml: Can't contact LDAP server: TLS >>>> error >>>> -8172:Peer's certificate issuer has been marked as not trusted by the >>>> user. >>>> ipa: DEBUG: Destroyed connection context.xmlclient >>>> ipa: ERROR: Can't contact LDAP server: TLS error -8172:Peer's >>>> certificate issuer has been marked as not trusted by the user. >>>> >>>> >>>> I am trying to work out which certificate is not trusted and how I >>>> should make it trusted. Any help would be appreciated. >>> >>> I suspect you're going to need to add the CA that issued your LDAP >>> server certificate to the IPA Apache NSS certificate database (where >>> our admin framework runs). >>> >>> You'd add it something like this: >>> >>> # certutil -A -d /etc/httpd/alias -n 'LDAP CA' -t CT,C,C -a < >>> /path/to/ca.crt >>> >>> The -n 'LDAP CA' adds a nickname to the CA. There is nothing special >>> about this, it just needs to be unique. Use something meaningful to >>> you. >>> >>> Then restart the httpd service and try the migration again. >>> >>> I don't know if we've tested using ldaps, so if my suggestion works >>> can you let us know? >> >> IMO the migrate-ds command should have additional argument to point to >> the cert file to use for connection. >> Then the framework should get the cert and import it into the store >> itself. >> >> Rob, do you agree that this would be a valid RFE? > > Yup, certainly something that would make things easier. > > rob > https://fedorahosted.org/freeipa/ticket/3243 -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From thughes at thegoldfish.org Tue Nov 6 18:39:41 2012 From: thughes at thegoldfish.org (Tim Hughes) Date: Tue, 6 Nov 2012 18:39:41 +0000 Subject: [Freeipa-users] Can't contact LDAP server: TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user In-Reply-To: <5099549F.5060001@redhat.com> References: <50990B9A.7040205@redhat.com> <50993DFC.9000505@redhat.com> <50994199.1070308@redhat.com> <5099549F.5060001@redhat.com> Message-ID: Thanks guys. I will try and have a go tomorrow and let you know how it goes. Regards Tim On 6 Nov 2012 18:20, "Dmitri Pal" wrote: > On 11/06/2012 11:58 AM, Rob Crittenden wrote: > > Dmitri Pal wrote: > >> On 11/06/2012 08:07 AM, Rob Crittenden wrote: > >>> Tim Hughes wrote: > >>>> > >>>> I am trying to migrate from a fedora-ds-1.1.2-1.fc6 server to > >>>> ipa-server-2.2.0-16.el6.x86_64 with the following command > >>>> > >>>> > >>>> ipa migrate-ds ldaps://fedora-ds-server.internal --continue > >>>> --with-compat --base-dn=dc=custsvc,dc=mycompany > >>>> --user-container=ou=People,ou=custsvc,dc=co,dc=mycompany > >>>> --group-container=ou=Groups,ou=custsvc,dc=co,dc=mycompany > >>>> > >>>> > >>>> I get the following response. > >>>> > >>>> > >>>> ipa: DEBUG: approved_usage = SSLServer intended_usage = SSLServer > >>>> ipa: DEBUG: cert valid True for > >>>> "CN=ipa-server.internal,O=CO.MYCOMPANY" > >>>> ipa: DEBUG: handshake complete, peer = 192.168.10.6:443 > >>>> > >>>> ipa: DEBUG: Caught fault 4203 from server > >>>> http://ipa-server.internal/ipa/xml: Can't contact LDAP server: TLS > >>>> error > >>>> -8172:Peer's certificate issuer has been marked as not trusted by the > >>>> user. > >>>> ipa: DEBUG: Destroyed connection context.xmlclient > >>>> ipa: ERROR: Can't contact LDAP server: TLS error -8172:Peer's > >>>> certificate issuer has been marked as not trusted by the user. > >>>> > >>>> > >>>> I am trying to work out which certificate is not trusted and how I > >>>> should make it trusted. Any help would be appreciated. > >>> > >>> I suspect you're going to need to add the CA that issued your LDAP > >>> server certificate to the IPA Apache NSS certificate database (where > >>> our admin framework runs). > >>> > >>> You'd add it something like this: > >>> > >>> # certutil -A -d /etc/httpd/alias -n 'LDAP CA' -t CT,C,C -a < > >>> /path/to/ca.crt > >>> > >>> The -n 'LDAP CA' adds a nickname to the CA. There is nothing special > >>> about this, it just needs to be unique. Use something meaningful to > >>> you. > >>> > >>> Then restart the httpd service and try the migration again. > >>> > >>> I don't know if we've tested using ldaps, so if my suggestion works > >>> can you let us know? > >> > >> IMO the migrate-ds command should have additional argument to point to > >> the cert file to use for connection. > >> Then the framework should get the cert and import it into the store > >> itself. > >> > >> Rob, do you agree that this would be a valid RFE? > > > > Yup, certainly something that would make things easier. > > > > rob > > > https://fedorahosted.org/freeipa/ticket/3243 > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Nov 6 21:06:26 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 06 Nov 2012 16:06:26 -0500 Subject: [Freeipa-users] Updating the CA certificate In-Reply-To: <5098186E.8070401@gmail.com> References: <5098115A.9050301@gmail.com> <509812B1.6060402@redhat.com> <50981312.70308@gmail.com> <5098168E.40603@redhat.com> <5098186E.8070401@gmail.com> Message-ID: <50997BD2.7020604@redhat.com> Erinn Looney-Triggs wrote: > On 11/05/12 10:42, Rob Crittenden wrote: >> Erinn Looney-Triggs wrote: >>> On 11/05/12 10:25, Rob Crittenden wrote: >>>> Erinn Looney-Triggs wrote: >>>>> I hope I haven't missed it in searching around, but how does one update >>>>> the CA certificate in IPA? >>>>> >>>>> Though it is a year out from expiring I would rather know sooner than >>>>> later when it comes to this. >>>> >>>> Kudos for planning ahead! >>>> >>>> What kind of CA do you have installed. Are you using a dogtag backend CA >>>> or did you install with the selfsign method? >>>> >>>> rob >>>> >>> >>> Using dogtag CA and it is replicated, though, and I am not sure if this >>> makes an difference, it is a subordinate CA that has been issued by an >>> AD PKI setup. >> >> You'll need to start with your AD PKI. I'm assuming it is expiring as >> well since the IPA CA validity period is limited by its issuer. Are you >> going to rekey the AD CA or renew the current CA cert? >> >> rob >> > > Subordinate CAs from the AD by default are only valid for two years, > whereas by default the CA for the AD is valid for 10 years. So only the > subordinate cert is being reissued. > > The key won't be changing on the IPA end, just the cert. Normally this > would just be an import new cert type thing, but I am unsure in the IPA > environment. > > Make sense? > -Erinn > > Renewing a CA signing certificate with the same key pair is a much simpler. Here is a link on how to do so: https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/managing-ca-related-profiles.html look under 2.7.3. Allowing a CA Certificate to Be Renewed Past the CA's Validity Period rob From Steven.Jones at vuw.ac.nz Tue Nov 6 21:22:28 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 6 Nov 2012 21:22:28 +0000 Subject: [Freeipa-users] Rebuilding the failing original IPA master Message-ID: <833D8E48405E064EBC54C84EC6B36E405471C1F4@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, It seems I am faced with rebuilding my original IPA master....trouble is I dont know the impact and problems with doing that. For instance, can I simply, 1) run a db2ldif to export the ldap contents, 2) un-install the IPA server, 3) reboot and re-install it, 4) run ldif2db 5) then re-sync the two replicas? or will the two replicas need rebuilding? and rejoining fresh? Will all the hosts need re-joining? Looking at this I dont know just how easy it is or not to do. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 From pspacek at redhat.com Wed Nov 7 09:17:35 2012 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 07 Nov 2012 10:17:35 +0100 Subject: [Freeipa-users] Rebuilding the failing original IPA master In-Reply-To: <833D8E48405E064EBC54C84EC6B36E405471C1F4@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E405471C1F4@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <509A272F.6080109@redhat.com> Hello, On 11/06/2012 10:22 PM, Steven Jones wrote: > It seems I am faced with rebuilding my original IPA master....trouble is I dont know the impact and problems with doing that. What it your topology right now? Do you have at least one fully-functional replica? Is CA installed on this replica? Or is it replica without Dogtag CA (i.e. installed with self-signed certificate)? If you have one "complete" replica including CA then you can simply destroy old server and install fresh replica as usual. Rob can add more details and advices. Petr^2 Spacek > For instance, can I simply, > > 1) run a db2ldif to export the ldap contents, > 2) un-install the IPA server, > 3) reboot and re-install it, > 4) run ldif2db > 5) then re-sync the two replicas? > > or will the two replicas need rebuilding? and rejoining fresh? > > Will all the hosts need re-joining? > > Looking at this I dont know just how easy it is or not to do. From rcritten at redhat.com Wed Nov 7 16:30:27 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 07 Nov 2012 11:30:27 -0500 Subject: [Freeipa-users] Rebuilding the failing original IPA master In-Reply-To: <833D8E48405E064EBC54C84EC6B36E405471C1F4@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E405471C1F4@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <509A8CA3.4030806@redhat.com> Steven Jones wrote: > Hi, > > It seems I am faced with rebuilding my original IPA master....trouble is I dont know the impact and problems with doing that. > > For instance, can I simply, > > 1) run a db2ldif to export the ldap contents, > 2) un-install the IPA server, > 3) reboot and re-install it, > 4) run ldif2db > 5) then re-sync the two replicas? > > or will the two replicas need rebuilding? and rejoining fresh? > > Will all the hosts need re-joining? > > Looking at this I dont know just how easy it is or not to do. > I think we need more details on what it is you're trying to do, and why. You wouldn't normally drop and reload a database in an IPA server like this. I gather you have three masters. Do you have a dogtag CA installed on one or all of them? Which one are you looking to rebuild? rob From Steven.Jones at vuw.ac.nz Wed Nov 7 19:26:15 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Wed, 7 Nov 2012 19:26:15 +0000 Subject: [Freeipa-users] Rebuilding the failing original IPA master In-Reply-To: <509A272F.6080109@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E405471C1F4@STAWINCOX10MBX1.staff.vuw.ac.nz>, <509A272F.6080109@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E405471CEF2@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, The master was 6.2 upgraded to 6.3 its got a "bad schema" so the advice I have is to rebuild it. I have 2 replicas they also were upgraded but "blew up" so were rebuilt as fresh 6.3, both these are fine, replicating and working perfectly. I dont use CA, its just self signed on them.. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Petr Spacek [pspacek at redhat.com] Sent: Wednesday, 7 November 2012 10:17 p.m. To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Rebuilding the failing original IPA master Hello, On 11/06/2012 10:22 PM, Steven Jones wrote: > It seems I am faced with rebuilding my original IPA master....trouble is I dont know the impact and problems with doing that. What it your topology right now? Do you have at least one fully-functional replica? Is CA installed on this replica? Or is it replica without Dogtag CA (i.e. installed with self-signed certificate)? If you have one "complete" replica including CA then you can simply destroy old server and install fresh replica as usual. Rob can add more details and advices. Petr^2 Spacek > For instance, can I simply, > > 1) run a db2ldif to export the ldap contents, > 2) un-install the IPA server, > 3) reboot and re-install it, > 4) run ldif2db > 5) then re-sync the two replicas? > > or will the two replicas need rebuilding? and rejoining fresh? > > Will all the hosts need re-joining? > > Looking at this I dont know just how easy it is or not to do. _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From rcritten at redhat.com Wed Nov 7 19:47:25 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 07 Nov 2012 14:47:25 -0500 Subject: [Freeipa-users] Rebuilding the failing original IPA master In-Reply-To: <833D8E48405E064EBC54C84EC6B36E405471CEF2@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E405471C1F4@STAWINCOX10MBX1.staff.vuw.ac.nz>, <509A272F.6080109@redhat.com> <833D8E48405E064EBC54C84EC6B36E405471CEF2@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <509ABACD.4070906@redhat.com> Steven Jones wrote: > Hi, > > The master was 6.2 upgraded to 6.3 its got a "bad schema" so the advice I have is to rebuild it. > > I have 2 replicas they also were upgraded but "blew up" so were rebuilt as fresh 6.3, both these are fine, replicating and working perfectly. > > I dont use CA, its just self signed on them.. OK, details are important here. Terms like "blew up" and "bad schema" leave me guessing exactly what you mean. So if I understand it correctly you have a 2.1.3 -> 2.2.0 master that is limping along and two freshly installed 2.2.0 masters and you'd like to uninstall and re-install the server whose upgrade didn't go well. With a selfsign CA there is only one that is the CA, so if that is the server you want to re-create you'll need to promote one of the working 2.2.0 servers to be the CA. I think the basics steps would be: - promote one of the 2.2.0 masters to be the new CA - verify that the new CA can issue certs - remove the server that failed upgrading (ipa-replica-manage del non-working.example.com) - Follow the CLEANRUV docs at http://directory.fedoraproject.org/wiki/Howto:CLEANRUV (starts about midway down the page) - ipa-server-install --uninstall on the decomissioned server - prepare a new replica file - ipa-replica-install Note that selfsign is not supported in RHEL. You'll need to refer to the Fedora docs on how to do that, see section 16.8.2 at http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/promoting-replica.html Unfortunately the docs are wrong. You want to use the NSS database in /etc/httpd/alias and not the DS instance. The cacert.p12 comes from the file you saved after the initial install. You saved that, right? If not, you can run this on the old master to re-create it: # pk12util -o /tmp/cacert.p12 -d /etc/httpd/alias -n '$REALM IPA CA' -k /etc/httpd/alias/pwdfile.txt These are some instructions one of our engineers wrote up when he needed to do this himself. You can probably skip step 1 as you already have a couple of working replicas. Tread carefully. If you lose your CA you won't have the ability to create new replicas, issue server certs, do much of anything. 1) Install replica # ipa-replica-install 2) Copy CA serial number setting from master to replica: # scp /var/lib/ipa/ca_serialno new_ca.example.com:/var/lib/ipa/ 3) On replica, set correct owner and permissions: # chown root:apache /var/lib/ipa/ca_serialno # chmod 550 /var/lib/ipa/ca_serialno 4) Restore SELinux context on serial file: # restorecon /var/lib/ipa/ca_serialno 5) Copy CA certificate and pwdfile.txt from master to replica: # scp /etc/httpd/alias/cacert.p12 /etc/httpd/alias/pwdfile.txt new_ca.example.com:~/ 7) On replica, import the CA certificate: # pk12util -i ~/cacert.p12 -w ~/pwdfile.txt -d /etc/httpd/alias/ -k /etc/httpd/alias/pwdfile.txt 8) The list of certificates in NSS database (including the one imported) can be listed with: # certutil -L -d /etc/httpd/alias/ However, since pk12util import util is not capable of setting a correct certificate nickname, the imported certificate will have a nickname like ""CN=$REALM Certificate Authority", which is not recognized by IPA certificate system. The following procedure can be used set a correct nickname of the certificate: a) Export the certificate # certutil -d /etc/httpd/alias/ -L -n 'CN=$REALM Certificate Authority' -a > ~/cacert.crt b) Delete the old certificate (NSS database /etc/httpd/alias/ should be backed up before this step): # certutil -d /etc/httpd/alias/ -D -n 'CN=$REALM Certificate Authority' c) Import the certificate with correct nickname: # certutil -A -n "$REALM IPA CA" -d /etc/httpd/alias/ -f /etc/httpd/alias/pwdfile.txt -i /root/cacert.crt -a -t CTu,u,Cu 9) Enable certificate operations on IPA replica: # echo "enable_ra=True" >> /etc/ipa/default.conf 10) Reload web server to pick up new configuration: # service httpd reload From Steven.Jones at vuw.ac.nz Wed Nov 7 19:51:07 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Wed, 7 Nov 2012 19:51:07 +0000 Subject: [Freeipa-users] Rebuilding the failing original IPA master In-Reply-To: <509ABACD.4070906@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E405471C1F4@STAWINCOX10MBX1.staff.vuw.ac.nz>, <509A272F.6080109@redhat.com> <833D8E48405E064EBC54C84EC6B36E405471CEF2@STAWINCOX10MBX1.staff.vuw.ac.nz>, <509ABACD.4070906@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E405471D0B7@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, Sorry but I get confused with all the terms, I think its simpler, I dont do certs nad have not as far as I know installed a CA. Except those for things like port 443 connections or winsync connections...which are just internal? regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: Rob Crittenden [rcritten at redhat.com] Sent: Thursday, 8 November 2012 8:47 a.m. To: Steven Jones Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Rebuilding the failing original IPA master Steven Jones wrote: > Hi, > > The master was 6.2 upgraded to 6.3 its got a "bad schema" so the advice I have is to rebuild it. > > I have 2 replicas they also were upgraded but "blew up" so were rebuilt as fresh 6.3, both these are fine, replicating and working perfectly. > > I dont use CA, its just self signed on them.. OK, details are important here. Terms like "blew up" and "bad schema" leave me guessing exactly what you mean. So if I understand it correctly you have a 2.1.3 -> 2.2.0 master that is limping along and two freshly installed 2.2.0 masters and you'd like to uninstall and re-install the server whose upgrade didn't go well. With a selfsign CA there is only one that is the CA, so if that is the server you want to re-create you'll need to promote one of the working 2.2.0 servers to be the CA. I think the basics steps would be: - promote one of the 2.2.0 masters to be the new CA - verify that the new CA can issue certs - remove the server that failed upgrading (ipa-replica-manage del non-working.example.com) - Follow the CLEANRUV docs at http://directory.fedoraproject.org/wiki/Howto:CLEANRUV (starts about midway down the page) - ipa-server-install --uninstall on the decomissioned server - prepare a new replica file - ipa-replica-install Note that selfsign is not supported in RHEL. You'll need to refer to the Fedora docs on how to do that, see section 16.8.2 at http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/promoting-replica.html Unfortunately the docs are wrong. You want to use the NSS database in /etc/httpd/alias and not the DS instance. The cacert.p12 comes from the file you saved after the initial install. You saved that, right? If not, you can run this on the old master to re-create it: # pk12util -o /tmp/cacert.p12 -d /etc/httpd/alias -n '$REALM IPA CA' -k /etc/httpd/alias/pwdfile.txt These are some instructions one of our engineers wrote up when he needed to do this himself. You can probably skip step 1 as you already have a couple of working replicas. Tread carefully. If you lose your CA you won't have the ability to create new replicas, issue server certs, do much of anything. 1) Install replica # ipa-replica-install 2) Copy CA serial number setting from master to replica: # scp /var/lib/ipa/ca_serialno new_ca.example.com:/var/lib/ipa/ 3) On replica, set correct owner and permissions: # chown root:apache /var/lib/ipa/ca_serialno # chmod 550 /var/lib/ipa/ca_serialno 4) Restore SELinux context on serial file: # restorecon /var/lib/ipa/ca_serialno 5) Copy CA certificate and pwdfile.txt from master to replica: # scp /etc/httpd/alias/cacert.p12 /etc/httpd/alias/pwdfile.txt new_ca.example.com:~/ 7) On replica, import the CA certificate: # pk12util -i ~/cacert.p12 -w ~/pwdfile.txt -d /etc/httpd/alias/ -k /etc/httpd/alias/pwdfile.txt 8) The list of certificates in NSS database (including the one imported) can be listed with: # certutil -L -d /etc/httpd/alias/ However, since pk12util import util is not capable of setting a correct certificate nickname, the imported certificate will have a nickname like ""CN=$REALM Certificate Authority", which is not recognized by IPA certificate system. The following procedure can be used set a correct nickname of the certificate: a) Export the certificate # certutil -d /etc/httpd/alias/ -L -n 'CN=$REALM Certificate Authority' -a > ~/cacert.crt b) Delete the old certificate (NSS database /etc/httpd/alias/ should be backed up before this step): # certutil -d /etc/httpd/alias/ -D -n 'CN=$REALM Certificate Authority' c) Import the certificate with correct nickname: # certutil -A -n "$REALM IPA CA" -d /etc/httpd/alias/ -f /etc/httpd/alias/pwdfile.txt -i /root/cacert.crt -a -t CTu,u,Cu 9) Enable certificate operations on IPA replica: # echo "enable_ra=True" >> /etc/ipa/default.conf 10) Reload web server to pick up new configuration: # service httpd reload From Steven.Jones at vuw.ac.nz Wed Nov 7 20:03:30 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Wed, 7 Nov 2012 20:03:30 +0000 Subject: [Freeipa-users] Rebuilding the failing original IPA master In-Reply-To: <509ABACD.4070906@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E405471C1F4@STAWINCOX10MBX1.staff.vuw.ac.nz>, <509A272F.6080109@redhat.com> <833D8E48405E064EBC54C84EC6B36E405471CEF2@STAWINCOX10MBX1.staff.vuw.ac.nz>, <509ABACD.4070906@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E405471D0D3@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, 8><----------- OK, details are important here. Terms like "blew up" and "bad schema" leave me guessing exactly what you mean. 8><----------- I dont know whast wrong either but everything I seem to try and setup goes badly with intermittant or total failures. For instance a winsync agreement with the old server and AD wipes existing IPA users groups and doesnt put the new users in the ipausers group, no one has seen that behaviour it seems. Yet a clean 6.3 IPA master does put new users in the ipausers group and existing users retain their groups. 8><------------ So if I understand it correctly you have a 2.1.3 -> 2.2.0 master that is limping along and two freshly installed 2.2.0 masters and you'd like to uninstall and re-install the server whose upgrade didn't go well. 8><----------- Yes....from testing a clean 6.3 it seems to work for winsync at least fine.....rpm -q says 2.2.0-16 8><----------- - remove the server that failed upgrading (ipa-replica-manage del non-working.example.com) - Follow the CLEANRUV docs at http://directory.fedoraproject.org/wiki/Howto:CLEANRUV (starts about midway down the page) - ipa-server-install --uninstall on the decomissioned server - prepare a new replica file - ipa-replica-install Note that selfsign is not supported in RHEL. You'll need to refer to the Fedora docs on how to do that, see section 16.8.2 at http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/promoting-replica.html Unfortunately the docs are wrong. You want to use the NSS database in /etc/httpd/alias and not the DS instance. The cacert.p12 comes from the file you saved after the initial install. You saved that, right? 8><---------- Yes, it should be in our subversion system. 8><---------- If not, you can run this on the old master to re-create it: # pk12util -o /tmp/cacert.p12 -d /etc/httpd/alias -n '$REALM IPA CA' -k /etc/httpd/alias/pwdfile.txt These are some instructions one of our engineers wrote up when he needed to do this himself. You can probably skip step 1 as you already have a couple of working replicas. Tread carefully. If you lose your CA you won't have the ability to create new replicas, issue server certs, do much of anything. 1) Install replica # ipa-replica-install 2) Copy CA serial number setting from master to replica: # scp /var/lib/ipa/ca_serialno new_ca.example.com:/var/lib/ipa/ 3) On replica, set correct owner and permissions: # chown root:apache /var/lib/ipa/ca_serialno # chmod 550 /var/lib/ipa/ca_serialno 4) Restore SELinux context on serial file: # restorecon /var/lib/ipa/ca_serialno 5) Copy CA certificate and pwdfile.txt from master to replica: # scp /etc/httpd/alias/cacert.p12 /etc/httpd/alias/pwdfile.txt new_ca.example.com:~/ 7) On replica, import the CA certificate: # pk12util -i ~/cacert.p12 -w ~/pwdfile.txt -d /etc/httpd/alias/ -k /etc/httpd/alias/pwdfile.txt 8) The list of certificates in NSS database (including the one imported) can be listed with: # certutil -L -d /etc/httpd/alias/ However, since pk12util import util is not capable of setting a correct certificate nickname, the imported certificate will have a nickname like ""CN=$REALM Certificate Authority", which is not recognized by IPA certificate system. The following procedure can be used set a correct nickname of the certificate: a) Export the certificate # certutil -d /etc/httpd/alias/ -L -n 'CN=$REALM Certificate Authority' -a > ~/cacert.crt b) Delete the old certificate (NSS database /etc/httpd/alias/ should be backed up before this step): # certutil -d /etc/httpd/alias/ -D -n 'CN=$REALM Certificate Authority' c) Import the certificate with correct nickname: # certutil -A -n "$REALM IPA CA" -d /etc/httpd/alias/ -f /etc/httpd/alias/pwdfile.txt -i /root/cacert.crt -a -t CTu,u,Cu 9) Enable certificate operations on IPA replica: # echo "enable_ra=True" >> /etc/ipa/default.conf 10) Reload web server to pick up new configuration: # service httpd reload From rcritten at redhat.com Wed Nov 7 20:30:33 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 07 Nov 2012 15:30:33 -0500 Subject: [Freeipa-users] Rebuilding the failing original IPA master In-Reply-To: <833D8E48405E064EBC54C84EC6B36E405471D0B7@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E405471C1F4@STAWINCOX10MBX1.staff.vuw.ac.nz>, <509A272F.6080109@redhat.com> <833D8E48405E064EBC54C84EC6B36E405471CEF2@STAWINCOX10MBX1.staff.vuw.ac.nz>, <509ABACD.4070906@redhat.com> <833D8E48405E064EBC54C84EC6B36E405471D0B7@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <509AC4E9.6060806@redhat.com> Steven Jones wrote: > Hi, > > Sorry but I get confused with all the terms, I think its simpler, I dont do certs nad have not as far as I know installed a CA. Except those for things like port 443 connections or winsync connections...which are just internal? No worries, I'm just trying to avoid giving bad advice. A CA is not optional with IPA. We use it to secure the XML-RPC interface and initial replication agreements. You may not need additional cert capabilities right now but the base IPA install does. It won't be pleasant if you lose the ability to issue certificates. It may be worthwhile running through the steps in a test set up to be sure things work as outlined. rob From Steven.Jones at vuw.ac.nz Wed Nov 7 20:50:39 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Wed, 7 Nov 2012 20:50:39 +0000 Subject: [Freeipa-users] Rebuilding the failing original IPA master In-Reply-To: <509AC4E9.6060806@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E405471C1F4@STAWINCOX10MBX1.staff.vuw.ac.nz>, <509A272F.6080109@redhat.com> <833D8E48405E064EBC54C84EC6B36E405471CEF2@STAWINCOX10MBX1.staff.vuw.ac.nz>, <509ABACD.4070906@redhat.com> <833D8E48405E064EBC54C84EC6B36E405471D0B7@STAWINCOX10MBX1.staff.vuw.ac.nz>, <509AC4E9.6060806@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E405471D154@STAWINCOX10MBX1.staff.vuw.ac.nz> This is what Im setting up to do. Thanks very much. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: Rob Crittenden [rcritten at redhat.com] Sent: Thursday, 8 November 2012 9:30 a.m. To: Steven Jones Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Rebuilding the failing original IPA master Steven Jones wrote: > Hi, > > Sorry but I get confused with all the terms, I think its simpler, I dont do certs nad have not as far as I know installed a CA. Except those for things like port 443 connections or winsync connections...which are just internal? No worries, I'm just trying to avoid giving bad advice. A CA is not optional with IPA. We use it to secure the XML-RPC interface and initial replication agreements. You may not need additional cert capabilities right now but the base IPA install does. It won't be pleasant if you lose the ability to issue certificates. It may be worthwhile running through the steps in a test set up to be sure things work as outlined. rob From william.muriithi at gmail.com Wed Nov 7 21:28:52 2012 From: william.muriithi at gmail.com (William Muriithi) Date: Wed, 7 Nov 2012 16:28:52 -0500 Subject: [Freeipa-users] Managing Sudo through FreeIPA Message-ID: Hello I have been trying to setup user access through sudo file managed by FreeIPA and it don't seem to be working. I am not sure how to go about fixing it, but I guess the best place to start is ask what I should expect the IPA installation script should set up and what should be done manually [root at demo2 wmuriithi]# rpm -qa | grep sssd sssd-client-1.8.0-32.el6.x86_64 sssd-1.8.0-32.el6.x86_64 [root at demo2 wmuriithi]# [root at demo2 wmuriithi]# rpm -qa | grep sudo sudo-1.7.4p5-13.el6_3.x86_64 The only errors related to sudo that I can find is on apache error logs [Wed Nov 07 13:16:18 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: sudorule_add_user(u'read_only_viewiers', all=False, raw=False, version=u'2.34', group=(u'operations',)): SUCCESS [Wed Nov 07 13:54:44 2012] [error] ipa: ERROR: release_ipa_ccache: ccache_name (FILE:/var/run/ipa_memcached/krbcc_3988) != KRB5CCNAME environment variable (FILE:/tmp/krb5cc_apache_NB7pph) [Wed Nov 07 13:54:44 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: sudorule_find(None, sizelimit=0, pkey_only=True): SUCCESS [Wed Nov 07 13:54:44 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: batch: sudorule_show(u'Full_Access', all=True): SUCCESS [Wed Nov 07 13:54:44 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: batch: sudorule_show(u'read_only_viewiers', all=True): SUCCESS [Wed Nov 07 13:54:44 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: batch: sudorule_show(u'developers', all=True): SUCCESS [Wed Nov 07 13:54:44 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: batch: sudorule_show(u'operation', all=True): SUCCESS [Wed Nov 07 13:54:44 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: batch(({u'params': [[u'Full_Access'], {u'all': True}], u'method': u'sudorule_show'}, {u'params': [[u'read_only_viewiers'], {u'all': True}], u'method': u'sudorule_show'}, {u'params': [[u'developers'], {u'all': True}], u'method': u'sudorule_show'}, {u'params': [[u'operation'], {u'all': True}], u'method': u'sudorule_show'})): SUCCESS [Wed Nov 07 13:54:50 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: sudorule_show(u'read_only_viewiers', rights=True, all=True): SUCCESS I created the user as below and associated it with a group, which I then allowed to use less for reading file. As you can see below, it seem to does not work. Nov 7 16:05:42 demo2 sudo: pam_sss(sudo:auth): authentication success; logname=williamm uid=0 euid=0 tty=/dev/pts/2 ruser=williamm rhost= user=williamm Nov 7 16:05:43 demo2 sudo: williamm : user NOT in sudoers ; TTY=pts/2 ; PWD=/home/wmuriithi ; USER=root ; COMMAND=/usr/bin/less /var/log/secure - My question is, does the client install script take care of sudo configuration or is that done manually? I don't see any sudo related flag on the client installation script. - I have tried configuring sssd for sudo use and it didn't go well. Last time I messed around with LDAP managed sudo, I have to install a LDAP capable sudo package. The ipa-client install did not install this package. Does IPA sudo management work differently? - Where would I check for logs? I checked sssd logs and they are empty. - I am missing the basedn configuration on sssd configuration. From this bug, it should have been setup by installer, oddly though it was not setup and the bug is closed. I attempted to fix it by adding the line below but it make sudo completely unusable. It could not find any valid users apparently https://fedorahosted.org/freeipa/ticket/932 ldap_netgroup_search_base = cn=ng,cn=compat,dc=example,dc=loc Nov 7 16:05:42 demo2 sudo: pam_sss(sudo:auth): authentication success; logname=williamm uid=0 euid=0 tty=/dev/pts/2 ruser=williamm rhost= user=williamm Nov 7 16:05:43 demo2 sudo: williamm : user NOT in sudoers ; TTY=pts/2 ; PWD=/home/wmuriithi ; USER=root ; COMMAND=/usr/bin/less /var/log/secure Any pointers on why we are going? Thank you a lot in advance. William ---------------------------- [root at ipa1-yyz-int wmuriithi]# ipa sudocmd-add --desc='For reading log files' '/usr/bin/less' ---------------------------------- Added Sudo Command "/usr/bin/less" ---------------------------------- Sudo Command: /usr/bin/less Description: For reading log files [root at ipa1-yyz-int wmuriithi]# ipa sudocmdgroup-add --desc='Read Only Commands' readonly ----------------------------------- Added Sudo Command Group "readonly" ----------------------------------- Sudo Command Group: readonly Description: Read Only Commands [root at ipa1-yyz-int wmuriithi]# ipa sudocmdgroup-add-member --sudocmds='/usr/bin/less' readonly Sudo Command Group: readonly Description: Read Only Commands Member Sudo commands: /usr/bin/less ------------------------- Number of members added 1 ------------------------- [root at ipa1-yyz-int wmuriithi]# ipa sudorule-add testing_viewiers ----------------------------------- Added Sudo Rule "testing_viewiers" ----------------------------------- Rule name: testing_viewiers Enabled: TRUE [root at ipa1-yyz-int wmuriithi]# ipa sudorule-add-allow-command --sudocmdgroups=readonly testing_viewiers Rule name: testing_viewiers Enabled: TRUE Sudo Allow Command Groups: readonly ------------------------- Number of members added 1 ------------------------- [root at ipa1-yyz-int wmuriithi]# ipa hostgroup-add demo Description: Demonstration systems >>> Description: Leading and trailing spaces are not allowed Description: Demonstration system ---------------------- Added hostgroup "demo" ---------------------- Host-group: demo Description: Demonstration system [root at ipa1-yyz-int wmuriithi]# ipa hostgroup-add-member --hosts=demo2.yyz.int.testing.com demo Host-group: demo Description: Demonstration system Member hosts: demo2.yyz.int.testing.com ------------------------- Number of members added 1 ------------------------- [root at ipa1-yyz-int wmuriithi]# ipa sudorule-add-host --hostgroups=demo testing_viewiers Rule name: testing_viewiers Enabled: TRUE Host Groups: demo Sudo Allow Command Groups: readonly ------------------------- Number of members added 1 ------------------------- [root at ipa1-yyz-int wmuriithi]# ipa sudorule-add-user --groups=operations testing_viewiers Rule name: testing_viewiers Enabled: TRUE User Groups: operations Host Groups: demo Sudo Allow Command Groups: readonly ------------------------- Number of members added 1 ------------------------- From dpal at redhat.com Thu Nov 8 00:13:40 2012 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 07 Nov 2012 19:13:40 -0500 Subject: [Freeipa-users] Managing Sudo through FreeIPA In-Reply-To: References: Message-ID: <509AF934.8090202@redhat.com> On 11/07/2012 04:28 PM, William Muriithi wrote: > Hello > > I have been trying to setup user access through sudo file managed by > FreeIPA and it don't seem to be working. I am not sure how to go > about fixing it, but I guess the best place to start is ask what I > should expect the IPA installation script should set up and what > should be done manually > > [root at demo2 wmuriithi]# rpm -qa | grep sssd > sssd-client-1.8.0-32.el6.x86_64 > sssd-1.8.0-32.el6.x86_64 > [root at demo2 wmuriithi]# > > > > [root at demo2 wmuriithi]# rpm -qa | grep sudo > sudo-1.7.4p5-13.el6_3.x86_64 > > The only errors related to sudo that I can find is on apache error logs > > [Wed Nov 07 13:16:18 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: > sudorule_add_user(u'read_only_viewiers', all=False, raw=False, > version=u'2.34', group=(u'operations',)): SUCCESS > [Wed Nov 07 13:54:44 2012] [error] ipa: ERROR: release_ipa_ccache: > ccache_name (FILE:/var/run/ipa_memcached/krbcc_3988) != KRB5CCNAME > environment variable (FILE:/tmp/krb5cc_apache_NB7pph) > [Wed Nov 07 13:54:44 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: > sudorule_find(None, sizelimit=0, pkey_only=True): SUCCESS > [Wed Nov 07 13:54:44 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: > batch: sudorule_show(u'Full_Access', all=True): SUCCESS > [Wed Nov 07 13:54:44 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: > batch: sudorule_show(u'read_only_viewiers', all=True): SUCCESS > [Wed Nov 07 13:54:44 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: > batch: sudorule_show(u'developers', all=True): SUCCESS > [Wed Nov 07 13:54:44 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: > batch: sudorule_show(u'operation', all=True): SUCCESS > [Wed Nov 07 13:54:44 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: > batch(({u'params': [[u'Full_Access'], {u'all': True}], u'method': > u'sudorule_show'}, {u'params': [[u'read_only_viewiers'], {u'all': > True}], u'method': u'sudorule_show'}, {u'params': [[u'developers'], > {u'all': True}], u'method': u'sudorule_show'}, {u'params': > [[u'operation'], {u'all': True}], u'method': u'sudorule_show'})): > SUCCESS > [Wed Nov 07 13:54:50 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: > sudorule_show(u'read_only_viewiers', rights=True, all=True): SUCCESS > > > I created the user as below and associated it with a group, which I > then allowed to use less for reading file. As you can see below, it > seem to does not work. > > Nov 7 16:05:42 demo2 sudo: pam_sss(sudo:auth): authentication > success; logname=williamm uid=0 euid=0 tty=/dev/pts/2 ruser=williamm > rhost= user=williamm > Nov 7 16:05:43 demo2 sudo: williamm : user NOT in sudoers ; TTY=pts/2 > ; PWD=/home/wmuriithi ; USER=root ; COMMAND=/usr/bin/less > /var/log/secure > > > - My question is, does the client install script take care of sudo > configuration or is that done manually? I don't see any sudo related > flag on the client installation script. > > - I have tried configuring sssd for sudo use and it didn't go well. > Last time I messed around with LDAP managed sudo, I have to install a > LDAP capable sudo package. The ipa-client install did not install > this package. Does IPA sudo management work differently? > > - Where would I check for logs? I checked sssd logs and they are empty. > > - I am missing the basedn configuration on sssd configuration. From > this bug, it should have been setup by installer, oddly though it was > not setup and the bug is closed. I attempted to fix it by adding the > line below but it make sudo completely unusable. It could not find > any valid users apparently > > https://fedorahosted.org/freeipa/ticket/932 > > ldap_netgroup_search_base = cn=ng,cn=compat,dc=example,dc=loc > > Nov 7 16:05:42 demo2 sudo: pam_sss(sudo:auth): authentication > success; logname=williamm uid=0 euid=0 tty=/dev/pts/2 ruser=williamm > rhost= user=williamm > Nov 7 16:05:43 demo2 sudo: williamm : user NOT in sudoers ; TTY=pts/2 > ; PWD=/home/wmuriithi ; USER=root ; COMMAND=/usr/bin/less > /var/log/secure > > > Any pointers on why we are going? > > Thank you a lot in advance. > > William > > ---------------------------- > [root at ipa1-yyz-int wmuriithi]# ipa sudocmd-add --desc='For reading log > files' '/usr/bin/less' > ---------------------------------- > Added Sudo Command "/usr/bin/less" > ---------------------------------- > Sudo Command: /usr/bin/less > Description: For reading log files > [root at ipa1-yyz-int wmuriithi]# ipa sudocmdgroup-add --desc='Read Only > Commands' readonly > ----------------------------------- > Added Sudo Command Group "readonly" > ----------------------------------- > Sudo Command Group: readonly > Description: Read Only Commands > [root at ipa1-yyz-int wmuriithi]# ipa sudocmdgroup-add-member > --sudocmds='/usr/bin/less' readonly > Sudo Command Group: readonly > Description: Read Only Commands > Member Sudo commands: /usr/bin/less > ------------------------- > Number of members added 1 > ------------------------- > [root at ipa1-yyz-int wmuriithi]# ipa sudorule-add testing_viewiers > ----------------------------------- > Added Sudo Rule "testing_viewiers" > ----------------------------------- > Rule name: testing_viewiers > Enabled: TRUE > [root at ipa1-yyz-int wmuriithi]# ipa sudorule-add-allow-command > --sudocmdgroups=readonly testing_viewiers > Rule name: testing_viewiers > Enabled: TRUE > Sudo Allow Command Groups: readonly > ------------------------- > Number of members added 1 > ------------------------- > [root at ipa1-yyz-int wmuriithi]# ipa hostgroup-add demo > Description: Demonstration systems >>>> Description: Leading and trailing spaces are not allowed > Description: Demonstration system > ---------------------- > Added hostgroup "demo" > ---------------------- > Host-group: demo > Description: Demonstration system > [root at ipa1-yyz-int wmuriithi]# ipa hostgroup-add-member > --hosts=demo2.yyz.int.testing.com demo > Host-group: demo > Description: Demonstration system > Member hosts: demo2.yyz.int.testing.com > ------------------------- > Number of members added 1 > ------------------------- > [root at ipa1-yyz-int wmuriithi]# ipa sudorule-add-host --hostgroups=demo > testing_viewiers > Rule name: testing_viewiers > Enabled: TRUE > Host Groups: demo > Sudo Allow Command Groups: readonly > ------------------------- > Number of members added 1 > ------------------------- > [root at ipa1-yyz-int wmuriithi]# ipa sudorule-add-user > --groups=operations testing_viewiers > Rule name: testing_viewiers > Enabled: TRUE > User Groups: operations > Host Groups: demo > Sudo Allow Command Groups: readonly > ------------------------- > Number of members added 1 > ------------------------- > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users The SODO integration is evolving so it important to know what OS and version you are on. I would assume you are on RHEL6.3 or equivalent. There are two main ways to integrate SUDO with IPA. One with SSSD integration and another without. The one with the SSSD integration was a tech preview in 6.3 and did not work well so we will set is aside for now (but we fixed it and it is coming in 6.4 as a supported feature). So the only reasonable option ATM is to setup sudo without SSSD integration. So this solution implies that SUDO will use LDAP to get data from the LDAP server and LDAP server happens to be IPA in this case. You need to configure SUDO with LDAP as one would do following the instructions provided by SUDO package. Please search archives of the last month. There have been couple threads that you can find helpful in your quest. Kee in mind that the location and name of the file used by sudo to configure LDAP connection has changed. The exact names of the files and recommendations you will find in the mentioned threads. Once you configured SUDO and if you still have problems please let us know and we will help to troubleshoot the issue. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From Steven.Jones at vuw.ac.nz Thu Nov 8 03:36:39 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Thu, 8 Nov 2012 03:36:39 +0000 Subject: [Freeipa-users] Managing Sudo through FreeIPA In-Reply-To: References: Message-ID: <833D8E48405E064EBC54C84EC6B36E405471D2B7@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, I assume rhel6.3 by the el6 in the rpm.... 1) Make sure the host and IPA server are fully patched/updated. 2) Edit nsswitch.conf to have "sudoers: files ldap" as the last line, may or may not be there. 3) add lines to /etc/sudo-ldap.conf, takes a recent upgrade/patch of 6.3 for that file to "appear" Im not at work so I odnt have a pastable set 4) Add "nisdomainname example.com" to /etc/rc.d/rc.local. 5) Add or enable the sudo "connection" user in IPA with a password. 6) reboot the host If it doesnt work set the debug level in sudo-ldap.conf to 2 and re-try to see the output..restart sssd. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of William Muriithi [william.muriithi at gmail.com] Sent: Thursday, 8 November 2012 10:28 a.m. To: freeipa-users at redhat.com Subject: [Freeipa-users] Managing Sudo through FreeIPA Hello I have been trying to setup user access through sudo file managed by FreeIPA and it don't seem to be working. I am not sure how to go about fixing it, but I guess the best place to start is ask what I should expect the IPA installation script should set up and what should be done manually [root at demo2 wmuriithi]# rpm -qa | grep sssd sssd-client-1.8.0-32.el6.x86_64 sssd-1.8.0-32.el6.x86_64 [root at demo2 wmuriithi]# [root at demo2 wmuriithi]# rpm -qa | grep sudo sudo-1.7.4p5-13.el6_3.x86_64 The only errors related to sudo that I can find is on apache error logs [Wed Nov 07 13:16:18 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: sudorule_add_user(u'read_only_viewiers', all=False, raw=False, version=u'2.34', group=(u'operations',)): SUCCESS [Wed Nov 07 13:54:44 2012] [error] ipa: ERROR: release_ipa_ccache: ccache_name (FILE:/var/run/ipa_memcached/krbcc_3988) != KRB5CCNAME environment variable (FILE:/tmp/krb5cc_apache_NB7pph) [Wed Nov 07 13:54:44 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: sudorule_find(None, sizelimit=0, pkey_only=True): SUCCESS [Wed Nov 07 13:54:44 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: batch: sudorule_show(u'Full_Access', all=True): SUCCESS [Wed Nov 07 13:54:44 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: batch: sudorule_show(u'read_only_viewiers', all=True): SUCCESS [Wed Nov 07 13:54:44 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: batch: sudorule_show(u'developers', all=True): SUCCESS [Wed Nov 07 13:54:44 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: batch: sudorule_show(u'operation', all=True): SUCCESS [Wed Nov 07 13:54:44 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: batch(({u'params': [[u'Full_Access'], {u'all': True}], u'method': u'sudorule_show'}, {u'params': [[u'read_only_viewiers'], {u'all': True}], u'method': u'sudorule_show'}, {u'params': [[u'developers'], {u'all': True}], u'method': u'sudorule_show'}, {u'params': [[u'operation'], {u'all': True}], u'method': u'sudorule_show'})): SUCCESS [Wed Nov 07 13:54:50 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: sudorule_show(u'read_only_viewiers', rights=True, all=True): SUCCESS I created the user as below and associated it with a group, which I then allowed to use less for reading file. As you can see below, it seem to does not work. Nov 7 16:05:42 demo2 sudo: pam_sss(sudo:auth): authentication success; logname=williamm uid=0 euid=0 tty=/dev/pts/2 ruser=williamm rhost= user=williamm Nov 7 16:05:43 demo2 sudo: williamm : user NOT in sudoers ; TTY=pts/2 ; PWD=/home/wmuriithi ; USER=root ; COMMAND=/usr/bin/less /var/log/secure - My question is, does the client install script take care of sudo configuration or is that done manually? I don't see any sudo related flag on the client installation script. - I have tried configuring sssd for sudo use and it didn't go well. Last time I messed around with LDAP managed sudo, I have to install a LDAP capable sudo package. The ipa-client install did not install this package. Does IPA sudo management work differently? - Where would I check for logs? I checked sssd logs and they are empty. - I am missing the basedn configuration on sssd configuration. From this bug, it should have been setup by installer, oddly though it was not setup and the bug is closed. I attempted to fix it by adding the line below but it make sudo completely unusable. It could not find any valid users apparently https://fedorahosted.org/freeipa/ticket/932 ldap_netgroup_search_base = cn=ng,cn=compat,dc=example,dc=loc Nov 7 16:05:42 demo2 sudo: pam_sss(sudo:auth): authentication success; logname=williamm uid=0 euid=0 tty=/dev/pts/2 ruser=williamm rhost= user=williamm Nov 7 16:05:43 demo2 sudo: williamm : user NOT in sudoers ; TTY=pts/2 ; PWD=/home/wmuriithi ; USER=root ; COMMAND=/usr/bin/less /var/log/secure Any pointers on why we are going? Thank you a lot in advance. William ---------------------------- [root at ipa1-yyz-int wmuriithi]# ipa sudocmd-add --desc='For reading log files' '/usr/bin/less' ---------------------------------- Added Sudo Command "/usr/bin/less" ---------------------------------- Sudo Command: /usr/bin/less Description: For reading log files [root at ipa1-yyz-int wmuriithi]# ipa sudocmdgroup-add --desc='Read Only Commands' readonly ----------------------------------- Added Sudo Command Group "readonly" ----------------------------------- Sudo Command Group: readonly Description: Read Only Commands [root at ipa1-yyz-int wmuriithi]# ipa sudocmdgroup-add-member --sudocmds='/usr/bin/less' readonly Sudo Command Group: readonly Description: Read Only Commands Member Sudo commands: /usr/bin/less ------------------------- Number of members added 1 ------------------------- [root at ipa1-yyz-int wmuriithi]# ipa sudorule-add testing_viewiers ----------------------------------- Added Sudo Rule "testing_viewiers" ----------------------------------- Rule name: testing_viewiers Enabled: TRUE [root at ipa1-yyz-int wmuriithi]# ipa sudorule-add-allow-command --sudocmdgroups=readonly testing_viewiers Rule name: testing_viewiers Enabled: TRUE Sudo Allow Command Groups: readonly ------------------------- Number of members added 1 ------------------------- [root at ipa1-yyz-int wmuriithi]# ipa hostgroup-add demo Description: Demonstration systems >>> Description: Leading and trailing spaces are not allowed Description: Demonstration system ---------------------- Added hostgroup "demo" ---------------------- Host-group: demo Description: Demonstration system [root at ipa1-yyz-int wmuriithi]# ipa hostgroup-add-member --hosts=demo2.yyz.int.testing.com demo Host-group: demo Description: Demonstration system Member hosts: demo2.yyz.int.testing.com ------------------------- Number of members added 1 ------------------------- [root at ipa1-yyz-int wmuriithi]# ipa sudorule-add-host --hostgroups=demo testing_viewiers Rule name: testing_viewiers Enabled: TRUE Host Groups: demo Sudo Allow Command Groups: readonly ------------------------- Number of members added 1 ------------------------- [root at ipa1-yyz-int wmuriithi]# ipa sudorule-add-user --groups=operations testing_viewiers Rule name: testing_viewiers Enabled: TRUE User Groups: operations Host Groups: demo Sudo Allow Command Groups: readonly ------------------------- Number of members added 1 ------------------------- _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From william.muriithi at gmail.com Thu Nov 8 15:25:37 2012 From: william.muriithi at gmail.com (William Muriithi) Date: Thu, 8 Nov 2012 10:25:37 -0500 Subject: [Freeipa-users] Managing Sudo through FreeIPA Message-ID: Dmitri, > > The SODO integration is evolving so it important to know what OS and > version you are on. > I would assume you are on RHEL6.3 or equivalent. That's correct. I am on RHEL6.3 equivalent > There are two main ways to integrate SUDO with IPA. One with SSSD > integration and another without. The one with the SSSD integration was a > tech preview in 6.3 and did not work well so we will set is aside for > now (but we fixed it and it is coming in 6.4 as a supported feature). > Neat, looks forward to 6.4 > So the only reasonable option ATM is to setup sudo without SSSD integration. > > So this solution implies that SUDO will use LDAP to get data from the > LDAP server and LDAP server happens to be IPA in this case. > You need to configure SUDO with LDAP as one would do following the > instructions provided by SUDO package. > Please search archives of the last month. There have been couple threads > that you can find helpful in your quest. > Thank you for the pointer... Looking at the archive now > Kee in mind that the location and name of the file used by sudo to > configure LDAP connection has changed. The exact names of the files and > recommendations you will find in the mentioned threads. > > Once you configured SUDO and if you still have problems please let us > know and we will help to troubleshoot the issue. > Thank you aagain William > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > From william.muriithi at gmail.com Thu Nov 8 17:11:46 2012 From: william.muriithi at gmail.com (William Muriithi) Date: Thu, 8 Nov 2012 12:11:46 -0500 Subject: [Freeipa-users] Managing Sudo through FreeIPA In-Reply-To: References: Message-ID: Steven, Thanks for the pointers. I remember finding a post on this, but having problem finding it now > > I assume rhel6.3 by the el6 in the rpm.... > > 1) Make sure the host and IPA server are fully patched/updated. I am current already > 2) Edit nsswitch.conf to have "sudoers: files ldap" as the last line, may or may not be there. Done > 3) add lines to /etc/sudo-ldap.conf, takes a recent upgrade/patch of 6.3 for that file to "appear" Im not at work so I odnt have a pastable set Yes, the file was there already. Wonder if you can paste it now. Mine was like this uri ldap://ipa1-yyz-int.example.loc sudoers_base ou=SUDOers,dc=example,dc=loc ssl start_tls tls_checkpeer (yes) tls_cacertfile /etc/ipa/ca.crt > 4) Add "nisdomainname example.com" to /etc/rc.d/rc.local. Done > 5) Add or enable the sudo "connection" user in IPA with a password. ? Lost me here, mind explaining a bit please if you have a chance? > 6) reboot the host > > If it doesnt work set the debug level in sudo-ldap.conf to 2 and re-try to see the output..restart sssd. > sh-4.1$ sudo less /var/log/secure LDAP Config Summary =================== uri ldap://ipa1-yyz-int.example.loc ldap_version 3 sudoers_base ou=SUDOers,dc=example,dc=loc binddn (anonymous) bindpw (anonymous) ssl start_tls tls_checkpeer (no) tls_cacertfile /etc/ipa/ca.crt =================== sudo: ldap_set_option: debug -> 0 sudo: ldap_set_option: tls_checkpeer -> 0 sudo: ldap_set_option: tls_cacertfile -> /etc/ipa/ca.crt sudo: ldap_set_option: tls_cacert -> /etc/ipa/ca.crt sudo: ldap_initialize(ld, ldap://ipa1-yyz-int.example.loc) sudo: ldap_set_option: ldap_version -> 3 sudo: ldap_start_tls_s() ok sudo: ldap_sasl_bind_s() ok sudo: no default options found in ou=SUDOers,dc=example,dc=loc sudo: ldap search '(|(sudoUser=williamm)(sudoUser=%williamm)(sudoUser=%operations)(sudoUser=ALL))' sudo: ldap search 'sudoUser=+*' sudo: user_matches=0 sudo: host_matches=0 sudo: sudo_ldap_lookup(0)=0x60 [sudo] password for williamm: williamm is not in the sudoers file. This incident will be reported. Thank you again for your help Regards, William > regards > Steven Jones > Technical Specialist - Linux RHCE > Victoria University, Wellington, NZ > 0064 4 463 6272 > > > > ________________________________________ > From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of William Muriithi [william.muriithi at gmail.com] > Sent: Thursday, 8 November 2012 10:28 a.m. > To: freeipa-users at redhat.com > Subject: [Freeipa-users] Managing Sudo through FreeIPA > > Hello > > I have been trying to setup user access through sudo file managed by > FreeIPA and it don't seem to be working. I am not sure how to go > about fixing it, but I guess the best place to start is ask what I > should expect the IPA installation script should set up and what > should be done manually > > [root at demo2 wmuriithi]# rpm -qa | grep sssd > sssd-client-1.8.0-32.el6.x86_64 > sssd-1.8.0-32.el6.x86_64 > [root at demo2 wmuriithi]# > > > > [root at demo2 wmuriithi]# rpm -qa | grep sudo > sudo-1.7.4p5-13.el6_3.x86_64 > > The only errors related to sudo that I can find is on apache error logs > > [Wed Nov 07 13:16:18 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: > sudorule_add_user(u'read_only_viewiers', all=False, raw=False, > version=u'2.34', group=(u'operations',)): SUCCESS > [Wed Nov 07 13:54:44 2012] [error] ipa: ERROR: release_ipa_ccache: > ccache_name (FILE:/var/run/ipa_memcached/krbcc_3988) != KRB5CCNAME > environment variable (FILE:/tmp/krb5cc_apache_NB7pph) > [Wed Nov 07 13:54:44 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: > sudorule_find(None, sizelimit=0, pkey_only=True): SUCCESS > [Wed Nov 07 13:54:44 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: > batch: sudorule_show(u'Full_Access', all=True): SUCCESS > [Wed Nov 07 13:54:44 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: > batch: sudorule_show(u'read_only_viewiers', all=True): SUCCESS > [Wed Nov 07 13:54:44 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: > batch: sudorule_show(u'developers', all=True): SUCCESS > [Wed Nov 07 13:54:44 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: > batch: sudorule_show(u'operation', all=True): SUCCESS > [Wed Nov 07 13:54:44 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: > batch(({u'params': [[u'Full_Access'], {u'all': True}], u'method': > u'sudorule_show'}, {u'params': [[u'read_only_viewiers'], {u'all': > True}], u'method': u'sudorule_show'}, {u'params': [[u'developers'], > {u'all': True}], u'method': u'sudorule_show'}, {u'params': > [[u'operation'], {u'all': True}], u'method': u'sudorule_show'})): > SUCCESS > [Wed Nov 07 13:54:50 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: > sudorule_show(u'read_only_viewiers', rights=True, all=True): SUCCESS > > > I created the user as below and associated it with a group, which I > then allowed to use less for reading file. As you can see below, it > seem to does not work. > > Nov 7 16:05:42 demo2 sudo: pam_sss(sudo:auth): authentication > success; logname=williamm uid=0 euid=0 tty=/dev/pts/2 ruser=williamm > rhost= user=williamm > Nov 7 16:05:43 demo2 sudo: williamm : user NOT in sudoers ; TTY=pts/2 > ; PWD=/home/wmuriithi ; USER=root ; COMMAND=/usr/bin/less > /var/log/secure > > > - My question is, does the client install script take care of sudo > configuration or is that done manually? I don't see any sudo related > flag on the client installation script. > > - I have tried configuring sssd for sudo use and it didn't go well. > Last time I messed around with LDAP managed sudo, I have to install a > LDAP capable sudo package. The ipa-client install did not install > this package. Does IPA sudo management work differently? > > - Where would I check for logs? I checked sssd logs and they are empty. > > - I am missing the basedn configuration on sssd configuration. From > this bug, it should have been setup by installer, oddly though it was > not setup and the bug is closed. I attempted to fix it by adding the > line below but it make sudo completely unusable. It could not find > any valid users apparently > > https://fedorahosted.org/freeipa/ticket/932 > > ldap_netgroup_search_base = cn=ng,cn=compat,dc=example,dc=loc > > Nov 7 16:05:42 demo2 sudo: pam_sss(sudo:auth): authentication > success; logname=williamm uid=0 euid=0 tty=/dev/pts/2 ruser=williamm > rhost= user=williamm > Nov 7 16:05:43 demo2 sudo: williamm : user NOT in sudoers ; TTY=pts/2 > ; PWD=/home/wmuriithi ; USER=root ; COMMAND=/usr/bin/less > /var/log/secure > > > Any pointers on why we are going? > > Thank you a lot in advance. > > William > > ---------------------------- > [root at ipa1-yyz-int wmuriithi]# ipa sudocmd-add --desc='For reading log > files' '/usr/bin/less' > ---------------------------------- > Added Sudo Command "/usr/bin/less" > ---------------------------------- > Sudo Command: /usr/bin/less > Description: For reading log files > [root at ipa1-yyz-int wmuriithi]# ipa sudocmdgroup-add --desc='Read Only > Commands' readonly > ----------------------------------- > Added Sudo Command Group "readonly" > ----------------------------------- > Sudo Command Group: readonly > Description: Read Only Commands > [root at ipa1-yyz-int wmuriithi]# ipa sudocmdgroup-add-member > --sudocmds='/usr/bin/less' readonly > Sudo Command Group: readonly > Description: Read Only Commands > Member Sudo commands: /usr/bin/less > ------------------------- > Number of members added 1 > ------------------------- > [root at ipa1-yyz-int wmuriithi]# ipa sudorule-add testing_viewiers > ----------------------------------- > Added Sudo Rule "testing_viewiers" > ----------------------------------- > Rule name: testing_viewiers > Enabled: TRUE > [root at ipa1-yyz-int wmuriithi]# ipa sudorule-add-allow-command > --sudocmdgroups=readonly testing_viewiers > Rule name: testing_viewiers > Enabled: TRUE > Sudo Allow Command Groups: readonly > ------------------------- > Number of members added 1 > ------------------------- > [root at ipa1-yyz-int wmuriithi]# ipa hostgroup-add demo > Description: Demonstration systems >>>> Description: Leading and trailing spaces are not allowed > Description: Demonstration system > ---------------------- > Added hostgroup "demo" > ---------------------- > Host-group: demo > Description: Demonstration system > [root at ipa1-yyz-int wmuriithi]# ipa hostgroup-add-member > --hosts=demo2.yyz.int.testing.com demo > Host-group: demo > Description: Demonstration system > Member hosts: demo2.yyz.int.testing.com > ------------------------- > Number of members added 1 > ------------------------- > [root at ipa1-yyz-int wmuriithi]# ipa sudorule-add-host --hostgroups=demo > testing_viewiers > Rule name: testing_viewiers > Enabled: TRUE > Host Groups: demo > Sudo Allow Command Groups: readonly > ------------------------- > Number of members added 1 > ------------------------- > [root at ipa1-yyz-int wmuriithi]# ipa sudorule-add-user > --groups=operations testing_viewiers > Rule name: testing_viewiers > Enabled: TRUE > User Groups: operations > Host Groups: demo > Sudo Allow Command Groups: readonly > ------------------------- > Number of members added 1 > ------------------------- > > _______________________________________________ > 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 > > End of Freeipa-users Digest, Vol 52, Issue 18 > ********************************************* From JR.Aquino at citrix.com Thu Nov 8 17:36:24 2012 From: JR.Aquino at citrix.com (JR Aquino) Date: Thu, 8 Nov 2012 17:36:24 +0000 Subject: [Freeipa-users] Managing Sudo through FreeIPA In-Reply-To: References: Message-ID: <06E801C0-0711-47A0-B820-A3BFD2D6C80A@citrixonline.com> If you go to the CLI on the FreeIPA server and type: ipa sudorule It will give you some useful info. I believe you asked about the sudo user (which your log shows as currently unset, and configured as anonymous) Here is a snipit: -=-=-=-=-=- ... FreeIPA provides a designated binddn to use with Sudo located at: uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com To enable the binddn run the following command to set the password: LDAPTLS_CACERT=/etc/ipa/ca.crt /usr/bin/ldappasswd -S -W -h ipa.example.com -ZZ -D "cn=Directory Manager" uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com For more information, see the FreeIPA Documentation to Sudo. -=-=-=-=-=- The resulting user needs to be configured in your sudo-ldap.conf with: binddn uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com bindpw "Keeping your head in the cloud" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jr Aquino | Sr. Information Security Specialist GIAC Certified Incident Handler | GIAC WebApp Penetration Tester Citrix Online | 7408 Hollister Avenue | Goleta, CA 93117 T: +1 805.690.3478 C: +1 805.717.0365 jr.aquino at citrix.com http://www.citrixonline.com On Nov 8, 2012, at 9:11 AM, William Muriithi > wrote: Steven, Thanks for the pointers. I remember finding a post on this, but having problem finding it now I assume rhel6.3 by the el6 in the rpm.... 1) Make sure the host and IPA server are fully patched/updated. I am current already 2) Edit nsswitch.conf to have "sudoers: files ldap" as the last line, may or may not be there. Done 3) add lines to /etc/sudo-ldap.conf, takes a recent upgrade/patch of 6.3 for that file to "appear" Im not at work so I odnt have a pastable set Yes, the file was there already. Wonder if you can paste it now. Mine was like this uri ldap://ipa1-yyz-int.example.loc sudoers_base ou=SUDOers,dc=example,dc=loc ssl start_tls tls_checkpeer (yes) tls_cacertfile /etc/ipa/ca.crt 4) Add "nisdomainname example.com" to /etc/rc.d/rc.local. Done 5) Add or enable the sudo "connection" user in IPA with a password. ? Lost me here, mind explaining a bit please if you have a chance? 6) reboot the host If it doesnt work set the debug level in sudo-ldap.conf to 2 and re-try to see the output..restart sssd. sh-4.1$ sudo less /var/log/secure LDAP Config Summary =================== uri ldap://ipa1-yyz-int.example.loc ldap_version 3 sudoers_base ou=SUDOers,dc=example,dc=loc binddn (anonymous) bindpw (anonymous) ssl start_tls tls_checkpeer (no) tls_cacertfile /etc/ipa/ca.crt =================== sudo: ldap_set_option: debug -> 0 sudo: ldap_set_option: tls_checkpeer -> 0 sudo: ldap_set_option: tls_cacertfile -> /etc/ipa/ca.crt sudo: ldap_set_option: tls_cacert -> /etc/ipa/ca.crt sudo: ldap_initialize(ld, ldap://ipa1-yyz-int.example.loc) sudo: ldap_set_option: ldap_version -> 3 sudo: ldap_start_tls_s() ok sudo: ldap_sasl_bind_s() ok sudo: no default options found in ou=SUDOers,dc=example,dc=loc sudo: ldap search '(|(sudoUser=williamm)(sudoUser=%williamm)(sudoUser=%operations)(sudoUser=ALL))' sudo: ldap search 'sudoUser=+*' sudo: user_matches=0 sudo: host_matches=0 sudo: sudo_ldap_lookup(0)=0x60 [sudo] password for williamm: williamm is not in the sudoers file. This incident will be reported. Thank you again for your help Regards, William regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of William Muriithi [william.muriithi at gmail.com] Sent: Thursday, 8 November 2012 10:28 a.m. To: freeipa-users at redhat.com Subject: [Freeipa-users] Managing Sudo through FreeIPA Hello I have been trying to setup user access through sudo file managed by FreeIPA and it don't seem to be working. I am not sure how to go about fixing it, but I guess the best place to start is ask what I should expect the IPA installation script should set up and what should be done manually [root at demo2 wmuriithi]# rpm -qa | grep sssd sssd-client-1.8.0-32.el6.x86_64 sssd-1.8.0-32.el6.x86_64 [root at demo2 wmuriithi]# [root at demo2 wmuriithi]# rpm -qa | grep sudo sudo-1.7.4p5-13.el6_3.x86_64 The only errors related to sudo that I can find is on apache error logs [Wed Nov 07 13:16:18 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: sudorule_add_user(u'read_only_viewiers', all=False, raw=False, version=u'2.34', group=(u'operations',)): SUCCESS [Wed Nov 07 13:54:44 2012] [error] ipa: ERROR: release_ipa_ccache: ccache_name (FILE:/var/run/ipa_memcached/krbcc_3988) != KRB5CCNAME environment variable (FILE:/tmp/krb5cc_apache_NB7pph) [Wed Nov 07 13:54:44 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: sudorule_find(None, sizelimit=0, pkey_only=True): SUCCESS [Wed Nov 07 13:54:44 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: batch: sudorule_show(u'Full_Access', all=True): SUCCESS [Wed Nov 07 13:54:44 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: batch: sudorule_show(u'read_only_viewiers', all=True): SUCCESS [Wed Nov 07 13:54:44 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: batch: sudorule_show(u'developers', all=True): SUCCESS [Wed Nov 07 13:54:44 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: batch: sudorule_show(u'operation', all=True): SUCCESS [Wed Nov 07 13:54:44 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: batch(({u'params': [[u'Full_Access'], {u'all': True}], u'method': u'sudorule_show'}, {u'params': [[u'read_only_viewiers'], {u'all': True}], u'method': u'sudorule_show'}, {u'params': [[u'developers'], {u'all': True}], u'method': u'sudorule_show'}, {u'params': [[u'operation'], {u'all': True}], u'method': u'sudorule_show'})): SUCCESS [Wed Nov 07 13:54:50 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: sudorule_show(u'read_only_viewiers', rights=True, all=True): SUCCESS I created the user as below and associated it with a group, which I then allowed to use less for reading file. As you can see below, it seem to does not work. Nov 7 16:05:42 demo2 sudo: pam_sss(sudo:auth): authentication success; logname=williamm uid=0 euid=0 tty=/dev/pts/2 ruser=williamm rhost= user=williamm Nov 7 16:05:43 demo2 sudo: williamm : user NOT in sudoers ; TTY=pts/2 ; PWD=/home/wmuriithi ; USER=root ; COMMAND=/usr/bin/less /var/log/secure - My question is, does the client install script take care of sudo configuration or is that done manually? I don't see any sudo related flag on the client installation script. - I have tried configuring sssd for sudo use and it didn't go well. Last time I messed around with LDAP managed sudo, I have to install a LDAP capable sudo package. The ipa-client install did not install this package. Does IPA sudo management work differently? - Where would I check for logs? I checked sssd logs and they are empty. - I am missing the basedn configuration on sssd configuration. From this bug, it should have been setup by installer, oddly though it was not setup and the bug is closed. I attempted to fix it by adding the line below but it make sudo completely unusable. It could not find any valid users apparently https://fedorahosted.org/freeipa/ticket/932 ldap_netgroup_search_base = cn=ng,cn=compat,dc=example,dc=loc Nov 7 16:05:42 demo2 sudo: pam_sss(sudo:auth): authentication success; logname=williamm uid=0 euid=0 tty=/dev/pts/2 ruser=williamm rhost= user=williamm Nov 7 16:05:43 demo2 sudo: williamm : user NOT in sudoers ; TTY=pts/2 ; PWD=/home/wmuriithi ; USER=root ; COMMAND=/usr/bin/less /var/log/secure Any pointers on why we are going? Thank you a lot in advance. William ---------------------------- [root at ipa1-yyz-int wmuriithi]# ipa sudocmd-add --desc='For reading log files' '/usr/bin/less' ---------------------------------- Added Sudo Command "/usr/bin/less" ---------------------------------- Sudo Command: /usr/bin/less Description: For reading log files [root at ipa1-yyz-int wmuriithi]# ipa sudocmdgroup-add --desc='Read Only Commands' readonly ----------------------------------- Added Sudo Command Group "readonly" ----------------------------------- Sudo Command Group: readonly Description: Read Only Commands [root at ipa1-yyz-int wmuriithi]# ipa sudocmdgroup-add-member --sudocmds='/usr/bin/less' readonly Sudo Command Group: readonly Description: Read Only Commands Member Sudo commands: /usr/bin/less ------------------------- Number of members added 1 ------------------------- [root at ipa1-yyz-int wmuriithi]# ipa sudorule-add testing_viewiers ----------------------------------- Added Sudo Rule "testing_viewiers" ----------------------------------- Rule name: testing_viewiers Enabled: TRUE [root at ipa1-yyz-int wmuriithi]# ipa sudorule-add-allow-command --sudocmdgroups=readonly testing_viewiers Rule name: testing_viewiers Enabled: TRUE Sudo Allow Command Groups: readonly ------------------------- Number of members added 1 ------------------------- [root at ipa1-yyz-int wmuriithi]# ipa hostgroup-add demo Description: Demonstration systems Description: Leading and trailing spaces are not allowed Description: Demonstration system ---------------------- Added hostgroup "demo" ---------------------- Host-group: demo Description: Demonstration system [root at ipa1-yyz-int wmuriithi]# ipa hostgroup-add-member --hosts=demo2.yyz.int.testing.com demo Host-group: demo Description: Demonstration system Member hosts: demo2.yyz.int.testing.com ------------------------- Number of members added 1 ------------------------- [root at ipa1-yyz-int wmuriithi]# ipa sudorule-add-host --hostgroups=demo testing_viewiers Rule name: testing_viewiers Enabled: TRUE Host Groups: demo Sudo Allow Command Groups: readonly ------------------------- Number of members added 1 ------------------------- [root at ipa1-yyz-int wmuriithi]# ipa sudorule-add-user --groups=operations testing_viewiers Rule name: testing_viewiers Enabled: TRUE User Groups: operations Host Groups: demo Sudo Allow Command Groups: readonly ------------------------- Number of members added 1 ------------------------- _______________________________________________ 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 End of Freeipa-users Digest, Vol 52, Issue 18 ********************************************* _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From william.muriithi at gmail.com Thu Nov 8 18:15:50 2012 From: william.muriithi at gmail.com (William Muriithi) Date: Thu, 8 Nov 2012 13:15:50 -0500 Subject: [Freeipa-users] Managing Sudo through FreeIPA In-Reply-To: References: Message-ID: FYI Got it working, credit to JR for pointing I need to assign a password to sudo account on LDAP and use it for binding. Thanks a lot William On 8 November 2012 12:11, William Muriithi wrote: > Steven, > > Thanks for the pointers. I remember finding a post on this, but having > problem finding it now >> >> I assume rhel6.3 by the el6 in the rpm.... >> >> 1) Make sure the host and IPA server are fully patched/updated. > I am current already > >> 2) Edit nsswitch.conf to have "sudoers: files ldap" as the last line, may or may not be there. > > Done > >> 3) add lines to /etc/sudo-ldap.conf, takes a recent upgrade/patch of 6.3 for that file to "appear" Im not at work so I odnt have a pastable set > Yes, the file was there already. Wonder if you can paste it now. > Mine was like this > > uri ldap://ipa1-yyz-int.example.loc > > sudoers_base ou=SUDOers,dc=example,dc=loc > > ssl start_tls > tls_checkpeer (yes) > tls_cacertfile /etc/ipa/ca.crt > > >> 4) Add "nisdomainname example.com" to /etc/rc.d/rc.local. > Done >> 5) Add or enable the sudo "connection" user in IPA with a password. > ? Lost me here, mind explaining a bit please if you have a chance? >> 6) reboot the host >> >> If it doesnt work set the debug level in sudo-ldap.conf to 2 and re-try to see the output..restart sssd. >> > sh-4.1$ sudo less /var/log/secure > LDAP Config Summary > =================== > uri ldap://ipa1-yyz-int.example.loc > ldap_version 3 > sudoers_base ou=SUDOers,dc=example,dc=loc > binddn (anonymous) > bindpw (anonymous) > ssl start_tls > tls_checkpeer (no) > tls_cacertfile /etc/ipa/ca.crt > =================== > sudo: ldap_set_option: debug -> 0 > sudo: ldap_set_option: tls_checkpeer -> 0 > sudo: ldap_set_option: tls_cacertfile -> /etc/ipa/ca.crt > sudo: ldap_set_option: tls_cacert -> /etc/ipa/ca.crt > sudo: ldap_initialize(ld, ldap://ipa1-yyz-int.example.loc) > sudo: ldap_set_option: ldap_version -> 3 > sudo: ldap_start_tls_s() ok > sudo: ldap_sasl_bind_s() ok > sudo: no default options found in ou=SUDOers,dc=example,dc=loc > sudo: ldap search > '(|(sudoUser=williamm)(sudoUser=%williamm)(sudoUser=%operations)(sudoUser=ALL))' > sudo: ldap search 'sudoUser=+*' > sudo: user_matches=0 > sudo: host_matches=0 > sudo: sudo_ldap_lookup(0)=0x60 > [sudo] password for williamm: > williamm is not in the sudoers file. This incident will be reported. > > > Thank you again for your help > > Regards, > > William >> regards >> Steven Jones >> Technical Specialist - Linux RHCE >> Victoria University, Wellington, NZ >> 0064 4 463 6272 >> >> >> >> ________________________________________ >> From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of William Muriithi [william.muriithi at gmail.com] >> Sent: Thursday, 8 November 2012 10:28 a.m. >> To: freeipa-users at redhat.com >> Subject: [Freeipa-users] Managing Sudo through FreeIPA >> >> Hello >> >> I have been trying to setup user access through sudo file managed by >> FreeIPA and it don't seem to be working. I am not sure how to go >> about fixing it, but I guess the best place to start is ask what I >> should expect the IPA installation script should set up and what >> should be done manually >> >> [root at demo2 wmuriithi]# rpm -qa | grep sssd >> sssd-client-1.8.0-32.el6.x86_64 >> sssd-1.8.0-32.el6.x86_64 >> [root at demo2 wmuriithi]# >> >> >> >> [root at demo2 wmuriithi]# rpm -qa | grep sudo >> sudo-1.7.4p5-13.el6_3.x86_64 >> >> The only errors related to sudo that I can find is on apache error logs >> >> [Wed Nov 07 13:16:18 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: >> sudorule_add_user(u'read_only_viewiers', all=False, raw=False, >> version=u'2.34', group=(u'operations',)): SUCCESS >> [Wed Nov 07 13:54:44 2012] [error] ipa: ERROR: release_ipa_ccache: >> ccache_name (FILE:/var/run/ipa_memcached/krbcc_3988) != KRB5CCNAME >> environment variable (FILE:/tmp/krb5cc_apache_NB7pph) >> [Wed Nov 07 13:54:44 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: >> sudorule_find(None, sizelimit=0, pkey_only=True): SUCCESS >> [Wed Nov 07 13:54:44 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: >> batch: sudorule_show(u'Full_Access', all=True): SUCCESS >> [Wed Nov 07 13:54:44 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: >> batch: sudorule_show(u'read_only_viewiers', all=True): SUCCESS >> [Wed Nov 07 13:54:44 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: >> batch: sudorule_show(u'developers', all=True): SUCCESS >> [Wed Nov 07 13:54:44 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: >> batch: sudorule_show(u'operation', all=True): SUCCESS >> [Wed Nov 07 13:54:44 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: >> batch(({u'params': [[u'Full_Access'], {u'all': True}], u'method': >> u'sudorule_show'}, {u'params': [[u'read_only_viewiers'], {u'all': >> True}], u'method': u'sudorule_show'}, {u'params': [[u'developers'], >> {u'all': True}], u'method': u'sudorule_show'}, {u'params': >> [[u'operation'], {u'all': True}], u'method': u'sudorule_show'})): >> SUCCESS >> [Wed Nov 07 13:54:50 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: >> sudorule_show(u'read_only_viewiers', rights=True, all=True): SUCCESS >> >> >> I created the user as below and associated it with a group, which I >> then allowed to use less for reading file. As you can see below, it >> seem to does not work. >> >> Nov 7 16:05:42 demo2 sudo: pam_sss(sudo:auth): authentication >> success; logname=williamm uid=0 euid=0 tty=/dev/pts/2 ruser=williamm >> rhost= user=williamm >> Nov 7 16:05:43 demo2 sudo: williamm : user NOT in sudoers ; TTY=pts/2 >> ; PWD=/home/wmuriithi ; USER=root ; COMMAND=/usr/bin/less >> /var/log/secure >> >> >> - My question is, does the client install script take care of sudo >> configuration or is that done manually? I don't see any sudo related >> flag on the client installation script. >> >> - I have tried configuring sssd for sudo use and it didn't go well. >> Last time I messed around with LDAP managed sudo, I have to install a >> LDAP capable sudo package. The ipa-client install did not install >> this package. Does IPA sudo management work differently? >> >> - Where would I check for logs? I checked sssd logs and they are empty. >> >> - I am missing the basedn configuration on sssd configuration. From >> this bug, it should have been setup by installer, oddly though it was >> not setup and the bug is closed. I attempted to fix it by adding the >> line below but it make sudo completely unusable. It could not find >> any valid users apparently >> >> https://fedorahosted.org/freeipa/ticket/932 >> >> ldap_netgroup_search_base = cn=ng,cn=compat,dc=example,dc=loc >> >> Nov 7 16:05:42 demo2 sudo: pam_sss(sudo:auth): authentication >> success; logname=williamm uid=0 euid=0 tty=/dev/pts/2 ruser=williamm >> rhost= user=williamm >> Nov 7 16:05:43 demo2 sudo: williamm : user NOT in sudoers ; TTY=pts/2 >> ; PWD=/home/wmuriithi ; USER=root ; COMMAND=/usr/bin/less >> /var/log/secure >> >> >> Any pointers on why we are going? >> >> Thank you a lot in advance. >> >> William >> >> ---------------------------- >> [root at ipa1-yyz-int wmuriithi]# ipa sudocmd-add --desc='For reading log >> files' '/usr/bin/less' >> ---------------------------------- >> Added Sudo Command "/usr/bin/less" >> ---------------------------------- >> Sudo Command: /usr/bin/less >> Description: For reading log files >> [root at ipa1-yyz-int wmuriithi]# ipa sudocmdgroup-add --desc='Read Only >> Commands' readonly >> ----------------------------------- >> Added Sudo Command Group "readonly" >> ----------------------------------- >> Sudo Command Group: readonly >> Description: Read Only Commands >> [root at ipa1-yyz-int wmuriithi]# ipa sudocmdgroup-add-member >> --sudocmds='/usr/bin/less' readonly >> Sudo Command Group: readonly >> Description: Read Only Commands >> Member Sudo commands: /usr/bin/less >> ------------------------- >> Number of members added 1 >> ------------------------- >> [root at ipa1-yyz-int wmuriithi]# ipa sudorule-add testing_viewiers >> ----------------------------------- >> Added Sudo Rule "testing_viewiers" >> ----------------------------------- >> Rule name: testing_viewiers >> Enabled: TRUE >> [root at ipa1-yyz-int wmuriithi]# ipa sudorule-add-allow-command >> --sudocmdgroups=readonly testing_viewiers >> Rule name: testing_viewiers >> Enabled: TRUE >> Sudo Allow Command Groups: readonly >> ------------------------- >> Number of members added 1 >> ------------------------- >> [root at ipa1-yyz-int wmuriithi]# ipa hostgroup-add demo >> Description: Demonstration systems >>>>> Description: Leading and trailing spaces are not allowed >> Description: Demonstration system >> ---------------------- >> Added hostgroup "demo" >> ---------------------- >> Host-group: demo >> Description: Demonstration system >> [root at ipa1-yyz-int wmuriithi]# ipa hostgroup-add-member >> --hosts=demo2.yyz.int.testing.com demo >> Host-group: demo >> Description: Demonstration system >> Member hosts: demo2.yyz.int.testing.com >> ------------------------- >> Number of members added 1 >> ------------------------- >> [root at ipa1-yyz-int wmuriithi]# ipa sudorule-add-host --hostgroups=demo >> testing_viewiers >> Rule name: testing_viewiers >> Enabled: TRUE >> Host Groups: demo >> Sudo Allow Command Groups: readonly >> ------------------------- >> Number of members added 1 >> ------------------------- >> [root at ipa1-yyz-int wmuriithi]# ipa sudorule-add-user >> --groups=operations testing_viewiers >> Rule name: testing_viewiers >> Enabled: TRUE >> User Groups: operations >> Host Groups: demo >> Sudo Allow Command Groups: readonly >> ------------------------- >> Number of members added 1 >> ------------------------- >> >> _______________________________________________ >> 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 >> >> End of Freeipa-users Digest, Vol 52, Issue 18 >> ********************************************* From dpal at redhat.com Thu Nov 8 21:09:42 2012 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 08 Nov 2012 16:09:42 -0500 Subject: [Freeipa-users] Managing Sudo through FreeIPA In-Reply-To: References: Message-ID: <509C1F96.9080006@redhat.com> On 11/08/2012 01:15 PM, William Muriithi wrote: > FYI > > Got it working, credit to JR for pointing I need to assign a password > to sudo account on LDAP and use it for binding. Great to hear! > Thanks a lot > > William > > On 8 November 2012 12:11, William Muriithi wrote: >> Steven, >> >> Thanks for the pointers. I remember finding a post on this, but having >> problem finding it now >>> I assume rhel6.3 by the el6 in the rpm.... >>> >>> 1) Make sure the host and IPA server are fully patched/updated. >> I am current already >> >>> 2) Edit nsswitch.conf to have "sudoers: files ldap" as the last line, may or may not be there. >> Done >> >>> 3) add lines to /etc/sudo-ldap.conf, takes a recent upgrade/patch of 6.3 for that file to "appear" Im not at work so I odnt have a pastable set >> Yes, the file was there already. Wonder if you can paste it now. >> Mine was like this >> >> uri ldap://ipa1-yyz-int.example.loc >> >> sudoers_base ou=SUDOers,dc=example,dc=loc >> >> ssl start_tls >> tls_checkpeer (yes) >> tls_cacertfile /etc/ipa/ca.crt >> >> >>> 4) Add "nisdomainname example.com" to /etc/rc.d/rc.local. >> Done >>> 5) Add or enable the sudo "connection" user in IPA with a password. >> ? Lost me here, mind explaining a bit please if you have a chance? >>> 6) reboot the host >>> >>> If it doesnt work set the debug level in sudo-ldap.conf to 2 and re-try to see the output..restart sssd. >>> >> sh-4.1$ sudo less /var/log/secure >> LDAP Config Summary >> =================== >> uri ldap://ipa1-yyz-int.example.loc >> ldap_version 3 >> sudoers_base ou=SUDOers,dc=example,dc=loc >> binddn (anonymous) >> bindpw (anonymous) >> ssl start_tls >> tls_checkpeer (no) >> tls_cacertfile /etc/ipa/ca.crt >> =================== >> sudo: ldap_set_option: debug -> 0 >> sudo: ldap_set_option: tls_checkpeer -> 0 >> sudo: ldap_set_option: tls_cacertfile -> /etc/ipa/ca.crt >> sudo: ldap_set_option: tls_cacert -> /etc/ipa/ca.crt >> sudo: ldap_initialize(ld, ldap://ipa1-yyz-int.example.loc) >> sudo: ldap_set_option: ldap_version -> 3 >> sudo: ldap_start_tls_s() ok >> sudo: ldap_sasl_bind_s() ok >> sudo: no default options found in ou=SUDOers,dc=example,dc=loc >> sudo: ldap search >> '(|(sudoUser=williamm)(sudoUser=%williamm)(sudoUser=%operations)(sudoUser=ALL))' >> sudo: ldap search 'sudoUser=+*' >> sudo: user_matches=0 >> sudo: host_matches=0 >> sudo: sudo_ldap_lookup(0)=0x60 >> [sudo] password for williamm: >> williamm is not in the sudoers file. This incident will be reported. >> >> >> Thank you again for your help >> >> Regards, >> >> William >>> regards >>> Steven Jones >>> Technical Specialist - Linux RHCE >>> Victoria University, Wellington, NZ >>> 0064 4 463 6272 >>> >>> >>> >>> ________________________________________ >>> From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of William Muriithi [william.muriithi at gmail.com] >>> Sent: Thursday, 8 November 2012 10:28 a.m. >>> To: freeipa-users at redhat.com >>> Subject: [Freeipa-users] Managing Sudo through FreeIPA >>> >>> Hello >>> >>> I have been trying to setup user access through sudo file managed by >>> FreeIPA and it don't seem to be working. I am not sure how to go >>> about fixing it, but I guess the best place to start is ask what I >>> should expect the IPA installation script should set up and what >>> should be done manually >>> >>> [root at demo2 wmuriithi]# rpm -qa | grep sssd >>> sssd-client-1.8.0-32.el6.x86_64 >>> sssd-1.8.0-32.el6.x86_64 >>> [root at demo2 wmuriithi]# >>> >>> >>> >>> [root at demo2 wmuriithi]# rpm -qa | grep sudo >>> sudo-1.7.4p5-13.el6_3.x86_64 >>> >>> The only errors related to sudo that I can find is on apache error logs >>> >>> [Wed Nov 07 13:16:18 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: >>> sudorule_add_user(u'read_only_viewiers', all=False, raw=False, >>> version=u'2.34', group=(u'operations',)): SUCCESS >>> [Wed Nov 07 13:54:44 2012] [error] ipa: ERROR: release_ipa_ccache: >>> ccache_name (FILE:/var/run/ipa_memcached/krbcc_3988) != KRB5CCNAME >>> environment variable (FILE:/tmp/krb5cc_apache_NB7pph) >>> [Wed Nov 07 13:54:44 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: >>> sudorule_find(None, sizelimit=0, pkey_only=True): SUCCESS >>> [Wed Nov 07 13:54:44 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: >>> batch: sudorule_show(u'Full_Access', all=True): SUCCESS >>> [Wed Nov 07 13:54:44 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: >>> batch: sudorule_show(u'read_only_viewiers', all=True): SUCCESS >>> [Wed Nov 07 13:54:44 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: >>> batch: sudorule_show(u'developers', all=True): SUCCESS >>> [Wed Nov 07 13:54:44 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: >>> batch: sudorule_show(u'operation', all=True): SUCCESS >>> [Wed Nov 07 13:54:44 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: >>> batch(({u'params': [[u'Full_Access'], {u'all': True}], u'method': >>> u'sudorule_show'}, {u'params': [[u'read_only_viewiers'], {u'all': >>> True}], u'method': u'sudorule_show'}, {u'params': [[u'developers'], >>> {u'all': True}], u'method': u'sudorule_show'}, {u'params': >>> [[u'operation'], {u'all': True}], u'method': u'sudorule_show'})): >>> SUCCESS >>> [Wed Nov 07 13:54:50 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: >>> sudorule_show(u'read_only_viewiers', rights=True, all=True): SUCCESS >>> >>> >>> I created the user as below and associated it with a group, which I >>> then allowed to use less for reading file. As you can see below, it >>> seem to does not work. >>> >>> Nov 7 16:05:42 demo2 sudo: pam_sss(sudo:auth): authentication >>> success; logname=williamm uid=0 euid=0 tty=/dev/pts/2 ruser=williamm >>> rhost= user=williamm >>> Nov 7 16:05:43 demo2 sudo: williamm : user NOT in sudoers ; TTY=pts/2 >>> ; PWD=/home/wmuriithi ; USER=root ; COMMAND=/usr/bin/less >>> /var/log/secure >>> >>> >>> - My question is, does the client install script take care of sudo >>> configuration or is that done manually? I don't see any sudo related >>> flag on the client installation script. >>> >>> - I have tried configuring sssd for sudo use and it didn't go well. >>> Last time I messed around with LDAP managed sudo, I have to install a >>> LDAP capable sudo package. The ipa-client install did not install >>> this package. Does IPA sudo management work differently? >>> >>> - Where would I check for logs? I checked sssd logs and they are empty. >>> >>> - I am missing the basedn configuration on sssd configuration. From >>> this bug, it should have been setup by installer, oddly though it was >>> not setup and the bug is closed. I attempted to fix it by adding the >>> line below but it make sudo completely unusable. It could not find >>> any valid users apparently >>> >>> https://fedorahosted.org/freeipa/ticket/932 >>> >>> ldap_netgroup_search_base = cn=ng,cn=compat,dc=example,dc=loc >>> >>> Nov 7 16:05:42 demo2 sudo: pam_sss(sudo:auth): authentication >>> success; logname=williamm uid=0 euid=0 tty=/dev/pts/2 ruser=williamm >>> rhost= user=williamm >>> Nov 7 16:05:43 demo2 sudo: williamm : user NOT in sudoers ; TTY=pts/2 >>> ; PWD=/home/wmuriithi ; USER=root ; COMMAND=/usr/bin/less >>> /var/log/secure >>> >>> >>> Any pointers on why we are going? >>> >>> Thank you a lot in advance. >>> >>> William >>> >>> ---------------------------- >>> [root at ipa1-yyz-int wmuriithi]# ipa sudocmd-add --desc='For reading log >>> files' '/usr/bin/less' >>> ---------------------------------- >>> Added Sudo Command "/usr/bin/less" >>> ---------------------------------- >>> Sudo Command: /usr/bin/less >>> Description: For reading log files >>> [root at ipa1-yyz-int wmuriithi]# ipa sudocmdgroup-add --desc='Read Only >>> Commands' readonly >>> ----------------------------------- >>> Added Sudo Command Group "readonly" >>> ----------------------------------- >>> Sudo Command Group: readonly >>> Description: Read Only Commands >>> [root at ipa1-yyz-int wmuriithi]# ipa sudocmdgroup-add-member >>> --sudocmds='/usr/bin/less' readonly >>> Sudo Command Group: readonly >>> Description: Read Only Commands >>> Member Sudo commands: /usr/bin/less >>> ------------------------- >>> Number of members added 1 >>> ------------------------- >>> [root at ipa1-yyz-int wmuriithi]# ipa sudorule-add testing_viewiers >>> ----------------------------------- >>> Added Sudo Rule "testing_viewiers" >>> ----------------------------------- >>> Rule name: testing_viewiers >>> Enabled: TRUE >>> [root at ipa1-yyz-int wmuriithi]# ipa sudorule-add-allow-command >>> --sudocmdgroups=readonly testing_viewiers >>> Rule name: testing_viewiers >>> Enabled: TRUE >>> Sudo Allow Command Groups: readonly >>> ------------------------- >>> Number of members added 1 >>> ------------------------- >>> [root at ipa1-yyz-int wmuriithi]# ipa hostgroup-add demo >>> Description: Demonstration systems >>>>>> Description: Leading and trailing spaces are not allowed >>> Description: Demonstration system >>> ---------------------- >>> Added hostgroup "demo" >>> ---------------------- >>> Host-group: demo >>> Description: Demonstration system >>> [root at ipa1-yyz-int wmuriithi]# ipa hostgroup-add-member >>> --hosts=demo2.yyz.int.testing.com demo >>> Host-group: demo >>> Description: Demonstration system >>> Member hosts: demo2.yyz.int.testing.com >>> ------------------------- >>> Number of members added 1 >>> ------------------------- >>> [root at ipa1-yyz-int wmuriithi]# ipa sudorule-add-host --hostgroups=demo >>> testing_viewiers >>> Rule name: testing_viewiers >>> Enabled: TRUE >>> Host Groups: demo >>> Sudo Allow Command Groups: readonly >>> ------------------------- >>> Number of members added 1 >>> ------------------------- >>> [root at ipa1-yyz-int wmuriithi]# ipa sudorule-add-user >>> --groups=operations testing_viewiers >>> Rule name: testing_viewiers >>> Enabled: TRUE >>> User Groups: operations >>> Host Groups: demo >>> Sudo Allow Command Groups: readonly >>> ------------------------- >>> Number of members added 1 >>> ------------------------- >>> >>> _______________________________________________ >>> 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 >>> >>> End of Freeipa-users Digest, Vol 52, Issue 18 >>> ********************************************* > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From pbrezina at redhat.com Fri Nov 9 09:34:00 2012 From: pbrezina at redhat.com (=?UTF-8?B?UGF2ZWwgQsWZZXppbmE=?=) Date: Fri, 09 Nov 2012 10:34:00 +0100 Subject: [Freeipa-users] Managing Sudo through FreeIPA In-Reply-To: <509AF934.8090202@redhat.com> References: <509AF934.8090202@redhat.com> Message-ID: <509CCE08.7070502@redhat.com> On 11/08/2012 01:13 AM, Dmitri Pal wrote: > On 11/07/2012 04:28 PM, William Muriithi wrote: >> Hello >> >> I have been trying to setup user access through sudo file managed by >> FreeIPA and it don't seem to be working. I am not sure how to go >> about fixing it, but I guess the best place to start is ask what I >> should expect the IPA installation script should set up and what >> should be done manually >> >> [root at demo2 wmuriithi]# rpm -qa | grep sssd >> sssd-client-1.8.0-32.el6.x86_64 >> sssd-1.8.0-32.el6.x86_64 >> [root at demo2 wmuriithi]# >> >> >> >> [root at demo2 wmuriithi]# rpm -qa | grep sudo >> sudo-1.7.4p5-13.el6_3.x86_64 >> >> The only errors related to sudo that I can find is on apache error logs >> >> [Wed Nov 07 13:16:18 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: >> sudorule_add_user(u'read_only_viewiers', all=False, raw=False, >> version=u'2.34', group=(u'operations',)): SUCCESS >> [Wed Nov 07 13:54:44 2012] [error] ipa: ERROR: release_ipa_ccache: >> ccache_name (FILE:/var/run/ipa_memcached/krbcc_3988) != KRB5CCNAME >> environment variable (FILE:/tmp/krb5cc_apache_NB7pph) >> [Wed Nov 07 13:54:44 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: >> sudorule_find(None, sizelimit=0, pkey_only=True): SUCCESS >> [Wed Nov 07 13:54:44 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: >> batch: sudorule_show(u'Full_Access', all=True): SUCCESS >> [Wed Nov 07 13:54:44 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: >> batch: sudorule_show(u'read_only_viewiers', all=True): SUCCESS >> [Wed Nov 07 13:54:44 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: >> batch: sudorule_show(u'developers', all=True): SUCCESS >> [Wed Nov 07 13:54:44 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: >> batch: sudorule_show(u'operation', all=True): SUCCESS >> [Wed Nov 07 13:54:44 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: >> batch(({u'params': [[u'Full_Access'], {u'all': True}], u'method': >> u'sudorule_show'}, {u'params': [[u'read_only_viewiers'], {u'all': >> True}], u'method': u'sudorule_show'}, {u'params': [[u'developers'], >> {u'all': True}], u'method': u'sudorule_show'}, {u'params': >> [[u'operation'], {u'all': True}], u'method': u'sudorule_show'})): >> SUCCESS >> [Wed Nov 07 13:54:50 2012] [error] ipa: INFO: admin at EXAMPLE.LOC: >> sudorule_show(u'read_only_viewiers', rights=True, all=True): SUCCESS >> >> >> I created the user as below and associated it with a group, which I >> then allowed to use less for reading file. As you can see below, it >> seem to does not work. >> >> Nov 7 16:05:42 demo2 sudo: pam_sss(sudo:auth): authentication >> success; logname=williamm uid=0 euid=0 tty=/dev/pts/2 ruser=williamm >> rhost= user=williamm >> Nov 7 16:05:43 demo2 sudo: williamm : user NOT in sudoers ; TTY=pts/2 >> ; PWD=/home/wmuriithi ; USER=root ; COMMAND=/usr/bin/less >> /var/log/secure >> >> >> - My question is, does the client install script take care of sudo >> configuration or is that done manually? I don't see any sudo related >> flag on the client installation script. >> >> - I have tried configuring sssd for sudo use and it didn't go well. >> Last time I messed around with LDAP managed sudo, I have to install a >> LDAP capable sudo package. The ipa-client install did not install >> this package. Does IPA sudo management work differently? >> >> - Where would I check for logs? I checked sssd logs and they are empty. >> >> - I am missing the basedn configuration on sssd configuration. From >> this bug, it should have been setup by installer, oddly though it was >> not setup and the bug is closed. I attempted to fix it by adding the >> line below but it make sudo completely unusable. It could not find >> any valid users apparently >> >> https://fedorahosted.org/freeipa/ticket/932 >> >> ldap_netgroup_search_base = cn=ng,cn=compat,dc=example,dc=loc >> >> Nov 7 16:05:42 demo2 sudo: pam_sss(sudo:auth): authentication >> success; logname=williamm uid=0 euid=0 tty=/dev/pts/2 ruser=williamm >> rhost= user=williamm >> Nov 7 16:05:43 demo2 sudo: williamm : user NOT in sudoers ; TTY=pts/2 >> ; PWD=/home/wmuriithi ; USER=root ; COMMAND=/usr/bin/less >> /var/log/secure >> >> >> Any pointers on why we are going? >> >> Thank you a lot in advance. >> >> William >> >> ---------------------------- >> [root at ipa1-yyz-int wmuriithi]# ipa sudocmd-add --desc='For reading log >> files' '/usr/bin/less' >> ---------------------------------- >> Added Sudo Command "/usr/bin/less" >> ---------------------------------- >> Sudo Command: /usr/bin/less >> Description: For reading log files >> [root at ipa1-yyz-int wmuriithi]# ipa sudocmdgroup-add --desc='Read Only >> Commands' readonly >> ----------------------------------- >> Added Sudo Command Group "readonly" >> ----------------------------------- >> Sudo Command Group: readonly >> Description: Read Only Commands >> [root at ipa1-yyz-int wmuriithi]# ipa sudocmdgroup-add-member >> --sudocmds='/usr/bin/less' readonly >> Sudo Command Group: readonly >> Description: Read Only Commands >> Member Sudo commands: /usr/bin/less >> ------------------------- >> Number of members added 1 >> ------------------------- >> [root at ipa1-yyz-int wmuriithi]# ipa sudorule-add testing_viewiers >> ----------------------------------- >> Added Sudo Rule "testing_viewiers" >> ----------------------------------- >> Rule name: testing_viewiers >> Enabled: TRUE >> [root at ipa1-yyz-int wmuriithi]# ipa sudorule-add-allow-command >> --sudocmdgroups=readonly testing_viewiers >> Rule name: testing_viewiers >> Enabled: TRUE >> Sudo Allow Command Groups: readonly >> ------------------------- >> Number of members added 1 >> ------------------------- >> [root at ipa1-yyz-int wmuriithi]# ipa hostgroup-add demo >> Description: Demonstration systems >>>>> Description: Leading and trailing spaces are not allowed >> Description: Demonstration system >> ---------------------- >> Added hostgroup "demo" >> ---------------------- >> Host-group: demo >> Description: Demonstration system >> [root at ipa1-yyz-int wmuriithi]# ipa hostgroup-add-member >> --hosts=demo2.yyz.int.testing.com demo >> Host-group: demo >> Description: Demonstration system >> Member hosts: demo2.yyz.int.testing.com >> ------------------------- >> Number of members added 1 >> ------------------------- >> [root at ipa1-yyz-int wmuriithi]# ipa sudorule-add-host --hostgroups=demo >> testing_viewiers >> Rule name: testing_viewiers >> Enabled: TRUE >> Host Groups: demo >> Sudo Allow Command Groups: readonly >> ------------------------- >> Number of members added 1 >> ------------------------- >> [root at ipa1-yyz-int wmuriithi]# ipa sudorule-add-user >> --groups=operations testing_viewiers >> Rule name: testing_viewiers >> Enabled: TRUE >> User Groups: operations >> Host Groups: demo >> Sudo Allow Command Groups: readonly >> ------------------------- >> Number of members added 1 >> ------------------------- >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > The SODO integration is evolving so it important to know what OS and > version you are on. > I would assume you are on RHEL6.3 or equivalent. > There are two main ways to integrate SUDO with IPA. One with SSSD > integration and another without. The one with the SSSD integration was a > tech preview in 6.3 and did not work well Hi, caching capabilities were not optimal in the tech preview, but it was fully functional (or at least should be, I don't think anyone really tried it in production), unless sssd is configured with multiple domains. so we will set is aside for > now (but we fixed it and it is coming in 6.4 as a supported feature). > > So the only reasonable option ATM is to setup sudo without SSSD integration. > > So this solution implies that SUDO will use LDAP to get data from the > LDAP server and LDAP server happens to be IPA in this case. > You need to configure SUDO with LDAP as one would do following the > instructions provided by SUDO package. > Please search archives of the last month. There have been couple threads > that you can find helpful in your quest. > > Kee in mind that the location and name of the file used by sudo to > configure LDAP connection has changed. The exact names of the files and > recommendations you will find in the mentioned threads. > > Once you configured SUDO and if you still have problems please let us > know and we will help to troubleshoot the issue. > From rcritten at redhat.com Fri Nov 9 16:43:53 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 09 Nov 2012 11:43:53 -0500 Subject: [Freeipa-users] Announcing FreeIPA v3.0.1 Release Message-ID: <509D32C9.3070305@redhat.com> The FreeIPA team is proud to announce version FreeIPA v3.0.1. It can be downloaded from http://www.freeipa.org/page/Downloads. A build will be submitted to updates-testing for Fedora 18 soon. == Highlights in 3.0.1 == * Change the way we calculate what services IPA is managing so that startup/shutdown with systemd works. * Resolve external members from trusted domain via Global Catalog. * Improvements to ipa-client-automount. * Man page and command help improvements. * Added option to configure DNS forwarding by zone. == 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 the referential integrity extension requires an extended set of indexes to be configured. RPM update for an IPA server with a excessive number of hosts, SUDO or HBAC entries 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 2.2.0 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-devel mailing list: http://www.redhat.com/mailman/listinfo/freeipa-devel == Detailed Changelog since 3.0.0 == Alexander Bokovoy (4): * Remove bogus check for smbpasswd * Warn about DNA plugin configuration when working with local ID ranges * Resolve external members from trusted domain via Global Catalog * Clarify trust-add help regarding multiple runs against the same domain Jakub Hrozek (1): * ipa-client-automount: Add the autofs service if it doesn't exist yet Jan Cholasta (1): * Reword description of the --passsync option of ipa-replica-manage. John Dennis (1): * log dogtag errors Martin Kosek (9): * Create reverse zone in unattended mode * Add fallback for httpd restarts on sysV platforms * Report ipa-upgradeconfig errors during RPM upgrade * Avoid uninstalling dependencies during package lifetime * Remove servertrls and clientctrls options from rename_s * Use common encoding in modlist generation * Process relative nameserver DNS record correctly * Do not require resolvable nameserver in DNS install * Disable global forwarding per-zone Nikolai Kondrashov (1): * Add uninstall command hints to ipa-*-install Petr Viktorin (3): * ipautil.run: Log the command line before running the command * ipa-replica-install: Use configured IPA DNS servers in forward/reverse resolution check * Make sure the CA is running when starting services Petr Vobornik (2): * Simpler instructions to generate certificate * Fixed incorrect link to browser config after session expiration Rob Crittenden (11): * Use TLS for CA replication * Don't configure a reverse zone if not desired in interactive installer. * Fix requesting certificates that contain subject altnames. * Improve error messages in ipa-replica-manage. * Close connection after each request, avoid NSS shutdown problem. * The SECURE_NFS value needs to be lower-case yes on SysV systems. * After unininstall see if certmonger is still tracking any of our certs. * Wait for the directory server to come up when updating the agent certificate. * Set MLS/MCS for user_u context to what will be on remote systems. * Handle the case where there are no replicas with list-ruv * Become IPA 3.0.1 Simo Sorce (6): * Add support for using AES fo cross-realm TGTs * Preserve original service_name in services * Save service name on service startup * Get list of service from LDAP only at startup * Revert "Save service name on service startup" * Save service name on service startup/shutdown Sumit Bose (4): * Fix various issues found by Coverity * extdom: handle INP_POSIX_UID and INP_POSIX_GID requests * Restart httpd if ipa-server-trust-ad is installed or updated * ipa-adtrust-install: allow to reset te NetBIOS domain name Tomas Babej (4): * Forbid overlapping primary and secondary rid ranges * Refactoring of default.conf man page * Make service naming in ipa-server-install consistent * IPA Server check in ipa-replica-manage From amessina at messinet.com Sun Nov 11 22:37:46 2012 From: amessina at messinet.com (Anthony Messina) Date: Sun, 11 Nov 2012 16:37:46 -0600 Subject: [Freeipa-users] sssd/pam login issues after upgrade to 2.2.1 on Fedora 17 Message-ID: <3008204.GPn6mR990f@linux-ws1.messinet.com> After upgrading to freeipa-{client,server}-2.2.1-1.fc17.x86_64 today, my clients are no longer able to login via kdm or ssh (and perhaps others). The secure log shows the following: sshd[28922]: pam_sss(sshd:account): Access denied for user amessina: 4 (System error) Of note, I have always had the HBAC allow_all rule enabled--I've never done anything with HBAC since I began using IPA. The problem and resolution seems to be the same as https://www.redhat.com/archives/freeipa-users/2012-September/msg00016.html where if I uninstall IPA on the clients, then remove the host on the IPA server, then reinstall on the client, things work as expected. I have done this for all but one of the clients, and of course, the IPA server, which itself is a client. I have increased sssd debugging and find that when trying to login to the servers that have not been reinstalled as above, I get the following significant error in sssd_.log: (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [be_pam_handler] (0x0100): Got request with the following data (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] (0x0100): command: PAM_ACCT_MGMT (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] (0x0100): domain: messinet.com (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] (0x0100): user: amessina (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] (0x0100): service: sshd (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] (0x0100): tty: ssh (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] (0x0100): ruser: (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] (0x0100): rhost: 2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] (0x0100): authtok type: 0 (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] (0x0100): authtok size: 0 (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] (0x0100): newauthtok type: 0 (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] (0x0100): newauthtok size: 0 (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] (0x0100): priv: 1 (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] (0x0100): cli_pid: 9069 (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [sdap_access_send] (0x0400): Performing access check for user [amessina] (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [sdap_account_expired_rhds] (0x0400): Performing RHDS access check for user [amessina] (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectClass=ipaHost)(fqdn=ds.messinet.com))] [cn=accounts,dc=messinet,dc=com]. (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [serverHostName] (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [fqdn] (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipauniqueid] (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [member] (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberOf] (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 15 (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [sdap_process_result] (0x2000): Trace: sh[0x7f553cd5a500], connected[1], ops[0x7f553cd653a0], ldap[0x7f553cd56e20] (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [sdap_get_generic_ext_done] (0x1000): Total count [0] (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [be_pam_handler_callback] (0x0100): Backend returned: (3, 4, ) [Internal Error (System error)] I also find that when I do a manual ldapsearch for the non-upgraded clients as follows: ldapsearch -x -D "cn=directory manager" -W -b cn=accounts,dc=messinet,dc=com "(&(objectClass=ipaHost)(fqdn=*))" dn the non-upgraded clients DO NOT appear in the list, but if I do the following: ldapsearch -x -D "cn=directory manager" -W -b cn=accounts,dc=messinet,dc=com "(&(objectClass=ipaHost))" dn the non-upgraded clients DO appear in the list. Somehow the addition of the fqdn=* in the filter "(&(objectClass=ipaHost)(fqdn=*))" prevents them from being displayed. There were no errors on any of the servers or clients during the upgrade. Your help is appreciated. I've tried to get this corrected all day without success. Thanks in advance. -A -- Anthony - http://messinet.com - http://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: 198 bytes Desc: This is a digitally signed message part. URL: From jhrozek at redhat.com Mon Nov 12 14:32:33 2012 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 12 Nov 2012 15:32:33 +0100 Subject: [Freeipa-users] sssd/pam login issues after upgrade to 2.2.1 on Fedora 17 In-Reply-To: <3008204.GPn6mR990f@linux-ws1.messinet.com> References: <3008204.GPn6mR990f@linux-ws1.messinet.com> Message-ID: <20121112143233.GP4144@hendrix.brq.redhat.com> On Sun, Nov 11, 2012 at 04:37:46PM -0600, Anthony Messina wrote: > After upgrading to freeipa-{client,server}-2.2.1-1.fc17.x86_64 today, my > clients are no longer able to login via kdm or ssh (and perhaps others). The > secure log shows the following: > > sshd[28922]: pam_sss(sshd:account): Access denied for user amessina: 4 (System > error) > > Of note, I have always had the HBAC allow_all rule enabled--I've never done > anything with HBAC since I began using IPA. > > The problem and resolution seems to be the same as > https://www.redhat.com/archives/freeipa-users/2012-September/msg00016.html > > where if I uninstall IPA on the clients, then remove the host on the IPA > server, then reinstall on the client, things work as expected. > > I have done this for all but one of the clients, and of course, the IPA > server, which itself is a client. > > I have increased sssd debugging and find that when trying to login to the > servers that have not been reinstalled as above, I get the following > significant error in sssd_.log: > > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [be_pam_handler] (0x0100): > Got request with the following data > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] (0x0100): > command: PAM_ACCT_MGMT > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] (0x0100): > domain: messinet.com > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] (0x0100): > user: amessina > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] (0x0100): > service: sshd > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] (0x0100): > tty: ssh > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] (0x0100): > ruser: > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] (0x0100): > rhost: 2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] (0x0100): > authtok type: 0 > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] (0x0100): > authtok size: 0 > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] (0x0100): > newauthtok type: 0 > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] (0x0100): > newauthtok size: 0 > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] (0x0100): > priv: 1 > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] (0x0100): > cli_pid: 9069 > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [sdap_access_send] > (0x0400): Performing access check for user [amessina] > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] > [sdap_account_expired_rhds] (0x0400): Performing RHDS access check for user > [amessina] > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] > [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with > [(&(objectClass=ipaHost)(fqdn=ds.messinet.com))] > [cn=accounts,dc=messinet,dc=com]. > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [serverHostName] > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [fqdn] > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipauniqueid] > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [member] > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberOf] > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] > [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 15 > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [sdap_process_result] > (0x2000): Trace: sh[0x7f553cd5a500], connected[1], ops[0x7f553cd653a0], > ldap[0x7f553cd56e20] > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] > [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] > [sdap_get_generic_ext_done] (0x1000): Total count [0] > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [be_pam_handler_callback] > (0x0100): Backend returned: (3, 4, ) [Internal Error (System error)] > > I also find that when I do a manual ldapsearch for the non-upgraded clients as > follows: > > ldapsearch -x -D "cn=directory manager" -W -b cn=accounts,dc=messinet,dc=com > "(&(objectClass=ipaHost)(fqdn=*))" dn > > the non-upgraded clients DO NOT appear in the list, but if I do the following: > > ldapsearch -x -D "cn=directory manager" -W -b cn=accounts,dc=messinet,dc=com > "(&(objectClass=ipaHost))" dn > > the non-upgraded clients DO appear in the list. Somehow the addition of the > fqdn=* in the filter "(&(objectClass=ipaHost)(fqdn=*))" prevents them from > being displayed. > > There were no errors on any of the servers or clients during the upgrade. > > Your help is appreciated. I've tried to get this corrected all day without > success. > > Thanks in advance. -A Hi, the SSSD depends on the fqdn attribute being present for the access control mechanism. Also, the SSSD searches the directory anonymously, so in order to get the same results, you should simply search the directory with anonymous bind. Can you check on the server how the host entries look like? For example: ipa host-show ds.messinet.com --all --raw Is the FQDN attribute present in the directory at all? From amessina at messinet.com Mon Nov 12 15:17:17 2012 From: amessina at messinet.com (Anthony Messina) Date: Mon, 12 Nov 2012 09:17:17 -0600 Subject: [Freeipa-users] sssd/pam login issues after upgrade to 2.2.1 on Fedora 17 In-Reply-To: <20121112143233.GP4144@hendrix.brq.redhat.com> References: <3008204.GPn6mR990f@linux-ws1.messinet.com> <20121112143233.GP4144@hendrix.brq.redhat.com> Message-ID: <6450656.BrEhMucQJ9@linux-ws1.messinet.com> On Monday, November 12, 2012 03:32:33 PM Jakub Hrozek wrote: > On Sun, Nov 11, 2012 at 04:37:46PM -0600, Anthony Messina wrote: > > After upgrading to freeipa-{client,server}-2.2.1-1.fc17.x86_64 today, my > > clients are no longer able to login via kdm or ssh (and perhaps > > others). The > > > secure log shows the following: > > > > > > sshd[28922]: pam_sss(sshd:account): Access denied for user amessina: 4 > > (System error) > > > > > > > > Of note, I have always had the HBAC allow_all rule enabled--I've never > > done anything with HBAC since I began using IPA. > > > > > > > > The problem and resolution seems to be the same as > > https://www.redhat.com/archives/freeipa-users/2012-September/msg00016.html > > > > > > > > where if I uninstall IPA on the clients, then remove the host on the IPA > > server, then reinstall on the client, things work as expected. > > > > > > > > I have done this for all but one of the clients, and of course, the IPA > > server, which itself is a client. > > > > > > > > I have increased sssd debugging and find that when trying to login to the > > servers that have not been reinstalled as above, I get the following > > > > significant error in sssd_.log: > > > > > > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [be_pam_handler] > > (0x0100): Got request with the following data > > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] > > (0x0100): command: PAM_ACCT_MGMT > > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] > > (0x0100): domain: messinet.com > > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] > > (0x0100): user: amessina > > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] > > (0x0100): service: sshd > > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] > > (0x0100): tty: ssh > > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] > > (0x0100): ruser: > > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] > > (0x0100): rhost: 2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e > > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] > > (0x0100): authtok type: 0 > > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] > > (0x0100): authtok size: 0 > > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] > > (0x0100): newauthtok type: 0 > > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] > > (0x0100): newauthtok size: 0 > > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] > > (0x0100): priv: 1 > > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] > > (0x0100): cli_pid: 9069 > > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [sdap_access_send] > > (0x0400): Performing access check for user [amessina] > > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] > > [sdap_account_expired_rhds] (0x0400): Performing RHDS access check for > > user [amessina] > > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] > > [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with > > [(&(objectClass=ipaHost)(fqdn=ds.messinet.com))] > > [cn=accounts,dc=messinet,dc=com]. > > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] > > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] > > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] > > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [serverHostName] > > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] > > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [fqdn] > > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] > > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipauniqueid] > > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] > > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [member] > > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] > > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberOf] > > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] > > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] > > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] > > [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 15 > > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [sdap_process_result] > > (0x2000): Trace: sh[0x7f553cd5a500], connected[1], ops[0x7f553cd653a0], > > ldap[0x7f553cd56e20] > > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] > > [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg > > set (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] > > [sdap_get_generic_ext_done] (0x1000): Total count [0] > > (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] > > [be_pam_handler_callback] (0x0100): Backend returned: (3, 4, ) > > [Internal Error (System error)]> > > > > > > I also find that when I do a manual ldapsearch for the non-upgraded > > clients as > > > follows: > > > > > > ldapsearch -x -D "cn=directory manager" -W -b > > cn=accounts,dc=messinet,dc=com "(&(objectClass=ipaHost)(fqdn=*))" dn > > > > > > > > the non-upgraded clients DO NOT appear in the list, but if I do the following: > > > > > > ldapsearch -x -D "cn=directory manager" -W -b > > cn=accounts,dc=messinet,dc=com "(&(objectClass=ipaHost))" dn > > > > > > > > the non-upgraded clients DO appear in the list. Somehow the addition of > > the fqdn=* in the filter "(&(objectClass=ipaHost)(fqdn=*))" prevents > > them from being displayed. > > > > > > > > There were no errors on any of the servers or clients during the upgrade. > > > > > > > > Your help is appreciated. I've tried to get this corrected all day > > without success. > > > > > > > > Thanks in advance. -A > > Hi, > > the SSSD depends on the fqdn attribute being present for the access > control mechanism. Also, the SSSD searches the directory anonymously, so > in order to get the same results, you should simply search the directory > with anonymous bind. Thank you for replying. I have disabled anonymous access and increased the minssf (all prior to the upgrade) and SSSD seemed to be alright: ~]# cat nsslapd-allow-anonymous-access.ldif dn: cn=config changetype: modify replace: nsslapd-allow-anonymous-access nsslapd-allow-anonymous-access: rootdse ~]# cat nsslapd-localssf.ldif dn: cn=config changetype: modify replace: nsslapd-localssf nsslapd-localssf: 71 ~]# cat nsslapd-minssf-exclude-rootdse.ldif dn: cn=config changetype: modify replace: nsslapd-minssf-exclude-rootdse nsslapd-minssf-exclude-rootdse: on ~]# cat nsslapd-minssf.ldif dn: cn=config changetype: modify replace: nsslapd-minssf nsslapd-minssf: 56 ~]# cat /etc/sssd/sssd.conf [domain/messinet.com] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = messinet.com id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = ds.messinet.com chpass_provider = ipa ipa_server = ds.messinet.com ldap_tls_cacert = /etc/ipa/ca.crt sudo_provider = ldap ldap_sasl_mech = GSSAPI ldap_sudo_search_base = ou=SUDOers,dc=messinet,dc=com debug_level = 8 [sssd] services = nss, pam, ssh, sudo config_file_version = 2 domains = messinet.com [nss] [pam] [sudo] [autofs] [ssh] > Can you check on the server how the host entries look like? > > For example: > ipa host-show ds.messinet.com --all --raw > > Is the FQDN attribute present in the directory at all? Yes it is present. The entry seems to appear similar to other entries. I'm wondering if for some reason it wasn't indexed (I don't know much about indexing), but only the hosts that are re-enrolled after the update are displayed with the above search. I'm thinking this may be related to http://git.fedorahosted.org/cgit/freeipa.git/commit/?h=ipa-2-2&id=ce11a7c0e22ee8f70e14c43419f20be70176fe8c Is there a way to re-index the fqdn attribute? ~]# ipa host-show ds.messinet.com --all --raw dn: fqdn=ds.messinet.com,cn=computers,cn=accounts,dc=messinet,dc=com fqdn: ds.messinet.com krbprincipalname: host/ds.messinet.com at MESSINET.COM ipasshpubkey: .... ipasshpubkey: .... sshpubkeyfp: .... sshpubkeyfp: .... has_password: False managedby: fqdn=ds.messinet.com,cn=computers,cn=accounts,dc=messinet,dc=com has_keytab: True cn: ds.messinet.com ipauniqueid: fea4af02-ab17-11e1-bb55-d4ae52b94185 krbextradata: .... krblastpwdchange: 20120531115854Z krblastsuccessfulauth: 20121112145732Z managing: fqdn=ds.messinet.com,cn=computers,cn=accounts,dc=messinet,dc=com objectclass: top objectclass: ipaobject objectclass: nshost objectclass: ipahost objectclass: ipaservice objectclass: pkiuser objectclass: krbprincipalaux objectclass: krbprincipal objectclass: krbticketpolicyaux objectclass: ipasshhost objectclass: ipaSshGroupOfPubKeys serverhostname: ds On another but perhaps related note, client changes to ssh_config and sshd_config aren't made unless the host is removed from IPA, then re-enrolled. http://git.fedorahosted.org/cgit/freeipa.git/commit/?h=ipa-2-2&id=0b33b9fb3791545ab952b46c7443482a52fe6a6c ~]# rpm -q --scripts freeipa-client yields nothing. Again, thanks for helping. -A -- Anthony - http://messinet.com - http://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: 198 bytes Desc: This is a digitally signed message part. URL: From amessina at messinet.com Mon Nov 12 15:51:14 2012 From: amessina at messinet.com (Anthony Messina) Date: Mon, 12 Nov 2012 09:51:14 -0600 Subject: [Freeipa-users] sssd/pam login issues after upgrade to 2.2.1 on Fedora 17 In-Reply-To: <6450656.BrEhMucQJ9@linux-ws1.messinet.com> References: <3008204.GPn6mR990f@linux-ws1.messinet.com> <20121112143233.GP4144@hendrix.brq.redhat.com> <6450656.BrEhMucQJ9@linux-ws1.messinet.com> Message-ID: <2605490.sxqcQKAmra@linux-ws1.messinet.com> On Monday, November 12, 2012 09:17:17 AM Anthony Messina wrote: > > > I also find that when I do a manual ldapsearch for the non-upgraded > > > clients as > > > > > > > follows: > > > > > > > > > ldapsearch -x -D "cn=directory manager" -W -b > > > cn=accounts,dc=messinet,dc=com "(&(objectClass=ipaHost)(fqdn=*))" dn > > > > > > > > > > > > the non-upgraded clients DO NOT appear in the list, but if I do the > > following: > > > > > > > > > ldapsearch -x -D "cn=directory manager" -W -b > > > cn=accounts,dc=messinet,dc=com "(&(objectClass=ipaHost))" dn > > > > > > > > > > > > the non-upgraded clients DO appear in the list. Somehow the addition of > > > the fqdn=* in the filter "(&(objectClass=ipaHost)(fqdn=*))" prevents > > > them from being displayed. > > > > > > > > > > > > There were no errors on any of the servers or clients during the > > > upgrade. > > > > > > > > > > > > Your help is appreciated. I've tried to get this corrected all day > > > without success. > > > > > > > > > > > > Thanks in advance. -A > > > > > > > > Hi, > > > > > > > > the SSSD depends on the fqdn attribute being present for the access > > control mechanism. Also, the SSSD searches the directory anonymously, so > > in order to get the same results, you should simply search the directory > > with anonymous bind. > > Can you check on the server how the host entries look like? > > > > > > > > For example: > > ipa host-show ds.messinet.com --all --raw > > > > > > > > Is the FQDN attribute present in the directory at all? > > Yes it is present. The entry seems to appear similar to other > entries. I'm wondering if for some reason it wasn't indexed (I don't know > much about indexing), but only the hosts that are re-enrolled after the > update are displayed with the above search. I'm thinking this may be > related to > http://git.fedorahosted.org/cgit/freeipa.git/commit/?h=ipa-2-2&id=ce11a7c0e > 22ee8f70e14c43419f20be70176fe8c > > Is there a way to re-index the fqdn attribute? While this may be a red herring, I also do not find in my ipaupgrade.log any attempt to re-index the fqdn attribute. These are the only entries for which tasks are created. 2012-11-11T13:25:39Z INFO Creating task to index attribute: memberuid 2012-11-11T13:25:45Z INFO Creating task to index attribute: memberOf 2012-11-11T13:25:51Z INFO Creating task to index attribute: memberHost 2012-11-11T13:25:57Z INFO Creating task to index attribute: memberUser 2012-11-11T13:26:03Z INFO Creating task to index attribute: ntUniqueId 2012-11-11T13:26:09Z INFO Creating task to index attribute: ntUserDomainId -- Anthony - http://messinet.com - http://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: 198 bytes Desc: This is a digitally signed message part. URL: From rmeggins at redhat.com Mon Nov 12 16:28:22 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 12 Nov 2012 09:28:22 -0700 Subject: [Freeipa-users] sssd/pam login issues after upgrade to 2.2.1 on Fedora 17 In-Reply-To: <1352737649.10327.473.camel@willson.li.ssimo.org> References: <3008204.GPn6mR990f@linux-ws1.messinet.com> <20121112143233.GP4144@hendrix.brq.redhat.com> <6450656.BrEhMucQJ9@linux-ws1.messinet.com> <2605490.sxqcQKAmra@linux-ws1.messinet.com> <1352737649.10327.473.camel@willson.li.ssimo.org> Message-ID: <50A123A6.8030504@redhat.com> On 11/12/2012 09:27 AM, Simo Sorce wrote: > On Mon, 2012-11-12 at 09:51 -0600, Anthony Messina wrote: >> On Monday, November 12, 2012 09:17:17 AM Anthony Messina wrote: >>>>> I also find that when I do a manual ldapsearch for the non-upgraded >>>>> clients as> >>>>> >>>>> follows: >>>>> >>>>> >>>>> ldapsearch -x -D "cn=directory manager" -W -b >>>>> cn=accounts,dc=messinet,dc=com "(&(objectClass=ipaHost)(fqdn=*))" dn >>>>> >>>>> >>>>> >>>>> the non-upgraded clients DO NOT appear in the list, but if I do the >>> following: >>>>> >>>>> ldapsearch -x -D "cn=directory manager" -W -b >>>>> cn=accounts,dc=messinet,dc=com "(&(objectClass=ipaHost))" dn >>>>> >>>>> >>>>> >>>>> the non-upgraded clients DO appear in the list. Somehow the addition of >>>>> the fqdn=* in the filter "(&(objectClass=ipaHost)(fqdn=*))" prevents >>>>> them from being displayed. >>>>> >>>>> >>>>> >>>>> There were no errors on any of the servers or clients during the >>>>> upgrade. >>>>> >>>>> >>>>> >>>>> Your help is appreciated. I've tried to get this corrected all day >>>>> without success. >>>>> >>>>> >>>>> >>>>> Thanks in advance. -A >>>> >>>> >>>> Hi, >>>> >>>> >>>> >>>> the SSSD depends on the fqdn attribute being present for the access >>>> control mechanism. Also, the SSSD searches the directory anonymously, so >>>> in order to get the same results, you should simply search the directory >>>> with anonymous bind. >>>> Can you check on the server how the host entries look like? >>>> >>>> >>>> >>>> For example: >>>> ipa host-show ds.messinet.com --all --raw >>>> >>>> >>>> >>>> Is the FQDN attribute present in the directory at all? >>> Yes it is present. The entry seems to appear similar to other >>> entries. I'm wondering if for some reason it wasn't indexed (I don't know >>> much about indexing), but only the hosts that are re-enrolled after the >>> update are displayed with the above search. I'm thinking this may be >>> related to >>> http://git.fedorahosted.org/cgit/freeipa.git/commit/?h=ipa-2-2&id=ce11a7c0e >>> 22ee8f70e14c43419f20be70176fe8c >>> >>> Is there a way to re-index the fqdn attribute? >> While this may be a red herring, I also do not find in my ipaupgrade.log any >> attempt to re-index the fqdn attribute. These are the only entries for which >> tasks are created. >> >> 2012-11-11T13:25:39Z INFO Creating task to index attribute: memberuid >> 2012-11-11T13:25:45Z INFO Creating task to index attribute: memberOf >> 2012-11-11T13:25:51Z INFO Creating task to index attribute: memberHost >> 2012-11-11T13:25:57Z INFO Creating task to index attribute: memberUser >> 2012-11-11T13:26:03Z INFO Creating task to index attribute: ntUniqueId >> 2012-11-11T13:26:09Z INFO Creating task to index attribute: ntUserDomainId > Seem like it may be the issue. > Can you open a ticket on this ? > > Rich, > do you have a quick pointer for recreating the fqdn index ? Creating the config https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Indexes-Creating_Indexes.html Creating the actual index db files https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/applying-indexes.html > > Simo. > From simo at redhat.com Mon Nov 12 16:27:29 2012 From: simo at redhat.com (Simo Sorce) Date: Mon, 12 Nov 2012 11:27:29 -0500 Subject: [Freeipa-users] sssd/pam login issues after upgrade to 2.2.1 on Fedora 17 In-Reply-To: <2605490.sxqcQKAmra@linux-ws1.messinet.com> References: <3008204.GPn6mR990f@linux-ws1.messinet.com> <20121112143233.GP4144@hendrix.brq.redhat.com> <6450656.BrEhMucQJ9@linux-ws1.messinet.com> <2605490.sxqcQKAmra@linux-ws1.messinet.com> Message-ID: <1352737649.10327.473.camel@willson.li.ssimo.org> On Mon, 2012-11-12 at 09:51 -0600, Anthony Messina wrote: > On Monday, November 12, 2012 09:17:17 AM Anthony Messina wrote: > > > > I also find that when I do a manual ldapsearch for the non-upgraded > > > > clients as > > > > > > > > > follows: > > > > > > > > > > > > ldapsearch -x -D "cn=directory manager" -W -b > > > > cn=accounts,dc=messinet,dc=com "(&(objectClass=ipaHost)(fqdn=*))" dn > > > > > > > > > > > > > > > > the non-upgraded clients DO NOT appear in the list, but if I do the > > > > following: > > > > > > > > > > > > ldapsearch -x -D "cn=directory manager" -W -b > > > > cn=accounts,dc=messinet,dc=com "(&(objectClass=ipaHost))" dn > > > > > > > > > > > > > > > > the non-upgraded clients DO appear in the list. Somehow the addition of > > > > the fqdn=* in the filter "(&(objectClass=ipaHost)(fqdn=*))" prevents > > > > them from being displayed. > > > > > > > > > > > > > > > > There were no errors on any of the servers or clients during the > > > > upgrade. > > > > > > > > > > > > > > > > Your help is appreciated. I've tried to get this corrected all day > > > > without success. > > > > > > > > > > > > > > > > Thanks in advance. -A > > > > > > > > > > > > Hi, > > > > > > > > > > > > the SSSD depends on the fqdn attribute being present for the access > > > control mechanism. Also, the SSSD searches the directory anonymously, so > > > in order to get the same results, you should simply search the directory > > > with anonymous bind. > > > Can you check on the server how the host entries look like? > > > > > > > > > > > > For example: > > > ipa host-show ds.messinet.com --all --raw > > > > > > > > > > > > Is the FQDN attribute present in the directory at all? > > > > Yes it is present. The entry seems to appear similar to other > > entries. I'm wondering if for some reason it wasn't indexed (I don't know > > much about indexing), but only the hosts that are re-enrolled after the > > update are displayed with the above search. I'm thinking this may be > > related to > > http://git.fedorahosted.org/cgit/freeipa.git/commit/?h=ipa-2-2&id=ce11a7c0e > > 22ee8f70e14c43419f20be70176fe8c > > > > Is there a way to re-index the fqdn attribute? > > While this may be a red herring, I also do not find in my ipaupgrade.log any > attempt to re-index the fqdn attribute. These are the only entries for which > tasks are created. > > 2012-11-11T13:25:39Z INFO Creating task to index attribute: memberuid > 2012-11-11T13:25:45Z INFO Creating task to index attribute: memberOf > 2012-11-11T13:25:51Z INFO Creating task to index attribute: memberHost > 2012-11-11T13:25:57Z INFO Creating task to index attribute: memberUser > 2012-11-11T13:26:03Z INFO Creating task to index attribute: ntUniqueId > 2012-11-11T13:26:09Z INFO Creating task to index attribute: ntUserDomainId Seem like it may be the issue. Can you open a ticket on this ? Rich, do you have a quick pointer for recreating the fqdn index ? Simo. -- Simo Sorce * Red Hat, Inc * New York From amessina at messinet.com Mon Nov 12 16:44:23 2012 From: amessina at messinet.com (Anthony Messina) Date: Mon, 12 Nov 2012 10:44:23 -0600 Subject: [Freeipa-users] sssd/pam login issues after upgrade to 2.2.1 on Fedora 17 In-Reply-To: <2605490.sxqcQKAmra@linux-ws1.messinet.com> References: <3008204.GPn6mR990f@linux-ws1.messinet.com> <6450656.BrEhMucQJ9@linux-ws1.messinet.com> <2605490.sxqcQKAmra@linux-ws1.messinet.com> Message-ID: <1702108.6dHCFZAZ6h@linux-ws1.messinet.com> On Monday, November 12, 2012 09:51:14 AM Anthony Messina wrote: > On Monday, November 12, 2012 09:17:17 AM Anthony Messina wrote: > > > > I also find that when I do a manual ldapsearch for the non-upgraded > > > > clients as > > > > > > > > > follows: > > > > > > > > > > > > ldapsearch -x -D "cn=directory manager" -W -b > > > > cn=accounts,dc=messinet,dc=com "(&(objectClass=ipaHost)(fqdn=*))" dn > > > > > > > > > > > > > > > > the non-upgraded clients DO NOT appear in the list, but if I do the > > > > > > > > following: > > > > > > > > > > > > ldapsearch -x -D "cn=directory manager" -W -b > > > > cn=accounts,dc=messinet,dc=com "(&(objectClass=ipaHost))" dn > > > > > > > > > > > > > > > > the non-upgraded clients DO appear in the list. Somehow the addition > > > > of > > > > the fqdn=* in the filter "(&(objectClass=ipaHost)(fqdn=*))" prevents > > > > them from being displayed. > > > > > > > > > > > > > > > > There were no errors on any of the servers or clients during the > > > > upgrade. > > > > > > > > > > > > > > > > Your help is appreciated. I've tried to get this corrected all day > > > > without success. > > > > > > > > > > > > > > > > Thanks in advance. -A > > > > > > > > > > > > Hi, > > > > > > > > > > > > the SSSD depends on the fqdn attribute being present for the access > > > control mechanism. Also, the SSSD searches the directory anonymously, so > > > in order to get the same results, you should simply search the directory > > > with anonymous bind. > > > Can you check on the server how the host entries look like? > > > > > > > > > > > > For example: > > > ipa host-show ds.messinet.com --all --raw > > > > > > > > > > > > Is the FQDN attribute present in the directory at all? > > > > > > > > Yes it is present. The entry seems to appear similar to other > > entries. I'm wondering if for some reason it wasn't indexed (I don't > > know > > much about indexing), but only the hosts that are re-enrolled after the > > update are displayed with the above search. I'm thinking this may be > > related to > > http://git.fedorahosted.org/cgit/freeipa.git/commit/?h=ipa-2-2&id=ce11a7c0 > > e > > 22ee8f70e14c43419f20be70176fe8c > > > > > > > > Is there a way to re-index the fqdn attribute? > > While this may be a red herring, I also do not find in my ipaupgrade.log > any attempt to re-index the fqdn attribute. These are the only entries > for which tasks are created. > > 2012-11-11T13:25:39Z INFO Creating task to index attribute: memberuid > 2012-11-11T13:25:45Z INFO Creating task to index attribute: memberOf > 2012-11-11T13:25:51Z INFO Creating task to index attribute: memberHost > 2012-11-11T13:25:57Z INFO Creating task to index attribute: memberUser > 2012-11-11T13:26:03Z INFO Creating task to index attribute: ntUniqueId > 2012-11-11T13:26:09Z INFO Creating task to index attribute: ntUserDomainId This in fact was the issue for SSSD: while indexes were added to 389 for the fqdn attribute, there was no index task created, so previous entries were not indexed, as new hosts were. Running the following "fixed" the issue and SSSD- based logins resumed immediately: ~]# cat fqdn_index_task.ldif dn: cn=indextask_fqdn, cn=index, cn=tasks, cn=config objectclass: top objectclass: extensibleObject cn: indextask_fqdn nsInstance: userRoot nsIndexAttribute: fqdn ~]# ldapadd -vvv -x -D "cn=directory manager" -W -f fqdn_index_task.ldif See https://fedorahosted.org/freeipa/ticket/3253 -- Anthony - http://messinet.com - http://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: 198 bytes Desc: This is a digitally signed message part. URL: From mkosek at redhat.com Tue Nov 13 13:01:33 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 13 Nov 2012 14:01:33 +0100 Subject: [Freeipa-users] sssd/pam login issues after upgrade to 2.2.1 on Fedora 17 In-Reply-To: <1702108.6dHCFZAZ6h@linux-ws1.messinet.com> References: <3008204.GPn6mR990f@linux-ws1.messinet.com> <6450656.BrEhMucQJ9@linux-ws1.messinet.com> <2605490.sxqcQKAmra@linux-ws1.messinet.com> <1702108.6dHCFZAZ6h@linux-ws1.messinet.com> Message-ID: <50A244AD.3060000@redhat.com> On 11/12/2012 05:44 PM, Anthony Messina wrote: > On Monday, November 12, 2012 09:51:14 AM Anthony Messina wrote: >> On Monday, November 12, 2012 09:17:17 AM Anthony Messina wrote: >>>>> I also find that when I do a manual ldapsearch for the >>>>> non-upgraded clients as > >>>>> >>>>> follows: >>>>> >>>>> >>>>> ldapsearch -x -D "cn=directory manager" -W -b >>>>> cn=accounts,dc=messinet,dc=com "(&(objectClass=ipaHost)(fqdn=*))" >>>>> dn >>>>> >>>>> >>>>> >>>>> the non-upgraded clients DO NOT appear in the list, but if I do >>>>> the >>> >>> >>> >>> following: >>>>> >>>>> >>>>> ldapsearch -x -D "cn=directory manager" -W -b >>>>> cn=accounts,dc=messinet,dc=com "(&(objectClass=ipaHost))" dn >>>>> >>>>> >>>>> >>>>> the non-upgraded clients DO appear in the list. Somehow the >>>>> addition of the fqdn=* in the filter >>>>> "(&(objectClass=ipaHost)(fqdn=*))" prevents them from being >>>>> displayed. >>>>> >>>>> >>>>> >>>>> There were no errors on any of the servers or clients during the >>>>> upgrade. >>>>> >>>>> >>>>> >>>>> Your help is appreciated. I've tried to get this corrected all >>>>> day without success. >>>>> >>>>> >>>>> >>>>> Thanks in advance. -A >>>> >>>> >>>> >>>> Hi, >>>> >>>> >>>> >>>> the SSSD depends on the fqdn attribute being present for the access >>>> control mechanism. Also, the SSSD searches the directory >>>> anonymously, so in order to get the same results, you should simply >>>> search the directory with anonymous bind. Can you check on the >>>> server how the host entries look like? >>>> >>>> >>>> >>>> For example: ipa host-show ds.messinet.com --all --raw >>>> >>>> >>>> >>>> Is the FQDN attribute present in the directory at all? >>> >>> >>> >>> Yes it is present. The entry seems to appear similar to other >>> entries. I'm wondering if for some reason it wasn't indexed (I >>> don't know much about indexing), but only the hosts that are >>> re-enrolled after the update are displayed with the above search. I'm >>> thinking this may be related to >>> http://git.fedorahosted.org/cgit/freeipa.git/commit/?h=ipa-2-2&id=ce11a7c0 >>> >>> e >>> 22ee8f70e14c43419f20be70176fe8c >>> >>> >>> >>> Is there a way to re-index the fqdn attribute? >> >> While this may be a red herring, I also do not find in my >> ipaupgrade.log any attempt to re-index the fqdn attribute. These are >> the only entries for which tasks are created. >> >> 2012-11-11T13:25:39Z INFO Creating task to index attribute: memberuid >> 2012-11-11T13:25:45Z INFO Creating task to index attribute: memberOf >> 2012-11-11T13:25:51Z INFO Creating task to index attribute: memberHost >> 2012-11-11T13:25:57Z INFO Creating task to index attribute: memberUser >> 2012-11-11T13:26:03Z INFO Creating task to index attribute: ntUniqueId >> 2012-11-11T13:26:09Z INFO Creating task to index attribute: >> ntUserDomainId > > This in fact was the issue for SSSD: while indexes were added to 389 for > the fqdn attribute, there was no index task created, so previous entries > were not indexed, as new hosts were. Running the following "fixed" the > issue and SSSD- based logins resumed immediately: > > > ~]# cat fqdn_index_task.ldif dn: cn=indextask_fqdn, cn=index, cn=tasks, > cn=config objectclass: top objectclass: extensibleObject cn: > indextask_fqdn nsInstance: userRoot nsIndexAttribute: fqdn > > ~]# ldapadd -vvv -x -D "cn=directory manager" -W -f fqdn_index_task.ldif > > See https://fedorahosted.org/freeipa/ticket/3253 > Thanks Anthony for this bug report! I added some info to the Trac ticket, but I will rather repeat here: This is indeed a bug in a code processing index updates. Index task is supposed to be created automatically for every new or updated index (i.e. the referred patch is OK), but it is unfortunately only processed in the update code path. To workaround the issue, one can either fire the index task manually as you did or simply run the FreeIPA LDAP upgrade procedure manually after freeipa-server package update. This will fire an index task too: # ipa-ldap-updater --upgrade # grep "Creating task to index" /var/log/ipaupgrade.log 2012-11-13T12:17:23Z INFO Creating task to index attribute: memberuid 2012-11-13T12:17:29Z INFO Creating task to index attribute: memberOf 2012-11-13T12:17:35Z INFO Creating task to index attribute: memberHost 2012-11-13T12:17:41Z INFO Creating task to index attribute: memberUser 2012-11-13T12:17:47Z INFO Creating task to index attribute: fqdn <<<< 2012-11-13T12:17:53Z INFO Creating task to index attribute: ntUniqueId 2012-11-13T12:17:59Z INFO Creating task to index attribute: ntUserDomainId After this command is run, the issue will be fixed. Martin From george_he7 at yahoo.com Tue Nov 13 22:10:44 2012 From: george_he7 at yahoo.com (george he) Date: Tue, 13 Nov 2012 14:10:44 -0800 (PST) Subject: [Freeipa-users] ipa and cronjob Message-ID: <1352844644.45947.YahooMailNeo@web163102.mail.bf1.yahoo.com> Hi all, I have a cronjob run daily by an ipa user, which accesses nfs mounted data on the nfs server (another machine in the realm). The problem is when the user was away for a few days, his credential expired and the cronjob did not run until he came back and logged on to the system again. Then all halted cronjob from the past days started to run, which is not desired because all of them were doing the same thing. My question is: Can we keep the cronjob running when the user's credential is expired? If we cannot, then can we skip or kill all of the old cronjobs but not the most recent one? Thanks, George -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Nov 14 00:04:11 2012 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 13 Nov 2012 19:04:11 -0500 Subject: [Freeipa-users] ipa and cronjob In-Reply-To: <1352844644.45947.YahooMailNeo@web163102.mail.bf1.yahoo.com> References: <1352844644.45947.YahooMailNeo@web163102.mail.bf1.yahoo.com> Message-ID: <50A2DFFB.90008@redhat.com> On 11/13/2012 05:10 PM, george he wrote: > Hi all, > I have a cronjob run daily by an ipa user, which accesses nfs mounted > data on the nfs server (another machine in the realm). > The problem is when the user was away for a few days, his credential > expired and the cronjob did not run until he came back and logged on > to the system again. Then all halted cronjob from the past days > started to run, which is not desired because all of them were doing > the same thing. > My question is: Can we keep the cronjob running when the user's > credential is expired? If we cannot, then can we skip or kill all of > the old cronjobs but not the most recent one? > Thanks, > George > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users Which cron jobs to keep and which ones to kill is really something you have to decide for yourself and script in your environment. There are several ways to overcome the issue though. Does the job really have to run as user? If so you might want to consider allowing SSSD to automatically renew the ticket on user behalf. See sssd-krb5 man page for details about the renewable tickets. Once the original authentication is conducted there is a period of the validity of the ticket but there is also a much longer period (by default a week or so) when the ticket can be renewed on behalf of the user. If the usual absence of users is less than say 10 days you can set a policy in IPA to allow renewable tickets for 10 days from the original authentication. Then the cron jobs would be able to run for at least 10 day until the tickets completely expire and can't be renewed. Keep in mind that by allowing the ticket to be longer lived you reduce the security of your environment as you increase the time the potential attacker can use to crack the ticket. However this kind of attack is unlikely but worth mentioning. If the job can be run under different identity then you have several options. You can create an account for the cron jobs to run and assign a keytab to it and provision it. Then the cron job can use this account and keytab to acquire tickets. One would have to periodically do kinit with this keytab as another cron job or use k5start which is not supported in RHEL but available upstream. Keep in mind that in future GSS proxy daemon would be able to automatically renew the tickets for such accounts on as needed basis. This functionality is planned for Fedora 19 and is waiting for MIT 1.11 to land in Fedora later this year or early next year. HTH -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From amessina at messinet.com Wed Nov 14 03:53:19 2012 From: amessina at messinet.com (Anthony Messina) Date: Tue, 13 Nov 2012 21:53:19 -0600 Subject: [Freeipa-users] ipa and cronjob In-Reply-To: <1352844644.45947.YahooMailNeo@web163102.mail.bf1.yahoo.com> References: <1352844644.45947.YahooMailNeo@web163102.mail.bf1.yahoo.com> Message-ID: <1496311.9buQiMQakS@linux-ws1.messinet.com> On Tuesday, November 13, 2012 02:10:44 PM george he wrote: > I have a cronjob run daily by an ipa user, which accesses nfs mounted data > on the nfs server (another machine in the realm). The problem is when the > user was away for a few days, his credential expired and the cronjob did > not run until he came back and logged on to the system again. Then all > halted cronjob from the past days started to run, which is not desired > because all of them were doing the same thing. My question is: Can we keep > the cronjob running when the user's credential is expired? If we cannot, > then can we skip or kill all of the old cronjobs but not the most recent > one? This may not be exactly what you're looking for, but it might get you started. I have a Kerberized NFSv4 setup with F17 machines here, two of which are used only as MythTV frontend/backend machines. For each of these, I wanted NFSv4/Kerberos mounted home directories with autologin AND the ability for the frontend/backend machines to potentially stay on for more than 24 hours so I do the following: 1. Using automatic login with the lightdm display manager, I have it run the following script to remove any old Kerberos ccaches, then obtain a new ticket on behalf of the user, and set the appropriate permissions and SELinux context. Note that in this case, I echo the password to kinit -- If I exported a keytab, I would not be able to manually login with a known password if there were a problem. #!/bin/bash # USERNAME="user1" USERID="$(/usr/bin/id -u $USERNAME)" PASSWORD="super_secret_password" export KRB5CCNAME="FILE:/tmp/krb5cc_${USERID}" /usr/bin/kdestroy -A -c ${KRB5CCNAME} /usr/bin/echo "${PASSWORD}" | /usr/bin/kinit -r 604800s \ -c ${KRB5CCNAME##*:} ${USERNAME} /bin/chown ${USERNAME}:${USERNAME} ${KRB5CCNAME##*:} /usr/bin/chcon -t user_tmp_t ${KRB5CCNAME##*:} 2. I run the following user-specific cron job (/var/spool/cron/user1) # For MythTV frontend hosts requiring access to NFSv4 filesystems exported # with Kerberos v5, renew the Kerberos v5 ticket for the MythTV frontend user. MAILTO=root 15 */4 * * * /usr/bin/kinit -R I'm guessing that if your user is an actual user, you may be able to do something similar by ensuring that a renewable ticket was requested in the first place, then issuing the cron task every so often. I tried using the auto-renewal option of SSSD, but that didn't seem to work for me. I didn't investigate why not, but I'm guessing it has something to do with how a "user" logs in in the first place. My MythTV backend user, for example, never actually logs in, but still needs Kerberos credentials to access NFSv4 filesystems. Now this will probably all change a bit in F18 with the switch to Kerberos DIR ccaches placed under the /run/user/$UID portion of the filesystem, which is not retained across reboots: http://fedoraproject.org/wiki/Features/KRB5DirCache http://fedoraproject.org/wiki/Features/KRB5CacheMove I hope this helps in some small way. Also, if others have better ideas, I'd love to hear them too! -A -- Anthony - http://messinet.com - http://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: 198 bytes Desc: This is a digitally signed message part. URL: From simo at redhat.com Wed Nov 14 05:00:29 2012 From: simo at redhat.com (Simo Sorce) Date: Wed, 14 Nov 2012 05:00:29 +0000 Subject: [Freeipa-users] ipa and cronjob In-Reply-To: <1496311.9buQiMQakS@linux-ws1.messinet.com> References: <1352844644.45947.YahooMailNeo@web163102.mail.bf1.yahoo.com> <1496311.9buQiMQakS@linux-ws1.messinet.com> Message-ID: <1352869229.10327.642.camel@willson.li.ssimo.org> On Tue, 2012-11-13 at 21:53 -0600, Anthony Messina wrote: > 1. Using automatic login with the lightdm display manager, I have it > run the > following script to remove any old Kerberos ccaches, then obtain a new > ticket > on behalf of the user, and set the appropriate permissions and > SELinux > context. Note that in this case, I echo the password to kinit -- If > I > exported a keytab, I would not be able to manually login with a known > password > if there were a problem. Just FYI, this is not strictly true, look at the -P, --password option of ipa-getkeytab :-) Simo. -- Simo Sorce * Red Hat, Inc * New York From amessina at messinet.com Wed Nov 14 06:22:29 2012 From: amessina at messinet.com (Anthony Messina) Date: Wed, 14 Nov 2012 00:22:29 -0600 Subject: [Freeipa-users] ipa and cronjob In-Reply-To: <1352869229.10327.642.camel@willson.li.ssimo.org> References: <1352844644.45947.YahooMailNeo@web163102.mail.bf1.yahoo.com> <1496311.9buQiMQakS@linux-ws1.messinet.com> <1352869229.10327.642.camel@willson.li.ssimo.org> Message-ID: <25082895.l9WEP28WKN@linux-ws1.messinet.com> On Wednesday, November 14, 2012 05:00:29 AM Simo Sorce wrote: > On Tue, 2012-11-13 at 21:53 -0600, Anthony Messina wrote: > > 1. Using automatic login with the lightdm display manager, I have it > > run the > > following script to remove any old Kerberos ccaches, then obtain a new > > ticket > > on behalf of the user, and set the appropriate permissions and > > SELinux > > context. Note that in this case, I echo the password to kinit -- If > > I > > exported a keytab, I would not be able to manually login with a known > > password > > if there were a problem. > > Just FYI, this is not strictly true, look at the -P, --password option > of ipa-getkeytab Thanks. I didn't notice that option since I'd been using this method since before I started using IPA. Is the password used to genterate a principle still usable after a keytab has been exported? I seem to remember from my pre-IPA days of using a plain old standalone MIT KDC that I couldn't use the password to authenticate after they keytab had been exported using kadmin. Again, I never really investigated it, but the password never seemed to work after the keytab was exported. -A -- Anthony - http://messinet.com - http://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: 198 bytes Desc: This is a digitally signed message part. URL: From mkosek at redhat.com Wed Nov 14 08:06:20 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 14 Nov 2012 09:06:20 +0100 Subject: [Freeipa-users] sssd/pam login issues after upgrade to 2.2.1 on Fedora 17 In-Reply-To: <50A244AD.3060000@redhat.com> References: <3008204.GPn6mR990f@linux-ws1.messinet.com> <6450656.BrEhMucQJ9@linux-ws1.messinet.com> <2605490.sxqcQKAmra@linux-ws1.messinet.com> <1702108.6dHCFZAZ6h@linux-ws1.messinet.com> <50A244AD.3060000@redhat.com> Message-ID: <50A350FC.4030101@redhat.com> On 11/13/2012 02:01 PM, Martin Kosek wrote: > On 11/12/2012 05:44 PM, Anthony Messina wrote: >> On Monday, November 12, 2012 09:51:14 AM Anthony Messina wrote: >>> On Monday, November 12, 2012 09:17:17 AM Anthony Messina wrote: >>>>>> I also find that when I do a manual ldapsearch for the >>>>>> non-upgraded clients as > >>>>>> >>>>>> follows: >>>>>> >>>>>> >>>>>> ldapsearch -x -D "cn=directory manager" -W -b >>>>>> cn=accounts,dc=messinet,dc=com "(&(objectClass=ipaHost)(fqdn=*))" >>>>>> dn >>>>>> >>>>>> >>>>>> >>>>>> the non-upgraded clients DO NOT appear in the list, but if I do >>>>>> the >>>> >>>> >>>> >>>> following: >>>>>> >>>>>> >>>>>> ldapsearch -x -D "cn=directory manager" -W -b >>>>>> cn=accounts,dc=messinet,dc=com "(&(objectClass=ipaHost))" dn >>>>>> >>>>>> >>>>>> >>>>>> the non-upgraded clients DO appear in the list. Somehow the >>>>>> addition of the fqdn=* in the filter >>>>>> "(&(objectClass=ipaHost)(fqdn=*))" prevents them from being >>>>>> displayed. >>>>>> >>>>>> >>>>>> >>>>>> There were no errors on any of the servers or clients during the >>>>>> upgrade. >>>>>> >>>>>> >>>>>> >>>>>> Your help is appreciated. I've tried to get this corrected all >>>>>> day without success. >>>>>> >>>>>> >>>>>> >>>>>> Thanks in advance. -A >>>>> >>>>> >>>>> >>>>> Hi, >>>>> >>>>> >>>>> >>>>> the SSSD depends on the fqdn attribute being present for the access >>>>> control mechanism. Also, the SSSD searches the directory >>>>> anonymously, so in order to get the same results, you should simply >>>>> search the directory with anonymous bind. Can you check on the >>>>> server how the host entries look like? >>>>> >>>>> >>>>> >>>>> For example: ipa host-show ds.messinet.com --all --raw >>>>> >>>>> >>>>> >>>>> Is the FQDN attribute present in the directory at all? >>>> >>>> >>>> >>>> Yes it is present. The entry seems to appear similar to other >>>> entries. I'm wondering if for some reason it wasn't indexed (I >>>> don't know much about indexing), but only the hosts that are >>>> re-enrolled after the update are displayed with the above search. I'm >>>> thinking this may be related to >>>> http://git.fedorahosted.org/cgit/freeipa.git/commit/?h=ipa-2-2&id=ce11a7c0 >>>> >>>> > e >>>> 22ee8f70e14c43419f20be70176fe8c >>>> >>>> >>>> >>>> Is there a way to re-index the fqdn attribute? >>> >>> While this may be a red herring, I also do not find in my >>> ipaupgrade.log any attempt to re-index the fqdn attribute. These are >>> the only entries for which tasks are created. >>> >>> 2012-11-11T13:25:39Z INFO Creating task to index attribute: memberuid >>> 2012-11-11T13:25:45Z INFO Creating task to index attribute: memberOf >>> 2012-11-11T13:25:51Z INFO Creating task to index attribute: memberHost >>> 2012-11-11T13:25:57Z INFO Creating task to index attribute: memberUser >>> 2012-11-11T13:26:03Z INFO Creating task to index attribute: ntUniqueId >>> 2012-11-11T13:26:09Z INFO Creating task to index attribute: >>> ntUserDomainId >> >> This in fact was the issue for SSSD: while indexes were added to 389 for >> the fqdn attribute, there was no index task created, so previous entries >> were not indexed, as new hosts were. Running the following "fixed" the >> issue and SSSD- based logins resumed immediately: >> >> >> ~]# cat fqdn_index_task.ldif dn: cn=indextask_fqdn, cn=index, cn=tasks, >> cn=config objectclass: top objectclass: extensibleObject cn: >> indextask_fqdn nsInstance: userRoot nsIndexAttribute: fqdn >> >> ~]# ldapadd -vvv -x -D "cn=directory manager" -W -f fqdn_index_task.ldif >> >> See https://fedorahosted.org/freeipa/ticket/3253 >> > > Thanks Anthony for this bug report! I added some info to the Trac ticket, but > I will rather repeat here: > > This is indeed a bug in a code processing index updates. Index task is > supposed to be created automatically for every new or updated index (i.e. the > referred patch is OK), but it is unfortunately only processed in the update > code path. > > To workaround the issue, one can either fire the index task manually as you > did or simply run the FreeIPA LDAP upgrade procedure manually after > freeipa-server package update. This will fire an index task too: > > # ipa-ldap-updater --upgrade > # grep "Creating task to index" /var/log/ipaupgrade.log > 2012-11-13T12:17:23Z INFO Creating task to index attribute: memberuid > 2012-11-13T12:17:29Z INFO Creating task to index attribute: memberOf > 2012-11-13T12:17:35Z INFO Creating task to index attribute: memberHost > 2012-11-13T12:17:41Z INFO Creating task to index attribute: memberUser > 2012-11-13T12:17:47Z INFO Creating task to index attribute: fqdn <<<< > 2012-11-13T12:17:53Z INFO Creating task to index attribute: ntUniqueId > 2012-11-13T12:17:59Z INFO Creating task to index attribute: ntUserDomainId > > After this command is run, the issue will be fixed. > > Martin > I just released FreeIPA with a fix for this issue to Fedora 17: https://admin.fedoraproject.org/updates/freeipa-2.2.1-2.fc17 The build should hit updates-testing repo soon. Upgrading 2.2.0 (or 2.2.1-1) to 2.2.1-2 should be now flawless. Martin From pspacek at redhat.com Wed Nov 14 08:42:03 2012 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 14 Nov 2012 09:42:03 +0100 Subject: [Freeipa-users] ipa and cronjob In-Reply-To: <25082895.l9WEP28WKN@linux-ws1.messinet.com> References: <1352844644.45947.YahooMailNeo@web163102.mail.bf1.yahoo.com> <1496311.9buQiMQakS@linux-ws1.messinet.com> <1352869229.10327.642.camel@willson.li.ssimo.org> <25082895.l9WEP28WKN@linux-ws1.messinet.com> Message-ID: <50A3595B.7010301@redhat.com> On 11/14/2012 07:22 AM, Anthony Messina wrote: > On Wednesday, November 14, 2012 05:00:29 AM Simo Sorce wrote: >> On Tue, 2012-11-13 at 21:53 -0600, Anthony Messina wrote: >>> 1. Using automatic login with the lightdm display manager, I have it >>> run the >>> following script to remove any old Kerberos ccaches, then obtain a new >>> ticket >>> on behalf of the user, and set the appropriate permissions and >>> SELinux >>> context. Note that in this case, I echo the password to kinit -- If >>> I >>> exported a keytab, I would not be able to manually login with a known >>> password >>> if there were a problem. >> >> Just FYI, this is not strictly true, look at the -P, --password option >> of ipa-getkeytab > > Thanks. I didn't notice that option since I'd been using this method since > before I started using IPA. > > Is the password used to genterate a principle still usable after a keytab has > been exported? I seem to remember from my pre-IPA days of using a plain old > standalone MIT KDC that I couldn't use the password to authenticate after they > keytab had been exported using kadmin. Again, I never really investigated it, > but the password never seemed to work after the keytab was exported. Kadmin from original MIT Kerberos has to flavors: kadmin and kadmin.local. Only "kadmin.local" (which works locally on KDC) can export keytab without re-generating key (i.e. password). Network version - "kadmin" - have to re-generate key before each export. Simo can provide details about IPA get-keytab implementation. -- Petr^2 Spacek From simo at redhat.com Wed Nov 14 13:30:48 2012 From: simo at redhat.com (Simo Sorce) Date: Wed, 14 Nov 2012 08:30:48 -0500 Subject: [Freeipa-users] ipa and cronjob In-Reply-To: <25082895.l9WEP28WKN@linux-ws1.messinet.com> References: <1352844644.45947.YahooMailNeo@web163102.mail.bf1.yahoo.com> <1496311.9buQiMQakS@linux-ws1.messinet.com> <1352869229.10327.642.camel@willson.li.ssimo.org> <25082895.l9WEP28WKN@linux-ws1.messinet.com> Message-ID: <1352899848.10327.649.camel@willson.li.ssimo.org> On Wed, 2012-11-14 at 00:22 -0600, Anthony Messina wrote: > On Wednesday, November 14, 2012 05:00:29 AM Simo Sorce wrote: > > On Tue, 2012-11-13 at 21:53 -0600, Anthony Messina wrote: > > > 1. Using automatic login with the lightdm display manager, I have it > > > run the > > > following script to remove any old Kerberos ccaches, then obtain a new > > > ticket > > > on behalf of the user, and set the appropriate permissions and > > > SELinux > > > context. Note that in this case, I echo the password to kinit -- If > > > I > > > exported a keytab, I would not be able to manually login with a known > > > password > > > if there were a problem. > > > > Just FYI, this is not strictly true, look at the -P, --password option > > of ipa-getkeytab > > Thanks. I didn't notice that option since I'd been using this method since > before I started using IPA. > > Is the password used to genterate a principle still usable after a keytab has > been exported? I seem to remember from my pre-IPA days of using a plain old > standalone MIT KDC that I couldn't use the password to authenticate after they > keytab had been exported using kadmin. Again, I never really investigated it, > but the password never seemed to work after the keytab was exported. If you ask kadmin to randomize the password, then you are basically *changing* the password at the time you export the keytab with a random one, so your *old* password won't work anymore and you do not know the new random one. But if you tell ipa-getkeytab to use a specific secret when generating the keytab that is what is used to generate the new keys, so whether you use pre-computed hashes in the keytab or manually regenerate them at kinit time using a password it makes no difference. Of course if you then change your password or get a new keytab you will change again keys so the repvious password/keytab won't work anymore. Simo. -- Simo Sorce * Red Hat, Inc * New York From andrerobauru at gmail.com Wed Nov 14 13:54:17 2012 From: andrerobauru at gmail.com (Andre Rodrigues) Date: Wed, 14 Nov 2012 11:54:17 -0200 Subject: [Freeipa-users] replica read-only Message-ID: Hi, I'm trying to setup replicas from my ipa server and "ipa-replica-install" is based on multimaster replication. Is there a way to set a ipa replica to be a slave/read-only? -- Thanks a lot, -Andre -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Wed Nov 14 14:07:11 2012 From: simo at redhat.com (Simo Sorce) Date: Wed, 14 Nov 2012 09:07:11 -0500 Subject: [Freeipa-users] replica read-only In-Reply-To: References: Message-ID: <1352902031.10327.655.camel@willson.li.ssimo.org> On Wed, 2012-11-14 at 11:54 -0200, Andre Rodrigues wrote: > Hi, > I'm trying to setup replicas from my ipa server and > "ipa-replica-install" is based on multimaster replication. > Is there a way to set a ipa replica to be a slave/read-only? > No,at the moment replicas are full masters, we are investigating how to create read-only replicas in the future, but it will be a while. What is the reason you'd like a read-only replica ? Knowing use cases will help us decide how read-only replicas will need to behave in general. Simo. -- Simo Sorce * Red Hat, Inc * New York From amessina at messinet.com Wed Nov 14 17:57:56 2012 From: amessina at messinet.com (Anthony Messina) Date: Wed, 14 Nov 2012 11:57:56 -0600 Subject: [Freeipa-users] sssd/pam login issues after upgrade to 2.2.1 on Fedora 17 In-Reply-To: <50A350FC.4030101@redhat.com> References: <3008204.GPn6mR990f@linux-ws1.messinet.com> <50A244AD.3060000@redhat.com> <50A350FC.4030101@redhat.com> Message-ID: <13674206.nsuY1EbA5e@linux-ws1.messinet.com> On Wednesday, November 14, 2012 09:06:20 AM Martin Kosek wrote: > >> See https://fedorahosted.org/freeipa/ticket/3253 > > > > > > > > Thanks Anthony for this bug report! I added some info to the Trac ticket, > > but> > > I will rather repeat here: > > > > > > This is indeed a bug in a code processing index updates. Index task is > > supposed to be created automatically for every new or updated index (i.e. > > the referred patch is OK), but it is unfortunately only processed in the > > update code path. > > > > > > > > To workaround the issue, one can either fire the index task manually as > > you > > did or simply run the FreeIPA LDAP upgrade procedure manually after > > > > freeipa-server package update. This will fire an index task too: > > > > > > # ipa-ldap-updater --upgrade > > # grep "Creating task to index" /var/log/ipaupgrade.log > > 2012-11-13T12:17:23Z INFO Creating task to index attribute: memberuid > > 2012-11-13T12:17:29Z INFO Creating task to index attribute: memberOf > > 2012-11-13T12:17:35Z INFO Creating task to index attribute: memberHost > > 2012-11-13T12:17:41Z INFO Creating task to index attribute: memberUser > > 2012-11-13T12:17:47Z INFO Creating task to index attribute: > > fqdn <<<< 2012-11-13T12:17:53Z INFO Creating task to index > > attribute: ntUniqueId 2012-11-13T12:17:59Z INFO Creating task to index > > attribute: ntUserDomainId> > > > > > > After this command is run, the issue will be fixed. > > > > > > > > Martin > > > > > > I just released FreeIPA with a fix for this issue to Fedora 17: > > https://admin.fedoraproject.org/updates/freeipa-2.2.1-2.fc17 > > The build should hit updates-testing repo soon. Upgrading 2.2.0 (or 2.2.1-1) > to 2.2.1-2 should be now flawless. > > Martin Thanks again, Martin, for the speedy work on this. -A -- Anthony - http://messinet.com - http://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: 198 bytes Desc: This is a digitally signed message part. URL: From amessina at messinet.com Wed Nov 14 18:14:44 2012 From: amessina at messinet.com (Anthony Messina) Date: Wed, 14 Nov 2012 12:14:44 -0600 Subject: [Freeipa-users] ipa and cronjob In-Reply-To: <50A3595B.7010301@redhat.com> References: <1352844644.45947.YahooMailNeo@web163102.mail.bf1.yahoo.com> <25082895.l9WEP28WKN@linux-ws1.messinet.com> <50A3595B.7010301@redhat.com> Message-ID: <3587535.gsOWats2LV@linux-ws1.messinet.com> On Wednesday, November 14, 2012 09:42:03 AM Petr Spacek wrote: > >> Just FYI, this is not strictly true, look at the -P, --password option > >> of ipa-getkeytab > > > > Thanks. I didn't notice that option since I'd been using this method > > since > > before I started using IPA. > > > > Is the password used to genterate a principle still usable after a keytab > > has been exported? I seem to remember from my pre-IPA days of using a > > plain old standalone MIT KDC that I couldn't use the password to > > authenticate after they keytab had been exported using kadmin. Again, I > > never really investigated it, but the password never seemed to work after > > the keytab was exported. > Kadmin from original MIT Kerberos has to flavors: kadmin and kadmin.local. > > Only "kadmin.local" (which works locally on KDC) can export keytab without > re-generating key (i.e. password). > > Network version - "kadmin" - have to re-generate key before each export. Petr, you are right. I never knew that distinction between kadmin and kadmin.local. It was kadmin that I would use on remote machines to export the keytab, rendering the original password useless. Thanks for the info. -A -- Anthony - http://messinet.com - http://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: 198 bytes Desc: This is a digitally signed message part. URL: From amessina at messinet.com Wed Nov 14 18:16:42 2012 From: amessina at messinet.com (Anthony Messina) Date: Wed, 14 Nov 2012 12:16:42 -0600 Subject: [Freeipa-users] ipa and cronjob In-Reply-To: <1352899848.10327.649.camel@willson.li.ssimo.org> References: <1352844644.45947.YahooMailNeo@web163102.mail.bf1.yahoo.com> <25082895.l9WEP28WKN@linux-ws1.messinet.com> <1352899848.10327.649.camel@willson.li.ssimo.org> Message-ID: <7129005.DExMgBnzgU@linux-ws1.messinet.com> On Wednesday, November 14, 2012 08:30:48 AM Simo Sorce wrote: > > > Just FYI, this is not strictly true, look at the -P, --password option > > > of ipa-getkeytab > > > > > > > > Thanks. I didn't notice that option since I'd been using this method > > since before I started using IPA. > > > > > > > > Is the password used to genterate a principle still usable after a keytab > > has been exported? I seem to remember from my pre-IPA days of using a > > plain old standalone MIT KDC that I couldn't use the password to > > authenticate after they keytab had been exported using kadmin. Again, I > > never really investigated it, but the password never seemed to work after > > the keytab was exported. > If you ask kadmin to randomize the password, then you are basically > changing the password at the time you export the keytab with a random > one, so your old password won't work anymore and you do not know the > new random one. > > But if you tell ipa-getkeytab to use a specific secret when generating > the keytab that is what is used to generate the new keys, so whether you > use pre-computed hashes in the keytab or manually regenerate them at > kinit time using a password it makes no difference. > > Of course if you then change your password or get a new keytab you will > change again keys so the repvious password/keytab won't work anymore. > > Simo. Thanks Simo and Petr for clarifying this. This is something that I'll definitely take a look at now having this information. -A -- Anthony - http://messinet.com - http://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: 198 bytes Desc: This is a digitally signed message part. URL: From bcook at redhat.com Wed Nov 14 18:26:02 2012 From: bcook at redhat.com (Brian Cook) Date: Wed, 14 Nov 2012 10:26:02 -0800 Subject: [Freeipa-users] replica read-only In-Reply-To: <1352902031.10327.655.camel@willson.li.ssimo.org> References: <1352902031.10327.655.camel@willson.li.ssimo.org> Message-ID: <2128D3BF-84E7-4669-81D5-567D871FD709@redhat.com> Having a read-only replica would be ideal for placement in a DMZ. See active directory's read-only domain controller introduced in 2008 R2 for just that use case. -Brian On Nov 14, 2012, at 6:07 AM, Simo Sorce wrote: > On Wed, 2012-11-14 at 11:54 -0200, Andre Rodrigues wrote: >> Hi, >> I'm trying to setup replicas from my ipa server and >> "ipa-replica-install" is based on multimaster replication. >> Is there a way to set a ipa replica to be a slave/read-only? >> > No,at the moment replicas are full masters, we are investigating how to > create read-only replicas in the future, but it will be a while. > > What is the reason you'd like a read-only replica ? Knowing use cases > will help us decide how read-only replicas will need to behave in > general. > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From simo at redhat.com Wed Nov 14 18:36:50 2012 From: simo at redhat.com (Simo Sorce) Date: Wed, 14 Nov 2012 13:36:50 -0500 Subject: [Freeipa-users] replica read-only In-Reply-To: <2128D3BF-84E7-4669-81D5-567D871FD709@redhat.com> References: <1352902031.10327.655.camel@willson.li.ssimo.org> <2128D3BF-84E7-4669-81D5-567D871FD709@redhat.com> Message-ID: <1352918210.10327.677.camel@willson.li.ssimo.org> On Wed, 2012-11-14 at 10:26 -0800, Brian Cook wrote: > Having a read-only replica would be ideal for placement in a DMZ. See > active directory's read-only domain controller introduced in 2008 R2 > for just that use case. Hi Brian, yes we know about the DMZ use case, but that one goes beyond just the 'Read-Only' aspect. Although they call their DC a RODC, the 'ReadOnly' part is a bit misleading. A RODC is not much about being read-only, but more about information segregation, A RODC not only prevents modification of a lot of data, it also is not given most of the key material at all, requiring additional server2server protocols to deal with proxying some of the requests when key material is not available locally. When people ask about read-only replicas I am interested in their use case because it means usually they come from a setup where they have just NIS or LDAP (and no kerberos, or kerberos is completely separated) and used master-slave solutions. What I try to understand is if they are asking just because they are used to the setup or if there are actual deeper reasons for wanting a similar setup. Simo. -- Simo Sorce * Red Hat, Inc * New York From andrerobauru at gmail.com Wed Nov 14 18:47:36 2012 From: andrerobauru at gmail.com (Andre Rodrigues) Date: Wed, 14 Nov 2012 16:47:36 -0200 Subject: [Freeipa-users] Fwd: replica read-only In-Reply-To: References: <1352902031.10327.655.camel@willson.li.ssimo.org> Message-ID: thanks for the info Simo! I work at a university and the current structure is: a meta-directory that feeds a master 389-ds, and the master replicates the data to two read-only directories, that are accessible to customers. any changes in the directory should be sent to the meta-directory, which will apply the changes on the master. Now I'm studying FreeIPA to see a possible exchange of 389DS for FreeIPA (primarily by trust with ad). This is not an appropriate structure for FreeIPA(nor a directory actually) but a read-only FreeIPA would be best for us. -- Thanks a lot, -Andre On Wed, Nov 14, 2012 at 12:07 PM, Simo Sorce wrote: > On Wed, 2012-11-14 at 11:54 -0200, Andre Rodrigues wrote: > > Hi, > > I'm trying to setup replicas from my ipa server and > > "ipa-replica-install" is based on multimaster replication. > > Is there a way to set a ipa replica to be a slave/read-only? > > > No,at the moment replicas are full masters, we are investigating how to > create read-only replicas in the future, but it will be a while. > > What is the reason you'd like a read-only replica ? Knowing use cases > will help us decide how read-only replicas will need to behave in > general. > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Wed Nov 14 18:50:29 2012 From: simo at redhat.com (Simo Sorce) Date: Wed, 14 Nov 2012 13:50:29 -0500 Subject: [Freeipa-users] Fwd: replica read-only In-Reply-To: References: <1352902031.10327.655.camel@willson.li.ssimo.org> Message-ID: <1352919029.10327.679.camel@willson.li.ssimo.org> On Wed, 2012-11-14 at 16:47 -0200, Andre Rodrigues wrote: > thanks for the info Simo! > I work at a university and the current structure is: > a meta-directory that feeds a master 389-ds, and the master replicates > the data to two read-only directories, that are accessible to > customers. > any changes in the directory should be sent to the meta-directory, > which will apply the changes on the master. > Now I'm studying FreeIPA to see a possible exchange of 389DS for > FreeIPA (primarily by trust with ad). > This is not an appropriate structure for FreeIPA(nor a directory > actually) but a read-only FreeIPA would be best for us. Oh so you would want a completely read-only setup, no changes at all on any server in orer to drive everything from the meta-directory ? Don't think that will be possible. You can certainly use metadirectories to synchronize stuff but enforcing read-only behavior for everything simply does not cope with the feature set unless you want to strip freeipa of all the reasons to use it :) Simo. -- Simo Sorce * Red Hat, Inc * New York From Steven.Jones at vuw.ac.nz Thu Nov 15 20:32:32 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Thu, 15 Nov 2012 20:32:32 +0000 Subject: [Freeipa-users] replica read-only In-Reply-To: <1352902031.10327.655.camel@willson.li.ssimo.org> References: , <1352902031.10327.655.camel@willson.li.ssimo.org> Message-ID: <833D8E48405E064EBC54C84EC6B36E4054720364@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, Where a security manager/context/system wants a read-only slave out in the DMZ. If you want more reasoning I think AD has these, I would assume Microsoft has some white papers on the "classic" reasons. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Simo Sorce [simo at redhat.com] Sent: Thursday, 15 November 2012 3:07 a.m. To: Andre Rodrigues Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] replica read-only On Wed, 2012-11-14 at 11:54 -0200, Andre Rodrigues wrote: > Hi, > I'm trying to setup replicas from my ipa server and > "ipa-replica-install" is based on multimaster replication. > Is there a way to set a ipa replica to be a slave/read-only? > No,at the moment replicas are full masters, we are investigating how to create read-only replicas in the future, but it will be a while. What is the reason you'd like a read-only replica ? Knowing use cases will help us decide how read-only replicas will need to behave in general. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From Steven.Jones at vuw.ac.nz Thu Nov 15 20:34:52 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Thu, 15 Nov 2012 20:34:52 +0000 Subject: [Freeipa-users] replica read-only In-Reply-To: <1352918210.10327.677.camel@willson.li.ssimo.org> References: <1352902031.10327.655.camel@willson.li.ssimo.org> <2128D3BF-84E7-4669-81D5-567D871FD709@redhat.com>, <1352918210.10327.677.camel@willson.li.ssimo.org> Message-ID: <833D8E48405E064EBC54C84EC6B36E4054720371@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, Which also rises the Q why windows trained security ppl think such read only solutions are the bees knees. ie are they blidly looking at the offering and saying that sounds good we'll have that without really understanding the issues.... Salesmen win over techies again maybe.....(story of my life) regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Simo Sorce [simo at redhat.com] Sent: Thursday, 15 November 2012 7:36 a.m. To: Brian Cook Cc: Andre Rodrigues; freeipa-users at redhat.com Subject: Re: [Freeipa-users] replica read-only On Wed, 2012-11-14 at 10:26 -0800, Brian Cook wrote: > Having a read-only replica would be ideal for placement in a DMZ. See > active directory's read-only domain controller introduced in 2008 R2 > for just that use case. Hi Brian, yes we know about the DMZ use case, but that one goes beyond just the 'Read-Only' aspect. Although they call their DC a RODC, the 'ReadOnly' part is a bit misleading. A RODC is not much about being read-only, but more about information segregation, A RODC not only prevents modification of a lot of data, it also is not given most of the key material at all, requiring additional server2server protocols to deal with proxying some of the requests when key material is not available locally. When people ask about read-only replicas I am interested in their use case because it means usually they come from a setup where they have just NIS or LDAP (and no kerberos, or kerberos is completely separated) and used master-slave solutions. What I try to understand is if they are asking just because they are used to the setup or if there are actual deeper reasons for wanting a similar setup. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From qchang at sri.utoronto.ca Thu Nov 15 21:21:23 2012 From: qchang at sri.utoronto.ca (Qing Chang) Date: Thu, 15 Nov 2012 16:21:23 -0500 Subject: [Freeipa-users] adding group fails with "Type or value exists" In-Reply-To: References: Message-ID: <50A55CD3.9010201@sri.utoronto.ca> Adding group produces error message "Type or value exists" and fails. As shown below, I tried a few different group name to ensure that there is no duplicates: [root at ipa1 ~]# ipa -d group-add example --desc="Test" ipa: DEBUG: Caught fault 4203 from server http://ipa1/ipa/xml: Type or value exists: ipa: DEBUG: Destroyed connection context.xmlclient ipa: ERROR: Type or value exists: Saw in a thread in March, it did not appear there was a resolution. I have turned off migration mode also to make sure that's not a factor. Thanks, Qing From jdennis at redhat.com Thu Nov 15 23:10:04 2012 From: jdennis at redhat.com (John Dennis) Date: Thu, 15 Nov 2012 18:10:04 -0500 Subject: [Freeipa-users] adding group fails with "Type or value exists" In-Reply-To: <50A55CD3.9010201@sri.utoronto.ca> References: <50A55CD3.9010201@sri.utoronto.ca> Message-ID: <50A5764C.50802@redhat.com> On 11/15/2012 04:21 PM, Qing Chang wrote: > Adding group produces error message "Type or value exists" and fails. > > As shown below, I tried a few different group name to ensure that there > is no duplicates: > > [root at ipa1 ~]# ipa -d group-add example --desc="Test" > > ipa: DEBUG: Caught fault 4203 from server http://ipa1/ipa/xml: Type or value exists: > ipa: DEBUG: Destroyed connection context.xmlclient > ipa: ERROR: Type or value exists: > > Saw in a thread in March, it did not appear there was a resolution. Hello Qing: What version of ipa are you using? Which distribution (e.g. F17, RHEL 6.3)? -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From qchang at sri.utoronto.ca Thu Nov 15 23:48:53 2012 From: qchang at sri.utoronto.ca (Qing Chang) Date: Thu, 15 Nov 2012 18:48:53 -0500 Subject: [Freeipa-users] adding group fails with "Type or value exists" In-Reply-To: <50A5764C.50802@redhat.com> References: <50A55CD3.9010201@sri.utoronto.ca> <50A5764C.50802@redhat.com> Message-ID: <50A57F65.6090506@sri.utoronto.ca> On 15/11/2012 6:10 PM, John Dennis wrote: > On 11/15/2012 04:21 PM, Qing Chang wrote: >> Adding group produces error message "Type or value exists" and fails. >> >> As shown below, I tried a few different group name to ensure that there >> is no duplicates: >> >> [root at ipa1 ~]# ipa -d group-add example --desc="Test" >> >> ipa: DEBUG: Caught fault 4203 from server http://ipa1/ipa/xml: Type or value exists: >> ipa: DEBUG: Destroyed connection context.xmlclient >> ipa: ERROR: Type or value exists: >> >> Saw in a thread in March, it did not appear there was a resolution. > > Hello Qing: > > What version of ipa are you using? Which distribution (e.g. F17, RHEL 6.3)? > > ipa-admintools.x86_64 2.2.0-16.el6 @rhel-x86_64-server-6 ipa-client.x86_64 2.2.0-16.el6 @rhel-x86_64-server-6 ipa-pki-ca-theme.noarch 9.0.3-7.el6 @rhel-x86_64-server-6 ipa-pki-common-theme.noarch 9.0.3-7.el6 @rhel-x86_64-server-6 ipa-python.x86_64 2.2.0-16.el6 @rhel-x86_64-server-6 ipa-server.x86_64 2.2.0-16.el6 @rhel-x86_64-server-6 ipa-server-selinux.x86_64 2.2.0-16.el6 @rhel-x86_64-server-6 libipa_hbac.x86_64 1.8.0-32.el6 @rhel-x86_64-server-6 libipa_hbac-python.x86_64 1.8.0-32.el6 @rhel-x86_64-server-6 python-iniparse.noarch 0.3.1-2.1.el6 @anaconda-RedHatEnterpriseLinux-201111171049.x86_64/6.2 Red Hat Enterprise Linux Server release 6.3 (Santiago) Thanks, Qing -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri Nov 16 00:07:07 2012 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 15 Nov 2012 19:07:07 -0500 Subject: [Freeipa-users] adding group fails with "Type or value exists" In-Reply-To: <50A57F65.6090506@sri.utoronto.ca> References: <50A55CD3.9010201@sri.utoronto.ca> <50A5764C.50802@redhat.com> <50A57F65.6090506@sri.utoronto.ca> Message-ID: <50A583AB.7040200@redhat.com> On 11/15/2012 06:48 PM, Qing Chang wrote: > > On 15/11/2012 6:10 PM, John Dennis wrote: >> On 11/15/2012 04:21 PM, Qing Chang wrote: >>> Adding group produces error message "Type or value exists" and fails. >>> >>> As shown below, I tried a few different group name to ensure that there >>> is no duplicates: >>> >>> [root at ipa1 ~]# ipa -d group-add example --desc="Test" >>> >>> ipa: DEBUG: Caught fault 4203 from server http://ipa1/ipa/xml: Type >>> or value exists: >>> ipa: DEBUG: Destroyed connection context.xmlclient >>> ipa: ERROR: Type or value exists: >>> >>> Saw in a thread in March, it did not appear there was a resolution. >> >> Hello Qing: >> >> What version of ipa are you using? Which distribution (e.g. F17, RHEL >> 6.3)? >> >> > Do you already have group "example"? > ipa-admintools.x86_64 2.2.0-16.el6 > @rhel-x86_64-server-6 > ipa-client.x86_64 2.2.0-16.el6 > @rhel-x86_64-server-6 > ipa-pki-ca-theme.noarch 9.0.3-7.el6 > @rhel-x86_64-server-6 > ipa-pki-common-theme.noarch 9.0.3-7.el6 > @rhel-x86_64-server-6 > ipa-python.x86_64 2.2.0-16.el6 > @rhel-x86_64-server-6 > ipa-server.x86_64 2.2.0-16.el6 > @rhel-x86_64-server-6 > ipa-server-selinux.x86_64 2.2.0-16.el6 > @rhel-x86_64-server-6 > libipa_hbac.x86_64 1.8.0-32.el6 > @rhel-x86_64-server-6 > libipa_hbac-python.x86_64 1.8.0-32.el6 > @rhel-x86_64-server-6 > python-iniparse.noarch 0.3.1-2.1.el6 > @anaconda-RedHatEnterpriseLinux-201111171049.x86_64/6.2 > > Red Hat Enterprise Linux Server release 6.3 (Santiago) > > Thanks, > Qing > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steven.Jones at vuw.ac.nz Fri Nov 16 01:38:02 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Fri, 16 Nov 2012 01:38:02 +0000 Subject: [Freeipa-users] Rebuilding the failing original IPA master In-Reply-To: <509ABACD.4070906@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E405471C1F4@STAWINCOX10MBX1.staff.vuw.ac.nz>, <509A272F.6080109@redhat.com> <833D8E48405E064EBC54C84EC6B36E405471CEF2@STAWINCOX10MBX1.staff.vuw.ac.nz>, <509ABACD.4070906@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E4054720535@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, So far Im working through this, so I made ipam002 the new self cert holder and deleted the old "master" ipam001. Built a new ipam001 from scratch and joined it, all OK. There was however an ipam003, the replication agreements at least for that had to be redone. Without knowing the topology of course you wouldnt have realised that. Ive applied the bind.ldap fix and 389 hotfix for the winsync problem.... Now to test. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: Rob Crittenden [rcritten at redhat.com] Sent: Thursday, 8 November 2012 8:47 a.m. To: Steven Jones Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Rebuilding the failing original IPA master Steven Jones wrote: > Hi, > > The master was 6.2 upgraded to 6.3 its got a "bad schema" so the advice I have is to rebuild it. > > I have 2 replicas they also were upgraded but "blew up" so were rebuilt as fresh 6.3, both these are fine, replicating and working perfectly. > > I dont use CA, its just self signed on them.. OK, details are important here. Terms like "blew up" and "bad schema" leave me guessing exactly what you mean. So if I understand it correctly you have a 2.1.3 -> 2.2.0 master that is limping along and two freshly installed 2.2.0 masters and you'd like to uninstall and re-install the server whose upgrade didn't go well. With a selfsign CA there is only one that is the CA, so if that is the server you want to re-create you'll need to promote one of the working 2.2.0 servers to be the CA. I think the basics steps would be: - promote one of the 2.2.0 masters to be the new CA - verify that the new CA can issue certs - remove the server that failed upgrading (ipa-replica-manage del non-working.example.com) - Follow the CLEANRUV docs at http://directory.fedoraproject.org/wiki/Howto:CLEANRUV (starts about midway down the page) - ipa-server-install --uninstall on the decomissioned server - prepare a new replica file - ipa-replica-install Note that selfsign is not supported in RHEL. You'll need to refer to the Fedora docs on how to do that, see section 16.8.2 at http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/promoting-replica.html Unfortunately the docs are wrong. You want to use the NSS database in /etc/httpd/alias and not the DS instance. The cacert.p12 comes from the file you saved after the initial install. You saved that, right? If not, you can run this on the old master to re-create it: # pk12util -o /tmp/cacert.p12 -d /etc/httpd/alias -n '$REALM IPA CA' -k /etc/httpd/alias/pwdfile.txt These are some instructions one of our engineers wrote up when he needed to do this himself. You can probably skip step 1 as you already have a couple of working replicas. Tread carefully. If you lose your CA you won't have the ability to create new replicas, issue server certs, do much of anything. 1) Install replica # ipa-replica-install 2) Copy CA serial number setting from master to replica: # scp /var/lib/ipa/ca_serialno new_ca.example.com:/var/lib/ipa/ 3) On replica, set correct owner and permissions: # chown root:apache /var/lib/ipa/ca_serialno # chmod 550 /var/lib/ipa/ca_serialno 4) Restore SELinux context on serial file: # restorecon /var/lib/ipa/ca_serialno 5) Copy CA certificate and pwdfile.txt from master to replica: # scp /etc/httpd/alias/cacert.p12 /etc/httpd/alias/pwdfile.txt new_ca.example.com:~/ 7) On replica, import the CA certificate: # pk12util -i ~/cacert.p12 -w ~/pwdfile.txt -d /etc/httpd/alias/ -k /etc/httpd/alias/pwdfile.txt 8) The list of certificates in NSS database (including the one imported) can be listed with: # certutil -L -d /etc/httpd/alias/ However, since pk12util import util is not capable of setting a correct certificate nickname, the imported certificate will have a nickname like ""CN=$REALM Certificate Authority", which is not recognized by IPA certificate system. The following procedure can be used set a correct nickname of the certificate: a) Export the certificate # certutil -d /etc/httpd/alias/ -L -n 'CN=$REALM Certificate Authority' -a > ~/cacert.crt b) Delete the old certificate (NSS database /etc/httpd/alias/ should be backed up before this step): # certutil -d /etc/httpd/alias/ -D -n 'CN=$REALM Certificate Authority' c) Import the certificate with correct nickname: # certutil -A -n "$REALM IPA CA" -d /etc/httpd/alias/ -f /etc/httpd/alias/pwdfile.txt -i /root/cacert.crt -a -t CTu,u,Cu 9) Enable certificate operations on IPA replica: # echo "enable_ra=True" >> /etc/ipa/default.conf 10) Reload web server to pick up new configuration: # service httpd reload From mkosek at redhat.com Fri Nov 16 08:25:06 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 16 Nov 2012 09:25:06 +0100 Subject: [Freeipa-users] adding group fails with "Type or value exists" In-Reply-To: <50A57F65.6090506@sri.utoronto.ca> References: <50A55CD3.9010201@sri.utoronto.ca> <50A5764C.50802@redhat.com> <50A57F65.6090506@sri.utoronto.ca> Message-ID: <50A5F862.9050600@redhat.com> On 11/16/2012 12:48 AM, Qing Chang wrote: > > On 15/11/2012 6:10 PM, John Dennis wrote: >> On 11/15/2012 04:21 PM, Qing Chang wrote: >>> Adding group produces error message "Type or value exists" and fails. >>> >>> As shown below, I tried a few different group name to ensure that there >>> is no duplicates: >>> >>> [root at ipa1 ~]# ipa -d group-add example --desc="Test" >>> >>> ipa: DEBUG: Caught fault 4203 from server http://ipa1/ipa/xml: Type or value >>> exists: >>> ipa: DEBUG: Destroyed connection context.xmlclient >>> ipa: ERROR: Type or value exists: >>> >>> Saw in a thread in March, it did not appear there was a resolution. >> >> Hello Qing: >> >> What version of ipa are you using? Which distribution (e.g. F17, RHEL 6.3)? >> >> > > ipa-admintools.x86_64 2.2.0-16.el6 @rhel-x86_64-server-6 > ipa-client.x86_64 2.2.0-16.el6 @rhel-x86_64-server-6 > ipa-pki-ca-theme.noarch 9.0.3-7.el6 @rhel-x86_64-server-6 > ipa-pki-common-theme.noarch 9.0.3-7.el6 @rhel-x86_64-server-6 > ipa-python.x86_64 2.2.0-16.el6 @rhel-x86_64-server-6 > ipa-server.x86_64 2.2.0-16.el6 @rhel-x86_64-server-6 > ipa-server-selinux.x86_64 2.2.0-16.el6 @rhel-x86_64-server-6 > libipa_hbac.x86_64 1.8.0-32.el6 @rhel-x86_64-server-6 > libipa_hbac-python.x86_64 1.8.0-32.el6 @rhel-x86_64-server-6 > python-iniparse.noarch 0.3.1-2.1.el6 > @anaconda-RedHatEnterpriseLinux-201111171049.x86_64/6.2 > > Red Hat Enterprise Linux Server release 6.3 (Santiago) > > Thanks, > Qing > Hello Quing, did you by any chance modified the list of default group objectclasses? I managed to reproduce the same error with adding "posixgroup" to the list: # ipa config-mod --groupobjectclasses="top,groupofnames,nestedgroup,ipausergroup,ipaobject,posixgroup" ... Default group objectclasses: top, groupofnames, nestedgroup, ipausergroup, ipaobject, posixgroup ... # ipa group-add foo --desc foo ipa: ERROR: Type or value exists: posixgroup should not be in the list as it is later added in group-add command when the group is non-posix. In my case, remedy was simple: # ipa config-mod --groupobjectclasses="top,groupofnames,nestedgroup,ipausergroup,ipaobject" # ipa group-add foo --desc foo ----------------- Added group "foo" ----------------- Group name: foo Description: foo GID: 674400007 Martin From natxo.asenjo at gmail.com Fri Nov 16 12:29:31 2012 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Fri, 16 Nov 2012 13:29:31 +0100 Subject: [Freeipa-users] failure to register dns on joining IPA domain Message-ID: hi, this is a part of ipaclient-install.log 2012-11-16T12:12:32Z DEBUG Writing nsupdate commands to /etc/ipa/.dns_update.txt : zone ipa.domain.tld. update delete host.ipa.domain.tld. IN SSHFP send update add host.ipa.domain.tld. 1200 IN SSHFP 1 1 904DA80AD2554ABEC354599E6876 89307F4ADCF3 update add host.ipa.domain.tld. 1200 IN SSHFP 2 1 0E48943001D3BFB1C0B272C4787C 74C7003DB5CD send 2012-11-16T12:12:32Z DEBUG args=/usr/bin/nsupdate -g /etc/ipa/.dns_update.txt 2012-11-16T12:12:32Z DEBUG stdout= 2012-11-16T12:12:32Z DEBUG stderr=update failed: SERVFAIL I can manually add the A record, but it would be nice to have the sshfp records automatically added as well :-) What can be possibly going wrong? This is in a test centos 6.3 environment (fully patched). -- Groeten, natxo From pspacek at redhat.com Fri Nov 16 13:41:00 2012 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 16 Nov 2012 14:41:00 +0100 Subject: [Freeipa-users] failure to register dns on joining IPA domain In-Reply-To: References: Message-ID: <50A6426C.7030406@redhat.com> On 11/16/2012 01:29 PM, Natxo Asenjo wrote: > hi, > > this is a part of ipaclient-install.log > > 2012-11-16T12:12:32Z DEBUG Writing nsupdate commands to /etc/ipa/.dns_update.txt > : > zone ipa.domain.tld. > update delete host.ipa.domain.tld. IN SSHFP > send > update add host.ipa.domain.tld. 1200 IN SSHFP 1 1 904DA80AD2554ABEC354599E6876 > 89307F4ADCF3 > update add host.ipa.domain.tld. 1200 IN SSHFP 2 1 0E48943001D3BFB1C0B272C4787C > 74C7003DB5CD > send > > 2012-11-16T12:12:32Z DEBUG args=/usr/bin/nsupdate -g /etc/ipa/.dns_update.txt > 2012-11-16T12:12:32Z DEBUG stdout= > 2012-11-16T12:12:32Z DEBUG stderr=update failed: SERVFAIL > > I can manually add the A record, but it would be nice to have the > sshfp records automatically added as well :-) > > What can be possibly going wrong? This is in a test centos 6.3 > environment (fully patched). Hello, do you use IPA managed DNS or own DNS server? Please provide logs from named if you use IPA managed DNS, ideally with higher debug level. 1) Modify log severity in /etc/named.conf on your DNS server: logging { channel default_debug { file "data/named.run"; severity debug 10; }; }; 2) restart named $ service named restart 3) install a new client - and hope for failure 4) send file /var/named/data/named.run to me I will look into it. Thank you for bug report! -- Petr^2 Spacek From natxo.asenjo at gmail.com Fri Nov 16 13:52:18 2012 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Fri, 16 Nov 2012 14:52:18 +0100 Subject: [Freeipa-users] sssd cache Message-ID: hi, when running getent negroup I get old entries. Apparently sssd is being helpful :-) and caching info, but it should not do it when I am connected to the domain (IMHO). According to https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sssd-cache.html I can clean records with sss_cache, but this command is not available. Running yum whatprovides "*/sss_cache" finds nothing either. I ended up wiping the cache and restarting the sssd daemon to have it working, but there should be another way I have missed. Do you have any ideas? TIA. -- Groeten, natxo From natxo.asenjo at gmail.com Fri Nov 16 13:56:59 2012 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Fri, 16 Nov 2012 14:56:59 +0100 Subject: [Freeipa-users] sssd cache In-Reply-To: References: Message-ID: On Fri, Nov 16, 2012 at 2:52 PM, Natxo Asenjo wrote: > hi, > > when running getent negroup I get old entries. > Apparently sssd is being helpful :-) and caching info, but it should > not do it when I am connected to the domain (IMHO). > > According to https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sssd-cache.html > I can clean records with sss_cache, but this command is not available. ahem ... this is in sssd-tools, which is in the 2nd dvd iso which is not in my local mirror (just the first one). Sorry for the noise. -- groet, natxo From sgallagh at redhat.com Fri Nov 16 14:00:23 2012 From: sgallagh at redhat.com (Stephen Gallagher) Date: Fri, 16 Nov 2012 09:00:23 -0500 Subject: [Freeipa-users] sssd cache In-Reply-To: References: Message-ID: <50A646F7.8030705@redhat.com> On Fri 16 Nov 2012 08:56:59 AM EST, Natxo Asenjo wrote: > On Fri, Nov 16, 2012 at 2:52 PM, Natxo Asenjo wrote: >> hi, >> >> when running getent negroup I get old entries. >> Apparently sssd is being helpful :-) and caching info, but it should >> not do it when I am connected to the domain (IMHO). >> >> According to https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sssd-cache.html >> I can clean records with sss_cache, but this command is not available. > > ahem ... > > this is in sssd-tools, which is in the 2nd dvd iso which is not in my > local mirror (just the first one). Sorry for the noise. > Two points here. 1) sss_cache is moving to the main package in RHEL 6.4, so you won't have to install the separate sssd-tools package for it. 2) You might also look at the manpage for entry_cache_netgroup_timeout. If you want to have a shorter timeout period for netgroups, you can set it individually (starting with SSSD 1.8.0, IIRC). I'd suggest not setting it shorter than 10s for performance reasons though. From arpittolani at gmail.com Fri Nov 16 14:00:01 2012 From: arpittolani at gmail.com (Arpit Tolani) Date: Fri, 16 Nov 2012 19:30:01 +0530 Subject: [Freeipa-users] sssd cache In-Reply-To: References: Message-ID: Hello On Fri, Nov 16, 2012 at 7:22 PM, Natxo Asenjo wrote: > hi, > > when running getent negroup I get old entries. > Apparently sssd is being helpful :-) and caching info, but it should > not do it when I am connected to the domain (IMHO). > > According to https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sssd-cache.html > I can clean records with sss_cache, but this command is not available. > > Running yum whatprovides "*/sss_cache" finds nothing either. > sss_cache is shipped with sssd-tools package, which can be found in Red Hat Enterprise Linux Server optional or EPEL optional repository. I guess we have a bugzilla opened to move sssd-tools package to move in base channel, as of now you can Download it from optional channel > I ended up wiping the cache and restarting the sssd daemon to have it > working, but there should be another way I have missed. Do you have > any ideas? > > TIA. > -- > Groeten, > natxo > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users Regards Arpit Tolani From natxo.asenjo at gmail.com Fri Nov 16 14:26:32 2012 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Fri, 16 Nov 2012 15:26:32 +0100 Subject: [Freeipa-users] sssd cache In-Reply-To: <50A646F7.8030705@redhat.com> References: <50A646F7.8030705@redhat.com> Message-ID: On Fri, Nov 16, 2012 at 3:00 PM, Stephen Gallagher wrote: > Two points here. 1) sss_cache is moving to the main package in RHEL 6.4, so > you won't have to install the separate sssd-tools package for it. 2) You > might also look at the manpage for entry_cache_netgroup_timeout. If you want > to have a shorter timeout period for netgroups, you can set it individually > (starting with SSSD 1.8.0, IIRC). I'd suggest not setting it shorter than > 10s for performance reasons though. Thanks for the info. So the default entry_cache_timeout for all operations is 5400 seconds (90 minutes) and after that it queries again. Good to know. -- groet, natxo From bret.wortman at damascusgrp.com Fri Nov 16 15:11:25 2012 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Fri, 16 Nov 2012 10:11:25 -0500 Subject: [Freeipa-users] Problem adding DNS Zones Message-ID: Using FreeIPA on a private network (where it's easier to just alias our own servers to these names than to edit config file after config file). Any idea what I'm doing wrong here? # ipa dnszone-add 0.pool.ntp.org --name-server=dns.project.net--admin-email= root at project.net ipa: ERROR: Nameserver 'dns.project.net' does not have a corresponding A/AAAA record # ipa dnsrecord-find project.net dns Record name: dns A record: a.b.c.d ---------------------------- Number of entries returned 1 ---------------------------- # host dns.project.net dns.project.net has address a.b.c.d # -- Bret Wortman The Damascus Group Fairfax, VA http://bretwortman.com/ http://twitter.com/BretWortman -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Fri Nov 16 15:23:31 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 16 Nov 2012 16:23:31 +0100 Subject: [Freeipa-users] Problem adding DNS Zones In-Reply-To: References: Message-ID: <50A65A73.2000605@redhat.com> On 11/16/2012 04:11 PM, Bret Wortman wrote: > Using FreeIPA on a private network (where it's easier to just alias our own > servers to these names than to edit config file after config file). Any idea > what I'm doing wrong here? > > # ipa dnszone-add 0.pool.ntp.org > --name-server=dns.project.net > --admin-email=root at project.net > ipa: ERROR: Nameserver 'dns.project.net ' does not have > a corresponding A/AAAA record > # ipa dnsrecord-find project.net dns > Record name: dns > A record: a.b.c.d > ---------------------------- > Number of entries returned 1 > ---------------------------- > # host dns.project.net > dns.project.net has address a.b.c.d > # > > > -- > Bret Wortman > The Damascus Group > Fairfax, VA > http://bretwortman.com/ > http://twitter.com/BretWortman > Hello Bret, can you try reloading the httpd server where your IPA server is being run? This issue can happen if you for example change the nameserver in /etc/resolv.conf during httpd run time. Python framework in this httpd server would still be initialized with the old nameserver address and may not be able to resolve the address. Second note: it is safer to use --name-server option in a FQDN form, i.e. dns.project.net. instead of dns.project.net . With newer IPA versions, nameserver set to dns.project.net would effectively mean this FQDN: dns.project.net.0.pool.ntp.org. HTH, Martin Martin From tbabej at redhat.com Fri Nov 16 15:25:37 2012 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 16 Nov 2012 16:25:37 +0100 Subject: [Freeipa-users] Problem adding DNS Zones In-Reply-To: References: Message-ID: <50A65AF1.7090503@redhat.com> On 11/16/2012 04:11 PM, Bret Wortman wrote: > Using FreeIPA on a private network (where it's easier to just alias > our own servers to these names than to edit config file after config > file). Any idea what I'm doing wrong here? > > # ipa dnszone-add 0.pool.ntp.org > --name-server=dns.project.net > --admin-email=root at project.net > ipa: ERROR: Nameserver 'dns.project.net ' does > not have a corresponding A/AAAA record > # ipa dnsrecord-find project.net dns > Record name: dns > A record: a.b.c.d > ---------------------------- > Number of entries returned 1 > ---------------------------- > # host dns.project.net > dns.project.net has address a.b.c.d > # > > > -- > Bret Wortman > The Damascus Group > Fairfax, VA > http://bretwortman.com/ > http://twitter.com/BretWortman > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users Hi, this may be a known bug: https://fedorahosted.org/freeipa/ticket/3063 is this 100% reproducible in your set-up? Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From qchang at sri.utoronto.ca Fri Nov 16 15:26:11 2012 From: qchang at sri.utoronto.ca (Qing Chang) Date: Fri, 16 Nov 2012 10:26:11 -0500 Subject: [Freeipa-users] adding group fails with "Type or value exists" In-Reply-To: <50A5F862.9050600@redhat.com> References: <50A55CD3.9010201@sri.utoronto.ca> <50A5764C.50802@redhat.com> <50A57F65.6090506@sri.utoronto.ca> <50A5F862.9050600@redhat.com> Message-ID: <50A65B13.3020906@sri.utoronto.ca> On 16/11/2012 3:25 AM, Martin Kosek wrote: > On 11/16/2012 12:48 AM, Qing Chang wrote: >> >> On 15/11/2012 6:10 PM, John Dennis wrote: >>> On 11/15/2012 04:21 PM, Qing Chang wrote: >>>> Adding group produces error message "Type or value exists" and fails. >>>> >>>> As shown below, I tried a few different group name to ensure that there >>>> is no duplicates: >>>> >>>> [root at ipa1 ~]# ipa -d group-add example --desc="Test" >>>> >>>> ipa: DEBUG: Caught fault 4203 from server http://ipa1/ipa/xml: Type or value >>>> exists: >>>> ipa: DEBUG: Destroyed connection context.xmlclient >>>> ipa: ERROR: Type or value exists: >>>> >>>> Saw in a thread in March, it did not appear there was a resolution. >>> >>> Hello Qing: >>> >>> What version of ipa are you using? Which distribution (e.g. F17, RHEL 6.3)? >>> >>> >> >> ipa-admintools.x86_64 2.2.0-16.el6 @rhel-x86_64-server-6 >> ipa-client.x86_64 2.2.0-16.el6 @rhel-x86_64-server-6 >> ipa-pki-ca-theme.noarch 9.0.3-7.el6 @rhel-x86_64-server-6 >> ipa-pki-common-theme.noarch 9.0.3-7.el6 @rhel-x86_64-server-6 >> ipa-python.x86_64 2.2.0-16.el6 @rhel-x86_64-server-6 >> ipa-server.x86_64 2.2.0-16.el6 @rhel-x86_64-server-6 >> ipa-server-selinux.x86_64 2.2.0-16.el6 @rhel-x86_64-server-6 >> libipa_hbac.x86_64 1.8.0-32.el6 @rhel-x86_64-server-6 >> libipa_hbac-python.x86_64 1.8.0-32.el6 @rhel-x86_64-server-6 >> python-iniparse.noarch 0.3.1-2.1.el6 >> @anaconda-RedHatEnterpriseLinux-201111171049.x86_64/6.2 >> >> Red Hat Enterprise Linux Server release 6.3 (Santiago) >> >> Thanks, >> Qing >> > > Hello Quing, > > did you by any chance modified the list of default group objectclasses? I managed to reproduce the > same error with adding "posixgroup" to the list: > > # ipa config-mod --groupobjectclasses="top,groupofnames,nestedgroup,ipausergroup,ipaobject,posixgroup" > ... > Default group objectclasses: top, groupofnames, nestedgroup, ipausergroup, ipaobject, posixgroup > ... > > # ipa group-add foo --desc foo > ipa: ERROR: Type or value exists: > > posixgroup should not be in the list as it is later added in group-add command when the group is > non-posix. In my case, remedy was simple: > > # ipa config-mod --groupobjectclasses="top,groupofnames,nestedgroup,ipausergroup,ipaobject" > # ipa group-add foo --desc foo > ----------------- > Added group "foo" > ----------------- > Group name: foo > Description: foo > GID: 674400007 > > Martin Brilliant observation, I do have posixgroup added thinking that's necessary to ensure posix group is created... Removed and works. Many thanks, Qing From pspacek at redhat.com Fri Nov 16 15:27:54 2012 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 16 Nov 2012 16:27:54 +0100 Subject: [Freeipa-users] Problem adding DNS Zones In-Reply-To: References: Message-ID: <50A65B7A.9050708@redhat.com> Hello, you didn't specified IPA version, OS version etc., so my reply will be valid latest IPA master but not necessarily for Your version: You are trying to use name server from another zone so you have to enter absolute DNS name. Value "dns.project.net" is missing the trailing dot, so DNS name was read as relative. As a result zone origin (i.e. "0.pool.ntp.org") was appended to the name - and not found in (empty!) zone "0.pool.ntp.org". You have to specify --ip-address if you want to create a new NS record with relative name. --ip-address and --name-server combination will create NS+A record pair. Petr^2 Spacek On 11/16/2012 04:11 PM, Bret Wortman wrote: > Using FreeIPA on a private network (where it's easier to just alias our own servers to these names than to edit config file after config file). Any idea what I'm doing wrong here? > > # ipa dnszone-add 0.pool.ntp.org --name-server=dns.project.net --admin-email=root at project.net > ipa: ERROR: Nameserver 'dns.project.net' does not have a corresponding A/AAAA record > # ipa dnsrecord-find project.net dns > Record name: dns > A record: a.b.c.d > ---------------------------- > Number of entries returned 1 > ---------------------------- > # host dns.project.net > dns.project.net has address a.b.c.d From qchang at sri.utoronto.ca Fri Nov 16 15:59:18 2012 From: qchang at sri.utoronto.ca (Qing Chang) Date: Fri, 16 Nov 2012 10:59:18 -0500 Subject: [Freeipa-users] IPA weirdness with Samba, Dovecot IMAP and SSHD In-Reply-To: <50A55CD3.9010201@sri.utoronto.ca> References: <50A55CD3.9010201@sri.utoronto.ca> Message-ID: <50A662D6.6050308@sri.utoronto.ca> just migrated all my user from OpenLDAP and MIT Kerberos to IPA. Out of more than 400 users, there are around 10 that have problem accessing Samba or Dovecot IMAP or ssh. They never have problem login to ipa/ipa/ui/login.html. For Dovecot IMAP following error is generated: ===== Nov 16 10:15:03 dovecot2 auth: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=uesrid rhost=IP user=userid Nov 16 10:15:03 dovecot2 auth: pam_sss(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=userid rhost=IP user=useris Nov 16 10:15:03 dovecot2 auth: pam_sss(dovecot:auth): received for user userid: 4 (System error) ===== For Samba, it appears that a mapping request never gets to Samba server because nothing is logged for a problematic user ID although I have turned on excessive logging. What is really frustrating is that there is no pattern to be found, even my fellow Sysadmin's ID is also in trouble. Also, in his case, he has no problem with Dovecot. For another user ID Samba works but not Dovecot. It looks to me there might be some problem with sssd on the different servers? BTW, for at least one user, creating a brand new account for samba did not work either, while the trick worked for another user:-(. Please shed some light on this. I don't mind opening a case with RedHat support if necessary. Red Hat Enterprise Linux Server release 6.3 (Santiago) ipa-server.x86_64 2.2.0-16.el6 @rhel-x86_64-server-6 sssd.x86_64 1.8.0-32.el6 @rhel-x86_64-server-6 sssd-client.x86_64 1.8.0-32.el6 @rhel-x86_64-server-6 TIA, Qing -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri Nov 16 17:11:40 2012 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 16 Nov 2012 12:11:40 -0500 Subject: [Freeipa-users] IPA weirdness with Samba, Dovecot IMAP and SSHD In-Reply-To: <50A662D6.6050308@sri.utoronto.ca> References: <50A55CD3.9010201@sri.utoronto.ca> <50A662D6.6050308@sri.utoronto.ca> Message-ID: <50A673CC.1010206@redhat.com> On 11/16/2012 10:59 AM, Qing Chang wrote: > just migrated all my user from OpenLDAP and MIT Kerberos to IPA. > > Out of more than 400 users, there are around 10 that have problem > accessing Samba or Dovecot IMAP or ssh. > > They never have problem login to ipa/ipa/ui/login.html. > > For Dovecot IMAP following error is generated: > ===== > Nov 16 10:15:03 dovecot2 auth: pam_unix(dovecot:auth): authentication > failure; logname= uid=0 euid=0 tty=dovecot ruser=uesrid rhost=IP > user=userid > Nov 16 10:15:03 dovecot2 auth: pam_sss(dovecot:auth): authentication > failure; logname= uid=0 euid=0 tty=dovecot ruser=userid rhost=IP > user=useris > Nov 16 10:15:03 dovecot2 auth: pam_sss(dovecot:auth): received for > user userid: 4 (System error) Hello Qing There are several things to do: 1) Compare entries of the users that login with no problems and users that have problems. There might be some attributes different (absent/present). That might give a hint of what might be wrong. We have seen some issues in this area related to Samba. 2) Can you please enable the higher debug_level in SSSD and provide the SSSD logs + sssd.conf that would help to see what is going on with the user that is failing. 3) Also if you can describe your environment of how all the parts work together and what are the workflows in which you see the problem/issue. I am personally not familiar with Dovecot in details so I assume that Dovecot is configured to use PAM for the authentication and the snippet above is from that authentication. Is this the correct assumption? Thanks Dmitri > ===== > > For Samba, it appears that a mapping request never gets to Samba > server because > nothing is logged for a problematic user ID although I have turned on > excessive logging. > > What is really frustrating is that there is no pattern to be found, > even my fellow > Sysadmin's ID is also in trouble. > > Also, in his case, he has no problem with Dovecot. For another user ID > Samba works > but not Dovecot. It looks to me there might be some problem with sssd > on the > different servers? > > BTW, for at least one user, creating a brand new account for samba did > not work either, > while the trick worked for another user:-(. > > Please shed some light on this. I don't mind opening a case with > RedHat support > if necessary. > > Red Hat Enterprise Linux Server release 6.3 (Santiago) > ipa-server.x86_64 2.2.0-16.el6 > @rhel-x86_64-server-6 > sssd.x86_64 1.8.0-32.el6 > @rhel-x86_64-server-6 > sssd-client.x86_64 1.8.0-32.el6 > @rhel-x86_64-server-6 > > TIA, > Qing > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bcook at redhat.com Fri Nov 16 23:03:14 2012 From: bcook at redhat.com (Brian Cook) Date: Fri, 16 Nov 2012 15:03:14 -0800 Subject: [Freeipa-users] testing cross realm trusts Message-ID: Hi I'm trying to setup a cross realm trust with AD using directions here: http://freeipa.org/page/IPAv3_testing_AD_trust#Prepare_FreeIPA_server_for_trusts I got all the way to creating the trust, but then I get: [root at ipa1 slapd-IPA-TEST]# ipa trust-add --type=ad msad.test --admin Administrator --password Active directory domain administrator's password: ipa: ERROR: invalid Gettext('ID range exists', domain='ipa', localedir=None): ID range already exists, must be added manually [root at ipa1 slapd-IPA-TEST]# freeipa packages on my box: freeipa-client-3.0.0.rc1-0.fc17.x86_64 freeipa-python-3.0.0.rc1-0.fc17.x86_64 freeipa-admintools-3.0.0.rc1-0.fc17.x86_64 freeipa-server-selinux-3.0.0.rc1-0.fc17.x86_64 freeipa-server-trust-ad-3.0.0.rc1-0.fc17.x86_64 freeipa-server-3.0.0.rc1-0.fc17.x86_64 Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From chillermillerlong at hotmail.com Fri Nov 16 23:35:48 2012 From: chillermillerlong at hotmail.com (=?gb2312?B?0KHB+iCzwg==?=) Date: Fri, 16 Nov 2012 18:35:48 -0500 Subject: [Freeipa-users] FreeIPA on a dual boot system Message-ID: Hi fellow FreeIPA users! I just got my FreeIPA set up perfectly and I was wondering if it's possible to set it up in the other OS in a dual boot configuration. Since I'm still on the same computer (therefore, the same MAC address), ipa-client-install fails saying that I'm already joined to the domain. Is there anything I can do allow the dual booted OS to join? Do I need to change my network configuration? Thanks in advance! Xiao-Long Chen From qchang at sri.utoronto.ca Sat Nov 17 19:20:15 2012 From: qchang at sri.utoronto.ca (Qing Chang) Date: Sat, 17 Nov 2012 14:20:15 -0500 Subject: [Freeipa-users] IPA weirdness with Samba, Dovecot IMAP and SSHD In-Reply-To: <50A673CC.1010206@redhat.com> References: <50A55CD3.9010201@sri.utoronto.ca> <50A662D6.6050308@sri.utoronto.ca> <50A673CC.1010206@redhat.com> Message-ID: <50A7E36F.2010701@sri.utoronto.ca> On 16/11/2012 12:11 PM, Dmitri Pal wrote: > On 11/16/2012 10:59 AM, Qing Chang wrote: >> just migrated all my user from OpenLDAP and MIT Kerberos to IPA. >> >> Out of more than 400 users, there are around 10 that have problem >> accessing Samba or Dovecot IMAP or ssh. >> >> They never have problem login to ipa/ipa/ui/login.html. >> >> For Dovecot IMAP following error is generated: >> ===== >> Nov 16 10:15:03 dovecot2 auth: pam_unix(dovecot:auth): authentication failure; logname= uid=0 >> euid=0 tty=dovecot ruser=uesrid rhost=IP user=userid >> Nov 16 10:15:03 dovecot2 auth: pam_sss(dovecot:auth): authentication failure; logname= uid=0 >> euid=0 tty=dovecot ruser=userid rhost=IP user=useris >> Nov 16 10:15:03 dovecot2 auth: pam_sss(dovecot:auth): received for user userid: 4 (System error) > > Hello Qing > > There are several things to do: > 1) Compare entries of the users that login with no problems and users that have problems. There > might be some attributes different (absent/present). That might give a hint of what might be > wrong. We have seen some issues in this area related to Samba. > 2) Can you please enable the higher debug_level in SSSD and provide the SSSD logs + sssd.conf that > would help to see what is going on with the user that is failing. > 3) Also if you can describe your environment of how all the parts work together and what are the > workflows in which you see the problem/issue. I am personally not familiar with Dovecot in details > so I assume that Dovecot is configured to use PAM for the authentication and the snippet above is > from that authentication. Is this the correct assumption? > > Thanks > Dmitri > Dmitri, appreciate your prompt response. I having being on this thing for past day and a half, I think I now understand the issues and found fix/workaround for them. 1, Samba + IPA: when this attribute sambaPwdLastSet is set to 0, a samba mapping request will cause samba to CLEAR sambaLMPassword and sambaNTPassword attributes, yes, not set password to something, but the attributes are wiped out. This may only apply to my situation because I HAVE to use samba 3.0.23d, a ancient version!! Originally when I migrated users from OpenLDAP, sambaPwdLastSet has a none zero value for every account. As users migrated their password properly, the value was not touch. But, if someone's password has to be reset (too short, forgotten) by us admin user using the UI, sambaPwdLastSet is set to 0. This explains why the problem is not wide spread. Fix/workaround: change sambaPwdLastSet to a sensible value after a password reset by admin. Question: is this a designed behavior for IPA? Or does migrate-mode or not make difference? 2, Dovecot + IPA: it is not an IPA issue but sss cache timeout issue, I read it's 90 min? When a user changes his/her password, the cache usually is not updated, hence problem checking IMAP email with new password. Fix/workaround: \rm /var/lib/sss/db/cache_sri.utoronto.ca.ldb service sssd restart This is really heavy handed, but I can not find the sss_cache utility any where for RHEL 6.3! Question: is there a way to shorten the timeout period? Where can I find sss_cache? I have great confidence in IPA now, big part of it is because of this list!! Many thanks, Qing >> ===== >> >> For Samba, it appears that a mapping request never gets to Samba server because >> nothing is logged for a problematic user ID although I have turned on excessive logging. >> >> What is really frustrating is that there is no pattern to be found, even my fellow >> Sysadmin's ID is also in trouble. >> >> Also, in his case, he has no problem with Dovecot. For another user ID Samba works >> but not Dovecot. It looks to me there might be some problem with sssd on the >> different servers? >> >> BTW, for at least one user, creating a brand new account for samba did not work either, >> while the trick worked for another user:-(. >> >> Please shed some light on this. I don't mind opening a case with RedHat support >> if necessary. >> >> Red Hat Enterprise Linux Server release 6.3 (Santiago) >> ipa-server.x86_64 2.2.0-16.el6 @rhel-x86_64-server-6 >> sssd.x86_64 1.8.0-32.el6 @rhel-x86_64-server-6 >> sssd-client.x86_64 1.8.0-32.el6 @rhel-x86_64-server-6 >> >> TIA, >> Qing >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From natxo.asenjo at gmail.com Mon Nov 19 08:33:32 2012 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Mon, 19 Nov 2012 09:33:32 +0100 Subject: [Freeipa-users] IPA weirdness with Samba, Dovecot IMAP and SSHD In-Reply-To: <50A7E36F.2010701@sri.utoronto.ca> References: <50A55CD3.9010201@sri.utoronto.ca> <50A662D6.6050308@sri.utoronto.ca> <50A673CC.1010206@redhat.com> <50A7E36F.2010701@sri.utoronto.ca> Message-ID: hi, Qing On Sat, Nov 17, 2012 at 8:20 PM, Qing Chang wrote: > 2, Dovecot + IPA: it is not an IPA issue but sss cache timeout issue, I read > it's 90 min? > When a user changes his/her password, the cache usually is not updated, > hence > problem checking IMAP email with new password. > Fix/workaround: > \rm /var/lib/sss/db/cache_sri.utoronto.ca.ldb > service sssd restart > This is really heavy handed, but I can not find the sss_cache utility > any where for > RHEL 6.3! > Question: is there a way to shorten the timeout period? Where can I find > sss_cache? last week I asked a similar question :-). In the man page of sssd.conf look for 'timeoute'. There are quite a few settings you can change about the sss_cache. the sss_cache is in a package called sssd-tools now, in the next release it will be part of the sssd main package > I have great confidence in IPA now, big part of it is because of this list!! Me too. -- groet, natxo From pspacek at redhat.com Mon Nov 19 09:15:02 2012 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 19 Nov 2012 10:15:02 +0100 Subject: [Freeipa-users] DNSSEC & DNS zone "spoofing" (was: Problem adding DNS Zones) In-Reply-To: References: Message-ID: <50A9F896.3020305@redhat.com> Hello, On 11/16/2012 04:11 PM, Bret Wortman wrote: > Using FreeIPA on a private network (where it's easier to just alias our own > servers to these names than to edit config file after config file). Any idea > what I'm doing wrong here? > > # ipa dnszone-add 0.pool.ntp.org > --name-server=dns.project.net > --admin-email=root at project.net I should mention another thing: Resolution of "spoofed" zones could become broken when DNSSEC comes into the game. NTP pool is not the case now, but please remember that possibility. -- Petr^2 Spacek From grimme at atix.de Mon Nov 19 09:37:55 2012 From: grimme at atix.de (Marc Grimme) Date: Mon, 19 Nov 2012 10:37:55 +0100 Subject: [Freeipa-users] Problem with password reset on ubuntu 12.04 (lightdm) Message-ID: <50A9FDF3.2030408@atix.de> Hello all, I have problems resetting the user passwords of my IPA Server with Ubuntu 12.04 clients and lightdm. When a user password expires the users are requested to change their password (in the login screen). They'll type their old password and then repeat it as part of the change process. Nevertheless - although the password matches - they are not issued to input their new password but get the error message that this action could not be performed (Password change failed. Server message..). The sssd logs show the following. (Mon Nov 19 10:33:18 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): dbus conn: 8C8E50 (Mon Nov 19 10:33:18 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): Dispatching. (Mon Nov 19 10:33:18 2012) [sssd[be[gallien.atix]]] [sbus_message_handler] (0x4000): Received SBUS method [ping] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): dbus conn: 8ED0A0 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): Dispatching. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [be_get_account_info] (0x0100): Got request for [3][1][name=tuser] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_initgr_send] (0x4000): Retrieving info for initgroups call (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_initgr_next_base] (0x0400): Searching for users with base [cn=accounts,dc=cl,dc=atix] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(uid=tuser)(objectclass=posixAccount))][cn=accounts,dc=cl,dc=atix]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uid] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userPassword] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uidNumber] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gidNumber] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gecos] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [homeDirectory] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginShell] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbPrincipalName] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberOf] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [nsUniqueId] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [modifyTimestamp] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [entryUSN] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowLastChange] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowMin] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowMax] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowWarning] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowInactive] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowExpire] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowFlag] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbLastPwdChange] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbPasswordExpiration] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [pwdAttribute] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [authorizedService] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [accountExpires] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userAccountControl] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [nsAccountLock] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [host] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginDisabled] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginExpirationTime] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginAllowedTimeMap] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSshPubKey] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 8 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_process_result] (0x2000): Trace: sh[0x997840], connected[1], ops[0x9a7480], ldap[0x9a48d0] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_parse_entry] (0x4000): OriginalDN: [uid=tuser,cn=users,cn=accounts,dc=cl,dc=atix]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_process_result] (0x2000): Trace: sh[0x997840], connected[1], ops[0x9a7480], ldap[0x9a48d0] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_initgr_user] (0x4000): Receiving info for the user (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 0) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_initgr_user] (0x4000): Storing the user (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_save_user] (0x4000): Save user (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding original DN [uid=tuser,cn=users,cn=accounts,dc=cl,dc=atix] to attributes of [tuser]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_save_user] (0x1000): Original memberOf is not available for [tuser]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding original mod-Timestamp [20121119092148Z] to attributes of [tuser]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_save_user] (0x1000): Adding user principal [tuser at CL.ATIX] to attributes of [tuser]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowLastChange is not available for [tuser]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowMin is not available for [tuser]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowMax is not available for [tuser]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowWarning is not available for [tuser]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowInactive is not available for [tuser]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowExpire is not available for [tuser]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowFlag is not available for [tuser]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding krbLastPwdChange [20121119091442Z] to attributes of [tuser]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding krbPasswordExpiration [20121119091442Z] to attributes of [tuser]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): pwdAttribute is not available for [tuser]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): authorizedService is not available for [tuser]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): adAccountExpires is not available for [tuser]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): adUserAccountControl is not available for [tuser]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): nsAccountLock is not available for [tuser]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): authorizedHost is not available for [tuser]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): ndsLoginDisabled is not available for [tuser]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): ndsLoginExpirationTime is not available for [tuser]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): ndsLoginAllowedTimeMap is not available for [tuser]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): sshPublicKey is not available for [tuser]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_save_user] (0x0400): Storing info for user tuser (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 1) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x99b6e0 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x99b800 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x99b800 "ltdb_timeout" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x99b6e0 "ltdb_callback" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 2) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x99b6e0 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x9a8300 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x9a8300 "ltdb_timeout" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x99b6e0 "ltdb_callback" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 2) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [userPassword] from [tuser] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9a8300 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x99b800 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x99b800 "ltdb_timeout" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9a8300 "ltdb_callback" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [shadowLastChange] from [tuser] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x99b6e0 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x99b800 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x99b800 "ltdb_timeout" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x99b6e0 "ltdb_callback" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [shadowMin] from [tuser] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9a8300 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x99b800 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x99b800 "ltdb_timeout" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9a8300 "ltdb_callback" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [shadowMax] from [tuser] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x99b6e0 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x99b800 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x99b800 "ltdb_timeout" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x99b6e0 "ltdb_callback" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [shadowWarning] from [tuser] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9a8300 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x99b800 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x99b800 "ltdb_timeout" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9a8300 "ltdb_callback" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [shadowInactive] from [tuser] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x99b6e0 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x99b800 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x99b800 "ltdb_timeout" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x99b6e0 "ltdb_callback" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [shadowExpire] from [tuser] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9a8300 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x99b800 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x99b800 "ltdb_timeout" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9a8300 "ltdb_callback" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [shadowFlag] from [tuser] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x99b6e0 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x99b800 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x99b800 "ltdb_timeout" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x99b6e0 "ltdb_callback" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [pwdAttribute] from [tuser] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9a8300 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x99b800 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x99b800 "ltdb_timeout" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9a8300 "ltdb_callback" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [authorizedService] from [tuser] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x99b6e0 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x99b800 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x99b800 "ltdb_timeout" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x99b6e0 "ltdb_callback" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [adAccountExpires] from [tuser] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9a8300 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x99b800 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x99b800 "ltdb_timeout" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9a8300 "ltdb_callback" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [adUserAccountControl] from [tuser] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x99b6e0 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x99b800 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x99b800 "ltdb_timeout" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x99b6e0 "ltdb_callback" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [nsAccountLock] from [tuser] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9a8300 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x99b800 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x99b800 "ltdb_timeout" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9a8300 "ltdb_callback" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [authorizedHost] from [tuser] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x99b6e0 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x99b800 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x99b800 "ltdb_timeout" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x99b6e0 "ltdb_callback" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [ndsLoginDisabled] from [tuser] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9a8300 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x99b800 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x99b800 "ltdb_timeout" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9a8300 "ltdb_callback" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [ndsLoginExpirationTime] from [tuser] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x99b6e0 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x99b800 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x99b800 "ltdb_timeout" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x99b6e0 "ltdb_callback" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [ndsLoginAllowedTimeMap] from [tuser] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9a8300 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x99b800 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x99b800 "ltdb_timeout" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9a8300 "ltdb_callback" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [sshPublicKey] from [tuser] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x99b6e0 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x99b800 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x99b800 "ltdb_timeout" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x99b6e0 "ltdb_callback" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): commit ldb transaction (nesting: 1) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_initgr_user] (0x4000): Commit change (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): commit ldb transaction (nesting: 0) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9d8720 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x9d8840 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x9d8840 "ltdb_timeout" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9d8720 "ltdb_callback" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_initgr_user] (0x4000): Process user's groups (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_initgr_nested_send] (0x0100): User entry lacks original memberof ? (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_initgr_done] (0x4000): Initgroups done (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_id_op_destroy] (0x4000): releasing operation connection (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_id_op_done] (0x4000): releasing operation connection (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_process_result] (0x2000): Trace: sh[0x997840], connected[1], ops[(nil)], ldap[0x9a48d0] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): dbus conn: 8ED0A0 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): Dispatching. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sbus_message_handler] (0x4000): Received SBUS method [pamHandler] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [be_pam_handler] (0x0100): Got request with the following data (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): command: PAM_AUTHENTICATE (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): domain: gallien.atix (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): user: tuser (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): service: lightdm (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): tty: :0 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): ruser: (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): rhost: (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): authtok type: 1 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): authtok size: 7 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): newauthtok type: 0 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): newauthtok size: 0 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): priv: 1 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): cli_pid: 19892 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9d0710 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x9b6400 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x9b6400 "ltdb_timeout" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9d0710 "ltdb_callback" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [krb5_auth_send] (0x0100): No ccache file for user [tuser] found. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [krb5_auth_send] (0x4000): Ccache_file is [not set] and is not active and TGT is not valid. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [get_server_status] (0x1000): Status of server 'axinfra02-1.cl.atix' is 'working' (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [get_port_status] (0x1000): Port status of port 0 for server 'axinfra02-1.cl.atix' is 'working' (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 10 seconds (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [get_server_status] (0x1000): Status of server 'axinfra02-1.cl.atix' is 'working' (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [be_resolve_server_done] (0x1000): Saving the first resolved server (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [be_resolve_server_done] (0x0200): Found address for server axinfra02-1.cl.atix: [192.168.3.4] TTL 1200 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ipa_resolve_callback] (0x0400): Constructed uri 'ldap://axinfra02-1.cl.atix' (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [krb5_find_ccache_step] (0x4000): Recreating ccache file. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [19941] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [child_handler_setup] (0x2000): Signal handler set up for pid [19941] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [write_pipe_handler] (0x0400): All data has been sent! ==> /var/log/sssd/krb5_child.log <== (Mon Nov 19 10:33:27 2012) [[sssd[krb5_child[19941]]]] [main] (0x0400): krb5_child started. (Mon Nov 19 10:33:27 2012) [[sssd[krb5_child[19941]]]] [krb5_child_setup] (0x1000): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Mon Nov 19 10:33:27 2012) [[sssd[krb5_child[19941]]]] [krb5_child_setup] (0x1000): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Mon Nov 19 10:33:27 2012) [[sssd[krb5_child[19941]]]] [krb5_child_setup] (0x4000): Not using FAST. (Mon Nov 19 10:33:27 2012) [[sssd[krb5_child[19941]]]] [get_and_save_tgt] (0x0020): 660: [-1765328361][Password has expired] (Mon Nov 19 10:33:27 2012) [[sssd[krb5_child[19941]]]] [tgt_req_child] (0x0020): 919: [-1765328361][Password has expired] ==> /var/log/sssd/sssd_gallien.atix.log <== (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [read_pipe_handler] (0x0400): EOF received, client finished (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [krb5_child_done] (0x4000): child response [12][1][21]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 12, ) [Success] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [be_pam_handler_callback] (0x0100): Sending result [12][gallien.atix] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [be_pam_handler_callback] (0x0100): Sent result [12][gallien.atix] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): dbus conn: 8ED0A0 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): Dispatching. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sbus_message_handler] (0x4000): Received SBUS method [pamHandler] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [be_pam_handler] (0x0100): Got request with the following data (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): command: PAM_ACCT_MGMT (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): domain: gallien.atix (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): user: tuser (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): service: lightdm (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): tty: :0 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): ruser: (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): rhost: (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): authtok type: 0 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): authtok size: 0 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): newauthtok type: 0 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): newauthtok size: 0 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): priv: 1 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): cli_pid: 19892 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [be_target_access_permit] (0x4000): be_target_access_permit called, returning PAM_SUCCESS. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, ) [Success] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [be_pam_handler_callback] (0x0100): Sending result [0][gallien.atix] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [be_pam_handler_callback] (0x0100): Sent result [0][gallien.atix] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [child_sig_handler] (0x1000): Waiting for child [19941]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [child_sig_handler] (0x0100): child [19941] finished successfully. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sss_child_handler] (0x2000): waitpid failed [10]: No child processes (Mon Nov 19 10:33:28 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): dbus conn: 8C8E50 (Mon Nov 19 10:33:28 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): Dispatching. (Mon Nov 19 10:33:28 2012) [sssd[be[gallien.atix]]] [sbus_message_handler] (0x4000): Received SBUS method [ping] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): dbus conn: 8ED0A0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): Dispatching. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [be_get_account_info] (0x0100): Got request for [3][1][name=tuser] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_initgr_send] (0x4000): Retrieving info for initgroups call (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_initgr_next_base] (0x0400): Searching for users with base [cn=accounts,dc=cl,dc=atix] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(uid=tuser)(objectclass=posixAccount))][cn=accounts,dc=cl,dc=atix]. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uid] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userPassword] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uidNumber] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gidNumber] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gecos] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [homeDirectory] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginShell] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbPrincipalName] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberOf] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [nsUniqueId] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [modifyTimestamp] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [entryUSN] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowLastChange] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowMin] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowMax] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowWarning] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowInactive] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowExpire] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowFlag] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbLastPwdChange] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbPasswordExpiration] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [pwdAttribute] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [authorizedService] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [accountExpires] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userAccountControl] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [nsAccountLock] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [host] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginDisabled] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginExpirationTime] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginAllowedTimeMap] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSshPubKey] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 9 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_process_result] (0x2000): Trace: sh[0x997840], connected[1], ops[0x9a7480], ldap[0x9a48d0] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_parse_entry] (0x4000): OriginalDN: [uid=tuser,cn=users,cn=accounts,dc=cl,dc=atix]. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_process_result] (0x2000): Trace: sh[0x997840], connected[1], ops[0x9a7480], ldap[0x9a48d0] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_initgr_user] (0x4000): Receiving info for the user (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 0) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_initgr_user] (0x4000): Storing the user (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_save_user] (0x4000): Save user (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding original DN [uid=tuser,cn=users,cn=accounts,dc=cl,dc=atix] to attributes of [tuser]. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_save_user] (0x1000): Original memberOf is not available for [tuser]. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding original mod-Timestamp [20121119093326Z] to attributes of [tuser]. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_save_user] (0x1000): Adding user principal [tuser at CL.ATIX] to attributes of [tuser]. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowLastChange is not available for [tuser]. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowMin is not available for [tuser]. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowMax is not available for [tuser]. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowWarning is not available for [tuser]. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowInactive is not available for [tuser]. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowExpire is not available for [tuser]. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowFlag is not available for [tuser]. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding krbLastPwdChange [20121119091442Z] to attributes of [tuser]. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding krbPasswordExpiration [20121119091442Z] to attributes of [tuser]. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): pwdAttribute is not available for [tuser]. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): authorizedService is not available for [tuser]. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): adAccountExpires is not available for [tuser]. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): adUserAccountControl is not available for [tuser]. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): nsAccountLock is not available for [tuser]. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): authorizedHost is not available for [tuser]. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): ndsLoginDisabled is not available for [tuser]. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): ndsLoginExpirationTime is not available for [tuser]. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): ndsLoginAllowedTimeMap is not available for [tuser]. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): sshPublicKey is not available for [tuser]. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_save_user] (0x0400): Storing info for user tuser (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 1) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9b6300 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x9d48d0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x9d48d0 "ltdb_timeout" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9b6300 "ltdb_callback" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 2) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9d0600 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x9d0720 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x9d0720 "ltdb_timeout" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9d0600 "ltdb_callback" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 2) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [userPassword] from [tuser] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9d08b0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0xa319d0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0xa319d0 "ltdb_timeout" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9d08b0 "ltdb_callback" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [shadowLastChange] from [tuser] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9d08b0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x9d0720 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x9d0720 "ltdb_timeout" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9d08b0 "ltdb_callback" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [shadowMin] from [tuser] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9d0720 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x9d08b0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x9d08b0 "ltdb_timeout" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9d0720 "ltdb_callback" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [shadowMax] from [tuser] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9d08b0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x9d0720 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x9d0720 "ltdb_timeout" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9d08b0 "ltdb_callback" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [shadowWarning] from [tuser] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9d0720 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x9d08b0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x9d08b0 "ltdb_timeout" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9d0720 "ltdb_callback" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [shadowInactive] from [tuser] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9d08b0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x9d0720 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x9d0720 "ltdb_timeout" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9d08b0 "ltdb_callback" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [shadowExpire] from [tuser] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9d0720 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x9d08b0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x9d08b0 "ltdb_timeout" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9d0720 "ltdb_callback" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [shadowFlag] from [tuser] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9d08b0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x9d0720 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x9d0720 "ltdb_timeout" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9d08b0 "ltdb_callback" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [pwdAttribute] from [tuser] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9d0720 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x9d08b0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x9d08b0 "ltdb_timeout" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9d0720 "ltdb_callback" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [authorizedService] from [tuser] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9d08b0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x9d0720 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x9d0720 "ltdb_timeout" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9d08b0 "ltdb_callback" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [adAccountExpires] from [tuser] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9d0720 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x9d08b0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x9d08b0 "ltdb_timeout" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9d0720 "ltdb_callback" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [adUserAccountControl] from [tuser] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9d08b0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x9d0720 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x9d0720 "ltdb_timeout" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9d08b0 "ltdb_callback" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [nsAccountLock] from [tuser] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9d0720 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x9d08b0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x9d08b0 "ltdb_timeout" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9d0720 "ltdb_callback" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [authorizedHost] from [tuser] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9d08b0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x9d0720 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x9d0720 "ltdb_timeout" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9d08b0 "ltdb_callback" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [ndsLoginDisabled] from [tuser] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9d0720 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x9d08b0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x9d08b0 "ltdb_timeout" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9d0720 "ltdb_callback" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [ndsLoginExpirationTime] from [tuser] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9d08b0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x9d0720 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x9d0720 "ltdb_timeout" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9d08b0 "ltdb_callback" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [ndsLoginAllowedTimeMap] from [tuser] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9d0720 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x9d08b0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x9d08b0 "ltdb_timeout" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9d0720 "ltdb_callback" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [sshPublicKey] from [tuser] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9d08b0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x9d0720 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x9d0720 "ltdb_timeout" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9d08b0 "ltdb_callback" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): commit ldb transaction (nesting: 1) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_initgr_user] (0x4000): Commit change (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): commit ldb transaction (nesting: 0) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x99b840 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x99b960 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x99b960 "ltdb_timeout" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x99b840 "ltdb_callback" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_initgr_user] (0x4000): Process user's groups (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_initgr_nested_send] (0x0100): User entry lacks original memberof ? (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_initgr_done] (0x4000): Initgroups done (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_id_op_destroy] (0x4000): releasing operation connection (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_id_op_done] (0x4000): releasing operation connection (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_process_result] (0x2000): Trace: sh[0x997840], connected[1], ops[(nil)], ldap[0x9a48d0] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): dbus conn: 8ED0A0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): Dispatching. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sbus_message_handler] (0x4000): Received SBUS method [pamHandler] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [be_pam_handler] (0x0100): Got request with the following data (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): command: PAM_CHAUTHTOK_PRELIM (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): domain: gallien.atix (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): user: tuser (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): service: lightdm (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): tty: :0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): ruser: (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): rhost: (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): authtok type: 1 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): authtok size: 7 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): newauthtok type: 0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): newauthtok size: 0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): priv: 1 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): cli_pid: 19892 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9cfdf0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x9d8b50 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x9d8b50 "ltdb_timeout" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9cfdf0 "ltdb_callback" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [krb5_auth_send] (0x0100): No ccache file for user [tuser] found. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [krb5_auth_send] (0x4000): Ccache_file is [not set] and is not active and TGT is not valid. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [get_server_status] (0x1000): Status of server 'axinfra02-1.cl.atix' is 'working' (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [get_port_status] (0x1000): Port status of port 0 for server 'axinfra02-1.cl.atix' is 'working' (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 10 seconds (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [get_server_status] (0x1000): Status of server 'axinfra02-1.cl.atix' is 'working' (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [be_resolve_server_done] (0x1000): Saving the first resolved server (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [be_resolve_server_done] (0x0200): Found address for server axinfra02-1.cl.atix: [192.168.3.4] TTL 1200 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [krb5_find_ccache_step] (0x4000): Recreating ccache file. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [19942] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [child_handler_setup] (0x2000): Signal handler set up for pid [19942] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [write_pipe_handler] (0x0400): All data has been sent! ==> /var/log/sssd/krb5_child.log <== (Mon Nov 19 10:33:32 2012) [[sssd[krb5_child[19942]]]] [main] (0x0400): krb5_child started. (Mon Nov 19 10:33:32 2012) [[sssd[krb5_child[19942]]]] [krb5_child_setup] (0x1000): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Mon Nov 19 10:33:32 2012) [[sssd[krb5_child[19942]]]] [krb5_child_setup] (0x1000): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Mon Nov 19 10:33:32 2012) [[sssd[krb5_child[19942]]]] [krb5_child_setup] (0x4000): Not using FAST. (Mon Nov 19 10:33:33 2012) [[sssd[krb5_child[19942]]]] [changepw_child] (0x4000): Initial authentication for change password operation successfull. ==> /var/log/sssd/sssd_gallien.atix.log <== (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [read_pipe_handler] (0x0400): EOF received, client finished (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, ) [Success] (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [be_pam_handler_callback] (0x0100): Sending result [0][gallien.atix] (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [be_pam_handler_callback] (0x0100): Sent result [0][gallien.atix] (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): dbus conn: 8ED0A0 (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): Dispatching. (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [sbus_message_handler] (0x4000): Received SBUS method [pamHandler] (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [be_pam_handler] (0x0100): Got request with the following data (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): command: PAM_CHAUTHTOK (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): domain: gallien.atix (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): user: tuser (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): service: lightdm (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): tty: :0 (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): ruser: (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): rhost: (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): authtok type: 1 (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): authtok size: 7 (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): newauthtok type: 1 (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): newauthtok size: 0 (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): priv: 1 (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): cli_pid: 19892 (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9d8720 (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x9d9090 (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x9d9090 "ltdb_timeout" (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9d8720 "ltdb_callback" (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [krb5_auth_send] (0x0100): No ccache file for user [tuser] found. (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [krb5_auth_send] (0x4000): Ccache_file is [not set] and is not active and TGT is not valid. (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [get_server_status] (0x1000): Status of server 'axinfra02-1.cl.atix' is 'working' (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [get_port_status] (0x1000): Port status of port 0 for server 'axinfra02-1.cl.atix' is 'working' (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 10 seconds (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [get_server_status] (0x1000): Status of server 'axinfra02-1.cl.atix' is 'working' (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [be_resolve_server_done] (0x1000): Saving the first resolved server (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [be_resolve_server_done] (0x0200): Found address for server axinfra02-1.cl.atix: [192.168.3.4] TTL 1200 (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [krb5_find_ccache_step] (0x4000): Recreating ccache file. (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [19943] (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [child_handler_setup] (0x2000): Signal handler set up for pid [19943] (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [write_pipe_handler] (0x0400): All data has been sent! (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [child_sig_handler] (0x1000): Waiting for child [19943]. (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [child_sig_handler] (0x0020): waitpid did not found a child with changed status. (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [child_sig_handler] (0x1000): Waiting for child [19942]. (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [child_sig_handler] (0x0100): child [19942] finished successfully. ==> /var/log/sssd/krb5_child.log <== (Mon Nov 19 10:33:33 2012) [[sssd[krb5_child[19943]]]] [main] (0x0400): krb5_child started. (Mon Nov 19 10:33:33 2012) [[sssd[krb5_child[19943]]]] [krb5_child_setup] (0x1000): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Mon Nov 19 10:33:33 2012) [[sssd[krb5_child[19943]]]] [krb5_child_setup] (0x1000): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Mon Nov 19 10:33:33 2012) [[sssd[krb5_child[19943]]]] [krb5_child_setup] (0x4000): Not using FAST. (Mon Nov 19 10:33:33 2012) [[sssd[krb5_child[19943]]]] [changepw_child] (0x0020): krb5_change_password failed [2][Server error]. (Mon Nov 19 10:33:33 2012) [[sssd[krb5_child[19943]]]] [changepw_child] (0x0020): krb5_change_password failed [2][Password not changed.]. ==> /var/log/sssd/sssd_gallien.atix.log <== (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [read_pipe_handler] (0x0400): EOF received, client finished (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [krb5_child_done] (0x4000): child response [20][1][27]. (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [krb5_child_done] (0x4000): child response [20][6][29]. (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 20, ) [Success] (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [be_pam_handler_callback] (0x0100): Sending result [20][gallien.atix] (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [be_pam_handler_callback] (0x0100): Sent result [20][gallien.atix] (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [child_sig_handler] (0x1000): Waiting for child [19943]. (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [child_sig_handler] (0x0100): child [19943] finished successfully. (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [sss_child_handler] (0x2000): waitpid failed [10]: No child processes (Mon Nov 19 10:33:38 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): dbus conn: 8C8E50 (Mon Nov 19 10:33:38 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): Dispatching. (Mon Nov 19 10:33:38 2012) [sssd[be[gallien.atix]]] [sbus_message_handler] (0x4000): Received SBUS method [ping] (Mon Nov 19 10:33:48 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): dbus conn: 8C8E50 (Mon Nov 19 10:33:48 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): Dispatching. (Mon Nov 19 10:33:48 2012) [sssd[be[gallien.atix]]] [sbus_message_handler] (0x4000): Received SBUS method [ping] (Mon Nov 19 10:33:58 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): dbus conn: 8C8E50 (Mon Nov 19 10:33:58 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): Dispatching. (Mon Nov 19 10:33:58 2012) [sssd[be[gallien.atix]]] [sbus_message_handler] (0x4000): Received SBUS method [ping] (Mon Nov 19 10:34:08 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): dbus conn: 8C8E50 (Mon Nov 19 10:34:08 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): Dispatching. (Mon Nov 19 10:34:08 2012) [sssd[be[gallien.atix]]] [sbus_message_handler] (0x4000): Received SBUS method [ping] (Mon Nov 19 10:34:18 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): dbus conn: 8C8E50 (Mon Nov 19 10:34:18 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): Dispatching. (Mon Nov 19 10:34:18 2012) [sssd[be[gallien.atix]]] [sbus_message_handler] (0x4000): Received SBUS method [ping] (Mon Nov 19 10:34:28 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): dbus conn: 8C8E50 (Mon Nov 19 10:34:28 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): Dispatching. (Mon Nov 19 10:34:28 2012) [sssd[be[gallien.atix]]] [sbus_message_handler] (0x4000): Received SBUS method [ping] Any ideas? Thanks Marc. -- Marc Grimme E-Mail: grimme( at )atix.de ATIX Informationstechnologie und Consulting AG | Einsteinstrasse 10 | 85716 Unterschleissheim | www.atix.de | www.comoonics.org Registergericht: Amtsgericht Muenchen, Registernummer: HRB 168930, USt.-Id.: DE209485962 | Vorstand: Marc Grimme, Mark Hlawatschek, Thomas Merz (Vors.) | Vorsitzender des Aufsichtsrats: Dr. Martin Buss From bret.wortman at damascusgrp.com Mon Nov 19 15:22:04 2012 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Mon, 19 Nov 2012 10:22:04 -0500 Subject: [Freeipa-users] IPA'd users not going through .bashrc Message-ID: I've noticed that my users who are provided identities through IPA aren't having their .bashrc and other login profile files run when they log in. I tried googling this issue but haven't found anything. Has anyone else encountered this? Puppet 3.0.1 from puppetlabs' repos on F17. -- Bret Wortman The Damascus Group Fairfax, VA http://bretwortman.com/ http://twitter.com/BretWortman -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Mon Nov 19 15:30:14 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 19 Nov 2012 10:30:14 -0500 Subject: [Freeipa-users] FreeIPA on a dual boot system In-Reply-To: References: Message-ID: <50AA5086.3080109@redhat.com> ?? ? wrote: > Hi fellow FreeIPA users! > > I just got my FreeIPA set up perfectly and I was wondering if it's possible to set it up in the other OS in a dual boot configuration. Since I'm still on the same computer (therefore, the same MAC address), ipa-client-install fails saying that I'm already joined to the domain. > > Is there anything I can do allow the dual booted OS to join? Do I need to change my network configuration? It isn't enforcing it on a MAC level, but a hostname level. It should be possible though I'm not sure it's a great idea to do so. You'd have effectively two machines claiming to be one. I haven't tried this procedure, but I suspect this will work. I'll refer to the different boot states as A and B. 1. Configure A as an ipa client 2. Boot to B 3. On the IPA server run: ipa host-disable A 4. Configure B as an ipa client 5. Copy the host keytab on B from /etc/krb5.conf to the same location on A 6. Boot to A to confirm it works There is also the matter of the SSL certificate for A and B. It is not currently being used, so it should be safe to stop tracking it on one or both of them: # ipa-getcert list # ipa-getcert stop-tracking -i From a support standpoint you'll likely be much better off having separate hostnames for your different boot images. rob From bret.wortman at damascusgrp.com Mon Nov 19 15:38:10 2012 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Mon, 19 Nov 2012 10:38:10 -0500 Subject: [Freeipa-users] IPA'd users not going through .bashrc In-Reply-To: References: Message-ID: Never mind. Had the default shell set to /bin/sh. On Mon, Nov 19, 2012 at 10:22 AM, Bret Wortman wrote: > I've noticed that my users who are provided identities through IPA aren't > having their .bashrc and other login profile files run when they log in. I > tried googling this issue but haven't found anything. Has anyone else > encountered this? > > Puppet 3.0.1 from puppetlabs' repos on F17. > > > -- > Bret Wortman > The Damascus Group > Fairfax, VA > http://bretwortman.com/ > http://twitter.com/BretWortman > > -- Bret Wortman The Damascus Group Fairfax, VA http://bretwortman.com/ http://twitter.com/BretWortman -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Mon Nov 19 15:57:04 2012 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 19 Nov 2012 10:57:04 -0500 Subject: [Freeipa-users] Problem with password reset on ubuntu 12.04 (lightdm) In-Reply-To: <50A9FDF3.2030408@atix.de> References: <50A9FDF3.2030408@atix.de> Message-ID: <50AA56D0.3020205@redhat.com> On 11/19/2012 04:37 AM, Marc Grimme wrote: > (Mon Nov 19 10:33:33 2012) [[sssd[krb5_child[19943]]]] > [krb5_child_setup] (0x4000): Not using FAST. > (Mon Nov 19 10:33:33 2012) [[sssd[krb5_child[19943]]]] [changepw_child] > (0x0020): krb5_change_password failed [2][Server error]. > (Mon Nov 19 10:33:33 2012) [[sssd[krb5_child[19943]]]] [changepw_child] > (0x0020): krb5_change_password failed [2][Password not changed.]. Have you looked at the server Kerberos log? Do you see an attempt there? If not there might be a problem accessing kadmin process on the server. Might be a firewall issue then. But let us start with the server side. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From qchang at sri.utoronto.ca Mon Nov 19 16:29:25 2012 From: qchang at sri.utoronto.ca (Qing Chang) Date: Mon, 19 Nov 2012 11:29:25 -0500 Subject: [Freeipa-users] IPA weirdness with Samba, Dovecot IMAP and SSHD In-Reply-To: References: <50A55CD3.9010201@sri.utoronto.ca> <50A662D6.6050308@sri.utoronto.ca> <50A673CC.1010206@redhat.com> <50A7E36F.2010701@sri.utoronto.ca> Message-ID: <50AA5E65.6030303@sri.utoronto.ca> On 19/11/2012 3:33 AM, Natxo Asenjo wrote: > hi, Qing > > On Sat, Nov 17, 2012 at 8:20 PM, Qing Chang wrote: > >> 2, Dovecot + IPA: it is not an IPA issue but sss cache timeout issue, I read >> it's 90 min? >> When a user changes his/her password, the cache usually is not updated, >> hence >> problem checking IMAP email with new password. >> Fix/workaround: >> \rm /var/lib/sss/db/cache_sri.utoronto.ca.ldb >> service sssd restart >> This is really heavy handed, but I can not find the sss_cache utility >> any where for >> RHEL 6.3! >> Question: is there a way to shorten the timeout period? Where can I find >> sss_cache? > last week I asked a similar question :-). In the man page of sssd.conf > look for 'timeoute'. There are quite a few settings you can change > about the sss_cache. > > the sss_cache is in a package called sssd-tools now, in the next > release it will be part of the sssd main package > >> I have great confidence in IPA now, big part of it is because of this list!! > Me too. > thanks, Naxto, I'll do some research on it. Qing From grimme at atix.de Mon Nov 19 16:31:34 2012 From: grimme at atix.de (Marc Grimme) Date: Mon, 19 Nov 2012 17:31:34 +0100 Subject: [Freeipa-users] Problem with password reset on ubuntu 12.04 (lightdm) In-Reply-To: <50AA56D0.3020205@redhat.com> References: <50A9FDF3.2030408@atix.de> <50AA56D0.3020205@redhat.com> Message-ID: <50AA5EE6.7090605@atix.de> This is what the kerberos (kadmin.log) shows on the relevant IPA server. Nov 19 17:29:54 axinfra02-1.cl.atix kadmind[18851](Error): password quality module empty rejected password for tuser at CL.ATIX: Empty passwords are not allowed Nov 19 17:29:54 axinfra02-1.cl.atix kadmind[18851](Notice): chpw request from 192.168.3.231 for tuser at CL.ATIX: Password is too short I could only enter the old password the new one was never queried. Any idea? Thanks Marc. Am 19.11.2012 16:57, schrieb Dmitri Pal: > On 11/19/2012 04:37 AM, Marc Grimme wrote: >> (Mon Nov 19 10:33:33 2012) [[sssd[krb5_child[19943]]]] >> [krb5_child_setup] (0x4000): Not using FAST. >> (Mon Nov 19 10:33:33 2012) [[sssd[krb5_child[19943]]]] [changepw_child] >> (0x0020): krb5_change_password failed [2][Server error]. >> (Mon Nov 19 10:33:33 2012) [[sssd[krb5_child[19943]]]] [changepw_child] >> (0x0020): krb5_change_password failed [2][Password not changed.]. > Have you looked at the server Kerberos log? > Do you see an attempt there? > If not there might be a problem accessing kadmin process on the server. > Might be a firewall issue then. > But let us start with the server side. > > -- Marc Grimme Tel: +49 (0)89 452 35 38-140 Fax: +49 (0)89 452 35 38-290 E-Mail: grimme at atix.de ATIX Informationstechnologie und Consulting AG | Einsteinstrasse 10 | 85716 Unterschleissheim | www.atix.de | www.comoonics.org Registergericht: Amtsgericht Muenchen, Registernummer: HRB 168930, USt.-Id.: DE209485962 | Vorstand: Marc Grimme, Mark Hlawatschek, Thomas Merz (Vors.) | Vorsitzender des Aufsichtsrats: Dr. Martin Buss From dpal at redhat.com Mon Nov 19 17:06:54 2012 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 19 Nov 2012 12:06:54 -0500 Subject: [Freeipa-users] IPA weirdness with Samba, Dovecot IMAP and SSHD In-Reply-To: <50A7E36F.2010701@sri.utoronto.ca> References: <50A55CD3.9010201@sri.utoronto.ca> <50A662D6.6050308@sri.utoronto.ca> <50A673CC.1010206@redhat.com> <50A7E36F.2010701@sri.utoronto.ca> Message-ID: <50AA672E.4040303@redhat.com> On 11/17/2012 02:20 PM, Qing Chang wrote: > > On 16/11/2012 12:11 PM, Dmitri Pal wrote: >> On 11/16/2012 10:59 AM, Qing Chang wrote: >>> just migrated all my user from OpenLDAP and MIT Kerberos to IPA. >>> >>> Out of more than 400 users, there are around 10 that have problem >>> accessing Samba or Dovecot IMAP or ssh. >>> >>> They never have problem login to ipa/ipa/ui/login.html. >>> >>> For Dovecot IMAP following error is generated: >>> ===== >>> Nov 16 10:15:03 dovecot2 auth: pam_unix(dovecot:auth): >>> authentication failure; logname= uid=0 euid=0 tty=dovecot >>> ruser=uesrid rhost=IP user=userid >>> Nov 16 10:15:03 dovecot2 auth: pam_sss(dovecot:auth): authentication >>> failure; logname= uid=0 euid=0 tty=dovecot ruser=userid rhost=IP >>> user=useris >>> Nov 16 10:15:03 dovecot2 auth: pam_sss(dovecot:auth): received for >>> user userid: 4 (System error) >> >> Hello Qing >> >> There are several things to do: >> 1) Compare entries of the users that login with no problems and users >> that have problems. There might be some attributes different >> (absent/present). That might give a hint of what might be wrong. We >> have seen some issues in this area related to Samba. >> 2) Can you please enable the higher debug_level in SSSD and provide >> the SSSD logs + sssd.conf that would help to see what is going on >> with the user that is failing. >> 3) Also if you can describe your environment of how all the parts >> work together and what are the workflows in which you see the >> problem/issue. I am personally not familiar with Dovecot in details >> so I assume that Dovecot is configured to use PAM for the >> authentication and the snippet above is from that authentication. Is >> this the correct assumption? >> >> Thanks >> Dmitri >> > Dmitri, > > appreciate your prompt response. I having being on this thing for past > day and a half, > I think I now understand the issues and found fix/workaround for them. > > 1, Samba + IPA: when this attribute sambaPwdLastSet is set to 0, a > samba mapping > request will cause samba to CLEAR sambaLMPassword and sambaNTPassword > attributes, yes, not set password to something, but the attributes > are wiped out. > This may only apply to my situation because I HAVE to use samba > 3.0.23d, a > ancient version!! Originally when I migrated users from OpenLDAP, > sambaPwdLastSet > has a none zero value for every account. As users migrated their > password properly, > the value was not touch. But, if someone's password has to be > reset (too short, forgotten) > by us admin user using the UI, sambaPwdLastSet is set to 0. This > explains why the > problem is not wide spread. > Fix/workaround: change sambaPwdLastSet to a sensible value after a > password > reset by admin. > Question: is this a designed behavior for IPA? Or does > migrate-mode or not make difference? I think you see this: https://fedorahosted.org/freeipa/ticket/3206 This is exactly the ticket I referred to when said: " We have seen some issues in this area related to Samba." It is planned for next big release code name "Pilsner barrel". We will start working on this release early next year. > > 2, Dovecot + IPA: it is not an IPA issue but sss cache timeout issue, > I read it's 90 min? > When a user changes his/her password, the cache usually is not > updated, hence > problem checking IMAP email with new password. > Fix/workaround: > \rm /var/lib/sss/db/cache_sri.utoronto.ca.ldb > service sssd restart > This is really heavy handed, but I can not find the sss_cache > utility any where for > RHEL 6.3! > Question: is there a way to shorten the timeout period? Where can > I find > sss_cache? > > I have great confidence in IPA now, big part of it is because of this > list!! > > Many thanks, > > Qing >>> ===== >>> >>> For Samba, it appears that a mapping request never gets to Samba >>> server because >>> nothing is logged for a problematic user ID although I have turned >>> on excessive logging. >>> >>> What is really frustrating is that there is no pattern to be found, >>> even my fellow >>> Sysadmin's ID is also in trouble. >>> >>> Also, in his case, he has no problem with Dovecot. For another user >>> ID Samba works >>> but not Dovecot. It looks to me there might be some problem with >>> sssd on the >>> different servers? >>> >>> BTW, for at least one user, creating a brand new account for samba >>> did not work either, >>> while the trick worked for another user:-(. >>> >>> Please shed some light on this. I don't mind opening a case with >>> RedHat support >>> if necessary. >>> >>> Red Hat Enterprise Linux Server release 6.3 (Santiago) >>> ipa-server.x86_64 2.2.0-16.el6 >>> @rhel-x86_64-server-6 >>> sssd.x86_64 1.8.0-32.el6 >>> @rhel-x86_64-server-6 >>> sssd-client.x86_64 1.8.0-32.el6 >>> @rhel-x86_64-server-6 >>> >>> TIA, >>> Qing >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager for IdM portfolio >> Red Hat Inc. >> >> >> ------------------------------- >> Looking to carve out IT costs? >> www.redhat.com/carveoutcosts/ >> >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Mon Nov 19 17:12:08 2012 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 19 Nov 2012 12:12:08 -0500 Subject: [Freeipa-users] Problem with password reset on ubuntu 12.04 (lightdm) In-Reply-To: <50AA5EE6.7090605@atix.de> References: <50A9FDF3.2030408@atix.de> <50AA56D0.3020205@redhat.com> <50AA5EE6.7090605@atix.de> Message-ID: <50AA6868.9060100@redhat.com> On 11/19/2012 11:31 AM, Marc Grimme wrote: > This is what the kerberos (kadmin.log) shows on the relevant IPA server. > Nov 19 17:29:54 axinfra02-1.cl.atix kadmind[18851](Error): password > quality module empty rejected password for tuser at CL.ATIX: Empty > passwords are not allowed > Nov 19 17:29:54 axinfra02-1.cl.atix kadmind[18851](Notice): chpw request > from 192.168.3.231 for tuser at CL.ATIX: Password is too short > > I could only enter the old password the new one was never queried. > Any idea? Please cross post to the sssd-users. It seems that the server receives an empty password. I do not know if one can enable a trace that would show what password is actually sent. You might need to have a special build of SSSD to see what SSSD is actually sending. Anyways ask on SSSD list, you might get some good hints. Thanks Dmitri > Thanks > Marc. > > Am 19.11.2012 16:57, schrieb Dmitri Pal: >> On 11/19/2012 04:37 AM, Marc Grimme wrote: >>> (Mon Nov 19 10:33:33 2012) [[sssd[krb5_child[19943]]]] >>> [krb5_child_setup] (0x4000): Not using FAST. >>> (Mon Nov 19 10:33:33 2012) [[sssd[krb5_child[19943]]]] [changepw_child] >>> (0x0020): krb5_change_password failed [2][Server error]. >>> (Mon Nov 19 10:33:33 2012) [[sssd[krb5_child[19943]]]] [changepw_child] >>> (0x0020): krb5_change_password failed [2][Password not changed.]. >> Have you looked at the server Kerberos log? >> Do you see an attempt there? >> If not there might be a problem accessing kadmin process on the server. >> Might be a firewall issue then. >> But let us start with the server side. >> >> > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From grimme at atix.de Mon Nov 19 20:18:51 2012 From: grimme at atix.de (Marc Grimme) Date: Mon, 19 Nov 2012 21:18:51 +0100 Subject: [Freeipa-users] Problem with password reset on ubuntu 12.04 (lightdm) In-Reply-To: <50AA6868.9060100@redhat.com> References: <50A9FDF3.2030408@atix.de> <50AA56D0.3020205@redhat.com> <50AA5EE6.7090605@atix.de> <50AA6868.9060100@redhat.com> Message-ID: <50AA942B.1030903@atix.de> Hello sssd list. My problem is that a with sssd configured ubuntu 12.04 client cannot change a password that has to be set a new for IPA. As I've learned from the IPA list there are indications that sssd might be the problem in this case. With logging=10 in sssd.conf I see the following logs by sssd: When a user password expires the users are requested to change their password (in the login screen). They'll type their old password and then repeat it as part of the change process. Nevertheless - although the password matches - they are not issued to input their new password but get the error message that this action could not be performed (Password change failed. Server message..). The sssd logs show the following. (Mon Nov 19 10:33:18 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): dbus conn: 8C8E50 (Mon Nov 19 10:33:18 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): Dispatching. (Mon Nov 19 10:33:18 2012) [sssd[be[gallien.atix]]] [sbus_message_handler] (0x4000): Received SBUS method [ping] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): dbus conn: 8ED0A0 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): Dispatching. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [be_get_account_info] (0x0100): Got request for [3][1][name=tuser] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_initgr_send] (0x4000): Retrieving info for initgroups call (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_initgr_next_base] (0x0400): Searching for users with base [cn=accounts,dc=cl,dc=atix] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(uid=tuser)(objectclass=posixAccount))][cn=accounts,dc=cl,dc=atix]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uid] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userPassword] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uidNumber] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gidNumber] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gecos] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [homeDirectory] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginShell] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbPrincipalName] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberOf] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [nsUniqueId] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [modifyTimestamp] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [entryUSN] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowLastChange] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowMin] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowMax] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowWarning] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowInactive] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowExpire] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowFlag] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbLastPwdChange] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbPasswordExpiration] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [pwdAttribute] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [authorizedService] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [accountExpires] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userAccountControl] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [nsAccountLock] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [host] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginDisabled] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginExpirationTime] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginAllowedTimeMap] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSshPubKey] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 8 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_process_result] (0x2000): Trace: sh[0x997840], connected[1], ops[0x9a7480], ldap[0x9a48d0] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_parse_entry] (0x4000): OriginalDN: [uid=tuser,cn=users,cn=accounts,dc=cl,dc=atix]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_process_result] (0x2000): Trace: sh[0x997840], connected[1], ops[0x9a7480], ldap[0x9a48d0] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_initgr_user] (0x4000): Receiving info for the user (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 0) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_initgr_user] (0x4000): Storing the user (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_save_user] (0x4000): Save user (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding original DN [uid=tuser,cn=users,cn=accounts,dc=cl,dc=atix] to attributes of [tuser]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_save_user] (0x1000): Original memberOf is not available for [tuser]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding original mod-Timestamp [20121119092148Z] to attributes of [tuser]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_save_user] (0x1000): Adding user principal [tuser at CL.ATIX] to attributes of [tuser]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowLastChange is not available for [tuser]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowMin is not available for [tuser]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowMax is not available for [tuser]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowWarning is not available for [tuser]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowInactive is not available for [tuser]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowExpire is not available for [tuser]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowFlag is not available for [tuser]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding krbLastPwdChange [20121119091442Z] to attributes of [tuser]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding krbPasswordExpiration [20121119091442Z] to attributes of [tuser]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): pwdAttribute is not available for [tuser]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): authorizedService is not available for [tuser]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): adAccountExpires is not available for [tuser]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): adUserAccountControl is not available for [tuser]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): nsAccountLock is not available for [tuser]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): authorizedHost is not available for [tuser]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): ndsLoginDisabled is not available for [tuser]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): ndsLoginExpirationTime is not available for [tuser]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): ndsLoginAllowedTimeMap is not available for [tuser]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): sshPublicKey is not available for [tuser]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_save_user] (0x0400): Storing info for user tuser (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 1) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x99b6e0 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x99b800 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x99b800 "ltdb_timeout" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x99b6e0 "ltdb_callback" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 2) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x99b6e0 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x9a8300 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x9a8300 "ltdb_timeout" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x99b6e0 "ltdb_callback" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 2) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [userPassword] from [tuser] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9a8300 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x99b800 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x99b800 "ltdb_timeout" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9a8300 "ltdb_callback" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [shadowLastChange] from [tuser] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x99b6e0 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x99b800 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x99b800 "ltdb_timeout" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x99b6e0 "ltdb_callback" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [shadowMin] from [tuser] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9a8300 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x99b800 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x99b800 "ltdb_timeout" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9a8300 "ltdb_callback" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [shadowMax] from [tuser] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x99b6e0 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x99b800 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x99b800 "ltdb_timeout" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x99b6e0 "ltdb_callback" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [shadowWarning] from [tuser] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9a8300 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x99b800 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x99b800 "ltdb_timeout" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9a8300 "ltdb_callback" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [shadowInactive] from [tuser] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x99b6e0 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x99b800 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x99b800 "ltdb_timeout" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x99b6e0 "ltdb_callback" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [shadowExpire] from [tuser] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9a8300 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x99b800 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x99b800 "ltdb_timeout" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9a8300 "ltdb_callback" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [shadowFlag] from [tuser] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x99b6e0 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x99b800 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x99b800 "ltdb_timeout" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x99b6e0 "ltdb_callback" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [pwdAttribute] from [tuser] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9a8300 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x99b800 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x99b800 "ltdb_timeout" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9a8300 "ltdb_callback" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [authorizedService] from [tuser] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x99b6e0 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x99b800 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x99b800 "ltdb_timeout" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x99b6e0 "ltdb_callback" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [adAccountExpires] from [tuser] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9a8300 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x99b800 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x99b800 "ltdb_timeout" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9a8300 "ltdb_callback" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [adUserAccountControl] from [tuser] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x99b6e0 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x99b800 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x99b800 "ltdb_timeout" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x99b6e0 "ltdb_callback" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [nsAccountLock] from [tuser] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9a8300 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x99b800 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x99b800 "ltdb_timeout" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9a8300 "ltdb_callback" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [authorizedHost] from [tuser] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x99b6e0 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x99b800 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x99b800 "ltdb_timeout" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x99b6e0 "ltdb_callback" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [ndsLoginDisabled] from [tuser] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9a8300 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x99b800 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x99b800 "ltdb_timeout" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9a8300 "ltdb_callback" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [ndsLoginExpirationTime] from [tuser] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x99b6e0 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x99b800 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x99b800 "ltdb_timeout" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x99b6e0 "ltdb_callback" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [ndsLoginAllowedTimeMap] from [tuser] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9a8300 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x99b800 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x99b800 "ltdb_timeout" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9a8300 "ltdb_callback" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [sshPublicKey] from [tuser] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x99b6e0 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x99b800 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x99b800 "ltdb_timeout" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x99b6e0 "ltdb_callback" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): commit ldb transaction (nesting: 1) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_initgr_user] (0x4000): Commit change (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): commit ldb transaction (nesting: 0) (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9d8720 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x9d8840 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x9d8840 "ltdb_timeout" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9d8720 "ltdb_callback" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_initgr_user] (0x4000): Process user's groups (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_initgr_nested_send] (0x0100): User entry lacks original memberof ? (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_get_initgr_done] (0x4000): Initgroups done (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_id_op_destroy] (0x4000): releasing operation connection (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_id_op_done] (0x4000): releasing operation connection (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_process_result] (0x2000): Trace: sh[0x997840], connected[1], ops[(nil)], ldap[0x9a48d0] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): dbus conn: 8ED0A0 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): Dispatching. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sbus_message_handler] (0x4000): Received SBUS method [pamHandler] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [be_pam_handler] (0x0100): Got request with the following data (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): command: PAM_AUTHENTICATE (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): domain: gallien.atix (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): user: tuser (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): service: lightdm (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): tty: :0 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): ruser: (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): rhost: (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): authtok type: 1 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): authtok size: 7 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): newauthtok type: 0 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): newauthtok size: 0 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): priv: 1 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): cli_pid: 19892 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9d0710 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x9b6400 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x9b6400 "ltdb_timeout" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9d0710 "ltdb_callback" (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [krb5_auth_send] (0x0100): No ccache file for user [tuser] found. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [krb5_auth_send] (0x4000): Ccache_file is [not set] and is not active and TGT is not valid. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [get_server_status] (0x1000): Status of server 'axinfra02-1.cl.atix' is 'working' (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [get_port_status] (0x1000): Port status of port 0 for server 'axinfra02-1.cl.atix' is 'working' (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 10 seconds (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [get_server_status] (0x1000): Status of server 'axinfra02-1.cl.atix' is 'working' (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [be_resolve_server_done] (0x1000): Saving the first resolved server (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [be_resolve_server_done] (0x0200): Found address for server axinfra02-1.cl.atix: [192.168.3.4] TTL 1200 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [ipa_resolve_callback] (0x0400): Constructed uri 'ldap://axinfra02-1.cl.atix' (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [krb5_find_ccache_step] (0x4000): Recreating ccache file. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [19941] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [child_handler_setup] (0x2000): Signal handler set up for pid [19941] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [write_pipe_handler] (0x0400): All data has been sent! ==> /var/log/sssd/krb5_child.log <== (Mon Nov 19 10:33:27 2012) [[sssd[krb5_child[19941]]]] [main] (0x0400): krb5_child started. (Mon Nov 19 10:33:27 2012) [[sssd[krb5_child[19941]]]] [krb5_child_setup] (0x1000): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Mon Nov 19 10:33:27 2012) [[sssd[krb5_child[19941]]]] [krb5_child_setup] (0x1000): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Mon Nov 19 10:33:27 2012) [[sssd[krb5_child[19941]]]] [krb5_child_setup] (0x4000): Not using FAST. (Mon Nov 19 10:33:27 2012) [[sssd[krb5_child[19941]]]] [get_and_save_tgt] (0x0020): 660: [-1765328361][Password has expired] (Mon Nov 19 10:33:27 2012) [[sssd[krb5_child[19941]]]] [tgt_req_child] (0x0020): 919: [-1765328361][Password has expired] ==> /var/log/sssd/sssd_gallien.atix.log <== (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [read_pipe_handler] (0x0400): EOF received, client finished (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [krb5_child_done] (0x4000): child response [12][1][21]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 12, ) [Success] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [be_pam_handler_callback] (0x0100): Sending result [12][gallien.atix] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [be_pam_handler_callback] (0x0100): Sent result [12][gallien.atix] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): dbus conn: 8ED0A0 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): Dispatching. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sbus_message_handler] (0x4000): Received SBUS method [pamHandler] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [be_pam_handler] (0x0100): Got request with the following data (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): command: PAM_ACCT_MGMT (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): domain: gallien.atix (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): user: tuser (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): service: lightdm (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): tty: :0 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): ruser: (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): rhost: (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): authtok type: 0 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): authtok size: 0 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): newauthtok type: 0 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): newauthtok size: 0 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): priv: 1 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): cli_pid: 19892 (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [be_target_access_permit] (0x4000): be_target_access_permit called, returning PAM_SUCCESS. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, ) [Success] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [be_pam_handler_callback] (0x0100): Sending result [0][gallien.atix] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [be_pam_handler_callback] (0x0100): Sent result [0][gallien.atix] (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [child_sig_handler] (0x1000): Waiting for child [19941]. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [child_sig_handler] (0x0100): child [19941] finished successfully. (Mon Nov 19 10:33:27 2012) [sssd[be[gallien.atix]]] [sss_child_handler] (0x2000): waitpid failed [10]: No child processes (Mon Nov 19 10:33:28 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): dbus conn: 8C8E50 (Mon Nov 19 10:33:28 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): Dispatching. (Mon Nov 19 10:33:28 2012) [sssd[be[gallien.atix]]] [sbus_message_handler] (0x4000): Received SBUS method [ping] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): dbus conn: 8ED0A0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): Dispatching. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [be_get_account_info] (0x0100): Got request for [3][1][name=tuser] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_initgr_send] (0x4000): Retrieving info for initgroups call (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_initgr_next_base] (0x0400): Searching for users with base [cn=accounts,dc=cl,dc=atix] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(uid=tuser)(objectclass=posixAccount))][cn=accounts,dc=cl,dc=atix]. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uid] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userPassword] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uidNumber] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gidNumber] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gecos] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [homeDirectory] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginShell] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbPrincipalName] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberOf] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [nsUniqueId] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [modifyTimestamp] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [entryUSN] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowLastChange] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowMin] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowMax] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowWarning] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowInactive] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowExpire] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowFlag] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbLastPwdChange] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbPasswordExpiration] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [pwdAttribute] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [authorizedService] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [accountExpires] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userAccountControl] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [nsAccountLock] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [host] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginDisabled] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginExpirationTime] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginAllowedTimeMap] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSshPubKey] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 9 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_process_result] (0x2000): Trace: sh[0x997840], connected[1], ops[0x9a7480], ldap[0x9a48d0] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_parse_entry] (0x4000): OriginalDN: [uid=tuser,cn=users,cn=accounts,dc=cl,dc=atix]. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_process_result] (0x2000): Trace: sh[0x997840], connected[1], ops[0x9a7480], ldap[0x9a48d0] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_initgr_user] (0x4000): Receiving info for the user (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 0) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_initgr_user] (0x4000): Storing the user (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_save_user] (0x4000): Save user (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding original DN [uid=tuser,cn=users,cn=accounts,dc=cl,dc=atix] to attributes of [tuser]. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_save_user] (0x1000): Original memberOf is not available for [tuser]. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding original mod-Timestamp [20121119093326Z] to attributes of [tuser]. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_save_user] (0x1000): Adding user principal [tuser at CL.ATIX] to attributes of [tuser]. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowLastChange is not available for [tuser]. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowMin is not available for [tuser]. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowMax is not available for [tuser]. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowWarning is not available for [tuser]. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowInactive is not available for [tuser]. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowExpire is not available for [tuser]. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowFlag is not available for [tuser]. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding krbLastPwdChange [20121119091442Z] to attributes of [tuser]. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding krbPasswordExpiration [20121119091442Z] to attributes of [tuser]. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): pwdAttribute is not available for [tuser]. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): authorizedService is not available for [tuser]. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): adAccountExpires is not available for [tuser]. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): adUserAccountControl is not available for [tuser]. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): nsAccountLock is not available for [tuser]. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): authorizedHost is not available for [tuser]. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): ndsLoginDisabled is not available for [tuser]. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): ndsLoginExpirationTime is not available for [tuser]. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): ndsLoginAllowedTimeMap is not available for [tuser]. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_attrs_add_ldap_attr] (0x2000): sshPublicKey is not available for [tuser]. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_save_user] (0x0400): Storing info for user tuser (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 1) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9b6300 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x9d48d0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x9d48d0 "ltdb_timeout" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9b6300 "ltdb_callback" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 2) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9d0600 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x9d0720 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x9d0720 "ltdb_timeout" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9d0600 "ltdb_callback" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 2) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [userPassword] from [tuser] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9d08b0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0xa319d0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0xa319d0 "ltdb_timeout" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9d08b0 "ltdb_callback" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [shadowLastChange] from [tuser] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9d08b0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x9d0720 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x9d0720 "ltdb_timeout" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9d08b0 "ltdb_callback" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [shadowMin] from [tuser] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9d0720 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x9d08b0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x9d08b0 "ltdb_timeout" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9d0720 "ltdb_callback" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [shadowMax] from [tuser] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9d08b0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x9d0720 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x9d0720 "ltdb_timeout" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9d08b0 "ltdb_callback" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [shadowWarning] from [tuser] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9d0720 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x9d08b0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x9d08b0 "ltdb_timeout" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9d0720 "ltdb_callback" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [shadowInactive] from [tuser] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9d08b0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x9d0720 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x9d0720 "ltdb_timeout" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9d08b0 "ltdb_callback" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [shadowExpire] from [tuser] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9d0720 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x9d08b0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x9d08b0 "ltdb_timeout" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9d0720 "ltdb_callback" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [shadowFlag] from [tuser] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9d08b0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x9d0720 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x9d0720 "ltdb_timeout" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9d08b0 "ltdb_callback" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [pwdAttribute] from [tuser] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9d0720 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x9d08b0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x9d08b0 "ltdb_timeout" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9d0720 "ltdb_callback" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [authorizedService] from [tuser] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9d08b0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x9d0720 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x9d0720 "ltdb_timeout" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9d08b0 "ltdb_callback" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [adAccountExpires] from [tuser] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9d0720 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x9d08b0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x9d08b0 "ltdb_timeout" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9d0720 "ltdb_callback" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [adUserAccountControl] from [tuser] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9d08b0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x9d0720 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x9d0720 "ltdb_timeout" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9d08b0 "ltdb_callback" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [nsAccountLock] from [tuser] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9d0720 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x9d08b0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x9d08b0 "ltdb_timeout" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9d0720 "ltdb_callback" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [authorizedHost] from [tuser] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9d08b0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x9d0720 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x9d0720 "ltdb_timeout" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9d08b0 "ltdb_callback" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [ndsLoginDisabled] from [tuser] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9d0720 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x9d08b0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x9d08b0 "ltdb_timeout" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9d0720 "ltdb_callback" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [ndsLoginExpirationTime] from [tuser] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9d08b0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x9d0720 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x9d0720 "ltdb_timeout" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9d08b0 "ltdb_callback" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [ndsLoginAllowedTimeMap] from [tuser] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9d0720 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x9d08b0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x9d08b0 "ltdb_timeout" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9d0720 "ltdb_callback" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sysdb_remove_attrs] (0x2000): Removing attribute [sshPublicKey] from [tuser] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9d08b0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x9d0720 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x9d0720 "ltdb_timeout" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9d08b0 "ltdb_callback" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): commit ldb transaction (nesting: 1) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_initgr_user] (0x4000): Commit change (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): commit ldb transaction (nesting: 0) (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x99b840 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x99b960 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x99b960 "ltdb_timeout" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x99b840 "ltdb_callback" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_initgr_user] (0x4000): Process user's groups (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_initgr_nested_send] (0x0100): User entry lacks original memberof ? (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_get_initgr_done] (0x4000): Initgroups done (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_id_op_destroy] (0x4000): releasing operation connection (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_id_op_done] (0x4000): releasing operation connection (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_process_result] (0x2000): Trace: sh[0x997840], connected[1], ops[(nil)], ldap[0x9a48d0] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): dbus conn: 8ED0A0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): Dispatching. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [sbus_message_handler] (0x4000): Received SBUS method [pamHandler] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [be_pam_handler] (0x0100): Got request with the following data (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): command: PAM_CHAUTHTOK_PRELIM (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): domain: gallien.atix (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): user: tuser (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): service: lightdm (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): tty: :0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): ruser: (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): rhost: (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): authtok type: 1 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): authtok size: 7 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): newauthtok type: 0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): newauthtok size: 0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): priv: 1 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): cli_pid: 19892 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9cfdf0 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x9d8b50 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x9d8b50 "ltdb_timeout" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9cfdf0 "ltdb_callback" (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [krb5_auth_send] (0x0100): No ccache file for user [tuser] found. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [krb5_auth_send] (0x4000): Ccache_file is [not set] and is not active and TGT is not valid. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [get_server_status] (0x1000): Status of server 'axinfra02-1.cl.atix' is 'working' (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [get_port_status] (0x1000): Port status of port 0 for server 'axinfra02-1.cl.atix' is 'working' (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 10 seconds (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [get_server_status] (0x1000): Status of server 'axinfra02-1.cl.atix' is 'working' (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [be_resolve_server_done] (0x1000): Saving the first resolved server (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [be_resolve_server_done] (0x0200): Found address for server axinfra02-1.cl.atix: [192.168.3.4] TTL 1200 (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [krb5_find_ccache_step] (0x4000): Recreating ccache file. (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [19942] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [child_handler_setup] (0x2000): Signal handler set up for pid [19942] (Mon Nov 19 10:33:32 2012) [sssd[be[gallien.atix]]] [write_pipe_handler] (0x0400): All data has been sent! ==> /var/log/sssd/krb5_child.log <== (Mon Nov 19 10:33:32 2012) [[sssd[krb5_child[19942]]]] [main] (0x0400): krb5_child started. (Mon Nov 19 10:33:32 2012) [[sssd[krb5_child[19942]]]] [krb5_child_setup] (0x1000): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Mon Nov 19 10:33:32 2012) [[sssd[krb5_child[19942]]]] [krb5_child_setup] (0x1000): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Mon Nov 19 10:33:32 2012) [[sssd[krb5_child[19942]]]] [krb5_child_setup] (0x4000): Not using FAST. (Mon Nov 19 10:33:33 2012) [[sssd[krb5_child[19942]]]] [changepw_child] (0x4000): Initial authentication for change password operation successfull. ==> /var/log/sssd/sssd_gallien.atix.log <== (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [read_pipe_handler] (0x0400): EOF received, client finished (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, ) [Success] (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [be_pam_handler_callback] (0x0100): Sending result [0][gallien.atix] (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [be_pam_handler_callback] (0x0100): Sent result [0][gallien.atix] (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): dbus conn: 8ED0A0 (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): Dispatching. (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [sbus_message_handler] (0x4000): Received SBUS method [pamHandler] (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [be_pam_handler] (0x0100): Got request with the following data (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): command: PAM_CHAUTHTOK (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): domain: gallien.atix (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): user: tuser (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): service: lightdm (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): tty: :0 (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): ruser: (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): rhost: (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): authtok type: 1 (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): authtok size: 7 (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): newauthtok type: 1 (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): newauthtok size: 0 (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): priv: 1 (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [pam_print_data] (0x0100): cli_pid: 19892 (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_callback": 0x9d8720 (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Added timed event "ltdb_timeout": 0x9d9090 (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Destroying timer event 0x9d9090 "ltdb_timeout" (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [ldb] (0x4000): tevent: Ending timer event 0x9d8720 "ltdb_callback" (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [krb5_auth_send] (0x0100): No ccache file for user [tuser] found. (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [krb5_auth_send] (0x4000): Ccache_file is [not set] and is not active and TGT is not valid. (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [get_server_status] (0x1000): Status of server 'axinfra02-1.cl.atix' is 'working' (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [get_port_status] (0x1000): Port status of port 0 for server 'axinfra02-1.cl.atix' is 'working' (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 10 seconds (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [get_server_status] (0x1000): Status of server 'axinfra02-1.cl.atix' is 'working' (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [be_resolve_server_done] (0x1000): Saving the first resolved server (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [be_resolve_server_done] (0x0200): Found address for server axinfra02-1.cl.atix: [192.168.3.4] TTL 1200 (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [krb5_find_ccache_step] (0x4000): Recreating ccache file. (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [19943] (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [child_handler_setup] (0x2000): Signal handler set up for pid [19943] (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [write_pipe_handler] (0x0400): All data has been sent! (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [child_sig_handler] (0x1000): Waiting for child [19943]. (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [child_sig_handler] (0x0020): waitpid did not found a child with changed status. (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [child_sig_handler] (0x1000): Waiting for child [19942]. (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [child_sig_handler] (0x0100): child [19942] finished successfully. ==> /var/log/sssd/krb5_child.log <== (Mon Nov 19 10:33:33 2012) [[sssd[krb5_child[19943]]]] [main] (0x0400): krb5_child started. (Mon Nov 19 10:33:33 2012) [[sssd[krb5_child[19943]]]] [krb5_child_setup] (0x1000): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Mon Nov 19 10:33:33 2012) [[sssd[krb5_child[19943]]]] [krb5_child_setup] (0x1000): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Mon Nov 19 10:33:33 2012) [[sssd[krb5_child[19943]]]] [krb5_child_setup] (0x4000): Not using FAST. (Mon Nov 19 10:33:33 2012) [[sssd[krb5_child[19943]]]] [changepw_child] (0x0020): krb5_change_password failed [2][Server error]. (Mon Nov 19 10:33:33 2012) [[sssd[krb5_child[19943]]]] [changepw_child] (0x0020): krb5_change_password failed [2][Password not changed.]. ==> /var/log/sssd/sssd_gallien.atix.log <== (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [read_pipe_handler] (0x0400): EOF received, client finished (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [krb5_child_done] (0x4000): child response [20][1][27]. (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [krb5_child_done] (0x4000): child response [20][6][29]. (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 20, ) [Success] (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [be_pam_handler_callback] (0x0100): Sending result [20][gallien.atix] (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [be_pam_handler_callback] (0x0100): Sent result [20][gallien.atix] (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [child_sig_handler] (0x1000): Waiting for child [19943]. (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [child_sig_handler] (0x0100): child [19943] finished successfully. (Mon Nov 19 10:33:33 2012) [sssd[be[gallien.atix]]] [sss_child_handler] (0x2000): waitpid failed [10]: No child processes (Mon Nov 19 10:33:38 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): dbus conn: 8C8E50 (Mon Nov 19 10:33:38 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): Dispatching. (Mon Nov 19 10:33:38 2012) [sssd[be[gallien.atix]]] [sbus_message_handler] (0x4000): Received SBUS method [ping] (Mon Nov 19 10:33:48 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): dbus conn: 8C8E50 (Mon Nov 19 10:33:48 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): Dispatching. (Mon Nov 19 10:33:48 2012) [sssd[be[gallien.atix]]] [sbus_message_handler] (0x4000): Received SBUS method [ping] (Mon Nov 19 10:33:58 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): dbus conn: 8C8E50 (Mon Nov 19 10:33:58 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): Dispatching. (Mon Nov 19 10:33:58 2012) [sssd[be[gallien.atix]]] [sbus_message_handler] (0x4000): Received SBUS method [ping] (Mon Nov 19 10:34:08 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): dbus conn: 8C8E50 (Mon Nov 19 10:34:08 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): Dispatching. (Mon Nov 19 10:34:08 2012) [sssd[be[gallien.atix]]] [sbus_message_handler] (0x4000): Received SBUS method [ping] (Mon Nov 19 10:34:18 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): dbus conn: 8C8E50 (Mon Nov 19 10:34:18 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): Dispatching. (Mon Nov 19 10:34:18 2012) [sssd[be[gallien.atix]]] [sbus_message_handler] (0x4000): Received SBUS method [ping] (Mon Nov 19 10:34:28 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): dbus conn: 8C8E50 (Mon Nov 19 10:34:28 2012) [sssd[be[gallien.atix]]] [sbus_dispatch] (0x4000): Dispatching. (Mon Nov 19 10:34:28 2012) [sssd[be[gallien.atix]]] [sbus_message_handler] (0x4000): Received SBUS method [ping] Any ideas? If you need more information or have a special trace let me know. Regards Marc. Am 19.11.2012 18:12, schrieb Dmitri Pal: > On 11/19/2012 11:31 AM, Marc Grimme wrote: >> This is what the kerberos (kadmin.log) shows on the relevant IPA server. >> Nov 19 17:29:54 axinfra02-1.cl.atix kadmind[18851](Error): password >> quality module empty rejected password for tuser at CL.ATIX: Empty >> passwords are not allowed >> Nov 19 17:29:54 axinfra02-1.cl.atix kadmind[18851](Notice): chpw request >> from 192.168.3.231 for tuser at CL.ATIX: Password is too short >> >> I could only enter the old password the new one was never queried. >> Any idea? > Please cross post to the sssd-users. It seems that the server receives > an empty password. I do not know if one can enable a trace that would > show what password is actually sent. > You might need to have a special build of SSSD to see what SSSD is > actually sending. > Anyways ask on SSSD list, you might get some good hints. > > Thanks > Dmitri > >> Thanks >> Marc. >> >> Am 19.11.2012 16:57, schrieb Dmitri Pal: >>> On 11/19/2012 04:37 AM, Marc Grimme wrote: >>>> (Mon Nov 19 10:33:33 2012) [[sssd[krb5_child[19943]]]] >>>> [krb5_child_setup] (0x4000): Not using FAST. >>>> (Mon Nov 19 10:33:33 2012) [[sssd[krb5_child[19943]]]] [changepw_child] >>>> (0x0020): krb5_change_password failed [2][Server error]. >>>> (Mon Nov 19 10:33:33 2012) [[sssd[krb5_child[19943]]]] [changepw_child] >>>> (0x0020): krb5_change_password failed [2][Password not changed.]. >>> Have you looked at the server Kerberos log? >>> Do you see an attempt there? >>> If not there might be a problem accessing kadmin process on the server. >>> Might be a firewall issue then. >>> But let us start with the server side. >>> >>> > -- Marc Grimme Tel: +49 (0)89 452 35 38-140 Fax: +49 (0)89 452 35 38-290 E-Mail: grimme at atix.de ATIX Informationstechnologie und Consulting AG | Einsteinstrasse 10 | 85716 Unterschleissheim | www.atix.de | www.comoonics.org Registergericht: Amtsgericht Muenchen, Registernummer: HRB 168930, USt.-Id.: DE209485962 | Vorstand: Marc Grimme, Mark Hlawatschek, Thomas Merz (Vors.) | Vorsitzender des Aufsichtsrats: Dr. Martin Buss From marcello.giannoni at ucla.edu Mon Nov 19 22:51:48 2012 From: marcello.giannoni at ucla.edu (Marcello Giannoni UCLA) Date: Mon, 19 Nov 2012 14:51:48 -0800 Subject: [Freeipa-users] passwd: Authentication token manipulation error Message-ID: Hi THis morning I was asked to reset the user password of one of our IPA/LDAP user accounts. After I reset the password I tried to logon to a particular ssh machine . The system asked to cheange the password as expeceted. I entered the NEw Password and the Re enter the the new password after this the system answered with: passwd: Authentication token manipulation error So in order to test this situation I created a new account and I had the same problem with the new account. I try also to reset another user password and I got the same problem. It seems that I'm not be able to reset anybody user password. Any ideas???? From the krb5kdc.log I get : Nov 19 14:35:31 ldap.webdom.lifesci.ucla.edu krb5kdc[1610](info): AS_REQ (4 etypes {18 17 16 23}) 164.67.110.65: PREAUTH_FAILED: taccount at myserver.com for kadmin/changepw at myserver.com, Decrypt integrity check failed from the /var/lib/dirsrv/slapd-server.com/errors file I get: ipapwd_setPasswordHistory - [file ipapwd_common.c, line 926]: failed to generate new password history! [19/Nov/2012:14:35:40 -0800] managed-entries-plugin - mep_mod_post_op: Unable to find config for origin entry "uid=taccount,cn=users,cn=accounts,dc=myserver,dc=com". Any idea on what's going on? Thank you Marcello -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Mon Nov 19 23:31:46 2012 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 19 Nov 2012 18:31:46 -0500 Subject: [Freeipa-users] passwd: Authentication token manipulation error In-Reply-To: References: Message-ID: <50AAC162.5020101@redhat.com> On 11/19/2012 05:51 PM, Marcello Giannoni UCLA wrote: > > Hi THis morning I was asked to reset the user password of one of our > IPA/LDAP user accounts. > > > > After I reset the password I tried to logon to a particular ssh machine . > > The system asked to cheange the password as expeceted. > > I entered the NEw Password and the Re enter the the new password after > this the system answered with: > > > > passwd: Authentication token manipulation error > > > > > So in order to test this situation I created a new account and I had > the same problem with the new account. > > I try also to reset another user password and I got the same problem. > > > > It seems that I'm not be able to reset anybody user password. > > > > Any ideas???? > > > > From the krb5kdc.log > > I get : Nov 19 14:35:31 ldap.webdom.lifesci.ucla.edu > krb5kdc[1610](info): AS_REQ (4 etypes {18 17 16 23}) 164.67.110.65: > PREAUTH_FAILED: taccount at myserver.com > for kadmin/changepw at myserver.com > , Decrypt integrity check failed > > > > from the /var/lib/dirsrv/slapd-server.com/errors file I get: > > ipapwd_setPasswordHistory - [file ipapwd_common.c, line 926]: failed > to generate new password history! > [19/Nov/2012:14:35:40 -0800] managed-entries-plugin - mep_mod_post_op: > Unable to find config for origin entry > "uid=taccount,cn=users,cn=accounts,dc=myserver,dc=com". > > > > > Any idea on what's going on? > Something is really mis configured on the server. When the user tries to change password his password policy needs to be read from lDAP. Password policy depends on the groups the user is a member of so effectively the policy is merged from different policies. That merge is failing because the DS plugin configuration is missing. Does this happen on all your replicas? If not and other replicas that you have work correctly, I would suggest considering re-installation of the current replica. But to make it work, I suggest you ask JR on #freeipa for exact steps as he has a lot of expertise on recycling replicas. > > > Thank you > > Marcello > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Tue Nov 20 08:39:11 2012 From: sbose at redhat.com (Sumit Bose) Date: Tue, 20 Nov 2012 09:39:11 +0100 Subject: [Freeipa-users] [SSSD-users] Problem with password reset on ubuntu 12.04 (lightdm) In-Reply-To: <50AA942B.1030903@atix.de> References: <50A9FDF3.2030408@atix.de> <50AA56D0.3020205@redhat.com> <50AA5EE6.7090605@atix.de> <50AA6868.9060100@redhat.com> <50AA942B.1030903@atix.de> Message-ID: <20121120083911.GO24620@localhost.localdomain> On Mon, Nov 19, 2012 at 09:18:51PM +0100, Marc Grimme wrote: > Hello sssd list. > My problem is that a with sssd configured ubuntu 12.04 client cannot > change a password that has to be set a new for IPA. > As I've learned from the IPA list there are indications that sssd might > be the problem in this case. > > With logging=10 in sssd.conf I see the following logs by sssd: > > When a user password expires the users are requested to change their > password (in the login screen). > They'll type their old password and then repeat it as part of the change > process. Nevertheless - although the password matches - they are not > issued to input their new password but get the error message that this > action could not be performed (Password change failed. Server message..). I guess it is you PAM configuration. If you use a client side password checker, e.g. pam_cracklib or pam_pwquality.so, in the password section of you PAM configuration you have to add the 'use_authtok' option to pam_sss in the section. If you do not use any checker you must not use 'use_authtok' here because sssd would expect a password to be available on the PAM stack but no module sets it. >From your description I guess you do not have a client-side password checker but 'use_authtok' is set. If this is the case, please remove 'use_authtok' and try again. HTH bye, Sumit From natxo.asenjo at gmail.com Tue Nov 20 09:24:57 2012 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Tue, 20 Nov 2012 10:24:57 +0100 Subject: [Freeipa-users] failure to register dns on joining IPA domain In-Reply-To: <50AB3F24.7020402@redhat.com> References: <50A6426C.7030406@redhat.com> <50A9F5E9.7040908@redhat.com> <50AB3F24.7020402@redhat.com> Message-ID: On Tue, Nov 20, 2012 at 9:28 AM, Petr Spacek wrote: > Hello, > > > On 11/19/2012 05:28 PM, Natxo Asenjo wrote: >> >> On Mon, Nov 19, 2012 at 10:03 AM, Petr Spacek wrote: >>> >>> Hello, >> >> >> hi, >> >>> The log showed the root cause: >>> Dynamic Update is not allowed in zone >>> idnsname=ipa.asenjo.nx,cn=dns,dc=ipa,dc=asenjo,dc=nx >> >> >> omg!!! >> >> I grepped the log for errors (error/panic/denied/deny) but missed that. > > Sorry, the error messages are not very nice. I have a ticket for log message > cleanup/consolidation/standardization but I don't have enough time ... > https://fedorahosted.org/bind-dyndb-ldap/ticket/62 > > In future version it should return more descriptive error code (rather than > general SERVFAIL). > > >> thanks for not shaming me in public ;-) and for helping me find this, of >> course. > > Actually, I replied privately by mistake :-) > > I still want to post the solution publicly to make it available via archive. > Do you re-post the solution yourself? Feel free to re-formulate the message > :-) For the posterity :-), my dns zone did not allow dynamic updates and thus the registration of the dns host failed miserably. Thanks to Petr for helping me find this. -- groet, natxo From grimme at atix.de Tue Nov 20 09:25:56 2012 From: grimme at atix.de (Marc Grimme) Date: Tue, 20 Nov 2012 10:25:56 +0100 Subject: [Freeipa-users] [SSSD-users] Problem with password reset on ubuntu 12.04 (lightdm) In-Reply-To: <20121120083911.GO24620@localhost.localdomain> References: <50A9FDF3.2030408@atix.de> <50AA56D0.3020205@redhat.com> <50AA5EE6.7090605@atix.de> <50AA6868.9060100@redhat.com> <50AA942B.1030903@atix.de> <20121120083911.GO24620@localhost.localdomain> Message-ID: <50AB4CA4.9050109@atix.de> Am 20.11.2012 09:39, schrieb Sumit Bose: > On Mon, Nov 19, 2012 at 09:18:51PM +0100, Marc Grimme wrote: >> Hello sssd list. >> My problem is that a with sssd configured ubuntu 12.04 client cannot >> change a password that has to be set a new for IPA. >> As I've learned from the IPA list there are indications that sssd might >> be the problem in this case. >> >> With logging=10 in sssd.conf I see the following logs by sssd: >> >> When a user password expires the users are requested to change their >> password (in the login screen). >> They'll type their old password and then repeat it as part of the change >> process. Nevertheless - although the password matches - they are not >> issued to input their new password but get the error message that this >> action could not be performed (Password change failed. Server message..). > I guess it is you PAM configuration. If you use a client side password > checker, e.g. pam_cracklib or pam_pwquality.so, in the password section > of you PAM configuration you have to add the 'use_authtok' option to > pam_sss in the section. If you do not use any checker you must not use > 'use_authtok' here because sssd would expect a password to be available > on the PAM stack but no module sets it. > > From your description I guess you do not have a client-side password > checker but 'use_authtok' is set. If this is the case, please remove > 'use_authtok' and try again. > > HTH > > bye, > Sumit > _______________________________________________ > sssd-users mailing list > sssd-users at lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/sssd-users Hi Sumit, thanks very much. I replaced the line /etc/pam.d/common-password: password sufficient pam_sss.so use_authtok with password sufficient pam_sss.so restarted lightdm and the password change succeeded like a charm. Regards Marc. From abosch at ticmallorca.net Tue Nov 20 10:33:29 2012 From: abosch at ticmallorca.net (Angel Bosch) Date: Tue, 20 Nov 2012 11:33:29 +0100 (CET) Subject: [Freeipa-users] [SSSD-users] Problem with password reset on ubuntu 12.04 (lightdm) In-Reply-To: <50AB4CA4.9050109@atix.de> Message-ID: <17817535.27020.1353407609358.JavaMail.root@pampol2> on related problems: I opened a bug regarding messages given to user on lightdm: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1009013 seems that pam interaction with user is not correctly handled by graphical logins. ----- Original Message ----- De: "Marc Grimme" A: "End-user discussions about the System Security Services Daemon" CC: freeipa-users at redhat.com Enviat: dimarts, 20 de novembre de 2012 10:25:56 Assumpte: Re: [SSSD-users] [Freeipa-users] Problem with password reset on ubuntu 12.04 (lightdm) Am 20.11.2012 09:39, schrieb Sumit Bose: > On Mon, Nov 19, 2012 at 09:18:51PM +0100, Marc Grimme wrote: >> Hello sssd list. >> My problem is that a with sssd configured ubuntu 12.04 client cannot >> change a password that has to be set a new for IPA. >> As I've learned from the IPA list there are indications that sssd might >> be the problem in this case. >> >> With logging=10 in sssd.conf I see the following logs by sssd: >> >> When a user password expires the users are requested to change their >> password (in the login screen). >> They'll type their old password and then repeat it as part of the change >> process. Nevertheless - although the password matches - they are not >> issued to input their new password but get the error message that this >> action could not be performed (Password change failed. Server message..). > I guess it is you PAM configuration. If you use a client side password > checker, e.g. pam_cracklib or pam_pwquality.so, in the password section > of you PAM configuration you have to add the 'use_authtok' option to > pam_sss in the section. If you do not use any checker you must not use > 'use_authtok' here because sssd would expect a password to be available > on the PAM stack but no module sets it. > > From your description I guess you do not have a client-side password > checker but 'use_authtok' is set. If this is the case, please remove > 'use_authtok' and try again. > > HTH > > bye, > Sumit > _______________________________________________ > sssd-users mailing list > sssd-users at lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/sssd-users Hi Sumit, thanks very much. I replaced the line /etc/pam.d/common-password: password sufficient pam_sss.so use_authtok with password sufficient pam_sss.so restarted lightdm and the password change succeeded like a charm. Regards Marc. _______________________________________________ sssd-users mailing list sssd-users at lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Wed Nov 21 15:40:42 2012 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 21 Nov 2012 16:40:42 +0100 Subject: [Freeipa-users] replica installation with external DNS In-Reply-To: <4F8B8BAD74DCB94ABB26045D79389B54167ADA55D4@woodpecker.LIBERO.INT> References: <4F8B8BAD74DCB94ABB26045D79389B54167ADA55D4@woodpecker.LIBERO.INT> Message-ID: <50ACF5FA.2000305@redhat.com> Hello, I added freeipa-users to Cc to reach bigger auditorium and mailing list archive. Please post your questions primarily to freeipa-users at redhat.com. On 11/21/2012 04:28 PM, Bilal Bas wrote: > I have a small question about freeIPA DNS configuration. > I have server #1 have FreeIPA installed on it, and server #2 which is a replication of server #1, and I use a external DNS in my environment. So after installing ipa on server #1, I added the DNS records below in my domain zone file; > > ; ldap servers > _ldap._tcp IN SRV 0 100 389 ipatest01 > > ; kerberos servers > _kerberos._tcp IN SRV 0 100 88 ipatest01 > _kerberos._udp IN SRV 0 100 88 ipatest01 > _kerberos-master._tcp IN SRV 0 100 88 ipatest01 > _kerberos-master._udp IN SRV 0 100 88 ipatest01 > _kpasswd._tcp IN SRV 0 100 464 ipatest01 > _kpasswd._udp IN SRV 0 100 464 ipatest01 > > ;ntp server > _ntp._udp IN SRV 0 100 123 ntpsrv01 > > > ;kerberos realm > _kerberos IN TXT MYDOMAIN.COM > > Now, for the replica server #2, should I add the same records for it as well? You are right. All records except _kerberos IN TXT should be duplicated with new server name. Of course, you need to skip _ntp._udp IN SRV if you have external NTP. -- Petr^2 Spacek From tjaalton at ubuntu.com Wed Nov 21 16:17:13 2012 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Wed, 21 Nov 2012 18:17:13 +0200 Subject: [Freeipa-users] [SSSD-users] Problem with password reset on ubuntu 12.04 (lightdm) In-Reply-To: <50AB4CA4.9050109@atix.de> References: <50A9FDF3.2030408@atix.de> <50AA56D0.3020205@redhat.com> <50AA5EE6.7090605@atix.de> <50AA6868.9060100@redhat.com> <50AA942B.1030903@atix.de> <20121120083911.GO24620@localhost.localdomain> <50AB4CA4.9050109@atix.de> Message-ID: <50ACFE89.7020907@ubuntu.com> On 20.11.2012 11:25, Marc Grimme wrote: > Am 20.11.2012 09:39, schrieb Sumit Bose: >> On Mon, Nov 19, 2012 at 09:18:51PM +0100, Marc Grimme wrote: >>> Hello sssd list. >>> My problem is that a with sssd configured ubuntu 12.04 client cannot >>> change a password that has to be set a new for IPA. >>> As I've learned from the IPA list there are indications that sssd might >>> be the problem in this case. >>> >>> With logging=10 in sssd.conf I see the following logs by sssd: >>> >>> When a user password expires the users are requested to change their >>> password (in the login screen). >>> They'll type their old password and then repeat it as part of the change >>> process. Nevertheless - although the password matches - they are not >>> issued to input their new password but get the error message that this >>> action could not be performed (Password change failed. Server message..). >> I guess it is you PAM configuration. If you use a client side password >> checker, e.g. pam_cracklib or pam_pwquality.so, in the password section >> of you PAM configuration you have to add the 'use_authtok' option to >> pam_sss in the section. If you do not use any checker you must not use >> 'use_authtok' here because sssd would expect a password to be available >> on the PAM stack but no module sets it. >> >> From your description I guess you do not have a client-side password >> checker but 'use_authtok' is set. If this is the case, please remove >> 'use_authtok' and try again. >> >> HTH >> >> bye, >> Sumit >> _______________________________________________ >> sssd-users mailing list >> sssd-users at lists.fedorahosted.org >> https://lists.fedorahosted.org/mailman/listinfo/sssd-users > > Hi Sumit, > thanks very much. > I replaced the line > /etc/pam.d/common-password: > password sufficient pam_sss.so use_authtok > with > password sufficient pam_sss.so > restarted lightdm and the password change succeeded like a charm. Right, the next upload to 12.04 will drop use_authtok from the pam config. The pam-auth-update tool unfortunately doesn't currently support the use case that sssd needs, where on the pam auth stack it should be with a lower priority than pam_unix, but on password stack it should be on top (or after pam_cracklib). That'll get fixed later.. -- t From biteoag at gmail.com Mon Nov 26 18:35:14 2012 From: biteoag at gmail.com (Albert Tesla) Date: Mon, 26 Nov 2012 13:35:14 -0500 Subject: [Freeipa-users] IPA DNS forward only is not working Message-ID: I have FreeIPA installed on RHEL 6 server. There is an existing windows domain and DNS; example.com. I created a FreeIPA domain of example.com. I have attempted to configure the "forward first" option in both the DNS Global Configuration and the example.com zone configuration. I would like all lookups to first point to the forwarder and if it is unable to resolve I want it to look at the FreeIPA DNS. As I understand it, the "forward first" setting should accomplish this. Unfortunately DNS is behaving as if the "forward only" option is enabled as it will resolve addresses outside of the FreeIPA example.com domain but will not resolve hosts that are only in the FreeIPA example.com domain. I am very new to FreeIPA and would appreciate any help that can be provided. Here is my named.conf: options { // turns on IPv6 for port 53, IPv4 is on by default for all ifaces listen-on-v6 {any;}; // Put files that named is allowed to write in the data/ directory: directory "/var/named"; // the default dump-file "data/cache_dump.db"; statistics-file "data/named_stats.txt"; memstatistics-file "data/named_mem_stats.txt"; forward first; forwarders { 192.168.x.x; }; // Any host is permitted to issue recursive queries allow-recursion { any; }; tkey-gssapi-credential "DNS/freeipa.example.com"; tkey-domain "EXAMPLE.COM"; }; /* If you want to enable debugging, eg. using the 'rndc trace' command, * By default, SELinux policy does not allow named to modify the /var/named directory, * so put the default debug log file in data/ : */ logging { channel default_debug { file "data/named.run"; severity dynamic; }; }; zone "." IN { type hint; file "named.ca"; }; include "/etc/named.rfc1912.zones"; dynamic-db "ipa" { library "ldap.so"; arg "uri ldapi://%2fvar%2frun%2fslapd-EXAMPLE-COM.socket"; arg "base cn=dns, dc=example,dc=com"; arg "fake_mname freeipa.example.com."; arg "auth_method sasl"; arg "sasl_mech GSSAPI"; arg "sasl_user DNS/freeipa.example.com"; arg "zone_refresh 30"; }; Thanks in advance, Albert -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Tue Nov 27 07:47:30 2012 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 27 Nov 2012 08:47:30 +0100 Subject: [Freeipa-users] IPA DNS forward only is not working In-Reply-To: References: Message-ID: <50B47012.3030405@redhat.com> Hello, I will try to summarize your question, please correct me if I'm wrong. - existing Windows domain: example.com - installed IPA domain: example.com (I guess from named.conf) - you want to query Windows DNS first and then try to query IPA DNS when Windows DNS do not have specific record Do I understand correctly? From DNS point of view it doesn't make sense. Only single database can be authoritative for specific domain. In you case you have to chose if Windows or IPA DNS should be authoritative for example.com. There is no fallback-if-record-doesn't-exist method. All servers serving particular zone have to have exactly same database, i.e. they have to be Windows OR IPA replicated servers. Another problem comes from IPA+Windows installation in the same domain. In can theoretically work, but you will lose server auto-detection and ability to create trust between AD and IPA. Please don't do that. It is much better to create sub-domain for AD or IPA, e.g. ipa.example.com. Then you will create delegation and glue records in AD DNS (NS+A records in example.com) and it will work. If I misunderstood your question please add following information: - FreeIPA version rpm -q ipa-server - bind-dyndb-ldap version rpm -q bind-dyndb-ldap - export configuration object cn=dns, dc=example, dc=com from IPA LDAP - export IPA zone objects idnsname=*, cn=dns, dc=example, dc=com from IPA LDAP (i.e. one level under cn=dns, dc=example, dc=com) Petr^2 Spacek > I have FreeIPA installed on RHEL 6 server. There is an existing windows domain and DNS; example.com. I created a FreeIPA domain of example.com. I have attempted to configure the "forward first" option in both the DNS Global Configuration and the example.com zone configuration. I would like all lookups to first point to the forwarder and if it is unable to resolve I want it to look at the FreeIPA DNS. As I understand it, the "forward first" setting should accomplish this. Unfortunately DNS is behaving as if the "forward only" option is enabled as it will resolve addresses outside of the FreeIPA example.com domain but will not resolve hosts that are only in the FreeIPA example.com domain. I am very new to FreeIPA and would appreciate any help that can be provided. > > Here is my named.conf: > options { > // turns on IPv6 for port 53, IPv4 is on by default for all ifaces > listen-on-v6 {any;}; > > // Put files that named is allowed to write in the data/ directory: > directory "/var/named"; // the default > dump-file "data/cache_dump.db"; > statistics-file "data/named_stats.txt"; > memstatistics-file "data/named_mem_stats.txt"; > > forward first; > forwarders { > 192.168.x.x; > }; > > // Any host is permitted to issue recursive queries > allow-recursion { any; }; > > tkey-gssapi-credential "DNS/freeipa.example.com"; > tkey-domain "EXAMPLE.COM"; > }; > > /* If you want to enable debugging, eg. using the 'rndc trace' command, > * By default, SELinux policy does not allow named to modify the /var/named directory, > * so put the default debug log file in data/ : > */ > logging { > channel default_debug { > file "data/named.run"; > severity dynamic; > }; > }; > > zone "." IN { > type hint; > file "named.ca"; > }; > > include "/etc/named.rfc1912.zones"; > > dynamic-db "ipa" { > library "ldap.so"; > arg "uri ldapi://%2fvar%2frun%2fslapd-EXAMPLE-COM.socket"; > arg "base cn=dns, dc=example,dc=com"; > arg "fake_mname freeipa.example.com."; > arg "auth_method sasl"; > arg "sasl_mech GSSAPI"; > arg "sasl_user DNS/freeipa.example.com"; > arg "zone_refresh 30"; > }; From pspacek at redhat.com Tue Nov 27 08:12:50 2012 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 27 Nov 2012 09:12:50 +0100 Subject: [Freeipa-users] IPA DNS forward only is not working In-Reply-To: <50B47012.3030405@redhat.com> References: <50B47012.3030405@redhat.com> Message-ID: <50B47602.2050004@redhat.com> Hello once again, some DNS scenarios are described in https://fedorahosted.org/freeipa/attachment/ticket/3268/3268.v1 It is preliminary version of new text for IPA manual. Please report any errors and ambiguities. Petr^2 Spacek On 11/27/2012 08:47 AM, Petr Spacek wrote: > Hello, > > I will try to summarize your question, please correct me if I'm wrong. > > - existing Windows domain: example.com > - installed IPA domain: example.com (I guess from named.conf) > - you want to query Windows DNS first and then try to query IPA DNS when > Windows DNS do not have specific record > > Do I understand correctly? > > > From DNS point of view it doesn't make sense. Only single database can be > authoritative for specific domain. In you case you have to chose if Windows or > IPA DNS should be authoritative for example.com. There is no > fallback-if-record-doesn't-exist method. All servers serving particular zone > have to have exactly same database, i.e. they have to be Windows OR IPA > replicated servers. > > Another problem comes from IPA+Windows installation in the same domain. In can > theoretically work, but you will lose server auto-detection and ability to > create trust between AD and IPA. Please don't do that. > > It is much better to create sub-domain for AD or IPA, e.g. ipa.example.com. > Then you will create delegation and glue records in AD DNS (NS+A records in > example.com) and it will work. > > > If I misunderstood your question please add following information: > - FreeIPA version > rpm -q ipa-server > > - bind-dyndb-ldap version > rpm -q bind-dyndb-ldap > > - export configuration object cn=dns, dc=example, dc=com from IPA LDAP > > - export IPA zone objects idnsname=*, cn=dns, dc=example, dc=com from IPA LDAP > (i.e. one level under cn=dns, dc=example, dc=com) > > Petr^2 Spacek > > >> I have FreeIPA installed on RHEL 6 server. There is an existing windows > domain and DNS; example.com. I created a FreeIPA domain of example.com. I > have attempted to configure the "forward first" option in both the DNS Global > Configuration and the example.com zone configuration. I would like all > lookups to first point to the forwarder and if it is unable to resolve I want > it to look at the FreeIPA DNS. As I understand it, the "forward first" > setting should accomplish this. Unfortunately DNS is behaving as if the > "forward only" option is enabled as it will resolve addresses outside of the > FreeIPA example.com domain but will not resolve hosts that are only in the > FreeIPA example.com domain. I am very new to FreeIPA and would appreciate any > help that can be provided. >> >> Here is my named.conf: >> options { >> // turns on IPv6 for port 53, IPv4 is on by default for all ifaces >> listen-on-v6 {any;}; >> >> // Put files that named is allowed to write in the data/ directory: >> directory "/var/named"; // the default >> dump-file "data/cache_dump.db"; >> statistics-file "data/named_stats.txt"; >> memstatistics-file "data/named_mem_stats.txt"; >> >> forward first; >> forwarders { >> 192.168.x.x; >> }; >> >> // Any host is permitted to issue recursive queries >> allow-recursion { any; }; >> >> tkey-gssapi-credential "DNS/freeipa.example.com"; >> tkey-domain "EXAMPLE.COM"; >> }; >> >> /* If you want to enable debugging, eg. using the 'rndc trace' command, >> * By default, SELinux policy does not allow named to modify the /var/named > directory, >> * so put the default debug log file in data/ : >> */ >> logging { >> channel default_debug { >> file "data/named.run"; >> severity dynamic; >> }; >> }; >> >> zone "." IN { >> type hint; >> file "named.ca"; >> }; >> >> include "/etc/named.rfc1912.zones"; >> >> dynamic-db "ipa" { >> library "ldap.so"; >> arg "uri ldapi://%2fvar%2frun%2fslapd-EXAMPLE-COM.socket"; >> arg "base cn=dns, dc=example,dc=com"; >> arg "fake_mname freeipa.example.com."; >> arg "auth_method sasl"; >> arg "sasl_mech GSSAPI"; >> arg "sasl_user DNS/freeipa.example.com"; >> arg "zone_refresh 30"; >> }; -- Petr^2 Spacek From natxo.asenjo at gmail.com Tue Nov 27 15:46:49 2012 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Tue, 27 Nov 2012 16:46:49 +0100 Subject: [Freeipa-users] ttl settings for host records Message-ID: hi, this is puzzling me. I have an AD environment (which is leading) with integrated dns servers. In the AD dns I have a zone domain.tld. I have created a delegation unix.domain.tld in it with a glue record pointing to a new ipa server kdc01.unix.domain.tld. This works. I can join hosts to the IPA domain and reach their services from the AD domain. this is the what a host querying the AD dns servers gets when getting info about the unix.domain.tld zone: $ dig unix.domain.tld ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6_3.5 <<>> unix.domain.tld ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34185 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;unix.domain.tld. IN A ;; AUTHORITY SECTION: unix.domain.tld. 300 IN SOA kdc01.unix.domain.tld. hostmaster.unix.domain.tld. 2012110713 3600 900 1209600 3600 And the TTL is 300. When I re-run the query, I see that it is less than that. This is normal, I have the domain.tld in AD dns with ttl 5 minutes. So far, so good. Now I joing a host to the IPA domain and query the host: $ dig solr01.unix.domain.tld ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6_3.5 <<>> solr01.unix.domain.tld ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7726 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;solr01.unix.domain.tld. IN A ;; ANSWER SECTION: solr01.unix.domain.tld. 84185 IN A 172.20.6.42 The ttl has gone up to one day. this are the zone settings in IPA: $ ipa dnszone-show Zone name: unix.domain.tld Zone name: unix.domain.tld Authoritative nameserver: kdc01.unix.domain.tld. Administrator e-mail address: hostmaster.unix.domain.tld. SOA serial: 2012110713 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 Active zone: TRUE Allow query: any; Allow transfer: none; In the web-ui I have filled in the SOA time to live field: 300 for this zone, but it is not being picked up. Where can I set this? If there are changes on the IPA server, I do not want that the old info gets cached for a day on the AD dns servers. TIA. -- Groeten, natxo From rcritten at redhat.com Tue Nov 27 15:52:38 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 27 Nov 2012 10:52:38 -0500 Subject: [Freeipa-users] ttl settings for host records In-Reply-To: References: Message-ID: <50B4E1C6.5060501@redhat.com> Natxo Asenjo wrote: > hi, > > this is puzzling me. > > I have an AD environment (which is leading) with integrated dns servers. > > In the AD dns I have a zone domain.tld. I have created a delegation > unix.domain.tld in it with a glue record pointing to a new ipa server > kdc01.unix.domain.tld. > > This works. I can join hosts to the IPA domain and reach their > services from the AD domain. > > this is the what a host querying the AD dns servers gets when getting > info about the unix.domain.tld zone: > > $ dig unix.domain.tld > > ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6_3.5 <<>> unix.domain.tld > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34185 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;unix.domain.tld. IN A > > ;; AUTHORITY SECTION: > unix.domain.tld. 300 IN SOA kdc01.unix.domain.tld. > hostmaster.unix.domain.tld. 2012110713 3600 900 1209600 3600 > > And the TTL is 300. When I re-run the query, I see that it is less > than that. This is normal, I have the domain.tld in AD dns with ttl 5 > minutes. > > So far, so good. > > Now I joing a host to the IPA domain and query the host: > > $ dig solr01.unix.domain.tld > > ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6_3.5 <<>> solr01.unix.domain.tld > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7726 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;solr01.unix.domain.tld. IN A > > ;; ANSWER SECTION: > solr01.unix.domain.tld. 84185 IN A 172.20.6.42 > > The ttl has gone up to one day. > > this are the zone settings in IPA: > $ ipa dnszone-show > Zone name: unix.domain.tld > Zone name: unix.domain.tld > Authoritative nameserver: kdc01.unix.domain.tld. > Administrator e-mail address: hostmaster.unix.domain.tld. > SOA serial: 2012110713 > SOA refresh: 3600 > SOA retry: 900 > SOA expire: 1209600 > SOA minimum: 3600 > Active zone: TRUE > Allow query: any; > Allow transfer: none; > > In the web-ui I have filled in the SOA time to live field: 300 for > this zone, but it is not being picked up. > > Where can I set this? If there are changes on the IPA server, I do not > want that the old info gets cached for a day on the AD dns servers. I'm not entirely sure where that 86400 came from. When we do a dynamic update the TTL is hardcoded to 1200. There is a ticket to make this configurable, https://fedorahosted.org/freeipa/ticket/3031 rob From pspacek at redhat.com Tue Nov 27 17:10:20 2012 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 27 Nov 2012 18:10:20 +0100 Subject: [Freeipa-users] ttl settings for host records In-Reply-To: <50B4E1C6.5060501@redhat.com> References: <50B4E1C6.5060501@redhat.com> Message-ID: <50B4F3FC.4030905@redhat.com> Hello, On 11/27/2012 04:52 PM, Rob Crittenden wrote: > Natxo Asenjo wrote: >> hi, >> >> this is puzzling me. >> >> I have an AD environment (which is leading) with integrated dns servers. >> >> In the AD dns I have a zone domain.tld. I have created a delegation >> unix.domain.tld in it with a glue record pointing to a new ipa server >> kdc01.unix.domain.tld. >> >> This works. I can join hosts to the IPA domain and reach their >> services from the AD domain. >> >> this is the what a host querying the AD dns servers gets when getting >> info about the unix.domain.tld zone: >> >> $ dig unix.domain.tld >> >> ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6_3.5 <<>> unix.domain.tld >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34185 >> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 >> >> ;; QUESTION SECTION: >> ;unix.domain.tld. IN A >> >> ;; AUTHORITY SECTION: >> unix.domain.tld. 300 IN SOA kdc01.unix.domain.tld. >> hostmaster.unix.domain.tld. 2012110713 3600 900 1209600 3600 >> >> And the TTL is 300. When I re-run the query, I see that it is less >> than that. This is normal, I have the domain.tld in AD dns with ttl 5 >> minutes. >> >> So far, so good. Do you set TTL = 300 explicitly for unix.domain.tld. (i.e. SOA record), right? >> Now I joing a host to the IPA domain and query the host: >> >> $ dig solr01.unix.domain.tld >> >> ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6_3.5 <<>> solr01.unix.domain.tld >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7726 >> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 >> >> ;; QUESTION SECTION: >> ;solr01.unix.domain.tld. IN A >> >> ;; ANSWER SECTION: >> solr01.unix.domain.tld. 84185 IN A 172.20.6.42 >> >> The ttl has gone up to one day. 86400 seconds is default value for entries without explicit TTL definition. TTL setting is effective per-name, so setting TTL for zone's root (SOA record) will affect only SOA itself. Current version have default TTL 86400 seconds hard-coded. It is known limitation and it is planned to address this in IPA 3.2: https://fedorahosted.org/bind-dyndb-ldap/ticket/70 Before this ticket is solved you have to explicitly set TTL attribute for each existing DNS name. Sorry! >> this are the zone settings in IPA: >> $ ipa dnszone-show >> Zone name: unix.domain.tld >> Zone name: unix.domain.tld >> Authoritative nameserver: kdc01.unix.domain.tld. >> Administrator e-mail address: hostmaster.unix.domain.tld. >> SOA serial: 2012110713 >> SOA refresh: 3600 >> SOA retry: 900 >> SOA expire: 1209600 >> SOA minimum: 3600 For completeness: This value affects only negative record caching. See http://tools.ietf.org/html/rfc2308 section "2.2.1 - Special Handling of No Data", part "4 - SOA Minimum Field". >> Active zone: TRUE >> Allow query: any; >> Allow transfer: none; >> >> In the web-ui I have filled in the SOA time to live field: 300 for >> this zone, but it is not being picked up. The plan is to have separate SOA TTL and per-zone default-TTL setting, but now there is no attribute for default TTL. >> Where can I set this? If there are changes on the IPA server, I do not >> want that the old info gets cached for a day on the AD dns servers. > > I'm not entirely sure where that 86400 came from. When we do a dynamic update > the TTL is hardcoded to 1200. There is a ticket to make this configurable, > https://fedorahosted.org/freeipa/ticket/3031 -- Petr^2 Spacek From tim.wissman at gmail.com Tue Nov 27 23:02:46 2012 From: tim.wissman at gmail.com (Tim Wissman) Date: Wed, 28 Nov 2012 08:32:46 +0930 Subject: [Freeipa-users] Solaris 10 and Solaris 11 clients Message-ID: Folks - I have started using FreeIPA and have tried to download the Solaris 10 nss-ldap for the intel platform, but when i tried to save the file i received an error saying the server had issues. I was able to download the SPARC package from the same site. If someone could look into it, it could just be a permissions problem. As for Solaris 11, has there been any work in that direction yet? thanks. tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Nov 28 13:48:43 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 28 Nov 2012 08:48:43 -0500 Subject: [Freeipa-users] Solaris 10 and Solaris 11 clients In-Reply-To: References: Message-ID: <50B6163B.4020404@redhat.com> Tim Wissman wrote: > > Folks - I have started using FreeIPA and have tried to download the > Solaris 10 nss-ldap for the intel platform, but when i tried to save the > file i received an error saying the server had issues. I was able to > download the SPARC package from the same site. If someone could look > into it, it could just be a permissions problem. > > As for Solaris 11, has there been any work in that direction yet? > > thanks. > > tim You shouldn't need to use this. The native packages in 10 and 11 should work fine with IPA (see ldapclient). I was able to download the i386 bits from Solaris 10 just fine, so you might want to try it again. There are no plans to support these existing packages or build them for other releases. rob From natxo.asenjo at gmail.com Wed Nov 28 13:55:28 2012 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Wed, 28 Nov 2012 14:55:28 +0100 Subject: [Freeipa-users] Solaris 10 and Solaris 11 clients In-Reply-To: References: Message-ID: hi, On Wed, Nov 28, 2012 at 12:02 AM, Tim Wissman wrote: > > Folks - I have started using FreeIPA and have tried to download the Solaris > 10 nss-ldap for the intel platform, but when i tried to save the file i > received an error saying the server had issues. I was able to download the > SPARC package from the same site. If someone could look into it, it could > just be a permissions problem. > > As for Solaris 11, has there been any work in that direction yet? I have not tested with solaris 10, but I can confirm that it works with openindiana (former opensolaris) using the instructions in http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html I posted a while ago a problem with this when using dhcp (see archives: https://www.redhat.com/archives/freeipa-users/2012-September/thread.html#00001, look for 'openindiana' and you will find the whole thread). As Sigbjorn Lie pointed, you can use a DUAprofile which *just works*. -- Groeten, natxo From sigbjorn at nixtra.com Wed Nov 28 18:27:01 2012 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Wed, 28 Nov 2012 19:27:01 +0100 (CET) Subject: [Freeipa-users] Solaris 10 and Solaris 11 clients In-Reply-To: References: Message-ID: <25191.62.92.50.17.1354127221.squirrel@www.nixtra.com> Hi, There was an issue with Solaris 11. I can't remember of the top of my head, I believe it had to do with logins. So ldapclient would run successfully, and kerberos would set up successfully as well, however there we're some issue when logging in. I suppose it's time to have a closer look at it one of these days...if I can find some spare time. :) Regards, Siggi On Wed, November 28, 2012 00:02, Tim Wissman wrote: > Folks - I have started using FreeIPA and have tried to download the Solaris > 10 nss-ldap for the intel platform, but when i tried to save the file i > received an error saying the server had issues. I was able to download the SPARC package from the > same site. If someone could look into it, it could just be a permissions problem. > > As for Solaris 11, has there been any work in that direction yet? > > > thanks. > > tim _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From tim.wissman at gmail.com Wed Nov 28 22:22:07 2012 From: tim.wissman at gmail.com (Tim Wissman) Date: Thu, 29 Nov 2012 07:52:07 +0930 Subject: [Freeipa-users] Solaris 10 and Solaris 11 clients In-Reply-To: <50B6163B.4020404@redhat.com> References: <50B6163B.4020404@redhat.com> Message-ID: Thanks for that Rob. I was going off of the docs, that's why i went to the download page. I will give ldapclient a whirl and see how we go. thanks again for getting back to me so quickly. tim On Wed, Nov 28, 2012 at 11:18 PM, Rob Crittenden wrote: > Tim Wissman wrote: > >> >> Folks - I have started using FreeIPA and have tried to download the >> Solaris 10 nss-ldap for the intel platform, but when i tried to save the >> file i received an error saying the server had issues. I was able to >> download the SPARC package from the same site. If someone could look >> into it, it could just be a permissions problem. >> >> As for Solaris 11, has there been any work in that direction yet? >> >> thanks. >> >> tim >> > > You shouldn't need to use this. The native packages in 10 and 11 should > work fine with IPA (see ldapclient). > > I was able to download the i386 bits from Solaris 10 just fine, so you > might want to try it again. > > There are no plans to support these existing packages or build them for > other releases. > > rob > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.wissman at gmail.com Wed Nov 28 22:26:57 2012 From: tim.wissman at gmail.com (Tim Wissman) Date: Thu, 29 Nov 2012 07:56:57 +0930 Subject: [Freeipa-users] Solaris 10 and Solaris 11 clients In-Reply-To: <25191.62.92.50.17.1354127221.squirrel@www.nixtra.com> References: <25191.62.92.50.17.1354127221.squirrel@www.nixtra.com> Message-ID: had a similar problem with OpenDJ and i think i had to tweek some of the pam files...as i am working in a 10/11 environment, i can test both very easily...i will give you any feedback i might have. tim On Thu, Nov 29, 2012 at 3:57 AM, Sigbjorn Lie wrote: > Hi, > > There was an issue with Solaris 11. I can't remember of the top of my > head, I believe it had to do > with logins. So ldapclient would run successfully, and kerberos would set > up successfully as well, > however there we're some issue when logging in. > > I suppose it's time to have a closer look at it one of these days...if I > can find some spare time. :) > > > > Regards, > Siggi > > > > On Wed, November 28, 2012 00:02, Tim Wissman wrote: > > Folks - I have started using FreeIPA and have tried to download the > Solaris > > 10 nss-ldap for the intel platform, but when i tried to save the file i > > received an error saying the server had issues. I was able to download > the SPARC package from the > > same site. If someone could look into it, it could just be a permissions > problem. > > > > As for Solaris 11, has there been any work in that direction yet? > > > > > > thanks. > > > > tim _______________________________________________ > > 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 tim.wissman at gmail.com Wed Nov 28 22:24:59 2012 From: tim.wissman at gmail.com (Tim Wissman) Date: Thu, 29 Nov 2012 07:54:59 +0930 Subject: [Freeipa-users] Solaris 10 and Solaris 11 clients In-Reply-To: References: Message-ID: natxo - i will read through those pages today. i guess i should just be able to point it from my OpenDJ server to my IPA server...just use kerberos tim On Wed, Nov 28, 2012 at 11:25 PM, Natxo Asenjo wrote: > hi, > > On Wed, Nov 28, 2012 at 12:02 AM, Tim Wissman > wrote: > > > > Folks - I have started using FreeIPA and have tried to download the > Solaris > > 10 nss-ldap for the intel platform, but when i tried to save the file i > > received an error saying the server had issues. I was able to download > the > > SPARC package from the same site. If someone could look into it, it could > > just be a permissions problem. > > > > As for Solaris 11, has there been any work in that direction yet? > > > I have not tested with solaris 10, but I can confirm that it works > with openindiana (former opensolaris) using the instructions in > > http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html > > I posted a while ago a problem with this when using dhcp (see > archives: > https://www.redhat.com/archives/freeipa-users/2012-September/thread.html#00001 > , > look for 'openindiana' and you will find the whole thread). As > Sigbjorn Lie pointed, you can use a DUAprofile which *just works*. > -- > Groeten, > natxo > > _______________________________________________ > 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 chillermillerlong at hotmail.com Thu Nov 29 08:42:00 2012 From: chillermillerlong at hotmail.com (=?gb2312?B?0KHB+iCzwg==?=) Date: Thu, 29 Nov 2012 03:42:00 -0500 Subject: [Freeipa-users] FreeIPA manual PAM setup help Message-ID: Hi, I've been working on porting the FreeIPA client to Arch Linux lately and I'm now to the last step of the puzzle. Everything works the way it should, except for PAM, which I don't know how to setup. I must admit that I'm very confused my the PAM configuration (which PAM module does what, the order of the modules, etc). What I'm trying to find out is where the pam_sss.so lines should go. Here's a copy of the /etc/pam.d/ directory in Arch Linux: http://ompldr.org/vZ2hxcw/pam.d.tar.bz2 I'd greatly appreciate it if someone could help me out :) Thanks! Best Regards, Xiao-Long Chen -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.hogarth at gmail.com Thu Nov 29 12:16:30 2012 From: james.hogarth at gmail.com (James Hogarth) Date: Thu, 29 Nov 2012 12:16:30 +0000 Subject: [Freeipa-users] ttl settings for host records In-Reply-To: <50B4E1C6.5060501@redhat.com> References: <50B4E1C6.5060501@redhat.com> Message-ID: > > I'm not entirely sure where that 86400 came from. When we do a dynamic > update the TTL is hardcoded to 1200. There is a ticket to make this > configurable, https://fedorahosted.org/**freeipa/ticket/3031 > > > The patch I submitted on the SSSD side has actually been committed in 1.10 ... The report and patch I had there was about getting ipa-client-install to configure sssd.conf appropriately for sssd ... rather than changing the TTL after the system was first registered... Still trying to find time to work on the TTL this side within IPA GUI rather than just CLI (have it exposed in IPA... working on modifying it at the moment but still have one TTL per primary key rather than split it out entirely). James -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Nov 29 15:26:00 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 29 Nov 2012 10:26:00 -0500 Subject: [Freeipa-users] FreeIPA manual PAM setup help In-Reply-To: References: Message-ID: <50B77E88.9040500@redhat.com> ?? ? wrote: > Hi, > > I've been working on porting the FreeIPA client to Arch Linux lately and > I'm now to the last step of the puzzle. Everything works the way it > should, except for PAM, which I don't know how to setup. > > I must admit that I'm very confused my the PAM configuration (which PAM > module does what, the order of the modules, etc). What I'm trying to > find out is where the pam_sss.so lines should go. Here's a copy of the > /etc/pam.d/ directory in Arch Linux: http://ompldr.org/vZ2hxcw/pam.d.tar.bz2 > > I'd greatly appreciate it if someone could help me out :) Thanks! > I gather that this is due to a lack of authconfig. Timo Aaltonen has been working on ipa-client (and server!) for Ubuntu and he ran into similar problems but I'm not sure what solution he came up with. I'll find someone with more PAM experience to try to give you more practical help. rob From pspacek at redhat.com Thu Nov 29 15:51:28 2012 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 29 Nov 2012 16:51:28 +0100 Subject: [Freeipa-users] ttl settings for host records In-Reply-To: References: <50B4E1C6.5060501@redhat.com> Message-ID: <50B78480.6020101@redhat.com> On 11/29/2012 01:16 PM, James Hogarth wrote: > > > I'm not entirely sure where that 86400 came from. When we do a dynamic > update the TTL is hardcoded to 1200. There is a ticket to make this > configurable, https://fedorahosted.org/__freeipa/ticket/3031 > > > > The patch I submitted on the SSSD side has actually been committed in 1.10 ... > The report and patch I had there was about getting ipa-client-install to > configure sssd.conf appropriately for sssd ... rather than changing the TTL > after the system was first registered... > > Still trying to find time to work on the TTL this side within IPA GUI rather > than just CLI (have it exposed in IPA... working on modifying it at the moment > but still have one TTL per primary key rather than split it out entirely). I'm not sure if I understood your intention correctly, but current IPA LDAP schema can't handle more than single TTL value per DNS name. I.e. all records under single name (e.g. machine.example.com) has to have same TTL value. -- Petr^2 Spacek From jhrozek at redhat.com Thu Nov 29 15:56:08 2012 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 29 Nov 2012 16:56:08 +0100 Subject: [Freeipa-users] FreeIPA manual PAM setup help In-Reply-To: <50B77E88.9040500@redhat.com> References: <50B77E88.9040500@redhat.com> Message-ID: <20121129155608.GA2534@hendrix.brq.redhat.com> On Thu, Nov 29, 2012 at 10:26:00AM -0500, Rob Crittenden wrote: > ?? ? wrote: > >Hi, > > > >I've been working on porting the FreeIPA client to Arch Linux lately and > >I'm now to the last step of the puzzle. Everything works the way it > >should, except for PAM, which I don't know how to setup. > > > >I must admit that I'm very confused my the PAM configuration (which PAM > >module does what, the order of the modules, etc). What I'm trying to > >find out is where the pam_sss.so lines should go. Here's a copy of the > >/etc/pam.d/ directory in Arch Linux: http://ompldr.org/vZ2hxcw/pam.d.tar.bz2 > > > >I'd greatly appreciate it if someone could help me out :) Thanks! > > > > I gather that this is due to a lack of authconfig. > > Timo Aaltonen has been working on ipa-client (and server!) for > Ubuntu and he ran into similar problems but I'm not sure what > solution he came up with. > > I'll find someone with more PAM experience to try to give you more > practical help. > > rob Hi, the PAM config files on Arch Linux are a little bit different than what Fedora/RHEL uses. It seems that the per-service config files (such as /etc/pam.d/su for logging in with su) directly include the PAM modules, in your case pam_unix.so only. On Fedora/RHEL, the per-service files usually include a more generic file called something like system-auth. Either way works, but if you'd like to configure more services in a similar way, then including a common file might save you some edits. This document is a little outdated but provides a nice intro into configuring PAM: http://tldp.org/HOWTO/User-Authentication-HOWTO/x115.html In general you there are fours stacks in PAM, each of them controls one step in the auth process. I think you'll want to use both pam_unix and pam_sss in all the stacks -- pam_sss is needed for users coming in from the SSSD to log in and you'll also want to keep pam_unix around so that local users (at least root) can log in too. Here is what my PAM config on Fedora 18 looks like: -------------------------------------------------------------------- auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 1000 quiet_success auth sufficient pam_sss.so use_first_pass auth required pam_deny.so account required pam_unix.so broken_shadow account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 1000 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so password optional pam_pwquality.so try_first_pass retry=3 type= password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password sufficient pam_sss.so use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd.so session optional pam_oddjob_mkhomedir.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so -------------------------------------------------------------------- If Arch Linux ships the same modules as Fedora, the you should be able to simply copy and use the PAM config we use.. I've put Honza to CC, I know he runs Arch Linux as well and might have some insights into how PAM is configured on Arch. From chillermillerlong at hotmail.com Thu Nov 29 18:56:24 2012 From: chillermillerlong at hotmail.com (=?gb2312?B?0KHB+iCzwg==?=) Date: Thu, 29 Nov 2012 13:56:24 -0500 Subject: [Freeipa-users] FreeIPA manual PAM setup help In-Reply-To: <50B77E88.9040500@redhat.com> References: , <50B77E88.9040500@redhat.com> Message-ID: > Date: Thu, 29 Nov 2012 10:26:00 -0500 > From: rcritten at redhat.com > To: chillermillerlong at hotmail.com > CC: freeipa-users at redhat.com; tjaalton at ubuntu.com > Subject: Re: [Freeipa-users] FreeIPA manual PAM setup help > > ?? ? wrote: > > Hi, > > > > I've been working on porting the FreeIPA client to Arch Linux lately and > > I'm now to the last step of the puzzle. Everything works the way it > > should, except for PAM, which I don't know how to setup. > > > > I must admit that I'm very confused my the PAM configuration (which PAM > > module does what, the order of the modules, etc). What I'm trying to > > find out is where the pam_sss.so lines should go. Here's a copy of the > > /etc/pam.d/ directory in Arch Linux: http://ompldr.org/vZ2hxcw/pam.d.tar.bz2 > > > > I'd greatly appreciate it if someone could help me out :) Thanks! > > > > I gather that this is due to a lack of authconfig. > > Timo Aaltonen has been working on ipa-client (and server!) for Ubuntu > and he ran into similar problems but I'm not sure what solution he came > up with. > > I'll find someone with more PAM experience to try to give you more > practical help. > > rob Hi Rob, Thanks a lot for your reply! You;re right that this is due to the lack or authconfig (or any other tool to manage the PAM settings). I took a look at Ubuntu's packaging and it seems that Ubuntu's PAM is similar to Fedora's. Fedora uses a common /etc/pam.d/system-auth file and Ubuntu uses a common /etc/pam.d/common-auth file. Arch doesn't have a common PAM configuration file, so I'll need to change every file for every service that I want to authenticate with sssd. I didn't know that ipa-server is now working in Ubuntu. That's really great news! Best regards, Xiao-Long Chen -------------- next part -------------- An HTML attachment was scrubbed... URL: From chillermillerlong at hotmail.com Thu Nov 29 19:02:45 2012 From: chillermillerlong at hotmail.com (=?gb2312?B?0KHB+iCzwg==?=) Date: Thu, 29 Nov 2012 14:02:45 -0500 Subject: [Freeipa-users] FreeIPA manual PAM setup help In-Reply-To: <20121129155608.GA2534@hendrix.brq.redhat.com> References: , <50B77E88.9040500@redhat.com>, <20121129155608.GA2534@hendrix.brq.redhat.com> Message-ID: > Date: Thu, 29 Nov 2012 16:56:08 +0100 > From: jhrozek at redhat.com > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] FreeIPA manual PAM setup help > > On Thu, Nov 29, 2012 at 10:26:00AM -0500, Rob Crittenden wrote: > > ?? ? wrote: > > >Hi, > > > > > >I've been working on porting the FreeIPA client to Arch Linux lately and > > >I'm now to the last step of the puzzle. Everything works the way it > > >should, except for PAM, which I don't know how to setup. > > > > > >I must admit that I'm very confused my the PAM configuration (which PAM > > >module does what, the order of the modules, etc). What I'm trying to > > >find out is where the pam_sss.so lines should go. Here's a copy of the > > >/etc/pam.d/ directory in Arch Linux: http://ompldr.org/vZ2hxcw/pam.d.tar.bz2 > > > > > >I'd greatly appreciate it if someone could help me out :) Thanks! > > > > > > > I gather that this is due to a lack of authconfig. > > > > Timo Aaltonen has been working on ipa-client (and server!) for > > Ubuntu and he ran into similar problems but I'm not sure what > > solution he came up with. > > > > I'll find someone with more PAM experience to try to give you more > > practical help. > > > > rob > > Hi, > > the PAM config files on Arch Linux are a little bit different than what > Fedora/RHEL uses. It seems that the per-service config files (such as > /etc/pam.d/su for logging in with su) directly include the PAM modules, > in your case pam_unix.so only. On Fedora/RHEL, the per-service files > usually include a more generic file called something like system-auth. > > Either way works, but if you'd like to configure more services in a > similar way, then including a common file might save you some edits. > > This document is a little outdated but provides a nice intro into > configuring PAM: > http://tldp.org/HOWTO/User-Authentication-HOWTO/x115.html > > In general you there are fours stacks in PAM, each of them controls one > step in the auth process. > > I think you'll want to use both pam_unix and pam_sss in all the > stacks -- pam_sss is needed for users coming in from the SSSD to log in > and you'll also want to keep pam_unix around so that local users (at > least root) can log in too. > > Here is what my PAM config on Fedora 18 looks like: > -------------------------------------------------------------------- > auth required pam_env.so > auth sufficient pam_unix.so nullok try_first_pass > auth requisite pam_succeed_if.so uid >= 1000 quiet_success > auth sufficient pam_sss.so use_first_pass > auth required pam_deny.so > > account required pam_unix.so broken_shadow > account sufficient pam_localuser.so > account sufficient pam_succeed_if.so uid < 1000 quiet > account [default=bad success=ok user_unknown=ignore] pam_sss.so > account required pam_permit.so > > password optional pam_pwquality.so try_first_pass retry=3 type= > password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok > password sufficient pam_sss.so use_authtok > password required pam_deny.so > > session optional pam_keyinit.so revoke > session required pam_limits.so > -session optional pam_systemd.so > session optional pam_oddjob_mkhomedir.so > session [success=1 default=ignore] pam_succeed_if.so service in > crond quiet use_uid > session required pam_unix.so > session optional pam_sss.so > -------------------------------------------------------------------- > > If Arch Linux ships the same modules as Fedora, the you should be able to > simply copy and use the PAM config we use.. I've put Honza to CC, I know > he runs Arch Linux as well and might have some insights into how PAM is > configured on Arch. > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users Hi, Thanks a lot for your reply! I'll be sure to read up on the link. The per-service config files are a bit annoying in Arch. I'm not sure if it's possible, but maybe I can create a /etc/pam.d/sssd that can be included in the other files? I'm guessing that the order of the PAM modules matters, so I'm not sure that that would work. I'll try adding pam_sss to each file, based on Fedora's system-auth, and see how that goes. Best Regards, Xiao-Long Chen -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Thu Nov 29 19:30:01 2012 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 29 Nov 2012 20:30:01 +0100 Subject: [Freeipa-users] FreeIPA manual PAM setup help In-Reply-To: References: <50B77E88.9040500@redhat.com> Message-ID: <20121129193001.GD2534@hendrix.brq.redhat.com> On Thu, Nov 29, 2012 at 01:56:24PM -0500, ?? ? wrote: > I didn't know that ipa-server is now working in Ubuntu. That's really great news! > > Best regards, > Xiao-Long Chen > I could be wrong, but I don't think the IPA server is working in Ubuntu..I know the client bits are and there was an effort to package the server as well, but I don't think it's finished yet. Timo would know better, though.. From tjaalton at ubuntu.com Thu Nov 29 21:41:03 2012 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Thu, 29 Nov 2012 23:41:03 +0200 Subject: [Freeipa-users] FreeIPA status on Debian & Ubuntu (was: Re: FreeIPA manual PAM setup help) In-Reply-To: <20121129193001.GD2534@hendrix.brq.redhat.com> References: <50B77E88.9040500@redhat.com> <20121129193001.GD2534@hendrix.brq.redhat.com> Message-ID: <50B7D66F.4040108@ubuntu.com> 29.11.2012 21:30, Jakub Hrozek kirjoitti: > On Thu, Nov 29, 2012 at 01:56:24PM -0500, ?? ? wrote: >> I didn't know that ipa-server is now working in Ubuntu. That's really great news! >> >> Best regards, >> Xiao-Long Chen >> > > I could be wrong, but I don't think the IPA server is working in > Ubuntu..I know the client bits are and there was an effort to package > the server as well, but I don't think it's finished yet. right, the server isn't ready, client is limping along though not seen an update in a while. > Timo would know better, though. here's a short summary: - 389ds is packaged and included in Debian & Ubuntu - Dogtag 9 is packaged in git and worked the last time I tried, not pushed to either distros, since.. - Dogtag 10 is close(?) and I'd rather skip the transition if possible, then again.. - D10 needs RESTEasy, which in turn depends on nearly 50 new bits of software that needs to be packaged, mostly java/maven based (and there's a helper that should automate most of the packaging, haven't tried it yet though) - IPA server still needs the platform code rework, and I still need to rework the first patch to meet the review notes so not quite there yet :) t From chillermillerlong at hotmail.com Thu Nov 29 22:18:16 2012 From: chillermillerlong at hotmail.com (=?gb2312?B?0KHB+iCzwg==?=) Date: Thu, 29 Nov 2012 17:18:16 -0500 Subject: [Freeipa-users] FreeIPA status on Debian & Ubuntu (was: Re: FreeIPA manual PAM setup help) In-Reply-To: <50B7D66F.4040108@ubuntu.com> References: , <50B77E88.9040500@redhat.com>, , <20121129193001.GD2534@hendrix.brq.redhat.com>, <50B7D66F.4040108@ubuntu.com> Message-ID: > Date: Thu, 29 Nov 2012 23:41:03 +0200 > From: tjaalton at ubuntu.com > To: jhrozek at redhat.com > CC: freeipa-users at redhat.com > Subject: [Freeipa-users] FreeIPA status on Debian & Ubuntu (was: Re: FreeIPA manual PAM setup help) > > 29.11.2012 21:30, Jakub Hrozek kirjoitti: > > On Thu, Nov 29, 2012 at 01:56:24PM -0500, ?? ? wrote: > >> I didn't know that ipa-server is now working in Ubuntu. That's really great news! > >> > >> Best regards, > >> Xiao-Long Chen > >> > > > > I could be wrong, but I don't think the IPA server is working in > > Ubuntu..I know the client bits are and there was an effort to package > > the server as well, but I don't think it's finished yet. > > right, the server isn't ready, client is limping along though not seen > an update in a while. > > > Timo would know better, though. > > here's a short summary: > > - 389ds is packaged and included in Debian & Ubuntu > - Dogtag 9 is packaged in git and worked the last time I tried, not > pushed to either distros, since.. > - Dogtag 10 is close(?) and I'd rather skip the transition if possible, > then again.. > - D10 needs RESTEasy, which in turn depends on nearly 50 new bits of > software that needs to be packaged, mostly java/maven based (and > there's a helper that should automate most of the packaging, haven't > tried it yet though) > - IPA server still needs the platform code rework, and I still need to > rework the first patch to meet the review notes > > so not quite there yet :) > > t > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users Could you post a link to the git repo (if it's public)? I'd like to test out the work in progress :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From JR.Aquino at citrix.com Thu Nov 29 23:43:28 2012 From: JR.Aquino at citrix.com (JR Aquino) Date: Thu, 29 Nov 2012 23:43:28 +0000 Subject: [Freeipa-users] RHEL6.3 Install Problem with IPA Message-ID: I have a weird ipa-replica-install problem that I have not been able to work around. I have managed to successfully reproduce and identify the root cause of my pain, but I don't understand why its coming up... My install fails with: Starting httpd: (98)Address already in use: make_sock: could not bind to address 0.0.0.0:80 After much head scratching, I finally was able to reproduce the problem: If you start httpd as the install script does, it gives the following: service httpd start Starting httpd: Please enter password for "internal" token: This process doesn't create the pidfile and essentially hangs httpd on 80 and 443 When the restart process is later called, you get the message that the installer is throwing: service httpd restart Stopping httpd: [FAILED] Starting httpd: (98)Address already in use: make_sock: could not bind to address 0.0.0.0:80 no listening sockets available, shutting down Unable to open logs [FAILED] I've verified that the content of /etc/httpd/conf/password.conf is valid and will 'authenticate' if passed to that internal token prompt... mod_nss is clearly the piece that is causing the prompting but I'm not sure what is breaking here or how I can work around it. Can someone help? "Keeping your head in the cloud" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jr Aquino | Sr. Information Security Specialist GIAC Exploit Researcher and Advanced Penetration Tester | GIAC Certified Incident Handler | GIAC WebApp Penetration Tester Citrix Online | 7408 Hollister Avenue | Goleta, CA 93117 T: +1 805.690.3478 C: +1 805.717.0365 jr.aquino at citrix.com http://www.citrixonline.com From Steven.Jones at vuw.ac.nz Thu Nov 29 23:49:08 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Thu, 29 Nov 2012 23:49:08 +0000 Subject: [Freeipa-users] One time passwords - 2 factor Message-ID: <833D8E48405E064EBC54C84EC6B36E405472781F@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, Is it possible to use the freeipa API and and external program to do one time passwords? (password is sent by the external app, sms to smartphone). regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 From rcritten at redhat.com Fri Nov 30 01:34:52 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 29 Nov 2012 20:34:52 -0500 Subject: [Freeipa-users] RHEL6.3 Install Problem with IPA In-Reply-To: References: Message-ID: <50B80D3C.9090509@redhat.com> JR Aquino wrote: > I have a weird ipa-replica-install problem that I have not been able to work around. > > I have managed to successfully reproduce and identify the root cause of my pain, but I don't understand why its coming up... > > My install fails with: > Starting httpd: (98)Address already in use: make_sock: could not bind to address 0.0.0.0:80 > > > After much head scratching, I finally was able to reproduce the problem: > > If you start httpd as the install script does, it gives the following: > > service httpd start > Starting httpd: Please enter password for "internal" token: > > This process doesn't create the pidfile and essentially hangs httpd on 80 and 443 > > When the restart process is later called, you get the message that the installer is throwing: > > service httpd restart > Stopping httpd: [FAILED] > Starting httpd: (98)Address already in use: make_sock: could not bind to address 0.0.0.0:80 > no listening sockets available, shutting down > Unable to open logs > [FAILED] > > > I've verified that the content of /etc/httpd/conf/password.conf is valid and will 'authenticate' if passed to that internal token prompt... > > mod_nss is clearly the piece that is causing the prompting but I'm not sure what is breaking here or how I can work around it. > > Can someone help? What version of mod_nss is this? Can you see if there are SELinux or permission errors? Maybe password.conf can't be read. rob From rcritten at redhat.com Fri Nov 30 01:43:45 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 29 Nov 2012 20:43:45 -0500 Subject: [Freeipa-users] One time passwords - 2 factor In-Reply-To: <833D8E48405E064EBC54C84EC6B36E405472781F@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E405472781F@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <50B80F51.4070906@redhat.com> Steven Jones wrote: > Hi, > > Is it possible to use the freeipa API and and external program to do one time passwords? (password is sent by the external app, sms to smartphone). Not yet. The problem is lack of support in the KDC and this is being actively worked on. We did a proof-of-concept at the Red Hat Summit a couple of years ago using a Yubikey as the OTP source. It was, as they say in New England, wicked cool. It was very much hardcoded though. AFAIK they are working on a plugin interface to make this much easier to do. A lot of the work is being done here: https://fedorahosted.org/AuthHub/ rob From chillermillerlong at hotmail.com Fri Nov 30 01:55:57 2012 From: chillermillerlong at hotmail.com (=?gb2312?B?0KHB+iCzwg==?=) Date: Thu, 29 Nov 2012 20:55:57 -0500 Subject: [Freeipa-users] FreeIPA manual PAM setup help In-Reply-To: <20121129193001.GD2534@hendrix.brq.redhat.com> References: , <50B77E88.9040500@redhat.com>, , <20121129193001.GD2534@hendrix.brq.redhat.com> Message-ID: > Date: Thu, 29 Nov 2012 20:30:01 +0100 > From: jhrozek at redhat.com > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] FreeIPA manual PAM setup help > > On Thu, Nov 29, 2012 at 01:56:24PM -0500, ?? ? wrote: > > I didn't know that ipa-server is now working in Ubuntu. That's really great news! > > > > Best regards, > > Xiao-Long Chen > > > > I could be wrong, but I don't think the IPA server is working in > Ubuntu..I know the client bits are and there was an effort to package > the server as well, but I don't think it's finished yet. > > Timo would know better, though.. > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users And PAM is working! I've just finished a helper for setting up NSS and PAM for sssd. It basically does the following: 1. Looks for 'passwd', 'shadow', 'group', 'services', 'netgroup', and 'automount' in /etc/nsswitch.conf and adds 'sss' to it. 2. Looks for pam_unix.so in every file in /etc/pam.d/, changes 'required' to 'sufficient', and adds an 'include' line for 'sss' right below itq. /etc/pam.d/sss contains the pam_sss.so lines. So far, I've tested sudo and su, and both are working :) Here's a link to the script: https://github.com/chenxiaolong/ArchLinux-Packages/blob/master/freeipa/sss-auth-setup.py If someone is bored, I'd appreciate it if he/she would take a look at it for glaring issues. Best regards, Xiao-Long Chen -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Fri Nov 30 02:08:02 2012 From: simo at redhat.com (Simo Sorce) Date: Thu, 29 Nov 2012 21:08:02 -0500 Subject: [Freeipa-users] FreeIPA manual PAM setup help In-Reply-To: References: , <50B77E88.9040500@redhat.com> , , <20121129193001.GD2534@hendrix.brq.redhat.com> Message-ID: <1354241282.19871.98.camel@willson.li.ssimo.org> On Thu, 2012-11-29 at 20:55 -0500, ?? ? wrote: > And PAM is working! Excellent! > I've just finished a helper for setting up NSS and PAM for sssd. It > basically does the following: > > 1. Looks for 'passwd', 'shadow', 'group', 'services', 'netgroup', and > 'automount' > in /etc/nsswitch.conf and adds 'sss' to it. SSSD does not provide a shadow map so you shouldn't ad sss to shadow. It will do no harm though, it will just be a noop. > 2. Looks for pam_unix.so in every file in /etc/pam.d/, changes > 'required' > to 'sufficient', and adds an 'include' line for 'sss' right below > itq. /etc/pam.d/sss > contains the pam_sss.so lines. > > So far, I've tested sudo and su, and both are working :) > > Here's a link to the script: > https://github.com/chenxiaolong/ArchLinux-Packages/blob/master/freeipa/sss-auth-setup.py > > If someone is bored, I'd appreciate it if he/she would take a look at > it > for glaring issues. Cool stuff, I do not know Arch Linux default PAm stack configuration so I can;t tell with certainty that the replace you make is perfect, but I do not see anything stunningly bad. Simo. -- Simo Sorce * Red Hat, Inc * New York From chillermillerlong at hotmail.com Fri Nov 30 02:40:34 2012 From: chillermillerlong at hotmail.com (=?gb2312?B?0KHB+iCzwg==?=) Date: Thu, 29 Nov 2012 21:40:34 -0500 Subject: [Freeipa-users] FreeIPA manual PAM setup help In-Reply-To: <1354241282.19871.98.camel@willson.li.ssimo.org> References: ,, <50B77E88.9040500@redhat.com>,, ,, <20121129193001.GD2534@hendrix.brq.redhat.com>, , <1354241282.19871.98.camel@willson.li.ssimo.org> Message-ID: > Subject: Re: [Freeipa-users] FreeIPA manual PAM setup help > From: simo at redhat.com > To: chillermillerlong at hotmail.com > CC: jhrozek at redhat.com; freeipa-users at redhat.com > Date: Thu, 29 Nov 2012 21:08:02 -0500 > > On Thu, 2012-11-29 at 20:55 -0500, ?? ? wrote: > > > > And PAM is working! > > Excellent! > > > I've just finished a helper for setting up NSS and PAM for sssd. It > > basically does the following: > > > > 1. Looks for 'passwd', 'shadow', 'group', 'services', 'netgroup', and > > 'automount' > > in /etc/nsswitch.conf and adds 'sss' to it. > > SSSD does not provide a shadow map so you shouldn't ad sss to shadow. It > will do no harm though, it will just be a noop. I see. I'll remove that part that. I just saw that Fedora's authconfig adds it by default. > > > 2. Looks for pam_unix.so in every file in /etc/pam.d/, changes > > 'required' > > to 'sufficient', and adds an 'include' line for 'sss' right below > > itq. /etc/pam.d/sss > > contains the pam_sss.so lines. > > > > So far, I've tested sudo and su, and both are working :) > > > > Here's a link to the script: > > https://github.com/chenxiaolong/ArchLinux-Packages/blob/master/freeipa/sss-auth-setup.py > > > > If someone is bored, I'd appreciate it if he/she would take a look at > > it > > for glaring issues. > > Cool stuff, I do not know Arch Linux default PAm stack configuration so > I can;t tell with certainty that the replace you make is perfect, but I > do not see anything stunningly bad. Thanks for taking a look at the script! I'm having some ssh issues now, unfortunately. Password authentication works find, but GSSAPI doesn't. The client always fails "Connection closed by UNKNOWN" Client: http://paste.kde.org/617216/ Server: http://paste.kde.org/617222/ Interestingly enough, the server logs nothing (with GSSAPI) unless I set it to log debug messages. Anyways, I'll have to look at this tomorrow. I'm not going to finish my homework :) Xiao-Long Chen -------------- next part -------------- An HTML attachment was scrubbed... URL: From rendhalver at gmail.com Fri Nov 30 02:55:07 2012 From: rendhalver at gmail.com (Peter Brown) Date: Fri, 30 Nov 2012 12:55:07 +1000 Subject: [Freeipa-users] One time passwords - 2 factor In-Reply-To: <50B80F51.4070906@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E405472781F@STAWINCOX10MBX1.staff.vuw.ac.nz> <50B80F51.4070906@redhat.com> Message-ID: On 30 November 2012 11:43, Rob Crittenden wrote: > Steven Jones wrote: > >> Hi, >> >> Is it possible to use the freeipa API and and external program to do one >> time passwords? (password is sent by the external app, sms to smartphone). >> > > Not yet. The problem is lack of support in the KDC and this is being > actively worked on. > > We did a proof-of-concept at the Red Hat Summit a couple of years ago > using a Yubikey as the OTP source. It was, as they say in New England, > wicked cool. > > It was very much hardcoded though. AFAIK they are working on a plugin > interface to make this much easier to do. A lot of the work is being done > here: https://fedorahosted.org/**AuthHub/ Awesome! Looking forward to that. If I had some spare time I could contribute... > > > rob > > > ______________________________**_________________ > 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 natxo.asenjo at gmail.com Fri Nov 30 12:06:12 2012 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Fri, 30 Nov 2012 13:06:12 +0100 Subject: [Freeipa-users] libvirt with vnc freeipa Message-ID: hi, I'm following the howto on http://freeipa.org/page/Libvirt_with_VNC_Consoles to authenticate users voor virsh with ipa. I have it mostly working :-) except for the fact that libvirtd is not respecting the sasl_allowed_username_list parameter. If I do not set it, and I have a realm ticket, then I may login virsh or virtual manager and I get tickets for libvirt/vnc services. If I do set it, then it tells me the client is not in the whitelist, so I cannot log in :-) 2012-11-30 12:00:53.403+0000: 7786: error : virNetSASLContextCheckIdentity:146 : SASL client admin not allowed in whitelist 2012-11-30 12:00:53.403+0000: 7786: error : virNetSASLContextCheckIdentity:150 : Client's username is not on the list of allowed clients 2012-11-30 12:00:53.403+0000: 7786: error : remoteDispatchAuthSaslStep:2447 : authentication failed: authentication failed 2012-11-30 12:00:53.415+0000: 7781: error : virNetSocketReadWire:999 : End of file while reading data: Input/output error Is this a question for the libvirt folks or is it ok to post it here? -- Groeten, natxo From tjaalton at ubuntu.com Fri Nov 30 13:18:08 2012 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Fri, 30 Nov 2012 15:18:08 +0200 Subject: [Freeipa-users] FreeIPA status on Debian & Ubuntu In-Reply-To: References: , <50B77E88.9040500@redhat.com>, , <20121129193001.GD2534@hendrix.brq.redhat.com>, <50B7D66F.4040108@ubuntu.com> Message-ID: <50B8B210.7050608@ubuntu.com> 30.11.2012 00:18, ?? ? kirjoitti: > Could you post a link to the git repo (if it's public)? I'd like to test > out the > work in progress :) it's all on http://anonscm.debian.org/gitweb/ check out pkg-sssd/*, pkg-fedora-ds/* and pkg-freeipa/* if you have questions, use #ubuntu-freeipa on freenode. From simo at redhat.com Fri Nov 30 14:25:34 2012 From: simo at redhat.com (Simo Sorce) Date: Fri, 30 Nov 2012 09:25:34 -0500 Subject: [Freeipa-users] libvirt with vnc freeipa In-Reply-To: References: Message-ID: <1354285534.19871.113.camel@willson.li.ssimo.org> Hi Natxo, On Fri, 2012-11-30 at 13:06 +0100, Natxo Asenjo wrote: > hi, > > I'm following the howto on > http://freeipa.org/page/Libvirt_with_VNC_Consoles to authenticate > users voor virsh with ipa. > > I have it mostly working :-) except for the fact that libvirtd is not > respecting the sasl_allowed_username_list parameter. > > If I do not set it, and I have a realm ticket, then I may login virsh > or virtual manager and I get tickets for libvirt/vnc services. > > If I do set it, then it tells me the client is not in the whitelist, > so I cannot log in :-) > > > 2012-11-30 12:00:53.403+0000: 7786: error : > virNetSASLContextCheckIdentity:146 : SASL client admin not allowed in > whitelist > 2012-11-30 12:00:53.403+0000: 7786: error : > virNetSASLContextCheckIdentity:150 : Client's username is not on the > list of allowed clients > 2012-11-30 12:00:53.403+0000: 7786: error : > remoteDispatchAuthSaslStep:2447 : authentication failed: > authentication failed > 2012-11-30 12:00:53.415+0000: 7781: error : virNetSocketReadWire:999 : > End of file while reading data: Input/output error > > Is this a question for the libvirt folks or is it ok to post it here? Seem more like a libvirt or maybe even a cyrus-sasl question but I would be interested in knowing what is going on. Have you used a full principal name including the realm in the list, or just the bare user names ? CCing libvirt-users. Simo. -- Simo Sorce * Red Hat, Inc * New York From natxo.asenjo at gmail.com Fri Nov 30 14:56:14 2012 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Fri, 30 Nov 2012 15:56:14 +0100 Subject: [Freeipa-users] [libvirt-users] libvirt with vnc freeipa In-Reply-To: <20121130144259.GH25966@redhat.com> References: <1354285534.19871.113.camel@willson.li.ssimo.org> <20121130144259.GH25966@redhat.com> Message-ID: hi, sasl_allowed_username_list = ["admin at IPA.EXAMPLE.COM" ] if I leave this field commented out (default setting), everybody can manage the kvm host. -- Groeten, natxo On Fri, Nov 30, 2012 at 3:42 PM, Daniel P. Berrange wrote: > On Fri, Nov 30, 2012 at 09:25:34AM -0500, Simo Sorce wrote: >> Hi Natxo, >> >> On Fri, 2012-11-30 at 13:06 +0100, Natxo Asenjo wrote: >> > hi, >> > >> > I'm following the howto on >> > http://freeipa.org/page/Libvirt_with_VNC_Consoles to authenticate >> > users voor virsh with ipa. >> > >> > I have it mostly working :-) except for the fact that libvirtd is not >> > respecting the sasl_allowed_username_list parameter. >> > >> > If I do not set it, and I have a realm ticket, then I may login virsh >> > or virtual manager and I get tickets for libvirt/vnc services. >> > >> > If I do set it, then it tells me the client is not in the whitelist, >> > so I cannot log in :-) > > That indicates the client identity is not matching against the whitelist. > What are you setting it to ? > >> > 2012-11-30 12:00:53.403+0000: 7786: error : >> > virNetSASLContextCheckIdentity:146 : SASL client admin not allowed in >> > whitelist >> > 2012-11-30 12:00:53.403+0000: 7786: error : >> > virNetSASLContextCheckIdentity:150 : Client's username is not on the >> > list of allowed clients >> > 2012-11-30 12:00:53.403+0000: 7786: error : >> > remoteDispatchAuthSaslStep:2447 : authentication failed: >> > authentication failed >> > 2012-11-30 12:00:53.415+0000: 7781: error : virNetSocketReadWire:999 : >> > End of file while reading data: Input/output error >> > >> > Is this a question for the libvirt folks or is it ok to post it here? >> >> Seem more like a libvirt or maybe even a cyrus-sasl question but I would >> be interested in knowing what is going on. >> >> Have you used a full principal name including the realm in the list, or >> just the bare user names ? > > Daniel > -- > |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| > |: http://libvirt.org -o- http://virt-manager.org :| > |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| > |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| From natxo.asenjo at gmail.com Fri Nov 30 15:16:56 2012 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Fri, 30 Nov 2012 16:16:56 +0100 Subject: [Freeipa-users] [libvirt-users] libvirt with vnc freeipa In-Reply-To: <20121130150444.GI25966@redhat.com> References: <1354285534.19871.113.camel@willson.li.ssimo.org> <20121130144259.GH25966@redhat.com> <20121130150444.GI25966@redhat.com> Message-ID: On Fri, Nov 30, 2012 at 4:04 PM, Daniel P. Berrange wrote: > On Fri, Nov 30, 2012 at 03:56:14PM +0100, Natxo Asenjo wrote: >> hi, >> >> sasl_allowed_username_list = ["admin at IPA.EXAMPLE.COM" ] >> >> if I leave this field commented out (default setting), everybody can >> manage the kvm host. > > Oh it isn't very obvious, but in this log message: > >> >> > 2012-11-30 12:00:53.403+0000: 7786: error : >> >> > virNetSASLContextCheckIdentity:146 : SASL client admin not allowed in > > 'admin' is the identity being matched against. > > We ought to quote that string int he log message to make it more > obvious. > > So I guess SASL/GSSAPI is not giving us back the REALM, just > the username > > So you need to change your whitelist to leave out the realm. Bingo! Thanks. If I may just hijack this thread: is it possible to whitelist groups instead of individual users to use virsh/virtual manager? I know sasl only deals with the authentication stuff, buy here you are also authorizing in the whitelist. If this authorization could go further to allow ipa groups, that would be ideal from an admin point of view ;-) -- groet, natxo From berrange at redhat.com Fri Nov 30 14:42:59 2012 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 30 Nov 2012 14:42:59 +0000 Subject: [Freeipa-users] [libvirt-users] libvirt with vnc freeipa In-Reply-To: <1354285534.19871.113.camel@willson.li.ssimo.org> References: <1354285534.19871.113.camel@willson.li.ssimo.org> Message-ID: <20121130144259.GH25966@redhat.com> On Fri, Nov 30, 2012 at 09:25:34AM -0500, Simo Sorce wrote: > Hi Natxo, > > On Fri, 2012-11-30 at 13:06 +0100, Natxo Asenjo wrote: > > hi, > > > > I'm following the howto on > > http://freeipa.org/page/Libvirt_with_VNC_Consoles to authenticate > > users voor virsh with ipa. > > > > I have it mostly working :-) except for the fact that libvirtd is not > > respecting the sasl_allowed_username_list parameter. > > > > If I do not set it, and I have a realm ticket, then I may login virsh > > or virtual manager and I get tickets for libvirt/vnc services. > > > > If I do set it, then it tells me the client is not in the whitelist, > > so I cannot log in :-) That indicates the client identity is not matching against the whitelist. What are you setting it to ? > > 2012-11-30 12:00:53.403+0000: 7786: error : > > virNetSASLContextCheckIdentity:146 : SASL client admin not allowed in > > whitelist > > 2012-11-30 12:00:53.403+0000: 7786: error : > > virNetSASLContextCheckIdentity:150 : Client's username is not on the > > list of allowed clients > > 2012-11-30 12:00:53.403+0000: 7786: error : > > remoteDispatchAuthSaslStep:2447 : authentication failed: > > authentication failed > > 2012-11-30 12:00:53.415+0000: 7781: error : virNetSocketReadWire:999 : > > End of file while reading data: Input/output error > > > > Is this a question for the libvirt folks or is it ok to post it here? > > Seem more like a libvirt or maybe even a cyrus-sasl question but I would > be interested in knowing what is going on. > > Have you used a full principal name including the realm in the list, or > just the bare user names ? Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| From berrange at redhat.com Fri Nov 30 15:04:44 2012 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 30 Nov 2012 15:04:44 +0000 Subject: [Freeipa-users] [libvirt-users] libvirt with vnc freeipa In-Reply-To: References: <1354285534.19871.113.camel@willson.li.ssimo.org> <20121130144259.GH25966@redhat.com> Message-ID: <20121130150444.GI25966@redhat.com> On Fri, Nov 30, 2012 at 03:56:14PM +0100, Natxo Asenjo wrote: > hi, > > sasl_allowed_username_list = ["admin at IPA.EXAMPLE.COM" ] > > if I leave this field commented out (default setting), everybody can > manage the kvm host. Oh it isn't very obvious, but in this log message: > >> > 2012-11-30 12:00:53.403+0000: 7786: error : > >> > virNetSASLContextCheckIdentity:146 : SASL client admin not allowed in 'admin' is the identity being matched against. We ought to quote that string int he log message to make it more obvious. So I guess SASL/GSSAPI is not giving us back the REALM, just the username So you need to change your whitelist to leave out the realm. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| From berrange at redhat.com Fri Nov 30 15:20:30 2012 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 30 Nov 2012 15:20:30 +0000 Subject: [Freeipa-users] [libvirt-users] libvirt with vnc freeipa In-Reply-To: References: <1354285534.19871.113.camel@willson.li.ssimo.org> <20121130144259.GH25966@redhat.com> <20121130150444.GI25966@redhat.com> Message-ID: <20121130152029.GJ25966@redhat.com> On Fri, Nov 30, 2012 at 04:16:56PM +0100, Natxo Asenjo wrote: > On Fri, Nov 30, 2012 at 4:04 PM, Daniel P. Berrange wrote: > > On Fri, Nov 30, 2012 at 03:56:14PM +0100, Natxo Asenjo wrote: > >> hi, > >> > >> sasl_allowed_username_list = ["admin at IPA.EXAMPLE.COM" ] > >> > >> if I leave this field commented out (default setting), everybody can > >> manage the kvm host. > > > > Oh it isn't very obvious, but in this log message: > > > >> >> > 2012-11-30 12:00:53.403+0000: 7786: error : > >> >> > virNetSASLContextCheckIdentity:146 : SASL client admin not allowed in > > > > 'admin' is the identity being matched against. > > > > We ought to quote that string int he log message to make it more > > obvious. > > > > So I guess SASL/GSSAPI is not giving us back the REALM, just > > the username > > > > So you need to change your whitelist to leave out the realm. > > Bingo! > > Thanks. If I may just hijack this thread: is it possible to whitelist > groups instead of individual users to use virsh/virtual manager? > > I know sasl only deals with the authentication stuff, buy here you are > also authorizing in the whitelist. If this authorization could go > further to allow ipa groups, that would be ideal from an admin point > of view ;-) It is desirable, but we don't have any way to find out information about groups. The authorization problem is something we've yet to really get a good pluggable solution for, though perhaps policykit would help here. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| From simo at redhat.com Fri Nov 30 15:52:47 2012 From: simo at redhat.com (Simo Sorce) Date: Fri, 30 Nov 2012 10:52:47 -0500 Subject: [Freeipa-users] [libvirt-users] libvirt with vnc freeipa In-Reply-To: References: <1354285534.19871.113.camel@willson.li.ssimo.org> <20121130144259.GH25966@redhat.com> <20121130150444.GI25966@redhat.com> Message-ID: <1354290767.19871.114.camel@willson.li.ssimo.org> On Fri, 2012-11-30 at 16:16 +0100, Natxo Asenjo wrote: > On Fri, Nov 30, 2012 at 4:04 PM, Daniel P. Berrange wrote: > > On Fri, Nov 30, 2012 at 03:56:14PM +0100, Natxo Asenjo wrote: > >> hi, > >> > >> sasl_allowed_username_list = ["admin at IPA.EXAMPLE.COM" ] > >> > >> if I leave this field commented out (default setting), everybody can > >> manage the kvm host. > > > > Oh it isn't very obvious, but in this log message: > > > >> >> > 2012-11-30 12:00:53.403+0000: 7786: error : > >> >> > virNetSASLContextCheckIdentity:146 : SASL client admin not allowed in > > > > 'admin' is the identity being matched against. > > > > We ought to quote that string int he log message to make it more > > obvious. > > > > So I guess SASL/GSSAPI is not giving us back the REALM, just > > the username > > > > So you need to change your whitelist to leave out the realm. > > Bingo! > > Thanks. If I may just hijack this thread: is it possible to whitelist > groups instead of individual users to use virsh/virtual manager? > > I know sasl only deals with the authentication stuff, buy here you are > also authorizing in the whitelist. If this authorization could go > further to allow ipa groups, that would be ideal from an admin point > of view ;-) Natxo it sounds odd that you are getting back a non fully qualified principal name, are you sure your configuration is using SASL/GSSAPI ? What other directives have you configured ? Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Fri Nov 30 16:33:30 2012 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 30 Nov 2012 11:33:30 -0500 Subject: [Freeipa-users] [libvirt-users] libvirt with vnc freeipa In-Reply-To: <20121130152029.GJ25966@redhat.com> References: <1354285534.19871.113.camel@willson.li.ssimo.org> <20121130144259.GH25966@redhat.com> <20121130150444.GI25966@redhat.com> <20121130152029.GJ25966@redhat.com> Message-ID: <50B8DFDA.3060608@redhat.com> On 11/30/2012 10:20 AM, Daniel P. Berrange wrote: > On Fri, Nov 30, 2012 at 04:16:56PM +0100, Natxo Asenjo wrote: >> On Fri, Nov 30, 2012 at 4:04 PM, Daniel P. Berrange wrote: >>> On Fri, Nov 30, 2012 at 03:56:14PM +0100, Natxo Asenjo wrote: >>>> hi, >>>> >>>> sasl_allowed_username_list = ["admin at IPA.EXAMPLE.COM" ] >>>> >>>> if I leave this field commented out (default setting), everybody can >>>> manage the kvm host. >>> Oh it isn't very obvious, but in this log message: >>> >>>>>>> 2012-11-30 12:00:53.403+0000: 7786: error : >>>>>>> virNetSASLContextCheckIdentity:146 : SASL client admin not allowed in >>> 'admin' is the identity being matched against. >>> >>> We ought to quote that string int he log message to make it more >>> obvious. >>> >>> So I guess SASL/GSSAPI is not giving us back the REALM, just >>> the username >>> >>> So you need to change your whitelist to leave out the realm. >> Bingo! >> >> Thanks. If I may just hijack this thread: is it possible to whitelist >> groups instead of individual users to use virsh/virtual manager? >> >> I know sasl only deals with the authentication stuff, buy here you are >> also authorizing in the whitelist. If this authorization could go >> further to allow ipa groups, that would be ideal from an admin point >> of view ;-) > It is desirable, but we don't have any way to find out information about > groups. The authorization problem is something we've yet to really get > a good pluggable solution for, though perhaps policykit would help here. > > Daniel Policy kit is local escalation to admin privileges. The policy kit policies are not centrally managed, they are preinstalled. Are you sure it is the right mechanism? Should there be some more centrally managed mechanism for access control rules like HBAC or SUDO? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From berrange at redhat.com Fri Nov 30 16:36:24 2012 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 30 Nov 2012 16:36:24 +0000 Subject: [Freeipa-users] [libvirt-users] libvirt with vnc freeipa In-Reply-To: <50B8DFDA.3060608@redhat.com> References: <1354285534.19871.113.camel@willson.li.ssimo.org> <20121130144259.GH25966@redhat.com> <20121130150444.GI25966@redhat.com> <20121130152029.GJ25966@redhat.com> <50B8DFDA.3060608@redhat.com> Message-ID: <20121130163624.GL25966@redhat.com> On Fri, Nov 30, 2012 at 11:33:30AM -0500, Dmitri Pal wrote: > On 11/30/2012 10:20 AM, Daniel P. Berrange wrote: > > On Fri, Nov 30, 2012 at 04:16:56PM +0100, Natxo Asenjo wrote: > >> On Fri, Nov 30, 2012 at 4:04 PM, Daniel P. Berrange wrote: > >>> On Fri, Nov 30, 2012 at 03:56:14PM +0100, Natxo Asenjo wrote: > >>>> hi, > >>>> > >>>> sasl_allowed_username_list = ["admin at IPA.EXAMPLE.COM" ] > >>>> > >>>> if I leave this field commented out (default setting), everybody can > >>>> manage the kvm host. > >>> Oh it isn't very obvious, but in this log message: > >>> > >>>>>>> 2012-11-30 12:00:53.403+0000: 7786: error : > >>>>>>> virNetSASLContextCheckIdentity:146 : SASL client admin not allowed in > >>> 'admin' is the identity being matched against. > >>> > >>> We ought to quote that string int he log message to make it more > >>> obvious. > >>> > >>> So I guess SASL/GSSAPI is not giving us back the REALM, just > >>> the username > >>> > >>> So you need to change your whitelist to leave out the realm. > >> Bingo! > >> > >> Thanks. If I may just hijack this thread: is it possible to whitelist > >> groups instead of individual users to use virsh/virtual manager? > >> > >> I know sasl only deals with the authentication stuff, buy here you are > >> also authorizing in the whitelist. If this authorization could go > >> further to allow ipa groups, that would be ideal from an admin point > >> of view ;-) > > It is desirable, but we don't have any way to find out information about > > groups. The authorization problem is something we've yet to really get > > a good pluggable solution for, though perhaps policykit would help here. > > > > Daniel > Policy kit is local escalation to admin privileges. The policy kit > policies are not centrally managed, they are preinstalled. > Are you sure it is the right mechanism? > Should there be some more centrally managed mechanism for access control > rules like HBAC or SUDO? You're referring to the traditional policykit backed based on a local policy file database. More generally policykit is pluggable, so you could reference an off-node policy store. In theory the new javascript engine for policykit could be used to do a check against ldap or IPA, but I've no idea if that'd work out in reality, without more investigation. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| From natxo.asenjo at gmail.com Fri Nov 30 17:50:35 2012 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Fri, 30 Nov 2012 18:50:35 +0100 Subject: [Freeipa-users] [libvirt-users] libvirt with vnc freeipa In-Reply-To: <1354290767.19871.114.camel@willson.li.ssimo.org> References: <1354285534.19871.113.camel@willson.li.ssimo.org> <20121130144259.GH25966@redhat.com> <20121130150444.GI25966@redhat.com> <1354290767.19871.114.camel@willson.li.ssimo.org> Message-ID: On Fri, Nov 30, 2012 at 4:52 PM, Simo Sorce wrote: > Natxo it sounds odd that you are getting back a non fully qualified > principal name, are you sure your configuration is using SASL/GSSAPI ? > > What other directives have you configured ? I have followed the howto in the freeipa.org wiki. I was getting kerberos principasl (libvirt/vnc) as expected even when I could not use virsh, so it looked like it was using GSSAPI. -- groet, natxo From qchang at sri.utoronto.ca Fri Nov 30 17:17:28 2012 From: qchang at sri.utoronto.ca (Qing Chang) Date: Fri, 30 Nov 2012 12:17:28 -0500 Subject: [Freeipa-users] IPA client randomly lose memory of users In-Reply-To: <50AA56D0.3020205@redhat.com> References: <50A9FDF3.2030408@atix.de> <50AA56D0.3020205@redhat.com> Message-ID: <50B8EA28.20601@sri.utoronto.ca> my dovecot IMAP server would randomly lose memory of users, as an example: Samba/NFS server knows this user: [root at smb2 shassan]# getent passwd bqiang bqiang:*:47105:471:Beiping Qiang:/home2/bqiang:/bin/tcsh But dovecot server does not: [root at dovecot2 ~]# getent passwd bqiang Only when I apply this: [root at dovecot2 ~]# \rm /var/lib/sss/db/cache_sri.utoronto.ca.ldb [root at dovecot2 ~]# service sssd restart It gets it: [root at dovecot2 ~]# getent passwd bqiang bqiang:*:47105:471:Beiping Qiang:/home2/bqiang:/bin/tcsh So far I have to deal with this for three users. It's quite possible that there are more than 3 that are affected, they were just patient enough to wait until dovecot "recovers its memory". Again, this seems to be a sssd bug? Thanks, Qing From natxo.asenjo at gmail.com Fri Nov 30 17:56:28 2012 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Fri, 30 Nov 2012 18:56:28 +0100 Subject: [Freeipa-users] [libvirt-users] libvirt with vnc freeipa In-Reply-To: <20121130152029.GJ25966@redhat.com> References: <1354285534.19871.113.camel@willson.li.ssimo.org> <20121130144259.GH25966@redhat.com> <20121130150444.GI25966@redhat.com> <20121130152029.GJ25966@redhat.com> Message-ID: On Fri, Nov 30, 2012 at 4:20 PM, Daniel P. Berrange wrote: > On Fri, Nov 30, 2012 at 04:16:56PM +0100, Natxo Asenjo wrote: >> Thanks. If I may just hijack this thread: is it possible to whitelist >> groups instead of individual users to use virsh/virtual manager? >> >> I know sasl only deals with the authentication stuff, buy here you are >> also authorizing in the whitelist. If this authorization could go >> further to allow ipa groups, that would be ideal from an admin point >> of view ;-) > > It is desirable, but we don't have any way to find out information about > groups. The authorization problem is something we've yet to really get > a good pluggable solution for, though perhaps policykit would help here. well, if I create a policykit policy like this: /etc/polkit-1/localauthority/50-local.d/50-libvirt-remote-access.pkla [libvirt Management Access] Identity=unix-group:libvirt Action=org.libvirt.unix.manage ResultAny=yes ResultInactive=yes ResultActive=yes and I create an ipa group, I can achieve in fact what I want. Members of the group may use virsh and if you have a kerberos ticket it is truly sso (I get a ticket from ssh, libvirt and vnc) with the original configuration (so no sasl, just using ssh). -- groet, natxo From natxo.asenjo at gmail.com Fri Nov 30 18:02:56 2012 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Fri, 30 Nov 2012 19:02:56 +0100 Subject: [Freeipa-users] RFE: default hbac is too open Message-ID: hi, the default hbac rule 'allow_all' is nice for testing, but for a production environment I am not so sure ;-) We do not want our users getting a shell in our kdc servers or in the database servers for instance. We want them to use the postgresql service, but not login the database server with a shell. Many more examples are conceivable, of course. Is it possible to have this policy adapted to 'everything but ssh' for instance? That is, disable ssh logins unless explicitely allowed by another policy. This would be the equivalent of 'Remote Desktop Users' in an AD domain. Uses may login at the console everywhere (their workstations), but if they need to login interactively in a server then they need to be a member of this group. This does not prevent them from using other resources like shares, printers, e-mail, databases, ... I am just afraid that unless this becomes the default during the installation, most ipa environments will stay like this which could be an unexpected security problem. No one but kerberos admins should have shell access to the kdc in a kerberos realm. -- Groeten, natxo From rcritten at redhat.com Fri Nov 30 18:03:56 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 30 Nov 2012 13:03:56 -0500 Subject: [Freeipa-users] IPA client randomly lose memory of users In-Reply-To: <50B8EA28.20601@sri.utoronto.ca> References: <50A9FDF3.2030408@atix.de> <50AA56D0.3020205@redhat.com> <50B8EA28.20601@sri.utoronto.ca> Message-ID: <50B8F50C.9050101@redhat.com> Qing Chang wrote: > my dovecot IMAP server would randomly lose memory of users, as an example: > > Samba/NFS server knows this user: > [root at smb2 shassan]# getent passwd bqiang > bqiang:*:47105:471:Beiping Qiang:/home2/bqiang:/bin/tcsh > > But dovecot server does not: > [root at dovecot2 ~]# getent passwd bqiang > > Only when I apply this: > [root at dovecot2 ~]# \rm /var/lib/sss/db/cache_sri.utoronto.ca.ldb > [root at dovecot2 ~]# service sssd restart > > It gets it: > [root at dovecot2 ~]# getent passwd bqiang > bqiang:*:47105:471:Beiping Qiang:/home2/bqiang:/bin/tcsh > > So far I have to deal with this for three users. It's quite possible > that there are more than 3 that are affected, they were just patient > enough to wait until dovecot "recovers its memory". > > Again, this seems to be a sssd bug? Seems like it. I'd go ahead and file a bug against sssd to get the ball rolling. If you can enable sssd debugging and catch the case where a user is lost I'm sure that would be very helpful to the sssd team. rob From rcritten at redhat.com Fri Nov 30 18:24:28 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 30 Nov 2012 13:24:28 -0500 Subject: [Freeipa-users] RFE: default hbac is too open In-Reply-To: References: Message-ID: <50B8F9DC.4020204@redhat.com> Natxo Asenjo wrote: > hi, > > the default hbac rule 'allow_all' is nice for testing, but for a > production environment I am not so sure ;-) > > We do not want our users getting a shell in our kdc servers or in the > database servers for instance. We want them to use the postgresql > service, but not login the database server with a shell. Many more > examples are conceivable, of course. > > Is it possible to have this policy adapted to 'everything but ssh' for > instance? That is, disable ssh logins unless explicitely allowed by > another policy. This would be the equivalent of 'Remote Desktop Users' > in an AD domain. Uses may login at the console everywhere (their > workstations), but if they need to login interactively in a server > then they need to be a member of this group. This does not prevent > them from using other resources like shares, printers, e-mail, > databases, ... > > I am just afraid that unless this becomes the default during the > installation, most ipa environments will stay like this which could be > an unexpected security problem. No one but kerberos admins should have > shell access to the kdc in a kerberos realm. Our expectation was that this default rule would be deleted by sites that want to use HBAC, and that specially crafted rules would replace it. There is an install option to not create this rule at all, --no_hbac_allow. Still, your suggestion makes sense. Better to be secure out-of-the-box. I created an enhancement ticket for this, https://fedorahosted.org/freeipa/ticket/3278 The tricky part is probably going to be around replicas, automatically adding and removing access to them for the rule. rob From berrange at redhat.com Fri Nov 30 18:37:29 2012 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 30 Nov 2012 18:37:29 +0000 Subject: [Freeipa-users] [libvirt-users] libvirt with vnc freeipa In-Reply-To: References: <1354285534.19871.113.camel@willson.li.ssimo.org> <20121130144259.GH25966@redhat.com> <20121130150444.GI25966@redhat.com> <20121130152029.GJ25966@redhat.com> Message-ID: <20121130183729.GN25966@redhat.com> On Fri, Nov 30, 2012 at 06:56:28PM +0100, Natxo Asenjo wrote: > On Fri, Nov 30, 2012 at 4:20 PM, Daniel P. Berrange wrote: > > On Fri, Nov 30, 2012 at 04:16:56PM +0100, Natxo Asenjo wrote: > > >> Thanks. If I may just hijack this thread: is it possible to whitelist > >> groups instead of individual users to use virsh/virtual manager? > >> > >> I know sasl only deals with the authentication stuff, buy here you are > >> also authorizing in the whitelist. If this authorization could go > >> further to allow ipa groups, that would be ideal from an admin point > >> of view ;-) > > > > It is desirable, but we don't have any way to find out information about > > groups. The authorization problem is something we've yet to really get > > a good pluggable solution for, though perhaps policykit would help here. > > well, if I create a policykit policy like this: > > /etc/polkit-1/localauthority/50-local.d/50-libvirt-remote-access.pkla > > [libvirt Management Access] > Identity=unix-group:libvirt > Action=org.libvirt.unix.manage > ResultAny=yes > ResultInactive=yes > ResultActive=yes > > and I create an ipa group, I can achieve in fact what I want. Members > of the group may use virsh and if you have a kerberos ticket it is > truly sso (I get a ticket from ssh, libvirt and vnc) with the original > configuration (so no sasl, just using ssh). Yep, as you say, this only works for real UNIX users. We basically want to make it posible todo the same, but using the SASL / GSSAPI users instead. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|