[Freeipa-users] Free-IPA in an AWS Base Image

2014-02-10 Thread Steve Severance 
I want to create an AWS AMI that when it starts up will register itself
with a Free-IPA instance. The issue I have run into so far is every
instance when it starts up uses the original instances hostname. What do I
need to do to have free-ipa work in a DHCP environment like this?
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

[Freeipa-users] Upgrade of Free ipa in CENTOS 6

2014-02-10 Thread barrykfl 
Dear all:

Any one have exp to upgrade ipa-server-3.0.0-26.el6_4.4.x86_64 to
ipa-server-3.0.0-37.el6_4.4.x86_64 ( jus t minor patch/upgrade it think )

Is it just yum install then ok ??? i notice some official document but they
are 3.3 free ipa of fedora ...just yum / run the rpm and not necessary shut
down.

Is it same in CENTOS ipa 3.0 server one ?

http://www.freeipa.org/page/Releases/3.2.0#Upgrading
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC

2014-02-10 Thread Shree 


Lucas (sorry my previous email may have got sent improperly edited.


My typical command looks like this (domain name changed due to disclosure 
reasons)

# ipa-client-install --domain=mydomain.com --server=ldap2.mydomain.com 
--hostname=test500.mydomain.com -d

master = ldap.mydomain.com
replica = ldap2.mydomain.com

I ran lsof while running a ipa-client-install and found the following "kinit" 
instances trying to access my "master"
=

ipa-clien 10443      root  mem       REG              253,0   334040    1704353 
/lib64/libldap_r-2.4.so.2.5.6
ipa-clien 10443      root  mem       REG              253,0    61896    1444372 
/usr/lib64/python2.6/site-packages/_ldap.so
kinit     10545      root    3u     IPv4             143621      0t0        UDP 
test500.mydomain.com:57166->ldap.mydomain.com:kerberos
kinit     10545      root    4u     IPv4             143636      0t0        TCP 
test500.mydomain.com:35574->ldap.mydomain.com:kerberos (SYN_SENT)
=

the client install also finds issue with syncing time during client install, 
but only gives warning. The time difference between master and client is within 
seconds.

 
the client install also finds issue with 
 
Shreeraj



Change is the only Constant !



On Sunday, February 9, 2014 4:44 AM, Rob Crittenden  wrote:
 
Shree wrote:
> Lukas
> Perhaps I should explain the design a bit and see if FreeIPA even
> supports this.Our replica is in a separate network and all the
> appropriate ports are opened between the master and the replica. The
> "replica" got created successfully and is in sync with the master
> (except the CA services which I mentioned earlier)
> Now,when I try to run ipa-client-install on hosts in the new network
> using the replica, it complains that about "Cannot contact any KDC for
> realm".
> I am wondering it my hosts in the new network are trying to access the
> "master" for certificates since the replica does not have any CA
> services running? I couldn't find any obvious proof of
 this even running
> the install in a debug mode. Do I need to open ports between the new
> hosts and the master for CA services?
> At this point I
 cannot disable or  move the master, it needs to function
> in its location but I need

No, the clients don't directly talk to the CA.

You'd need to look in /var/log/ipaclient-install.log to see what KDC was 
found and we were trying to use. If you have SRV records for both but we 
try to contact the hidden master this will happen. You can try 
specifying the server on the command-line with --server but this will be 
hardcoding things and make it less flexible later.

rob

> Shreeraj
> 
>
>
> Change is the only Constant !
>
>
> On Saturday, February 8, 2014 1:29 AM, Lukas Slebodnik
>  wrote:
> On (06/02/14 18:33), Shree wrote:
>
>  >First of
 all, the ipa-replica-install did not allow me to use
> the --setup-ca
>  > option complaining that a cert already exists, replicate creation was
>  > successful after I skipped the option.
>  >Seems like the replica is one except
>  >1) There is no CA Service running on the replica (which I guess is
> expected)
>  >and
>  >2) I am unable to run ipa-client-install successfully on any clients using
>  > the replica. (I don't have the option of using the primary master as
> it is
>  > configured in a segregated environment. Only the master and replica are
>  > allowed to sync.
>  >Debug shows it fails at
> 
 >
>  >ipa         : DEBUG    stderr=kinit: Cannot contact any KDC for realm
> 'mydomainname.com' while getting initial
 credentials
>
>  >
>  >
>
> I was not able to install replica witch CA on fedora 20,
> Bug is already reported https://fedorahosted.org/pki/ticket/816
>
> Guys from dogtag found a workaround
> https://fedorahosted.org/pki/ticket/816#comment:12
>
> Does it work for you?
>
> LS
>
>
>
>
>
> ___
> Freeipa-users mailing
 list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
>___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] CentOS 6.5 client install failing

2014-02-10 Thread Dave Jablonski 
Unfortunately no.  I don't have access to the server.
On Feb 10, 2014 2:36 PM, "Dmitri Pal"  wrote:

> On 02/08/2014 08:48 AM, Rob Crittenden wrote:
>
>> Dave Jablonski wrote:
>>
>>> FreeIPA Server:  Fedora 16, freeipa 2.1.4
>>> Latest CentOS 6.5 client
>>>
>>> When running:
>>>
>>> ipa-client-install --mkhomedir --enable-dns-updates
>>>
>>> The install fails with:
>>>
>>> trying https:///ipa/xml
>>> Forwarding 'env' to server u'https:///ipa/xml'
>>> Traceback (most recent call last):
>>>File "/usr/sbin/ipa-client-install", line 2377, in 
>>>  sys.exit(main())
>>>File "/usr/sbin/ipa-client-install", line 2363, in main
>>>  rval = install(options, env, fstore, statestore)
>>>File "/usr/sbin/ipa-client-install", line 2167, in install
>>>  remote_env = api.Command['env'](server=True)['result']
>>>File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 435,
>>> in __call__
>>>  ret = self.run(*args, **options)
>>>File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line
>>> 1073, in run
>>>  return self.forward(*args, **options)
>>>File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 769,
>>> in forward
>>>  return self.Backend.xmlclient.forward(self.name ,
>>> *args, **kw)
>>>File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line 736, in
>>> forward
>>>  raise error(message=e.faultString)
>>> ipalib.errors.CCacheError: did not receive Kerberos credentials
>>>
>>> In /var/log/ipaclient-install.log:
>>>
>>> 2014-02-06T18:19:53Z DEBUG approved_usage = SSLServer intended_usage =
>>> SSLServer
>>> 2014-02-06T18:19:53Z DEBUG cert valid True for
>>> "CN=,O="
>>> 2014-02-06T18:19:53Z DEBUG handshake complete, peer = 10.1.1.111:443
>>> 
>>> 2014-02-06T18:19:53Z DEBUG Caught fault 1101 from server
>>> https:///ipa/xml: did not receive Kerberos credentials
>>>
>>
>> We need to see more context from the client install log, preferably the
>> whole thing.
>>
>> IPA v2 doesn't support session cookies but the 3.x client should have
>> support for falling back to using TGT delegation.
>>
>> rob
>>
>> ___
>> Freeipa-users mailing list
>> Freeipa-users@redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>
>
> Any chance to upgrade the server to something more modern?
>
>
> --
> Thank you,
> Dmitri Pal
>
> Sr. Engineering Manager for IdM portfolio
> Red Hat Inc.
>
>
> ---
> Looking to carve out IT costs?
> www.redhat.com/carveoutcosts/
>
>
>
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
>

-- 
 

IMPORTANT: This e-mail (including any attachments) is intended for the use 
of the individual or entity to which it is addressed and may contain 
information that is classified, private, or confidential. If the reader of 
this message is not the intended recipient, or the employee or agent 
responsible for delivering the message to the intended recipient, you are 
hereby notified that any dissemination, distribution, or copying of this 
communication is prohibited. If you have received this communication in 
error, please notify us immediately by replying to this e-mail. Thank you.
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] ipa-client-install does not seem to like the ipa's ntp

2014-02-10 Thread Mauricio Tavares 
On Mon, Feb 10, 2014 at 3:40 PM, Dmitri Pal  wrote:
> On 02/09/2014 09:52 PM, Mauricio Tavares wrote:
>>
>> On Sun, Feb 9, 2014 at 9:07 PM, Steve Dainard
>> wrote:
>>>
>>> I've noticed if ntpd is already running on the client when you run the
>>> ipa-client-install, you will get that error. I'm guessing its using
>>> ntpdate
>>> IP ADDRESS to sync time, and cannot do so when the daemon is running.
>>>
>>> I've noticed if ntpd is already running on the client when you run the
>>> ipa-client-install, you will get that error. I'm guessing its using
>>> ntpdate
>>> IP ADDRESS to sync time, and cannot do so when the daemon is running.
>>>
>>Now that you mentioned that I would agree with you in that it is
>> failing because ntpd is running already; I could not see it because of
>> the option "-s" in
>>
>> [root@centos64 ~]# service ntpd status
>> ntpd (pid  3721) is running...
>> [root@centos64 ~]# /usr/sbin/ntpdate -U ntp -s -b -v auth.in.domain.com
>> [root@centos64 ~]#
>>
>> I could not find what all of those arguments mean in the centos 6.5
>> ntpdate man page, but here is what I found under ubuntu's:
>>
>> -b Force  the  time  to  be stepped using the settimeofday()
>> system
>>call, rather than slewed (default) using  the  adjtime()
>> system
>>call. This option should be used when called from a startup
>> file
>>at boot time.
>>
>> -s Divert logging output from the standard output (default) to
>> the
>>system  syslog  facility.  This is designed primarily for
>> conve‐
>>nience of cron scripts.
>>
>> -v Be verbose. This option will cause ntpdate's version
>> identifica‐
>>tion string to be logged.
>>
>> In other words, -s is sending the output to syslog. And, if we check
>> /var/log/messages we will find that
>>
>> Feb  9 21:17:06 centos64 ntpdate[8275]: the NTP socket is in use, exiting
>>
>> as you expected. Now, how did it detect the ntpdate failed?
>>
>>> Steve
>>>
>>>
>>> On Sat, Feb 8, 2014 at 8:34 AM, Mauricio Tavares
>>> wrote:

Even though I already have a ntp server, I setup my newly
 created freeipa kdc to do that too (it is a slave to my primary ntp).

 I then build a centos host to be the test client. Just to make sure it
 can see and use auth's ntp, I tested with ntpdate:

 [root@centos64 ~]# ntpdate auth
   8 Feb 08:13:35 ntpdate[3251]: adjust time server 10.0.0.11 offset
 -0.003097 sec
 [root@centos64 ~]#

 so far so good, so how about running ipa-client-install?

 [root@centos64 ~]# hostname
 centos64
 [root@centos64 ~]# ipa-client-install --hostname=`hostname -f`
 Discovery was successful!
 Hostname: centos64.in.domain.com
 Realm: DOMAIN.COM
 DNS Domain: domain.com
 IPA Server: auth.in.domain.com
 BaseDN: dc=domain,dc=com

 [so far so good!]

 Continue to configure the system with these values? [no]: yes
 User authorized to enroll computers: admin
 Synchronizing time with KDC...
 Unable to sync time with IPA NTP server, assuming the time is in sync.
 Please check that 123 UDP port is opened.
 Password for ad...@domain.com:

 But, it had not problems using ntpdate against auth.  to add insult to
 injury, the log claims it is using ntpdate:

 2014-02-08T13:14:31Z DEBUG args=/usr/sbin/ntpdate -U ntp -s -b -v
 auth.in.domain.com
 2014-02-08T13:14:31Z DEBUG stdout=
 2014-02-08T13:14:31Z DEBUG stderr=
 2014-02-08T13:14:31Z WARNING Unable to sync time with IPA NTP server,
 assuming the time is in sync. Please check that 123 UDP port is
 opened.

 Could it be it is pissed because it was in sync to begin with? I mean,
 if we run the exact command the log file claims to have run,

 [root@centos64 ~]# /usr/sbin/ntpdate -U ntp -s -b -v auth.in.domain.com|
 echo $?
 0
 [root@centos64 ~]#

 We see it was successful.

 I am feeling rather clueless here...

 ___
 Freeipa-users mailing list
 Freeipa-users@redhat.com
 https://www.redhat.com/mailman/listinfo/freeipa-users
>>>
>>>
>> ___
>> Freeipa-users mailing list
>> Freeipa-users@redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>
>
> This sounds like a bug to me but I would wait for European gurus to chime in
> the morning.
> If it is a bug we need a ticket.
>
  I dunno where to file a ticket but here is my suggestion:

in /usr/lib/python2.6/site-packages/ipaclient/ntpconf.py, function def
synconce_ntp(server_fqdn):

replace

cmd = [ntpdate, "-U", "ntp", "-s", "-b", "-v", server_fqdn]

with

cmd = [ntpdate, "-U", "ntp", "-s", "-b", "-v", "-u", server_fqdn]

Reasoning:

[root@centos64 ~]# date +%T -s "10:13:13"
10:13:13
[root@centos64 ~]# date
Mon F

Re: [Freeipa-users] ipa-client-install does not seem to like the ipa's ntp

2014-02-10 Thread Dmitri Pal 

On 02/09/2014 09:52 PM, Mauricio Tavares wrote:

On Sun, Feb 9, 2014 at 9:07 PM, Steve Dainard  wrote:

I've noticed if ntpd is already running on the client when you run the
ipa-client-install, you will get that error. I'm guessing its using ntpdate
IP ADDRESS to sync time, and cannot do so when the daemon is running.

I've noticed if ntpd is already running on the client when you run the
ipa-client-install, you will get that error. I'm guessing its using ntpdate
IP ADDRESS to sync time, and cannot do so when the daemon is running.


   Now that you mentioned that I would agree with you in that it is
failing because ntpd is running already; I could not see it because of
the option "-s" in

[root@centos64 ~]# service ntpd status
ntpd (pid  3721) is running...
[root@centos64 ~]# /usr/sbin/ntpdate -U ntp -s -b -v auth.in.domain.com
[root@centos64 ~]#

I could not find what all of those arguments mean in the centos 6.5
ntpdate man page, but here is what I found under ubuntu's:

-b Force  the  time  to  be stepped using the settimeofday() system
   call, rather than slewed (default) using  the  adjtime()  system
   call. This option should be used when called from a startup file
   at boot time.

-s Divert logging output from the standard output (default) to  the
   system  syslog  facility.  This is designed primarily for conve‐
   nience of cron scripts.

-v Be verbose. This option will cause ntpdate's version identifica‐
   tion string to be logged.

In other words, -s is sending the output to syslog. And, if we check
/var/log/messages we will find that

Feb  9 21:17:06 centos64 ntpdate[8275]: the NTP socket is in use, exiting

as you expected. Now, how did it detect the ntpdate failed?


Steve


On Sat, Feb 8, 2014 at 8:34 AM, Mauricio Tavares
wrote:

   Even though I already have a ntp server, I setup my newly
created freeipa kdc to do that too (it is a slave to my primary ntp).

I then build a centos host to be the test client. Just to make sure it
can see and use auth's ntp, I tested with ntpdate:

[root@centos64 ~]# ntpdate auth
  8 Feb 08:13:35 ntpdate[3251]: adjust time server 10.0.0.11 offset
-0.003097 sec
[root@centos64 ~]#

so far so good, so how about running ipa-client-install?

[root@centos64 ~]# hostname
centos64
[root@centos64 ~]# ipa-client-install --hostname=`hostname -f`
Discovery was successful!
Hostname: centos64.in.domain.com
Realm: DOMAIN.COM
DNS Domain: domain.com
IPA Server: auth.in.domain.com
BaseDN: dc=domain,dc=com

[so far so good!]

Continue to configure the system with these values? [no]: yes
User authorized to enroll computers: admin
Synchronizing time with KDC...
Unable to sync time with IPA NTP server, assuming the time is in sync.
Please check that 123 UDP port is opened.
Password for ad...@domain.com:

But, it had not problems using ntpdate against auth.  to add insult to
injury, the log claims it is using ntpdate:

2014-02-08T13:14:31Z DEBUG args=/usr/sbin/ntpdate -U ntp -s -b -v
auth.in.domain.com
2014-02-08T13:14:31Z DEBUG stdout=
2014-02-08T13:14:31Z DEBUG stderr=
2014-02-08T13:14:31Z WARNING Unable to sync time with IPA NTP server,
assuming the time is in sync. Please check that 123 UDP port is
opened.

Could it be it is pissed because it was in sync to begin with? I mean,
if we run the exact command the log file claims to have run,

[root@centos64 ~]# /usr/sbin/ntpdate -U ntp -s -b -v auth.in.domain.com|
echo $?
0
[root@centos64 ~]#

We see it was successful.

I am feeling rather clueless here...

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users



___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users


This sounds like a bug to me but I would wait for European gurus to 
chime in the morning.

If it is a bug we need a ticket.

--
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC

2014-02-10 Thread Dmitri Pal 

On 02/09/2014 07:44 AM, Rob Crittenden wrote:

Shree wrote:

Lukas
Perhaps I should explain the design a bit and see if FreeIPA even
supports this.Our replica is in a separate network and all the
appropriate ports are opened between the master and the replica. The
"replica" got created successfully and is in sync with the master
(except the CA services which I mentioned earlier)
Now,when I try to run ipa-client-install on hosts in the new network
using the replica, it complains that about "Cannot contact any KDC for
realm".
I am wondering it my hosts in the new network are trying to access the
"master" for certificates since the replica does not have any CA
services running? I couldn't find any obvious proof of this even running
the install in a debug mode. Do I need to open ports between the new
hosts and the master for CA services?
At this point I cannot disable or  move the master, it needs to function
in its location but I need


No, the clients don't directly talk to the CA.

You'd need to look in /var/log/ipaclient-install.log to see what KDC 
was found and we were trying to use. If you have SRV records for both 
but we try to contact the hidden master this will happen. You can try 
specifying the server on the command-line with --server but this will 
be hardcoding things and make it less flexible later.


rob


Shreeraj
 




Change is the only Constant !


On Saturday, February 8, 2014 1:29 AM, Lukas Slebodnik
 wrote:
On (06/02/14 18:33), Shree wrote:

>First of all, the ipa-replica-install did not allow me to use
the --setup-ca
> option complaining that a cert already exists, replicate creation was
> successful after I skipped the option.
>Seems like the replica is one except
>1) There is no CA Service running on the replica (which I guess is
expected)
>and
>2) I am unable to run ipa-client-install successfully on any clients 
using

> the replica. (I don't have the option of using the primary master as
it is
> configured in a segregated environment. Only the master and replica 
are

> allowed to sync.
>Debug shows it fails at
>
>ipa : DEBUGstderr=kinit: Cannot contact any KDC for realm
'mydomainname.com' while getting initial credentials

>
>

I was not able to install replica witch CA on fedora 20,
Bug is already reported https://fedorahosted.org/pki/ticket/816

Guys from dogtag found a workaround
https://fedorahosted.org/pki/ticket/816#comment:12

Does it work for you?

LS





___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users



___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users


What server provides DNS capabilities to the clients?
Do you use IPA DNS or some other DNS?
Clients seem to not be able to see replica KDC and try to access hidden 
master but they can know about this master only via DNS.



--
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] CentOS 6.5 client install failing

2014-02-10 Thread Dmitri Pal 

On 02/08/2014 08:48 AM, Rob Crittenden wrote:

Dave Jablonski wrote:

FreeIPA Server:  Fedora 16, freeipa 2.1.4
Latest CentOS 6.5 client

When running:

ipa-client-install --mkhomedir --enable-dns-updates

The install fails with:

trying https:///ipa/xml
Forwarding 'env' to server u'https:///ipa/xml'
Traceback (most recent call last):
   File "/usr/sbin/ipa-client-install", line 2377, in 
 sys.exit(main())
   File "/usr/sbin/ipa-client-install", line 2363, in main
 rval = install(options, env, fstore, statestore)
   File "/usr/sbin/ipa-client-install", line 2167, in install
 remote_env = api.Command['env'](server=True)['result']
   File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 435,
in __call__
 ret = self.run(*args, **options)
   File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line
1073, in run
 return self.forward(*args, **options)
   File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 769,
in forward
 return self.Backend.xmlclient.forward(self.name ,
*args, **kw)
   File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line 736, in
forward
 raise error(message=e.faultString)
ipalib.errors.CCacheError: did not receive Kerberos credentials

In /var/log/ipaclient-install.log:

2014-02-06T18:19:53Z DEBUG approved_usage = SSLServer intended_usage =
SSLServer
2014-02-06T18:19:53Z DEBUG cert valid True for 
"CN=,O="

2014-02-06T18:19:53Z DEBUG handshake complete, peer = 10.1.1.111:443

2014-02-06T18:19:53Z DEBUG Caught fault 1101 from server
https:///ipa/xml: did not receive Kerberos credentials


We need to see more context from the client install log, preferably 
the whole thing.


IPA v2 doesn't support session cookies but the 3.x client should have 
support for falling back to using TGT delegation.


rob

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users


Any chance to upgrade the server to something more modern?


--
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] RHEL 7 beta trust - slow domain user authentication to Linux hosts

2014-02-10 Thread Steve Dainard 
Sure:

(Mon Feb 10 10:14:58 2014) [[sssd[krb5_child[9879 [main] (0x0400):
krb5_child started.
(Mon Feb 10 10:14:58 2014) [[sssd[krb5_child[9879 [unpack_buffer]
(0x1000): total buffer size: [125]
(Mon Feb 10 10:14:58 2014) [[sssd[krb5_child[9879 [unpack_buffer]
(0x0100): cmd [241] uid [799001323] gid [799001323] validate [true] offline
[false] UPN [sdain...@miovision.corp]
(Mon Feb 10 10:14:58 2014) [[sssd[krb5_child[9879 [unpack_buffer]
(0x0100): ccname: [FILE:/tmp/krb5cc_799001323_zWaW2Z] keytab:
[/etc/krb5.keytab]
(Mon Feb 10 10:14:58 2014) [[sssd[krb5_child[9879 [krb5_child_setup]
(0x0400): Will perform online auth
(Mon Feb 10 10:14:58 2014) [[sssd[krb5_child[9879 [krb5_child_setup]
(0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment.
(Mon Feb 10 10:14:58 2014) [[sssd[krb5_child[9879 [krb5_child_setup]
(0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment.
(Mon Feb 10 10:14:58 2014) [[sssd[krb5_child[9879
[krb5_set_canonicalize] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true]
(Mon Feb 10 10:14:58 2014) [[sssd[krb5_child[9879 [krb5_child_setup]
(0x0100): Not using FAST.
(Mon Feb 10 10:14:58 2014) [[sssd[krb5_child[9879 [tgt_req_child]
(0x1000): Attempting to get a TGT
(Mon Feb 10 10:14:58 2014) [[sssd[krb5_child[9879 [get_and_save_tgt]
(0x0400): Attempting kinit for realm [MIOVISION.CORP]
(Mon Feb 10 10:14:58 2014) [[sssd[krb5_child[9879 [validate_tgt]
(0x0400): TGT verified using key for
[host/snapshot-test.miolinux.c...@miolinux.corp].
(Mon Feb 10 10:15:06 2014) [[sssd[krb5_child[9879 [become_user]
(0x0200): Trying to become user [799001323][799001323].
(Mon Feb 10 10:15:06 2014) [[sssd[krb5_child[9879 [create_ccache_file]
(0x0200): Creating ccache at [FILE:/tmp/krb5cc_799001323_zWaW2Z]
(Mon Feb 10 10:15:06 2014) [[sssd[krb5_child[9879 [create_ccache_file]
(0x1000): Created ccache file: [FILE:/tmp/krb5cc_799001323_zWaW2Z]
(Mon Feb 10 10:15:06 2014) [[sssd[krb5_child[9879
[prepare_response_message] (0x0400): Building response for result [0]
(Mon Feb 10 10:15:06 2014) [[sssd[krb5_child[9879 [main] (0x0400):
krb5_child completed successfully
(Mon Feb 10 10:16:34 2014) [[sssd[krb5_child[9929 [main] (0x0400):
krb5_child started.
(Mon Feb 10 10:16:34 2014) [[sssd[krb5_child[9929 [unpack_buffer]
(0x1000): total buffer size: [125]
(Mon Feb 10 10:16:34 2014) [[sssd[krb5_child[9929 [unpack_buffer]
(0x0100): cmd [241] uid [799001323] gid [799001323] validate [true] offline
[false] UPN [sdain...@miovision.corp]
(Mon Feb 10 10:16:34 2014) [[sssd[krb5_child[9929 [unpack_buffer]
(0x0100): ccname: [FILE:/tmp/krb5cc_799001323_zWaW2Z] keytab:
[/etc/krb5.keytab]
(Mon Feb 10 10:16:34 2014) [[sssd[krb5_child[9929 [krb5_child_setup]
(0x0400): Will perform online auth
(Mon Feb 10 10:16:34 2014) [[sssd[krb5_child[9929 [krb5_child_setup]
(0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment.
(Mon Feb 10 10:16:34 2014) [[sssd[krb5_child[9929 [krb5_child_setup]
(0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment.
(Mon Feb 10 10:16:34 2014) [[sssd[krb5_child[9929
[krb5_set_canonicalize] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true]
(Mon Feb 10 10:16:34 2014) [[sssd[krb5_child[9929 [krb5_child_setup]
(0x0100): Not using FAST.
(Mon Feb 10 10:16:34 2014) [[sssd[krb5_child[9929 [tgt_req_child]
(0x1000): Attempting to get a TGT
(Mon Feb 10 10:16:34 2014) [[sssd[krb5_child[9929 [get_and_save_tgt]
(0x0400): Attempting kinit for realm [MIOVISION.CORP]
(Mon Feb 10 10:16:35 2014) [[sssd[krb5_child[9929 [validate_tgt]
(0x0400): TGT verified using key for
[host/snapshot-test.miolinux.c...@miolinux.corp].
(Mon Feb 10 10:16:40 2014) [[sssd[krb5_child[9929 [become_user]
(0x0200): Trying to become user [799001323][799001323].
(Mon Feb 10 10:16:40 2014) [[sssd[krb5_child[9929 [create_ccache_file]
(0x0200): Creating ccache at [FILE:/tmp/krb5cc_799001323_zWaW2Z]
(Mon Feb 10 10:16:40 2014) [[sssd[krb5_child[9929 [create_ccache_file]
(0x1000): Created ccache file: [FILE:/tmp/krb5cc_799001323_zWaW2Z]
(Mon Feb 10 10:16:40 2014) [[sssd[krb5_child[9929
[prepare_response_message] (0x0400): Building response for result [0]
(Mon Feb 10 10:16:40 2014) [[sssd[krb5_child[9929 [main] (0x0400):
krb5_child completed successfully
(Mon Feb 10 10:16:57 2014) [[sssd[krb5_child[9960 [main] (0x0400):
krb5_child started.
(Mon Feb 10 10:16:57 2014) [[sssd[krb5_child[9960 [unpack_buffer]
(0x1000): total buffer size: [125]
(Mon Feb 10 10:16:57 2014) [[sssd[krb5_child[9960 [unpack_buffer]
(0x0100): cmd [241] uid [799001323] gid [799001323] validate [true] offline
[false] UPN [sdain...@miovision.corp]
(Mon Feb 10 10:16:57 2014) [[sssd[krb5_child[9960 [unpack_buffer]
(0x0100): ccname: [FILE:/tmp/krb5cc_799001323_zWaW2Z] keytab:
[/etc/krb5.keytab]
(Mon Feb 10 10:16:57 2014) [[sssd[krb5_child[9960 [krb5_child_setup]
(0x0400): Will perform online auth
(Mon Feb 10 10:16:57

Re: [Freeipa-users] RHEL 7 beta trust - slow domain user authentication to Linux hosts

2014-02-10 Thread Sumit Bose 
On Mon, Feb 10, 2014 at 10:55:33AM -0500, Steve Dainard wrote:
> I've setup RHEL 7 beta IPA with a trust to an AD domain.
> 
> When I use an AD domain login it takes roughly 9-14 seconds to get to a
> shell after entering a password. Is there any way to speed this process up?
> I thought supplemental logins would be quicker, but the login time is the
> same. This is either via console, or via ssh@localhost or ssh over the
> network.

at a first glace I would say that the delay is in krb5_child. Can you
send this log file as well?

bye,
Sumit

> 
> IPA realm = miolinux.corp
> DC domain/forest = miovision.corp
> 

...

> (Mon Feb 10 10:17:29 2014) [sssd[be[miolinux.corp]]] [write_pipe_handler]
> (0x0400): All data has been sent!

...

> *(Mon Feb 10 10:17:35 2014) [sssd[be[miolinux.corp]]] [read_pipe_handler]
> (0x0400): EOF received, client finished*
> 

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] export user info

2014-02-10 Thread Martin Kosek 
On 02/10/2014 12:01 PM, barry...@gmail.com wrote:
> Dear all:
> 
> Which command can export /show all users a/c and info? better in table
> format .
> 
> Regards
> 
> Barry

$ ipa user-find

Or in JSON-RPC command:

{"method":"user_find","params":[[""],{"sizelimit":0}]}

Martin

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

[Freeipa-users] export user info

2014-02-10 Thread barrykfl 
Dear all:

Which command can export /show all users a/c and info? better in table
format .

Regards

Barry
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

[Freeipa-users] Clarifying Pilsner/Beer Exchange/Deferred Trac milestones

2014-02-10 Thread Martin Kosek 
Hello,

I would to follow up on a core devel team discussion we had last week. Part of
it were changes to milestones as we currently use it.

1) "Pilsner/Beer Exchange/Deferred
Currently, we have 3 levels of deferring feature request and bug fix tickets to
later releases:

a) Pilsner barrel: when planning next release, most of the tickets will come
from this release, based on priority or topic of the next release

b) Beer Exchange: tickets we do not plan to complete any time soon as we do not
consider it critical enough to devote our limited development resources to it.
However, it does not mean we do not welcome our community to contact us and
provide patches! More details in [1]. It may still happen though, that we will
pick a ticket from this milestone to next release, but it is much less likely
than with Pilsner

c) Deferred: we surely do not plan to complete those and we do not recommend
community to look at those either (unless strongly justified).

More information about Roadmap in [2].

As discussed, this naming is not very transparent and obvious for people
outside of core development team. Thus, to narrow the expectations, we would
like to rename it to become more obvious. Here are my proposals:

a) "Pilsner" -> "Future releases" (with appropriate milestone description to
set the expectations right)

b) "Beer Exchange" -> "Backlog" (with better description)

c) "Deferred" - can stay as is.

If there are any objections or better suggestions, please let me know.

[1] http://www.freeipa.org/page/Contribute/Code
[2] http://www.freeipa.org/page/Roadmap

-- 
Martin Kosek 
Supervisor, Software Engineering - Identity Management Team
Red Hat Inc.

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users