Re: [Freeipa-users] External group membership

2015-04-17 Thread Dmitri Pal

On 04/17/2015 09:12 PM, Benjamen Keroack wrote:

Hi,

We have a number of local groups on our IPA-managed servers that we 
add LDAP/IPA users to. This works fine locally on the server on an ad 
hoc basis:


$ usermod -a -G local-group test.user

However I'm trying to do this as part of user provisioning in IPA via 
user groups. I've created external user groups in IPA, then added 
those external groups to the user groups that new users are added to 
via automember rules. For example:


local-group [external] -> [is a member of] -> developers [IPA group]

Then I SSH into one of the servers as a user who is a member of 
developers:


test.user@qa$ groups
test.user developers qa_users

I do not see 'local-group' membership, even after restarting 
sssd/rebooting. Is it possible to achieve this kind of automatic local 
group membership? The only alternative I can see would be to write a 
SUID binary that .bash_profile runs on login to add them to the 
applicable groups, which seems like a bad hack.


This is IPA 4.1.0 running on RHEL 7.1. Client servers are Ubuntu Trusty.

Thanks for any help,

--
Benjamen Keroack
/Infrastructure/DevOps Engineer/
benja...@dollarshaveclub.com 





It looks like you are looking for this: 
https://fedorahosted.org/sssd/ticket/1591

It is on the roadmap for 1.13 alpha which should be out in couple months.
Would you be interested to test?

--
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

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

Re: [Freeipa-users] 4.1.4 and OTP

2015-04-17 Thread Dmitri Pal

On 04/17/2015 11:21 PM, Janelle wrote:

On 4/17/15 5:59 PM, Dmitri Pal wrote:

On 04/17/2015 08:07 PM, Janelle wrote:





On Apr 17, 2015, at 16:36, Dmitri Pal > wrote:



On 04/17/2015 04:52 PM, Janelle wrote:

On 4/17/15 1:19 PM, Dmitri Pal wrote:

On 04/17/2015 01:20 PM, Janelle wrote:

On 4/17/15 9:53 AM, Dmitri Pal wrote:

On 04/17/2015 11:16 AM, Janelle wrote:

Hi,

Is anyone else having issues with OTP since upgrading? For the 
life of me I can't get it to accept "Sync" for the tokens. No 
matter what is put in, it just keeps saying the username, 
password or tokens entered  are incorrect.


To make it simple - I am tryign this on a brand new CentOS 7.1 
system with a clean/fresh install of FreeIPA 4.1.4 and yet it 
just refuses to work.


I create a user -- configure them. They work just fine with a 
password. Then add a token. Sync with FreeOTP and that all 
works. Then going back to the web UI and do Sync OTP and it 
simply refuses to accept any values. And yet the same user can 
login to the regular web UI with their password.


I have tried setting the user to both Password and OTP for 
auth methods. And also just OTP and nothing works.


Please look in the logs to see what is going on.
You would need to look at the KDC, http and DS logs on the 
server to sort out what is going on.


Do you change the password for the user first after creating him?

Can you reproduce the problem with demo instance?
http://www.freeipa.org/page/Demo
If you can then we can take a look at the logs right away.
Hints? Am I missing  a step?

~J

It appears to be the UI. If I go through the steps and let it 
"fail", I can still login using OTP to servers. I made the 
assumption that the error itself was not an error.. :-)


~J

I am not sure I get what you are saying. Do you still see the 
problem or you misinterpreted the UI and now the problem is gone? 
If you did is there any recommendation how to improve the UI not 
to confuse people?



The problem exists -- this is what it shows:
HOWEVER, it is still WORKING. Meaning, even if you get this error, 
if you attempt to login with your FreeOTP token, it WORKS.


~J






Does it give you this error when you use password or password and 
token?

Can you please describe the flow of steps in more details?
I start browser, go here, click here, enter this, etc.

Are you using SSSD to login to servers? Is SSSD configured with IPA 
provider or you configured it for LDAP manually. There is a 
difference between LDAP and Kerberos authentication.


May be the following article will help you to understand the 
expectations:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System-Level_Authentication_Guide/authconfig-addl-auth.html#enable-otp



I suspect it is some combination of flags and protocols that is 
confusing


Simple. And my test made it simple.
Stand up new vm running fc21/freeipa.
Configure user.
Add password.
Add token.

Login to the vm with the user created using password. Kerberos 
ticket assigned, all is well.


Login to web interface with admin. Change user to OTP only.
Go to web UI and click sync OTP.
Enter username, password and 2 OTP sequences. Click sync. Error appears.

Now, ssh to same vm using OTP username. Enter password + OTP value.
Login successful.


I can reproduce this issue with demo instance.
I will file a bug later today.
I think it is a bug with sync.
Which token do you use time based or event based?

TOTP...

Hmm, makes me wonder - with HOTP fail the same? Off to try it.

~J

PS - is there a way to sync a token from command line? I can't think 
of a way, but maybe...


Yes, there is a command line. But you do not really need to sync it. So 
far it works without syncing as you have noticed.
It seems that the bug is with TOTP token. With HOTP token it seems to 
work fine.


I filed a ticket
https://fedorahosted.org/freeipa/ticket/4990

I also filed another ticket
https://fedorahosted.org/freeipa/ticket/4991

And another one
https://fedorahosted.org/freeipa/ticket/4992







--
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

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

Re: [Freeipa-users] 4.1.4 and OTP

2015-04-17 Thread Janelle

On 4/17/15 5:59 PM, Dmitri Pal wrote:

On 04/17/2015 08:07 PM, Janelle wrote:





On Apr 17, 2015, at 16:36, Dmitri Pal > wrote:



On 04/17/2015 04:52 PM, Janelle wrote:

On 4/17/15 1:19 PM, Dmitri Pal wrote:

On 04/17/2015 01:20 PM, Janelle wrote:

On 4/17/15 9:53 AM, Dmitri Pal wrote:

On 04/17/2015 11:16 AM, Janelle wrote:

Hi,

Is anyone else having issues with OTP since upgrading? For the 
life of me I can't get it to accept "Sync" for the tokens. No 
matter what is put in, it just keeps saying the username, 
password or tokens entered  are incorrect.


To make it simple - I am tryign this on a brand new CentOS 7.1 
system with a clean/fresh install of FreeIPA 4.1.4 and yet it 
just refuses to work.


I create a user -- configure them. They work just fine with a 
password. Then add a token. Sync with FreeOTP and that all 
works. Then going back to the web UI and do Sync OTP and it 
simply refuses to accept any values. And yet the same user can 
login to the regular web UI with their password.


I have tried setting the user to both Password and OTP for auth 
methods. And also just OTP and nothing works.


Please look in the logs to see what is going on.
You would need to look at the KDC, http and DS logs on the 
server to sort out what is going on.


Do you change the password for the user first after creating him?

Can you reproduce the problem with demo instance?
http://www.freeipa.org/page/Demo
If you can then we can take a look at the logs right away.
Hints? Am I missing  a step?

~J

It appears to be the UI. If I go through the steps and let it 
"fail", I can still login using OTP to servers. I made the 
assumption that the error itself was not an error.. :-)


~J

I am not sure I get what you are saying. Do you still see the 
problem or you misinterpreted the UI and now the problem is gone? 
If you did is there any recommendation how to improve the UI not 
to confuse people?



The problem exists -- this is what it shows:
HOWEVER, it is still WORKING. Meaning, even if you get this error, 
if you attempt to login with your FreeOTP token, it WORKS.


~J






Does it give you this error when you use password or password and token?
Can you please describe the flow of steps in more details?
I start browser, go here, click here, enter this, etc.

Are you using SSSD to login to servers? Is SSSD configured with IPA 
provider or you configured it for LDAP manually. There is a 
difference between LDAP and Kerberos authentication.


May be the following article will help you to understand the 
expectations:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System-Level_Authentication_Guide/authconfig-addl-auth.html#enable-otp



I suspect it is some combination of flags and protocols that is 
confusing


Simple. And my test made it simple.
Stand up new vm running fc21/freeipa.
Configure user.
Add password.
Add token.

Login to the vm with the user created using password. Kerberos ticket 
assigned, all is well.


Login to web interface with admin. Change user to OTP only.
Go to web UI and click sync OTP.
Enter username, password and 2 OTP sequences. Click sync. Error appears.

Now, ssh to same vm using OTP username. Enter password + OTP value.
Login successful.


I can reproduce this issue with demo instance.
I will file a bug later today.
I think it is a bug with sync.
Which token do you use time based or event based?

TOTP...

Hmm, makes me wonder - with HOTP fail the same? Off to try it.

~J

PS - is there a way to sync a token from command line? I can't think of 
a way, but maybe...
-- 
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] External group membership

2015-04-17 Thread Benjamen Keroack
Hi,

We have a number of local groups on our IPA-managed servers that we add
LDAP/IPA users to. This works fine locally on the server on an ad hoc basis:

$ usermod -a -G local-group test.user

However I'm trying to do this as part of user provisioning in IPA via user
groups. I've created external user groups in IPA, then added those external
groups to the user groups that new users are added to via automember rules.
For example:

local-group [external] -> [is a member of] -> developers [IPA group]

Then I SSH into one of the servers as a user who is a member of developers:

test.user@qa$ groups
test.user developers qa_users

I do not see 'local-group' membership, even after restarting
sssd/rebooting. Is it possible to achieve this kind of automatic local
group membership? The only alternative I can see would be to write a SUID
binary that .bash_profile runs on login to add them to the applicable
groups, which seems like a bad hack.

This is IPA 4.1.0 running on RHEL 7.1. Client servers are Ubuntu Trusty.

Thanks for any help,

-- 
Benjamen Keroack
*Infrastructure/DevOps Engineer*
benja...@dollarshaveclub.com
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] 4.1.4 and OTP

2015-04-17 Thread Dmitri Pal

On 04/17/2015 08:07 PM, Janelle wrote:





On Apr 17, 2015, at 16:36, Dmitri Pal > wrote:



On 04/17/2015 04:52 PM, Janelle wrote:

On 4/17/15 1:19 PM, Dmitri Pal wrote:

On 04/17/2015 01:20 PM, Janelle wrote:

On 4/17/15 9:53 AM, Dmitri Pal wrote:

On 04/17/2015 11:16 AM, Janelle wrote:

Hi,

Is anyone else having issues with OTP since upgrading? For the 
life of me I can't get it to accept "Sync" for the tokens. No 
matter what is put in, it just keeps saying the username, 
password or tokens entered  are incorrect.


To make it simple - I am tryign this on a brand new CentOS 7.1 
system with a clean/fresh install of FreeIPA 4.1.4 and yet it 
just refuses to work.


I create a user -- configure them. They work just fine with a 
password. Then add a token. Sync with FreeOTP and that all 
works. Then going back to the web UI and do Sync OTP and it 
simply refuses to accept any values. And yet the same user can 
login to the regular web UI with their password.


I have tried setting the user to both Password and OTP for auth 
methods. And also just OTP and nothing works.


Please look in the logs to see what is going on.
You would need to look at the KDC, http and DS logs on the server 
to sort out what is going on.


Do you change the password for the user first after creating him?

Can you reproduce the problem with demo instance?
http://www.freeipa.org/page/Demo
If you can then we can take a look at the logs right away.
Hints? Am I missing  a step?

~J

It appears to be the UI. If I go through the steps and let it 
"fail", I can still login using OTP to servers. I made the 
assumption that the error itself was not an error.. :-)


~J

I am not sure I get what you are saying. Do you still see the 
problem or you misinterpreted the UI and now the problem is gone? 
If you did is there any recommendation how to improve the UI not to 
confuse people?



The problem exists -- this is what it shows:
HOWEVER, it is still WORKING. Meaning, even if you get this error, 
if you attempt to login with your FreeOTP token, it WORKS.


~J






Does it give you this error when you use password or password and token?
Can you please describe the flow of steps in more details?
I start browser, go here, click here, enter this, etc.

Are you using SSSD to login to servers? Is SSSD configured with IPA 
provider or you configured it for LDAP manually. There is a 
difference between LDAP and Kerberos authentication.


May be the following article will help you to understand the 
expectations:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System-Level_Authentication_Guide/authconfig-addl-auth.html#enable-otp



I suspect it is some combination of flags and protocols that is confusing


Simple. And my test made it simple.
Stand up new vm running fc21/freeipa.
Configure user.
Add password.
Add token.

Login to the vm with the user created using password. Kerberos ticket 
assigned, all is well.


Login to web interface with admin. Change user to OTP only.
Go to web UI and click sync OTP.
Enter username, password and 2 OTP sequences. Click sync. Error appears.

Now, ssh to same vm using OTP username. Enter password + OTP value.
Login successful.


I can reproduce this issue with demo instance.
I will file a bug later today.
I think it is a bug with sync.
Which token do you use time based or event based?



Logout.
Repeat, but try JUST the password, and it fails.

???
~J



--
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

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

Re: [Freeipa-users] 4.1.4 and OTP

2015-04-17 Thread Janelle




> On Apr 17, 2015, at 16:36, Dmitri Pal  wrote:
> 
>> On 04/17/2015 04:52 PM, Janelle wrote:
>>> On 4/17/15 1:19 PM, Dmitri Pal wrote:
 On 04/17/2015 01:20 PM, Janelle wrote: 
> On 4/17/15 9:53 AM, Dmitri Pal wrote: 
>> On 04/17/2015 11:16 AM, Janelle wrote: 
>> Hi, 
>> 
>> Is anyone else having issues with OTP since upgrading? For the life of 
>> me I can't get it to accept "Sync" for the tokens. No matter what is put 
>> in, it just keeps saying the username, password or tokens entered  are 
>> incorrect. 
>> 
>> To make it simple - I am tryign this on a brand new CentOS 7.1 system 
>> with a clean/fresh install of FreeIPA 4.1.4 and yet it just refuses to 
>> work. 
>> 
>> I create a user -- configure them. They work just fine with a password. 
>> Then add a token. Sync with FreeOTP and that all works. Then going back 
>> to the web UI and do Sync OTP and it simply refuses to accept any 
>> values. And yet the same user can login to the regular web UI with their 
>> password. 
>> 
>> I have tried setting the user to both Password and OTP for auth methods. 
>> And also just OTP and nothing works. 
> 
> Please look in the logs to see what is going on. 
> You would need to look at the KDC, http and DS logs on the server to sort 
> out what is going on. 
> 
> Do you change the password for the user first after creating him? 
> 
> Can you reproduce the problem with demo instance? 
> http://www.freeipa.org/page/Demo 
> If you can then we can take a look at the logs right away. 
> Hints? Am I missing  a step? 
> 
> ~J 
> 
 It appears to be the UI. If I go through the steps and let it "fail", I 
 can still login using OTP to servers. I made the assumption that the error 
 itself was not an error.. :-) 
 
 ~J 
 
>>> I am not sure I get what you are saying. Do you still see the problem or 
>>> you misinterpreted the UI and now the problem is gone? If you did is there 
>>> any recommendation how to improve the UI not to confuse people? 
>>> 
>> The problem exists -- this is what it shows:
>> HOWEVER, it is still WORKING. Meaning, even if you get this error, if you 
>> attempt to login with your FreeOTP token, it WORKS.
>> 
>> ~J
>> 
>> 
>> 
>> 
> 
> Does it give you this error when you use password or password and token?
> Can you please describe the flow of steps in more details?
> I start browser, go here, click here, enter this, etc.
> 
> Are you using SSSD to login to servers? Is SSSD configured with IPA provider 
> or you configured it for LDAP manually. There is a difference between LDAP 
> and Kerberos authentication.
> 
> May be the following article will help you to understand the expectations:
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System-Level_Authentication_Guide/authconfig-addl-auth.html#enable-otp
> 
> 
> 
> I suspect it is some combination of flags and protocols that is confusing

Simple. And my test made it simple.
Stand up new vm running fc21/freeipa.
Configure user.
Add password.
Add token.

Login to the vm with the user created using password. Kerberos ticket assigned, 
all is well.

Login to web interface with admin. Change user to OTP only.
Go to web UI and click sync OTP. 
Enter username, password and 2 OTP sequences. Click sync. Error appears.

Now, ssh to same vm using OTP username. Enter password + OTP value.
Login successful.

Logout.
Repeat, but try JUST the password, and it fails.

???
~J-- 
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] 4.1.4 and OTP

2015-04-17 Thread Dmitri Pal

On 04/17/2015 04:52 PM, Janelle wrote:

On 4/17/15 1:19 PM, Dmitri Pal wrote:

On 04/17/2015 01:20 PM, Janelle wrote:

On 4/17/15 9:53 AM, Dmitri Pal wrote:

On 04/17/2015 11:16 AM, Janelle wrote:

Hi,

Is anyone else having issues with OTP since upgrading? For the 
life of me I can't get it to accept "Sync" for the tokens. No 
matter what is put in, it just keeps saying the username, password 
or tokens entered  are incorrect.


To make it simple - I am tryign this on a brand new CentOS 7.1 
system with a clean/fresh install of FreeIPA 4.1.4 and yet it just 
refuses to work.


I create a user -- configure them. They work just fine with a 
password. Then add a token. Sync with FreeOTP and that all works. 
Then going back to the web UI and do Sync OTP and it simply 
refuses to accept any values. And yet the same user can login to 
the regular web UI with their password.


I have tried setting the user to both Password and OTP for auth 
methods. And also just OTP and nothing works.


Please look in the logs to see what is going on.
You would need to look at the KDC, http and DS logs on the server 
to sort out what is going on.


Do you change the password for the user first after creating him?

Can you reproduce the problem with demo instance?
http://www.freeipa.org/page/Demo
If you can then we can take a look at the logs right away.
Hints? Am I missing  a step?

~J

It appears to be the UI. If I go through the steps and let it 
"fail", I can still login using OTP to servers. I made the 
assumption that the error itself was not an error.. :-)


~J

I am not sure I get what you are saying. Do you still see the problem 
or you misinterpreted the UI and now the problem is gone? If you did 
is there any recommendation how to improve the UI not to confuse people?



The problem exists -- this is what it shows:
HOWEVER, it is still WORKING. Meaning, even if you get this error, if 
you attempt to login with your FreeOTP token, it WORKS.


~J






Does it give you this error when you use password or password and token?
Can you please describe the flow of steps in more details?
I start browser, go here, click here, enter this, etc.

Are you using SSSD to login to servers? Is SSSD configured with IPA 
provider or you configured it for LDAP manually. There is a difference 
between LDAP and Kerberos authentication.


May be the following article will help you to understand the expectations:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System-Level_Authentication_Guide/authconfig-addl-auth.html#enable-otp



I suspect it is some combination of flags and protocols that is confusing.

--
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

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

Re: [Freeipa-users] Stuck getting sudo working with Ubuntu client

2015-04-17 Thread Andrew Sacamano
Thanks Lukas,

I'm very glad to have concrete debugging suggestions. I'll investigate as
you suggest and report back.

Thanks again,

Andrew

On Fri, Apr 17, 2015 at 2:28 PM, Lukas Slebodnik 
wrote:

> On (17/04/15 11:32), Andrew Sacamano wrote:
> >Hi everyone,
> >
> >
> >I've spent a couple of days digging around the web, watching logs, and
> >poking things, and I'm stuck getting sudo working with IPA on a new box
> >I've just set up. I have had it working in the past on a test box, but
> >something about this box is blocking me, and I can't for the life of me
> >figure out what.
> >
> >
> >The basic symptom is that I can log into the Ubuntu box as an IPA user,
> but
> >sudo is always denied:
> >
> >
> >[root@security-core-1 log]# ssh dru@jenkins
> >
> >dru@jenkins's password:
> >
> >...
> >
> >Could not chdir to home directory /home/dru: No such file or directory
> >
> >dru@jenkins:/$ sudo -l
> >
> >[sudo] password for dru:
> >
> >Sorry, user dru may not run sudo on jenkins.
> >
> >
> >I've appended version output, config files, sample logs, and ipa config -
> >which I think is all of the relevant material, but I'll gladly share more
> >if it's needed.
> >
> >
> >Thanks so much in advance for any debugging advice, hints, or help!
> >
> >
>
> I looked to the configuration files and they look good.
>
> I have few hints which might help you with troubleshooting
> * please ensure you have installed package sudo and not sudo-ldap.
>   The second one is not build with sssd support.
> * please read about sudo caching in sssd
>   man sssd-sudo -> THE SUDO RULE CACHING MECHANISM
> * please test simple sudo rules first.
>   (all hosts, one user instead of groups, ...)
> * check whether sudo rules are cached by sssd (use ldb-tools)
>
> If previous hints does not help then you need to enable
> debugging in sudo and analyse log file.
> @see slide 18 in presentation[1]
>
> LS
>
> [1] http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf
>
-- 
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] 4.1.4 and OTP

2015-04-17 Thread Janelle

On 4/17/15 1:19 PM, Dmitri Pal wrote:

On 04/17/2015 01:20 PM, Janelle wrote:

On 4/17/15 9:53 AM, Dmitri Pal wrote:

On 04/17/2015 11:16 AM, Janelle wrote:

Hi,

Is anyone else having issues with OTP since upgrading? For the life 
of me I can't get it to accept "Sync" for the tokens. No matter 
what is put in, it just keeps saying the username, password or 
tokens entered  are incorrect.


To make it simple - I am tryign this on a brand new CentOS 7.1 
system with a clean/fresh install of FreeIPA 4.1.4 and yet it just 
refuses to work.


I create a user -- configure them. They work just fine with a 
password. Then add a token. Sync with FreeOTP and that all works. 
Then going back to the web UI and do Sync OTP and it simply refuses 
to accept any values. And yet the same user can login to the 
regular web UI with their password.


I have tried setting the user to both Password and OTP for auth 
methods. And also just OTP and nothing works.


Please look in the logs to see what is going on.
You would need to look at the KDC, http and DS logs on the server to 
sort out what is going on.


Do you change the password for the user first after creating him?

Can you reproduce the problem with demo instance?
http://www.freeipa.org/page/Demo
If you can then we can take a look at the logs right away.
Hints? Am I missing  a step?

~J

It appears to be the UI. If I go through the steps and let it "fail", 
I can still login using OTP to servers. I made the assumption that 
the error itself was not an error.. :-)


~J

I am not sure I get what you are saying. Do you still see the problem 
or you misinterpreted the UI and now the problem is gone? If you did 
is there any recommendation how to improve the UI not to confuse people?



The problem exists -- this is what it shows:
HOWEVER, it is still WORKING. Meaning, even if you get this error, if 
you attempt to login with your FreeOTP token, it WORKS.


~J


-- 
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] Stuck getting sudo working with Ubuntu client

2015-04-17 Thread Lukas Slebodnik
On (17/04/15 11:32), Andrew Sacamano wrote:
>Hi everyone,
>
>
>I've spent a couple of days digging around the web, watching logs, and
>poking things, and I'm stuck getting sudo working with IPA on a new box
>I've just set up. I have had it working in the past on a test box, but
>something about this box is blocking me, and I can't for the life of me
>figure out what.
>
>
>The basic symptom is that I can log into the Ubuntu box as an IPA user, but
>sudo is always denied:
>
>
>[root@security-core-1 log]# ssh dru@jenkins
>
>dru@jenkins's password:
>
>...
>
>Could not chdir to home directory /home/dru: No such file or directory
>
>dru@jenkins:/$ sudo -l
>
>[sudo] password for dru:
>
>Sorry, user dru may not run sudo on jenkins.
>
>
>I've appended version output, config files, sample logs, and ipa config -
>which I think is all of the relevant material, but I'll gladly share more
>if it's needed.
>
>
>Thanks so much in advance for any debugging advice, hints, or help!
>
>

I looked to the configuration files and they look good.

I have few hints which might help you with troubleshooting
* please ensure you have installed package sudo and not sudo-ldap.
  The second one is not build with sssd support.
* please read about sudo caching in sssd
  man sssd-sudo -> THE SUDO RULE CACHING MECHANISM
* please test simple sudo rules first.
  (all hosts, one user instead of groups, ...)
* check whether sudo rules are cached by sssd (use ldb-tools)

If previous hints does not help then you need to enable
debugging in sudo and analyse log file.
@see slide 18 in presentation[1]

LS

[1] http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf

-- 
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] 4.1.4 and OTP

2015-04-17 Thread Dmitri Pal

On 04/17/2015 01:20 PM, Janelle wrote:

On 4/17/15 9:53 AM, Dmitri Pal wrote:

On 04/17/2015 11:16 AM, Janelle wrote:

Hi,

Is anyone else having issues with OTP since upgrading? For the life 
of me I can't get it to accept "Sync" for the tokens. No matter what 
is put in, it just keeps saying the username, password or tokens 
entered  are incorrect.


To make it simple - I am tryign this on a brand new CentOS 7.1 
system with a clean/fresh install of FreeIPA 4.1.4 and yet it just 
refuses to work.


I create a user -- configure them. They work just fine with a 
password. Then add a token. Sync with FreeOTP and that all works. 
Then going back to the web UI and do Sync OTP and it simply refuses 
to accept any values. And yet the same user can login to the regular 
web UI with their password.


I have tried setting the user to both Password and OTP for auth 
methods. And also just OTP and nothing works.


Please look in the logs to see what is going on.
You would need to look at the KDC, http and DS logs on the server to 
sort out what is going on.


Do you change the password for the user first after creating him?

Can you reproduce the problem with demo instance?
http://www.freeipa.org/page/Demo
If you can then we can take a look at the logs right away.
Hints? Am I missing  a step?

~J

It appears to be the UI. If I go through the steps and let it "fail", 
I can still login using OTP to servers. I made the assumption that the 
error itself was not an error.. :-)


~J

I am not sure I get what you are saying. Do you still see the problem or 
you misinterpreted the UI and now the problem is gone? If you did is 
there any recommendation how to improve the UI not to confuse people?


--
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

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


[Freeipa-users] Stuck getting sudo working with Ubuntu client

2015-04-17 Thread Andrew Sacamano
Hi everyone,


I've spent a couple of days digging around the web, watching logs, and
poking things, and I'm stuck getting sudo working with IPA on a new box
I've just set up. I have had it working in the past on a test box, but
something about this box is blocking me, and I can't for the life of me
figure out what.


The basic symptom is that I can log into the Ubuntu box as an IPA user, but
sudo is always denied:


[root@security-core-1 log]# ssh dru@jenkins

dru@jenkins's password:

...

Could not chdir to home directory /home/dru: No such file or directory

dru@jenkins:/$ sudo -l

[sudo] password for dru:

Sorry, user dru may not run sudo on jenkins.


I've appended version output, config files, sample logs, and ipa config -
which I think is all of the relevant material, but I'll gladly share more
if it's needed.


Thanks so much in advance for any debugging advice, hints, or help!


Cheers,


Andrew




===

Version info

===


Server:

# ipa --version

VERSION: 4.1.0, API_VERSION: 2.112


# cat /etc/redhat-release

CentOS Linux release 7.1.1503 (Core)


Client:

# cat /etc/lsb-release

DISTRIB_ID=Ubuntu

DISTRIB_RELEASE=14.04

DISTRIB_CODENAME=trusty

DISTRIB_DESCRIPTION="Ubuntu 14.04.2 LTS"


#sssd --version

1.11.5




===

hostname, nisdomainname, config files, etc.

===


On the client:


# hostname

jenkins.us-ca1.prod.mydomain.com


# nisdomainname

mydomain.com


# getent netgroup rdn | grep $HOSTNAME

rdn   (jenkins.us-ca1.prod.mydomain.com,-,mydomain.com)



# cat /etc/sssd/sssd.conf

[domain/mydomain.com]


cache_credentials = True

krb5_store_password_if_offline = True

ipa_domain = mydomain.com

id_provider = ipa

auth_provider = ipa

access_provider = ipa

ldap_tls_cacert = /etc/ipa/ca.crt

ipa_hostname = jenkins.us-ca1.prod.mydomain.com

chpass_provider = ipa

ipa_server = _srv_, security-core-1.prod.mydomain.com

dns_discovery_domain = mydomain.com

sudo_provider=ipa

[sssd]

services = nss, pam, ssh, sudo

config_file_version = 2


domains = mydomain.com

[nss]


[pam]


[sudo]

debug_level = 9


[autofs]


[ssh]


[pac]



# cat /etc/nsswitch.conf

# /etc/nsswitch.conf

#

# Example configuration of GNU Name Service Switch functionality.

# If you have the `glibc-doc-reference' and `info' packages installed, try:

# `info libc "Name Service Switch"' for information about this file.


passwd: compat sss

group:  compat sss

shadow: compat


hosts:  files dns

networks:   files


protocols:  db files

services:   db files

ethers: db files

rpc:db files


netgroup:   nis sss

sudoers:files sss



===

Host & group & user info in IPA

===


# ipa host-show jenkins.us-ca1.prod.mydomain.com

  Host name: jenkins.us-ca1.prod.mydomain.com

  Certificate: ...

  Principal name: host/jenkins.us-ca1.prod.mydomain@mydomain.com

  Password: False

  Member of host-groups: rdn

  Member of Sudo rule: priv_sudo_anywhere, dru_security

  Keytab: True

  Managed by: jenkins.us-ca1.prod.mydomain.com

  Subject: CN=jenkins.us-ca1.prod.mydomain.com,O=MYDOMAIN.COM

  Serial Number: 14

  Serial Number (hex): 0xE

  Issuer: CN=Certificate Authority,O=MYDOMAIN.COM

  Not Before: Fri Apr 10 17:43:10 2015 UTC

  Not After: Mon Apr 10 17:43:10 2017 UTC

  Fingerprint (MD5): ...

  Fingerprint (SHA1): ...

  SSH public key fingerprint: ...


# ipa sudorule-show priv_sudo_anywhere

  Rule name: priv_sudo_anywhere

  Description: Allow anyone with priv_sudo_anywhere to actually run sudo
anywhere

  Enabled: TRUE

  Command category: all

  RunAs User category: all

  RunAs Group category: all

  User Groups: priv_sudo_anywhere

  Hosts: jenkins.us-ca1.prod.mydomain.com

  Host Groups: security, dev-infrastructure, rdn, dev, prod


# ipa group-show priv_sudo_anywhere

  Group name: priv_sudo_anywhere

  Description: Give the privilege to SSH anywhere.

  GID: 1907

  Member users: dru, ...

  Member groups: role_prod_engineer

  Member of Sudo rule: priv_sudo_anywhere, ...

  Member of HBAC rule: sudo_anywhere_anywhere

  Indirect Member users: 



===

Relevant (I think) log entries

===


# tail -f /var/log/sssd/sssd_sudo.log

...

(Fri Apr 17 17:20:16 2015) [sssd[sudo]] [sbus_dispatch] (0x4000): dbus conn:
0x15b6520

(Fri Apr 17 17:20:16 2015) [sssd[sudo]] [sbus_dispatch] (0x4000):
Dispatching.

(Fri Apr 17 17:20:16 2015) [sssd[sudo]] [sbus_message_handler] (0x4000):
Received SBUS method [ping]




(From a different attempt to run sudo)


# tail -f /var/log/auth.log

...

Apr 17 17:20:55 jenkins sshd[3335]: pam_unix(sshd:auth): authentication
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=
security-core-1.prod.mydomain.com  user=dru

Apr 17 17:20:55 jenkins sshd[3335]: pam_sss(sshd:auth): authentication
success; logname= uid=0 euid=0 tty=ssh ruser= rhost=
security-core-1.prod.mydomain.com user=dru

Apr 1

Re: [Freeipa-users] 4.1.4 and OTP

2015-04-17 Thread Janelle

On 4/17/15 9:53 AM, Dmitri Pal wrote:

On 04/17/2015 11:16 AM, Janelle wrote:

Hi,

Is anyone else having issues with OTP since upgrading? For the life 
of me I can't get it to accept "Sync" for the tokens. No matter what 
is put in, it just keeps saying the username, password or tokens 
entered  are incorrect.


To make it simple - I am tryign this on a brand new CentOS 7.1 system 
with a clean/fresh install of FreeIPA 4.1.4 and yet it just refuses 
to work.


I create a user -- configure them. They work just fine with a 
password. Then add a token. Sync with FreeOTP and that all works. 
Then going back to the web UI and do Sync OTP and it simply refuses 
to accept any values. And yet the same user can login to the regular 
web UI with their password.


I have tried setting the user to both Password and OTP for auth 
methods. And also just OTP and nothing works.


Please look in the logs to see what is going on.
You would need to look at the KDC, http and DS logs on the server to 
sort out what is going on.


Do you change the password for the user first after creating him?

Can you reproduce the problem with demo instance?
http://www.freeipa.org/page/Demo
If you can then we can take a look at the logs right away.
Hints? Am I missing  a step?

~J

It appears to be the UI. If I go through the steps and let it "fail", I 
can still login using OTP to servers. I made the assumption that the 
error itself was not an error.. :-)


~J

--
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] Pro/Con on Admin accounts

2015-04-17 Thread Dmitri Pal

On 04/17/2015 12:11 PM, Ash Alam wrote:

Hello

I wanted to get some input on what your approach is for admin 
accounts. In the past i approached it where you have a user `John Doe` 
he has a normal user account for everyday tasks (wifi, anything that 
talks ldap). He also has an admin account for when he needs to 
administer ipa, active directory etc.


There are few groups of thought around this. Mine being that admin 
permissions should not be granted to accounts that are not 
specifically create to administer ipa/ad. I have worked at places 
where admin and user accounts were one in the same and others where 
they were separated.


Currently i have an opportunity to start fresh and wanted to get some 
input as to what the best approach would be. Freeipa and its 
developers are security conscious and its built around security so 
getting your though on this would be great.


Thank You


I do not think there is a clear cut rule you can follow. This is why you 
have the experience with both approaches.
The question that I would ask is how significantly the administrative 
activity is logically segregated from end user activity in your environment.
If there are a lot of areas that only special accounts can get to and no 
end user can routinely access then probably having a logical separation 
of the accounts would be better.
If admins and users can access the same systems and applications and 
just have different privileges then you need to focus on access control 
anyways so having separate accounts would be more overhead than gain.


But this is just my take on this. Others might disagree.

--
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

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

Re: [Freeipa-users] 4.1.4 and OTP

2015-04-17 Thread Dmitri Pal

On 04/17/2015 11:16 AM, Janelle wrote:

Hi,

Is anyone else having issues with OTP since upgrading? For the life of 
me I can't get it to accept "Sync" for the tokens. No matter what is 
put in, it just keeps saying the username, password or tokens entered  
are incorrect.


To make it simple - I am tryign this on a brand new CentOS 7.1 system 
with a clean/fresh install of FreeIPA 4.1.4 and yet it just refuses to 
work.


I create a user -- configure them. They work just fine with a 
password. Then add a token. Sync with FreeOTP and that all works. Then 
going back to the web UI and do Sync OTP and it simply refuses to 
accept any values. And yet the same user can login to the regular web 
UI with their password.


I have tried setting the user to both Password and OTP for auth 
methods. And also just OTP and nothing works.


Please look in the logs to see what is going on.
You would need to look at the KDC, http and DS logs on the server to 
sort out what is going on.


Do you change the password for the user first after creating him?

Can you reproduce the problem with demo instance?
http://www.freeipa.org/page/Demo
If you can then we can take a look at the logs right away.




Hints? Am I missing  a step?

~J




--
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

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


Re: [Freeipa-users] Critique

2015-04-17 Thread Dmitri Pal

On 04/17/2015 03:33 AM, Jan Pazdziora wrote:

On Fri, Apr 17, 2015 at 09:14:33AM +0200, Andrew Holway wrote:

In an obviously blatant promotion exercise and attempt to build page
rank

Please could I have some critique on this article?

http://otternetworks.de/tech/freeipa-technical-brief/

Your feedback would be really appreciated

Nice.

One detail -- Red Hat prefers its name to be spelled "Red Hat".


Yes. Great article.
I agree with other comments.
It seems that you really have two parts: overview of the technologies 
and OpenVPN setup. May be it would make sense to have two parts of the 
article.
Then the title can be "Overview of the modern Open Source Identity 
Management technologies and their use to provide 2FA with OpenVPN".

A bit long but right to the point.

--
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

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


[Freeipa-users] Pro/Con on Admin accounts

2015-04-17 Thread Ash Alam
Hello

I wanted to get some input on what your approach is for admin accounts. In
the past i approached it where you have a user `John Doe` he has a normal
user account for everyday tasks (wifi, anything that talks ldap). He also
has an admin account for when he needs to administer ipa, active directory
etc.

There are few groups of thought around this. Mine being that admin
permissions should not be granted to accounts that are not specifically
create to administer ipa/ad. I have worked at places where admin and user
accounts were one in the same and others where they were separated.

Currently i have an opportunity to start fresh and wanted to get some input
as to what the best approach would be. Freeipa and its developers are
security conscious and its built around security so getting your though on
this would be great.

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

[Freeipa-users] 4.1.4 and OTP

2015-04-17 Thread Janelle

Hi,

Is anyone else having issues with OTP since upgrading? For the life of 
me I can't get it to accept "Sync" for the tokens. No matter what is put 
in, it just keeps saying the username, password or tokens entered  are 
incorrect.


To make it simple - I am tryign this on a brand new CentOS 7.1 system 
with a clean/fresh install of FreeIPA 4.1.4 and yet it just refuses to 
work.


I create a user -- configure them. They work just fine with a password. 
Then add a token. Sync with FreeOTP and that all works. Then going back 
to the web UI and do Sync OTP and it simply refuses to accept any 
values. And yet the same user can login to the regular web UI with their 
password.


I have tried setting the user to both Password and OTP for auth methods. 
And also just OTP and nothing works.


Hints? Am I missing  a step?

~J

--
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] LDAP bind failing on new IPA setup

2015-04-17 Thread Sumit Bose
On Fri, Apr 17, 2015 at 10:29:31AM -0400, Gould, Joshua wrote:
> We setup our new IPA server (RHEL7) with a trust against our AD domain. The 
> trust and ID range look right in IPA
> 
> [root sssd]# ipa trust-show
> Realm name: example.com
>   Realm name: EXAMPLE.COM
>   Domain NetBIOS name: EXAMPLE
>   Domain Security Identifier: S-1-5-21-
>   Trust direction: Two-way trust
>   Trust type: Active Directory domain
> [root sssd]# ipa idrange-find --all
> 
> 2 ranges matched
> 
>   dn: cn=EXAMPLE.COM_id_range,cn=ranges,cn=etc,dc=examle,dc=com
>   Range name: EXAMPLE.COM_id_range
>   First Posix ID of the range: 200
>   Number of IDs in the range: 90
>   First RID of the corresponding RID range: 0
>   Domain SID of the trusted domain: S-1-5-21-
>   Range type: Active Directory domain range
>   iparangetyperaw: ipa-ad-trust
>   objectclass: ipatrustedaddomainrange, ipaIDrange
> 
>   dn: cn=UNIX.EXAMPLE.COM_id_range,cn=ranges,cn=etc,dc=example,dc=com
>   Range name: UNIX.EXAMPLE.COM_id_range
>   First Posix ID of the range: 36960
>   Number of IDs in the range: 20
>   First RID of the corresponding RID range: 1000
>   First RID of the secondary RID range: 1
>   Range type: local domain range
>   iparangetyperaw: ipa-local
>   objectclass: top, ipaIDrange, ipaDomainIDRange
> 
> Number of entries returned 2
> 
> [root sssd]#
> 
> I see that the bind fails but I’m not sure why. Here are the errors. Could 
> someone point me in the right direction please?
> 
> (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] 
> [sdap_get_server_opts_from_rootdse] (0x0100): Setting AD compatibility level 
> to [4]
> (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [sdap_kinit_send] 
> (0x0400): Attempting kinit (default, host/xxx, UNIX.EXAMPLE.COM, 86400)
> (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [sdap_kinit_next_kdc] 
> (0x1000): Resolving next KDC for service EXAMPLE.COM
> (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] 
> [fo_resolve_service_send] (0x0100): Trying to resolve service 'EXAMPLE.COM'
> (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [get_server_status] 
> (0x1000): Status of server 'domain_controller.EXAMPLE.COM' is 'name resolved'
> (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] 
> [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6 
> seconds
> (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [resolve_srv_send] 
> (0x0200): The status of SRV lookup is resolved
> (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [get_server_status] 
> (0x1000): Status of server 'domain_controller.EXAMPLE.COM' is 'name resolved'
> (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] 
> [be_resolve_server_process] (0x1000): Saving the first resolved server
> (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] 
> [be_resolve_server_process] (0x0200): Found address for server 
> domain_controller.EXAMPLE.COM: [1.2.3.4] TTL 3600
> (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] 
> [sdap_kinit_kdc_resolved] (0x1000): KDC resolved, attempting to get TGT...
> (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] 
> [create_tgt_req_send_buffer] (0x0400): buffer size: 70
> (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [child_handler_setup] 
> (0x2000): Setting up signal handler up for pid [8734]
> (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [child_handler_setup] 
> (0x2000): Signal handler set up for pid [8734]
> (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] 
> [set_tgt_child_timeout] (0x0400): Setting 6 seconds timeout for tgt child
> (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [sdap_process_result] 
> (0x2000): Trace: sh[0x7f6ca7b71b70], connected[1], ops[(nil)], 
> ldap[0x7f6ca7b89f20]
> (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [sdap_process_result] 
> (0x2000): Trace: ldap_result found nothing!
> (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [write_pipe_handler] 
> (0x0400): All data has been sent!
> (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [child_sig_handler] 
> (0x1000): Waiting for child [8734].
> (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [child_sig_handler] 
> (0x0100): child [8734] finished successfully.
> (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [read_pipe_handler] 
> (0x0400): EOF received, client finished
> (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [sdap_get_tgt_recv] 
> (0x0400): Child responded: 0 [FILE:/var/lib/sss/db/ccache_UNIX.EXAMPLE.COM], 
> expired on [1429366284]
> (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [sdap_cli_auth_step] 
> (0x0100): expire timeout is 900
> (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [sdap_cli_auth_step] 
> (0x1000): the connection will expire at 1429280784
> (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [sasl_bind_send] 
> 

Re: [Freeipa-users] LDAP bind failing on new IPA setup

2015-04-17 Thread Alexander Bokovoy

On Fri, 17 Apr 2015, Gould, Joshua wrote:

We setup our new IPA server (RHEL7) with a trust against our AD domain.
The trust and ID range look right in IPA

[root sssd]# ipa trust-show
Realm name: example.com
 Realm name: EXAMPLE.COM
 Domain NetBIOS name: EXAMPLE
 Domain Security Identifier: S-1-5-21-
 Trust direction: Two-way trust
 Trust type: Active Directory domain
[root sssd]# ipa idrange-find --all

2 ranges matched

 dn: cn=EXAMPLE.COM_id_range,cn=ranges,cn=etc,dc=examle,dc=com
 Range name: EXAMPLE.COM_id_range
 First Posix ID of the range: 200
 Number of IDs in the range: 90
 First RID of the corresponding RID range: 0
 Domain SID of the trusted domain: S-1-5-21-
 Range type: Active Directory domain range
 iparangetyperaw: ipa-ad-trust
 objectclass: ipatrustedaddomainrange, ipaIDrange

 dn: cn=UNIX.EXAMPLE.COM_id_range,cn=ranges,cn=etc,dc=example,dc=com
 Range name: UNIX.EXAMPLE.COM_id_range
 First Posix ID of the range: 36960
 Number of IDs in the range: 20
 First RID of the corresponding RID range: 1000
 First RID of the secondary RID range: 1
 Range type: local domain range
 iparangetyperaw: ipa-local
 objectclass: top, ipaIDrange, ipaDomainIDRange

Number of entries returned 2


Either you obfuscated too much or your setup makes little sense as IPA
local domain ID range is for unix.example.com while your realm is
EXAMPLE.COM and AD realm is EXAMPLE.COM. This is not going to work --
IPA and AD has to have different realms.



[root sssd]#

I see that the bind fails but I’m not sure why. Here are the errors.
Could someone point me in the right direction please?


A single line you need to look at is this:
(Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [sasl_bind_send] 
(0x0080): Extended failure message: [SASL(-1): generic failure: GSSAPI Error: 
Unspecified GSS failure.  Minor code may provide more information (KDC policy 
rejects request)]

KDC policy rejects request is Kerberos way of saying "My realm doesn't
trust your realm, go away".

In order to know what exactly is wrong, do following (it is all written
in the troubleshooting section of the trust documentation on FreeIPA
wiki):

1. add 'log level = 100' to [global] section of
/usr/share/ipa/smb.conf.empty

2. Without restarting anything, re-establish trust with 'ipa trust-add ...'.

3. Look into /var/log/http/error_log to see a response for something
like this:
s4_tevent: Run immediate event "tevent_req_trigger": 0x7f5ccc084a40
netr_LogonControl2Ex: struct netr_LogonControl2Ex
   out: struct netr_LogonControl2Ex
   query: *
   query: union 
netr_CONTROL_QUERY_INFORMATION(case 2)
   info2: *
   info2: struct netr_NETLOGON_INFO_2
   flags: 0x00b0 (176)
  0: NETLOGON_REPLICATION_NEEDED
  0: NETLOGON_REPLICATION_IN_PROGRESS
  0: NETLOGON_FULL_SYNC_REPLICATION
  0: NETLOGON_REDO_NEEDED 
  1: NETLOGON_HAS_IP  
  1: NETLOGON_HAS_TIMESERV
  0: NETLOGON_DNS_UPDATE_FAILURE

  1: NETLOGON_VERIFY_STATUS_RETURNED
   pdc_connection_status: WERR_OK
   trusted_dc_name  : *
   trusted_dc_name  : '\\rh7-1.ipacloud7.test'
   tc_connection_status : WERR_OK
   result   : WERR_OK

If instead of WERR_OK in pdc_connection_status  you have something else,
that is telling an error. Show us the output like above.


--
/ Alexander Bokovoy

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

[Freeipa-users] LDAP bind failing on new IPA setup

2015-04-17 Thread Gould, Joshua
We setup our new IPA server (RHEL7) with a trust against our AD domain. The 
trust and ID range look right in IPA

[root sssd]# ipa trust-show
Realm name: example.com
  Realm name: EXAMPLE.COM
  Domain NetBIOS name: EXAMPLE
  Domain Security Identifier: S-1-5-21-
  Trust direction: Two-way trust
  Trust type: Active Directory domain
[root sssd]# ipa idrange-find --all

2 ranges matched

  dn: cn=EXAMPLE.COM_id_range,cn=ranges,cn=etc,dc=examle,dc=com
  Range name: EXAMPLE.COM_id_range
  First Posix ID of the range: 200
  Number of IDs in the range: 90
  First RID of the corresponding RID range: 0
  Domain SID of the trusted domain: S-1-5-21-
  Range type: Active Directory domain range
  iparangetyperaw: ipa-ad-trust
  objectclass: ipatrustedaddomainrange, ipaIDrange

  dn: cn=UNIX.EXAMPLE.COM_id_range,cn=ranges,cn=etc,dc=example,dc=com
  Range name: UNIX.EXAMPLE.COM_id_range
  First Posix ID of the range: 36960
  Number of IDs in the range: 20
  First RID of the corresponding RID range: 1000
  First RID of the secondary RID range: 1
  Range type: local domain range
  iparangetyperaw: ipa-local
  objectclass: top, ipaIDrange, ipaDomainIDRange

Number of entries returned 2

[root sssd]#

I see that the bind fails but I’m not sure why. Here are the errors. Could 
someone point me in the right direction please?

(Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] 
[sdap_get_server_opts_from_rootdse] (0x0100): Setting AD compatibility level to 
[4]
(Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [sdap_kinit_send] 
(0x0400): Attempting kinit (default, host/xxx, UNIX.EXAMPLE.COM, 86400)
(Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [sdap_kinit_next_kdc] 
(0x1000): Resolving next KDC for service EXAMPLE.COM
(Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] 
[fo_resolve_service_send] (0x0100): Trying to resolve service 'EXAMPLE.COM'
(Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [get_server_status] 
(0x1000): Status of server 'domain_controller.EXAMPLE.COM' is 'name resolved'
(Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] 
[fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6 seconds
(Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [resolve_srv_send] 
(0x0200): The status of SRV lookup is resolved
(Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [get_server_status] 
(0x1000): Status of server 'domain_controller.EXAMPLE.COM' is 'name resolved'
(Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] 
[be_resolve_server_process] (0x1000): Saving the first resolved server
(Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] 
[be_resolve_server_process] (0x0200): Found address for server 
domain_controller.EXAMPLE.COM: [1.2.3.4] TTL 3600
(Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] 
[sdap_kinit_kdc_resolved] (0x1000): KDC resolved, attempting to get TGT...
(Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] 
[create_tgt_req_send_buffer] (0x0400): buffer size: 70
(Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [child_handler_setup] 
(0x2000): Setting up signal handler up for pid [8734]
(Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [child_handler_setup] 
(0x2000): Signal handler set up for pid [8734]
(Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [set_tgt_child_timeout] 
(0x0400): Setting 6 seconds timeout for tgt child
(Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [sdap_process_result] 
(0x2000): Trace: sh[0x7f6ca7b71b70], connected[1], ops[(nil)], 
ldap[0x7f6ca7b89f20]
(Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [sdap_process_result] 
(0x2000): Trace: ldap_result found nothing!
(Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [write_pipe_handler] 
(0x0400): All data has been sent!
(Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [child_sig_handler] 
(0x1000): Waiting for child [8734].
(Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [child_sig_handler] 
(0x0100): child [8734] finished successfully.
(Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [read_pipe_handler] 
(0x0400): EOF received, client finished
(Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [sdap_get_tgt_recv] 
(0x0400): Child responded: 0 [FILE:/var/lib/sss/db/ccache_UNIX.EXAMPLE.COM], 
expired on [1429366284]
(Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [sdap_cli_auth_step] 
(0x0100): expire timeout is 900
(Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [sdap_cli_auth_step] 
(0x1000): the connection will expire at 1429280784
(Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [sasl_bind_send] 
(0x0100): Executing sasl bind mech: gssapi, user: 
host/ipa_server.unix.EXAMPLE.COM
(Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [sasl_bind_send] 
(0x0020): ldap_sasl_bind failed (-2)[Local error]
(Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE

Re: [Freeipa-users] Expired Certs

2015-04-17 Thread Rob Crittenden
John Williams wrote:
> 
>> You are going way to far back in time AFAICT. The certs expired on April
>> 5 of this year so you don't need to go back to 2014. Just go back to
>> April 3 or 4.
> 
>> You'll also need to restart IPA before kicking certmonger ipactl restart
> 
>> rob
> 
> 
> 
> 
> ***  SNIP ***
> 
> Thanks!!
> 
> 
> Following your advice, it looks like only one of the eight certificates
> are now monitoring.  Check out the following:

It's impossible to see what is going on with this output, other than the
fact that your hostname seems to be using the shortname rather than FQDN
(or order is bad in /etc/hosts), based on the error for the cert in
MONITORING.

rob

> 
> 
> [root@ipa ~]# getcert list | grep -A1 status
> status: CA_UNREACHABLE
> ca-error: Error 60 connecting to
> https://ipa.infra.idef:9443/ca/agent/ca/profileReview: Peer certificate
> cannot be authenticated with known CA certificates.
> --
> status: CA_UNREACHABLE
> ca-error: Error 60 connecting to
> https://ipa.infra.idef:9443/ca/agent/ca/profileReview: Peer certificate
> cannot be authenticated with known CA certificates.
> --
> status: CA_UNREACHABLE
> ca-error: Error 60 connecting to
> https://ipa.infra.idef:9443/ca/agent/ca/profileReview: Peer certificate
> cannot be authenticated with known CA certificates.
> --
> status: CA_UNREACHABLE
> ca-error: Error 60 connecting to
> https://ipa.infra.idef:9443/ca/agent/ca/profileReview: Peer certificate
> cannot be authenticated with known CA certificates.
> --
> status: CA_UNREACHABLE
> ca-error: Error 60 connecting to
> https://ipa.infra.idef:9443/ca/agent/ca/profileReview: Peer certificate
> cannot be authenticated with known CA certificates.
> --
> status: CA_UNREACHABLE
> ca-error: Server at https://ipa.infra.idef/ipa/xml failed request, will
> retry: 4301 (RPC failed at server.  Certificate operation cannot be
> completed: EXCEPTION (Invalid Credential.)).
> --
> status: CA_UNREACHABLE
> ca-error: Server at https://ipa.infra.idef/ipa/xml failed request, will
> retry: 4301 (RPC failed at server.  Certificate operation cannot be
> completed: EXCEPTION (Invalid Credential.)).
> --
> status: MONITORING
> ca-error: Server at https://ipa.infra.idef/ipa/xml denied our request,
> giving up: 2100 (RPC failed at server.  Insufficient access: hostname in
> subject of request 'ipa.infra.idef' does not match principal hostname
> 'ipa').
> 
> How can I get the remaining certs fixed as well?  Thanks in advance.
> 
> 
> 

-- 
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] posix ids not propgating

2015-04-17 Thread Rob Crittenden
Bryan Pearson wrote:
> Am I mistaken in your example:
> 
> "You can find the master it is trying to talk to here:
> $ ldapsearch -x -D 'cn=Directory Manager' -W -b
> cn=posix-ids,cn=dna,cn=ipa,cn=etc,dc=example,dc=com"
> 
> Mine:
> $ ldapsearch -x -D 'cn=Directory Manager' -W -b
> cn=posix-ids,cn=dna,cn=ipa,cn=etc,dc=EXAMPLE,dc=lan

You're not sharing enough information. A list of DNA hosts tells us
nothing when we don't know which host you're having a problem on, if a
host is down or has been replaced, etc.

I'd poke around the DNA plugin configuration in cn=config on each master
to see what the actual DNA configuration is. You have one with the
default max 1000, next 1001 expired configuration pointing at a host
that is either down or has no ranges.

Or easier, if you are running IPA 3.3+ then ipa-replica-manage has some
DNA commands which makes this easier to figure out and fix.

You don't want to set overlapping ranges.

rob

> Bryan
> 
> 
> On Fri, Apr 17, 2015 at 9:19 AM, Rob Crittenden  wrote:
>> Bryan Pearson wrote:
>>> I believe that my master dna server isnt currently being used, so I did 
>>> this.
>>>
>>> ldapsearch -x -D 'cn=Directory Manager' -W -b
>>> cn=posix-ids,cn=dna,cn=ipa,cn=etc,dc=EXAMPLE,dc=lan
>>> Enter LDAP Password:
>>
>> That's not the right location to search for the DNA configuration. See
>> http://blog-rcritten.rhcloud.com/?p=50
>>
>> 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] Expired Certs

2015-04-17 Thread John Williams

> You are going way to far back in time AFAICT. The certs expired on April
> 5 of this year so you don't need to go back to 2014. Just go back to
> April 3 or 4.

> You'll also need to restart IPA before kicking certmonger ipactl restart

> rob



***  SNIP ***
Thanks!!

Following your advice, it looks like only one of the eight certificates are now 
monitoring.  Check out the following:

[root@ipa ~]# getcert list | grep -A1 status status: CA_UNREACHABLE ca-error: 
Error 60 connecting to https://ipa.infra.idef:9443/ca/agent/ca/profileReview: 
Peer certificate cannot be authenticated with known CA certificates.-- status: 
CA_UNREACHABLE ca-error: Error 60 connecting to 
https://ipa.infra.idef:9443/ca/agent/ca/profileReview: Peer certificate cannot 
be authenticated with known CA certificates.-- status: CA_UNREACHABLE ca-error: 
Error 60 connecting to https://ipa.infra.idef:9443/ca/agent/ca/profileReview: 
Peer certificate cannot be authenticated with known CA certificates.-- status: 
CA_UNREACHABLE ca-error: Error 60 connecting to 
https://ipa.infra.idef:9443/ca/agent/ca/profileReview: Peer certificate cannot 
be authenticated with known CA certificates.-- status: CA_UNREACHABLE ca-error: 
Error 60 connecting to https://ipa.infra.idef:9443/ca/agent/ca/profileReview: 
Peer certificate cannot be authenticated with known CA certificates.-- status: 
CA_UNREACHABLE ca-error: Server at https://ipa.infra.idef/ipa/xml failed 
request, will retry: 4301 (RPC failed at server.  Certificate operation cannot 
be completed: EXCEPTION (Invalid Credential.)).-- status: CA_UNREACHABLE 
ca-error: Server at https://ipa.infra.idef/ipa/xml failed request, will retry: 
4301 (RPC failed at server.  Certificate operation cannot be completed: 
EXCEPTION (Invalid Credential.)).-- status: MONITORING ca-error: Server at 
https://ipa.infra.idef/ipa/xml denied our request, giving up: 2100 (RPC failed 
at server.  Insufficient access: hostname in subject of request 
'ipa.infra.idef' does not match principal hostname 'ipa').
How can I get the remaining certs fixed as well?  Thanks in advance.
 

 -- 
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] posix ids not propgating

2015-04-17 Thread Bryan Pearson
Am I mistaken in your example:

"You can find the master it is trying to talk to here:
$ ldapsearch -x -D 'cn=Directory Manager' -W -b
cn=posix-ids,cn=dna,cn=ipa,cn=etc,dc=example,dc=com"

Mine:
$ ldapsearch -x -D 'cn=Directory Manager' -W -b
cn=posix-ids,cn=dna,cn=ipa,cn=etc,dc=EXAMPLE,dc=lan
Bryan


On Fri, Apr 17, 2015 at 9:19 AM, Rob Crittenden  wrote:
> Bryan Pearson wrote:
>> I believe that my master dna server isnt currently being used, so I did this.
>>
>> ldapsearch -x -D 'cn=Directory Manager' -W -b
>> cn=posix-ids,cn=dna,cn=ipa,cn=etc,dc=EXAMPLE,dc=lan
>> Enter LDAP Password:
>
> That's not the right location to search for the DNA configuration. See
> http://blog-rcritten.rhcloud.com/?p=50
>
> 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] ipa-replica-prepare failing

2015-04-17 Thread Jan Cholasta

Hi,

I don't have any new information. I'm trying to reproduce the problem 
but had no luck so far.


Honza

Dne 17.4.2015 v 15:23 David Dejaeghere napsal(a):

Hi,

Any more things I can try out? How do we proceed?

Kind Regards,

D

2015-04-15 11:48 GMT+02:00 David Dejaeghere mailto:david.dejaegh...@gmail.com>>:

Hi Honza,

That gave me the exact same output.  Any ideas?

Regards,

D

2015-04-15 7:33 GMT+02:00 Jan Cholasta mailto:jchol...@redhat.com>>:

Hi,

Dne 14.4.2015 v 19:47 Rob Crittenden napsal(a):

David Dejaeghere wrote:

Hi Rob,

So you want to output of the command using pk12 with
server cert and
key? or with the ca chain in there too?


Oddly enough it is failing in exactly the same place. Those
GoDaddy CA
certs are still being loaded from somewhere, I'm not sure
where, and I
suspect that is the source of the problem.


They are in the default CA certificate bundle (in the
ca-certificate package). I guess NSS loads it automatically.


I'm going to forward the log to a colleague who has worked
on this code
more recently than I have. Maybe he will have an idea.


Could you try if the following works?

 # mv /usr/share/pki/ca-trust-__source/ca-bundle.trust.crt
/root/ca-bundle.trust.crt

 # update-ca-trust

 # ipa-replica-prepare ...

 # mv /root/ca-bundle.trust.crt
/usr/share/pki/ca-trust-__source/ca-bundle.trust.crt

 # update-ca-trust


rob


Honza

--
Jan Cholasta






--
Jan Cholasta

--
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] ipa-replica-prepare failing

2015-04-17 Thread David Dejaeghere
Hi,

Any more things I can try out? How do we proceed?

Kind Regards,

D

2015-04-15 11:48 GMT+02:00 David Dejaeghere :

> Hi Honza,
>
> That gave me the exact same output.  Any ideas?
>
> Regards,
>
> D
>
> 2015-04-15 7:33 GMT+02:00 Jan Cholasta :
>
>> Hi,
>>
>> Dne 14.4.2015 v 19:47 Rob Crittenden napsal(a):
>>
>>> David Dejaeghere wrote:
>>>
 Hi Rob,

 So you want to output of the command using pk12 with server cert and
 key? or with the ca chain in there too?


>>> Oddly enough it is failing in exactly the same place. Those GoDaddy CA
>>> certs are still being loaded from somewhere, I'm not sure where, and I
>>> suspect that is the source of the problem.
>>>
>>
>> They are in the default CA certificate bundle (in the ca-certificate
>> package). I guess NSS loads it automatically.
>>
>>
>>> I'm going to forward the log to a colleague who has worked on this code
>>> more recently than I have. Maybe he will have an idea.
>>>
>>
>> Could you try if the following works?
>>
>> # mv /usr/share/pki/ca-trust-source/ca-bundle.trust.crt
>> /root/ca-bundle.trust.crt
>>
>> # update-ca-trust
>>
>> # ipa-replica-prepare ...
>>
>> # mv /root/ca-bundle.trust.crt /usr/share/pki/ca-trust-
>> source/ca-bundle.trust.crt
>>
>> # update-ca-trust
>>
>>
>>> rob
>>>
>>>
>> Honza
>>
>> --
>> Jan Cholasta
>>
>
>
-- 
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] posix ids not propgating

2015-04-17 Thread Rob Crittenden
Bryan Pearson wrote:
> I believe that my master dna server isnt currently being used, so I did this.
> 
> ldapsearch -x -D 'cn=Directory Manager' -W -b
> cn=posix-ids,cn=dna,cn=ipa,cn=etc,dc=EXAMPLE,dc=lan
> Enter LDAP Password:

That's not the right location to search for the DNA configuration. See
http://blog-rcritten.rhcloud.com/?p=50

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] posix ids not propgating

2015-04-17 Thread Bryan Pearson
I believe that my master dna server isnt currently being used, so I did this.

ldapsearch -x -D 'cn=Directory Manager' -W -b
cn=posix-ids,cn=dna,cn=ipa,cn=etc,dc=EXAMPLE,dc=lan
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# posix-ids, dna, ipa, etc, EXAMPLE.lan
dn: cn=posix-ids,cn=dna,cn=ipa,cn=etc,dc=EXAMPLE,dc=lan
objectClass: nsContainer
objectClass: top
cn: posix-ids

# ipa3.EXAMPLE.lan + 0, posix-ids, dna, ipa, etc, EXAMPLE.lan
dn: dnaHostname=ipa3.EXAMPLE.lan+dnaPortNum=0,cn=posix-ids,cn=dna
 ,cn=ipa,cn=etc,dc=EXAMPLE,dc=lan
dnaRemainingValues: 0
dnaSecurePortNum: 636
dnaPortNum: 0
dnaHostname: ipa3.EXAMPLE.lan
objectClass: dnaSharedConfig
objectClass: top

# ipa3.EXAMPLE.lan + 389, posix-ids, dna, ipa, etc, EXAMPLE.lan
dn: dnaHostname=ipa3.EXAMPLE.lan+dnaPortNum=389,cn=posix-ids,cn=d
 na,cn=ipa,cn=etc,dc=EXAMPLE,dc=lan
dnaRemainingValues: 7
dnaSecurePortNum: 636
dnaPortNum: 389
dnaHostname: ipa3.EXAMPLE.lan
objectClass: dnaSharedConfig
objectClass: top

# ipa4.EXAMPLE.lan + 389, posix-ids, dna, ipa, etc, EXAMPLE.lan
dn: dnaHostname=ipa4.EXAMPLE.lan+dnaPortNum=389,cn=posix-ids,cn=dna,cn=ip
 a,cn=etc,dc=EXAMPLE,dc=lan
objectClass: dnaSharedConfig
objectClass: top
dnaHostname: ipa4.EXAMPLE.lan
dnaPortNum: 389
dnaSecurePortNum: 636
dnaRemainingValues: 0

# ipa2.EXAMPLE.lan + 389, posix-ids, dna, ipa, etc, EXAMPLE.lan
dn: dnaHostname=ipa2.EXAMPLE.lan+dnaPortNum=389,cn=posix-ids,cn
 =dna,cn=ipa,cn=etc,dc=EXAMPLE,dc=lan
objectClass: dnaSharedConfig
objectClass: top
dnaHostname: ipa2.EXAMPLE.lan
dnaPortNum: 389
dnaSecurePortNum: 636
dnaRemainingValues: 0

# search result
search: 2
result: 0 Success

# numResponses: 6
# numEntries: 5
Bryan


On Fri, Apr 17, 2015 at 7:08 AM, Sumit Bose  wrote:
> On Fri, Apr 17, 2015 at 06:36:24AM -0400, Bryan Pearson wrote:
>> Should I add the same range to this machine or give each one it's own id
>> range?
>
> The ranges are global for the whole IPA domain. The idranges manages
> with the ipa tool have their data in the replicated tree hence changes
> are available on all replicas. The DNA plugin has its own scheme to
> distribute the data, see e.g.
>
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/Managing-Unique_UID_and_GID_Attributes.html
>
> for details.
>
> bye,
> Sumit
>> On Apr 17, 2015 3:53 AM, "Sumit Bose"  wrote:
>>
>> > On Thu, Apr 16, 2015 at 07:46:55PM -0400, Bryan Pearson wrote:
>> > > I ran this comand on each of my IPA servers and one returned usable
>> > > response: ipa idrange-find
>> > >
>> > > ---
>> > > 1 range matched
>> > > ---
>> > >   Range name: HOSTNAME.LAN_id_range
>> > >   First Posix ID of the range: 192020
>> > >   Number of IDs in the range: 30
>> > >   Range type: local domain range
>> > > 
>> > > Number of entries returned 1
>> > > 
>> > >
>> > > While trying to add a new user on one of the other severs I recieve:
>> > > ***
>> > > Operations error: Allocation of a new value for range cn=posix
>> > > ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config
>> > > failed! Unable to proceed.
>> > > ***
>> >
>> > This is expected, unfortunately the idranges used to manage different
>> > idranges in environments with trust and the range used by the DNA plugin
>> > to assign IDs to local users and groups are currently not connected.
>> > There is ticket https://fedorahosted.org/freeipa/ticket/3609 to fix
>> > this.
>> >
>> > bye,
>> > Sumit
>> >
>> > >
>> > > Should I go forward on other masters and do:
>> > >
>> > > ***
>> > > ldapmodify -x -D 'cn=Directory Manager' -W
>> > > Enter LDAP Password:
>> > > dn: cn=Posix IDs,cn=Distributed Numeric Assignment
>> > Plugin,cn=plugins,cn=config
>> > > changetype: modify
>> > > replace: dnaNextValue
>> > > dnaNextValue: 168970
>> > > -
>> > > replace: dnaMaxValue
>> > > dnaMaxValue: 168979
>> > > ^D
>> > >
>> > > modifying entry "cn=Posix IDs,cn=Distributed Numeric Assignment
>> > > Plugin,cn=plugins,cn=config"
>> > > ***
>> > >
>> > > --
>> > > 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] posix ids not propgating

2015-04-17 Thread Sumit Bose
On Fri, Apr 17, 2015 at 06:36:24AM -0400, Bryan Pearson wrote:
> Should I add the same range to this machine or give each one it's own id
> range?

The ranges are global for the whole IPA domain. The idranges manages
with the ipa tool have their data in the replicated tree hence changes
are available on all replicas. The DNA plugin has its own scheme to
distribute the data, see e.g.

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/Managing-Unique_UID_and_GID_Attributes.html

for details.

bye,
Sumit
> On Apr 17, 2015 3:53 AM, "Sumit Bose"  wrote:
> 
> > On Thu, Apr 16, 2015 at 07:46:55PM -0400, Bryan Pearson wrote:
> > > I ran this comand on each of my IPA servers and one returned usable
> > > response: ipa idrange-find
> > >
> > > ---
> > > 1 range matched
> > > ---
> > >   Range name: HOSTNAME.LAN_id_range
> > >   First Posix ID of the range: 192020
> > >   Number of IDs in the range: 30
> > >   Range type: local domain range
> > > 
> > > Number of entries returned 1
> > > 
> > >
> > > While trying to add a new user on one of the other severs I recieve:
> > > ***
> > > Operations error: Allocation of a new value for range cn=posix
> > > ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config
> > > failed! Unable to proceed.
> > > ***
> >
> > This is expected, unfortunately the idranges used to manage different
> > idranges in environments with trust and the range used by the DNA plugin
> > to assign IDs to local users and groups are currently not connected.
> > There is ticket https://fedorahosted.org/freeipa/ticket/3609 to fix
> > this.
> >
> > bye,
> > Sumit
> >
> > >
> > > Should I go forward on other masters and do:
> > >
> > > ***
> > > ldapmodify -x -D 'cn=Directory Manager' -W
> > > Enter LDAP Password:
> > > dn: cn=Posix IDs,cn=Distributed Numeric Assignment
> > Plugin,cn=plugins,cn=config
> > > changetype: modify
> > > replace: dnaNextValue
> > > dnaNextValue: 168970
> > > -
> > > replace: dnaMaxValue
> > > dnaMaxValue: 168979
> > > ^D
> > >
> > > modifying entry "cn=Posix IDs,cn=Distributed Numeric Assignment
> > > Plugin,cn=plugins,cn=config"
> > > ***
> > >
> > > --
> > > 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] posix ids not propgating

2015-04-17 Thread Bryan Pearson
Should I add the same range to this machine or give each one it's own id
range?
On Apr 17, 2015 3:53 AM, "Sumit Bose"  wrote:

> On Thu, Apr 16, 2015 at 07:46:55PM -0400, Bryan Pearson wrote:
> > I ran this comand on each of my IPA servers and one returned usable
> > response: ipa idrange-find
> >
> > ---
> > 1 range matched
> > ---
> >   Range name: HOSTNAME.LAN_id_range
> >   First Posix ID of the range: 192020
> >   Number of IDs in the range: 30
> >   Range type: local domain range
> > 
> > Number of entries returned 1
> > 
> >
> > While trying to add a new user on one of the other severs I recieve:
> > ***
> > Operations error: Allocation of a new value for range cn=posix
> > ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config
> > failed! Unable to proceed.
> > ***
>
> This is expected, unfortunately the idranges used to manage different
> idranges in environments with trust and the range used by the DNA plugin
> to assign IDs to local users and groups are currently not connected.
> There is ticket https://fedorahosted.org/freeipa/ticket/3609 to fix
> this.
>
> bye,
> Sumit
>
> >
> > Should I go forward on other masters and do:
> >
> > ***
> > ldapmodify -x -D 'cn=Directory Manager' -W
> > Enter LDAP Password:
> > dn: cn=Posix IDs,cn=Distributed Numeric Assignment
> Plugin,cn=plugins,cn=config
> > changetype: modify
> > replace: dnaNextValue
> > dnaNextValue: 168970
> > -
> > replace: dnaMaxValue
> > dnaMaxValue: 168979
> > ^D
> >
> > modifying entry "cn=Posix IDs,cn=Distributed Numeric Assignment
> > Plugin,cn=plugins,cn=config"
> > ***
> >
> > --
> > 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] posix ids not propgating

2015-04-17 Thread Sumit Bose
On Thu, Apr 16, 2015 at 07:46:55PM -0400, Bryan Pearson wrote:
> I ran this comand on each of my IPA servers and one returned usable
> response: ipa idrange-find
> 
> ---
> 1 range matched
> ---
>   Range name: HOSTNAME.LAN_id_range
>   First Posix ID of the range: 192020
>   Number of IDs in the range: 30
>   Range type: local domain range
> 
> Number of entries returned 1
> 
> 
> While trying to add a new user on one of the other severs I recieve:
> ***
> Operations error: Allocation of a new value for range cn=posix
> ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config
> failed! Unable to proceed.
> ***

This is expected, unfortunately the idranges used to manage different
idranges in environments with trust and the range used by the DNA plugin
to assign IDs to local users and groups are currently not connected.
There is ticket https://fedorahosted.org/freeipa/ticket/3609 to fix
this.

bye,
Sumit

> 
> Should I go forward on other masters and do:
> 
> ***
> ldapmodify -x -D 'cn=Directory Manager' -W
> Enter LDAP Password:
> dn: cn=Posix IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config
> changetype: modify
> replace: dnaNextValue
> dnaNextValue: 168970
> -
> replace: dnaMaxValue
> dnaMaxValue: 168979
> ^D
> 
> modifying entry "cn=Posix IDs,cn=Distributed Numeric Assignment
> Plugin,cn=plugins,cn=config"
> ***
> 
> -- 
> 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] Critique

2015-04-17 Thread Alexander Bokovoy

On Fri, 17 Apr 2015, Andrew Holway wrote:

In an obviously blatant promotion exercise and attempt to build page
rank

Please could I have some critique on this article?

http://otternetworks.de/tech/freeipa-technical-brief/

Your feedback would be really appreciated

Thanks for the nice article showing how to enable OpenVPN with
two-factor authentication.

My notes:
- Title is misleading as article is about setting up OpenVPN with
  two-factor auth, not really about FreeIPA itself

- You mention "Using a completely standard client OpenVPN configuration
  with only one addition “auth-user-pass” to prompt for a password we
  are able to use OpenVPN to log into a network using password+OTP."
  However, there is no config example that shows it. I would add that,
  along the lines of using PAM plugin.

- It would probably be good to mention that by using PAM authentication
  plugin you also get HBAC rules from FreeIPA to fine tune which users
  can actually use this VPN concentrator. As it is, any user from your
  system would be able to use VPN but most probably you'd want to limit
  them by group membership and it is better to achieve by using HBAC
  rules.


--
/ Alexander Bokovoy

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

Re: [Freeipa-users] Critique

2015-04-17 Thread Jan Pazdziora
On Fri, Apr 17, 2015 at 09:14:33AM +0200, Andrew Holway wrote:
> In an obviously blatant promotion exercise and attempt to build page
> rank
> 
> Please could I have some critique on this article?
> 
> http://otternetworks.de/tech/freeipa-technical-brief/
> 
> Your feedback would be really appreciated

Nice.

One detail -- Red Hat prefers its name to be spelled "Red Hat".

-- 
Jan Pazdziora
Senior Principal Software Engineer, Identity Management Engineering, Red Hat

-- 
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] Critique

2015-04-17 Thread Andrew Holway
In an obviously blatant promotion exercise and attempt to build page
rank

Please could I have some critique on this article?

http://otternetworks.de/tech/freeipa-technical-brief/

Your feedback would be really appreciated

Thanks,

Andrew
-- 
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