Re: [Freeipa-users] Announcing FreeIPA v2 Server Release Candidate 2 Release

[Sigbjorn Lie]

Hi,

I updated my IPA test servers last night without a problem. I have only the 
default Fedora 14 repo
+ Fedora 14 updates-testing repo and the Freeipa-devel repo enabled on my IPA 
test servers.


Rgds,
Siggi




On Tue, March 1, 2011 01:32, Steven Jones wrote:
> I have tried to download the rpms by hand and the dependencies are all
> broken ie pythonwell stuffed by the looks of it...
>
> regards
>
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
>
>


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

[Freeipa-users] IPA v2 in Red Hat

[Sigbjorn Lie]

Hi,

Is there a roadmap for when version 2 of IPA is expected to be seen in RHEL?


Regards,
Siggi


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

Re: [Freeipa-users] IPA v2 in Red Hat

[Sigbjorn Lie]

On Tue, March 1, 2011 15:06, Dmitri Pal wrote:
> On 03/01/2011 06:11 AM, Sigbjorn Lie wrote:
>
>> Hi,
>>
>>
>> Is there a roadmap for when version 2 of IPA is expected to be seen in RHEL?
>>
>>
>>
>> Regards,
>> Siggi
>>
>>
>>
>> ___
>> Freeipa-users mailing list
>> Freeipa-users@redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>
>>
>>
>
> It is planned to be in tech preview in RHEL 6.1.
> We will be working towards releasing it as a fully supported version in
> RHEL 6.2.
>
>
> --
> Thank you,
> Dmitri Pal
>
>
> Sr. Engineering Manager IPA project,
> Red Hat Inc.
>
>
>


Hi,

Thank you for your answer.

Is there a release date for 6.1 yet?



Rgds,
Siggi


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

Re: [Freeipa-users] RC3 Install fails with " Unable to connect to LDAP server "

[Sigbjorn Lie]

On 03/12/2011 09:58 PM, tomasz.napier...@allegro.pl wrote:

On 2011-03-12, at 20:06, tomasz.napier...@allegro.pl wrote:


Hi,
I'm trying to install FreeIPA 2.0. RC3 on fresh, minimal F14 box, but it fails 
for some reason:

Looks like the problem is that my realm is different than domain name (QXLTEST 
vs. DC2). After accepting defaults installation was completed succesfully. Can 
anybody confirm?

Regards,

Hi,

I reinstalled and found the same to be the problem for me.


Rgds,
Siggi

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

Re: [Freeipa-users] Sync with AD error

[Sigbjorn Lie]

On 03/13/2011 08:35 PM, Simo Sorce wrote:

On Fri, 11 Mar 2011 21:31:50 +0100
Sigbjørn Lie  wrote:



On 03/11/2011 09:15 PM, Dmitri Pal wrote:

On 03/11/2011 03:00 PM, Sigbjørn Lie wrote:

Hi,

I just upgraded my FreeIPA @ F14 to 2.0.0.rc3, and attempted to
add a sync agreement with Active Directory.

Did you upgrade in place or re-installed?
The recent (a month ago or so) changes moved the location of the
replication agreements.
There were a lot of other changes in this area.
We do not support smooth migration between beta and RCs that would
have taken too much effort.
Can you please try on a fresh install?

Thank you
Dmitri


Added CA certificate /root/testing-ca.cer to certificate database
for ipasrv01.ix.testing.com
ipa: INFO: AD Suffix is: DC=ad,DC=testing,DC=com
The user for the Windows PassSync service is
uid=passsync,cn=sysaccounts,cn=etc,dc=ix,dc=testing,dc=com
Windows PassSync entry exists, not resetting password
ipa: INFO: Added new sync agreement, waiting for it to become
ready . . . ipa: INFO: Replication Update in progress: FALSE:
status: 0 Replica acquired successfully: Incremental update
succeeded: start: 20110311195207Z: end: 20110311195207Z
ipa: INFO: Agreement is ready, starting replication . . .
ipa: INFO: Failed to create public entry for winsync replica
Starting replication, please wait until this has completed.
Update succeeded
Connected 'ipasrv01.ix.testing.com' to 'addc01.ad.testing.com'


Now I can't list the sync agreements. All I get is:

# ipa-replica-manage list
unexpected error: * not found

Any ideas?


Rgds,
Siggi

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




Hi,

I upgraded in place. I did the initial installation on the 12th of
February. I think I started out with the first RC. Do I still have to
reinstall?

Have you run ipa-ldap-updater after the rpm upgrade ?

Simo.





Hi,

Yes I have.



Rgds,
Siggi



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

[Freeipa-users] Delete AD replica failure

[Sigbjorn Lie]

Hi,

I just did a fresh installation of FreeIPA 2 on a host called ipa1, 
created a replica on a second server called ipa2. I then created a 
winsync replica to an AD domain on the ipa1 host.


I noticed that I forgot the --win-subtree option and decided to delete 
the replication agreement:


# ipa-replica-manage -H ipa1.ix.nowhere.com del dc01.ad.nowhere.com
Directory Manager password:
Unable to delete replica dc01.ad.nowhere.com: {'desc': "Can't contact 
LDAP server"}



If I did a force a got a bit more output, where it complains about the 
ipa2 replica server not having a sync agreement with the dc01 server.


# ipa-replica-manage -v -f -H ipa1.ix.nowhere.com del dc01.ad.nowhere.com
Directory Manager password:
Unable to connect to replica dc01.ad.nowhere.com, forcing removal
Forcing removal on 'dc01.ad.nowhere.com'
'ipa2.ix.nowhere.com' has no replication agreement for 'dc01.ad.nowhere.com'


Is this intended behavior or a bug?

After re-creating the sync agreement with the win-subtree option, IPA 
synced with AD successfully.



Rgds,
Siggi

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

Re: [Freeipa-users] Delete AD replica failure

[Sigbjorn Lie]

On 03/21/2011 02:31 PM, Simo Sorce wrote:

On Sun, 20 Mar 2011 18:28:12 +0100
Sigbjorn Lie  wrote:


Hi,

I just did a fresh installation of FreeIPA 2 on a host called ipa1,
created a replica on a second server called ipa2. I then created a
winsync replica to an AD domain on the ipa1 host.

I noticed that I forgot the --win-subtree option and decided to
delete the replication agreement:

# ipa-replica-manage -H ipa1.ix.nowhere.com del dc01.ad.nowhere.com
Directory Manager password:
Unable to delete replica dc01.ad.nowhere.com: {'desc': "Can't contact
LDAP server"}

This is not the correct command to use.


If I did a force a got a bit more output, where it complains about
the ipa2 replica server not having a sync agreement with the dc01
server.

# ipa-replica-manage -v -f -H ipa1.ix.nowhere.com del
dc01.ad.nowhere.com Directory Manager password:
Unable to connect to replica dc01.ad.nowhere.com, forcing removal
Forcing removal on 'dc01.ad.nowhere.com'
'ipa2.ix.nowhere.com' has no replication agreement for
'dc01.ad.nowhere.com'


Is this intended behavior or a bug?

Intended, to remove the AD replication link you need to 'disconnect'
the AD server.

Use:
ipa-replica-manage disconnect dc01.ad.nowhere.com


Ah, thank you. :)

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

[Freeipa-users] Adding user accounts

[Sigbjorn Lie]

Hi,

Using --gidnumber when adding a new user with "ipa user-add" does not 
seem to have any effect. A gid number with the same value as what I 
specify in with the --uid parameter is chosen.


I presume this is not the way user-add is intended to work?


# ipa user-add mysql14 --first=MySQL --last=Server 
--homedir=/var/lib/mysql --shell=/bin/false --uid=110 --gidnumber=3004


Added user "mysql14"

  User login: mysql14
  First name: MySQL
  Last name: Server
  Full name: MySQL Server
  Display name: MySQL Server
  Initials: MS
  Home directory: /var/lib/mysql
  GECOS field: mysql14
  Login shell: /bin/false
  Kerberos principal: mysq...@ix.nixtra.com
  UID: 110
  GID: 110



Regards,
Siggi

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

[Freeipa-users] NIS/local files to IPA migration

[Sigbjorn Lie]

Hi,

I have written some scripts for migration from NIS/local files to IPA. 
They will import the passwd, group, netgroup, and hosts  maps.


This is the first version, be aware of bugs. :)

Please read the README file before using.

You can download them from here if you are interested: 
http://www.nixtra.com/ipa/NIS-TO-IPA-current.php



Rgds,
Siggi

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

Re: [Freeipa-users] Adding user accounts

[Sigbjorn Lie]

On Mon, March 28, 2011 11:10, Martin Kosek wrote:
> On Fri, 2011-03-25 at 20:13 +0100, Sigbjorn Lie wrote:
>
>> Hi,
>>
>>
>> Using --gidnumber when adding a new user with "ipa user-add" does not
>> seem to have any effect. A gid number with the same value as what I specify 
>> in with the --uid
>> parameter is chosen.
>>
>> I presume this is not the way user-add is intended to work?
>>
>>
>>
>> # ipa user-add mysql14 --first=MySQL --last=Server
>> --homedir=/var/lib/mysql --shell=/bin/false --uid=110 --gidnumber=3004
>> 
>> Added user "mysql14"
>> 
>> User login: mysql14
>> First name: MySQL
>> Last name: Server
>> Full name: MySQL Server
>> Display name: MySQL Server
>> Initials: MS
>> Home directory: /var/lib/mysql
>> GECOS field: mysql14
>> Login shell: /bin/false
>> Kerberos principal: mysq...@ix.nixtra.com
>> UID: 110
>> GID: 110
>>
>>
>>
>>
>> Regards,
>> Siggi
>>
>>
>
> Hello Sigbjorn,
>
>
> it is not common to manually specify GID. Can you please tell me what's your 
> use case for doing
> that? Maybe I can help with a proper way to do that.
>
> In your case, GID was set to UID because it's the GID of User Private
> Group "mysql14" which was automatically associated with the user
> "mysql14".
>
>
> Martin
>

Hi Martin,

I discovered this when I was writing scripts to migrate from existing a 
existing NIS/local files
environemnt. I agree that this would not be used normally, but when you're 
migrating from an
existing environment it's a requirement. :)




Rgds,
Siggi







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

Re: [Freeipa-users] Adding user accounts

[Sigbjorn Lie]

Thanks.

I also noticed that a group with the same GID number as the users UID number is 
automatically
created when creating the user account, this is a problem for existing 
environments who's already
used the same ID number for a group.

I see that even after doing a user-mod, changing the GID of the account, the 
private (invisible)
group still exists.

I'm missing an option to choose if I want to create or not create a private 
group for the user.


Rgds,
Siggi






On Sat, March 26, 2011 18:21, Dmitri Pal wrote:
> On 03/25/2011 03:13 PM, Sigbjorn Lie wrote:
>
>> Hi,
>>
>>
>> Using --gidnumber when adding a new user with "ipa user-add" does not
>> seem to have any effect. A gid number with the same value as what I specify 
>> in with the --uid
>> parameter is chosen.
>>
>> I presume this is not the way user-add is intended to work?
>>
>
> We will take a look.
> https://fedorahosted.org/freeipa/ticket/1127
>
>
> Looks like a bug so I filed a ticket.
>
>
>
>>
>>
>> # ipa user-add mysql14 --first=MySQL --last=Server
>> --homedir=/var/lib/mysql --shell=/bin/false --uid=110 --gidnumber=3004
>> 
>> Added user "mysql14"
>> 
>> User login: mysql14
>> First name: MySQL
>> Last name: Server
>> Full name: MySQL Server
>> Display name: MySQL Server
>> Initials: MS
>> Home directory: /var/lib/mysql
>> GECOS field: mysql14
>> Login shell: /bin/false
>> Kerberos principal: mysq...@ix.nixtra.com
>> UID: 110
>> GID: 110
>>
>>
>>
>>
>> Regards,
>> Siggi
>>
>
>
> --
> Thank you,
> Dmitri Pal
>
>
> Sr. Engineering Manager IPA project,
> Red Hat Inc.
>
>
>
> ---
> Looking to carve out IT costs?
> www.redhat.com/carveoutcosts/
>
>
>
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
>
>


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

Re: [Freeipa-users] NIS/local files to IPA migration

[Sigbjorn Lie]

On Mon, March 28, 2011 14:31, Dmitri Pal wrote:
> On 03/27/2011 06:14 PM, Sigbjorn Lie wrote:
>
>> Hi,
>>
>>
>> I have written some scripts for migration from NIS/local files to IPA.
>> They will import the passwd, group, netgroup, and hosts  maps.
>>
>>
>> This is the first version, be aware of bugs. :)
>>
>>
>> Please read the README file before using.
>>
>>
>> You can download them from here if you are interested:
>> http://www.nixtra.com/ipa/NIS-TO-IPA-current.php
>>
>
> Thank you for the contribution!
> I see that it is under GPL v2. Would you mind relicensing it under GPL v3?
> http://www.gnu.org/licenses/gpl-3.0.html
>
>
> Would you be interested in these scripts being incorporated into the
> project source? Rob, can you please take a look into this? Should we consider 
> rewriting
> them in Python and incorporating into the main tool set or leave and use as 
> is?
>
>
>>

Sure I can relicense to GPL v3. All I care about is the scripts staying open 
and free to use. :)

You can include as a part of IPA if you would like. I was planning to re-write 
them all into perl,
as my initial efforts to write them in bash for maximum portability didn't work 
out, and the
netgroup and hosts import scripts ended up written in perl.

I cannot help re-writing to python, I don't know the language.


Rgds,
Siggi


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

[Freeipa-users] Ethers table?

[Sigbjorn Lie]

Hi,

We're using the ethers table in NIS today to generate DHCP config files for 
clients to we can send
different TFTP,DNS,etc options to different clients depening on which type of 
machine they are
(mostly Windows, Linux, etc). At some locations we're also required to only 
serve IP to clients
known by mac address.

I'm missing a ethers table in IPA. Having the MAC address added as an attribute 
to the host
object, and a lookup table for ethers, like hostgroup to netgroup is done would 
be very useful.

Any plans for this?


Rgds,
Siggi


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

Re: [Freeipa-users] NIS/local files to IPA migration

[Sigbjorn Lie]

On Mon, March 28, 2011 15:24, Dmitri Pal wrote:
> On 03/28/2011 09:01 AM, Sigbjorn Lie wrote:
>
>> On Mon, March 28, 2011 14:31, Dmitri Pal wrote:
>>
>>> On 03/27/2011 06:14 PM, Sigbjorn Lie wrote:
>>>
>>>
>>>> Hi,
>>>>
>>>>
>>>>
>>>> I have written some scripts for migration from NIS/local files to IPA.
>>>> They will import the passwd, group, netgroup, and hosts  maps.
>>>>
>>>>
>>>>
>>>> This is the first version, be aware of bugs. :)
>>>>
>>>>
>>>>
>>>> Please read the README file before using.
>>>>
>>>>
>>>>
>>>> You can download them from here if you are interested:
>>>> http://www.nixtra.com/ipa/NIS-TO-IPA-current.php
>>>>
>>>>
>>> Thank you for the contribution!
>>> I see that it is under GPL v2. Would you mind relicensing it under GPL v3?
>>> http://www.gnu.org/licenses/gpl-3.0.html
>>>
>>>
>>>
>>> Would you be interested in these scripts being incorporated into the
>>> project source? Rob, can you please take a look into this? Should we 
>>> consider rewriting them in
>>> Python and incorporating into the main tool set or leave and use as is?
>>>
>>>
>>>
>> Sure I can relicense to GPL v3. All I care about is the scripts staying open 
>> and free to use.
>> :)
>>
>>
>> You can include as a part of IPA if you would like. I was planning to 
>> re-write them all into
>> perl, as my initial efforts to write them in bash for maximum portability 
>> didn't work out, and
>> the netgroup and hosts import scripts ended up written in perl.
>>
>> I cannot help re-writing to python, I don't know the language.
>>
>>
>
> Ok, thank you!
>
>
> Can you elaborate a bit about the constraints you have regarding migration.
> As far as I understand you have users and groups with colliding gids and
> you have to resolve things manually to make things exactly as they were and 
> IPA as is does not
> allow you to do so as it always creates a privite group with the same GID.
>
> I have a stupid question: what is the implication of actually not doing
> things exactly as they were but rather embracing the IPA model of the unified 
> UID/GID namespace? Is
> the reason that there are some applications scattered in the enterprise that 
> might have gids
> configured explicitly in the configuration files (like SUDO for example) and 
> updating those would
> be a challenge or there is something else?
>

That question is not stupid. However...:)

Migrating group id's is possible, but quite a job. We just moved a few users's 
uid's as they had
been in the enterprise for very many years, and had a dangerously low UID's. 
Searching trough the
file servers for files belonging to these few users using a "find -exec chown 
..."  took 3 days.
Migrating GID's would also take a very long time.

Secondly, any files restored from backup would have the wrong uid/gid. Several 
of our clients have
a rentention time of 10 years for backups. That's quite some time to keep a 
mapping table over
new/old uids/gids.

Third, we would need to map our applications to see if any of them store or use 
the GID.

As you can see, migrating to IPA just became a much more time consuming and 
higher risk project
than it could be.

Is there a reason for why the approach with a private group per user is 
forcibly chosen?



Rgds,
Siggi






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

Re: [Freeipa-users] Adding user accounts

[Sigbjorn Lie]

Fantastic! Thanks. I will update my scripts.

Is there any downside to doing this?



Rgds,
Siggi




On Mon, March 28, 2011 16:02, Rob Crittenden wrote:
> Sigbjorn Lie wrote:
>
>> Thanks.
>>
>>
>> I also noticed that a group with the same GID number as the users UID number 
>> is automatically
>> created when creating the user account, this is a problem for existing 
>> environments who's
>> already used the same ID number for a group.
>>
>> I see that even after doing a user-mod, changing the GID of the account, the 
>> private
>> (invisible)
>> group still exists.
>>
>> I'm missing an option to choose if I want to create or not create a private 
>> group for the user.
>>
>
> There currently isn't an option for that. You can delete a managed group
> this way:
>
> $ ipa user-add --first=Tim --last=Test ttest
>
>
> You now have a group ttest too, lets delete it.
>
>
> $ ipa group-detach ttest
> $ ipa group-del ttest
>
>
> The first command detaches it from the user (this is not reversible) and
> the second removes it altogether.
>
> rob
>
>>
>>
>> Rgds,
>> Siggi
>>
>>
>>
>>
>>
>>
>>
>> On Sat, March 26, 2011 18:21, Dmitri Pal wrote:
>>
>>> On 03/25/2011 03:13 PM, Sigbjorn Lie wrote:
>>>
>>>
>>>> Hi,
>>>>
>>>>
>>>>
>>>> Using --gidnumber when adding a new user with "ipa user-add" does not
>>>> seem to have any effect. A gid number with the same value as what I 
>>>> specify in with the
>>>> --uid
>>>> parameter is chosen.
>>>>
>>>> I presume this is not the way user-add is intended to work?
>>>>
>>>>
>>>
>>> We will take a look.
>>> https://fedorahosted.org/freeipa/ticket/1127
>>>
>>>
>>>
>>> Looks like a bug so I filed a ticket.
>>>
>>>
>>>
>>>
>>>>
>>>>
>>>> # ipa user-add mysql14 --first=MySQL --last=Server
>>>> --homedir=/var/lib/mysql --shell=/bin/false --uid=110 --gidnumber=3004
>>>> 
>>>> Added user "mysql14"
>>>> 
>>>> User login: mysql14
>>>> First name: MySQL
>>>> Last name: Server
>>>> Full name: MySQL Server
>>>> Display name: MySQL Server
>>>> Initials: MS
>>>> Home directory: /var/lib/mysql
>>>> GECOS field: mysql14
>>>> Login shell: /bin/false
>>>> Kerberos principal: mysq...@ix.nixtra.com
>>>> UID: 110
>>>> GID: 110
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Regards,
>>>> Siggi
>>>>
>>>>
>>>
>>>
>>> --
>>> Thank you,
>>> Dmitri Pal
>>>
>>>
>>>
>>> Sr. Engineering Manager IPA project,
>>> Red Hat Inc.
>>>
>>>
>>>
>>>
>>> ---
>>> Looking to carve out IT costs?
>>> www.redhat.com/carveoutcosts/
>>>
>>>
>>>
>>> ___
>>> Freeipa-users mailing list
>>> Freeipa-users@redhat.com
>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>>
>>>
>>>
>>
>>
>> ___
>> Freeipa-users mailing list
>> Freeipa-users@redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>
>
>


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

Re: [Freeipa-users] Ethers table?

[Sigbjorn Lie]

Done, thanks.


Rgds,
Siggi


On Mon, March 28, 2011 15:49, Dmitri Pal wrote:
> On 03/28/2011 09:26 AM, Sigbjorn Lie wrote:
>
>> Hi,
>>
>>
>> We're using the ethers table in NIS today to generate DHCP config files for 
>> clients to we can
>> send different TFTP,DNS,etc options to different clients depening on which 
>> type of machine they
>> are (mostly Windows, Linux, etc). At some locations we're also required to 
>> only serve IP to
>> clients known by mac address.
>>
>> I'm missing a ethers table in IPA. Having the MAC address added as an 
>> attribute to the host
>> object, and a lookup table for ethers, like hostgroup to netgroup is done 
>> would be very useful.
>>
>> Any plans for this?
>>
>>
>
>
> Please file a ticket with the request and describe the requirement in as
> many details as you can. https://fedorahosted.org/freeipa
>
>
>> Rgds,
>> Siggi
>>
>>
>>
>> ___
>> Freeipa-users mailing list
>> Freeipa-users@redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>
>
>
> --
> Thank you,
> Dmitri Pal
>
>
> Sr. Engineering Manager IPA project,
> Red Hat Inc.
>
>
>
> ---
> Looking to carve out IT costs?
> www.redhat.com/carveoutcosts/
>
>
>
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
>
>


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

Re: [Freeipa-users] Adding user accounts

[Sigbjorn Lie]

I have updated the NIS-TO-IPA scripts with the suggestions for private 
group workarounds from Rob, and the license updated to GPL v3 as 
suggested by Dmitri.


Download link is still the same: 
http://www.nixtra.com/ipa/NIS-TO-IPA-current.php


A -noprivategroup option is very much welcome. Shall I open a request in 
bugzilla?



Rgds,
Siggi


On 03/28/2011 04:56 PM, Dmitri Pal wrote:

On 03/28/2011 10:50 AM, Rob Crittenden wrote:

Sigbjorn Lie wrote:

Fantastic! Thanks. I will update my scripts.

Is there any downside to doing this?

One thing I should warn you of though that we've run into from time to
time. Some of our LDAP operations are done as post-operations, that is
they execute after the data has been returned to the client. Managed
Entries (private groups) is one of these. I can definitely see the
case where you try to detach a managed group that hasn't quite
finished being created yet. I'd probably put a 1 or 2 second sleep
after the user creation to be sure, even if it does slow things
considerably.

We're working with the 389-ds devs on this. There is the tradeoff of
speed vs correctness (users don't like watching a blinking prompt).
Some of these post-ops could take a while.

I think we should seriously consider a -noprivategroup option



rob




Rgds,
Siggi




On Mon, March 28, 2011 16:02, Rob Crittenden wrote:

Sigbjorn Lie wrote:


Thanks.


I also noticed that a group with the same GID number as the users
UID number is automatically
created when creating the user account, this is a problem for
existing environments who's
already used the same ID number for a group.

I see that even after doing a user-mod, changing the GID of the
account, the private
(invisible)
group still exists.

I'm missing an option to choose if I want to create or not create a
private group for the user.


There currently isn't an option for that. You can delete a managed
group
this way:

$ ipa user-add --first=Tim --last=Test ttest


You now have a group ttest too, lets delete it.


$ ipa group-detach ttest
$ ipa group-del ttest


The first command detaches it from the user (this is not reversible)
and
the second removes it altogether.

rob



Rgds,
Siggi







On Sat, March 26, 2011 18:21, Dmitri Pal wrote:


On 03/25/2011 03:13 PM, Sigbjorn Lie wrote:



Hi,



Using --gidnumber when adding a new user with "ipa user-add" does
not
seem to have any effect. A gid number with the same value as what
I specify in with the
--uid
parameter is chosen.

I presume this is not the way user-add is intended to work?



We will take a look.
https://fedorahosted.org/freeipa/ticket/1127



Looks like a bug so I filed a ticket.






# ipa user-add mysql14 --first=MySQL --last=Server
--homedir=/var/lib/mysql --shell=/bin/false --uid=110
--gidnumber=3004

Added user "mysql14"

User login: mysql14
First name: MySQL
Last name: Server
Full name: MySQL Server
Display name: MySQL Server
Initials: MS
Home directory: /var/lib/mysql
GECOS field: mysql14
Login shell: /bin/false
Kerberos principal: mysq...@ix.nixtra.com
UID: 110
GID: 110





Regards,
Siggi




--
Thank you,
Dmitri Pal



Sr. Engineering Manager IPA project,
Red Hat Inc.




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



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





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






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






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

Re: [Freeipa-users] IPA Client join

[Sigbjorn Lie]

>
> In rc2 we had to make a change to the OID used for some operations
> because they were duplicated. The OID for the ipa-getkeytab operation was one 
> of them, so older
> clients don't work with newer servers. IIRC the EL6 ipa-client was based on 
> the alpha 3 release.
>
> I attached a patch that gives the general idea of what needs to change.
> It was originally for the EL 5 branch but it may work with few changes
> in EL6.
>

Will there be an update to the ipa-client package in RHEL 6.0, or do we have to 
wait for RHEL 6.1?


Rgds,
Siggi


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

Re: [Freeipa-users] 6.1 beta

[Sigbjorn Lie]

According to Red Hat Network it does:

ipa-server-2.0.0-16.el6.x86_64 
 
	Red Hat Enterprise Linux Server Beta (v. 6 for 64-bit x86_64)
ipa-server-2.0.0-16.el6.i686 
 
	Red Hat Enterprise Linux Server Beta (v. 6 for 32-bit x86)



Thanks for pointing this out, I'm installing RHEL 6.1 beta now. :)



Rgds,
Siggi



On 04/03/2011 11:29 PM, Steven Jones wrote:

Hi,

This has IPA 2.0 rcX server and client  in it?

regards

Steven

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


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

Re: [Freeipa-users] NIS/local files to IPA migration

[Sigbjorn Lie]

On Mon, April 4, 2011 04:58, Simo Sorce wrote:
> On Mon, 28 Mar 2011 15:43:18 +0200 (CEST)
> "Sigbjorn Lie"  wrote:
>
>
>> On Mon, March 28, 2011 15:24, Dmitri Pal wrote:
>>
>>> On 03/28/2011 09:01 AM, Sigbjorn Lie wrote:
>>>
>>>
>>>> On Mon, March 28, 2011 14:31, Dmitri Pal wrote:
>>>>
>>>>
>>>>> On 03/27/2011 06:14 PM, Sigbjorn Lie wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I have written some scripts for migration from NIS/local files
>>>>>> to IPA. They will import the passwd, group, netgroup, and hosts maps.
>>>>>>
>>>>>>
>>>>>>
>>>>>> This is the first version, be aware of bugs. :)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Please read the README file before using.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> You can download them from here if you are interested:
>>>>>> http://www.nixtra.com/ipa/NIS-TO-IPA-current.php
>>>>>>
>>>>>>
>>>>>>
>>>>> Thank you for the contribution!
>>>>> I see that it is under GPL v2. Would you mind relicensing it
>>>>> under GPL v3? http://www.gnu.org/licenses/gpl-3.0.html
>>>>>
>>>>>
>>>>>
>>>>> Would you be interested in these scripts being incorporated into
>>>>> the project source? Rob, can you please take a look into this? Should we 
>>>>> consider rewriting
>>>>> them in Python and incorporating into the main tool set or leave and use 
>>>>> as is?
>>>>>
>>>>>
>>>>>
>>>> Sure I can relicense to GPL v3. All I care about is the scripts
>>>> staying open and free to use. :)
>>>>
>>>>
>>>> You can include as a part of IPA if you would like. I was planning
>>>> to re-write them all into perl, as my initial efforts to write them in 
>>>> bash for maximum
>>>> portability didn't work out, and the netgroup and hosts import scripts 
>>>> ended up written in
>>>> perl.
>>>>
>>>> I cannot help re-writing to python, I don't know the language.
>>>>
>>>>
>>>>
>>>
>>> Ok, thank you!
>>>
>>>
>>>
>>> Can you elaborate a bit about the constraints you have regarding
>>> migration. As far as I understand you have users and groups with colliding 
>>> gids and you have to
>>> resolve things manually to make things exactly as they were and IPA as is 
>>> does not allow you
>>> to do so as it always creates a privite group with the same GID.
>>>
>>> I have a stupid question: what is the implication of actually not
>>> doing things exactly as they were but rather embracing the IPA model of the 
>>> unified UID/GID
>>> namespace? Is the reason that there are some applications scattered in the 
>>> enterprise that
>>> might have gids configured explicitly in the configuration files (like SUDO 
>>> for example) and
>>> updating those would be a challenge or there is something else?
>>>
>>
>> That question is not stupid. However...:)
>>
>>
>> Migrating group id's is possible, but quite a job. We just moved a
>> few users's uid's as they had been in the enterprise for very many years, 
>> and had a dangerously
>> low UID's. Searching trough the file servers for files belonging to these 
>> few users using a
>> "find -exec
>> chown ..."  took 3 days. Migrating GID's would also take a very long time.
>>
>> Secondly, any files restored from backup would have the wrong
>> uid/gid. Several of our clients have a rentention time of 10 years for 
>> backups. That's quite some
>> time to keep a mapping table over new/old uids/gids.
>>
>> Third, we would need to map our applications to see if any of them
>> store or use the GID.
>>
>> As you can see, migrating to IPA just became a much more time
>> consuming and higher risk project than it could be.
>>
>> Is there a reason for why the approach with a private group per user
>> is forcibly chosen?
>
> As a default it gives us the maximum compatibility with other directory
> services (like AD). Plus when we did freeipa v1 we got a lot of push back 
> when we choose a single
> group (ipausers) to be the primary group due to traditional umask use for 
> users.
>
> So we decided to make it a default and let admins that really do not
> want it to remove the groups. I guess we could add a switch somewhere to turn 
> off UPG groups
> creation completely, if you think that is something really important you may 
> want to open an RFE,
> although I am not sure when we will have cycles to get to implement such a 
> switch for the moment.
>

I see your point from a security point of view. So for new installations I 
agree this would be the
way to go.

Why can't I see the user private group listed as a group? Also I'm allowed to 
create a new public
group with the same GID as the user's private group without a warning. I should 
be getting a
warning and a force option?


Rgds,
Siggi





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

Re: [Freeipa-users] 6.1 beta

[Sigbjorn Lie]

On 04/04/2011 03:43 PM, Dmitri Pal wrote:

On 04/03/2011 05:41 PM, Sigbjorn Lie wrote:

According to Red Hat Network it does:

ipa-server-2.0.0-16.el6.x86_64 
<https://rhn.redhat.com/rhn/software/packages/details/Overview.do?pid=619857> 
Red Hat Enterprise Linux Server Beta (v. 6 for 64-bit x86_64)
ipa-server-2.0.0-16.el6.i686 
<https://rhn.redhat.com/rhn/software/packages/details/Overview.do?pid=617431> 
Red Hat Enterprise Linux Server Beta (v. 6 for 32-bit x86)



Thanks for pointing this out, I'm installing RHEL 6.1 beta now. :)



It is not the final bits though. There have done several bug fixes 
since then that will show up in the final 6.1 release.


Ok, thanks. I'll keep that in mind.
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] 6.1 beta

[Sigbjorn Lie]

On 04/04/2011 06:22 PM, Sigbjorn Lie wrote:

On 04/04/2011 03:43 PM, Dmitri Pal wrote:

On 04/03/2011 05:41 PM, Sigbjorn Lie wrote:

According to Red Hat Network it does:

ipa-server-2.0.0-16.el6.x86_64 
<https://rhn.redhat.com/rhn/software/packages/details/Overview.do?pid=619857> 
Red Hat Enterprise Linux Server Beta (v. 6 for 64-bit x86_64)
ipa-server-2.0.0-16.el6.i686 
<https://rhn.redhat.com/rhn/software/packages/details/Overview.do?pid=617431> 
Red Hat Enterprise Linux Server Beta (v. 6 for 32-bit x86)



Thanks for pointing this out, I'm installing RHEL 6.1 beta now. :)



It is not the final bits though. There have done several bug fixes 
since then that will show up in the final 6.1 release.


Ok, thanks. I'll keep that in mind.



I think I might have a found a few bugs  in the RHEL 6.1 beta release. 
Please correct me if you're already aware of these.



Unless FQDN of the host is returned when running `hostname`, the IPA 
services will fail to start as they return "No such object" when 
querying the IPA LDAP for services. Shouldn't this be changed to use 
`hostname -f` ?



ipa-replica-prepare fails with the error message below. I cannot find 
the plugin mentioned as a seperate RPM.

# ipa-replica-prepare
The 389-ds replication plug-in was not found on this system


Rgds,
Siggi

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

Re: [Freeipa-users] 6.1 beta

[Sigbjorn Lie]

On 04/04/2011 08:32 PM, Rob Crittenden wrote:

Sigbjorn Lie wrote:

  On 04/04/2011 06:22 PM, Sigbjorn Lie wrote:

On 04/04/2011 03:43 PM, Dmitri Pal wrote:

On 04/03/2011 05:41 PM, Sigbjorn Lie wrote:

According to Red Hat Network it does:

ipa-server-2.0.0-16.el6.x86_64
<https://rhn.redhat.com/rhn/software/packages/details/Overview.do?pid=619857> 


Red Hat Enterprise Linux Server Beta (v. 6 for 64-bit x86_64)
ipa-server-2.0.0-16.el6.i686
<https://rhn.redhat.com/rhn/software/packages/details/Overview.do?pid=617431> 


Red Hat Enterprise Linux Server Beta (v. 6 for 32-bit x86)


Thanks for pointing this out, I'm installing RHEL 6.1 beta now. :)



It is not the final bits though. There have done several bug fixes
since then that will show up in the final 6.1 release.


Ok, thanks. I'll keep that in mind.



I think I might have a found a few bugs in the RHEL 6.1 beta release.
Please correct me if you're already aware of these.


Unless FQDN of the host is returned when running `hostname`, the IPA
services will fail to start as they return "No such object" when
querying the IPA LDAP for services. Shouldn't this be changed to use
`hostname -f` ?


AFAIK we don't call `hostname` in our script, it may be that another 
part of init does. We have a ticket open on this, #1035.





ipa-replica-prepare fails with the error message below. I cannot find
the plugin mentioned as a seperate RPM.
# ipa-replica-prepare
The 389-ds replication plug-in was not found on this system


The package is named ds-replication. I'll open a ticket to make this 
more explicit.


thanks

rob


I could not find any ds-replication package in RHN.

I also noticed that in /etc/sssd/sssd.conf the ipa server is specified with:
ipa_server = _srv_, ipa01.ix.test.com

sssd doesn't resolve anything from IPA until I remove "_srv_,"


Rgds
Siggi



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

Re: [Freeipa-users] NIS/local files to IPA migration

[Sigbjorn Lie]

On 04/04/2011 09:00 PM, Dmitri Pal wrote:

On 04/04/2011 10:34 AM, Sigbjorn Lie wrote:

On Mon, April 4, 2011 04:58, Simo Sorce wrote:

On Mon, 28 Mar 2011 15:43:18 +0200 (CEST)
"Sigbjorn Lie"  wrote:



On Mon, March 28, 2011 15:24, Dmitri Pal wrote:


On 03/28/2011 09:01 AM, Sigbjorn Lie wrote:



On Mon, March 28, 2011 14:31, Dmitri Pal wrote:



On 03/27/2011 06:14 PM, Sigbjorn Lie wrote:




Hi,




I have written some scripts for migration from NIS/local files
to IPA. They will import the passwd, group, netgroup, and hosts maps.



This is the first version, be aware of bugs. :)




Please read the README file before using.




You can download them from here if you are interested:
http://www.nixtra.com/ipa/NIS-TO-IPA-current.php




Thank you for the contribution!
I see that it is under GPL v2. Would you mind relicensing it
under GPL v3? http://www.gnu.org/licenses/gpl-3.0.html



Would you be interested in these scripts being incorporated into
the project source? Rob, can you please take a look into this? Should we 
consider rewriting
them in Python and incorporating into the main tool set or leave and use as is?




Sure I can relicense to GPL v3. All I care about is the scripts
staying open and free to use. :)


You can include as a part of IPA if you would like. I was planning
to re-write them all into perl, as my initial efforts to write them in bash for 
maximum
portability didn't work out, and the netgroup and hosts import scripts ended up 
written in
perl.

I cannot help re-writing to python, I don't know the language.




Ok, thank you!



Can you elaborate a bit about the constraints you have regarding
migration. As far as I understand you have users and groups with colliding gids 
and you have to
resolve things manually to make things exactly as they were and IPA as is does 
not allow you
to do so as it always creates a privite group with the same GID.

I have a stupid question: what is the implication of actually not
doing things exactly as they were but rather embracing the IPA model of the 
unified UID/GID
namespace? Is the reason that there are some applications scattered in the 
enterprise that
might have gids configured explicitly in the configuration files (like SUDO for 
example) and
updating those would be a challenge or there is something else?


That question is not stupid. However...:)


Migrating group id's is possible, but quite a job. We just moved a
few users's uid's as they had been in the enterprise for very many years, and 
had a dangerously
low UID's. Searching trough the file servers for files belonging to these few 
users using a
"find -exec
chown ..."  took 3 days. Migrating GID's would also take a very long time.

Secondly, any files restored from backup would have the wrong
uid/gid. Several of our clients have a rentention time of 10 years for backups. 
That's quite some
time to keep a mapping table over new/old uids/gids.

Third, we would need to map our applications to see if any of them
store or use the GID.

As you can see, migrating to IPA just became a much more time
consuming and higher risk project than it could be.

Is there a reason for why the approach with a private group per user
is forcibly chosen?

As a default it gives us the maximum compatibility with other directory
services (like AD). Plus when we did freeipa v1 we got a lot of push back when 
we choose a single
group (ipausers) to be the primary group due to traditional umask use for users.

So we decided to make it a default and let admins that really do not
want it to remove the groups. I guess we could add a switch somewhere to turn 
off UPG groups
creation completely, if you think that is something really important you may 
want to open an RFE,
although I am not sure when we will have cycles to get to implement such a 
switch for the moment.


I see your point from a security point of view. So for new installations I 
agree this would be the
way to go.

Why can't I see the user private group listed as a group?

Because it is implied. They are filtered out unless you explicitly want
to see them.
We thought that by default we do not want to spam your group lists with
those groups.



Also I'm allowed to create a new public
group with the same GID as the user's private group without a warning. I should 
be getting a
warning and a force option?


Yes, if this is not the case it is a bug. Please log one then.




Done. :)

https://bugzilla.redhat.com/show_bug.cgi?id=693483


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

Re: [Freeipa-users] 6.1 beta

[Sigbjorn Lie]

On 04/04/2011 09:36 PM, Stephen Gallagher wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/04/2011 03:06 PM, Dmitri Pal wrote:

On 04/04/2011 03:01 PM, Sigbjorn Lie wrote:

I also noticed that in /etc/sssd/sssd.conf the ipa server is specified
with:
ipa_server = _srv_, ipa01.ix.test.com

sssd doesn't resolve anything from IPA until I remove "_srv_,"


Stephen, was there a recent bug on this matter in SSSD?


The purpose of _srv_ is to check DNS for IPA server addresses first. The
idea is that if you have more than one IPA server in service, then you
can use DNS to list all of them. Otherwise, the ipa-client-install can
only specify a static list of servers at the time of install. This would
mean that if the IPA servers changed IP addresses or new ones entered
production, it would be necessary to change all of the client
configuration files.

I'm puzzled why you would need to remove this, unless your DNS server is
returning something other than FreeIPA servers for a SRV request
directed at _ldap.tcp

I have verfied that the _ldap._tcp is resolving correctly. DNS was set 
up using "ipa-server-install --setup-dns". I discovered this at the IPA 
server. This is a newly installed IPA server at RH 6.1 beta installed a 
few hours ago. No IP addresses changed.



#  host -t srv _ldap._tcp
_ldap._tcp.ix.test.com has SRV record 0 100 389 ipa01.ix.test.com.


Rgds,
Siggi

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

Re: [Freeipa-users] 6.1 beta

[Sigbjorn Lie]

On 04/04/2011 10:12 PM, Stephen Gallagher wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/04/2011 03:52 PM, Sigbjorn Lie wrote:

On 04/04/2011 09:36 PM, Stephen Gallagher wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/04/2011 03:06 PM, Dmitri Pal wrote:

On 04/04/2011 03:01 PM, Sigbjorn Lie wrote:

I also noticed that in /etc/sssd/sssd.conf the ipa server is specified
with:
ipa_server = _srv_, ipa01.ix.test.com

sssd doesn't resolve anything from IPA until I remove "_srv_,"


Stephen, was there a recent bug on this matter in SSSD?


The purpose of _srv_ is to check DNS for IPA server addresses first. The
idea is that if you have more than one IPA server in service, then you
can use DNS to list all of them. Otherwise, the ipa-client-install can
only specify a static list of servers at the time of install. This would
mean that if the IPA servers changed IP addresses or new ones entered
production, it would be necessary to change all of the client
configuration files.

I'm puzzled why you would need to remove this, unless your DNS server is
returning something other than FreeIPA servers for a SRV request
directed at _ldap.tcp


I have verfied that the _ldap._tcp is resolving correctly. DNS was set
up using "ipa-server-install --setup-dns". I discovered this at the IPA
server. This is a newly installed IPA server at RH 6.1 beta installed a
few hours ago. No IP addresses changed.


#  host -t srv _ldap._tcp
_ldap._tcp.ix.test.com has SRV record 0 100 389 ipa01.ix.test.com.


Is the domain part of the client machine also ix.test.com?

The way we determine which SRV record to use is as follows:
1) If dns_discovery_domain exists in the config file, it is always used.
2) If not, first try the domain part of the machine's hostname (aka
hostname -d)
3) If that fails, try the name of the SSSD domain (in sssd.conf
[domain/]

IIRC ipa-client-install should set [domain/] so if
that's not the same as your DNS domain, we could be having problems.

Can we see your sssd.conf please? (feel free to sanitize as needed)

Please see the requested output below. This is taken from the IPA 
server, which had the issue. DNS servers in resolv.conf set to the IP of 
the IPA server.



# hostname -d
ix.test.com

# more sssd.conf
[sssd]
services = nss, pam
config_file_version = 2

domains = ix.test.com
[nss]

[pam]

[domain/ix.test.com]
cache_credentials = True
ipa_domain = ix.test.com
id_provider = ipa
auth_provider = ipa
access_provider = ipa
chpass_provider = ipa
#ipa_server = _srv_, ipa01.ix.test.com
ipa_server = ipa01.ix.test.com

[domain/default]
cache_credentials = True
krb5_realm = IX.TEST.COM
krb5_kdcip = ipa01.ix.test.com:88
auth_provider = krb5
chpass_provider = krb5
krb5_kpasswd = ipa01.ix.test.com:749

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

Re: [Freeipa-users] 6.1 beta

[Sigbjorn Lie]

On 04/05/2011 01:25 AM, Kevin Unthank wrote:



On 04/04/2011 12:06 PM, Dmitri Pal wrote:

On 04/04/2011 03:01 PM, Sigbjorn Lie wrote:

On 04/04/2011 08:32 PM, Rob Crittenden wrote:

Sigbjorn Lie wrote:

   On 04/04/2011 06:22 PM, Sigbjorn Lie wrote:

On 04/04/2011 03:43 PM, Dmitri Pal wrote:

On 04/03/2011 05:41 PM, Sigbjorn Lie wrote:

According to Red Hat Network it does:

ipa-server-2.0.0-16.el6.x86_64
<https://rhn.redhat.com/rhn/software/packages/details/Overview.do?pid=619857> 



Red Hat Enterprise Linux Server Beta (v. 6 for 64-bit x86_64)
ipa-server-2.0.0-16.el6.i686
<https://rhn.redhat.com/rhn/software/packages/details/Overview.do?pid=617431> 



Red Hat Enterprise Linux Server Beta (v. 6 for 32-bit x86)


Thanks for pointing this out, I'm installing RHEL 6.1 beta now. :)



It is not the final bits though. There have done several bug fixes
since then that will show up in the final 6.1 release.


Ok, thanks. I'll keep that in mind.



I think I might have a found a few bugs in the RHEL 6.1 beta release.
Please correct me if you're already aware of these.


Unless FQDN of the host is returned when running `hostname`, the IPA
services will fail to start as they return "No such object" when
querying the IPA LDAP for services. Shouldn't this be changed to use
`hostname -f` ?


AFAIK we don't call `hostname` in our script, it may be that another
part of init does. We have a ticket open on this, #1035.




ipa-replica-prepare fails with the error message below. I cannot find
the plugin mentioned as a seperate RPM.
# ipa-replica-prepare
The 389-ds replication plug-in was not found on this system


The package is named ds-replication. I'll open a ticket to make this
more explicit.

thanks

rob


I could not find any ds-replication package in RHN.


We are working on making it available.


Just to elaborate on Dmitri's comments. In addition to the IPA client
and server packages that are included in the RHEL6.1 beta channel, there
will be a separate RHEL add-on channel, Enterprise Identity Replication.
That add-on channel will contain ds-replication and the Windows sync
packages.

If you wish to use IPA during the beta or when it is a tech preview
feature of RHEL 6.1 you should request an eval entitlement to the
Enterprise Identity Replication channel from your Red Hat account
rep.

Cheers,
Kev

I will request the channel to be added to our account.

Thanks.

Rgds,
Siggi

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

Re: [Freeipa-users] 6.1 beta

[Sigbjorn Lie]

On 04/05/2011 01:25 AM, Kevin Unthank wrote:



On 04/04/2011 12:06 PM, Dmitri Pal wrote:

On 04/04/2011 03:01 PM, Sigbjorn Lie wrote:

On 04/04/2011 08:32 PM, Rob Crittenden wrote:

Sigbjorn Lie wrote:

   On 04/04/2011 06:22 PM, Sigbjorn Lie wrote:

On 04/04/2011 03:43 PM, Dmitri Pal wrote:

On 04/03/2011 05:41 PM, Sigbjorn Lie wrote:

According to Red Hat Network it does:

ipa-server-2.0.0-16.el6.x86_64
<https://rhn.redhat.com/rhn/software/packages/details/Overview.do?pid=619857> 



Red Hat Enterprise Linux Server Beta (v. 6 for 64-bit x86_64)
ipa-server-2.0.0-16.el6.i686
<https://rhn.redhat.com/rhn/software/packages/details/Overview.do?pid=617431> 



Red Hat Enterprise Linux Server Beta (v. 6 for 32-bit x86)


Thanks for pointing this out, I'm installing RHEL 6.1 beta now. :)



It is not the final bits though. There have done several bug fixes
since then that will show up in the final 6.1 release.


Ok, thanks. I'll keep that in mind.



I think I might have a found a few bugs in the RHEL 6.1 beta release.
Please correct me if you're already aware of these.


Unless FQDN of the host is returned when running `hostname`, the IPA
services will fail to start as they return "No such object" when
querying the IPA LDAP for services. Shouldn't this be changed to use
`hostname -f` ?


AFAIK we don't call `hostname` in our script, it may be that another
part of init does. We have a ticket open on this, #1035.




ipa-replica-prepare fails with the error message below. I cannot find
the plugin mentioned as a seperate RPM.
# ipa-replica-prepare
The 389-ds replication plug-in was not found on this system


The package is named ds-replication. I'll open a ticket to make this
more explicit.

thanks

rob


I could not find any ds-replication package in RHN.


We are working on making it available.


Just to elaborate on Dmitri's comments. In addition to the IPA client
and server packages that are included in the RHEL6.1 beta channel, there
will be a separate RHEL add-on channel, Enterprise Identity Replication.
That add-on channel will contain ds-replication and the Windows sync
packages.

If you wish to use IPA during the beta or when it is a tech preview
feature of RHEL 6.1 you should request an eval entitlement to the
Enterprise Identity Replication channel from your Red Hat account
rep.

Cheers,
Kev

Hi Kevin,

I have requested the replication channel as you recommended from our 
account manager.


I am curious to why such an important feature as replication is put in 
it's own channel. I see IPA is trying to compete with Active Directory 
to service Unix/Linux machines, however with Active Directory all 
features is included in the base package of the operating system.


Why does Red Hat put the replication feature of IPA into a seperate 
channel from the operating system?



Rgds,
Siggi




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

Re: [Freeipa-users] 6.1 beta

[Sigbjorn Lie]

>
>
>
>> Just to elaborate on Dmitri's comments. In addition to the IPA client
>> and server packages that are included in the RHEL6.1 beta channel, there 
>> will be a separate RHEL
>> add-on channel, Enterprise Identity Replication. That add-on channel will 
>> contain ds-replication
>> and the Windows sync packages.
>>
>> If you wish to use IPA during the beta or when it is a tech preview
>> feature of RHEL 6.1 you should request an eval entitlement to the Enterprise 
>> Identity Replication
>> channel from your Red Hat account rep.
>>
>> Cheers,
>> Kev
>>
> Hi Kevin,
>
>
> I have requested the replication channel as you recommended from our
> account manager.
>
> I am curious to why such an important feature as replication is put in
> it's own channel. I see IPA is trying to compete with Active Directory to 
> service Unix/Linux
> machines, however with Active Directory all features is included in the base 
> package of the
> operating system.
>
> Why does Red Hat put the replication feature of IPA into a seperate
> channel from the operating system?
>
>
> Rgds,
> Siggi
>
>
> ==
>
>
> Silly question.they want to make money and lock out the "easy" 
> possibility of you not paying
> them.
>
> There is a very good reason RedHat is nick named the Microsoft of the Linux 
> world..but they
> are all pretty much the same.
>
> You have to go into this with open eyes..this project isnt a real open 
> source project with
> real open source ppl from all walks of life.its a Red Hat projectthat 
> they let you see
> into on their terms, Sun and oracle for instance have done the same 
> thing.their projects
> splutter along with little OSS community support.
>
> Example, so if you went to say mailman (like I do) that's a real open source 
> product and I can
> get first class support via thatI would think that this will never be a 
> place for open source
> support for IPA it will be "please go to red hat and pay if you want help".
>
> I dont know Ive even seen a single contributor who doesnt have a @redhat.com 
> address, that set
> off warning lights for me..probably why the FDS project still has so many 
> contributors and
> users
>
> I hadnt noticed this wrinkle as I'm busy building a total virtual copy of 
> prod to run a huge
> proof of concept / pre-prod setup which will take me another week at 
> leastgiven we dont have
> much money and its going to take me more than 6months to do, paying $ isnt 
> practical/possible and
> we dont know the cost when 6.2 comes out.  So I suspect that if you dont want 
> or cant afford a
> support contract bailing to CENTOS 6.1 or using CENTOS rpms to finish the 
> glue (on RHEL) will be
> the way to go. Given we will be using shibboleth and everyone around us with 
> shibboleth is on
> CENTOS its probably where we will go.
>
>
> Its not all bad, bear in mind of course an Identity / LDAP product off anyone 
> else eg Oracle will
> cost you mega bucks to buy (think numbers ending in 5 0's), is bloody awful 
> (2 of us spent 6
> weeks trying to make its virtual front end LDAP server even start let alone 
> do anything of use
> and I failed).and costly to look after (think 1 FTE and a highly paid one 
> to boot).I
> really wonder if the business case stacks up at all
>
> regards
>


Hello Steven,

I do not agree with you. You can download the source for IPA at any time for 
using, forking or
creating and supporting your own distribution, that to me is an open source 
project. Doesn't
matter how many of the contributers have or does not have a @redhat address.


Rgds,
Siggi





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

Re: [Freeipa-users] 6.1 beta

[Sigbjorn Lie]

mvh,
Sigbjorn Lie

's/windows/unix/g'
- "Ubuntu" - an African word, meaning "Slackware is too hard for me"


On Fri, April 8, 2011 01:03, Kevin Unthank wrote:
> 
>
>>> Just to elaborate on Dmitri's comments. In addition to the IPA client
>>> and server packages that are included in the RHEL6.1 beta channel, there 
>>> will be a separate
>>> RHEL add-on channel, Enterprise Identity Replication.
>>> That add-on channel will contain ds-replication and the Windows sync
>>> packages.
>>>
>>> If you wish to use IPA during the beta or when it is a tech preview
>>> feature of RHEL 6.1 you should request an eval entitlement to the 
>>> Enterprise Identity
>>> Replication channel from your Red Hat account
>>> rep.
>>>
>>> Cheers,
>>> Kev
>>>
>> Hi Kevin,
>>
>>
>> I have requested the replication channel as you recommended from our account 
>> manager.
>>
>>
>> I am curious to why such an important feature as replication is put in it's 
>> own channel. I see
>> IPA is trying to compete with Active Directory to service Unix/Linux 
>> machines, however with
>> Active Directory all features is included in the base package of the 
>> operating system.
>>
>>
>> Why does Red Hat put the replication feature of IPA into a seperate channel 
>> from the operating
>> system?
>>
>>
>> Rgds,
>> Siggi
>>
>
> Hi Siggi,
>
>
> With RHEL6 we are striving to have more flexibility with packaging and
> features. From the website: http://www.redhat.com/rhel/add-ons/
>
> "Add-Ons to Red Hat Enterprise Linux allow you to tailor your application
> environment with workload extensions to suit your particular computing 
> requirements."
>
> For RHEL6.2 we are planning to have an Enterprise Identity Replication
> add-on. Until then, free evaluations will be available for customers who wish 
> to play with IPA
> while it is a technology preview.
>

Hi Kevin,

Please disregards Steven Jones' ranting, this was not the kind of feedback I 
was looking for.

Ok, I do like the wider options for channels in Red Hat, but this bring me to 
my next question:
Will there be an extra charge for this add on channel, or will this be included 
in the base
subscription?

If $answer = yes { Why does Red Hat think they can charge more for a feature 
that is included in
it's competitors base license for the equivalent product? }

Else if $answer = no { Great! :) }



Rgds,
Siggi










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

Re: [Freeipa-users] 6.1 beta

[Sigbjorn Lie]

Right, forgot to remove autosignature. :)

See my post at the bottom of my last email.


Rgds,
Siggi


On Fri, April 8, 2011 08:38, Sigbjorn Lie wrote:
>

> mvh, Sigbjorn Lie
>
>
> 's/windows/unix/g'
> - "Ubuntu" - an African word, meaning "Slackware is too hard for me"
>
>
>
> On Fri, April 8, 2011 01:03, Kevin Unthank wrote:
>
>> 
>>
>>
>>>> Just to elaborate on Dmitri's comments. In addition to the IPA client
>>>> and server packages that are included in the RHEL6.1 beta channel, there 
>>>> will be a separate
>>>> RHEL add-on channel, Enterprise Identity Replication.
>>>> That add-on channel will contain ds-replication and the Windows sync
>>>> packages.
>>>>
>>>> If you wish to use IPA during the beta or when it is a tech preview
>>>> feature of RHEL 6.1 you should request an eval entitlement to the 
>>>> Enterprise Identity
>>>> Replication channel from your Red Hat account
>>>> rep.
>>>>
>>>> Cheers,
>>>> Kev
>>>>
>>>>
>>> Hi Kevin,
>>>
>>>
>>>
>>> I have requested the replication channel as you recommended from our 
>>> account manager.
>>>
>>>
>>>
>>> I am curious to why such an important feature as replication is put in it's 
>>> own channel. I
>>> see IPA is trying to compete with Active Directory to service Unix/Linux 
>>> machines, however
>>> with Active Directory all features is included in the base package of the 
>>> operating system.
>>>
>>>
>>>
>>> Why does Red Hat put the replication feature of IPA into a seperate channel 
>>> from the
>>> operating system?
>>>
>>>
>>> Rgds,
>>> Siggi
>>>
>>>
>>
>> Hi Siggi,
>>
>>
>>
>> With RHEL6 we are striving to have more flexibility with packaging and
>> features. From the website: http://www.redhat.com/rhel/add-ons/
>>
>> "Add-Ons to Red Hat Enterprise Linux allow you to tailor your application
>> environment with workload extensions to suit your particular computing 
>> requirements."
>>
>> For RHEL6.2 we are planning to have an Enterprise Identity Replication
>> add-on. Until then, free evaluations will be available for customers who 
>> wish to play with IPA
>> while it is a technology preview.
>>
>
> Hi Kevin,
>
>
> Please disregards Steven Jones' ranting, this was not the kind of feedback I 
> was looking for.
>
>
> Ok, I do like the wider options for channels in Red Hat, but this bring me to 
> my next question:
> Will there be an extra charge for this add on channel, or will this be 
> included in the base
> subscription?
>
> If $answer = yes { Why does Red Hat think they can charge more for a feature 
> that is included in
> it's competitors base license for the equivalent product? }
>
> Else if $answer = no { Great! :) }
>
>
>
>
> Rgds,
> Siggi
>
>
>
>
>
>
>
>
>
>
>
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
>
>


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

Re: [Freeipa-users] 6.1 beta

[Sigbjorn Lie]

On Fri, April 8, 2011 09:48, Natxo Asenjo wrote:
> On Fri, Apr 8, 2011 at 8:38 AM, Sigbjorn Lie  wrote:
>
>
>> Ok, I do like the wider options for channels in Red Hat, but this bring me 
>> to my next question:
>>  Will there be an extra charge for this add on channel, or will this be 
>> included in the base
>> subscription?
>>
>> If $answer = yes { Why does Red Hat think they can charge more for a feature 
>> that is included
>> in it's competitors base license for the equivalent product? }
>
> does Microsoft include a synchronization plugin to RHDS? They do have a 
> synchronization package
> between different servers (sql and possibly other ldap servers) into AD, but 
> iirc not free (sorry,
> I forgot its
> name, I saw it in the pile of cd/dvds we get from MS just in case we bite and 
> use it :-) ).
>
> The synchronization between RHDS and Windows AD is as far as I see it,
> just like the one from 389 directory server:
> http://directory.fedoraproject.org/wiki/Howto:WindowsSync ; if there
> is a supported module for freeipa, then great. Otherwise, one can always try 
> to get it working on
> its own.
>
> Or am I absolutely wrong about this?
> --

Hi,

Sync between Windows and IPA is included. I am asking about the replication 
between IPA servers.


Rgds,
Siggi


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

[Freeipa-users] IPA replication in RHEL

[Sigbjorn Lie]

Hi Kevin,

I requested the add-on replication channel from our RH account rep, however I 
was advised they
we're unable to find any IPA Replication channel. Is this channel ready in RHN 
yet? If so, what is
the name of this channel?


Rgds,
Siggi




On Thu, April 28, 2011 00:31, Kevin Unthank wrote:
> We have no plans to limit the availability of Red Hat
> supported IPA by geographic region. This applies to both the core packages 
> that are part of RHEL,
> as well as any add-ons such as replication.
>
> For the RHEL6.1 release the functionality is a tech preview.
> We will not offer full support in any geographic region
> and access to the replication add-on will require a, no cost, unsupported 
> evaluation entitlement.
> Anyone with access to the RHEL6.1 beta channel can
> request the replication add-on from their Red Hat account rep.
>
> It is our intention to support all IPA functionality,
> globally, in the RHEL6.2 time frame.
>
> Cheers,
> Kev (Product Manager for IPA and DS and CS)
>
>

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

Re: [Freeipa-users] Disk layout - requirements

[Sigbjorn Lie]

On 05/06/2011 04:12 PM, Rob Crittenden wrote:

Steven Jones wrote:


Hi,

Digging through docs / googling I cant see any disk partition 
suggestions and size thereof requirements...


Suggestions please?  sizing for 500 servers, 2000 desktops, 5000+ 
users...


Especially around having different sections of the IPA master of 
different raid groups if that's needed...


It depends in part how you use IPA. A bare-bones user entry is about 
1k, a host that has a certificate is about the same. There is some 
amount of overhead in the DIT and you'll need to consider the space 
for groups, how many kerberos services you'll deploy (also about 1k in 
size) and what other features of IPA you'll use. We have quite a few 
indexes into the data, that will take some room too.


I think additional RAM will be better than terabytes of disk. 389-ds 
is going to try to cache much of this data, and with this number of 
entries it can probably keep most if not all of the database in memory.


We haven't done any analysis on different FS performance.

Does that help?

rob 


Would you consider these documents describing sizing and performance 
tuning of the RH DS to be comparable/transferable to IPA?



http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html/Installation_Guide/Installation_Guide-Platform_Support.html#Installation_Guide-Platform_Support-Hardware_Requirements

http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html/Performance_Tuning_Guide/system-tuning.html


Rgds,
Siggi

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

Re: [Freeipa-users] FreeIPA for Linux desktop deployment

[Sigbjorn Lie]

Hi,

I would like to see the ipa client scripts and possibly the admin tools 
in a nice Solaris package. This would make my job a lot easier as we 
have a lot of customers running Solaris. :)


For the server part I agree with you, keep it at RHEL.

SSSD @ Solaris / HP-UX / AIX ... well there isn't much (if any) of the 
UNIX vendors selling their iron as client machines anymore. And I don't 
see a considerable benefit in adding SSSD to servers, who will be well 
connected to the network anyway.




Rgds,
Siggi


On 05/10/2011 11:31 PM, Dmitri Pal wrote:

On 05/10/2011 05:11 PM, Steven Jones wrote:

Hi,

There are OSS packages that can be installed into Solaris.so I dont see why 
freeipa cant be portedat least the x86 CPU version anyway.

I think this will be a huge undertaking. It is not that simple. And is
there really a value for IPA to be on Solaris?
I can understand the client part but the server is less important. It is
a dedicated server running on BM or VM so does it really matter what os
it is running as long it is supported and affordable?

We as a dev community will be open to any effort to port the whole stack
to some other distribution but I bet there are better uses for someones
energy that we can utilize to deliver better functionality to this user
community.

Client is a different issue. I tried to talk to IBM, HP and Sun a year
ago. They are not interested in porting SSSD to their platforms.


  Oracle/Sun may not want to do IPA but if you had ever had the mis-fortune to 
try and use Oracle's IdM / OVD /OID you'd understand why few 
techies/ppl/businesses want it.its bloody awful to install let alone work 
with or maintainSo its turns into a risky endeavour and no one sane wants 
that much risk in their businesslet alone the 6 figure costs..and 
yes Im talking over a million

Hopefully we are getting away from the silo attitude of vendors.Vendors 
might want only their products in a customer site, but realistically customers 
dont want that for lots of reasons, and pillaging your wallet is one of the 
biggest

In our case all that happens is we wont buy Sun kit if it doesnt work the way 
we want to worktheir loss.

regards

From: freeipa-users-boun...@redhat.com [freeipa-users-boun...@redhat.com] on 
behalf of Dmitri Pal [d...@redhat.com]
Sent: Wednesday, 11 May 2011 8:24 a.m.
To: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] FreeIPA for Linux desktop deployment

On 05/10/2011 04:10 PM, Steven Jones wrote:

Hi,

Its quite interesting that there are no real clients for ipa outside of 
RH/Fedorathis will probably do more to delay or restrict its adoption than 
anything else.


Not sure what you are talking about. Any kerberos enabled service is a
service and any pam_krb5/nss_ldap or SSSD enabled system can be a client.
SSSD is in Debian, Ubuntu, SUSE, Fedora, RH
Would be nice to have it in other OSs like Solaris and HP-UX but they
have other plans.


regards

Steven

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






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

Re: [Freeipa-users] FreeIPA for Linux desktop deployment

[Sigbjorn Lie]

On Wed, May 11, 2011 14:42, Stephen Gallagher wrote:
> On Tue, 2011-05-10 at 23:42 +0200, Sigbjorn Lie wrote:
>
>> Hi,
>>
>>
>> I would like to see the ipa client scripts and possibly the admin tools
>> in a nice Solaris package. This would make my job a lot easier as we have a 
>> lot of customers
>> running Solaris. :)
>>
>> For the server part I agree with you, keep it at RHEL.
>>
>>
>> SSSD @ Solaris / HP-UX / AIX ... well there isn't much (if any) of the
>> UNIX vendors selling their iron as client machines anymore. And I don't
>> see a considerable benefit in adding SSSD to servers, who will be well 
>> connected to the network
>> anyway.
>
>
> Actually, SSSD is still valuable on server systems (and is used very
> often in datacenters). The reason is that it can allow a server to ride out 
> an outage in the LDAP
> and/or Kerberos server and still handle authentication and identity requests 
> from its cache.
>
> We've expressed interest several times in working WITH other platforms
> to help them port the SSSD, but we've received no real commitment to 
> assisting with it. We have a
> lot on our plates already, so it is difficult for us to justify spending time 
> improving our
> competitors' offerings :)
>
> Also, SSSD has additional features with FreeIPA integration that
> nss_ldap and pam_krb5 do not. Specifically, it has support for managing 
> access-control using
> FreeIPA's host-based access control model. This is
> a very valuable piece of the puzzle and should not be ignored.



I see you're having a valid point about the outage support. This could be 
worked around using the
"High Availability Add-on" in RHEL, sharing an IP address between your IPA 
servers, which you
would switch to the currently active IPA server.

With regards to IPA's host-based access control: What about doing access 
control through using
netgroups via the tcp wrappers?

You could still be configuring host based access control in IPA as it's 
creating transparent
netgroups for the host groups.

These are all workarounds, I assume having the functionality available trough 
the native sssd
would be of an advantage. But this way you would the mentioned extra 
functionality of SSSD without
having to do the work of supporting your competitors operating systems. :)


Rgds,
Siggi



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

Re: [Freeipa-users] FreeIPA for Linux desktop deployment

[Sigbjorn Lie]

Excellent, thanks.

I would add to this ticket: "Retreiving the kerberos keytab and storing in the 
clients's
krb5.keytab", as that's my main issue, not the actual distribution of the 
common client
configuration files. I do this with CFengine today.

Is the nfs/* kerberos service required for all nfs4+krb clients? If so, that 
should be added to
the script as well.


Rgds,
Siggi



On Wed, May 11, 2011 00:24, Dmitri Pal wrote:
> On 05/10/2011 05:42 PM, Sigbjorn Lie wrote:
>
>> Hi,
>>
>>
>> I would like to see the ipa client scripts and possibly the admin
>> tools in a nice Solaris package. This would make my job a lot easier as we 
>> have a lot of
>> customers running Solaris. :)
>>
>> For the server part I agree with you, keep it at RHEL.
>>
>>
>> SSSD @ Solaris / HP-UX / AIX ... well there isn't much (if any) of the
>> UNIX vendors selling their iron as client machines anymore. And I
>> don't see a considerable benefit in adding SSSD to servers, who will be well 
>> connected to the
>> network anyway.
>>
>
>
> https://fedorahosted.org/freeipa/ticket/1214
>
>
>
>>
>>
>> Rgds,
>> Siggi
>>
>>
>>
>> On 05/10/2011 11:31 PM, Dmitri Pal wrote:
>>
>>> On 05/10/2011 05:11 PM, Steven Jones wrote:
>>>
>>>> Hi,
>>>>
>>>>
>>>> There are OSS packages that can be installed into Solaris.so I
>>>> dont see why freeipa cant be portedat least the x86 CPU version anyway.
>>> I think this will be a huge undertaking. It is not that simple. And is
>>> there really a value for IPA to be on Solaris? I can understand the client 
>>> part but the server
>>> is less important. It is a dedicated server running on BM or VM so does it 
>>> really matter what
>>> os it is running as long it is supported and affordable?
>>>
>>> We as a dev community will be open to any effort to port the whole stack
>>> to some other distribution but I bet there are better uses for someones 
>>> energy that we can
>>> utilize to deliver better functionality to this user community.
>>>
>>> Client is a different issue. I tried to talk to IBM, HP and Sun a year
>>> ago. They are not interested in porting SSSD to their platforms.
>>>
>>>> Oracle/Sun may not want to do IPA but if you had ever had the
>>>> mis-fortune to try and use Oracle's IdM / OVD /OID you'd understand why few
>>>> techies/ppl/businesses want it.its bloody awful to install let alone 
>>>> work with or
>>>> maintainSo its turns into a risky endeavour and no one sane wants that 
>>>> much risk in
>>>> their businesslet alone the 6 figure costs..and yes Im talking 
>>>> over a million
>>>>
>>>>
>>>> Hopefully we are getting away from the silo attitude of
>>>> vendors.Vendors might want only their products in a customer site, but 
>>>> realistically
>>>> customers dont want that for lots of reasons, and pillaging your wallet is 
>>>> one of the
>>>> biggest
>>>>
>>>> In our case all that happens is we wont buy Sun kit if it doesnt
>>>> work the way we want to worktheir loss.
>>>>
>>>> regards 
>>>> From: freeipa-users-boun...@redhat.com
>>>> [freeipa-users-boun...@redhat.com] on behalf of Dmitri Pal
>>>> [d...@redhat.com]
>>>> Sent: Wednesday, 11 May 2011 8:24 a.m.
>>>> To: freeipa-users@redhat.com
>>>> Subject: Re: [Freeipa-users] FreeIPA for Linux desktop deployment
>>>>
>>>>
>>>> On 05/10/2011 04:10 PM, Steven Jones wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>> Its quite interesting that there are no real clients for ipa
>>>>> outside of RH/Fedorathis will probably do more to delay or restrict 
>>>>> its adoption than
>>>>> anything else.
>>>>>
>>>> Not sure what you are talking about. Any kerberos enabled service is a
>>>> service and any pam_krb5/nss_ldap or SSSD enabled system can be a client. 
>>>> SSSD is in Debian,
>>>> Ubuntu, SUSE, Fedora, RH
>>>> Would be nice to have it in other OSs like Solaris and HP-UX but they
>>>> have other plans.
>>>>
>>>>> regards
>>>>>
>>>>> Steven
>>>>>
>>>> ___
>>>> Freeipa-users mailing list
>>>> Freeipa-users@redhat.com
>>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>>>
>>>>
>>>>
>>>
>>
>> ___
>> Freeipa-users mailing list
>> Freeipa-users@redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>
>>
>>
>
>
> --
> Thank you,
> Dmitri Pal
>
>
> Sr. Engineering Manager IPA project,
> Red Hat Inc.
>
>
>
> ---
> Looking to carve out IT costs?
> www.redhat.com/carveoutcosts/
>
>
>
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
>
>


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

Re: [Freeipa-users] FreeIPA for Linux desktop deployment

[Sigbjorn Lie]

On 05/11/2011 09:25 PM, JR Aquino wrote:

On May 11, 2011, at 10:51 AM, Sigbjorn Lie wrote:


On Wed, May 11, 2011 14:42, Stephen Gallagher wrote:

On Tue, 2011-05-10 at 23:42 +0200, Sigbjorn Lie wrote:


Hi,


I would like to see the ipa client scripts and possibly the admin tools
in a nice Solaris package. This would make my job a lot easier as we have a lot 
of customers
running Solaris. :)

For the server part I agree with you, keep it at RHEL.


SSSD @ Solaris / HP-UX / AIX ... well there isn't much (if any) of the
UNIX vendors selling their iron as client machines anymore. And I don't
see a considerable benefit in adding SSSD to servers, who will be well 
connected to the network
anyway.


Actually, SSSD is still valuable on server systems (and is used very
often in datacenters). The reason is that it can allow a server to ride out an 
outage in the LDAP
and/or Kerberos server and still handle authentication and identity requests 
from its cache.

We've expressed interest several times in working WITH other platforms
to help them port the SSSD, but we've received no real commitment to assisting 
with it. We have a
lot on our plates already, so it is difficult for us to justify spending time 
improving our
competitors' offerings :)

Also, SSSD has additional features with FreeIPA integration that
nss_ldap and pam_krb5 do not. Specifically, it has support for managing 
access-control using
FreeIPA's host-based access control model. This is
a very valuable piece of the puzzle and should not be ignored.



I see you're having a valid point about the outage support. This could be 
worked around using the
"High Availability Add-on" in RHEL, sharing an IP address between your IPA 
servers, which you
would switch to the currently active IPA server.

Not only is there a question of high availability with regard to lookups into 
ldap.  But there is also a problem of scale and overhead.

nss_ldap and pam_ldap perform a lookup per iteration in many cases.

Consider for example. 4 data centers with 100 servers each, all tied back to 
ldap for uid/gid mappings and pam_ldap for authentication and authorization.

If you have a task that logs into each of these 400 servers and performs a 
'sudo ls -la /home' for example,
your ldap servers are going to incur the cost of looking up each file on each 
server, the cost of each authentication, and the cost of performing several 
ldap lookups from the sudo binary.

SSSD is not only beneficial during periods of network inaccessibility, but also 
crucial with regard to scale.


With regards to IPA's host-based access control: What about doing access 
control through using
netgroups via the tcp wrappers?

You could still be configuring host based access control in IPA as it's 
creating transparent
netgroups for the host groups.

Host based access control is currently a mess in the Linux Community.

There are currently a few ways to go about it.

netgroups with
TCP Wrappers
Access.conf

^ This method implies that the changes in your central database must eventually 
be pushed to flatfile configs on the end hosts.
While this works pretty well in small environments, it can fall apart and have 
serious scale issues when dealing with hundreds or thousands of hosts.
(Yes, even when using something like Satellite or Puppet)
Consider the case of Active Directory where you scratch your head and go: "Gee, I'm 
SURE that i pushed that GPO, but for some reason, this set of hosts didn't get the 
memo"

pam_ldap + pam_check_host_attr

^ This issue has a sheer drop off problem with scale.  In this approach, you 
need to fill the user objects with every host that the user is permitted to 
login to.
When the number of users/administrators grow along with the number of hosts you 
have, you get: n^users * n^hosts and the administrative overhead becomes 
overwhelming.


These are all workarounds, I assume having the functionality available trough 
the native sssd
would be of an advantage. But this way you would the mentioned extra 
functionality of SSSD without
having to do the work of supporting your competitors operating systems. :)

There have been _some_ discussions surrounding a pam module that could be used 
as a very base level of hbac support since there are a lot of pre-required 
dependancies for sssd.

The advantage would be theoretical portability, and the loss would be caching.

I have personally written such a pam plugin prototype in python, and it 
functions just fine in linux installations.  the c code that calls the python 
script is not compatible with open_pam,
so there is still work to be done to support the BSD / MAC solutions, but I 
believe its just a matter of some syntax changes...

I hope this information helps clarify these points.



I wasen't going at SSSD for not being usable. I was trying to make a 
suggestion for a alternative solution for using IPA with *nix OS' tha

Re: [Freeipa-users] FreeIPA for Linux desktop deployment

[Sigbjorn Lie]

That said we have configuration instructions for other platforms, I am
sure the community can hack-up scripts to use them if instructions are
not enough. We can also host them if someone wants to contribute.


Ok. Let's say I've pre-created the host on the IPA server.

I'm logged on to the Solaris/AIX/etc, machine I'm joining to IPA, I've 
configured krb and the ldap client. (And possibly tcp wrappers, 
sshd_config, etc for host (netgroup) based access control). That's the 
easy part done.


Can I somehow retrieve the keytab for this machine, at the machine itself?


Rgds,
Siggi

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

[Freeipa-users] IPA Startup issues

[Sigbjorn Lie]

I've noticed that if the machine running IPA is very busy at startup, 
the IPA services will not be online when the machine is started.


I noticed this is as my test virtualization host has had it's power cord 
knocked out a few times. When I restart the host machine, all the 
virtual machines is started at the same time, causing (a lot) higher 
than normal latency for each virtual machine.


This causes the IPA daemons to start, while during the startup one or 
several IPA daemons fails due to dependencies of other daemons which is 
not started yet, and all the IPA daemons is stopped as not all the IPA 
daemons started successfully. I've noticed that the default behavior of 
the ipactl command is to shut down all the IPA daemons, if any of the 
IPA daemons should fail during startup.


This can be seen in the logs of the individual services, as some is 
started successfully, just to receive a shutdown signal shortly after. 
It seem to be the pki-ca which shut down my IPA services this morning.


When rebooting the virtual machine running the IPA daemons during normal 
load of the host machine, all the IPA daemons start successfully. 
Logging on to the IPA server and manually starting the IPA daemons after 
the load of the host machine has decreased also works.


I suggest changing the startup scripts to allow (a lot) longer startup 
times for the IPA daemons prior to failing them.



Rgds,
Siggi

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

Re: [Freeipa-users] IPA Startup issues

[Sigbjorn Lie]

On 05/16/2011 03:41 PM, Dmitri Pal wrote:

On 05/14/2011 10:46 AM, Sigbjorn Lie wrote:

I've noticed that if the machine running IPA is very busy at startup,
the IPA services will not be online when the machine is started.

I noticed this is as my test virtualization host has had it's power
cord knocked out a few times. When I restart the host machine, all the
virtual machines is started at the same time, causing (a lot) higher
than normal latency for each virtual machine.

This causes the IPA daemons to start, while during the startup one or
several IPA daemons fails due to dependencies of other daemons which
is not started yet, and all the IPA daemons is stopped as not all the
IPA daemons started successfully. I've noticed that the default
behavior of the ipactl command is to shut down all the IPA daemons, if
any of the IPA daemons should fail during startup.

This can be seen in the logs of the individual services, as some is
started successfully, just to receive a shutdown signal shortly after.
It seem to be the pki-ca which shut down my IPA services this morning.

When rebooting the virtual machine running the IPA daemons during
normal load of the host machine, all the IPA daemons start
successfully. Logging on to the IPA server and manually starting the
IPA daemons after the load of the host machine has decreased also works.

I suggest changing the startup scripts to allow (a lot) longer startup
times for the IPA daemons prior to failing them.


F15 introduced new way to start daemons and define dependencies.
We have in our plans to port IPA to use systemd in F16. This will have
implications on the architecture of the service startup in general and
most likely will affect the current way of starting services too.



This was RHEL 6.1beta I tested at. I presume it will be some time before 
systemd will make it's way into RHEL? What can be done in the meantime 
for IPA in RHEL?



Rgds,
Siggi


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

Re: [Freeipa-users] IPA Startup issues

[Sigbjorn Lie]

On 05/16/2011 03:52 PM, Simo Sorce wrote:

On Sat, 2011-05-14 at 16:46 +0200, Sigbjorn Lie wrote:

I've noticed that if the machine running IPA is very busy at startup,
the IPA services will not be online when the machine is started.

I noticed this is as my test virtualization host has had it's power cord
knocked out a few times. When I restart the host machine, all the
virtual machines is started at the same time, causing (a lot) higher
than normal latency for each virtual machine.

This causes the IPA daemons to start, while during the startup one or
several IPA daemons fails due to dependencies of other daemons which is
not started yet, and all the IPA daemons is stopped as not all the IPA
daemons started successfully. I've noticed that the default behavior of
the ipactl command is to shut down all the IPA daemons, if any of the
IPA daemons should fail during startup.

This can be seen in the logs of the individual services, as some is
started successfully, just to receive a shutdown signal shortly after.
It seem to be the pki-ca which shut down my IPA services this morning.

When rebooting the virtual machine running the IPA daemons during normal
load of the host machine, all the IPA daemons start successfully.
Logging on to the IPA server and manually starting the IPA daemons after
the load of the host machine has decreased also works.

I suggest changing the startup scripts to allow (a lot) longer startup
times for the IPA daemons prior to failing them.

At the moment we just run service  start and wait until it is
done. If the pki-cad service timeouts and returns an error I think we
need to open a bug against the dogtag component as that is the cause.

Can you open a bug in the freeipa trac with logs showing that service is
responsible for the failure ?


I haven't been able to figure out which service that failed IPA yet. A 
lot of log files scattered around. As you can see from the slapd errors 
file, the slapd daemon was available for almost 3 minutes before 
receiving the shutdown signal. I notice now that the PKI daemon failed 8 
seconds after slapd had shut down, so I was wrong in blaming the PKI daemon.


See below for a list of log files I've been trough. They all have on 
thing in common, the daemons starts when the host machine is started, at 
approx 06:34, then receives a shutdown signal around 06:37. Some time 
later when the host has calmed down, I'm logging in and manually 
starting IPA using "ipactl start", and all the daemons start without any 
problem. And they keep running after my manual intervention.


I wish I could be more specific, but I'm unsure where else to look. 
Suggestions?



/var/log/krb5kdc.log
/var/log/pki-ca/catalina.out
/var/log/dirsrv/slapd-IX-TEST-COM/errors
/var/log/dirsrv/slapd-PKI-IPA/errors
/var/log/httpd/error_log
/var/log/messages (named log)

slapd errors:

[14/May/2011:06:33:52 +0200] - 389-Directory/1.2.8.rc1 B2011.062.1416 
starting up
[14/May/2011:06:33:54 +0200] - Detected Disorderly Shutdown last time 
Directory Server was running, recovering database.
[14/May/2011:06:34:39 +0200] schema-compat-plugin - warning: no entries 
set up under , ou=SUDOers, dc=ix,dc=TEST,dc=com
[14/May/2011:06:34:39 +0200] - Skipping CoS Definition cn=Password 
Policy,cn=accounts,dc=ix,dc=TEST,dc=com--no CoS Templates found, which 
should be added b

efore the CoS Definition.
[14/May/2011:06:34:40 +0200] - Skipping CoS Definition cn=Password 
Policy,cn=accounts,dc=ix,dc=TEST,dc=com--no CoS Templates found, which 
should be added b

efore the CoS Definition.
[14/May/2011:06:34:41 +0200] - slapd started.  Listening on All 
Interfaces port 389 for LDAP requests
[14/May/2011:06:34:41 +0200] - Listening on All Interfaces port 636 for 
LDAPS requests
[14/May/2011:06:34:42 +0200] - Listening on 
/var/run/slapd-IX-TEST-COM.socket for LDAPI requests
[14/May/2011:06:37:30 +0200] - slapd shutting down - signaling operation 
threads
[14/May/2011:06:37:30 +0200] - slapd shutting down - closing down 
internal subsystems and plugins

[14/May/2011:06:37:31 +0200] - Waiting for 4 database threads to stop
[14/May/2011:06:37:32 +0200] - All database threads now stopped
[14/May/2011:06:37:32 +0200] - slapd stopped.


/var/log/pki-ca/system:
1871.main - [14/May/2011:06:37:40 CEST] [8] [3] In Ldap (bound) 
connection pool to host ipasrv01.ix.TEST.com port 7389, Cannot connect 
to LDAP server. Error: netscape.ldap.LDAPException: failed to connect to 
server ldap://ipasrv01.ix.TEST.com:7389 (91)


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

Re: [Freeipa-users] IPA Startup issues

[Sigbjorn Lie]

On 05/16/2011 04:25 PM, Rob Crittenden wrote:

Sigbjorn Lie wrote:

On 05/16/2011 03:41 PM, Dmitri Pal wrote:

On 05/14/2011 10:46 AM, Sigbjorn Lie wrote:

I've noticed that if the machine running IPA is very busy at startup,
the IPA services will not be online when the machine is started.

I noticed this is as my test virtualization host has had it's power
cord knocked out a few times. When I restart the host machine, all the
virtual machines is started at the same time, causing (a lot) higher
than normal latency for each virtual machine.

This causes the IPA daemons to start, while during the startup one or
several IPA daemons fails due to dependencies of other daemons which
is not started yet, and all the IPA daemons is stopped as not all the
IPA daemons started successfully. I've noticed that the default
behavior of the ipactl command is to shut down all the IPA daemons, if
any of the IPA daemons should fail during startup.

This can be seen in the logs of the individual services, as some is
started successfully, just to receive a shutdown signal shortly after.
It seem to be the pki-ca which shut down my IPA services this morning.

When rebooting the virtual machine running the IPA daemons during
normal load of the host machine, all the IPA daemons start
successfully. Logging on to the IPA server and manually starting the
IPA daemons after the load of the host machine has decreased also 
works.


I suggest changing the startup scripts to allow (a lot) longer startup
times for the IPA daemons prior to failing them.


F15 introduced new way to start daemons and define dependencies.
We have in our plans to port IPA to use systemd in F16. This will have
implications on the architecture of the service startup in general and
most likely will affect the current way of starting services too.



This was RHEL 6.1beta I tested at. I presume it will be some time before
systemd will make it's way into RHEL? What can be done in the meantime
for IPA in RHEL?


Can you be more specific which services didn't start?


Please see my previous post when replying to Simo Sorce.


Rgds,
Siggi

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

Re: [Freeipa-users] IPA Startup issues

[Sigbjorn Lie]

On 05/16/2011 04:56 PM, Rich Megginson wrote:

On 05/16/2011 08:43 AM, Sigbjorn Lie wrote:

On 05/16/2011 03:52 PM, Simo Sorce wrote:

On Sat, 2011-05-14 at 16:46 +0200, Sigbjorn Lie wrote:

I've noticed that if the machine running IPA is very busy at startup,
the IPA services will not be online when the machine is started.

I noticed this is as my test virtualization host has had it's power 
cord

knocked out a few times. When I restart the host machine, all the
virtual machines is started at the same time, causing (a lot) higher
than normal latency for each virtual machine.

This causes the IPA daemons to start, while during the startup one or
several IPA daemons fails due to dependencies of other daemons 
which is

not started yet, and all the IPA daemons is stopped as not all the IPA
daemons started successfully. I've noticed that the default 
behavior of

the ipactl command is to shut down all the IPA daemons, if any of the
IPA daemons should fail during startup.

This can be seen in the logs of the individual services, as some is
started successfully, just to receive a shutdown signal shortly after.
It seem to be the pki-ca which shut down my IPA services this morning.

When rebooting the virtual machine running the IPA daemons during 
normal

load of the host machine, all the IPA daemons start successfully.
Logging on to the IPA server and manually starting the IPA daemons 
after

the load of the host machine has decreased also works.

I suggest changing the startup scripts to allow (a lot) longer startup
times for the IPA daemons prior to failing them.

At the moment we just run service  start and wait until it is
done. If the pki-cad service timeouts and returns an error I think we
need to open a bug against the dogtag component as that is the cause.

Can you open a bug in the freeipa trac with logs showing that 
service is

responsible for the failure ?


I haven't been able to figure out which service that failed IPA yet. 
A lot of log files scattered around. As you can see from the slapd 
errors file, the slapd daemon was available for almost 3 minutes 
before receiving the shutdown signal. I notice now that the PKI 
daemon failed 8 seconds after slapd had shut down, so I was wrong in 
blaming the PKI daemon.


See below for a list of log files I've been trough. They all have on 
thing in common, the daemons starts when the host machine is started, 
at approx 06:34, then receives a shutdown signal around 06:37. Some 
time later when the host has calmed down, I'm logging in and manually 
starting IPA using "ipactl start", and all the daemons start without 
any problem. And they keep running after my manual intervention.


I wish I could be more specific, but I'm unsure where else to look. 
Suggestions?



/var/log/krb5kdc.log
/var/log/pki-ca/catalina.out
/var/log/dirsrv/slapd-IX-TEST-COM/errors
/var/log/dirsrv/slapd-PKI-IPA/errors
/var/log/httpd/error_log
/var/log/messages (named log)

slapd errors:

[14/May/2011:06:33:52 +0200] - 389-Directory/1.2.8.rc1 B2011.062.1416 
starting up
[14/May/2011:06:33:54 +0200] - Detected Disorderly Shutdown last time 
Directory Server was running, recovering database.
1) Disorderly Shutdown means a) crash b) kill -9 or similar - neither 
of which should be happening - is this the replica install or the 
first master install?




First master install.

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

Re: [Freeipa-users] IPA Startup issues

[Sigbjorn Lie]

On 05/17/2011 07:24 PM, Rich Megginson wrote:

On 05/17/2011 06:40 AM, Sigbjorn Lie wrote:

On 05/16/2011 04:56 PM, Rich Megginson wrote:

On 05/16/2011 08:43 AM, Sigbjorn Lie wrote:

On 05/16/2011 03:52 PM, Simo Sorce wrote:

On Sat, 2011-05-14 at 16:46 +0200, Sigbjorn Lie wrote:
I've noticed that if the machine running IPA is very busy at 
startup,

the IPA services will not be online when the machine is started.

I noticed this is as my test virtualization host has had it's 
power cord

knocked out a few times. When I restart the host machine, all the
virtual machines is started at the same time, causing (a lot) higher
than normal latency for each virtual machine.

This causes the IPA daemons to start, while during the startup 
one or
several IPA daemons fails due to dependencies of other daemons 
which is
not started yet, and all the IPA daemons is stopped as not all 
the IPA
daemons started successfully. I've noticed that the default 
behavior of
the ipactl command is to shut down all the IPA daemons, if any of 
the

IPA daemons should fail during startup.

This can be seen in the logs of the individual services, as some is
started successfully, just to receive a shutdown signal shortly 
after.
It seem to be the pki-ca which shut down my IPA services this 
morning.


When rebooting the virtual machine running the IPA daemons during 
normal

load of the host machine, all the IPA daemons start successfully.
Logging on to the IPA server and manually starting the IPA 
daemons after

the load of the host machine has decreased also works.

I suggest changing the startup scripts to allow (a lot) longer 
startup

times for the IPA daemons prior to failing them.

At the moment we just run service  start and wait until it is
done. If the pki-cad service timeouts and returns an error I think we
need to open a bug against the dogtag component as that is the cause.

Can you open a bug in the freeipa trac with logs showing that 
service is

responsible for the failure ?


I haven't been able to figure out which service that failed IPA 
yet. A lot of log files scattered around. As you can see from the 
slapd errors file, the slapd daemon was available for almost 3 
minutes before receiving the shutdown signal. I notice now that the 
PKI daemon failed 8 seconds after slapd had shut down, so I was 
wrong in blaming the PKI daemon.


See below for a list of log files I've been trough. They all have 
on thing in common, the daemons starts when the host machine is 
started, at approx 06:34, then receives a shutdown signal around 
06:37. Some time later when the host has calmed down, I'm logging 
in and manually starting IPA using "ipactl start", and all the 
daemons start without any problem. And they keep running after my 
manual intervention.


I wish I could be more specific, but I'm unsure where else to look. 
Suggestions?



/var/log/krb5kdc.log
/var/log/pki-ca/catalina.out
/var/log/dirsrv/slapd-IX-TEST-COM/errors
/var/log/dirsrv/slapd-PKI-IPA/errors
/var/log/httpd/error_log
/var/log/messages (named log)

slapd errors:

[14/May/2011:06:33:52 +0200] - 389-Directory/1.2.8.rc1 
B2011.062.1416 starting up
[14/May/2011:06:33:54 +0200] - Detected Disorderly Shutdown last 
time Directory Server was running, recovering database.
1) Disorderly Shutdown means a) crash b) kill -9 or similar - 
neither of which should be happening - is this the replica install 
or the first master install?




First master install.

What is in the slapd errors log before [14/May/2011:06:33:52 +0200] - 
389-Directory/1.2.8.rc1 B2011.062.1416 starting up?



Hi,

Rich, there is nothing above that line. Previous entry was from last 
time the server started.


Yesterday I rebooted my host platform, graceful shutdown this time, and 
the same problem occurred again when the host, and all the virtual 
machines started. I had a look in  my boot.log file, see below for 
output. As you can see the "Starting pki-ca" return an "OK", but the 
next line says: "Failed to start CA Service"

"Shutting down".

Looking at the timestamps, it looks like the dirsrv instance is shut 
down before the pki-ca is given a chance to start, or am I looking at 
the incorrect log files?


I have included my boot.log, and the PKI-CA dirsrv log, and the pki-ca 
debug log.





/var/log/boot.log:

Starting Directory Service
Starting dirsrv:
IX-TEST-COM...   [  OK  ]
PKI-IPA... [  OK  ]
Starting KDC Service
Starting Kerberos 5 KDC:   [  OK  ]
Starting KPASSWD Service
Starting ipa_kpasswd:  [  OK  ]
Starting DNS Service
Starting named:[  OK  ]
Starting HTTP Service
Starting httpd:[  OK  ]
Starting CA Service
Starting pki-ca:   

[Freeipa-users] ipa-client in RHEL5

[Sigbjorn Lie]

Hi,

Is it so that the ipa-client-install script currently available for RHEL 
5.6 is not yet updated to work with the IPA server released in RHEL 6.1?



Rgds,
Siggi

[root@client5 ~]# rpm -qa|grep ipa-client
ipa-client-2.0-10.el5


[root@client5 ~]# ipa-client-install
Discovery was successful!
Realm: IX.TEST.COM
DNS Domain: ix.test.com
IPA Server: ipa01.ix.test.com
BaseDN: dc=ix,dc=test,dc=com


Continue to configure the system with these values? [no]: yes
Principal: admin
Password for ad...@ix.test.com:
Joining realm failed: Operation failed! unsupported extended operation
child exited with 9
Certificate subject base is: O=IX.TEST.COM


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

Re: [Freeipa-users] IPA Startup issues

[Sigbjorn Lie]

Hi,

These findings we're taken from a machine that's been upgraded to RHEL 
6.1 proper.




Rgds,
Siggi



On 05/22/2011 10:18 PM, Steven Jones wrote:

Hi,

I seem to have similar issues, but since 6.1 proper is now out, Im starting 
again from scratch, I need to improve disk layouts etc anyway.

regards



From: freeipa-users-boun...@redhat.com [freeipa-users-boun...@redhat.com] on 
behalf of Sigbjorn Lie [sigbj...@nixtra.com]
Sent: Sunday, 22 May 2011 10:16 p.m.
To: Rich Megginson
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] IPA Startup issues

On 05/17/2011 07:24 PM, Rich Megginson wrote:

On 05/17/2011 06:40 AM, Sigbjorn Lie wrote:

On 05/16/2011 04:56 PM, Rich Megginson wrote:

On 05/16/2011 08:43 AM, Sigbjorn Lie wrote:

On 05/16/2011 03:52 PM, Simo Sorce wrote:

On Sat, 2011-05-14 at 16:46 +0200, Sigbjorn Lie wrote:

I've noticed that if the machine running IPA is very busy at
startup,
the IPA services will not be online when the machine is started.

I noticed this is as my test virtualization host has had it's
power cord
knocked out a few times. When I restart the host machine, all the
virtual machines is started at the same time, causing (a lot) higher
than normal latency for each virtual machine.

This causes the IPA daemons to start, while during the startup
one or
several IPA daemons fails due to dependencies of other daemons
which is
not started yet, and all the IPA daemons is stopped as not all
the IPA
daemons started successfully. I've noticed that the default
behavior of
the ipactl command is to shut down all the IPA daemons, if any of
the
IPA daemons should fail during startup.

This can be seen in the logs of the individual services, as some is
started successfully, just to receive a shutdown signal shortly
after.
It seem to be the pki-ca which shut down my IPA services this
morning.

When rebooting the virtual machine running the IPA daemons during
normal
load of the host machine, all the IPA daemons start successfully.
Logging on to the IPA server and manually starting the IPA
daemons after
the load of the host machine has decreased also works.

I suggest changing the startup scripts to allow (a lot) longer
startup
times for the IPA daemons prior to failing them.

At the moment we just run service   start and wait until it is
done. If the pki-cad service timeouts and returns an error I think we
need to open a bug against the dogtag component as that is the cause.

Can you open a bug in the freeipa trac with logs showing that
service is
responsible for the failure ?

I haven't been able to figure out which service that failed IPA
yet. A lot of log files scattered around. As you can see from the
slapd errors file, the slapd daemon was available for almost 3
minutes before receiving the shutdown signal. I notice now that the
PKI daemon failed 8 seconds after slapd had shut down, so I was
wrong in blaming the PKI daemon.

See below for a list of log files I've been trough. They all have
on thing in common, the daemons starts when the host machine is
started, at approx 06:34, then receives a shutdown signal around
06:37. Some time later when the host has calmed down, I'm logging
in and manually starting IPA using "ipactl start", and all the
daemons start without any problem. And they keep running after my
manual intervention.

I wish I could be more specific, but I'm unsure where else to look.
Suggestions?


/var/log/krb5kdc.log
/var/log/pki-ca/catalina.out
/var/log/dirsrv/slapd-IX-TEST-COM/errors
/var/log/dirsrv/slapd-PKI-IPA/errors
/var/log/httpd/error_log
/var/log/messages (named log)

slapd errors:

[14/May/2011:06:33:52 +0200] - 389-Directory/1.2.8.rc1
B2011.062.1416 starting up
[14/May/2011:06:33:54 +0200] - Detected Disorderly Shutdown last
time Directory Server was running, recovering database.

1) Disorderly Shutdown means a) crash b) kill -9 or similar -
neither of which should be happening - is this the replica install
or the first master install?



First master install.


What is in the slapd errors log before [14/May/2011:06:33:52 +0200] -
389-Directory/1.2.8.rc1 B2011.062.1416 starting up?


Hi,

Rich, there is nothing above that line. Previous entry was from last
time the server started.

Yesterday I rebooted my host platform, graceful shutdown this time, and
the same problem occurred again when the host, and all the virtual
machines started. I had a look in  my boot.log file, see below for
output. As you can see the "Starting pki-ca" return an "OK", but the
next line says: "Failed to start CA Service"
"Shutting down".

Looking at the timestamps, it looks like the dirsrv instance is shut
down before the pki-ca is given a chance to start, or am I looking at
the incorrect log files?

I have included my boot.log, and the PKI-CA dirsrv log, and the pki-ca
debug log.




/var/log/boot.log:

Starting Directory Service
Sta

Re: [Freeipa-users] Also attempting to integrate Solaris 10 clients with freeipa

[Sigbjorn Lie]

Hi,

I wrote these bugzilla entries based on my own Solaris 10 configuration for IPA 
a while back. Did you try these? They include a working DUA profile (need to 
change server names of course) and the steps I did for configuring Solaris 10 
as an IPA client.

Config:
https://bugzilla.redhat.com/show_bug.cgi?id=815533 


Dua Profile:
https://bugzilla.redhat.com/show_bug.cgi?id=815515 


The attribute mapping I suggested was for auto.master only. The example dua 
profile above have this mapping. You may see here for a further explanation:

https://www.redhat.com/archives/freeipa-users/2015-March/msg00317.html 



Regards,
Siggi



> On 23 Apr 2015, at 12:59, Roderick Johnstone  wrote:
> 
> On 23/04/15 04:25, Rob Crittenden wrote:
>> Roderick Johnstone wrote:
>>> On 22/04/15 14:30, Dmitri Pal wrote:
 On 04/21/2015 01:13 PM, Roderick Johnstone wrote:
> Hi
> 
> I also need to integrate Solaris 10 clients with freeipa servers.
> 
> I've been round many resources, eg freeipa wiki, Fedora and Red Hat
> manuals, various bug trackers and the freeipa-users mailing list.
> 
> It looks to me as if this:
> https://www.redhat.com/archives/freeipa-users/2013-January/msg00030.html
> 
> might be the best guide available, although I'm not sure what changes
> I might need to make because I'm actually on Solaris 10 rather than 11.
> 
> Can anyone advise please?
> 
> There is a comment in the above post:
> "Make sure that the automount maps in ipaserver is named auto_* and
> NOT auto.* so they are compatible with Solaris name standards."
> 
> My automount maps are already called eg auto.master, auto.home on my
> ipa server and I'm sure I've seen a post somewhere suggesting an
> attributeMap can fix this issue, but I can't find it now, so maybe I
> am mistaken.
> 
> Am I on the right track? Is anyone familiar with that fix.
> 
> Thanks
> 
> Roderick Johnstone
> 
 We are not strong in Solaris so you really need to search user archives
 or wait for someone who accomplished Solaris integration to chime in
 here on the list.
 
>>> 
>>> Dmitri
>>> 
>>> I had gathered that from previous postings to the list and was indeed
>>> hoping that one of the Solaris experts might comment.
>>> 
>>> By the way, there are various suggestions on the list of putting the
>>> best Solaris instructions on the wiki. Is that still a possibility? I'd
>>> be happy to help, but I'm not experienced with connecting Solaris to ipa
>>> yet!
>>> 
>>> Roderick
>>> 
>> 
>> A few weeks back I added what I thought were the most relevant threads
>> and pointers. The mailing list thread you refer to was converted into
>> some documentation bugs and tickets. I referenced those at
>> http://www.freeipa.org/page/ConfiguringUnixClients#Additional_Resources
>> 
>> If there is anything I can improve here just let me know.
> 
> Rob
> 
> This page has expanded since I was searching a few weeks ago. Thanks for 
> that. I understand that the project has no direct Solaris expertise.
> 
> There are some things that could be made easier to follow and others that 
> seem inconsistent with the mailing list thread that I found. Maybe some are 
> just different ways of doing the same thing.
> 
> I started to point some some differences in this email, but its probably best 
> if I go through the mailing list link that I found and the web page you 
> referenced, systematically, and list what the differences are. I'll be in 
> touch when I have done that.
> 
> In the meantime I noticed a few of small html link issues on the web page you 
> referenced...
> 
> 1) Under the section Solaris 8/9/10 / Configuring Client Authentication
> the link to the reference files in /var/ldap 
> (http://www.freeipa.com/page/ConfiguringUnixClients#Client_Configuration_Files),
>  for me,  resolves to the top level "Open Source Community page" 
> http://community.redhat.com/software/. I do however see the files correctly 
> linked from the section "Client Configuration Files" at bottom of the page.
> 
> 2) There is the same issue for the links to the nsswitch.conf and pam.conf 
> files linked in items 2 and 4 below the above - sorry, its hard to describe 
> well where these links are.
> 
> And it would be good if the patch ("Patch to update Solaris documentation") 
> that is referred to in Solaris 8/9/10 / Additional resources could be applied 
> to the original document and the patched document made available, or at least 
> the information in it.
> 
> 
> Thanks
> 
> Roderick
> 
> 
>> 
>> 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

-- 
Manage your s

Re: [Freeipa-users] how can i create home directories automatically on solaris while IPA user login

[Sigbjorn Lie]

Hi,

You may download the profile from bugzilla, here’s a direct link to the 
attachement: https://bugzilla.redhat.com/attachment.cgi?id=579657 
<https://bugzilla.redhat.com/attachment.cgi?id=579657>

Modify the server names and baseDN to match your environment.

Use ldapadd to add the dua profile to your IPA LDAP server.

ldapadd -x -D 'cn=Directory Manager' -W 


Please note: We do not use any AD trust, so the users logging into our Solaris 
servers is doing so from an IPA account.


Regards,
Siggi


> On 12 Mar 2015, at 19:30, Ben .T.George  wrote:
> 
> HI Siggi,
> 
> thanks for the detailed information.
> 
> how can i apply this DUA profile? can you please give me the steps to apply 
> this.
> 
> my current stage is, i can able to login to solaris 10 box with AD user. only 
> thing from command like without "-" in su
> 
> Regards,
> Ben
> 
> On Thu, Mar 12, 2015 at 4:00 PM, Sigbjorn Lie  <mailto:sigbj...@nixtra.com>> wrote:
> Hi,
> 
> Yes the DUA profile needs manually editing and updating as IPA servers are 
> added or removed. Ideally this would be managed by ipa-replica-manage, 
> however as I was advised in the BZ, Red Hat does not have the knowledge or 
> resources to focus on integration with Solaris, which is understandable. :)
> 
> The DUA profile I’ve uploaded to the BZ is a copy (with server names edited), 
> of the DUA profile I1ve used at several environments when configuring Solaris 
> 10 to work with IPA, so unless there are typos I haven’t discovered, it would 
> work ok. :)
> 
> As for the auto mount, Linux uses “.” between auto and the map name, such as 
> auto.master, auto.home, etc. And Solaris uses “_” between the auto and the 
> map name, such as auto_master, auto_home.
> 
> This can be worked around in the DUA profile by adding a 
> searchServiceDescriptor for each auto mounter map, such as 
> "serviceSearchDescriptor: 
> auto_master:automountMapName=auto.master,cn=defualt,cn=automount,dc=ix,dc=test,dc=com”.
> 
> What I found as the best middle ground here, was to keep the master name 
> auto.master and have a serviceSearchDescriptor in the DUA profile for 
> auto.master, and have the remaining maps in IPA with “_”as the separator. 
> This works the best as Linux will look for automaster by default, and be 
> happy with the other maps being referred to with “_”as separator. Solaris 
> seem to require that all the maps  use “_”as seperator, unless 
> serviceSearchDescriptor entries are added for each map.
> 
> I hope this was what you we’re looking for?
> 
> 
> Regards,
> Siggi
> 
> 
> 
> 
>> On 11 Mar 2015, at 19:39, Dmitri Pal > <mailto:d...@redhat.com>> wrote:
>> 
>> Hello,
>> 
>> Is there any chance you can help this guy on the FreeIPA list?
>> 
>> Thanks
>> Dmitri
>> 
>> 
>>  Original Message 
>> Subject: Re: [Freeipa-users] how can i create home directories 
>> automatically on solaris while IPA user login
>> Date:Wed, 11 Mar 2015 21:22:02 +0300
>> From:Ben .T.George  
>> <mailto:bentech4...@gmail.com>
>> Reply-To:bentech4...@gmail.com <mailto:bentech4...@gmail.com>
>> To:  dpal  <mailto:d...@redhat.com>
>> CC:  freeipa-users  
>> <mailto:freeipa-users@redhat.com>
>> 
>> 
>> from BZ
>> 
>> "While
>> we value your interest in IPA Solaris support, the
>> implementation of the DUA profile is not on our nearest
>> schedule at the moment. We lack both knowledge and resources
>> to focus on integration with Solaris. This is where we need
>> a help (ideally patches) and contribution from the community
>> to help us push these features in.
>> I checked your example DUAConfigProfile and I think it cannot be just added 
>> to FreeIPA right away. E.g. for defaultServerList or preferredServerList, 
>> you would need to expand installers and ipa-replica-manage to handle these 
>> lists and update them when replica is added or updated to prevent it being 
>> outdated. printers or aliases serviceSearchDescriptor refers to objects not 
>> being available and so on. It is not as straightforward as it seems.
>> 
>> What I think that we can work on is to work together on
>> http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html#Configuring_an_IPA_Client_on_Solaris_10
>>  
>> <http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html#Configuring_an_IPA_Client_on_Solaris_10>
>> ..

Re: [Freeipa-users] Solaris 10 client configuration using profile

[Sigbjorn Lie]

On Sat, October 11, 2014 19:54, Alexander Bokovoy wrote:
> On Sat, 11 Oct 2014, Rob Crittenden wrote:
>
>> sipazzo wrote:
>>> Thank you,I know where the profile is in the directory tree and how I would 
>>> invoke it were it
>>> there...I don't know how to get it into the directory tree so that it is 
>>> available to
>>> clients. I see posts giving examples of different profilesthat could be 
>>> used but no post as
>>> to how to add it to the directory. Sorry if I am missing something obvious.
>>>
>>>
>>> 
>>> On Fri, 10/10/14, Rob Crittenden  wrote:
>>>
>>>
>>> Subject: Re: [Freeipa-users] Solaris 10 client configuration using profile
>>> To: "sipazzo" , freeipa-users@redhat.com
>>> Date: Friday, October 10, 2014, 4:53 PM
>>>
>>>
>>> sipazzo wrote:

>>> Hello, I am trying to set up a default profile for my
>>> Solaris 10 IPA clients as recommended. I generated a profile
>>> on a Solaris with the attributes I needed except I got an "invalid 
>>> parameter" error when
>>> specifying the domainName attribute like this -a domainName=example.com 
>>> even though this
>>> parameter works when I use it in ldapclient manual. More of an issue though 
>>> is I have been
>>> unable to find documentation on getting the profile incorporated into the 
>>> ipa server. How do I
>>> get this profile on the ipa server and make it available to my Solaris 
>>> clients? Also, my
>>> understanding is the clients periodically check this profile so they stay 
>>> updated with the
>>> latest configuration information. What generates this check? Is it time 
>>> based, a restart of a
>>> service or ??

 Thank you for any

>>> assistance.

>>>
>>> It's been forever since I configured a
>>> Solaris anything client but I can
>>> tell you where the profile gets stored: 
>>> cn=profilename,cn=default,ou=profile,$SUFFIX
>>>
>>> IPA ships with a default
>>> profile of:
>>>
>>> dn:
>>> cn=default,ou=profile,$SUFFIX ObjectClass:
>>> top ObjectClass: DUAConfigProfile
>>> defaultServerList: $FQDN
>>> defaultSearchBase: $SUFFIX
>>> authenticationMethod: none
>>> searchTimeLimit: 15
>>> cn:
>>> default serviceSearchDescriptor:
>>> passwd:cn=users,cn=accounts,$SUFFIX
>>> serviceSearchDescriptor:
>>> group:cn=groups,cn=compat,$SUFFIX
>>> bindTimeLimit: 5
>>> objectClassMap:
>>> shadow:shadowAccount=posixAccount
>>> followReferrals:TRUE
>>>
>>>
>>> The full schema can be found at
>>> http://docs.oracle.com/cd/E23824_01/html/821-1455/schemas-17.html
>>>
>>>
>>> So if your profile is named
>>> foo you'd invoke it with something like:
>>>
>>> # ldapclient init -a
>>> profileName=foo ipa.example.com
>>>
>>> rob
>>>
>>>
>>
>> Here is an example inspired by
>> https://bugzilla.redhat.com/show_bug.cgi?id=815515
>>
>>
>> $ ldapmodify -x -D 'cn=Directory Manager' -W
>> dn: cn=solaris_authssl_test,ou=profile,dc=example,dc=com
>> objectClass: top
>> objectClass: DUAConfigProfile
>> cn: solaris_authssl_test
>> authenticationMethod: tls:simple
>> bindTimeLimit: 5
>> credentialLevel: proxy
>> defaultSearchBase: dc=example,dc=com
>> defaultSearchScope: one
>> defaultServerList: ipa01.example.com ipa02.example.com ipa03.example.com
>> followReferrals: TRUE
>> objectclassMap: shadow:shadowAccount=posixAccount
>> objectclassMap: printers:sunPrinter=printerService
>> preferredServerList: ipa01.example.com ipa02.example.com
>> profileTTL: 6000
>> searchTimeLimit: 10
>> serviceSearchDescriptor: passwd:cn=users,cn=accounts,dc=example,dc=com
>> serviceSearchDescriptor: group:cn=groups,cn=compat,dc=example,dc=com
>> serviceSearchDescriptor: netgroup:cn=ng,cn=compat,dc=example,dc=com
>> serviceSearchDescriptor: ethers:cn=computers,cn=accounts,dc=example,dc=com
>> serviceSearchDescriptor: automount:cn=default,cn=automount,dc=example,dc=com
>> serviceSearchDescriptor:
>> auto_master:automountMapName=auto.master,cn=defualt,cn=automount,dc=example,dc=com
>> serviceSearchDescriptor: aliases:ou=aliases,ou=test,dc=example,dc=com
>> serviceSearchDescriptor: printers:ou=printers,ou=test,dc=example,dc=com
>> 
>> ^D
>>
>>
>> You may want to check out
>> https://bugzilla.redhat.com/show_bug.cgi?id=815533 as well.
>>
> Should the profile be available anonymously? It is not in 4.x:
> $ ldapsearch -x -b ou=profile,dc=ipacloud,dc=test
> # extended LDIF
> #
> # LDAPv3
> # base  with scope subtree
> # filter: (objectclass=*)
> # requesting: ALL
> #
>
>
> # search result
> search: 2
> result: 0 Success
>
>
> # numResponses: 1
> $ kinit admin
> Password for ad...@ipacloud.test:
> $ ldapsearch -Y GSSAPI -b ou=profile,dc=ipacloud,dc=test
> SASL/GSSAPI authentication started
> SASL username: ad...@ipacloud.test
> SASL SSF: 56
> SASL data security layer installed.
> # extended LDIF
> #
> # LDAPv3
> # base  with scope subtree
> # filter: (objectclass=*)
> # requesting: ALL
> #
>
>
> # profile, ipacloud.test
> dn: ou=profile,dc=ipacloud,dc=test
> objectClass: top
> objectClass: organizationalUnit
> ou: profiles
> ou: profile
>
>

Re: [Freeipa-users] how can i create home directories automatically on solaris while IPA user login

[Sigbjorn Lie]

Hi,

Yes the DUA profile needs manually editing and updating as IPA servers are 
added or removed. Ideally this would be managed by ipa-replica-manage, however 
as I was advised in the BZ, Red Hat does not have the knowledge or resources to 
focus on integration with Solaris, which is understandable. :)

The DUA profile I’ve uploaded to the BZ is a copy (with server names edited), 
of the DUA profile I1ve used at several environments when configuring Solaris 
10 to work with IPA, so unless there are typos I haven’t discovered, it would 
work ok. :)

As for the auto mount, Linux uses “.” between auto and the map name, such as 
auto.master, auto.home, etc. And Solaris uses “_” between the auto and the map 
name, such as auto_master, auto_home.

This can be worked around in the DUA profile by adding a 
searchServiceDescriptor for each auto mounter map, such as 
"serviceSearchDescriptor: 
auto_master:automountMapName=auto.master,cn=defualt,cn=automount,dc=ix,dc=test,dc=com”.

What I found as the best middle ground here, was to keep the master name 
auto.master and have a serviceSearchDescriptor in the DUA profile for 
auto.master, and have the remaining maps in IPA with “_”as the separator. This 
works the best as Linux will look for auto.master by default, and be happy with 
the other maps being referred to with “_”as separator. Solaris seem to require 
that all the maps  use “_”as seperator, unless serviceSearchDescriptor entries 
are added for each map.

I hope this was what you we’re looking for?


Regards,
Siggi




> On 11 Mar 2015, at 19:39, Dmitri Pal  wrote:
> 
> Hello,
> 
> Is there any chance you can help this guy on the FreeIPA list?
> 
> Thanks
> Dmitri
> 
> 
>  Original Message 
> Subject:  Re: [Freeipa-users] how can i create home directories 
> automatically on solaris while IPA user login
> Date: Wed, 11 Mar 2015 21:22:02 +0300
> From: Ben .T.George  
> Reply-To: bentech4...@gmail.com 
> To:   dpal  
> CC:   freeipa-users  
> 
> 
> from BZ
> 
> "While
> we value your interest in IPA Solaris support, the
> implementation of the DUA profile is not on our nearest
> schedule at the moment. We lack both knowledge and resources
> to focus on integration with Solaris. This is where we need
> a help (ideally patches) and contribution from the community
> to help us push these features in.
> I checked your example DUAConfigProfile and I think it cannot be just added 
> to FreeIPA right away. E.g. for defaultServerList or preferredServerList, you 
> would need to expand installers and ipa-replica-manage to handle these lists 
> and update them when replica is added or updated to prevent it being 
> outdated. printers or aliases serviceSearchDescriptor refers to objects not 
> being available and so on. It is not as straightforward as it seems.
> 
> What I think that we can work on is to work together on
> http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html#Configuring_an_IPA_Client_on_Solaris_10
>  
> 
> ... and add all the steps needed to make IPA work on Solaris 10. I could for 
> example prepare an updated page and you could review it. Would that work for 
> you?"
> this what i followed util now. but's not authenticate with AD, IPA user can 
> login on solaris box
> 
> On Wed, Mar 11, 2015 at 9:11 PM, Dmitri Pal  > wrote:
> On 03/11/2015 01:56 PM, Ben .T.George wrote:
>> HI
>> 
>> yea , i saw that mail thread and he claims that he achieved somehow. but not 
>> clear.
>> 
>> and the  steps mentioned is too technical for me. :) as i am very new to IPA 
>> it's bit confusing. 
>> 
>> later that thread also closed without proper explanation. 
>> 
>> i think you guys can contact him to change existing wiki :) as there are 
>> many solaris related documents which is pretty old.
>> 
>> anyway still waiting for rply
> 
> Have you found the BZ? They are very detailed.
> https://bugzilla.redhat.com/show_bug.cgi?id=815515 
> 
> The DUA profile is attached to the bug.
> 
> 
>> 
>> Regards,
>> Ben
>> 
>> On Wed, Mar 11, 2015 at 8:49 PM, Dmitri Pal > > wrote:
>> On 03/11/2015 01:18 PM, Ben .T.George wrote:
>>> HI 
>>> 
>>> thanks for the rply.
>>> 
>>> even i tried native auto_master file with directory checking script. if i 
>>> feed the user manually to the script, the directory is creating and while 
>>> login request comes, it didn't.
>>> 
>>> i don't think no one did full solaris integration util now as i asked many 
>>> questions related to that.
>>> 
>>> now i am little bit confident up to this level. 

Re: [Freeipa-users] Does Solaris 11 work as client to IPA server?

[Sigbjorn Lie]

Cool. :)

What do you see if you turn on pam debugging by touching /etc/pam_debug and 
enabling debug logging in the syslog daemon?


Rgds
Siggi

Johan Petersson  wrote:

>Of course it was a simple thing like replacing auto.nethome with
>auto_nethome that worked.
>Thank you for that help!
>I did not even think that it was that simple. :)
>
>Now everything works for the more secure client configuration on
>Solaris 11.
>The only thing left to investigate is why there is a delay now for the
>IPA users.
>I get the message : Your Kerberos account/password will expire in 89
>days quickly but then it waits for about 20 seconds until i get a
>prompt.
>
>Regards,
>Johan.
>____
>From: Sigbjorn Lie [sigbj...@nixtra.com]
>Sent: Wednesday, December 26, 2012 17:10
>To: Johan Petersson
>Cc: freeipa-users@redhat.com
>Subject: RE: [Freeipa-users] Does Solaris 11 work as client to IPA
>server?
>
>What is the name of the other maps besides auto.master? You should use
>_ instead of . for any additional maps when you need Solaris autofs
>compatibility. This also need to be reflected in the auto.master.
>
>The Linux automounter does not care about . or _ as long as the naming
>is consistent between the additional maps and auto.master. The default
>for Linux is auto.master with a . and auto_master for Solaris. Hence
>the auto.master mapping in the Solaris dua profile.
>
>
>Rgds
>Siggi
>
>Johan Petersson  wrote:
>
>Got everything except automount to work with Solaris 11 and the more
>secure DUAProfile.
>Verified that i can manually mount with krb5 on Solaris 11, ssh, su and
>console login works (as well as expected with no home directory) and
>automount map works for Red Hat clients.
>I have now tried with another directory for users (/nethome) since when
>trying with /home autofs made local users unavailable. They are
>automounted locally to /home/ from /export/home/  on Solaris for some
>strange reason and autofs then tried finding local users home
>directories on the NFS Server :)
>
>root@solaris2:~# ldapclient list
>NS_LDAP_FILE_VERSION= 2.0
>NS_LDAP_BINDDN= uid=solaris,cn=sysaccounts,cn=etc,dc=example,dc=org
>NS_LDAP_BINDPASSWD= {XXX}XX
>NS_LDAP_SERVERS= server.example.org<http://server.example.org>
>NS_LDAP_SEARCH_BASEDN=
>dc=example,dc=org
>NS_LDAP_AUTH= tls:simple
>NS_LDAP_SEARCH_REF= TRUE
>NS_LDAP_SEARCH_SCOPE= one
>NS_LDAP_SEARCH_TIME= 10
>NS_LDAP_CACHETTL= 6000
>NS_LDAP_PROFILE= solaris_authssl1
>NS_LDAP_CREDENTIAL_LEVEL= proxy
>NS_LDAP_SERVICE_SEARCH_DESC=
>passwd:cn=users,cn=accounts,dc=example,dc=org
>NS_LDAP_SERVICE_SEARCH_DESC=
>group:cn=groups,cn=compat,dc=example,dc=org
>NS_LDAP_SERVICE_SEARCH_DESC= netgroup:cn=ng,cn=compat,dc=example,dc=org
>NS_LDAP_SERVICE_SEARCH_DESC=
>ethers:cn=computers,cn=accounts,dc=example,dc=org
>NS_LDAP_SERVICE_SEARCH_DESC=
>automount:cn=default,cn=automount,dc=example,dc=org
>NS_LDAP_SERVICE_SEARCH_DESC=
>auto_master:automountMapName=auto.master,cn=default,cn=automount,dc=example,dc=org
>NS_LDAP_SERVICE_SEARCH_DESC=
>aliases:ou=aliases,ou=test,dc=example,dc=org
>NS_LDAP_SERVICE_SEARCH_DESC=
>printers:ou=printers,ou=test,dc=example,dc=org
>NS_LDAP_BIND_TIME= 5
>NS_LDAP_OBJECTCLASSMAP=
>shadow:shadowAccount=posixAccount
>NS_LDAP_OBJECTCLASSMAP= printers:sunPrinter=printerService
>
>root@solaris2:~# sharectl get autofs
>timeout=600
>automount_verbose=true
>automountd_verbose=true
>nobrowse=false
>trace=2
>environment=
>
>From /var/svc/log/system-filesystem-autofs\:default.log:
>
>t4 LOOKUP REQUEST: Wed Dec 26 12:28:43 2012
>t4 name=user02[] map=auto.nethome opts= path=/nethome direct=0
>t4 getmapent_ldap called
>t4 getmapent_ldap: key=[ user02 ]
>t4 ldap_match called
>t4 ldap_match: key =[ user02 ]
>t4 ldap_match: ldapkey =[ user02 ]
>t4 ldap_match: Requesting list for
>(&(objectClass=automount)(automountKey=user02)) in auto.nethome
>t4 ldap_match: __ns_ldap_list FAILED (2)
>t4 ldap_match: no entries found
>t4 ldap_match called
>t4 ldap_match: key =[ \2a ]
>t4 ldap_match: ldapkey =[ \2a ]
>t4 ldap_match: Requesting list for
>(&(objectClass=automount)(automountKey=\2a)) in auto.nethome
>t4 ldap_match: __ns_ldap_list FAILED (2)
>t4 ldap_match: no entries found
>t4 getmapent_ldap: exiting ...
>t4 do_lookup1: action=2 wildcard=FALSE error=2
>t4 LOOKUP REPLY : status=2
>The automount map is called auto.nethome
>key is: * -rw,soft
>server.example.org<http://server.example.org>:/nethome/&
>
>Is it that Solaris automount dont like asterisk(*) in a automount key?
>
>Regards,
>Johan.
>
>
>From: Sigbjorn Lie [sigbj...@nixtra.com]
>

Re: [Freeipa-users] Does Solaris 11 work as client to IPA server?

[Sigbjorn Lie]

How about enabling the firewall, and use tcpdump on the ipa server or snoop on 
the Solaris box to see where it stops and waits? 


Rgds
Siggi

Johan Petersson  wrote:

>Forgot to add the ports opened in my last message. :)
>
>22 TCP
>80 TCP
>443 TCP
>389 TCP
>636 TCP
>7389 TCP
>88 TCP,UDP
>464 TCP,UDP
>53 TCP,UDP
>123 TCP,UDP
>111 TCP,UDP
>2049 TCP,UDP
>
>Also tried 749,750 and everything kerberos related from Solaris
>/etc/services.
>Solaris.example.com and solaris2.example.com is same machine, just typo
>from me when editing the log for publishing.
>
>Regards,
>Johan
>
>
>
>
>From: freeipa-users-boun...@redhat.com
>[freeipa-users-boun...@redhat.com] on behalf of Johan Petersson
>[johan.peters...@sscspace.com]
>Sent: Friday, December 28, 2012 13:40
>To: Sigbjorn Lie
>Cc: freeipa-users@redhat.com
>Subject: Re: [Freeipa-users] Does Solaris 11 work as client to IPA
>server?
>
>Hi,
>
>I am getting these messages in my log when setting all instances of
>pam_krb5.so.1 debug in /etc/pam.d/other, /etc/pam.d/login:
>
>Dec 28 12:59:12 solaris.example.com su: [ID 737709 auth.error] unable
>to open connection to ADMIN server (t_error 13)
>Dec 28 12:59:12 solaris2.example.com su: [ID 436431 auth.error]
>PAM-KRB5-AUTOMIGRATE (auth): Error while doing kadm5_init_with_skey:
>Communication failure with server
>
>If i disable the firewall on my IPA Server everything works as fast as
>it should so clearly a firewall issue with iptables.
>However, i have all the ports enabled and Red Hat clients works with
>the firewall on.
>Clearly Solaris is using some secret other port(s) that is not
>mentioned.
>I have tried with 749 and 750 tcp and udp with no difference.
>
>Regards,
>Johan.
>
>
>From: Sigbjorn Lie [sigbj...@nixtra.com]
>Sent: Wednesday, December 26, 2012 18:56
>To: Johan Petersson
>Cc: freeipa-users@redhat.com
>Subject: RE: [Freeipa-users] Does Solaris 11 work as client to IPA
>server?
>
>Cool. :)
>
>What do you see if you turn on pam debugging by touching /etc/pam_debug
>and enabling debug logging in the syslog daemon?
>
>
>Rgds
>Siggi
>
>Johan Petersson  wrote:
>Of course it was a simple thing like replacing auto.nethome with
>auto_nethome that worked.
>Thank you for that help!
>I did not even think that it was that simple. :)
>
>Now everything works for the more secure client configuration on
>Solaris 11.
>The only thing left to investigate is why there is a delay now for the
>IPA users.
>I get the message : Your Kerberos account/password will expire in 89
>days quickly but then it waits for about 20 seconds until i get a
>prompt.
>
>Regards,
>Johan.
>
>From: Sigbjorn Lie [sigbj...@nixtra.com]
>Sent: Wednesday, December 26, 2012 17:10
>To: Johan Petersson
>Cc: freeipa-users@redhat.com
>Subject: RE: [Freeipa-users] Does Solaris 11 work as client to IPA
>server?
>
>What is the name of the other maps besides auto.master? You should use
>_ instead of . for any additional maps when you need Solaris autofs
>compatibility. This also need to be reflected in the auto.master.
>
>The Linux automounter does not care about . or _ as long as the naming
>is consistent between the additional maps and auto.master. The default
>for Linux is auto.master with a . and auto_master for Solaris. Hence
>the auto.master mapping in the Solaris dua profile.
>
>
>Rgds
>Siggi
>
>Johan Petersson  wrote:
>
>Got everything except automount to work with Solaris 11 and the more
>secure DUAProfile.
>Verified that i can manually mount with krb5 on Solaris 11, ssh, su and
>console login works (as well as expected with no home directory) and
>automount map works for Red Hat clients.
>I have now tried with another directory for users (/nethome) since when
>trying with /home autofs made local users unavailable. They are
>automounted locally to /home/ from /export/home/  on Solaris for some
>strange reason and autofs then tried finding local users home
>directories on the NFS Server :)
>
>root@solaris2:~# ldapclient list
>NS_LDAP_FILE_VERSION= 2.0
>NS_LDAP_BINDDN= uid=solaris,cn=sysaccounts,cn=etc,dc=example,dc=org
>NS_LDAP_BINDPASSWD= {XXX}XX
>NS_LDAP_SERVERS= server.example.org<http://server.example.org>
>NS_LDAP_SEARCH_BAS
> EDN=
>dc=example,dc=org
>NS_LDAP_AUTH= tls:simple
>NS_LDAP_SEARCH_REF= TRUE
>NS_LDAP_SEARCH_SCOPE= one
>NS_LDAP_SEARCH_TIME= 10
>NS_LDAP_CACHETTL= 6000
>NS_LDAP_PROFILE= solaris_authssl1
>NS_LDAP_CREDENTIAL_LEVEL= proxy
>NS_LDAP_SERVICE_SEARCH_DESC=
>passwd:cn=users,cn=accounts,dc=example,dc=

Re: [Freeipa-users] re-sync passwords after migration from LDAP to IPA ?

[Sigbjorn Lie]

Try to browse the user again after you've authenticated using the directory 
manager account. 

Rgds
Siggi

Jan-Frode Myklebust  wrote:

>On Wed, Jan 2, 2013 at 4:11 PM, Dmitri Pal  wrote:
>> Would it be simpler and cleaner to start with a fresh install?
>
>
>Unfortunately some systems are already using IPA so I can't easily
>start fresh.. but yes, I can probably just delete the accounts with
>different LDAP password in IPA and OLD-system, and then do a new
>migration of these few.
>
>But... where do I find the LDAP passwords in IPA ? I see there's no
>"userPassword" attribute on each user as I was expecting.., so where
>is this hidden? And can it be compared against the SSHA from the old
>directory ?
>
>
> -jf
>
>___
>Freeipa-users mailing list
>Freeipa-users@redhat.com
>https://www.redhat.com/mailman/listinfo/freeipa-users

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] non-expiring password policy (or as close as I can come)

[Sigbjorn Lie]

On 01/24/2013 11:17 PM, KodaK wrote:

On Thu, Jan 24, 2013 at 4:03 PM, Rob Crittenden  wrote:

It is a 32-bit time problem.

I'd set the maxlife no higher than 5000 for now.


Thanks.  Is there a way to apply this policy retroactively without
requiring my users to reset passwords?



A calender will be shown to choose a date and time for simplicity if you 
download and use the Apache Directory Studio 
(http://directory.apache.org/studio/) to edit the krbPasswordExpiration 
attribute for an user account. It works well.




Regards,
Siggi

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

Re: [Freeipa-users] Testing out FreeIPA

[Sigbjorn Lie]

On 02/06/2013 09:47 PM, KodaK wrote:

On Wed, Feb 6, 2013 at 2:13 PM, Shawn  wrote:

Is their any centos5/centos6 packages available?


Yup.  yum search ipa should show you them.  I don't run Centos here,
so I don't know if the packages are called ipa or freeipa.



They are called ipa-*

Just do "yum install ipa-server" and you'll get all the required packages.


ipa-admintools-2.2.0-17.el6_3.1.x86_64
ipa-client-2.2.0-17.el6_3.1.x86_64
ipa-pki-ca-theme-9.0.3-7.el6.noarch
ipa-pki-common-theme-9.0.3-7.el6.noarch
ipa-python-2.2.0-17.el6_3.1.x86_64
ipa-server-2.2.0-17.el6_3.1.x86_64
ipa-server-selinux-2.2.0-17.el6_3.1.x86_64



Regards,
Siggi

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

Re: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC

[Sigbjorn Lie]

On 02/13/2013 04:10 PM, Rob Crittenden wrote:



Also since we also require compatibility with Solaris, and roles (RBAC)
is currently used on Solaris, does IPA support RBAC on Solaris ? (We
noticed that RBAC mentioned in the IPA web interface only relates to IPA
management).


No, IPA doesn't support RBAC on Solaris.



I've come across the same issue. This is just a matter of extending the 
schema.


Would there be any interest for adding the Solaris RBAC schema as a part 
of the standard IPA distributed LDAP schemas?




Regards,
Siggi


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

Re: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC

[Sigbjorn Lie]

I agree with schema support being enough for now. I do not expect the ipa mgmt 
tools to support Solaris rbac mgmt.

The ipa mgmt tools are great, but I already have other data in the ipa ldap 
that I have to manage manually anyway.



Rgds,
Siggi



Rob Crittenden  wrote:

>Dag Wieers wrote:
>> On Thu, 14 Feb 2013, Rob Crittenden wrote:
>>
>>> Sigbjorn Lie wrote:
>>>>  On 02/13/2013 04:10 PM, Rob Crittenden wrote:
>>>>
>>>> > >  Also since we also require compatibility with Solaris, and
>roles
>>>> > >  (RBAC)
>>>> > >  is currently used on Solaris, does IPA support RBAC on Solaris
>?
>>>> (We
>>>> > >  noticed that RBAC mentioned in the IPA web interface only
>>>> relates to > >  IPA
>>>> > >  management).
>>>> > >  No, IPA doesn't support RBAC on Solaris.
>>>>
>>>>  I've come across the same issue. This is just a matter of
>extending the
>>>>  schema.
>>>>
>>>>  Would there be any interest for adding the Solaris RBAC schema as
>a
>>>> part
>>>>  of the standard IPA distributed LDAP schemas?
>>>
>>> Is the schema enough? Won't people want a way from IPA to manage the
>>> data too?
>>
>> Of course, integration in IPA is better, but having the schema
>> integrated is a good first step. Besides, integration in IPA probably
>> won't happen without RBAC support in Fedora/RHEL, right ?
>>
>
>Right, and it is a bit beyond our scope to create a compatible RBAC 
>solution.
>
>rob

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC

[Sigbjorn Lie]

On 02/15/2013 03:17 PM, Rodney L. Mercer wrote:



On Thu, 2013-02-14 at 21:44 +0100, Sigbjorn Lie wrote:

I agree with schema support being enough for now. I do not expect the
ipa mgmt tools to support Solaris rbac mgmt.

The ipa mgmt tools are great, but I already have other data in the ipa
ldap that I have to manage manually anyway.



Rgds,
Siggi



Rob Crittenden  wrote:
 Dag Wieers wrote:
 On Thu, 14 Feb 2013, Rob Crittenden wrote:

 Sigbjorn Lie wrote:
 On 02/13/2013 04:10 PM, Rob Crittenden wrote:

 Also since we also require 
compatibility with Solaris, and roles
 (RBAC)
 is currently used on Solaris, 
does IPA support RBAC on Solar
  is ?
 (We
 noticed that RBAC mentioned in 
the IPA web interface only
 relates to > >  IPA
 management).
 No, IPA doesn't support RBAC 
on Solaris.

 I've come across the same issue. This is just 
a matter of extending the
 schema.

 Would there be any interest for adding the 
Solaris RBAC schema as a
 part
 of the standard IPA distributed LDAP schemas?



Consider the following: What else would have to be put in to support
this?
Once the schema is established, can SSSD be extended to use this and
potentially be referenced in nsswitch.conf as it is implemented on
Solaris? IE:
tail -5 /etc/nsswitch.conf
user_attr:  sssd
auth_attr:  sssd
prof_attr:  sssd
exec_attr:  sssd
project:sssd




Do you use SSSD on Solaris?

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

Re: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC

[Sigbjorn Lie]

On 02/15/2013 10:31 PM, Dmitri Pal wrote:

On 02/15/2013 09:17 AM, Rodney L. Mercer wrote:


On Thu, 2013-02-14 at 21:44 +0100, Sigbjorn Lie wrote:

I agree with schema support being enough for now. I do not expect the
ipa mgmt tools to support Solaris rbac mgmt.

The ipa mgmt tools are great, but I already have other data in the ipa
ldap that I have to manage manually anyway.



Rgds,
Siggi



Rob Crittenden  wrote:
 Dag Wieers wrote:
 On Thu, 14 Feb 2013, Rob Crittenden wrote:

 Sigbjorn Lie wrote:
 On 02/13/2013 04:10 PM, Rob Crittenden wrote:

 Also since we also require 
compatibility with Solaris, and roles
 (RBAC)
 is currently used on Solaris, 
does IPA support RBAC on Solar
  is ?
 (We
 noticed that RBAC mentioned in 
the IPA web interface only
 relates to > >  IPA
 management).
 No, IPA doesn't support RBAC 
on Solaris.

 I've come across the same issue. This is just 
a matter of extending the
 schema.

 Would there be any interest for adding the 
Solaris RBAC schema as a
 part
 of the standard IPA distributed LDAP schemas?


Consider the following: What else would have to be put in to support
this?
Once the schema is established, can SSSD be extended to use this and
potentially be referenced in nsswitch.conf as it is implemented on
Solaris? IE:
tail -5 /etc/nsswitch.conf
user_attr:  sssd
auth_attr:  sssd
prof_attr:  sssd
exec_attr:  sssd
project:sssd


Before we define how it is passed/exposed it would nice to understand
who on Linux will be consuming it out of SSSD?



I don't think Linux would consume these attributes. They are specific to 
the Role Based Access Control solution implemented in Solaris.



Rgds,
Siggi




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

[Freeipa-users] ipa: ERROR: attribute "idnsAllowTransfer" not allowed

[Sigbjorn Lie]

Hi,

I am trying to add a new DNS zone to our IPA server, but I receive the 
following error:

$ ipa dnszone-add example.com --name-server=ns01.example.com 
--admin-email=hostmaster.example.com
ipa: ERROR: attribute "idnsAllowTransfer" not allowed


I get the same error no matter if I attempt to add a forward or a reverse zone.

I am using IPA 2.2 on RHEL 6.3:

bind-9.8.2-0.10.rc1.el6_3.3.x86_64
bind-dyndb-ldap-1.1.0-0.9.b1.el6_3.1.x86_64
bind-libs-9.8.2-0.10.rc1.el6_3.3.x86_64
bind-utils-9.8.2-0.10.rc1.el6_3.3.x86_64
ipa-admintools-2.2.0-16.el6.x86_64
ipa-client-2.2.0-16.el6.x86_64
ipa-pki-ca-theme-9.0.3-7.el6.noarch
ipa-pki-common-theme-9.0.3-7.el6.noarch
ipa-python-2.2.0-16.el6.x86_64
ipa-server-2.2.0-16.el6.x86_64
ipa-server-selinux-2.2.0-16.el6.x86_64
krb5-libs-1.9-33.el6_3.3.x86_64
krb5-pkinit-openssl-1.9-33.el6_3.3.x86_64
krb5-server-1.9-33.el6_3.3.x86_64
krb5-server-ldap-1.9-33.el6_3.3.x86_64
krb5-workstation-1.9-33.el6_3.3.x86_64
selinux-policy-3.7.19-155.el6_3.4.noarch
selinux-policy-targeted-3.7.19-155.el6_3.4.noarch
slapi-nis-0.40-1.el6.x86_64


We do have several dns zones in IPA today, so this has worked earlier.

Is this a known error?


Regards,
Siggi


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

Re: [Freeipa-users] ipa: ERROR: attribute 'idnsAllowTransfer' not allowed

[Sigbjorn Lie]

On Mon, February 25, 2013 12:59, Christian Horn wrote:
> Hi,
>
>
> On Mon, Feb 25, 2013 at 09:46:49AM +0100, Sigbjorn Lie wrote:
>
>>
>> $ ipa dnszone-add example.com --name-server=ns01.example.com
>> --admin-email=hostmaster.example.com
>> ipa: ERROR: attribute "idnsAllowTransfer" not allowed
>>
>>
>> [..]
>>
>>
>> Is this a known error?
>>
>
> Yes,
> the idnsZone objectClass entry was not updated properly during ipa-server 
> update process. To fix
> this the schema has to be modified, 
> https://access.redhat.com/knowledge/solutions/301213 has
> the details.
>

Thank you. That worked just fine. :)


Regards,
Siggi


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

Re: [Freeipa-users] ipa: ERROR: attribute 'idnsAllowTransfer' not allowed

[Sigbjorn Lie]

Hi.

This is ipa 2.2 on rhel 6.3. Upgraded from rhel 6.2. Initial install on 6.2.


Rgds
Siggi


Martin Kosek  wrote:

>On 02/25/2013 03:38 PM, Sigbjorn Lie wrote:
>> On Mon, February 25, 2013 12:59, Christian Horn wrote:
>>> Hi,
>>>
>>>
>>> On Mon, Feb 25, 2013 at 09:46:49AM +0100, Sigbjorn Lie wrote:
>>>
>>>>
>>>> $ ipa dnszone-add example.com --name-server=ns01.example.com
>>>> --admin-email=hostmaster.example.com
>>>> ipa: ERROR: attribute "idnsAllowTransfer" not allowed
>>>>
>>>>
>>>> [..]
>>>>
>>>>
>>>> Is this a known error?
>>>>
>>>
>>> Yes,
>>> the idnsZone objectClass entry was not updated properly during
>ipa-server update process. To fix
>>> this the schema has to be modified,
>https://access.redhat.com/knowledge/solutions/301213 has
>>> the details.
>>>
>> 
>> Thank you. That worked just fine. :)
>> 
>> 
>> Regards,
>> Siggi
>> 
>
>Hi guys, I am glad you resolved the issue. I am just curious - from
>what
>version to what version did you upgrade? Is this is a bug in IPA in
>RHEL 6.4?
>
>Thank you,
>Martin

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Solaris 10 problem using netgroups

[Sigbjorn Lie]

Have you considered using allowgroups in sshd_config for restricting ssh logins 
instead?

By using allowgroups you could use the same user group for ssh access to 
Solaris and for Linux hosts using sssd and hbac.


Regards
Siggi

"Eli J. Elliott"  wrote:

>I have a problem with Solaris 10 and netgroups with IPA.
>
>I am able to login to the Solaris 10 server with IPA users as long as I
>am
>not using netgroups. As soon as I add a netgroup I can no longer
>authenticate.
>
>I have updated nsswitch.conf:
>
>#passwd: files ldap
>
>passwd: compat
>
>passwd_compat:  files ldap
>
>group:  files ldap
>
>
>And then added the netgroup to /etc/passwd:
>
>+@MYHOST:x:
>
>And used pwconv to get the netgroup into /etc/shadow:
>
>+@MYHOST:x:15765::
>
>I am able to see the user in getent (and none of the users I want
>restricted show up, only the user I want which is great):
>
>-bash-3.2# getent passwd testuser
>
>testuser:x:3713:3713:Test User:/export/home/testuser:/bin/bash
>
>** **
>
>I am also able to su to testuser as root:
>
>-bash-3.2# su - testuser
>
>Oracle Corporation  SunOS 5.10  Generic Patch   January
>2005
>
>-bash-3.2$ id
>
>uid=3713(testuser) gid=3713(testgroup)
>
>
>I cannot su to the user from another user, it appears to be the
>password
>that is the problem. I can successfully change passwords using kpasswd
>from
>the Solaris 10 host.
>
>
>I've enabled Pam debugging:
>
>
>Mar  1 12:54:04 MYHOST sshd[3928]: [ID 228857 auth.debug] PAM[3928]:
>pam_start(sshd-kbdint,testuser,80a98a8:80c8b18) - debug = 1
>
>Mar  1 12:54:04 MYHOST sshd[3928]: [ID 224148 auth.debug] PAM[3928]:
>pam_set_item(80c8b18:service)
>
>Mar  1 12:54:04 MYHOST sshd[3928]: [ID 224148 auth.debug] PAM[3928]:
>pam_set_item(80c8b18:user)
>
>Mar  1 12:54:04 MYHOST sshd[3928]: [ID 224148 auth.debug] PAM[3928]:
>pam_set_item(80c8b18:conv)
>
>Mar  1 12:54:04 MYHOST sshd[3928]: [ID 224148 auth.debug] PAM[3928]:
>pam_set_item(80c8b18:rhost)
>
>Mar  1 12:54:04 MYHOST sshd[3928]: [ID 224148 auth.debug] PAM[3928]:
>pam_set_item(80c8b18:tty)
>
>Mar  1 12:54:04 MYHOST sshd[3928]: [ID 122435 auth.debug] PAM[3928]:
>pam_authenticate(80c8b18, 1)
>
>Mar  1 12:54:04 MYHOST sshd[3928]: [ID 746646 auth.debug] PAM[3928]:
>load_modules(80c8b18,
>pam_sm_authenticate)=/usr/lib/security/pam_authtok_get.so.1
>
>Mar  1 12:54:04 MYHOST sshd[3928]: [ID 586621 auth.debug] PAM[3928]:
>load_function: successful load of pam_sm_authenticate
>
>Mar  1 12:54:04 MYHOST sshd[3928]: [ID 746646 auth.debug] PAM[3928]:
>load_modules(80c8b18,
>pam_sm_authenticate)=/usr/lib/security/pam_dhkeys.so.1
>
>
>Mar  1 12:54:04 MYHOST sshd[3928]: [ID 586621 auth.debug] PAM[3928]:
>load_function: successful load of pam_sm_authenticate
>
>Mar  1 12:54:04 MYHOST sshd[3928]: [ID 746646 auth.debug] PAM[3928]:
>load_modules(80c8b18,
>pam_sm_authenticate)=/usr/lib/security/pam_unix_cred.so.1
>
>Mar  1 12:54:04 MYHOST sshd[3928]: [ID 586621 auth.debug] PAM[3928]:
>load_function: successful load of pam_sm_authenticate
>
>Mar  1 12:54:04 MYHOST sshd[3928]: [ID 746646 auth.debug] PAM[3928]:
>load_modules(80c8b18,
>pam_sm_authenticate)=/usr/lib/security/pam_unix_auth.so.1
>
>Mar  1 12:54:04 MYHOST sshd[3928]: [ID 586621 auth.debug] PAM[3928]:
>load_function: successful load of pam_sm_authenticate
>
>Mar  1 12:54:04 MYHOST sshd[3928]: [ID 746646 auth.debug] PAM[3928]:
>load_modules(80c8b18,
>pam_sm_authenticate)=/usr/lib/security/pam_ldap.so.1**
>**
>
>Mar  1 12:54:04 MYHOST sshd[3928]: [ID 586621 auth.debug] PAM[3928]:
>load_function: successful load of pam_sm_authenticate
>
>Mar  1 12:54:04 MYHOST sshd[3928]: [ID 425581 auth.debug] PAM[3928]:
>pam_get_user(80c8b18, 80c8b18, NULL)
>
>Mar  1 12:54:07 MYHOST sshd[3928]: [ID 224148 auth.debug] PAM[3928]:
>pam_set_item(80c8b18:authtok)
>
>Mar  1 12:54:07 MYHOST last message repeated 1 time
>
>Mar  1 12:54:07 MYHOST sshd[3928]: [ID 117705 auth.debug] PAM[3928]:
>pam_authenticate(80c8b18, 1): error Authentication failed
>
>Mar  1 12:54:08 MYHOST sshd[3928]: [ID 224148 auth.debug] PAM[3928]:
>pam_set_item(80c8b18:authtok)
>
>Mar  1 12:54:08 MYHOST sshd[3928]: [ID 800047 auth.info]
>Keyboard-interactive (PAM) userauth failed[9] while authenticating:
>Authentication failed
>
>Mar  1 12:54:08 MYHOST sshd[3928]: [ID 800047 auth.notice] Failed
>keyboard-interactive for testuser from 30.241.208.21 port 4469 ssh2
>
>Mar  1 12:54:08 MYHOST sshd[3928]: [ID 224148 auth.debug] PAM[3928]:
>pam_set_item(80c8b18:conv)
>
>Mar  1 12:54:08 MYHOST sshd[3928]: [ID 185624 auth.debug] PAM[3928]:
>pam_end(80c8b18): status = Authentication failed
>
>Mar  1 12:54:08 MYHOST sshd[3928]: [ID 228857 auth.debug] PAM[3928]:
>pam_start(sshd-kbdint,testuser,80a98a8:80c8b18) - debug = 1
>
>Mar  1 12:54:08 MYHOST sshd[3928]: [ID 224148 auth.debug] PAM[3928]:
>pam_set_item(80c8b18:service)
>
>Mar  1 12:54:08 MYHOST sshd[3928]: [ID

Re: [Freeipa-users] Solaris 10 problem using netgroups

[Sigbjorn Lie]

I've had some similar issues with logins and netgroups on Solaris with 
IPA, I don't recall the details, sorry. We moved to AllowGroups in sshd 
instead.


You don't need sssd to use AllowGroups with sshd. Have a look at the 
sshd_config manpage for how to set it up.




Regards,
Siggi


On 03/04/2013 04:39 PM, Eli J. Elliott wrote:

I don't see being able to install sssd on the solaris hosts due to
security restrictions. I had read about using the hosts.allow file to
restrict to netgroups but was concerned about logging in with local
accounts. Wish I could wrap my head around what is changing when I add
the passwd_compat to nsswitch. Why would it suddenly stop
authenticating? It still sees the ldap users.

-E

On Fri, Mar 1, 2013 at 4:48 PM, Sigbjorn Lie mailto:sigbj...@nixtra.com>> wrote:

Have you considered using allowgroups in sshd_config for restricting
ssh logins instead?

By using allowgroups you could use the same user group for ssh
access to Solaris and for Linux hosts using sssd and hbac.


Regards
Siggi

"Eli J. Elliott" mailto:eli.elli...@moser-inc.com>> wrote:

I have a problem with Solaris 10 and netgroups with IPA.

I am able to login to the Solaris 10 server with IPA users as
long as I am not using netgroups. As soon as I add a netgroup I
can no longer authenticate.

I have updated nsswitch.conf:

#passwd: files ldap

passwd: compat

passwd_compat:  files ldap

group:  files ldap


And then added the netgroup to /etc/passwd:

+@MYHOST:x:


And used pwconv to get the netgroup into /etc/shadow:

+@MYHOST:x:15765::


I am able to see the user in getent (and none of the users I
want restricted show up, only the user I want which is great):

-bash-3.2# getent passwd testuser

testuser:x:3713:3713:Test User:/export/home/testuser:/bin/bash

__ __

I am also able to su to testuser as root:

-bash-3.2# su - testuser

Oracle Corporation  SunOS 5.10  Generic Patch   January
2005

-bash-3.2$ id

uid=3713(testuser) gid=3713(testgroup)


I cannot su to the user from another user, it appears to be the
password that is the problem. I can successfully change
passwords using kpasswd from the Solaris 10 host.


I've enabled Pam debugging:


Mar  1 12:54:04 MYHOST sshd[3928]: [ID 228857 auth.debug]
PAM[3928]: pam_start(sshd-kbdint,testuser,80a98a8:80c8b18) -
debug = 1

Mar  1 12:54:04 MYHOST sshd[3928]: [ID 224148 auth.debug]
PAM[3928]: pam_set_item(80c8b18:service)

Mar  1 12:54:04 MYHOST sshd[3928]: [ID 224148 auth.debug]
PAM[3928]: pam_set_item(80c8b18:user)

Mar  1 12:54:04 MYHOST sshd[3928]: [ID 224148 auth.debug]
PAM[3928]: pam_set_item(80c8b18:conv)

Mar  1 12:54:04 MYHOST sshd[3928]: [ID 224148 auth.debug]
PAM[3928]: pam_set_item(80c8b18:rhost)

Mar  1 12:54:04 MYHOST sshd[3928]: [ID 224148 auth.debug]
PAM[3928]: pam_set_item(80c8b18:tty)

Mar  1 12:54:04 MYHOST sshd[3928]: [ID 122435 auth.debug]
PAM[3928]: pam_authenticate(80c8b18, 1)

Mar  1 12:54:04 MYHOST sshd[3928]: [ID 746646 auth.debug]
PAM[3928]: load_modules(80c8b18,
pam_sm_authenticate)=/usr/lib/security/pam_authtok_get.so.1

Mar  1 12:54:04 MYHOST sshd[3928]: [ID 586621 auth.debug]
PAM[3928]: load_function: successful load of pam_sm_authenticate

Mar  1 12:54:04 MYHOST sshd[3928]: [ID 746646 auth.debug]
PAM[3928]: load_modules(80c8b18,
pam_sm_authenticate)=/usr/lib/security/pam_dhkeys.so.1

Mar  1 12:54:04 MYHOST sshd[3928]: [ID 586621 auth.debug]
PAM[3928]: load_function: successful load of pam_sm_authenticate

Mar  1 12:54:04 MYHOST sshd[3928]: [ID 746646 auth.debug]
PAM[3928]: load_modules(80c8b18,
pam_sm_authenticate)=/usr/lib/security/pam_unix_cred.so.1

Mar  1 12:54:04 MYHOST sshd[3928]: [ID 586621 auth.debug]
PAM[3928]: load_function: successful load of pam_sm_authenticate

Mar  1 12:54:04 MYHOST sshd[3928]: [ID 746646 auth.debug]
PAM[3928]: load_modules(80c8b18,
pam_sm_authenticate)=/usr/lib/security/pam_unix_auth.so.1

Mar  1 12:54:04 MYHOST sshd[3928]: [ID 586621 auth.debug]
PAM[3928]: load_function: successful load of pam_sm_authenticate

Mar  1 12:54:04 MYHOST sshd[3928]: [ID 746646 auth.debug]
PAM[3928]: load_modules(80c8b18,
pam_sm_authenticate)=/usr/lib/security/pam_ldap.so.1

Mar  1 12:54:04 MYHOST sshd[3928]: [ID 586621 auth.debug]
PAM[3928]: load_function: successful load of pam_sm_authenticat

Re: [Freeipa-users] User admins for different groups

[Sigbjorn Lie]

On Fri, March 29, 2013 19:10, Dmitri Pal wrote:
> On 03/28/2013 05:11 AM, Petr Spacek wrote:
>
>> On 28.3.2013 09:38, Philipp Richter wrote:
>>
>>> Am 26.03.2013 um 16:55 schrieb Rob Crittenden :
>>>
>>>
 Petr Spacek wrote:

> On 26.3.2013 15:10, Rob Crittenden wrote:
>
>> Philipp Richter wrote:
>>
>>> On 03/26/2013 12:39 AM, Dmitri Pal wrote:
>>>
>>>
> I am trying to do the following:
>
>
> We have some branch offices at different locations. We want to use
> one ipa-server with replicas in each branch office. Each branch 
> office should have
> it's own set of administrators who should be able to 
> create/modify/delete users for
> its own branch but should not be allowed to change users from other 
> branches. every
> member of admin-at should be forced to create/modify/delete only 
> users in
> branch-at. The same applies for admin-us/branch-us.
>
> at first, i thought of a combination of (a) new role(s), with 
> write/delete
> permissions set for the branch-at group, as well as an automember 
> rule but it seems
> there is no way to filter for the creator of an entry, which would be 
> needed for
> the group membership..
>
> am i missing anything?

 This might help
 https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html-singl
 e/Identity_Management_Guide/index.html#delegating-users

>>>
>>> Yes, I read the whole document but as far as I understand
>>> delegates are only helpful for editing existing records. I want admins 
>>> of one branch to
>>> be able the also create users, but only in the assigned branch.
>>>
>>> Currently we use standard openldap with different ou's for the
>>> branches. Each branch admin has full ldap permissions for it's own 
>>> ou-subtree.
>>>
>>
>> IPA uses a flat DIT so here is no way to control adding users in a
>> given branch office.
>>
>> The most you'd be able to do is delegae management (delete/modify) a
>> subset of users who are members of a group that represents that branch 
>> office. Any new
>> users added would need to be added to the appropriate branch group by 
>> the admin adding
>> them.
>
> This sounds like big deficiency to me...
> Is it possible to hack automember plugin to enforce some group
> assignment based on creator's group/name as proposed above? It should 
> allow users to
> prepare some hand crafted ACIs, I guess.
>
> (Sorry, I don't have any knowledge about automember internals :-)
>

 Using automember doesn't prevent an admin from adding a user outside
 of the branch. It would just automatically assign that new user to the 
 correct branch based
 on the automember rules AND assuming that the admin that added the user 
 included the right
 information for the rules.

 ACIs control add at the subtree level, so for us it is a binary.
 Either you can add users or you can't.

>>>
>>> In our current ldap implementation (openldap) there are some
>>> attributes which are implicitly set. I think these are 
>>> creation/modification time and creator's
>>> name. So if these attributes would exist in ipa one could set up automember 
>>> rules based on the
>>>  creators name.
>>>
>>> Is there a way to switch such attributes on?
>>>
>>
>> creatorsname is present, but is not returned from search if you didn't 
>> require it explicitly:
>>
>> $ ldapsearch -Y GSSAPI 'creatorsname'
>> [...]
>> creatorsname: uid=admin,cn=users,cn=accounts,dc=example,dc=com
>>
>>
>
> So does that mean that automembership plugin can be configured to place
> users into the right groups based on the value of this attribute? That would 
> be really awesome!
>
>

It looks like that works just fine! I've been looking for a solution for this 
too! Awesome! :)

ipa automember-add-condition usergroupname 
--inclusive-regex="uid=creatorusername.*"
--key=creatorsname --type=group

Added condition(s) to "usergroupname"

  Automember Rule: usergroupname
  Inclusive Regex: creatorsname=uid=creatorusername.*


# ipa user-add atest2
---snip---

# ipa group-show usergroupname
  Group name: usergroupname
  Description: Created by creatorsname
  Member users: atest2


Is there any reason not to use the creatorsname attribute? Is there a reason it 
does not exist as
a selectable key in the webui?



Rgds,
Siggi



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

Re: [Freeipa-users] kinit seg-fault for Solaris 9

[Sigbjorn Lie]

Hi,

Do you have the Solaris Encryption Kit installed? I believe you need this to 
gain any more
encryption than DES on pre-Solaris 10. Even the early Solaris 10 releases were 
delivered without
proper crypto by default.

We have a few Solaris 8 hosts where I had to limit the number of enctypes in 
the hosts keytab
before it would work.



Regards,
Siggi




On Wed, March 27, 2013 17:56, David Redmond wrote:
> I've done 1,2,3 many times. 4 always fails.
>
>
> I realize you didn't ask for the info about allow_weak_crypto. I included
> it because it seems to me that it's a telling bit of info.
>
> On Wed, Mar 27, 2013 at 9:50 AM, Simo Sorce  wrote:
>
>
>> I didn't ask to run ipa-getkeytab,
>> can you do the following:
>>
>> 1. login to a linux client
>> 2. change the user password as an admin
>> 3. kinit as the user (and perform the password change as it will be
>> requested) 4. go to the solaris box and now try the kinit using the new 
>> password
>>
>>
>> Does step 4 work if you do 1,2,3 ?
>> Or does it keep segfaulting ?
>>
>>
>>
>>
>> The difference when allow_weak_crypto is false is that des keys are not
>> produced, so an AS REQ reply will return to the client with a list of 
>> encryption types that do
>> not include des as a valid algorithm.
>>
>> Maybe your kinit client is choking on that ?
>>
>>
>> You can change the default encryption types used to generate new
>> password, (changing allow_weak_crypto is not sufficient for that) in FreeIPA 
>> by adding the
>> desired enctypes in the krbDefaultEncSaltTypes multivalued attribute in 
>> entry named:
>> cn=,cn=Kerberos,
>>
>> The current defaults for new installs do *not* include DES as it is a
>> broken algorithm for security at this point.
>>
>>
>> Simo.
>>
>>
>> On Wed, 2013-03-27 at 09:36 -0700, David Redmond wrote:
>>
>>> I run the ipa-getkeytab command as the user I'm changing the password
>>> for.
>>>
>>> New info: On the server, in my /etc/krb5.conf file I have
>>> "allow_weak_crypto = true". If I remove that from the file, changing
>>> the password via ipa-getkeytab no longer works. The kinit command on the 
>>> Solaris client results
>>> in a segmentation fault. When I put "allow_weak_crypto = true" back into 
>>> the krb5.conf file
>>> and change the password via ipa-getkeytab the kinit command on the Solaris 
>>> client works
>>> normally.
>>>
>>> The ipa-getkeytab command must somehow be referencing
>>> "allow_weak_crypto" and storing the password differently depending on
>>> it.
>>>
>>> On Wed, Mar 27, 2013 at 5:51 AM, Simo Sorce  wrote:
>>> On Wed, 2013-03-27 at 12:23 +0100, Sumit Bose wrote:
>>>
>
> I did (as admin@REALM user). But we hardcode
>
>>> root/admin@REALM if
 this is
> administrative change:
>
> ipapwd_chpwop():
> ...
> if (pwdata.changetype == IPA_CHANGETYPE_NORMAL) { principal =
>>> slapi_entry_attr_get_charptr(pwdata.target,
>
 "krbPrincipalName");

> } else {
> principal = slapi_ch_smprintf("root/admin@%s",
 krbcfg->realm);
> }
> ...
>
>
> Maybe the root cause of the crash is that we place there a
>
>>> principal
> (root/admin@REALM) which does not exist. But this is just
>
>>> a
 speculation.

 ok, the principal is odd, and I guess this should be fixed,
>>> but maybe
 Simo knows some more history here. But nevertheless I think

>>> it is
 unrelated to the crash, becaus afaik this information is not
>>> send to
 the client and only used for book-keeing and auditing on the
>>> server side.

>>>
>>> I don't recall the root/admin story, looks odd to me, but
>>> nothing of this matter to a *client* segfaulting.
>>>
>>> Clients do not get access to this data this is purely internal
>>> metadata used by kadmin and the KDC.
>>>
>>> What I wonder is if the client is segfaulting when the
>>> password is expired due to a bug in handling the request to immediately 
>>> change the password ?
>>>
>>> David,
>>> if you kinit on a Linux machine and make sure you properly change the 
>>> password of the user (as
>>> the user no as an admin), and then kinit again with the new credentials on 
>>> Solaris, does it
>>> 'solve' your
>>> segfault issue ?
>>>
>>> In any case a segfault in a client command is something you
>>> need to report to your OS vendor, even if it is indirectly caused by the 
>>> server it shows a
>>> potential attack vector and it is particularly worrying in something like 
>>> kinit that may be run
>>> as root on a box.
>>>
>>> Simo.
>>>
>>>
>>> --
>>> Simo Sorce * Red Hat, Inc * New York
>>>
>>>
>>>
>>
>>
>> --
>> Simo Sorce * Red Hat, Inc * New York
>>
>>
>>
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users


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

Re: [Freeipa-users] User admins for different groups

[Sigbjorn Lie]

On Fri, March 29, 2013 22:25, Dmitri Pal wrote:
> On 03/29/2013 02:59 PM, Sigbjorn Lie wrote:
>
>>
>>
>> On Fri, March 29, 2013 19:10, Dmitri Pal wrote:
>>
>>> On 03/28/2013 05:11 AM, Petr Spacek wrote:
>>>
>>>
>>>> On 28.3.2013 09:38, Philipp Richter wrote:
>>>>
>>>>
>>>>> Am 26.03.2013 um 16:55 schrieb Rob Crittenden :
>>>>>
>>>>>
>>>>>
>>>>>> Petr Spacek wrote:
>>>>>>
>>>>>>
>>>>>>> On 26.3.2013 15:10, Rob Crittenden wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Philipp Richter wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> On 03/26/2013 12:39 AM, Dmitri Pal wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> I am trying to do the following:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> We have some branch offices at different locations. We want to use
>>>>>>>>>>> one ipa-server with replicas in each branch office. Each branch 
>>>>>>>>>>> office should
>>>>>>>>>>> have it's own set of administrators who should be able to 
>>>>>>>>>>> create/modify/delete
>>>>>>>>>>> users for its own branch but should not be allowed to change users 
>>>>>>>>>>> from other
>>>>>>>>>>> branches. every member of admin-at should be forced to 
>>>>>>>>>>> create/modify/delete
>>>>>>>>>>> only users in branch-at. The same applies for admin-us/branch-us.
>>>>>>>>>>>
>>>>>>>>>>> at first, i thought of a combination of (a) new role(s), with 
>>>>>>>>>>> write/delete
>>>>>>>>>>> permissions set for the branch-at group, as well as an automember 
>>>>>>>>>>> rule but it
>>>>>>>>>>> seems there is no way to filter for the creator of an entry, which 
>>>>>>>>>>> would be
>>>>>>>>>>> needed for the group membership..
>>>>>>>>>>>
>>>>>>>>>>> am i missing anything?
>>>>>>>>>> This might help
>>>>>>>>>> https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html-s
>>>>>>>>>> ingl e/Identity_Management_Guide/index.html#delegating-users
>>>>>>>>>>
>>>>>>>>> Yes, I read the whole document but as far as I understand
>>>>>>>>> delegates are only helpful for editing existing records. I want 
>>>>>>>>> admins of one
>>>>>>>>> branch to be able the also create users, but only in the assigned 
>>>>>>>>> branch.
>>>>>>>>>
>>>>>>>>> Currently we use standard openldap with different ou's for the
>>>>>>>>> branches. Each branch admin has full ldap permissions for it's own 
>>>>>>>>> ou-subtree.
>>>>>>>>>
>>>>>>>> IPA uses a flat DIT so here is no way to control adding users in a
>>>>>>>> given branch office.
>>>>>>>>
>>>>>>>> The most you'd be able to do is delegae management (delete/modify) a
>>>>>>>> subset of users who are members of a group that represents that branch 
>>>>>>>> office. Any
>>>>>>>> new users added would need to be added to the appropriate branch group 
>>>>>>>> by the admin
>>>>>>>> adding them.
>>>>>>> This sounds like big deficiency to me...
>>>>>>> Is it possible to hack automember plugin to enforce some group
>>>>>>> assignment based on creator's group/name as proposed above? It should 
>>>>>>> allow users to
>>>>>>> prepare some hand crafted ACIs, I guess.
>>>>>>

[Freeipa-users] Auto discover of the IPA server failing with LDAP anonymous binds off

[Sigbjorn Lie]

Hi,

I am trying to install the IPA client on a CentOS 6.4 host, however the 
auto discovery of the IPA server is failing, from what seem to be caused 
by my IPA servers having anonymous binds switched off.


Is this expected behaviour?


# rpm -qa|grep ^ipa|sort
ipa-client-3.0.0-26.el6_4.2.x86_64
ipa-python-3.0.0-26.el6_4.2.x86_64


# ipa-client-install -U --domain=unix.nuexample.com 
--password='somepassword' --enable-dns-updates -d
/usr/sbin/ipa-client-install was invoked with options: {'domain': 
'unix.nuexample.com', 'force': False, 'krb5_offline_passwords': True, 
'primary': False, 'mkhomedir': False, 'create_sshfp': True, 'conf_sshd': 
True, 'on_master': False, 'conf_ntp': True, 'ca_cert_file': None, 
'ntp_server': None, 'principal': None, 'hostname': None, 'no_ac': False, 
'unattended': True, 'sssd': True, 'trust_sshfp': False, 'dns_updates': 
True, 'realm_name': None, 'conf_ssh': True, 'server': None, 
'prompt_password': False, 'permit': False, 'debug': True, 
'preserve_sssd': False, 'uninstall': False}

missing options might be asked for interactively later
Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index'
Loading StateFile from '/var/lib/ipa-client/sysrestore/sysrestore.state'
[IPA Discovery]
Starting IPA discovery with domain=unix.nuexample.com, servers=None, 
hostname=clienthost.unix.nuexample.com

Search for LDAP SRV record in unix.nuexample.com
Search DNS for SRV record of _ldap._tcp.unix.nuexample.com.
DNS record found: 
DNSResult::name:_ldap._tcp.unix.nuexample.com.,type:33,class:1,rdata={priority:0,port:389,weight:100,server:ipa01.unix.nuexample.com.}
DNS record found: 
DNSResult::name:_ldap._tcp.unix.nuexample.com.,type:33,class:1,rdata={priority:0,port:389,weight:100,server:ipa02.unix.nuexample.com.}
DNS record found: 
DNSResult::name:_ldap._tcp.unix.nuexample.com.,type:33,class:1,rdata={priority:5,port:389,weight:100,server:ipa03.unix.nuexample.com.}

[Kerberos realm search]
Search DNS for TXT record of _kerberos.unix.nuexample.com.
DNS record found: 
DNSResult::name:_kerberos.unix.nuexample.com.,type:16,class:1,rdata={data:UNIX.NUEXAMPLE.COM}

Search DNS for SRV record of _kerberos._udp.unix.nuexample.com.
DNS record found: 
DNSResult::name:_kerberos._udp.unix.nuexample.com.,type:33,class:1,rdata={priority:0,port:88,weight:100,server:ipa02.unix.nuexample.com.}
DNS record found: 
DNSResult::name:_kerberos._udp.unix.nuexample.com.,type:33,class:1,rdata={priority:5,port:88,weight:100,server:ipa03.unix.nuexample.com.}
DNS record found: 
DNSResult::name:_kerberos._udp.unix.nuexample.com.,type:33,class:1,rdata={priority:0,port:88,weight:100,server:ipa01.unix.nuexample.com.}

[LDAP server check]
Verifying that ipa01.unix.nuexample.com (realm UNIX.NUEXAMPLE.COM) is an 
IPA server

Init LDAP connection with: ldap://ipa01.unix.nuexample.com:389
Search LDAP server for IPA base DN
Check if naming context 'dc=unix,dc=nuexample,dc=com' is for IPA
Naming context 'dc=unix,dc=nuexample,dc=com' is a valid IPA context
Search for (objectClass=krbRealmContainer) in 
dc=unix,dc=nuexample,dc=com (sub)

LDAP Error: Anonymous access not allowed
Discovery result: NO_ACCESS_TO_LDAP; server=None, 
domain=unix.nuexample.com, 
kdc=ipa02.unix.nuexample.com,ipa03.unix.nuexample.com,ipa01.unix.nuexample.com, 
basedn=dc=unix,dc=nuexample,dc=com

Validated servers: ipa01.unix.nuexample.com
will use discovered domain: unix.nuexample.com
IPA Server not found
Unable to find IPA Server to join
Installation failed. Rolling back changes.
IPA client is not configured on this system.




Regards,
Siggi

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

[Freeipa-users] ipa-client-automount - Unknown line format /etc/nsswitch.conf

[Sigbjorn Lie]

Hi,

I am having some issues with the new ipa-client-automount utility. It 
complains that my nsswitch.conf is in an unknown format. Not sure what 
format that is?


ipa-client-automount  --location=svg1 -U
Searching for IPA server...
IPA server: DNS discovery
Location: svg1
Installation failed. Rolling back changes.
Restoring configuration


 ipa-client-automount  --location=svg1 -U --debug
snip--
stderr=
args=keyctl pupdate 151012975
stdout=
stderr=
Backing up system configuration file '/etc/nsswitch.conf'
Saving Index File to '/var/lib/ipa-client/sysrestore/sysrestore.index'
Raised exception Syntax Error: Unknown line format
Installation failed. Rolling back changes.
Restoring configuration
Restoring system configuration file '/etc/nsswitch.conf'
args=/usr/sbin/selinuxenabled
stdout=
stderr=
Saving Index File to '/var/lib/ipa-client/sysrestore/sysrestore.index'



My nsswitch.conf file:
passwd: files sss
group:  files sss
shadow: files sss

hosts:  files dns
ipnodes:files dns
networks:   files

protocols:  db files
services:   files sss
rpc:db files
ethers:files ldap
netmasks:   files
bootparamsfiles
aliases:files ldap
printers:files

netgroup: files sss
automount: files

sudoers:files ldap



Regards,
Siggi


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

Re: [Freeipa-users] ipa-client-automount - Unknown line format /etc/nsswitch.conf

[Sigbjorn Lie]

On 04/06/2013 08:49 PM, Dmitri Pal wrote:

On 04/06/2013 01:45 PM, Sigbjorn Lie wrote:

Hi,

I am having some issues with the new ipa-client-automount utility. It
complains that my nsswitch.conf is in an unknown format. Not sure what
format that is?

ipa-client-automount  --location=svg1 -U
Searching for IPA server...
IPA server: DNS discovery
Location: svg1
Installation failed. Rolling back changes.
Restoring configuration


  ipa-client-automount  --location=svg1 -U --debug
snip--
stderr=
args=keyctl pupdate 151012975
stdout=
stderr=
Backing up system configuration file '/etc/nsswitch.conf'
Saving Index File to '/var/lib/ipa-client/sysrestore/sysrestore.index'
Raised exception Syntax Error: Unknown line format
Installation failed. Rolling back changes.
Restoring configuration
Restoring system configuration file '/etc/nsswitch.conf'
args=/usr/sbin/selinuxenabled
stdout=
stderr=
Saving Index File to '/var/lib/ipa-client/sysrestore/sysrestore.index'



My nsswitch.conf file:
passwd: files sss
group:  files sss
shadow: files sss

hosts:  files dns
ipnodes:files dns
networks:   files

protocols:  db files
services:   files sss
rpc:db files
ethers:files ldap
netmasks:   files
bootparamsfiles

I do not know whether it is the reason but this line misses a column
after "bootparams".



You are absolutely correct! It was a typo in there. :)

It's working just fine now.

Thanks.



Regards,
Siggi

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

Re: [Freeipa-users] bit OT: trouble getting nfsv4 with kerberos with ipa and opensolaris

[Sigbjorn Lie]

Your syntax seem correct but you need to quote the value.

Natxo Asenjo  wrote:

>hi,
>
>apparently what I am trying to do is not very usual because I do not
>get
>any answer on the omnios (opensolaris derivative) mailing list.
>
>I have successfully joined a host to the ipa domain, I can log in the
>omnios host as an ipa user, getent works, kerberos works (thanks to
>Johan
>Petersson in this thread:
>https://www.redhat.com/archives/freeipa-users/2013-January/msg00021.html)
>
>But when configuring nfs with krb5(i/p) security I get an error:
>
># zfs set sharenfs=sec=krb5 rpool/export/home
>cannot set property for 'rpool/export/home': 'sharenfs' cannot be set
>to
>invalid options
>
># share -F nfs -o sec=krb5 -d "homedirs" /export/home/
>Could not share: /export/home: invalid security type
>
>The omnios host has a keytab with both host and nfs principals:
>
># klist -k -e
>
>Keytab name: FILE:/etc/krb5/krb5.keytab
>KVNO Principal
>
>--
>   1 nfs/testomnios.ipa.asenjo...@ipa.asenjo.nx (AES-256 CTS mode with
>96-bit SHA-1 HMAC)
>   1 nfs/testomnios.ipa.asenjo...@ipa.asenjo.nx (AES-128 CTS mode with
>96-bit SHA-1 HMAC)
> 1 nfs/testomnios.ipa.asenjo...@ipa.asenjo.nx (Triple DES cbc mode with
>HMAC/sha1)
>   1 nfs/testomnios.ipa.asenjo...@ipa.asenjo.nx (ArcFour with HMAC/md5)
>   2 host/testomnios.ipa.asenjo...@ipa.asenjo.nx (AES-256 CTS mode with
>96-bit SHA-1 HMAC)
>   2 host/testomnios.ipa.asenjo...@ipa.asenjo.nx (AES-128 CTS mode with
>96-bit SHA-1 HMAC)
>2 host/testomnios.ipa.asenjo...@ipa.asenjo.nx (Triple DES cbc mode with
>HMAC/sha1)
>  2 host/testomnios.ipa.asenjo...@ipa.asenjo.nx (ArcFour with HMAC/md5)
>
>I can kinit with both principals:
>
>root@testomnios:~# kinit -k
>root@testomnios:~# klist
>Ticket cache: FILE:/tmp/krb5cc_0
>Default principal: host/testomnios.ipa.asenjo...@ipa.asenjo.nx
>
>Valid startingExpiresService principal
>04/12/13 11:56:07  04/13/13 11:56:07 
>krbtgt/ipa.asenjo...@ipa.asenjo.nx
>renew until 04/19/13 11:56:07
>root@testomnios:~# kinit -k nfs/testomnios.ipa.asenjo.nx
>root@testomnios:~# klist
>Ticket cache: FILE:/tmp/krb5cc_0
>Default principal: nfs/testomnios.ipa.asenjo...@ipa.asenjo.nx
>
>Valid startingExpiresService principal
>04/12/13 11:56:28  04/13/13 11:56:28 
>krbtgt/ipa.asenjo...@ipa.asenjo.nx
>renew until 04/19/13 11:56:28
>
>so the keytab is correct
>
>I have edited /etc/nfssec.conf and removed the comments for the krb5
>lines.
>
>According to all my google-fu it should work, but it does not. Any tips
>greatly appreciated.
>.
>--
>Groeten,
>natxo
>
>
>
>
>___
>Freeipa-users mailing list
>Freeipa-users@redhat.com
>https://www.redhat.com/mailman/listinfo/freeipa-users

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] bit OT: trouble getting nfsv4 with kerberos with ipa and opensolaris

[Sigbjorn Lie]

zfs set sharenfs='sec=krb5' pool/dataset

Natxo Asenjo  wrote:

>hi,
>
>thanks, still not working though:
>
># share -F nfs -o "sec=krb5" -d "homedirs" /export/home
>Could not share: /export/home: invalid security type
>
> # zfs set sharenfs="sec"="krb5" rpool/export/home
>cannot set property for 'rpool/export/home': 'sharenfs' cannot be set
>to
>invalid options
>
># zfs set "sharenfs"="sec"="krb5" rpool/export/home
>cannot set property for 'rpool/export/home': 'sharenfs' cannot be set
>to
>invalid options
>
># zfs set sharenfs=sec="krb5" rpool/export/home
>cannot set property for 'rpool/export/home': 'sharenfs' cannot be set
>to
>invalid options
>
># zfs set sharenfs=sec=krb5 rpool/export/home
>cannot set property for 'rpool/export/home': 'sharenfs' cannot be set
>to
>invalid options
>
># zfs set "sharenfs=sec=krb5" rpool/export/home
>cannot set property for 'rpool/export/home': 'sharenfs' cannot be set
>to
>invalid options
>
>
>--
>Groeten,
>natxo
>
>
>On Fri, Apr 12, 2013 at 11:30 PM, Sigbjorn Lie 
>wrote:
>
>> Your syntax seem correct but you need to quote the value.
>>

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] bit OT: trouble getting nfsv4 with kerberos with ipa and opensolaris

[Sigbjorn Lie]

No that syntax is correct.

# zfs create p00/test
# zfs set sharenfs='sec=krb5' p00/test

No errors on my system. But have you remembered to enable krb5 in 
/etc/nfssec.conf? It is not enabled by default.


You may read this thread I wrote a while back for how to make 
NexentaStor work with FreeIPA. It will be the same setup for openindiana:


https://www.redhat.com/archives/freeipa-users/2011-July/msg00033.html



Rgds,
Siggi


On 04/13/2013 01:16 PM, Natxo Asenjo wrote:

# zfs set sharenfs='sec=krb5' rpool/export/home
cannot set property for 'rpool/export/home': 'sharenfs' cannot be set 
to invalid options


I am starting to think this is a bug in illumos,


Thanks anyway!

--
Groeten,
natxo


On Fri, Apr 12, 2013 at 11:57 PM, Sigbjorn Lie <mailto:sigbj...@nixtra.com>> wrote:


zfs set sharenfs='sec=krb5' pool/dataset


Natxo Asenjo mailto:natxo.ase...@gmail.com>> wrote:

hi,

thanks, still not working though:

# share -F nfs -o "sec=krb5" -d "homedirs" /export/home
Could not share: /export/home: invalid security type

 # zfs set sharenfs="sec"="krb5" rpool/export/home
cannot set property for 'rpool/export/home': 'sharenfs' cannot
be set to invalid options

# zfs set "sharenfs"="sec"="krb5" rpool/export/home
cannot set property for 'rpool/export/home': 'sharenfs' cannot
be set to invalid options

# zfs set sharenfs=sec="krb5" rpool/export/home
cannot set property for 'rpool/export/home': 'sharenfs' cannot
be set to invalid options

# zfs set sharenfs=sec=krb5 rpool/export/home
cannot set property for 'rpool/export/home': 'sharenfs' cannot
be set to invalid options

# zfs set "sharenfs=sec=krb5" rpool/export/home
cannot set property for 'rpool/export/home': 'sharenfs' cannot
be set to invalid options


--
Groeten,
natxo


On Fri, Apr 12, 2013 at 11:30 PM, Sigbjorn Lie
mailto:sigbj...@nixtra.com>> wrote:

Your syntax seem correct but you need to quote the value.



-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.





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

Re: [Freeipa-users] FreeIPA dual stacked

[Sigbjorn Lie]

On 04/15/2013 05:45 PM, Adam Bishop wrote:

Hi,

I've just had a go at deploying FreeIPA v3.1.3 and have hit a minor road bump.

   The server hostname resolves to more than one address:
 :::::4
 xxx.xxx.xxx.180
   Please provide the IP address to be used for this host name:

The answer I would like to give here is both - is this a limitation of the 
installation script that I can fix up later, or is FreeIPA incompatible with 
dual-stacked hosts at the moment?

Thanks,





My IPA was installed having dual stack from the beginning and is working 
just fine with dual stack today. That was IPA 2.1.3 when I originally 
installed it.



Regards,
Siggi

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

[Freeipa-users] Automount cross-location support

[Sigbjorn Lie]

Hi,

I opened a RFE request almost 2 years ago for automount cross-location support, 
and recently I
discovered how it can be integrated.

https://fedorahosted.org/freeipa/ticket/1699


It is possible to reference a LDAP map from outside what is set in the BASE_DN 
in
/etc/sysconfig/autofs.

Consider the following. The BASE_DN is set to: 
cn=default,cn=automount,dc=example,dc=com

Add an entry to the auto.master in location "default" like this and restart 
automount:
/test2 ldap 
automountmapname=auto_test2,cn=secondlocation,cn=automount,dc=example,dc=com

I tested this on RHEL 6.4 and it worked just fine. Maps from the default 
location and the
specificed "test2" map is read and the entries are mounted successfully.

Now I can do this manually, but it would be nice to have this integrated in the 
IPA framework.

The only downside to this implementation is that I am not sure if this will 
work across platforms.
It might be a Linux automount feature only. Using features of 389ds such as the 
compat module to
mirror maps between automount maps would work on any platform.





Regards,
Siggi


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

Re: [Freeipa-users] Automount cross-location support

[Sigbjorn Lie]

On Thu, May 23, 2013 17:02, Martin Kosek wrote:
> On 05/23/2013 04:56 PM, Sigbjorn Lie wrote:
>
>> Hi,
>>
>>
>> I opened a RFE request almost 2 years ago for automount cross-location 
>> support, and recently I
>> discovered how it can be integrated.
>>
>> https://fedorahosted.org/freeipa/ticket/1699
>>
>>
>>
>> It is possible to reference a LDAP map from outside what is set in the 
>> BASE_DN in
>> /etc/sysconfig/autofs.
>>
>>
>> Consider the following. The BASE_DN is set to: 
>> cn=default,cn=automount,dc=example,dc=com
>>
>>
>> Add an entry to the auto.master in location "default" like this and restart 
>> automount:
>> /test2 ldap 
>> automountmapname=auto_test2,cn=secondlocation,cn=automount,dc=example,dc=com
>>
>>
>> I tested this on RHEL 6.4 and it worked just fine. Maps from the default 
>> location and the
>> specificed "test2" map is read and the entries are mounted successfully.
>>
>> Now I can do this manually, but it would be nice to have this integrated in 
>> the IPA framework.
>>
>>
>> The only downside to this implementation is that I am not sure if this will 
>> work across
>> platforms. It might be a Linux automount feature only. Using features of 
>> 389ds such as the
>> compat module to mirror maps between automount maps would work on any 
>> platform.
>>
>>
>>
>>
>>
>> Regards,
>> Siggi
>>
>>
>
> Thanks for sharing this information Sigbjorn! Maybe we should add what you
> discovered in the ticket, when other hit too.

I see Dmitry has already updated the ticket. :)

Regards,
Siggi


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

Re: [Freeipa-users] Automount cross-location support

[Sigbjorn Lie]

On Thu, May 23, 2013 17:23, Rob Crittenden wrote:
> Sigbjorn Lie wrote:
>
>> Hi,
>>
>>
>> I opened a RFE request almost 2 years ago for automount cross-location 
>> support, and recently I
>> discovered how it can be integrated.
>>
>> https://fedorahosted.org/freeipa/ticket/1699
>>
>>
>>
>> It is possible to reference a LDAP map from outside what is set in the 
>> BASE_DN in
>> /etc/sysconfig/autofs.
>>
>>
>> Consider the following. The BASE_DN is set to: 
>> cn=default,cn=automount,dc=example,dc=com
>>
>>
>> Add an entry to the auto.master in location "default" like this and restart 
>> automount:
>> /test2 ldap 
>> automountmapname=auto_test2,cn=secondlocation,cn=automount,dc=example,dc=com
>>
>>
>> I tested this on RHEL 6.4 and it worked just fine. Maps from the default 
>> location and the
>> specificed "test2" map is read and the entries are mounted successfully.
>>
>> Now I can do this manually, but it would be nice to have this integrated in 
>> the IPA framework.
>>
>>
>> The only downside to this implementation is that I am not sure if this will 
>> work across
>> platforms. It might be a Linux automount feature only. Using features of 
>> 389ds such as the
>> compat module to mirror maps between automount maps would work on any 
>> platform.
>
> It may be that the basedn for autofs is just to find the maps. For keys
> it can use the value directly because they point to real entries.
>
> Its good to know that this works, but we still need some way internally
> to detangle these and present the values in a way that it is easy to pick and 
> choose.
>
> I suppose one idea would be to create a new kind of map share, common.
> This would only allow ldap keys which could point to any valid key.
>
Yes, a "common" / "linked" map type sounds like a good way to go.

>
> A common map could be added to any location.
>
>
> I'm not sure how we'd represent this using compat though.
>

The compat module would have to be extended to support displaying selected 
automount maps from one
location in a different location. I do not know the internals of the compat 
plugin so what I'm
asking might be unable/hard to achieve with the compat plugin - I was referring 
to it because of
it's ability to mirror one part of the ldap tree to a different part of the 
ldap tree.



Regards,
Siggi






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

Re: [Freeipa-users] FreeIPA - Help ...

[Sigbjorn Lie]

Me too. +1 for ipa to ipa migration. 

Martin Kosek  wrote:

>On 05/24/2013 03:34 PM, Simo Sorce wrote:
>> On Fri, 2013-05-24 at 07:44 -0400, Ainsworth, Thomas wrote:
>>> Greetings,
>>>
>>> I was told to bring my issue to this distribution.
>>>
>>> Six months or so ago I was tasked with setting up a Kerberos/LDAP
>>> Authentication server.  After a 
>>> month of headaches I finally got it to work - Then I relaized it
>would
>>> be a monster to maintain.  Then a 
>>> peer asked me to have a look at FreeIPA. Wow.  Installed it - was
>>> amazed.  Runs great.  We love it.
>>>
>>> ...A few days ago, I was notified I have to change my domain/REALM
>in
>>> FreeIPA.  I read the manual,
>>> google searches ... crickets.  I hear crickets.  I started spitting
>>> blood in the trash can.
>>>
>>> I joined a forum and asked for any information, and I was pointed
>>> hereso...here goes...
>>>
>>>
>>> My Current Configuration
>>>
>>> - We have two (2) servers.  Both are installed with
>>> ipa-server-3.0.0-26.el6_4.2.x86_64.
>>>   One is a replica server.
>>>
>>> Domain:  my.network.domain
>>> Realm:MY.NETWORK.DOMAIN
>>>
>>>
>>> New Proposed Configuration
>>>
>>> Domain: my.local.network.domain
>>> Realm: MY.LOCAL.NETWORK.DOMAIN
>>>
>>>
>>>
>>> Sounds easy - but the paradox is ... the beauty of FreeIPA is that
>it
>>> does everything under the hood for you,
>>> and the horror is that it does everything under the hood for you!
>>> There seem to be so many tentacles with 
>>> KERBEROS that I am afraid of jacking something up.  
>>>
>>> Now, I have written a script that uses ipa to create all of my users
>-
>>> except the passwords.  So, what I was thinking 
>>> is to shut down the replica server, re-kick it, re-install FreeIPA
>>> with the new domain/REALM and then run my deploy 
>>> users script.  It would be my new master.  But then I would have to
>>> have "each" user log in and change their password.  
>>> Then take the second server and make it the replica.
>>>
>>> Question #1:  Is this a stupid idea  Is there a way (documented
>or
>>> not) that I can simply change my domain/REALM?  
>>> Am I making this too hard?
>>>
>>> Question #2: Is there a way to backup the users passwords and then
>>> after I re-kick, install ipa and create my users ... I 
>>>can simply "import" this information into the new
>>> ipa instance.
>>>
>>> Any and all suggestions are greatly appreciated...
>> 
>> I would look at the migration pages. You can probably use migration
>mode
>> to migrate user data from one FreeIPa install to the other and then
>the
>> migration mode of sssd to validate and recompute the kerberos keys.
>> 
>> 
>> See this for some guidance:
>>
>https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/Migrating_from_a_Directory_Server_to_IPA.html
>> 
>> Simo.
>> 
>
>Simo, on a side note - I am thinking, would it make sense to create a
>new
>command "ipa migrate-ipa" which would migrate data from other IPA
>installation?
>I.e. it would migrate users, groups, hosts, sudo, hbac, automount, etc?
>
>I came across several user cases where creating a replica was not an
>option and
>migration like this would have been beneficial.
>
>Martin
>u
>___
>Freeipa-users mailing list
>Freeipa-users@redhat.com
>https://www.redhat.com/mailman/listinfo/freeipa-users

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

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

Re: [Freeipa-users] Automount cross-location support

[Sigbjorn Lie]

On 24/05/13 23:48, Nalin Dahyabhai wrote:

On Fri, May 24, 2013 at 12:01:04PM +0200, Sigbjorn Lie wrote:

The compat module would have to be extended to support displaying selected 
automount maps from one
location in a different location. I do not know the internals of the compat 
plugin so what I'm
asking might be unable/hard to achieve with the compat plugin - I was referring 
to it because of
it's ability to mirror one part of the ldap tree to a different part of the 
ldap tree.

The compat plugin's usually used to make a group of entries appear
somewhere else, which isn't _quite_ the same thing as making part of the
tree show up elsewhere, since the tree structure isn't preserved, but if
you don't mind "flattening" of the results when your source is split up
in the hierarchy of a subtree, that won't be a problem.

Otherwise, yeah, if that newly-created part of the tree, where the
plugin's making the fake entries appear, happens to be under a subtree
which autofs is searching for a given map's contents, then I don't see a
reason why it shouldn't work.  The configuration for the compat plugin
would probably simply copy specific attributes rather than doing any
real manipulation their values, much like we do for user entries under
cn=users,cn=compat.  I guess you could either "tag" entries for
inclusion in a way that they'd match the filter which the compat
plugin's configured to use when searching for source entries, or grab
all of the entries in that given source area.

Whenever you added a new automount location, you'd need to add a new
mostly-boilerplate configuration entry under "cn=Schema Compatibility,
cn=plugins, cn=config" to have that same group of entries with the same
contents show up in the new location's part of the tree, but that would
be about it.

Also, if you're not rewriting attribute values, you could probably also
ccomplish it with managed entries, since it plays in a similar area.  Or
perhaps it could be done with just referrals, though that depends on the
client to follow them.




I did some testing on this. I added an entry to  "cn=Schema 
Compatibility, cn=plugins, cn=config", and defined the various settings 
for the compat plugin. It worked as a charm, the requested automountmaps 
we're mirrored. However, one glitch when I attempt to actually use it. 
Setting "schema-compat-container-group" to cn=default hides all the 
existing keys in automount location default. Setting it to a level below 
the cn=default, and the automounter does not see the entries with the 
error below. It seem like the automounter can only handle a single level 
of a tree, and does not search subtrees.


"get_query_dn: lookup(ldap): failed to find query dn under search base dns"

I don't think the flatten trees does any harm, it's already flat, as 
long as the container-group could be set to cn=default,cn=automount. 
However it would require logic within the IPA framework to follow any 
"automountinformation=-fstype=autofs auto_anothermapname" and also 
create setup for the additional "auto_anothermapname" in the compat 
plugin. And again the idea seem flawed when the additional maps cannot 
sit under the same schema-compat-container-group.


Is there any way to have several entries in the schema compatibility 
plugin to share the same level of schema-compat-container-group?



Regards,
Siggi







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

Re: [Freeipa-users] Automount cross-location support

[Sigbjorn Lie]

It may be that the basedn for autofs is just to find the maps. For 
keys it can use the value directly because they point to real entries.


Its good to know that this works, but we still need some way 
internally to detangle these and present the values in a way that it 
is easy to pick and choose.


I suppose one idea would be to create a new kind of map share, common. 
This would only allow ldap keys which could point to any valid key.


A common map could be added to any location.


I also found (not surprisingly) that a full dn had to be used in the 
target map for sublevel maps if the target map I referred to using "ldap 
dn-of-other-automount-map" contained additional maps.


A way to make sure this is always the case would be update the IPA 
framework to always set the full dn to the sub map when it's being added 
in the first place. I see IPA is already automatically adding the key in 
the Parent map when it's specified during creation of a new indirect 
automount map. That being said, referring to a full dn for sublevel maps 
breaks on non-Linux, such as the Solaris' automounter.




Regards,
Siggi

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

[Freeipa-users] user-custom script

[Sigbjorn Lie]

Hi,

A while back I got some help writing a python script who extends the user 
classes in ipalib to run
a custom command when a user is added/modified/deleted. This has been working 
perfectly in our
production environment for a few years now, until I upgraded to IPA 3.0 last 
week. The custom
script is no longer executed.

Did the libraries change since 2.2?


The script sits in 
/usr/lib/python2.6/site-packages/ipalib/plugins/user-custom.py and looks like:


#
# Extension to provide user-customizable script when a user id 
added/modified/deleted
#

from ipapython import ipautil

# Extend add

from ipalib.plugins.user import user_add

def script_post_add_callback(inst, ldap, dn, attrs_list, *keys, **options):
 inst.log.info('User added')
 if 'ipa_user_script' in inst.api.env:
 try:
 ipautil.run([inst.api.env.ipa_user_script,"add", dn])
 except:
  pass

 return dn

user_add.register_post_callback(script_post_add_callback)


# Extend delete

from ipalib.plugins.user import user_del

def script_post_del_callback(inst, ldap, dn, attrs_list, *keys, **options):
 inst.log.info('User deleted')
 if 'ipa_user_script' in inst.api.env:
 try:
 ipautil.run([inst.api.env.ipa_user_script,"del", dn])
 except:
  pass

 return dn

user_del.register_post_callback(script_post_del_callback)


# Extend modify

from ipalib.plugins.user import user_mod

def script_post_mod_callback(inst, ldap, dn, attrs_list, *keys, **options):
 inst.log.info('User modified')
 if 'ipa_user_script' in inst.api.env:
 try:
 ipautil.run([inst.api.env.ipa_user_script,"mod", dn])
 except:
  pass

 return dn

user_mod.register_post_callback(script_post_mod_callback)


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

Re: [Freeipa-users] user-custom script

[Sigbjorn Lie]

On Mon, May 27, 2013 13:28, Petr Viktorin wrote:
> On 05/27/2013 12:50 PM, Sigbjorn Lie wrote:
>
>> Hi,
>>
>>
>> A while back I got some help writing a python script who extends the user 
>> classes in ipalib to
>> run a custom command when a user is added/modified/deleted. This has been 
>> working perfectly in
>> our production environment for a few years now, until I upgraded to IPA 3.0 
>> last week. The
>> custom script is no longer executed.
>>
>> Did the libraries change since 2.2?
>>
>
> Hello,
> Yes, IPA did change, though not in the callback registration API. See
> comment below.
>
>>
>>
>> The script sits in 
>> /usr/lib/python2.6/site-packages/ipalib/plugins/user-custom.py and looks
>> like:
>>
>>
>>
>> #
>> # Extension to provide user-customizable script when a user id 
>> added/modified/deleted
>> #
>>
>>
>> from ipapython import ipautil
>>
>> # Extend add
>>
>>
>> from ipalib.plugins.user import user_add
>>
>> def script_post_add_callback(inst, ldap, dn, attrs_list, *keys, **options): 
>> inst.log.info('User
>> added') if 'ipa_user_script' in inst.api.env: try:
>> ipautil.run([inst.api.env.ipa_user_script,"add", dn]) except:
>> pass
>
> First of all, you can add better logging so you can diagnose errors more
> easily, e.g.:
>
> try:
> ipautil.run([inst.api.env.ipa_user_script,"add", dn]) except Exception, e:
> inst.log.error("ipa_user_script: Exception: %s", e)
>
>
> With this change, I can see the following line in the server log:
>
>
> ipa: ERROR: ipa_user_script: Exception: sequence item 2: expected string
> or Unicode, DN found
>
> The error is due to DN refactoring
> (https://fedorahosted.org/freeipa/ticket/1670). All DNs throughout IPA
> are now represented by DN objects. To use them as strings you need to convert 
> them explicitly:
>
> ipautil.run([inst.api.env.ipa_user_script, "add", str(dn)])
>
> The same change is needed in the other three cases.
> The modified code should still work under IPA 2.2.
> Let me know if you're having more trouble.
>
>
>> return dn
>>
>> user_add.register_post_callback(script_post_add_callback)
>>
>>
>> # Extend delete
>>
>>
>> from ipalib.plugins.user import user_del
>>
>> def script_post_del_callback(inst, ldap, dn, attrs_list, *keys, **options): 
>> inst.log.info('User
>> deleted') if 'ipa_user_script' in inst.api.env: try:
>> ipautil.run([inst.api.env.ipa_user_script,"del", dn]) except:
>> pass
>>
>> return dn
>>
>> user_del.register_post_callback(script_post_del_callback)
>>
>>
>> # Extend modify
>>
>>
>> from ipalib.plugins.user import user_mod
>>
>> def script_post_mod_callback(inst, ldap, dn, attrs_list, *keys, **options): 
>> inst.log.info('User
>> modified') if 'ipa_user_script' in inst.api.env: try:
>> ipautil.run([inst.api.env.ipa_user_script,"mod", dn]) except:
>> pass
>>
>> return dn
>>
>> user_mod.register_post_callback(script_post_mod_callback)
>>
>


Thank you.

I removed the user-custom.pyc, and moved the existing user-custom.py file to 
/root and made the
changes in a new file, user-custom-v3.py. I then restarted httpd. However a 
.pyc file is not
created, even after adding/removing/modifying a user.

And the command specified to run in ipa_user_script is not run.

Do you have a suggestions to what I might be doing wrong?


Regards,
Siggi




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

Re: [Freeipa-users] user-custom script

[Sigbjorn Lie]

On Tue, May 28, 2013 15:44, Petr Viktorin wrote:
> On 05/28/2013 02:33 PM, Sigbjorn Lie wrote:
>
>> On Mon, May 27, 2013 13:28, Petr Viktorin wrote:
>>
>>> On 05/27/2013 12:50 PM, Sigbjorn Lie wrote:
>>>
>>>
>>>> Hi,
>>>>
>>>>
>>>>
>>>> A while back I got some help writing a python script who extends the user 
>>>> classes in ipalib
>>>> to run a custom command when a user is added/modified/deleted. This has 
>>>> been working
>>>> perfectly in our production environment for a few years now, until I 
>>>> upgraded to IPA 3.0
>>>> last week. The custom script is no longer executed.
>>>>
>>>> Did the libraries change since 2.2?
>>>>
>>>>
>>>
>>> Hello,
>>> Yes, IPA did change, though not in the callback registration API. See
>>> comment below.
>>>
>>>>
>>>>
>>>> The script sits in 
>>>> /usr/lib/python2.6/site-packages/ipalib/plugins/user-custom.py and looks
>>>>  like:
>>>>
>>>>
>>>>
>>>>
>>>> #
>>>> # Extension to provide user-customizable script when a user id 
>>>> added/modified/deleted
>>>> #
>>>>
>>>>
>>>>
>>>> from ipapython import ipautil
>>>>
>>>> # Extend add
>>>>
>>>>
>>>>
>>>> from ipalib.plugins.user import user_add
>>>>
>>>> def script_post_add_callback(inst, ldap, dn, attrs_list, *keys, **options):
>>>> inst.log.info('User added') if 'ipa_user_script' in inst.api.env: try:
>>>> ipautil.run([inst.api.env.ipa_user_script,"add", dn]) except: pass
>>>
>>> First of all, you can add better logging so you can diagnose errors more
>>> easily, e.g.:
>>>
>>> try:
>>> ipautil.run([inst.api.env.ipa_user_script,"add", dn]) except Exception, e:
>>> inst.log.error("ipa_user_script: Exception: %s", e)
>>>
>>>
>>>
>>> With this change, I can see the following line in the server log:
>>>
>>>
>>>
>>> ipa: ERROR: ipa_user_script: Exception: sequence item 2: expected string
>>> or Unicode, DN found
>>>
>>> The error is due to DN refactoring
>>> (https://fedorahosted.org/freeipa/ticket/1670). All DNs throughout IPA
>>> are now represented by DN objects. To use them as strings you need to 
>>> convert them explicitly:
>>>
>>>
>>> ipautil.run([inst.api.env.ipa_user_script, "add", str(dn)])
>>>
>>> The same change is needed in the other three cases.
>>> The modified code should still work under IPA 2.2.
>>> Let me know if you're having more trouble.
>>>
>>>
>>>
> [...]
>
>>
>>
>> Thank you.
>>
>>
>> I removed the user-custom.pyc, and moved the existing user-custom.py file to 
>> /root and made the
>>  changes in a new file, user-custom-v3.py. I then restarted httpd. However a 
>> .pyc file is not
>> created, even after adding/removing/modifying a user.
>
> The server runs under apache, it doesn't have permissions to create .pyc
> files in /usr/lib/.
>
>> And the command specified to run in ipa_user_script is not run.
>>
>>
>> Do you have a suggestions to what I might be doing wrong?
>>
>
> Do you get any messages in /var/log/httpd/error_log?
>
>


I managed to figure this one out. SElinux was causing the issue. Everything 
worked just fine after
restoring the correct file labels.

Thank you for your help. :)


Regards,
Siggi



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

Re: [Freeipa-users] IPA + AD authentication in apache

[Sigbjorn Lie]

Hi.

I've done the kerberos part with several Apache Web servers with success. I've 
not done the fallback to ldap basic auth.  

Set KrbServiceName to Any in httpd.conf and put a HTTP service kerberos keytab 
from AD and one from IPA in the same keytab file. Reference this keytab file in 
httpd.conf.



Regards
Siggi


KodaK  wrote:

>Another off the wall one from me, but I just want to know if this is
>worth
>pursuing.
>
>I have a series of internal web applications that authenticate
>variously to
>AD or IPA via prompted credentials.
>
>I'd like to use Kerberos tickets (and fall back to LDAP) instead.
>
>I have an IPA connected apache server that most of this stuff runs on.
>
>Is it possible to use both?
>
>I'm going to try following this example to get my feet wet:
>
>http://www.tuxlanding.net/kerberos-authentication-with-apache-in-a-multi-domain-active-directory/
>
>but that's just talking about mutilple AD realms.  I'd like to know if
>there was any special considerations for IPA
>
>Thanks again,
>
>--Jason
>
>-- 
>The government is going to read our mail anyway, might as well make it
>tough for them.  GPG Public key ID:  B6A1A7C6
>
>
>
>
>___
>Freeipa-users mailing list
>Freeipa-users@redhat.com
>https://www.redhat.com/mailman/listinfo/freeipa-users

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] IPA + AD authentication in apache

[Sigbjorn Lie]

On Fri, July 19, 2013 15:23, KodaK wrote:
> On Thu, Jul 18, 2013 at 4:43 PM, Sigbjorn Lie  wrote:
>
>>
>> Hi.
>>
>>
>> I've done the kerberos part with several Apache Web servers with success. 
>> I've not done the
>> fallback to ldap basic auth.
>>
>> Set KrbServiceName to Any in httpd.conf and put a HTTP service kerberos 
>> keytab from AD and one
>> from IPA in the same keytab file. Reference this keytab file in httpd.conf.
>
>
> Thanks for the tips.
>
>
> You wouldn't happen to know how to coax a keytab out of AD when the
> box you're using doesn't have the the same domain name, do you?
>
> For example, the AD domain is SUB.AD.COMPANY.COM but the Linux box is
> UNIX.COMPANY.COM.
>
>
> When I try to get the keytab with:
>
>
> net ads keytab add HTTP -U myusername
>
> I get:
>
>
> libads/kerberos_keytab.c:326: unable to determine machine account's
> dns name in AD!
>
> I realize this is diverging wildly from the subject of IPA -- I can
> take this off list if anyone is annoyed, just let me know.
>

Hi,

Please see below my notes for how to create a combined keytab file.


Retreive a keytab from IPA:

Make sure you have a valid kerberos TGT:
$ klist
Check to see if the service exists in IPA:
$ ipa service-find HTTP/webserver.ipa.domain

If it does not exist, create it with ipa service-add.

Retreive the keytab:
$ ipa-getkeytab -s ipa01 -p HTTP/webserver.ipa.domain -k 
/etc/httpd/HTTP.keytab-IPA



Retreive a keytab from AD:

> ktpass -princ HTTP/webserver.ipa.domain@WINDOWS.DOMAIN +rndpass /mapuser 
> WINDOMAIN\webserver$
-crypto all -ptype KRB5_NT_PRINCIPAL -out webserver.keytab

The Windows admin will choose if they want to use a Computer Account or a User 
Account to bind the
keytab to.
Copy this keytab into /etc/httpd/HTTP.keytab-AD


Combine the keytabs using ktutil:
If an existing keytab exists, delete this keytab. /etc/httpd/HTTP.keytab
Failure to do so wll append the keytabs merging old and new keytabs into a 
single filre. THIS WILL
MAKE AUTHENTCATION FAIL!!

Fire up ktutil
$ ktutil

Read the IPA keytab
rkt /etc/httpd/HTTP.keytab-IPA

Read the MAIN keytab
rkt /etc/httpd/HTTP.keytab-AD

List the principals and verify that they look OK
list

Write them back to a combined keytab:
wkt /etc/httpd/HTTP.keytab

Quit:
q


Regards,
Siggi


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

Re: [Freeipa-users] IPA + AD authentication in apache

[Sigbjorn Lie]

You definitely don't need domain admin. I do not have much rights with my 
active directory account, still I can retrieve keytabs from ad. Sorry, I'm not 
at work so I can't figure out exactly what my access level is. 

Regards
Siggi

KodaK  wrote:

>On Fri, Jul 19, 2013 at 9:55 AM, natxo asenjo 
>wrote:
>> On 07/19/2013 04:09 PM, Sigbjorn Lie wrote:
>>>
>>>
>>> Retreive a keytab from AD:
>>>
>>>> ktpass -princ HTTP/webserver.ipa.domain@WINDOWS.DOMAIN +rndpass
>/mapuser
>>>> WINDOMAIN\webserver$
>>>
>>> -crypto all -ptype KRB5_NT_PRINCIPAL -out webserver.keytab
>>>
>>> The Windows admin will choose if they want to use a Computer Account
>or a
>>> User Account to bind the
>>> keytab to.
>>> Copy this keytab into /etc/httpd/HTTP.keytab-AD
>>
>>
>> just filling in (just in case this was not clear): ktpass.exe is a
>> windows tool you run in the domain controller (or in a workstation
>with
>> the admins tool installed).
>
>Thanks, everyone.
>
>I'm still waiting for a Windows admin to help me out with this.
>Unfortunately I'm not a domain admin, so I can't do this myself. :/
>
>--Jason
>
>___
>Freeipa-users mailing list
>Freeipa-users@redhat.com
>https://www.redhat.com/mailman/listinfo/freeipa-users

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] named failure: REQUIRE(pthread_kill(ldap_inst->watcher...) failed

[Sigbjorn Lie]

On 06/01/14 21:53, Alexandre Ellert wrote:


Do you see any messages complaining about broken connection or 
something like that? Did the server worked fine before the reload?

The server worked fine before reload (caused by logrotate).
I've searched in log file /var/log/dirsrv/*, /var/log/messages but 
didn't find anything interesting.




Some of the named crashes I had at first with bind-dyndb-ldap when I 
started using IPA in production a few years ago also happened at the 
exact time logrotate rotated the log files. I've not had any issues with 
bind-dyndb-ldap for a while now, however the most busy dns servers are 
still running flat files generated from IPA's LDAP tree, but the 
similarity was too close not to mention it. :)



Regards,
Siggi

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

Re: [Freeipa-users] FreeIPA Security issue : Anonymous user can fetch user details from IPA without authenticating

[Sigbjorn Lie]

On 03/01/14 20:33, Stephen Ingram wrote:
On Fri, Jan 3, 2014 at 10:29 AM, Dmitri Pal > wrote:


On 01/03/2014 12:50 PM, Will Sheldon wrote:

Thanks Petr, that certainly makes sense from the point of view of
functionality.

I do think the default is sane, but there are a lot of possible
deployment scenarios and my concern is that a junior or time poor
admin looking to implement a trusted, secure solution should be
made aware of any potential data leakage during configuration,
(preferably in big red letters in the documentation, or better
still, the install script).

Though I am reluctant to draw comparisons between IPA and MS AD
they do seem inevitable. AD restricts anonymous binds to the
rootDSE entry by default and as such this may be considered by
many to be the expected default. Extra care should therefore be
made to point out this difference. To do otherwise risks
undermining the confidence of users in the security of the solution.


It is a double edge sword. We compared IPA to LDAP based solutions
and with those you have (had) anonymous bind enabled by default.
IMO it is the question of a migration. The field of centralized
authentication is crowded with all sorts of different solutions,
though not that integrated as AD or IdM.
It seems that migrating and then tightening security to the level
you need is the way to go. The default you suggest might be a
barrier to migration as people usually tackle problems one step at
a time.
I am not against changing the default eventually but I am not sure
it is the time to.

But may be I am wrong. Are there any opinions on the matter?


I think traditionally LDAP-based solutions have been used as true 
directories where one might be able to search for people through say a 
Web-based interface, for example at a university. Whereas AD can also 
be deployed as a directory, but more often than not though say an 
email Interface (e.g. Outlook) where the user has already gained 
access via their own credentials so there was not a need to allow 
anonymous binds. I like following the tradition of LDAP-based 
directories where anonymous access is allowed by default, however, it 
would be really nice as the OP requested to have controls available 
via the WebUI where the admin could apply ACLs to the directory to 
restrict access to various areas. As changing the overall access 
scheme requires a directory restart, I'm not too sure how easy it 
would be to incorporate that into the WebUI, but maybe a notice 
somewhere to re-enforce the "open" nature of the directory if the 
default is retained.





Not to start a flame war here - but I would like to say I disagree with 
you. :)


The traditional LDAP-based solutions you're mentioning keep information 
that would be open to the public, such as a phone directory.


However IPA (like AD) keep sensitive information that should not be open 
to the public. From a security standpoint it's much easier to forget to 
secure a piece of information in an open directory, than to simply close 
the directory off and only open for known entities. In my point of view, 
it's better to keep these directories closed by default, to anything but 
authenticated requests.


It's a great thing that IPA can easily be configured to either be open 
or closed to anonymous requests by default. :)



Regards,
Siggi



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

[Freeipa-users] Certificate system unavailable

[Sigbjorn Lie]

Hi,

I seem to have issues with the certificate system on my IPA installation. 
Looking up hosts in the
IPA WEBUI on any of the IPA servers says "Certificate format error: [Errno 
-8015] error (-8015)
unknown".

I also notice that hosts says the certificate system is unavailable.

 certmonger: Server failed request, will retry: 4301 (RPC failed at server.  
Certificate operation
cannot be completed: Failure decoding Certificate Signing Request).


Looking at the pki-ca logs on the ipa servers I see that some selftest failed:

# tail -100 selftests.log
28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: 
Initializing self test plugins:
28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem:  loading 
all self test plugin
logger parameters
28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem:  loading 
all self test plugin
instances
28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem:  loading 
all self test plugin
instance parameters
28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem:  loading 
self test plugins in
on-demand order
28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem:  loading 
self test plugins in
startup order
28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: Self test 
plugins have been
successfully loaded!
28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SelfTestSubsystem: Running 
self test plugins
specified to be executed at startup:
28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] CAPresence:  CA is present
28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SystemCertsVerification: 
system certs
verification failure
28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SelfTestSubsystem: The 
CRITICAL self test plugin
called selftests.container.instance.SystemCertsVerification running at startup 
FAILED!

the pki-cad service is running and "pki-cad status" displays the ports 
available.
/etc/init.d/pki-cad status
pki-ca (pid 28697) is running...   [  OK  ]


My main consern is that the certmonger requests for renew of certificates for 
LDAP on 2 out of 3
of the IPA servers has failed, and the current certificate is expiring the 19th 
of January, under
a week from now.

Do you have any suggestions to where I can start troubleshootng this issue?


Regards,
Siggi


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

Re: [Freeipa-users] Certificate system unavailable

[Sigbjorn Lie]

On Mon, January 13, 2014 15:58, Rob Crittenden wrote:
> Sigbjorn Lie wrote:
>
>> Hi,
>>
>>
>> I seem to have issues with the certificate system on my IPA installation. 
>> Looking up hosts in
>> the IPA WEBUI on any of the IPA servers says "Certificate format error: 
>> [Errno -8015] error
>> (-8015)
>> unknown".
>>
>> I also notice that hosts says the certificate system is unavailable.
>>
>>
>> certmonger: Server failed request, will retry: 4301 (RPC failed at server.  
>> Certificate
>> operation cannot be completed: Failure decoding Certificate Signing Request).
>>
>>
>> Looking at the pki-ca logs on the ipa servers I see that some selftest 
>> failed:
>>
>>
>> # tail -100 selftests.log
>> 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: 
>> Initializing self test
>> plugins:
>> 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem:  loading 
>> all self test
>> plugin logger parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] 
>> SelfTestSubsystem:
>> loading all self test plugin instances 28697.main - [13/Jan/2014:15:06:33 
>> CET] [20] [1]
>> SelfTestSubsystem:  loading all self test plugin
>> instance parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] 
>> SelfTestSubsystem:  loading
>> self test plugins in on-demand order 28697.main - [13/Jan/2014:15:06:33 CET] 
>> [20] [1]
>> SelfTestSubsystem:  loading self test plugins in
>> startup order 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] 
>> SelfTestSubsystem: Self test
>> plugins have been successfully loaded! 28697.main - [13/Jan/2014:15:06:34 
>> CET] [20] [1]
>> SelfTestSubsystem: Running self test plugins
>> specified to be executed at startup: 28697.main - [13/Jan/2014:15:06:34 CET] 
>> [20] [1] CAPresence:
>> CA is present
>> 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SystemCertsVerification: 
>> system certs
>> verification failure 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] 
>> SelfTestSubsystem: The
>> CRITICAL self test plugin
>> called selftests.container.instance.SystemCertsVerification running at 
>> startup FAILED!
>>
>> the pki-cad service is running and "pki-cad status" displays the ports 
>> available.
>> /etc/init.d/pki-cad status
>> pki-ca (pid 28697) is running...   [  OK  ]
>>
>>
>> My main consern is that the certmonger requests for renew of certificates 
>> for LDAP on 2 out of
>> 3
>> of the IPA servers has failed, and the current certificate is expiring the 
>> 19th of January,
>> under a week from now.
>>
>> Do you have any suggestions to where I can start troubleshootng this issue?
>>
>
> Check the trust on the audit certificate:
>
>
> # certutil -L -d /var/lib/pki-ca/alias/
> ...
> auditSigningCert cert-pki-ca u,u,Pu
>
> If the trust is not u,u,Pu then you can fix it with:
>
>
> # certutil -M -d /var/lib/pki-ca/alias -n 'auditSigningCert cert-pki-ca'
> -t u,u,Pu
>
>
> Then restart the CA and it should be ok.
>

Looks like this certificate is expired. This is the same output on all 3 of the 
ipa servers.

How can this be fixed?


# certutil -L -d /var/lib/pki-ca/alias/ -n "auditSigningCert cert-pki-ca"
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 5 (0x5)
Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
Issuer: "CN=Certificate Authority,O=DNS.DOMAIN"
Validity:
Not Before: Thu Jan 19 19:44:24 2012
Not After : Wed Jan 08 19:44:24 2014


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

Re: [Freeipa-users] Certificate system unavailable

[Sigbjorn Lie]

On Mon, January 13, 2014 16:34, Rob Crittenden wrote:
> Sigbjorn Lie wrote:
>
>>
>>
>>
>> On Mon, January 13, 2014 15:58, Rob Crittenden wrote:
>>
>>> Sigbjorn Lie wrote:
>>>
>>>
>>>> Hi,
>>>>
>>>>
>>>>
>>>> I seem to have issues with the certificate system on my IPA installation. 
>>>> Looking up hosts
>>>> in the IPA WEBUI on any of the IPA servers says "Certificate format error: 
>>>> [Errno -8015]
>>>> error (-8015)
>>>> unknown".
>>>>
>>>> I also notice that hosts says the certificate system is unavailable.
>>>>
>>>>
>>>>
>>>> certmonger: Server failed request, will retry: 4301 (RPC failed at server. 
>>>>  Certificate
>>>> operation cannot be completed: Failure decoding Certificate Signing 
>>>> Request).
>>>>
>>>>
>>>> Looking at the pki-ca logs on the ipa servers I see that some selftest 
>>>> failed:
>>>>
>>>>
>>>>
>>>> # tail -100 selftests.log
>>>> 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: 
>>>> Initializing self test
>>>> plugins:
>>>> 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem:  
>>>> loading all self test
>>>> plugin logger parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] 
>>>> SelfTestSubsystem:
>>>>  loading all self test plugin instances 28697.main - [13/Jan/2014:15:06:33 
>>>> CET] [20] [1]
>>>> SelfTestSubsystem:  loading all self test plugin
>>>> instance parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] 
>>>> SelfTestSubsystem:
>>>> loading self test plugins in on-demand order 28697.main - 
>>>> [13/Jan/2014:15:06:33 CET] [20]
>>>> [1]
>>>> SelfTestSubsystem:  loading self test plugins in
>>>> startup order 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] 
>>>> SelfTestSubsystem: Self test
>>>> plugins have been successfully loaded! 28697.main - [13/Jan/2014:15:06:34 
>>>> CET] [20] [1]
>>>> SelfTestSubsystem: Running self test plugins
>>>> specified to be executed at startup: 28697.main - [13/Jan/2014:15:06:34 
>>>> CET] [20] [1]
>>>> CAPresence:
>>>> CA is present
>>>> 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SystemCertsVerification: 
>>>> system certs
>>>> verification failure 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] 
>>>> SelfTestSubsystem: The
>>>>  CRITICAL self test plugin
>>>> called selftests.container.instance.SystemCertsVerification running at 
>>>> startup FAILED!
>>>>
>>>> the pki-cad service is running and "pki-cad status" displays the ports 
>>>> available.
>>>> /etc/init.d/pki-cad status
>>>> pki-ca (pid 28697) is running...   [  OK  ]
>>>>
>>>>
>>>> My main consern is that the certmonger requests for renew of certificates 
>>>> for LDAP on 2 out
>>>> of 3
>>>> of the IPA servers has failed, and the current certificate is expiring the 
>>>> 19th of January,
>>>> under a week from now.
>>>>
>>>> Do you have any suggestions to where I can start troubleshootng this issue?
>>>>
>>>>
>>>
>>> Check the trust on the audit certificate:
>>>
>>>
>>>
>>> # certutil -L -d /var/lib/pki-ca/alias/
>>> ...
>>> auditSigningCert cert-pki-ca u,u,Pu
>>>
>>> If the trust is not u,u,Pu then you can fix it with:
>>>
>>>
>>>
>>> # certutil -M -d /var/lib/pki-ca/alias -n 'auditSigningCert cert-pki-ca'
>>> -t u,u,Pu
>>>
>>>
>>>
>>> Then restart the CA and it should be ok.
>>>
>>>
>>
>> Looks like this certificate is expired. This is the same output on all 3 of 
>> the ipa servers.
>>
>>
>> How can this be fixed?
>>
>>
>>
>> # certutil -L -d /var/lib/pki-ca/alias/ -n "auditSigningCert cert-pki-ca"
>> Certificate:
>> Data:
>> Version: 3 (0x2)
>> Serial Number: 5 (0x5)
>> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
>> Issuer: "CN=Certificate Authority,O=DNS.DOMAIN"
>> Validity:
>> Not Before: Thu Jan 19 19:44:24 2012
>> Not After : Wed Jan 08 19:44:24 2014
>>
>>
>>
>
> Go back in time to the 7th or 8th and run:
>
>
> # getcert resubmit -d /var/lib/pki-ca/alias -n "auditSigningCert
> cert-pki-ca"
>
> There may be other certs in a similar situation. getcert list will show you.
>
>

Ouch. That would be rather disruptive I suppose. There is quite a lot of 
activity going to this
server, not to mention it's the primary ntp and dns server for the network.

Do you suppose this todo list will work ?

Firewall off the rest of the network, leaving the ipa server alone
Stop ntpd
Set date to 8th of January
Run the getcert resubmit command.
Change date back to correct date
Start ntpd
Remove the firewall rules


How many of the services is required to be restarted for the renewal to work 
after the date is
changed to the 7th?


Regards,
Siggi


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

Re: [Freeipa-users] Certificate system unavailable

[Sigbjorn Lie]

Hi,

Thank you for your prompt reply Rob.


On Mon, January 13, 2014 15:58, Rob Crittenden wrote:
> Sigbjorn Lie wrote:
>
>> Hi,
>>
>>
>> I seem to have issues with the certificate system on my IPA installation. 
>> Looking up hosts in
>> the IPA WEBUI on any of the IPA servers says "Certificate format error: 
>> [Errno -8015] error
>> (-8015)
>> unknown".
>>
>> I also notice that hosts says the certificate system is unavailable.
>>
>>
>> certmonger: Server failed request, will retry: 4301 (RPC failed at server.  
>> Certificate
>> operation cannot be completed: Failure decoding Certificate Signing Request).
>>
>>
>> Looking at the pki-ca logs on the ipa servers I see that some selftest 
>> failed:
>>
>>
>> # tail -100 selftests.log
>> 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: 
>> Initializing self test
>> plugins:
>> 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem:  loading 
>> all self test
>> plugin logger parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] 
>> SelfTestSubsystem:
>> loading all self test plugin instances 28697.main - [13/Jan/2014:15:06:33 
>> CET] [20] [1]
>> SelfTestSubsystem:  loading all self test plugin
>> instance parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] 
>> SelfTestSubsystem:  loading
>> self test plugins in on-demand order 28697.main - [13/Jan/2014:15:06:33 CET] 
>> [20] [1]
>> SelfTestSubsystem:  loading self test plugins in
>> startup order 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] 
>> SelfTestSubsystem: Self test
>> plugins have been successfully loaded! 28697.main - [13/Jan/2014:15:06:34 
>> CET] [20] [1]
>> SelfTestSubsystem: Running self test plugins
>> specified to be executed at startup: 28697.main - [13/Jan/2014:15:06:34 CET] 
>> [20] [1] CAPresence:
>> CA is present
>> 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SystemCertsVerification: 
>> system certs
>> verification failure 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] 
>> SelfTestSubsystem: The
>> CRITICAL self test plugin
>> called selftests.container.instance.SystemCertsVerification running at 
>> startup FAILED!
>>
>> the pki-cad service is running and "pki-cad status" displays the ports 
>> available.
>> /etc/init.d/pki-cad status
>> pki-ca (pid 28697) is running...   [  OK  ]
>>
>>
>> My main consern is that the certmonger requests for renew of certificates 
>> for LDAP on 2 out of
>> 3
>> of the IPA servers has failed, and the current certificate is expiring the 
>> 19th of January,
>> under a week from now.
>>
>> Do you have any suggestions to where I can start troubleshootng this issue?
>>
>
> Check the trust on the audit certificate:
>
>
> # certutil -L -d /var/lib/pki-ca/alias/
> ...
> auditSigningCert cert-pki-ca u,u,Pu

All the 3 ipa servers return u,u,Pu for auditSigningCert

# certutil -L -d /var/lib/pki-ca/alias/

Certificate Nickname Trust Attributes
 SSL,S/MIME,JAR/XPI

caSigningCert cert-pki-caCTu,Cu,Cu
Server-Cert cert-pki-ca  u,u,u
auditSigningCert cert-pki-ca u,u,Pu
ocspSigningCert cert-pki-ca  u,u,u
subsystemCert cert-pki-cau,u,u

>
> If the trust is not u,u,Pu then you can fix it with:
>
>
> # certutil -M -d /var/lib/pki-ca/alias -n 'auditSigningCert cert-pki-ca'
> -t u,u,Pu
>
>
> Then restart the CA and it should be ok.
>

I have restarted the dirsrv for PKI-IPA, and the pki-cad service on all 3 IPA 
servers.

>
> What is the status on the failed certmonger requests?

After I restarted dirsrv, pki-cad and then the httpd on ipa01 the status of the 
request is now:

Request ID '20120119194518':
status: CA_UNREACHABLE
ca-error: Server failed request, will retry: 907 (RPC failed at server. 
 cannot connect to
'https://ipa01.dns.domain:443/ca/agent/ca/displayBySerial': [Errno -12269]
(SSL_ERROR_EXPIRED_CERT_ALERT) SSL peer rejected your certificate as expired.).
stuck: yes
key pair storage:
type=NSSDB,location='/etc/dirsrv/slapd-DNS-DOMAIN',nickname='Server-Cert',token='NSS
 Certificate
DB',pinfile='/etc/dirsrv/slapd-DNS-DOMAIN//pwdfile.txt'
certificate: 
type=NSSDB,location='/etc/dir

Re: [Freeipa-users] Certificate system unavailable

[Sigbjorn Lie]

On Mon, January 13, 2014 16:17, Rob Crittenden wrote:
> Sigbjorn Lie wrote:
>
>> Hi,
>>
>>
>> Thank you for your prompt reply Rob.
>>
>>
>>
>> On Mon, January 13, 2014 15:58, Rob Crittenden wrote:
>>
>>> Sigbjorn Lie wrote:
>>>
>>>
>>>> Hi,
>>>>
>>>>
>>>>
>>>> I seem to have issues with the certificate system on my IPA installation. 
>>>> Looking up hosts
>>>> in the IPA WEBUI on any of the IPA servers says "Certificate format error: 
>>>> [Errno -8015]
>>>> error (-8015)
>>>> unknown".
>>>>
>>>> I also notice that hosts says the certificate system is unavailable.
>>>>
>>>>
>>>>
>>>> certmonger: Server failed request, will retry: 4301 (RPC failed at server. 
>>>>  Certificate
>>>> operation cannot be completed: Failure decoding Certificate Signing 
>>>> Request).
>>>>
>>>>
>>>> Looking at the pki-ca logs on the ipa servers I see that some selftest 
>>>> failed:
>>>>
>>>>
>>>>
>>>> # tail -100 selftests.log
>>>> 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: 
>>>> Initializing self test
>>>> plugins:
>>>> 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem:  
>>>> loading all self test
>>>> plugin logger parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] 
>>>> SelfTestSubsystem:
>>>>  loading all self test plugin instances 28697.main - [13/Jan/2014:15:06:33 
>>>> CET] [20] [1]
>>>> SelfTestSubsystem:  loading all self test plugin
>>>> instance parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] 
>>>> SelfTestSubsystem:
>>>> loading self test plugins in on-demand order 28697.main - 
>>>> [13/Jan/2014:15:06:33 CET] [20]
>>>> [1]
>>>> SelfTestSubsystem:  loading self test plugins in
>>>> startup order 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] 
>>>> SelfTestSubsystem: Self test
>>>> plugins have been successfully loaded! 28697.main - [13/Jan/2014:15:06:34 
>>>> CET] [20] [1]
>>>> SelfTestSubsystem: Running self test plugins
>>>> specified to be executed at startup: 28697.main - [13/Jan/2014:15:06:34 
>>>> CET] [20] [1]
>>>> CAPresence:
>>>> CA is present
>>>> 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SystemCertsVerification: 
>>>> system certs
>>>> verification failure 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] 
>>>> SelfTestSubsystem: The
>>>>  CRITICAL self test plugin
>>>> called selftests.container.instance.SystemCertsVerification running at 
>>>> startup FAILED!
>>>>
>>>> the pki-cad service is running and "pki-cad status" displays the ports 
>>>> available.
>>>> /etc/init.d/pki-cad status
>>>> pki-ca (pid 28697) is running...   [  OK  ]
>>>>
>>>>
>>>> My main consern is that the certmonger requests for renew of certificates 
>>>> for LDAP on 2 out
>>>> of 3
>>>> of the IPA servers has failed, and the current certificate is expiring the 
>>>> 19th of January,
>>>> under a week from now.
>>>>
>>>> Do you have any suggestions to where I can start troubleshootng this issue?
>>>>
>>>>
>>>
>>> Check the trust on the audit certificate:
>>>
>>>
>>>
>>> # certutil -L -d /var/lib/pki-ca/alias/
>>> ...
>>> auditSigningCert cert-pki-ca u,u,Pu
>>
>> All the 3 ipa servers return u,u,Pu for auditSigningCert
>>
>>
>> # certutil -L -d /var/lib/pki-ca/alias/
>>
>>
>> Certificate Nickname Trust Attributes
>> SSL,S/MIME,JAR/XPI
>>
>>
>> caSigningCert cert-pki-caCTu,Cu,Cu 
>> Server-Cert cert-pki-ca
>> u,u,u auditSigningCert cert-pki-ca u,u,Pu 
>> ocspSigningCert
>> cert-pki-ca  u,u,u subsystemCert cert-pki-ca
>> u,u,u
>>
>>>
>>> If the trust is not u,u,Pu then you can fix it with:
>>>
>>>
>>>
>>> # certutil -M -d /var/lib/p

Re: [Freeipa-users] Certificate system unavailable

[Sigbjorn Lie]

On 13/01/14 19:13, Nalin Dahyabhai wrote:

On Mon, Jan 13, 2014 at 04:07:16PM +0100, Sigbjorn Lie wrote:

After I restarted dirsrv, pki-cad and then the httpd on ipa01 the status of the 
request is now:

Request ID '20120119194518':
status: CA_UNREACHABLE
ca-error: Server failed request, will retry: 907 (RPC failed at server. 
 cannot connect to
'https://ipa01.dns.domain:443/ca/agent/ca/displayBySerial': [Errno -12269]
(SSL_ERROR_EXPIRED_CERT_ALERT) SSL peer rejected your certificate as expired.).
stuck: yes
key pair storage:
type=NSSDB,location='/etc/dirsrv/slapd-DNS-DOMAIN',nickname='Server-Cert',token='NSS
 Certificate
DB',pinfile='/etc/dirsrv/slapd-DNS-DOMAIN//pwdfile.txt'
certificate: 
type=NSSDB,location='/etc/dirsrv/slapd-DNS-DOMAIN',nickname='Server-Cert',token='NSS
Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=DNS-DOMAIN
subject: CN=ipa01.dns.domain,O=DNS-DOMAIN
expires: 2014-01-19 19:45:18 UTC
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command:
track: yes
auto-renew: yes

However I cannot find the certificate that's expired?

That error message was the one the IPA server received and then relayed
back to certmonger, so I'd expect that the expired certificate is the
agent certificate that IPA uses when connecting to the CA's agent
interface.  That's stored in the NSS database in /etc/httpd/alias, with
nickname "ipaCert".




Yes, the ipaCert certificate in /etc/httpd/alias/ is expired.

Actually all certificates in /var/lib/pki-ca/alias/ is expired too, they 
all expired at the same date, within minutes of each other. It looks 
like they are the original certificates issued when I installed IPA, 
when I look at the "Not Before" timestamp of the certificates.




Regards,
Siggi

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

Re: [Freeipa-users] Certificate system unavailable

[Sigbjorn Lie]

On 13/01/14 19:37, Rob Crittenden wrote:

Sigbjorn Lie wrote:




On Mon, January 13, 2014 16:34, Rob Crittenden wrote:

Sigbjorn Lie wrote:





On Mon, January 13, 2014 15:58, Rob Crittenden wrote:


Sigbjorn Lie wrote:



Hi,



I seem to have issues with the certificate system on my IPA 
installation. Looking up hosts
in the IPA WEBUI on any of the IPA servers says "Certificate 
format error: [Errno -8015]

error (-8015)
unknown".

I also notice that hosts says the certificate system is unavailable.



certmonger: Server failed request, will retry: 4301 (RPC failed 
at server.  Certificate
operation cannot be completed: Failure decoding Certificate 
Signing Request).



Looking at the pki-ca logs on the ipa servers I see that some 
selftest failed:




# tail -100 selftests.log
28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] 
SelfTestSubsystem: Initializing self test

plugins:
28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] 
SelfTestSubsystem:  loading all self test
plugin logger parameters 28697.main - [13/Jan/2014:15:06:33 CET] 
[20] [1] SelfTestSubsystem:
  loading all self test plugin instances 28697.main - 
[13/Jan/2014:15:06:33 CET] [20] [1]

SelfTestSubsystem:  loading all self test plugin
instance parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] 
[1] SelfTestSubsystem:
loading self test plugins in on-demand order 28697.main - 
[13/Jan/2014:15:06:33 CET] [20]

[1]
SelfTestSubsystem:  loading self test plugins in
startup order 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] 
SelfTestSubsystem: Self test
plugins have been successfully loaded! 28697.main - 
[13/Jan/2014:15:06:34 CET] [20] [1]

SelfTestSubsystem: Running self test plugins
specified to be executed at startup: 28697.main - 
[13/Jan/2014:15:06:34 CET] [20] [1]

CAPresence:
CA is present
28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] 
SystemCertsVerification: system certs
verification failure 28697.main - [13/Jan/2014:15:06:34 CET] [20] 
[1] SelfTestSubsystem: The

  CRITICAL self test plugin
called selftests.container.instance.SystemCertsVerification 
running at startup FAILED!


the pki-cad service is running and "pki-cad status" displays the 
ports available.

/etc/init.d/pki-cad status
pki-ca (pid 28697) is running...   [  OK  ]


My main consern is that the certmonger requests for renew of 
certificates for LDAP on 2 out

of 3
of the IPA servers has failed, and the current certificate is 
expiring the 19th of January,

under a week from now.

Do you have any suggestions to where I can start troubleshootng 
this issue?





Check the trust on the audit certificate:



# certutil -L -d /var/lib/pki-ca/alias/
...
auditSigningCert cert-pki-ca u,u,Pu

If the trust is not u,u,Pu then you can fix it with:



# certutil -M -d /var/lib/pki-ca/alias -n 'auditSigningCert 
cert-pki-ca'

-t u,u,Pu



Then restart the CA and it should be ok.




Looks like this certificate is expired. This is the same output on 
all 3 of the ipa servers.



How can this be fixed?



# certutil -L -d /var/lib/pki-ca/alias/ -n "auditSigningCert 
cert-pki-ca"

Certificate:
Data:
Version: 3 (0x2)
Serial Number: 5 (0x5)
Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
Issuer: "CN=Certificate Authority,O=DNS.DOMAIN"
Validity:
Not Before: Thu Jan 19 19:44:24 2012
Not After : Wed Jan 08 19:44:24 2014





Go back in time to the 7th or 8th and run:


# getcert resubmit -d /var/lib/pki-ca/alias -n "auditSigningCert
cert-pki-ca"

There may be other certs in a similar situation. getcert list will 
show you.





Ouch. That would be rather disruptive I suppose. There is quite a lot 
of activity going to this
server, not to mention it's the primary ntp and dns server for the 
network.


Do you suppose this todo list will work ?

Firewall off the rest of the network, leaving the ipa server alone
Stop ntpd
Set date to 8th of January
Run the getcert resubmit command.
Change date back to correct date
Start ntpd
Remove the firewall rules


Looks good. I'd restart the certmonger service rather than 
resubmitting each individually. Be prepared for renewal to not 
succeed. For some reason it didn't on and before expiration time so 
whatever problem existed then likely still remains.


So the question to ask is "what will I do if renewal fails again?"

Nothing catastrophic will happen, but it will likely mean having to 
roll forward again, debug, roll back, try again, and perhaps more than 
once. It's hard to say w/o knowing why it failed in the first place.


How many of the services is required to be restarted for the renewal 
to work after the date is

changed to the 7th?


The renewal itself should restart the required services.



This worked better than expected. Thank you! :)

ipa01 and ipa02 seem to be happy again, "getcert list" no longer 
displays any certificates out of date, and all certificates i

Re: [Freeipa-users] Certificate system unavailable

[Sigbjorn Lie]

On Fri, January 17, 2014 16:37, Rob Crittenden wrote:
> Sigbjorn Lie wrote:
>
>>
>> This worked better than expected. Thank you! :)
>>
>>
>> ipa01 and ipa02 seem to be happy again, "getcert list" no longer displays 
>> any certificates out
>> of date, and all certificates in need of renewal within 28 days has been 
>> renewed. The webui also
>> started working again and things seem to be back to normal.
>>
>> ipa03 however is still having issues. I could not renew any certificates on 
>> this server to begin
>> with, but I managed to renew the certificates for the directory servers by 
>> changing the xmlrpc
>> url to another ipa server in /etc/ipa/default.conf and resubmitting these 
>> requests.
>>
>> "getcert resubmit -i > NEED_GUIDANCE after a short while for the certificates for the PKI service.
>>
>>
>> /var/log/messages says: "certmonger: #033[?1034h28800" and "python:
>> Updated certificate for ipaCert not available".
>>
>>
>> There is a lot of information in the /var/log/pki-ca/debug, but nothing
>> that I can easily distinguish as an error from all the other output. 
>> Anything in particular I
>> should look for?
>
> Ok, so this is a bug in IPA related to python readline. Garbage is
> getting inserted and causing bad things to happen, 
> https://fedorahosted.org/freeipa/ticket/4064
>
>
> So the question is, are the certs available or not.
>
>
> A number of the same certificates are shared amongst all the CAs. One
> does the renewal and stuffs the result into 
> cn=ca_renewal,cn=ipa,cn=etc,$SUFFIX. The other CAs
> refer to that location for an updated cert and will load them if they are 
> updated.
>
> Look to see if the certs are updated there. Given that you have 2
> working masters I'm assuming that is the case, so it may just be a matter of 
> fixing the python.
>

I could not get anywhere even after manually patching the python script as 
mentioned in the ticket
you provided.


I ended up removing and re-adding the replica during a maintenance window. For 
future reference,
what I did was to remove the replica as per the Identity Management Guide on 
docs.redhat.com. I
then re-created the replica installation file and installed the replica.

At this point Certmonger managed to retrieve new certificates for the expired 
certificates, but it
kept segfaulting when it attempted to save the certificate to disk. I restarted 
certmonger a few
times, but certmonger just ended up segfaulting over and over. I decided to 
block the ipa server
off the network and change the date back to before the certs expired. After the 
date was changed I
restarted certmonger. Certmonger managed to save the certs successfully this 
time and a "getcert
list" now displays only certificates with an expire date of 2015 or 2016 and a 
status of
MONTORING.

I changed the date back to correct date and time and removed the iptables 
rules. The replica now
works just fine.

Thank you for your assistance.


Regards,
Siggi





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

Re: [Freeipa-users] Certificate system unavailable

[Sigbjorn Lie]

Sure thing! I'll send them to you in private.


Regards
Siggi

Dmitri Pal  wrote:
>On 01/31/2014 10:00 AM, Sigbjorn Lie wrote:
>>
>>
>> On Fri, January 17, 2014 16:37, Rob Crittenden wrote:
>>> Sigbjorn Lie wrote:
>>>
>>>> This worked better than expected. Thank you! :)
>>>>
>>>>
>>>> ipa01 and ipa02 seem to be happy again, "getcert list" no longer
>displays any certificates out
>>>> of date, and all certificates in need of renewal within 28 days has
>been renewed. The webui also
>>>> started working again and things seem to be back to normal.
>>>>
>>>> ipa03 however is still having issues. I could not renew any
>certificates on this server to begin
>>>> with, but I managed to renew the certificates for the directory
>servers by changing the xmlrpc
>>>> url to another ipa server in /etc/ipa/default.conf and resubmitting
>these requests.
>>>>
>>>> "getcert resubmit -i with
>>>> NEED_GUIDANCE after a short while for the certificates for the PKI
>service.
>>>>
>>>>
>>>> /var/log/messages says: "certmonger: #033[?1034h28800" and "python:
>>>> Updated certificate for ipaCert not available".
>>>>
>>>>
>>>> There is a lot of information in the /var/log/pki-ca/debug, but
>nothing
>>>> that I can easily distinguish as an error from all the other
>output. Anything in particular I
>>>> should look for?
>>> Ok, so this is a bug in IPA related to python readline. Garbage is
>>> getting inserted and causing bad things to happen,
>https://fedorahosted.org/freeipa/ticket/4064
>>>
>>>
>>> So the question is, are the certs available or not.
>>>
>>>
>>> A number of the same certificates are shared amongst all the CAs.
>One
>>> does the renewal and stuffs the result into
>cn=ca_renewal,cn=ipa,cn=etc,$SUFFIX. The other CAs
>>> refer to that location for an updated cert and will load them if
>they are updated.
>>>
>>> Look to see if the certs are updated there. Given that you have 2
>>> working masters I'm assuming that is the case, so it may just be a
>matter of fixing the python.
>>>
>> I could not get anywhere even after manually patching the python
>script as mentioned in the ticket
>> you provided.
>>
>>
>> I ended up removing and re-adding the replica during a maintenance
>window. For future reference,
>> what I did was to remove the replica as per the Identity Management
>Guide on docs.redhat.com. I
>> then re-created the replica installation file and installed the
>replica.
>>
>> At this point Certmonger managed to retrieve new certificates for the
>expired certificates, but it
>> kept segfaulting when it attempted to save the certificate to disk. I
>restarted certmonger a few
>> times, but certmonger just ended up segfaulting over and over. I
>decided to block the ipa server
>> off the network and change the date back to before the certs expired.
>After the date was changed I
>> restarted certmonger. Certmonger managed to save the certs
>successfully this time and a "getcert
>> list" now displays only certificates with an expire date of 2015 or
>2016 and a status of
>> MONTORING.
>>
>> I changed the date back to correct date and time and removed the
>iptables rules. The replica now
>> works just fine.
>>
>> Thank you for your assistance.
>>
>
>Can you give us some core dumps from certmonger to see why it is
>crashing.
>We would like to fix crash bugs if we them.
>
>
>> Regards,
>> Siggi
>>
>>
>>
>>
>>
>> ___
>> Freeipa-users mailing list
>> Freeipa-users@redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>
>
>-- 
>Thank you,
>Dmitri Pal
>
>Sr. Engineering Manager for IdM portfolio
>Red Hat Inc.
>
>
>---
>Looking to carve out IT costs?
>www.redhat.com/carveoutcosts/
>
>
>
>___
>Freeipa-users mailing list
>Freeipa-users@redhat.com
>https://www.redhat.com/mailman/listinfo/freeipa-users

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Certificate system unavailable

[Sigbjorn Lie]

On Fri, January 31, 2014 20:32, Rob Crittenden wrote:
> Sigbjorn Lie wrote:
>
>>
>>
>>
>> On Fri, January 17, 2014 16:37, Rob Crittenden wrote:
>>
>>> Sigbjorn Lie wrote:
>>>
>>>
>>>>
>>>> This worked better than expected. Thank you! :)
>>>>
>>>>
>>>>
>>>> ipa01 and ipa02 seem to be happy again, "getcert list" no longer displays 
>>>> any certificates
>>>> out of date, and all certificates in need of renewal within 28 days has 
>>>> been renewed. The
>>>> webui also started working again and things seem to be back to normal.
>>>>
>>>> ipa03 however is still having issues. I could not renew any certificates 
>>>> on this server to
>>>> begin with, but I managed to renew the certificates for the directory 
>>>> servers by changing
>>>> the xmlrpc url to another ipa server in /etc/ipa/default.conf and 
>>>> resubmitting these
>>>> requests.
>>>>
>>>> "getcert resubmit -i >>> NEED_GUIDANCE after a short while for the certificates for the PKI service.
>>>>
>>>>
>>>>
>>>> /var/log/messages says: "certmonger: #033[?1034h28800" and "python:
>>>> Updated certificate for ipaCert not available".
>>>>
>>>>
>>>>
>>>> There is a lot of information in the /var/log/pki-ca/debug, but nothing
>>>> that I can easily distinguish as an error from all the other output. 
>>>> Anything in particular
>>>> I
>>>> should look for?
>>>
>>> Ok, so this is a bug in IPA related to python readline. Garbage is
>>> getting inserted and causing bad things to happen,
>>> https://fedorahosted.org/freeipa/ticket/4064
>>>
>>>
>>>
>>> So the question is, are the certs available or not.
>>>
>>>
>>>
>>> A number of the same certificates are shared amongst all the CAs. One
>>> does the renewal and stuffs the result into 
>>> cn=ca_renewal,cn=ipa,cn=etc,$SUFFIX. The other CAs
>>>  refer to that location for an updated cert and will load them if they are 
>>> updated.
>>>
>>> Look to see if the certs are updated there. Given that you have 2
>>> working masters I'm assuming that is the case, so it may just be a matter 
>>> of fixing the
>>> python.
>>>
>>
>> I could not get anywhere even after manually patching the python script as 
>> mentioned in the
>> ticket you provided.
>>
>>
>> I ended up removing and re-adding the replica during a maintenance window. 
>> For future
>> reference, what I did was to remove the replica as per the Identity 
>> Management Guide on
>> docs.redhat.com. I then re-created the replica installation file and 
>> installed the replica.
>>
>> At this point Certmonger managed to retrieve new certificates for the 
>> expired certificates, but
>> it kept segfaulting when it attempted to save the certificate to disk. I 
>> restarted certmonger a
>> few times, but certmonger just ended up segfaulting over and over. I decided 
>> to block the ipa
>> server off the network and change the date back to before the certs expired. 
>> After the date was
>> changed I restarted certmonger. Certmonger managed to save the certs 
>> successfully this time and
>> a "getcert list" now displays only certificates with an expire date of 2015 
>> or 2016 and a status
>> of MONTORING.
>>
>>
>> I changed the date back to correct date and time and removed the iptables 
>> rules. The replica
>> now works just fine.
>>
>> Thank you for your assistance.
>>
>
> Sounds like https://bugzilla.redhat.com/show_bug.cgi?id=1032760
>

It would seem like we're still encountering some issues. The date has now 
passed for when the old
certificate expired, and the "ipa" cli command no longer works. The webui is 
still working just
fine.

These are the errors I receive.

$ ipa user-find
ipa: ERROR: cert validation failed for 
"CN=serveripa03.example.com,O=EXAMPLE.COM"
((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not 
trusted by the
user.)
ipa: ERROR: cert validation failed for 
"CN=serveripa01.example.com,O=EXAMPLE.COM"
((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not 
trusted by the
user.)
ipa: ERROR: cert validation failed for 
"CN=serveripa0

Re: [Freeipa-users] Certificate system unavailable

[Sigbjorn Lie]

On Fri, February 14, 2014 15:29, Rob Crittenden wrote:
> Sigbjorn Lie wrote:
>
>>
>>
>> It would seem like we're still encountering some issues. The date has now 
>> passed for when the
>> old certificate expired, and the "ipa" cli command no longer works. The 
>> webui is still working
>> just fine.
>>
>> These are the errors I receive.
>>
>>
>> $ ipa user-find
>> ipa: ERROR: cert validation failed for 
>> "CN=serveripa03.example.com,O=EXAMPLE.COM"
>> ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as 
>> not trusted by the
>> user.) ipa: ERROR: cert validation failed for 
>> "CN=serveripa01.example.com,O=EXAMPLE.COM"
>> ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as 
>> not trusted by the
>> user.) ipa: ERROR: cert validation failed for 
>> "CN=serveripa02.example.com,O=EXAMPLE.COM"
>> ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as 
>> not trusted by the
>> user.) ipa: ERROR: cannot connect to Gettext('any of the configured 
>> servers', domain='ipa',
>> localedir=None): https://serveripa03.example.com/ipa/xml,
>> https://serveripa01.example.com/ipa/xml,
>> https://serveripa02.example.com/ipa/xml
>>
>
> This seems more like a client-side issue. Can you confirm that
> /etc/ipa/ca.crt is correct and that the NSS database in /etc/pki/nssdb
> contains the CA?
>
> certutil -L -d /etc/pki/nssdb -n 'IPA CA'
>


The CA seem to be available. I ran the command on ipa01. See below for the 
output.

The issue happens when I'm logged on to any of the ipa servers, and if I'm 
running the ipa command
from a remote machine.


]$ sudo certutil -L -d /etc/pki/nssdb -n 'IPA CA'
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
Issuer: "CN=Certificate Authority,O=EXAMPLE.COM"
Validity:
Not Before: Thu Jan 19 19:44:21 2012
Not After : Sun Jan 19 19:44:21 2020
Subject: "CN=Certificate Authority,O=EXAMPLE.COM"
Subject Public Key Info:
Public Key Algorithm: PKCS #1 RSA Encryption
RSA Public Key:
Modulus:


Regards,
Siggi


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