Re: [Freeipa-users] Help understanding issue with CentOS freeipa sudo host groups

2015-11-18 Thread Sparks, Alan
 
>> [root@als-centos0002 sys-ops]# nisdomainname 
>> dakar.useast.hpcloud.net
>> 
>> [root@als-centos0002 sys-ops]# getent netgroup opsauto
>> opsauto  
>> (als-ubuntu0001.oa.ftc.hpelabs.net,-,eucalyptus.internal)
>> (als-centos0002.dakar.useast.hpcloud.net,-,eucalyptus.internal)
> 

>Your NIS domain name doesn't match. dakar.useast.hpcloud.net != 
>eucalyptus.internal
>rob

Thanks for that.   I must be misunderstanding the purpose of the --domain 
option.
-Alan

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project


[Freeipa-users] Help understanding issue with CentOS freeipa sudo host groups

2015-11-18 Thread Sparks, Alan
I still can't find the problem after a lot of searching, can someone give me a 
little advice?   Assembling a POC of FreeIPA 4.1.0 server (stock CentOS-7 
packages) and a CentOS 6.7 server with their stock 3.0.0 packages.   Sudo 
version on the client is sudo-1.8.6p3.

Have created a general sudo rule on the IPA server to grant access to a host 
group.   However it doesn't allow access, just a "sparksa is not allowed to run 
sudo on als-centos0002".If I change the rule to not use host groups, and 
explicitly set the hosts, it works OK.

Have checked the stuff I've seen in general search, like the nisdomainname, 
values are set and look plausible.   The sudo debug logs seem to indicate 
vaguely that it can't match the netgroup:

Nov 18 16:07:37 sudo[15713]   username=sparksa
Nov 18 16:07:37 sudo[15713] domainname=(null)
Nov 18 16:07:37 sudo[15713] Received 1 rule(s)
Nov 18 16:07:37 sudo[15713] sssd/ldap sudoHost '+opsauto' ... not
Nov 18 16:07:37 sudo[15713] Sorting the remaining entries using the sudoOrder 
attribute
Nov 18 16:07:37 sudo[15713] searching SSSD/LDAP for sudoers entries
Nov 18 16:07:37 sudo[15713] Done with LDAP searches
Nov 18 16:07:37 sudo[15713] keep 
HOSTNAME=als-centos0002.dakar.useast.hpcloud.net: YES
Nov 18 16:07:37 sudo[15713] sudo_putenv: 
HOSTNAME=als-centos0002.dakar.useast.hpcloud.net

The setup of the client used the normal 'ipa-client-install' script.From 
questions asked before, some salient debugging info:

[root@als-centos0002 sys-ops]# nisdomainname
dakar.useast.hpcloud.net
[root@als-centos0002 sys-ops]# hostname
als-centos0002.dakar.useast.hpcloud.net
[root@als-centos0002 sys-ops]# getent netgroup opsauto
opsauto   (als-ubuntu0001.oa.ftc.hpelabs.net,-,eucalyptus.internal) 
(als-centos0002.dakar.useast.hpcloud.net,-,eucalyptus.internal)

Does anyone have any advice on what additional debug I should look at, just not 
sure what I'm missing.   Thanks in advance.
-Alan
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Help understanding issue with CentOS freeipa sudo host groups

2015-11-18 Thread Rob Crittenden
Sparks, Alan wrote:
> I still can’t find the problem after a lot of searching, can someone
> give me a little advice?   Assembling a POC of FreeIPA 4.1.0 server
> (stock CentOS-7 packages) and a CentOS 6.7 server with their stock 3.0.0
> packages.   Sudo version on the client is sudo-1.8.6p3. 
> 
>  
> 
> Have created a general sudo rule on the IPA server to grant access to a
> host group.   However it doesn’t allow access, just a “sparksa is not
> allowed to run sudo on als-centos0002”.If I change the rule to not
> use host groups, and explicitly set the hosts, it works OK.
> 
>  
> 
> Have checked the stuff I’ve seen in general search, like the
> nisdomainname, values are set and look plausible.   The sudo debug logs
> seem to indicate vaguely that it can’t match the netgroup:
> 
>  
> 
> Nov 18 16:07:37 sudo[15713]   username=sparksa
> 
> Nov 18 16:07:37 sudo[15713] domainname=(null)
> 
> Nov 18 16:07:37 sudo[15713] Received 1 rule(s)
> 
> Nov 18 16:07:37 sudo[15713] sssd/ldap sudoHost '+opsauto' ... not
> 
> Nov 18 16:07:37 sudo[15713] Sorting the remaining entries using the
> sudoOrder attribute
> 
> Nov 18 16:07:37 sudo[15713] searching SSSD/LDAP for sudoers entries
> 
> Nov 18 16:07:37 sudo[15713] Done with LDAP searches
> 
> Nov 18 16:07:37 sudo[15713] keep
> HOSTNAME=als-centos0002.dakar.useast.hpcloud.net: YES
> 
> Nov 18 16:07:37 sudo[15713] sudo_putenv:
> HOSTNAME=als-centos0002.dakar.useast.hpcloud.net
> 
>  
> 
> The setup of the client used the normal ‘ipa-client-install’ script.   
> From questions asked before, some salient debugging info:
> 
>  
> 
> [root@als-centos0002 sys-ops]# nisdomainname
> 
> dakar.useast.hpcloud.net
> 
> [root@als-centos0002 sys-ops]# hostname
> 
> als-centos0002.dakar.useast.hpcloud.net
> 
> [root@als-centos0002 sys-ops]# getent netgroup opsauto
> 
> opsauto  
> (als-ubuntu0001.oa.ftc.hpelabs.net,-,eucalyptus.internal)
> (als-centos0002.dakar.useast.hpcloud.net,-,eucalyptus.internal)
> 
>  
> 
> Does anyone have any advice on what additional debug I should look at,
> just not sure what I’m missing.   Thanks in advance.

Your NIS domain name doesn't match. dakar.useast.hpcloud.net !=
eucalyptus.internal

rob

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project


Re: [Freeipa-users] service account for ovirt

2015-11-18 Thread Rob Verduijn
2015-11-18 15:51 GMT+01:00 Martin Kosek :
> On 11/18/2015 08:23 AM, Rob Verduijn wrote:
>> Hello all,
>>
>> I've read a lot regarding service accounts on this mailinglist in the past.
>> But it's rather unclear to me what is the current preffered method to
>> create a service account for a service running on a different machine.
>>
>> In this case it would be  a service account for ovirt so that freeipa
>> users can authenticate in the ovirt portal using their freeipa
>> credentials.
>
> It sounds like that you do not want system user account, but you are OK with
> service account so that you can get a keytab for your oVirt instance. In that
> case, simple
>
> $ ipa service-add HTTP/frontend.ovirt.test
> and
> $ ipa-getkeytab ...
> should be enough, right?
>
> Maybe I just do not understand the use case.
>
>> I could ofcourse create an account and then apply a ldf to set its
>> password expiration to the next millennium to make sure the password
>> does not expire.
>>
>> Anybody who has a good suggestion on how to deal with this ?
>>
>> Cheers
>> Rob Verduijn
>>
>



Hello,

I think some more context should clear this up a bit.

according to the rhev administrator guide: (ovirt referes to rhev manuals a lot)
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.5/html/Administration_Guide/sect-Directory_Users.html

It talks about two options as a single sign on solution.

On have the single sign on work for the portal, but then it won't work
for the vm's.
( something about not being able to pass a password since the portal
won't have one to pass )

Or have the single sign on work for the vm's but than you have to sign
in to the portal so it can pass on your credentials to the vm's.

 I guess there is some interesting technical challenge to deal with to
merge those two cases.

The first option requires privileges to browse the freeipa directory
to look for user accounts.
I do not know if that can be solved with something as simple as a
keytab and a pricipal.

My current working solution is an account with a very long password
experation time in the freeipa directory
( a random 32 character/number password is being used for this )

However something tells me that there is a more elegant solution.
And I was wondering if anyone knows one.

Cheers
Rob Verduijn

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project


Re: [Freeipa-users] Sudo Rules Help (SOLVED)

2015-11-18 Thread Branden Coates
I was able to track down the issues with Cent 5 and the sudo rules. I do 
not fully understand why, but I assume it has to do with being able to 
determine the hostname from the fqdn. I ended up having to add the 
following line to the /etc/sysctl.conf file:


nkernel.domainname = 

Our domain for freeipa is actually a subdomain so possibly this may have 
had something to do with needing this setting?
After adding that line and running a "sysctl -p" sudo was able to 
identify the servers hostname within the host groups assigned on the 
sudo rule. At this point everything related to sudo I was having issues 
with is sorted out.


Thanks for pointing me in the right direction to sort the problem out. 
It looks like in both instances it was just user error and overlooking a 
few details.


On 11/12/2015 04:57 PM, Branden Coates wrote:

Thank you for the welcome!

So in the process of pulling the output of the log files with the most 
recent attempts on cent6 I sorted out the issues with cent6, though 
cent5 is still problematic. I added debug_level = 6 to sudo and the 
domain in the sssd.conf. Originally I only had this for sudo so I was 
missing part of the puzzle. I also removed the lines as suggested from 
the sssd.conf since they are un-necessary. I suspect that may have 
been something that was a hold over from the migration process between 
an old d389 system using ldap.conf and freeipa.


While I was cleansing the domain logs I could see all the ldap_ 
directives detected and the defaults if not defined in sssd.conf. Our 
setup does not allow anonymous access so a bind user is required to 
pull group info. I added the lines below knowing now that the binddn 
directive is invalid:


ldap_default_bind_dn =
ldap_default_authtok =


to the sssd.conf for cent6, reloaded sssd and cleared its cache with 
sss_cache -E and attempted to sudo and it worked!


After sorting that out I moved on to working with cent5, also adding 
the two lines above to its sssd.conf. I can now see in the logs that 
it finds the users groups and can match that up in the sudo rules but 
it is not finding the host in the host groups to match on the sudo 
rules. I am attaching the logs from cent5 to show the issue related 
here. The host I am testing on is a member of the host group called 
"sysops". You can see in the attached sudo_debug that it does find the 
sysops sudo rule, and also sees the host group called sysops assigned 
to the sudo rule, but it does not find the host within the group. Note 
that it prompts for a password, however the sudo rule does have the 
option !authenticate on the sysops sudo rule, so once it can find the 
host it should no longer prompt for a password.


I appreciate your taking the time to give insight on this issue. I 
have been fighting with this for a few weeks now.


On 11/12/2015 04:34 AM, Pavel Březina wrote:

On 11/11/2015 03:24 PM, Branden Coates wrote:
I have a few issues with sudo rules(FreeIPA 4.1.4-4 on Fedora 22) 
that I

would greatly appreciate some help with. The core of the issue is that
sudo rules fail to work when using ldap instead of ipa when you assign
user groups and host groups to the sudo rule in place of explicitly
adding users and hosts to the sudo rule. The reason for needing to use
ldap over ipa is due to the organization requiring 2fa for all users 
via

OTP tokens. We have a mix of cent 5 to 7 systems, not all can be
immediately upgraded, so with cent 5 and 6 nodes ldap must be used
instead of ipa to support 2fa.
Explicitly assigning users and hosts to sudo rules is also 
unmanageable,

the organization has hundreds of employees and multiple thousands of
servers. Utilizing the host and user groups is a must.

On cent 7 the default sssd.conf generated by FreeIPA works, 2fa 
works by

default and the sssd.conf is using the ipa directives as well to parse
user and host groups on sudo rules. Everything here works as expected.

In cent 6 to allow 2fa to work the conf has to be updated to use ldap
instead of ipa. In the process this seems to break the ability to 
search

user and host groups on sudo rules. Users and hosts explicitly defined
for the sudo rules still work so the clients can see the rules, they
just do not seem to want to look within the groups that may be assigned
to the rules. I moved the original sssd.conf created by FreeIPA using
the ipa directives and sudo works as expected, but 2fa is not possible
like this.

Cent 5 is entirely incapable of using the sudo rules with user and host
groups since sudo lacks sssd support in cent 5 and depends on
/etc/ldap.conf to work. However like cent 6, users and hosts explicitly
defined for the sudo rules still work, so I presume fixing the sudo
rules with cent 6 on ldap would fix them here as well.

Can anyone else confirm this behavior, and if so can anyone suggest any
possible fixes or workarounds? I have attached the modified Cent6 and
Cent 5 configs for sssd and ldap inline below(first time mailing, if
inline is not ok 

Re: [Freeipa-users] FreeIPA Internal Server Error

2015-11-18 Thread Rob Crittenden
Unknown wrote:
> I'm new here so first of all want to say hello to everyone.
> 
> I'm implementing FreeIPA in our environment. Everything was fine till i
> figure out listing of one domain stops working. When im trying to list
> zone via web panel i'm getting "Internal Server Error". It is happening
> only for default one zone/domain which is used by kerberos too. Here are
> http error logs:
> 
> [Wed Nov 18 06:13:45.226059 2015] [:error] [pid 11045] (70007)The
> timeout specified has expired: [client 172.16.0.117:48072] mod_wsgi
> (pid=11045): Unable to get bucket brigade for request., referer:
> https://freeipa01.domain.local/ipa/ui/
> [Wed Nov 18 06:13:45.226607 2015] [:error] [pid 3929] ipa: ERROR:
> non-public: IOError: request data read error
> [Wed Nov 18 06:13:45.226645 2015] [:error] [pid 3929] Traceback (most
> recent call last):
> [Wed Nov 18 06:13:45.226672 2015] [:error] [pid 3929]   File
> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 339, in
> wsgi_execute
> [Wed Nov 18 06:13:45.226680 2015] [:error] [pid 3929] data =
> read_input(environ)
> [Wed Nov 18 06:13:45.226685 2015] [:error] [pid 3929]   File
> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 187, in
> read_input
> [Wed Nov 18 06:13:45.226693 2015] [:error] [pid 3929] return
> environ['wsgi.input'].read(length)
> [Wed Nov 18 06:13:45.226698 2015] [:error] [pid 3929] IOError: request
> data read error
> [Wed Nov 18 06:13:45.226964 2015] [:error] [pid 3929] ipa: INFO:
> [jsonserver_session] admin@DOMAIN.LOCAL :
> None: IOError
> [Wed Nov 18 06:13:45.227879 2015] [:error] [pid 3929] [remote
> 172.16.0.117:164] mod_wsgi (pid=3929): Exception occurred processing
> WSGI script '/usr/share/ipa/wsgi.py'.
> [Wed Nov 18 06:13:45.227932 2015] [:error] [pid 3929] [remote
> 172.16.0.117:164] IOError: failed to write data

More context would be helpful. I'm assuming that this took a VERY long
time to execute? It looks like the wsgi request timed out.

Can you duplicate this on the CLI using the ipa tool?

> I realize that it stops working after i try to add Ubuntu instance but
> Ubuntu client is not work properly. What is strange when im using
> command client i don't have problem to list it.

I'm not sure I follow. Was it a coincidence after registering an Ubuntu
client or do you think it's the cause?

rob

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project


Re: [Freeipa-users] Invalid UID in persistent keyring name while getting default cache. on OEL 7.1

2015-11-18 Thread Jakub Hrozek
On Wed, Nov 18, 2015 at 04:34:39PM +0100, Christopher Lamb wrote:
> 
> I have a newly installed OEL 7.1 server (7.0 DVD, then yum updated to 7.1)
> The ipa-client is installed, making this server an ipa host.
> 
> 
> 
> > getent passwd 
> 
> is successful for ipa users.  -->OK
> 
> However I cannot log on to the host with ipa users (direct or ssh). -->NOT
> 
> OK
> 
> 
> 
> When logged on as root (local user), I can “su -“ to my ipa user. -->OK
> 
> 
> 
> "> systemctl status sssd" and "> kinit"
> 
> both show:
> 
> “Invalid UID in persistent keyring name while getting default cache.”
> 
> 
> 
> Having googled with this error, I saw some indications that it could be
> 
> related to the kernel.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1017683
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1029110
> 
> 
> 
> For a fresh OEL install, the default kernel is the uek version. "Aha" I
> 
> thought, let’s change back to the standard RHEL kernel.
> 
> After a reboot with the RHEL kernel, I was still not able to log in with my
> 
> ipa user.
> 
> 
> 
> I then logged on as root, and changed to my ipa user via su.
> 
> > klist -l
> 
> produced:
> 
> KEYRING:persistent:93397:krb_cache_76B9lf2 (Expired)

I'm surprised you had any ccache at all, because login as root bypasses
PAM.

But in general, if you login with sssd and the cache is expired a long
time ago (1970), that means sssd logged you in offline and the ccache is
a placeholder for when sssd switches to online mode.

> 
> 
> 
> I therefore deleted the key:
> 
> > kdestroy -A
> 
> Then I stopped the sssd service, and cleared the cache in /var/lib/sss/db/,
> 
> then restarted sssd
> 
> 
> 
> After that I was now able to log on with my ipa user (both direct and via
> 
> ssh).
> 
> 
> 
> However I cannot get any other ipa users to logon to this host!  --> NOT OK
> 
> The same users can successfully logon to other ipa hosts in the same
> 
> domain.
> 
> 
> 
> My ipa user was the one used to enroll the host.
> 
> 
> 
> Any ideas?

Not without logs, see:
https://fedorahosted.org/sssd/wiki/Troubleshooting

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Help understanding issue with CentOS freeipa sudo host groups

2015-11-18 Thread Rob Crittenden
Sparks, Alan wrote:
>  
>>> [root@als-centos0002 sys-ops]# nisdomainname 
>>> dakar.useast.hpcloud.net
>>>
>>> [root@als-centos0002 sys-ops]# getent netgroup opsauto
>>> opsauto  
>>> (als-ubuntu0001.oa.ftc.hpelabs.net,-,eucalyptus.internal)
>>> (als-centos0002.dakar.useast.hpcloud.net,-,eucalyptus.internal)
>>
> 
>> Your NIS domain name doesn't match. dakar.useast.hpcloud.net != 
>> eucalyptus.internal
>> rob
> 
> Thanks for that.   I must be misunderstanding the purpose of the --domain 
> option.
> -Alan
> 

--domain in the server is the default DNS zone for the IPA installation.

--domain in the client tells it where to look for the IPA server in DNS.

There is no actual NIS domain but since netgroups are a NIS construct it
requires something to be set. The NIS domain needs to match the IPA
server domain.

rob

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project


[Freeipa-users] Active Directory Integration and limitations

2015-11-18 Thread Domineaux Philippe
Here is my environment :

1 Windows Domain
Windows workstations
Windows servers
Multiple linux domains
Linux workstations
Linux servers

Here is my goal :

All users are centralized in the Active Directory.
Users will authenticate on linux workstations with their AD accounts (
using POSIX attributes).
Linux workstations must have access to NFS shares on Linux servers.


What are the limitations ?
Windows users equals ipa users in term of services ?

Do I have to configure kerberos to also join directly the Windows Kerberos
Realm,
or will IPA do the job to ask Windows server ?

in etc/krb5.conf :

includedir /var/lib/sss/pubconf/krb5.include.d/

[libdefaults]
  default_realm = IPA.ORG
  dns_lookup_realm = true
  dns_lookup_kdc = true
  rdns = false
  ticket_lifetime = 24h
  forwardable = yes
  udp_preference_limit = 0
  default_ccache_name = KEYRING:persistent:%{uid}
  canonicalize = yes
  allow_weak_crypto = true

[realms]
  IPA.ORG = {
pkinit_anchors = FILE:/etc/ipa/ca.crt
auth_to_local = RULE:[1:$1@
$0](^.*@WINDOMAIN.LOCAL$)s/@WINDOMAIN.LOCAL/@windomain.local/
auth_to_local = DEFAULT

  }

### IS THIS NECESSARY
WINDOMAIN.LOCAL = {
   kdc = srvadipa.windomain.local
   admin_server = srvadipa.windomain.local
}


[domain_realm]
  .cosmo.org = COSMO.ORG
  cosmo.org = COSMO.ORG

### IS THIS NECESSARY

  .windomain.local = WINDOMAIN.LOCAL
  windomain.local = WINDOMAIN.LOCAL




Is the bug in libnfsidmap still active and prevents Windows users to access
to
NFS4 krb5 secured shared folder ?

I currently have

bug here:
https://www.redhat.com/archives/freeipa-users/2014-June/msg00163.html
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Restricting access to unencrypted LDAP connections

2015-11-18 Thread Prashant Bapat
Exactly what I was looking for! Thank you!!

On 18 November 2015 at 13:26, Ludwig Krispenz  wrote:

> you could set minssf:
>
> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/SecureConnections.html#requiring-secure-connections
>
>
> On 11/18/2015 07:24 AM, Prashant Bapat wrote:
>
> Hi,
>
> We have a pair of freeipa servers (4.1.4) and a bunch of Linux clients
> configured to talk to them thru pam-nss-ldapd (no sssd). I want to ensure
> that these clients only talk to freeipa's LDAP server either via ldaps or
> ldap+starttls. Plain ldap should not be allowed.
>
> I can always switch to ldaps only and close the tcp/389 port on the
> firewall. But is there a way to achieve this using tcp/389 port.?
>
> Any suggestions appreciated.
>
> Thanks.
> --Prashant
>
>
>
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] service account for ovirt

2015-11-18 Thread Martin Kosek
On 11/18/2015 08:23 AM, Rob Verduijn wrote:
> Hello all,
> 
> I've read a lot regarding service accounts on this mailinglist in the past.
> But it's rather unclear to me what is the current preffered method to
> create a service account for a service running on a different machine.
> 
> In this case it would be  a service account for ovirt so that freeipa
> users can authenticate in the ovirt portal using their freeipa
> credentials.

It sounds like that you do not want system user account, but you are OK with
service account so that you can get a keytab for your oVirt instance. In that
case, simple

$ ipa service-add HTTP/frontend.ovirt.test
and
$ ipa-getkeytab ...
should be enough, right?

Maybe I just do not understand the use case.

> I could ofcourse create an account and then apply a ldf to set its
> password expiration to the next millennium to make sure the password
> does not expire.
> 
> Anybody who has a good suggestion on how to deal with this ?
> 
> Cheers
> Rob Verduijn
> 

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project


[Freeipa-users] General guidance

2015-11-18 Thread Tushar Sharma
Sir/Mam

Greeting for the day.

I am planing to use freeipa for identity access management for our office
network.

Currently we are not using any identity or access management software for
our users and servers.

We have around 200 systems (approx. 120 linux , 70 windows and 5 mac
systems.)

I have a firewall which supports users from ldap and all users are bound to
authenticate against it for Internet access.

I need i centralized solution for managing my users and servers.

Can you help me in designing a architecture for our  network.
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] FreeIPA Internal Server Error

2015-11-18 Thread Unknown
I'm new here so first of all want to say hello to everyone.

I'm implementing FreeIPA in our environment. Everything was fine till i
figure out listing of one domain stops working. When im trying to list
zone via web panel i'm getting "Internal Server Error". It is happening
only for default one zone/domain which is used by kerberos too. Here
are http error logs:

[Wed Nov 18 06:13:45.226059 2015] [:error] [pid 11045] (70007)The
timeout specified has expired: [client 172.16.0.117:48072] mod_wsgi
(pid=11045): Unable to get bucket brigade for request., referer: https:
//freeipa01.domain.local/ipa/ui/
[Wed Nov 18 06:13:45.226607 2015] [:error] [pid 3929] ipa: ERROR: non-
public: IOError: request data read error
[Wed Nov 18 06:13:45.226645 2015] [:error] [pid 3929] Traceback (most
recent call last):
[Wed Nov 18 06:13:45.226672 2015] [:error] [pid 3929]   File
"/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 339, in
wsgi_execute
[Wed Nov 18 06:13:45.226680 2015] [:error] [pid 3929] data =
read_input(environ)
[Wed Nov 18 06:13:45.226685 2015] [:error] [pid 3929]   File
"/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 187, in
read_input
[Wed Nov 18 06:13:45.226693 2015] [:error] [pid 3929] return
environ['wsgi.input'].read(length)
[Wed Nov 18 06:13:45.226698 2015] [:error] [pid 3929] IOError: request
data read error
[Wed Nov 18 06:13:45.226964 2015] [:error] [pid 3929] ipa: INFO:
[jsonserver_session] admin@DOMAIN.LOCAL: None: IOError
[Wed Nov 18 06:13:45.227879 2015] [:error] [pid 3929] [remote
172.16.0.117:164] mod_wsgi (pid=3929): Exception occurred processing
WSGI script '/usr/share/ipa/wsgi.py'.
[Wed Nov 18 06:13:45.227932 2015] [:error] [pid 3929] [remote
172.16.0.117:164] IOError: failed to write data

I realize that it stops working after i try to add Ubuntu instance but
Ubuntu client is not work properly. What is strange when im using
command client i don't have problem to list it.

Regards
Holo-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] service account for ovirt

2015-11-18 Thread Rob Verduijn
Hello all,

I've read a lot regarding service accounts on this mailinglist in the past.
But it's rather unclear to me what is the current preffered method to
create a service account for a service running on a different machine.

In this case it would be  a service account for ovirt so that freeipa
users can authenticate in the ovirt portal using their freeipa
credentials.

I could ofcourse create an account and then apply a ldf to set its
password expiration to the next millennium to make sure the password
does not expire.

Anybody who has a good suggestion on how to deal with this ?

Cheers
Rob Verduijn

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project