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

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] 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] AIX kerberos client to IPA

[Sigbjorn Lie]

On 12/03/14 22:52, Rob wrote:

Hi,

I have configured an AIX 6.1 server to connect to a RHEL 6.5 IPA server. The
AIX server is configured to use netgroups and all that works for existing the
users.

The problem is when a users password expires or when a new user is created.
They cannot change their password

WARNING: Your password has expired.
You must change your password now and login again!
Changing password for "testuser"
testuser's Old password:
testuser's New password:
Connection to localhost closed.

The problem seems to be related to not getting a kerberos ticket as kinit can
be used to change the password.

Logging is enabled but no logs ever get updated

[logging]
 kdc = FILE:/var/krb5/log/krb5kdc.log
 admin_server = FILE:/var/krb5/log/kadmin.log
 kadmin_local = FILE:/var/krb5/log/kadmin_local.log
 default = FILE:/var/krb5/log/krb5lib.log

Anybody ever come across this? Or know how to get logging working?

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


*

I am not familiar with AIX. Just quick tip for what we had to do on Solaris to 
make password changes work - as the issue sounded somewhat familiar... :)

We have to set "kpasswd_protocol = SET_CHANGE" to krb5.conf when used with any 
"non-Solaris KDC".

Perhaps you have a similar setting for AIX?



*

___
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 20/02/14 23:08, Rob Crittenden wrote:

Sigbjorn Lie wrote:

On 20/02/14 21:38, Rob Crittenden wrote:


I am surprised too. I dumped the PKI CA certificate from 
/etc/pki/nssdb

before and after I updated it into text files, and diff'ed them. No
differences was reported.


I can't think of a reason it would be using the sqlite database at
all. You don't have NSS_DEFAULT_DB_TYPE set somewhere do you? I'd find
it hard to believe that this would be set EVERYWHERE.

If we want to brute force things, trying strace against a client that
isn't working to confirm that it is trying to open cert9 might give us
a data point at least.


I have NSS_DEFAULT_DB_TYPE set to "sql".


Oh, ok, that's why then. You're telling NSS to use sqlite databases 
and we only configure the older database style so the client isn't 
finding its CA cert.


So you can either not set that or migrate all the client databases. 
I'm a little surprised the servers aren't blowing up on you too.




Ohh so true...unset NSS_DEFAULT_DB_TYPE and it's all working fine! I 
can't believe it was something this silly!


I've found the file where the NSS_DEFAULT_DB_TYPE is set to "sql" for 
our environment. This file has not been changed since Sep 2012. It's 
only set for a select amount of our accounts (mine being one of them) - 
that's why the servers isn't blowing up. And is why the webui is still 
working...


We installed IPA in early 2012 and I've not had issues using the "ipa" 
command on any machines until a few weeks ago - and yes, 
NSS_DEFAULT_DB_TYPE=sql has been in the environment for my account the 
whole time.


We recently installed a set of patches upgrading our servers to RHEL 
6.5+(some updates) from 6.4. It would seem like something changed with 
this set of patches. And it also explains why this did not happen in the 
test environment as the same accounts are not being utilised there.


Thank you for your assistance resolving these issues we've had recently. :)


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 20/02/14 21:38, Rob Crittenden wrote:

Sigbjorn Lie wrote:

On 20/02/14 21:19, Rob Crittenden wrote:

Sigbjorn Lie wrote:




On Wed, February 19, 2014 13:45, Sigbjorn Lie wrote:






On Tue, February 18, 2014 20:45, Rob Crittenden wrote:


Sigbjorn Lie wrote:


On what machine are you trying to use the ipa tool? Is it one 
of the

masters, all of them, enrolled clients?



It's the same error message when the "ipa" command is run directly
on any of the masters.



And it's the same error message if I run the "ipa" command on any
of the clients.



I do not have a working "ipa" command anywhere anymore.




Ok, let's test out the cert that ipa is using. Try this on any 
one of

the masters:

$ curl https://`hostname`/ipa/xml
Should fail with Peer certificate cannot be authenticated with
known CA
certificates


Yes, this did not work:


curl: (60) Peer certificate cannot be authenticated with known CA
certificates
More details here: http://curl.haxx.se/docs/sslcerts.html





$ curl --cacert /etc/ipa/ca.crt https://`hostname`/ipa/xml
Should succeed in that you get the "you are not logged in" HTML page




Indeed - this works.




Ok, now unfortunately curl only handles the sql-style NSS 
databases so

we can't fully reproduce it the same way that the IPA client is
doing things, but here is an
approximation:



# certutil -A -d sql:/etc/pki/nssdb -n 'IPA CA' -t CT,C,C -a -i
/etc/ipa/ca.crt
$ curl https://`hostname`/ipa/xml
You should see the login page HTML




Yes, I can now see the login page HTML.





If you stick a -v in there it'll give you more verbose output which
would be useful if any of these fail in an unexpected way.


Whatever is going on isn't likely related to the web server Apache
database as you get the same error out of each one. The client
log you sent confirmed that
it tried to contact each master. The SSL error we're getting is
that the client doesn't
trust the CA that
signed the server certificate so this appears to be a problem on
the client, which begs the
question: all clients or just this one?





All clients.






NSS is smart enough to handle multiple certificates, it should
pick the
newest one on startup.



Ok.



Where do you suggest I continue troubleshooting this issue?




We can also tackle this on the server side. Let's verify the server
cert:



# certutil -V -u V -n Server-Cert -d /etc/httpd/alias



This produces the same output for all 3 servers:


certutil: certificate is valid




This is verified on server startup so I expect it to be valid, but
doesn't hurt to try.

Restarting the Apache process might be something to try as 
changes to

the NSS database aren't picked up until a restart.



I ran "# certutil -A -d sql:/etc/pki/nssdb -n 'IPA CA' -t CT,C,C -a
-i /etc/ipa/ca.crt" on ipa03,
  and restarted httpd.

The "ipa" command is now *working* on ipa03. :)


However it's *not working* a client who's /etc/ipa/default.conf
points at ipa03.


Do I have to refresh the PKI CA in /etc/pki/nssdb on every client?


You shouldn't need to. Frankly I'm surprised this worked. What is the
distro and what version of nss is installed?

rob



This is RHEL 6.5 with nss-3.15.3-3.el6_5.x86_64.

I am surprised too. I dumped the PKI CA certificate from /etc/pki/nssdb
before and after I updated it into text files, and diff'ed them. No
differences was reported.


I can't think of a reason it would be using the sqlite database at 
all. You don't have NSS_DEFAULT_DB_TYPE set somewhere do you? I'd find 
it hard to believe that this would be set EVERYWHERE.


If we want to brute force things, trying strace against a client that 
isn't working to confirm that it is trying to open cert9 might give us 
a data point at least.


I have NSS_DEFAULT_DB_TYPE set to "sql".

When I do a strace I can see that on /etc/pki/nssdb/cert9.db it does: 
"access", "stat", attempt "open" read-write which is denied, then "open" 
read only. Looks pretty normal?


What is odd is the timestamp on the files in /etc/pki/nssdb/ on the 
different ipa servers


ipa01 and ipa02, which is not working
cert8.db is timestamped with the date we initially installed the ipa 
servers in 2012.
cert9.db, key3.db, key4.db, secmod.db is timestamped in 2010, 2 years 
before the server was installed - so this must be the original file 
provided by the nss-sysinit package.


ipa03, which is working after updating the nssdb:
cert8.db and key3.db is timestamped with the date when I carried out the 
changes you proposed which this thread originally started with in 
january 2014
cert9.db and key4.db is timestamped with the date I ran the certutil 
command you recommended me to 2 days ago

secmod.db is timestamped in 2010, 2 years before the server was installed.

As I described earlier in this thread, I

Re: [Freeipa-users] Certificate system unavailable

[Sigbjorn Lie]

On 20/02/14 21:19, Rob Crittenden wrote:

Sigbjorn Lie wrote:




On Wed, February 19, 2014 13:45, Sigbjorn Lie wrote:






On Tue, February 18, 2014 20:45, Rob Crittenden wrote:


Sigbjorn Lie wrote:



On what machine are you trying to use the ipa tool? Is it one of the
masters, all of them, enrolled clients?



It's the same error message when the "ipa" command is run directly 
on any of the masters.




And it's the same error message if I run the "ipa" command on any 
of the clients.




I do not have a working "ipa" command anywhere anymore.




Ok, let's test out the cert that ipa is using. Try this on any one of
the masters:

$ curl https://`hostname`/ipa/xml
Should fail with Peer certificate cannot be authenticated with 
known CA

certificates


Yes, this did not work:


curl: (60) Peer certificate cannot be authenticated with known CA 
certificates

More details here: http://curl.haxx.se/docs/sslcerts.html





$ curl --cacert /etc/ipa/ca.crt https://`hostname`/ipa/xml
Should succeed in that you get the "you are not logged in" HTML page




Indeed - this works.




Ok, now unfortunately curl only handles the sql-style NSS databases so
we can't fully reproduce it the same way that the IPA client is 
doing things, but here is an

approximation:



# certutil -A -d sql:/etc/pki/nssdb -n 'IPA CA' -t CT,C,C -a -i
/etc/ipa/ca.crt
$ curl https://`hostname`/ipa/xml
You should see the login page HTML




Yes, I can now see the login page HTML.





If you stick a -v in there it'll give you more verbose output which
would be useful if any of these fail in an unexpected way.


Whatever is going on isn't likely related to the web server Apache
database as you get the same error out of each one. The client 
log you sent confirmed that
it tried to contact each master. The SSL error we're getting is 
that the client doesn't

trust the CA that
signed the server certificate so this appears to be a problem on 
the client, which begs the

question: all clients or just this one?





All clients.






NSS is smart enough to handle multiple certificates, it should 
pick the

newest one on startup.



Ok.



Where do you suggest I continue troubleshooting this issue?




We can also tackle this on the server side. Let's verify the server 
cert:




# certutil -V -u V -n Server-Cert -d /etc/httpd/alias



This produces the same output for all 3 servers:


certutil: certificate is valid




This is verified on server startup so I expect it to be valid, but
doesn't hurt to try.

Restarting the Apache process might be something to try as changes to
the NSS database aren't picked up until a restart.



I ran "# certutil -A -d sql:/etc/pki/nssdb -n 'IPA CA' -t CT,C,C -a 
-i /etc/ipa/ca.crt" on ipa03,

  and restarted httpd.

The "ipa" command is now *working* on ipa03. :)


However it's *not working* a client who's /etc/ipa/default.conf 
points at ipa03.



Do I have to refresh the PKI CA in /etc/pki/nssdb on every client?


You shouldn't need to. Frankly I'm surprised this worked. What is the 
distro and what version of nss is installed?


rob



This is RHEL 6.5 with nss-3.15.3-3.el6_5.x86_64.

I am surprised too. I dumped the PKI CA certificate from /etc/pki/nssdb 
before and after I updated it into text files, and diff'ed them. No 
differences was reported.



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 Wed, February 19, 2014 13:45, Sigbjorn Lie wrote:
>

>
> On Tue, February 18, 2014 20:45, Rob Crittenden wrote:
>
>> Sigbjorn Lie wrote:
>>
>>
>>>> On what machine are you trying to use the ipa tool? Is it one of the
>>>> masters, all of them, enrolled clients?
>>>>
>>>
>>> It's the same error message when the "ipa" command is run directly on any 
>>> of the masters.
>>>
>>>
>>>
>>> And it's the same error message if I run the "ipa" command on any of the 
>>> clients.
>>>
>>>
>>>
>>> I do not have a working "ipa" command anywhere anymore.
>>>
>>>
>>
>> Ok, let's test out the cert that ipa is using. Try this on any one of
>> the masters:
>>
>> $ curl https://`hostname`/ipa/xml
>> Should fail with Peer certificate cannot be authenticated with known CA
>> certificates
>
> Yes, this did not work:
>
>
> curl: (60) Peer certificate cannot be authenticated with known CA certificates
> More details here: http://curl.haxx.se/docs/sslcerts.html
>
>
>
>>
>> $ curl --cacert /etc/ipa/ca.crt https://`hostname`/ipa/xml
>> Should succeed in that you get the "you are not logged in" HTML page
>>
>>
>
> Indeed - this works.
>
>
>>
>> Ok, now unfortunately curl only handles the sql-style NSS databases so
>> we can't fully reproduce it the same way that the IPA client is doing 
>> things, but here is an
>> approximation:
>>
>>
>>
>> # certutil -A -d sql:/etc/pki/nssdb -n 'IPA CA' -t CT,C,C -a -i
>> /etc/ipa/ca.crt
>> $ curl https://`hostname`/ipa/xml
>> You should see the login page HTML
>>
>>
>
> Yes, I can now see the login page HTML.
>
>
>
>>
>> If you stick a -v in there it'll give you more verbose output which
>> would be useful if any of these fail in an unexpected way.
>>
>>>> Whatever is going on isn't likely related to the web server Apache
>>>> database as you get the same error out of each one. The client log you 
>>>> sent confirmed that
>>>> it tried to contact each master. The SSL error we're getting is that the 
>>>> client doesn't
>>>> trust the CA that
>>>> signed the server certificate so this appears to be a problem on the 
>>>> client, which begs the
>>>> question: all clients or just this one?
>>>>
>>>>
>>>>
>>>
>>> All clients.
>>>
>>>
>>>
>>>
>>>>
>>>> NSS is smart enough to handle multiple certificates, it should pick the
>>>> newest one on startup.
>>>>
>>>
>>> Ok.
>>>
>>>
>>>
>>> Where do you suggest I continue troubleshooting this issue?
>>>
>>>
>>
>> We can also tackle this on the server side. Let's verify the server cert:
>>
>>
>>
>> # certutil -V -u V -n Server-Cert -d /etc/httpd/alias
>>
>>
> This produces the same output for all 3 servers:
>
>
> certutil: certificate is valid
>
>
>>
>> This is verified on server startup so I expect it to be valid, but
>> doesn't hurt to try.
>>
>> Restarting the Apache process might be something to try as changes to
>> the NSS database aren't picked up until a restart.
>>
>
> I ran "# certutil -A -d sql:/etc/pki/nssdb -n 'IPA CA' -t CT,C,C -a -i 
> /etc/ipa/ca.crt" on ipa03,
>  and restarted httpd.
>
> The "ipa" command is now *working* on ipa03. :)
>
>
> However it's *not working* a client who's /etc/ipa/default.conf points at 
> ipa03.
>
>
> Do I have to refresh the PKI CA in /etc/pki/nssdb on every client?
>
>

*ping* :)


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 Tue, February 18, 2014 20:45, Rob Crittenden wrote:
> Sigbjorn Lie wrote:
>
>>> On what machine are you trying to use the ipa tool? Is it one of the
>>> masters, all of them, enrolled clients?
>>>
>>
>> It's the same error message when the "ipa" command is run directly on any of 
>> the masters.
>>
>>
>> And it's the same error message if I run the "ipa" command on any of the 
>> clients.
>>
>>
>> I do not have a working "ipa" command anywhere anymore.
>>
>
> Ok, let's test out the cert that ipa is using. Try this on any one of
> the masters:
>
> $ curl https://`hostname`/ipa/xml
> Should fail with Peer certificate cannot be authenticated with known CA
> certificates

Yes, this did not work:

curl: (60) Peer certificate cannot be authenticated with known CA certificates
More details here: http://curl.haxx.se/docs/sslcerts.html


>
> $ curl --cacert /etc/ipa/ca.crt https://`hostname`/ipa/xml
> Should succeed in that you get the "you are not logged in" HTML page
>

Indeed - this works.

>
> Ok, now unfortunately curl only handles the sql-style NSS databases so
> we can't fully reproduce it the same way that the IPA client is doing things, 
> but here is an
> approximation:
>
>
> # certutil -A -d sql:/etc/pki/nssdb -n 'IPA CA' -t CT,C,C -a -i
> /etc/ipa/ca.crt
> $ curl https://`hostname`/ipa/xml
> You should see the login page HTML
>

Yes, I can now see the login page HTML.


>
> If you stick a -v in there it'll give you more verbose output which
> would be useful if any of these fail in an unexpected way.
>
>>> Whatever is going on isn't likely related to the web server Apache
>>> database as you get the same error out of each one. The client log you sent 
>>> confirmed that it
>>> tried to contact each master. The SSL error we're getting is that the 
>>> client doesn't trust the
>>> CA that
>>> signed the server certificate so this appears to be a problem on the 
>>> client, which begs the
>>> question: all clients or just this one?
>>>
>>>
>>
>> All clients.
>>
>>
>>
>>>
>>> NSS is smart enough to handle multiple certificates, it should pick the
>>> newest one on startup.
>>>
>>
>> Ok.
>>
>>
>> Where do you suggest I continue troubleshooting this issue?
>>
>
> We can also tackle this on the server side. Let's verify the server cert:
>
>
> # certutil -V -u V -n Server-Cert -d /etc/httpd/alias
>
This produces the same output for all 3 servers:

certutil: certificate is valid

>
> This is verified on server startup so I expect it to be valid, but
> doesn't hurt to try.
>
> Restarting the Apache process might be something to try as changes to
> the NSS database aren't picked up until a restart.
>

I ran "# certutil -A -d sql:/etc/pki/nssdb -n 'IPA CA' -t CT,C,C -a -i 
/etc/ipa/ca.crt" on ipa03,
and restarted httpd.

The "ipa" command is now *working* on ipa03. :)

However it's *not working* a client who's /etc/ipa/default.conf points at ipa03.

Do I have to refresh the PKI CA in /etc/pki/nssdb on every client?


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, February 17, 2014 17:59, Rob Crittenden wrote:
> Sigbjorn Lie wrote:
>
>>
>>
>>
>> On Mon, February 17, 2014 16:34, Rob Crittenden wrote:
>>
>>> Sigbjorn Lie wrote:
>>>
>>>
>>>>
>>>>
>>>>
>>>> On Fri, February 14, 2014 17:18, Rob Crittenden wrote:
>>>>
>>>>
>>>>> Sigbjorn Lie wrote:
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 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:
&g

Re: [Freeipa-users] Certificate system unavailable

[Sigbjorn Lie]

On Mon, February 17, 2014 16:34, Rob Crittenden wrote:
> Sigbjorn Lie wrote:
>
>>
>>
>>
>> On Fri, February 14, 2014 17:18, Rob Crittenden wrote:
>>
>>> Sigbjorn Lie wrote:
>>>
>>>
>>>>
>>>>
>>>>
>>>> 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:
>>>>
>>>>
>>>
>>> Perhaps we can brute force things to see what is going on. We can pass
>>> some extra options to the ipa tool to get ultra verbose output:
>>>
>>> $ ipa -vv -e debug=True user-show admin
>>>
>>>
>>>
>>> The thing to do is to check the server that it is communicating with and
>>> check /var/log/httpd/errors to see if there is an equivalent error logged 
>>> there.
>>>
>>
>> I've sent you the full output in private.  Could this be the reason for why 
>> it fails?
>>
>>
>> ipa: DEBUG: auth_certificate_callback: check_sig=True is_server=False
>>
>>
>> Name: Certificate Key Usage
>> Critical: True
>> Usages:
>> Digital Signature
>> Non-Repudiation
>> Key Encipherment
>> Data Encipherment
>>
>>
>
> No, that is normal for a server cert.
>
>
> This pretty clearly looks like an SSL trust issue. Is this happening on
> every client machine you run the ipa tool or just one?
>
> You might want to compare the cert in /etc/pki/nssdb with the one on the
> Apache server.
>
>
> # certutil -L -d /etc/httpd/alias -n 'EXAMPLE.COM IPA CA'
>
>
> # certutil -L -d /etc/pki/nssdb -n 'IPA CA'
>

Looks like the same certificate, just with different flags?

$ sudo  certutil -L -d /etc/httpd/alias -n 'EXAMPLE.COM IPA CA' > /tmp/ca1
$ sudo certutil -L -d /etc/pki/nssdb -n 'IPA CA' > /tmp/ca2
$ diff /tmp/ca1 /tmp/ca2
90a91,92
> Valid CA
> Trusted CA



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, February 17, 2014 16:34, Rob Crittenden wrote:
> Sigbjorn Lie wrote:
>
>>
>>
>>
>> On Fri, February 14, 2014 17:18, Rob Crittenden wrote:
>>
>>> Sigbjorn Lie wrote:
>>>
>>>
>>>>
>>>>
>>>>
>>>> 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:
>>>>
>>>>
>>>
>>> Perhaps we can brute force things to see what is going on. We can pass
>>> some extra options to the ipa tool to get ultra verbose output:
>>>
>>> $ ipa -vv -e debug=True user-show admin
>>>
>>>
>>>
>>> The thing to do is to check the server that it is communicating with and
>>> check /var/log/httpd/errors to see if there is an equivalent error logged 
>>> there.
>>>

This error is recorded in the httpd error log. The same error is repeated on 
all 3 ipa servers.

[Mon Feb 17 17:24:16 2014] [error] SSL Library Error: -12195 Peer does not 
recognize and trust the
CA that issued your certificate


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, February 17, 2014 16:34, Rob Crittenden wrote:
> Sigbjorn Lie wrote:
>
>>
>>
>>
>> On Fri, February 14, 2014 17:18, Rob Crittenden wrote:
>>
>>> Sigbjorn Lie wrote:
>>>
>>>
>>>>
>>>>
>>>>
>>>> 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:
>>>>
>>>>
>>>
>>> Perhaps we can brute force things to see what is going on. We can pass
>>> some extra options to the ipa tool to get ultra verbose output:
>>>
>>> $ ipa -vv -e debug=True user-show admin
>>>
>>>
>>>
>>> The thing to do is to check the server that it is communicating with and
>>> check /var/log/httpd/errors to see if there is an equivalent error logged 
>>> there.
>>>
>>
>> I've sent you the full output in private.  Could this be the reason for why 
>> it fails?
>>
>>
>> ipa: DEBUG: auth_certificate_callback: check_sig=True is_server=False
>>
>>
>> Name: Certificate Key Usage
>> Critical: True
>> Usages:
>> Digital Signature
>> Non-Repudiation
>> Key Encipherment
>> Data Encipherment
>>
>>
>
> No, that is normal for a server cert.
>
>
> This pr

Re: [Freeipa-users] Certificate system unavailable

[Sigbjorn Lie]

On Fri, February 14, 2014 17:18, Rob Crittenden wrote:
> Sigbjorn Lie wrote:
>
>>
>>
>>
>> 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:
>>
>
> Perhaps we can brute force things to see what is going on. We can pass
> some extra options to the ipa tool to get ultra verbose output:
>
> $ ipa -vv -e debug=True user-show admin
>
>
> The thing to do is to check the server that it is communicating with and
> check /var/log/httpd/errors to see if there is an equivalent error logged 
> there.
>

I've sent you the full output in private.  Could this be the reason for why it 
fails?

ipa: DEBUG: auth_certificate_callback: check_sig=True is_server=False

Name: Certificate Key Usage
Critical: True
Usages:
Digital Signature
Non-Repudiation
Key Encipherment
Data Encipherment




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

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]

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

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

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

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

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

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

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

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

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

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

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

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

[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

[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

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

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

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

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]

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

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
>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:/nethome/&
>
>Is it that Solaris automount dont like asterisk(*) in a automount key?
>
>Regards,
>Johan.
>
>From: Sigbjorn Lie [sigbj...@nixtra.com]
>Sent: Thursday, December 20, 2012 15:20
>To: Johan Petersson
>Cc: freeipa-users@redhat.com
>Subject: RE: [Freeipa-users] Does Solaris 11 work as client to IPA
>server?
>
>Thanks.
>
>I'm guessing it's taking such a long time because it's looking trough
>the entire LDAP server for
>your automount maps. The automountmap rules in the DUA profile will
>help with that. You'll also
>run into issues if you attempt to have several automount locations
>without having specified which
>one to use with a automountmap rule for auto master.
>
>If you are using NFS4 you should add the _nfsv4idmapdomain dns TXT
>record to your DNS or set
>NFSMAPID_DOMAIN in /etc/default/nfs to the same value as the domain id
>used on your NFS server to
>get rid of the nobody:nobody default mapping and enable mapping between
>the NFS server and the
>client.
>
>
>
>Regards,
>Siggi
>
>
>
>
>On Thu, December 20, 2012 13:40, Johan Petersson wrote:
>> Hi,
>>
>>
>> Here is my pam.conf cleaned 

Re: [Freeipa-users] Automount problems

[Sigbjorn Lie]

On 12/22/2012 10:24 AM, Johan Petersson wrote:
I can't get automount to work for some reason on a CentOS 6.3 
testserver with the NFS and IPA server on the same server.
Was going to set this up for some other configuration testing but are 
stuck on this instead. :)


Feels like i am missing something basic but can't figure it out.
Followed the guide and tried a variety of automount maps but nothing 
works.

Had automount working before installing IPA Client with:
auto.master:
/home/etc/auto.home
auto.home
*servername:/home/&

I can mount /home from the client:

mount -t nfs4 -o sec=krb5 servername:/home /mnt

/etc/sysconfig/autofs:


LDAP_URI="ldap://servername";
SEARCH_BASE="cn=default,cn=automount,dc=home"

MAP_OBJECT_CLASS="automountMap"
ENTRY_OBJECT_CLASS="automount"
MAP_ATTRIBUTE="automountMapName"
ENTRY_ATTRIBUTE="automountKey"
VALUE_ATTRIBUTE="automountInformation"

Getting this from debug lvl logging on autofs:

Dec 22 09:13:00 client2 automount[4528]: connected to uri 
ldap://servername
Dec 22 09:13:00 client2 automount[4528]: read_one_map: lookup(ldap): 
searching for "(objectclass=automount)" under 
"automountmapname=auto.direct,cn=default,cn=automount,dc=home"
Dec 22 09:13:00 client2 automount[4528]: do_get_entries: lookup(ldap): 
query succeeded, no matches for (objectclass=automount)
Dec 22 09:13:00 client2 automount[4528]: read_one_map: lookup(ldap): 
done updating map
Dec 22 09:13:00 client2 automount[4528]: st_ready: st_ready(): state = 
0 path /-


So what am i missing here?




Hi,

In your /etc/auto.master, do you still have the following line as the 
last line in the file? If not, add it back in.

+auto.master


Do you still have a specific map for auto.home in your /etc/auto.master? 
If so, add +auto.home to the end of your /etc/auto.home file. (Provided 
you named the automount map auto.home in IPA too...)



In your /etc/nsswitch.conf file, make sure your automount line looks 
like this:

automount:  files ldap


Let me know how you get on.



Regards,
Siggi

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

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

[Sigbjorn Lie]

Thanks.

I'm guessing it's taking such a long time because it's looking trough the 
entire LDAP server for
your automount maps. The automountmap rules in the DUA profile will help with 
that. You'll also
run into issues if you attempt to have several automount locations without 
having specified which
one to use with a automountmap rule for auto master.

If you are using NFS4 you should add the _nfsv4idmapdomain dns TXT record to 
your DNS or set
NFSMAPID_DOMAIN in /etc/default/nfs to the same value as the domain id used on 
your NFS server to
get rid of the nobody:nobody default mapping and enable mapping between the NFS 
server and the
client.



Regards,
Siggi




On Thu, December 20, 2012 13:40, Johan Petersson wrote:
> Hi,
>
>
> Here is my pam.conf cleaned up a bit.
>
>
> login   auth requisite  pam_authtok_get.so.1 login   auth required
> pam_dhkeys.so.1 login   auth sufficient pam_krb5.so.1 try_first_pass 
> login   auth required
> pam_unix_cred.so.1 login   auth required   pam_unix_auth.so.1 login   
> auth required
> pam_dial_auth.so.1
>
> gdm-autologin auth  requiredpam_unix_cred.so.1 gdm-autologin auth  
> sufficient  pam_allow.so.1
>
> other   auth requisite  pam_authtok_get.so.1 other   auth required
> pam_dhkeys.so.1 other   auth required   pam_unix_cred.so.1 other   
> auth sufficient
> pam_krb5.so.1 other   auth required   pam_unix_auth.so.1
>
> passwd  auth required   pam_passwd_auth.so.1
>
> gdm-autologin account  sufficient  pam_allow.so.1
>
> other   account requisite   pam_roles.so.1 other   account required
> pam_unix_account.so.1 other   account requiredpam_krb5.so.1
>
> other   session requiredpam_unix_session.so.1
>
> other   password required   pam_dhkeys.so.1 other   password requisite
> pam_authtok_get.so.1
>
> other   password requisite  pam_authtok_check.so.1 force_check other   
> password sufficient
> pam_krb5.so.1 other   password required   pam_authtok_store.so.1
>
> I am getting one error and it is for autofs.
>
>
> /var/adm/messages:
> Dec 20 12:56:58 servername automount[1651]: [ID 754625 daemon.error] Object 
> not found
>
>
> /var/svc/log/system.filesystem-autofs:default.log:
> [ Dec 20 12:24:22 Executing start method ("/lib/svc/method/svc-autofs 
> start"). ]
> automount: /net mounted
> automount: /nfs4 mounted
> automount: no unmounts
> [ Dec 20 12:24:22 Method "start" exited with status 0. ]
>
>
> ldapclient list NS_LDAP_FILE_VERSION= 2.0
> NS_LDAP_SERVERS= servername
> NS_LDAP_SEARCH_BASEDN= dc=home
> NS_LDAP_AUTH= none
> NS_LDAP_SEARCH_REF= TRUE
> NS_LDAP_SEARCH_TIME= 15
> NS_LDAP_PROFILE= default
> NS_LDAP_SERVICE_SEARCH_DESC= passwd:cn=users,cn=accounts,dc=home
> NS_LDAP_SERVICE_SEARCH_DESC= group:cn=groups,cn=compat,dc=home
> NS_LDAP_BIND_TIME= 5
> NS_LDAP_OBJECTCLASSMAP= shadow:shadowAccount=posixAccount
>
>
> Thinking it has to do with missing automountmap in default DUAProfile.
> Automount still works though but takes time during login and everything is 
> nobody:nobody :)
>
>
> 
> From: Sigbjorn Lie [sigbj...@nixtra.com]
> Sent: Thursday, December 20, 2012 10:13
> To: Johan Petersson
> Cc: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] Does Solaris 11 work as client to IPA server?
>
>
> Hi,
>
>
> This is interesting. When I tested Solaris 11 ssh worked, and su - testuser 
> worked. However
> console login did not work giving some PAM errors.
>
> Could you please share your entire pam.conf file?
>
>
> Is this Solaris 11 or Solaris 11.1?
>
>
>
>
> Regards,
> Siggi
>
>
>
>
> On Thu, December 20, 2012 09:40, Johan Petersson wrote:
>
>> I have now managed to use a Solaris 11 system as a client to IPA Server.
>> su - testuser works ssh works and console login works. I get a delay before 
>> getting the prompt
>> through ssh though and maybe from console too, probably something about 
>> autofs Going to see if
>> i can increase loginformation (Solaris newbie). To get it to work i mainly 
>> followed Sigbjorn
>> Lie's
>> instructions for Solaris 10 in earlier posts here. I also used the 
>> /etc/pam.conf configuration
>> example from the Solaris 10 client guide on Free IPA. I stuck with the 
>> default DUAProfile for
>> now and use a NFS4 Kerberos share for home directories with autofs. Going to 
>> try the other
>> DUAProfile
>> too from Bug 815515 and hopefully i can get everything working.
>>
>> 
>> From: freeipa-users-

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

[Sigbjorn Lie]

Hi,

This is interesting. When I tested Solaris 11 ssh worked, and su - testuser 
worked. However
console login did not work giving some PAM errors.

Could you please share your entire pam.conf file?

Is this Solaris 11 or Solaris 11.1?



Regards,
Siggi



On Thu, December 20, 2012 09:40, Johan Petersson wrote:
> I have now managed to use a Solaris 11 system as a client to IPA Server.
> su - testuser works ssh works and console login works. I get a delay before 
> getting the prompt
> through ssh though and maybe from console too, probably something about 
> autofs. Going to see if i
> can increase loginformation (Solaris newbie). To get it to work i mainly 
> followed Sigbjorn Lie's
> instructions for Solaris 10 in earlier posts here. I also used the 
> /etc/pam.conf configuration
> example from the Solaris 10 client guide on Free IPA. I stuck with the 
> default DUAProfile for now
> and use a NFS4 Kerberos share for home directories with autofs. Going to try 
> the other DUAProfile
> too from Bug 815515 and hopefully i can get everything working.
>
> 
> From: freeipa-users-boun...@redhat.com [freeipa-users-boun...@redhat.com] on 
> behalf of Dmitri Pal
> [d...@redhat.com]
> Sent: Tuesday, December 18, 2012 17:50
> To: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] Does Solaris 11 work as client to IPA server?
>
>
> On 12/18/2012 04:06 AM, Sigbjorn Lie wrote:
>
>> On Tue, December 18, 2012 08:28, Johan Petersson wrote:
>>
>>> Hi,
>>>
>>>
>>>
>>> We are implementing IPA Server and are gong to need to be able to 
>>> authenticate properly with
>>> a number of Solaris 11 servers. I have browsed the archives and found a few 
>>> threads mentioning
>>> some problems with Solaris 11 and IPA Server. Does anyone know if the issue 
>>> have been solved?
>>>
>>>
>> I don't think there is any problems with Solaris 11 except of nobody has yet 
>> sat down and
>> figured out how to configure it as an IPA client yet.
>>
>> I had a got at it a while ago (some of the posts you've probably found), and 
>> found that there
>> was enough differences in the LDAP/Kerberos client between Solaris 10 and 
>> Solaris 11 for making
>> it work with the setup guide I've created for Solaris 10. And there was a 
>> need for further
>> investigation for finding out how to configure Solaris 11 as an IPA client.
>>
>> I've not looked into this further as we do not use Solaris 11 yet.
>>
>>
>> I don't know if anyone else has had time to sit down and have a crack at 
>> this?
>>
>
> And we would like to hear about this effort.
> If it produces instructions we would like to put them on the wiki.
> If it produces bugs we would investigate 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
>
>
> ___
> 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] Problem generating Oracle ZFS Storage Appliance host and nfs principals and keys to IPA/Free IPA.

[Sigbjorn Lie]

On 12/18/2012 06:24 AM, Johan Petersson wrote:

Hi,

Unfortunately i still get the same error from the Appliance even after having 
added both host and nfs principals in the IPA web interface.

"failed to create principal 'host/zfs1.home@HOME': libkadm5clnt error:
  43787522 (Operation requires ``add'' privilege)"

I get the impression that the Appliance does not recognize existing principals 
since i still get the same create principal error.
So it seems that it does not cope with pre existing principals, at least not 
from IPA Server.
I will contact Oracle about this issue and see what they say.

Thank you for your help,
Johan.


We have these ZFS Storage Appliances at work too. There is a way to 
access the root shell of the ZFS Storage Appliance. It's been a long 
time since I've done it, but a quick googelig turned up this:


http://weblogs.java.net/blog/kohsuke/archive/2009/01/under_the_hood.html

Hopefully the "scp" commands still exists when you get access to the 
shell of the Solaris OS, so you can copy the pre-created keytab into 
/etc/krb5/krb5.keytab.


CAUTION! The /etc/krb5/krb5.keytab is by default shared between the CIFS 
server and the NFS server. This file will already contain the keytab for 
the CIFS/SMB service if you have already joined the ZFS Storage 
Appliance to AD. In which case copy the pre-created keytab from IPA into 
/etc/krb5/krb5.keytab-IPA, and use ktutil to merge the two files together.


I see I've kept the keytab from my AD in the beginning of the file and 
added the keytab from IPA to the end of the file. I do recall there 
being some significance to doing it this way.


I've written this howto for NexentaStor a while back. Perhaps this will 
be of some assistance to complete the configuration of the ZFS Storage 
Appliance too?


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

Please let me know how you get on.



Regards,
Siggi

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

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

[Sigbjorn Lie]

On Tue, December 18, 2012 08:28, Johan Petersson wrote:
> Hi,
>
>
> We are implementing IPA Server and are gong to need to be able to 
> authenticate properly with a
> number of Solaris 11 servers. I have browsed the archives and found a few 
> threads mentioning some
> problems with Solaris 11 and IPA Server. Does anyone know if the issue have 
> been solved?
>
>

I don't think there is any problems with Solaris 11 except of nobody has yet 
sat down and figured
out how to configure it as an IPA client yet.

I had a got at it a while ago (some of the posts you've probably found), and 
found that there was 
enough differences in the LDAP/Kerberos client between Solaris 10 and Solaris 
11 for making it
work with the setup guide I've created for Solaris 10. And there was a need for 
further
investigation for finding out how to configure Solaris 11 as an IPA client.

I've not looked into this further as we do not use Solaris 11 yet.

I don't know if anyone else has had time to sit down and have a crack at this?


Regards,
Siggi


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

Re: [Freeipa-users] netapp filer AD + ipa: possible?

[Sigbjorn Lie]

On Fri, September 7, 2012 16:50, Dmitri Pal wrote:
> On 09/07/2012 07:33 AM, Ondrej Valousek wrote:
>
>> That is actually the main benefit of the 'ldap.ADdomain' parameter. It
>> will allow you to simplify configuration and allows easy load 
>> balancing/failover functionality. We
>> are paying for NetApp support, too so if anyone is going to bug NetApp about 
>> this, I am happy to
>> join you.
>>
>> Ondrej
>>
>>
>> On 09/07/2012 10:07 AM, Sigbjorn Lie wrote:
>>
>>> Yes it would be great if NetApp would do that. The  ldap.ADdomain option is 
>>> used to configure
>>> the NetApp LDAP client from AD SRV DNS records. It would be great (and 
>>> should be easy for
>>> NetApp) to
>>> have an option for ldap.IPAdomain. I don't remember exactly why I did not 
>>> use this for IPA, as
>>> far as I remember most things worked, but I stumbeled across some issue.
>>
>>
>> ___
>> Freeipa-users mailing list
>> Freeipa-users@redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>
> I will.
>
>
> Siggi I will also send you a private email to give you access to the wiki.
>
>


I don't think I ever posted the wiki link for my details around NetApp 
configuration in a mixed
environment... See below.

http://www.freeipa.org/page/NetApp_integration_in_a_mixed_environment



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

Re: [Freeipa-users] User expiration on a certain date

[Sigbjorn Lie]

On Mon, December 17, 2012 19:32, Simo Sorce wrote:
> On Mon, 2012-12-17 at 19:08 +0100, Sigbjorn Lie wrote:
>
>>
>>
>> On Mon, December 17, 2012 18:40, Simo Sorce wrote:
>>
>>> On Mon, 2012-12-17 at 16:04 +0100, Sigbjorn Lie wrote:
>>>
>>>
>>>> Hi,
>>>>
>>>>
>>>>
>>>> Is it possible to lock out an user account on a set date?
>>>>
>>>>
>>>
>>> You should be able to set the krbPrincipalExpiration attribute to expire
>>> an account on a set date.
>>>
>>> However note this: https://fedorahosted.org/freeipa/ticket/3305
>>>
>>>
>>>
>>> It means ti will work with krb auth but not with ldap binds for now.
>>>
>>>
>>>
>>
>> Thanks! That worked like a charm!!
>>
>>
>> Is there any active ticket to have this property exposed for editing in the 
>> IPA CLI / WEBUI?
>>
>
> No, an RFE ticket would be welcome though.
>

Ok, for the record:

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


Rgds,
Siggi


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

Re: [Freeipa-users] User expiration on a certain date

[Sigbjorn Lie]

On Mon, December 17, 2012 18:40, Simo Sorce wrote:
> On Mon, 2012-12-17 at 16:04 +0100, Sigbjorn Lie wrote:
>
>> Hi,
>>
>>
>> Is it possible to lock out an user account on a set date?
>>
>
> You should be able to set the krbPrincipalExpiration attribute to expire
> an account on a set date.
>
> However note this: https://fedorahosted.org/freeipa/ticket/3305
>
>
> It means ti will work with krb auth but not with ldap binds for now.
>
>

Thanks! That worked like a charm!!

Is there any active ticket to have this property exposed for editing in the IPA 
CLI / WEBUI?


Rgds,
Siggi


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

[Freeipa-users] User expiration on a certain date

[Sigbjorn Lie]

Hi,

Is it possible to lock out an user account on a set date?




Regards,
Siggi


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

Re: [Freeipa-users] Solaris 10 and Solaris 11 clients

[Sigbjorn Lie]

Hi,

There was an issue with Solaris 11. I can't remember of the top of my head, I 
believe it had to do
with logins. So ldapclient would run successfully, and kerberos would set up 
successfully as well,
however there we're some issue when logging in.

I suppose it's time to have a closer look at it one of these days...if I can 
find some spare time. :)



Regards,
Siggi



On Wed, November 28, 2012 00:02, Tim Wissman wrote:
> Folks - I have started using FreeIPA and have tried to download the Solaris
> 10 nss-ldap for the intel platform, but when i tried to save the file i
> received an error saying the server had issues. I was able to download the 
> SPARC package from the
> same site. If someone could look into it, it could just be a permissions 
> problem.
>
> As for Solaris 11, has there been any work in that direction yet?
>
>
> thanks.
>
> tim ___
> Freeipa-users mailing list
> Freeipa-users@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] Easy deployment

[Sigbjorn Lie]

On 09/27/2012 03:58 PM, Dmitri Pal wrote:

On 09/25/2012 04:18 PM, Sigbjorn Lie wrote:

On 09/25/2012 12:17 AM, James James wrote:

Hi guys,

we are planning to install 150 freeipa clients and I was wondering 
if there is a way to easily install (from kickstart) nfsv4 client.


I can add host with

# ipa host-add --password=secret

But to get the keytab (host and service), I have to log into the 
machine, launch kinit and get the keytab.


This will be very painful for 150 clients 

Any hints is welcome ...


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

Hi,

I am working on integrating what you are asking for into 
OneClickKick. OneClickKick which is a web based GUI for managing DHCP 
server and PXE booting. The current version can read the host objects 
from IPA's LDAP, and you can use these to generate PXE boot files for 
kickstarting RHEL/Fedora, preseeding Debian/Ubuntu installations, do 
BIOS upgrades, run LIVE environments, etc.


What I have done in the past is to add a line like this to the post 
section of the kickstart:
/usr/sbin/ipa-client-install --domain="ix.test.com" 
--principal="ipajoinuser" --password="somepassword" -U -f


This is not ideal even though the kickstart is saved in a database 
and only made available dynamically trough a php script to the host 
that's enabled for kickstarting. It is not saved in a text file on 
the disk. The next version will include tighter integration with IPA 
where a One Time Password is set for the host being kickstarted at 
the time it's enabled for kickstarting, and this password is seeded 
dynamically when the host is served it's kickstart file.


The next version will also have the PXE Enrollment boot image updated 
to supporting adding new hosts directly into IPA. The PXE Enrollment 
is support for adding a new host simply to PXE booting it, logging 
on, and giving it a hostname and assigning it with a kickstart 
profile to load the machine directly from the console of the new 
machine.


Adding of machines directly to IPA from the web UI will also be 
available in the next version. This allows you to do everything from 
adding the host, to selecting the kickstart profile group, and 
enabling for PXE installation/kickstart in 1 step.


It can also search trough the /var/log/messages file to find new 
hosts that's unknown to it's naming sources and directly add these.


You can also select a group of machine to install, so if you have 
your 150 machines in one group you can select the entire group for 
installation.



See the project website or contact me for more information:
http://sourceforge.net/projects/oneclickkick/




Have you looked at Foreman?


Foreman did not exist back when I started working on OneClickKick.

I've not looked much into Foreman later.



Rgds,
Siggi




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

Re: [Freeipa-users] sudo questions

[Sigbjorn Lie]

On 10/09/2012 04:08 PM, Rob Crittenden wrote:

Sigbjorn Lie wrote:




On Tue, October 9, 2012 01:13, Dmitri Pal wrote:

On 10/08/2012 06:04 PM, Sigbjorn Lie wrote:


Hi,




Thank you for the report!




I've been testing the sudo integration with IPA and I came across some
questions:


1. When I disable or delete a sudo rule, it's not removed from the
ou=sudoers until I restart the directory server. Am I doing 
something wrong?

(389-ds-base-1.2.10.2-20.el6_3.x86_64, slapi-nis-0.40-1.el6.x86_64)




This might be a bug in the compat plugin. The internal tree is 
reflected
into the standard sudo schema that is supposed to be kept in sync 
with the internal tree. However I

would be surprised if there is actually a bug.



I definitely still saw the rules in ou=sudoers even though I disabled 
or deleted the rules.

However the cn=sudo tree was instantly updated.

Could someone else test and see if they see the same behaviour?



2. Perhaps the documentation should mention creating a rule called
"defaults" to put default options for all sudo rules in. Or even
better having one created by default with a fresh IPA installation. 
It took me a few seconds to

figure out where to put default options for all sudo rules.


Can you please open an RFE in trac?
https://fedorahosted.org/freeipa



Ok.







3. sudo integration with SSSD does not work when anonymous LDAP
authentication is disabled at the server. Enabling verbose logging 
in SSSD seem to suggest that

it's attempting  anonymous auth only. (sssd-1.8.4-14.fc17.x86_64)



Which integration you are trying? The one that was tech preview in 1.8?
The one that makes SSSD cache sudo rules? It was significantly 
rewritten

in 1.9. Can you please try with 1.9?



This was F17. There is F17 packages for 1.9 somewhere? Will 1.9 be in 
the next update of RHEL 6?






4. Having spaces in sudo options (such as "env_keep = 'ENV_VAR'") make
sudo display these options as errors when sudo debugging is enabled 
(sudoers_debug 1 in

/etc/ldap.conf or /etc/sudo-ldap.conf):
sudo: unknown defaults entry `env_keep '



Yes. This is a known issue already filed as a ticket.



OK





5. It would be great to have a set of sudo commands and a set of sudo
command groups installed by default.


Can you make a proposal about what groups would you like to see in 
an RFE?

https://fedorahosted.org/freeipa



Sure. I do believe in having only 1 sudoers source, either a file or 
ldap. So I I believe the
contents of the file /etc/sudoers distributed with the sudoers 
package is a good starting point.










6. Adding a sudo command having multiple commands listed (such as:
"/sbin/route, /sbin/ifconfig, /bin/ping
<https://lieipa01.ix.nixtra.com/ipa/ui/#/sbin/route,%20/sbin/ifconfig,%20/bin/ping,%20/sbin/dhcl 

ient,%20/usr/bin/net,%20/sbin/iptables,%20/usr/bin/%20rfcomm,%20/usr/bin/wvdial,%20/sbin/iwconf 

ig,%20/sbin/mii-tool>") is allowed in IPA and does list it 
correctly as allowed commands when
doing "sudo -l", however attempting to execute one of the commands 
in the list using sudo fails.





Can you please try SSSD 1.9?


Sure, but I'm not sure how that is going to matter as this is sudo 
returning an error. How is it
expected to be different when the information is coming from a 
different source?


I believe we have to do the LDAP way and not the SSSD way in 
production though as we have clients
such as older RHEL and Solaris as well besides RHEL 6. So this should 
be fixed regardsless of
where the sudo source is coming from. And I believe we are not alone 
here in having a mixed

environment... :)


Your command is allowing a user to pass the arguments /sbin/ifconfig, 
/bin/ping to /sbin/iparoute, (note the commas). A sudo command is a 
single invocation of a command.


rob


I am well aware of that. :)

However that is an allowed syntax in file based sudoers.

I believe there should be a syntax checking in IPA when adding sudo 
commands since it's not working with ldap based sudoers.



Regards,
Siggi

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

Re: [Freeipa-users] sudo questions

[Sigbjorn Lie]

On Tue, October 9, 2012 07:59, Jakub Hrozek wrote:
> On Tue, Oct 09, 2012 at 12:04:24AM +0200, Sigbjorn Lie wrote:
>
>> Hi,
>>
>>
>
> Hi Siggi,
>
>
>> 3. sudo integration with SSSD does not work when anonymous LDAP
>> authentication is disabled at the server. Enabling verbose logging in SSSD 
>> seem to suggest that
>> it's attempting  anonymous auth only. (sssd-1.8.4-14.fc17.x86_64)
>>
>
> This is a known limitation of both 1.8 and 1.9. SSSD-1.9 documentation
> includes an example on how to configure the sudo provider against an IPA 
> server:
> http://jhrozek.fedorapeople.org/sssd/1.9.1/man/sssd-sudo.5.html
>
>
> We're tracking creating a native IPA sudo backend in SSSD-1.10:
> https://fedorahosted.org/sssd/ticket/1108
>

OK


>
>> 6. Adding a sudo command having multiple commands listed (such as:
>> "/sbin/route, /sbin/ifconfig, /bin/ping
>> <https://lieipa01.ix.nixtra.com/ipa/ui/#/sbin/route,%20/sbin/ifconfig,%20/bin/ping,%20/sbin/dhc
>> lient,%20/usr/bin/net,%20/sbin/iptables,%20/usr/bin/%20rfcomm,%20/usr/bin/wvdial,%20/sbin/iwcon
>> fig,%20/sbin/mii-tool>") is allowed in IPA and does list it correctly as 
>> allowed commands when
>> doing "sudo -l", however attempting to execute one of the commands in the 
>> list using sudo fails.
>>
>
> This was with SSSD or nss-pam-ldapd?


ldap directly, not sssd.


regards,
Siggi


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

Re: [Freeipa-users] sudo questions

[Sigbjorn Lie]

On Tue, October 9, 2012 01:13, Dmitri Pal wrote:
> On 10/08/2012 06:04 PM, Sigbjorn Lie wrote:
>
>> Hi,
>>
>
>
> Thank you for the report!
>
>
>>
>> I've been testing the sudo integration with IPA and I came across some
>> questions:
>>
>>
>> 1. When I disable or delete a sudo rule, it's not removed from the
>> ou=sudoers until I restart the directory server. Am I doing something wrong?
>> (389-ds-base-1.2.10.2-20.el6_3.x86_64, slapi-nis-0.40-1.el6.x86_64)
>>
>>
>
> This might be a bug in the compat plugin. The internal tree is reflected
> into the standard sudo schema that is supposed to be kept in sync with the 
> internal tree. However I
> would be surprised if there is actually a bug.
>

I definitely still saw the rules in ou=sudoers even though I disabled or 
deleted the rules.
However the cn=sudo tree was instantly updated.

Could someone else test and see if they see the same behaviour?


>> 2. Perhaps the documentation should mention creating a rule called
>> "defaults" to put default options for all sudo rules in. Or even
>> better having one created by default with a fresh IPA installation. It took 
>> me a few seconds to
>> figure out where to put default options for all sudo rules.
>
> Can you please open an RFE in trac?
> https://fedorahosted.org/freeipa
>

Ok.


>
>
>>
>> 3. sudo integration with SSSD does not work when anonymous LDAP
>> authentication is disabled at the server. Enabling verbose logging in SSSD 
>> seem to suggest that
>> it's attempting  anonymous auth only. (sssd-1.8.4-14.fc17.x86_64)
>>
>
> Which integration you are trying? The one that was tech preview in 1.8?
> The one that makes SSSD cache sudo rules? It was significantly rewritten
> in 1.9. Can you please try with 1.9?
>

This was F17. There is F17 packages for 1.9 somewhere? Will 1.9 be in the next 
update of RHEL 6?

>
>>
>> 4. Having spaces in sudo options (such as "env_keep = 'ENV_VAR'") make
>> sudo display these options as errors when sudo debugging is enabled 
>> (sudoers_debug 1 in
>> /etc/ldap.conf or /etc/sudo-ldap.conf):
>> sudo: unknown defaults entry `env_keep '
>>
>
> Yes. This is a known issue already filed as a ticket.
>

OK

>
>>
>> 5. It would be great to have a set of sudo commands and a set of sudo
>> command groups installed by default.
>
> Can you make a proposal about what groups would you like to see in an RFE?
> https://fedorahosted.org/freeipa
>

Sure. I do believe in having only 1 sudoers source, either a file or ldap. So I 
I believe the
contents of the file /etc/sudoers distributed with the sudoers package is a 
good starting point.




>
>
>>
>> 6. Adding a sudo command having multiple commands listed (such as:
>> "/sbin/route, /sbin/ifconfig, /bin/ping
>> <https://lieipa01.ix.nixtra.com/ipa/ui/#/sbin/route,%20/sbin/ifconfig,%20/bin/ping,%20/sbin/dhcl
>> ient,%20/usr/bin/net,%20/sbin/iptables,%20/usr/bin/%20rfcomm,%20/usr/bin/wvdial,%20/sbin/iwconf
>> ig,%20/sbin/mii-tool>") is allowed in IPA and does list it correctly as 
>> allowed commands when
>> doing "sudo -l", however attempting to execute one of the commands in the 
>> list using sudo fails.
>>
>>
>
> Can you please try SSSD 1.9?

Sure, but I'm not sure how that is going to matter as this is sudo returning an 
error. How is it
expected to be different when the information is coming from a different source?

I believe we have to do the LDAP way and not the SSSD way in production though 
as we have clients
such as older RHEL and Solaris as well besides RHEL 6. So this should be fixed 
regardsless of
where the sudo source is coming from. And I believe we are not alone here in 
having a mixed
environment... :)

File a bug?



Regards,
Siggi





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

[Freeipa-users] sudo questions

[Sigbjorn Lie]

Hi,

I've been testing the sudo integration with IPA and I came across some 
questions:


1. When I disable or delete a sudo rule, it's not removed from the 
ou=sudoers until I restart the directory server. Am I doing something 
wrong? (389-ds-base-1.2.10.2-20.el6_3.x86_64, slapi-nis-0.40-1.el6.x86_64)


2. Perhaps the documentation should mention creating a rule called 
"defaults" to put default options for all sudo rules in. Or even better 
having one created by default with a fresh IPA installation. It took me 
a few seconds to figure out where to put default options for all sudo rules.


3. sudo integration with SSSD does not work when anonymous LDAP 
authentication is disabled at the server. Enabling verbose logging in 
SSSD seem to suggest that it's attempting  anonymous auth only. 
(sssd-1.8.4-14.fc17.x86_64)


4. Having spaces in sudo options (such as "env_keep = 'ENV_VAR'") make 
sudo display these options as errors when sudo debugging is enabled 
(sudoers_debug 1 in /etc/ldap.conf or /etc/sudo-ldap.conf):

sudo: unknown defaults entry `env_keep '

5. It would be great to have a set of sudo commands and a set of sudo 
command groups installed by default.


6. Adding a sudo command having multiple commands listed (such as: 
"/sbin/route, /sbin/ifconfig, /bin/ping 
") 
is allowed in IPA and does list it correctly as allowed commands when 
doing "sudo -l", however attempting to execute one of the commands in 
the list using sudo fails.


I did my testing with IPA server 2.2 in CentOS 6.3.



Regards,
Siggi

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

Re: [Freeipa-users] Apache, autofs and userdir

[Sigbjorn Lie]

On 09/26/2012 12:21 AM, James James wrote:
Hi, I don't know if this is the right place to ask this question but I 
will try.


I have  :

- a freeipa server + autofs maps
- a nfsv4 server
- a web server

from the webserver I can mount my nfs4 exported home dir. Everything 
works well.


I want to acces to my public_html directory from the web server. From 
my browser, when I try to reach http://myweserver/~user 
, I've got 403 Forbidden and the logs give 
me :


Sep 25 23:18:21 web-server rpc.gssd[4522]: WARNING: Failed to create 
krb5 context for user with uid 48 for server nfs-server.example.com 


Sep 25 23:18:21 web-server rpc.gssd[4522]: doing error downcall
Sep 25 23:18:21 web-server rpc.gssd[4522]: handling gssd upcall 
(/var/lib/nfs/rpc_pipefs/nfs/clnte2)
Sep 25 23:18:21 web-server rpc.gssd[4522]: handle_gssd_upcall: 
'mech=krb5 uid=48 enctypes=18,17,16,23,3,1,2 '
Sep 25 23:18:21 web-server rpc.gssd[4522]: handling krb5 upcall 
(/var/lib/nfs/rpc_pipefs/nfs/clnte2)
Sep 25 23:18:21 web-server rpc.gssd[4522]: process_krb5_upcall: 
service is ''
Sep 25 23:18:21 web-server rpc.gssd[4522]: getting credentials for 
client with uid 48 for server nfs-server.example.com 

Sep 25 23:18:21 web-server rpc.gssd[4522]: CC file 
'/tmp/krb5cc_797200160_Aqx6OL' being considered, with preferred realm 
'EXAMPLE.COM '
Sep 25 23:18:21 web-server rpc.gssd[4522]: CC file 
'/tmp/krb5cc_797200160_Aqx6OL' owned by 797200160, not 48
Sep 25 23:18:21 web-server rpc.gssd[4522]: CC file '/tmp/krb5cc_0' 
being considered, with preferred realm 'EXAMPLE.COM '
Sep 25 23:18:21 web-server rpc.gssd[4522]: CC file '/tmp/krb5cc_0' 
owned by 0, not 48
Sep 25 23:18:21 web-server rpc.gssd[4522]: WARNING: Failed to create 
krb5 context for user with uid 48 for server nfs-server.example.com 




Apache user id is 48.

Thanks for any help.

James


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



Are you using nfs4 + krb5 as auth for your home directories?

If so, what it's telling you is that it's unable to retreive kerberos 
credentials for the apache user (uid 48). I believe you have to create a 
user account for apache in IPA, initiate credentials for this user (and 
renew them when they expire), and set the KRB5CCNAME environment 
variable to point to the credendials cache in the startup script for 
httpd. A cronjob or similar would be required to keep renewing the 
credentials, I have not looked into this myself yet so I cannot give 
exact feedback for this.


Make sure the IPA user account that you provide credentials for have 
access to read the users public_html directory and list the users home 
directory.


Let me know how you get on. I haven't tested this myself yet but it's 
been on my mind.



Regards,
Siggi

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

Re: [Freeipa-users] Easy deployment

[Sigbjorn Lie]

On 09/25/2012 12:17 AM, James James wrote:

Hi guys,

we are planning to install 150 freeipa clients and I was wondering if 
there is a way to easily install (from kickstart) nfsv4 client.


I can add host with

# ipa host-add --password=secret

But to get the keytab (host and service), I have to log into the 
machine, launch kinit and get the keytab.


This will be very painful for 150 clients 

Any hints is welcome ...


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

Hi,

I am working on integrating what you are asking for into OneClickKick. 
OneClickKick which is a web based GUI for managing DHCP server and PXE 
booting. The current version can read the host objects from IPA's LDAP, 
and you can use these to generate PXE boot files for kickstarting 
RHEL/Fedora, preseeding Debian/Ubuntu installations, do BIOS upgrades, 
run LIVE environments, etc.


What I have done in the past is to add a line like this to the post 
section of the kickstart:
/usr/sbin/ipa-client-install --domain="ix.test.com" 
--principal="ipajoinuser" --password="somepassword" -U -f


This is not ideal even though the kickstart is saved in a database and 
only made available dynamically trough a php script to the host that's 
enabled for kickstarting. It is not saved in a text file on the disk. 
The next version will include tighter integration with IPA where a One 
Time Password is set for the host being kickstarted at the time it's 
enabled for kickstarting, and this password is seeded dynamically when 
the host is served it's kickstart file.


The next version will also have the PXE Enrollment boot image updated to 
supporting adding new hosts directly into IPA. The PXE Enrollment is 
support for adding a new host simply to PXE booting it, logging on, and 
giving it a hostname and assigning it with a kickstart profile to load 
the machine directly from the console of the new machine.


Adding of machines directly to IPA from the web UI will also be 
available in the next version. This allows you to do everything from 
adding the host, to selecting the kickstart profile group, and enabling 
for PXE installation/kickstart in 1 step.


It can also search trough the /var/log/messages file to find new hosts 
that's unknown to it's naming sources and directly add these.


You can also select a group of machine to install, so if you have your 
150 machines in one group you can select the entire group for installation.



See the project website or contact me for more information:
http://sourceforge.net/projects/oneclickkick/



Regards,
Siggi

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

Re: [Freeipa-users] Do we need ipa-client-update script?

[Sigbjorn Lie]

On 09/21/2012 10:45 AM, Petr Spacek wrote:

Hello users,

we have a question for client machine administrators:

On 09/21/2012 10:12 AM, Martin Kosek wrote:

> ..., that it may be useful to implement a script
> like "ipa-client-update" which would be capable of updating client 
information
> (and could be entered in a cron for example) without a need to 
re-enroll

> client. Such script could for example:
> * update SSH keys of the client
> * update a list of IPA DNS servers in #3095
> * ...
>
> Martin

Would it be useful at all? What other information should updater 
maintain?


Ad https://fedorahosted.org/freeipa/ticket/3095:
IMHO DNS configuration on client side is job for DHCP or Puppet. Isn't 
it?




A client update script for SSH keys setup etc has crossed my mind too. 
Such a script would be useful, however the various updates should be 
available as separate options to the command so the admin can choose 
between applying some options or all options. A --update-all could be 
used as a place holder for updating the whole collection of options.


As far as #3095 goes, updating the DNS client configuration is a job for 
DHCP or Puppet/CFengine. SSSD is very much dependent on DNS to work. I 
don't see why SSSD should be able to change the systems DNS servers, 
possibly rendering itself useless.




Regards,
Siggi

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

Re: [Freeipa-users] ipa host-add having both an IPv4 and an IPv6 address

[Sigbjorn Lie]

On 09/21/2012 10:29 AM, Martin Kosek wrote:

On 09/20/2012 10:35 PM, Sigbjorn Lie wrote:

Hi,

I see that I can add hosts with either an IPv4 or an IPv6 address when using
"ipa host-add --ip-address=".

Is there a way to add a host specifying both an IPv4 and an IPv6 address at the
same time?

Adding the --ip-address option twice yells this error:

ipa: ERROR: invalid 'ip_address': Only one value is allowed



Regards,
Siggi

Hello Signbjorn,

Unfortunately, host-add only accepts one IP address to be specified for the
given host. But allowing more addresses is a reasonable request, I filed an
upstream ticket:
https://fedorahosted.org/freeipa/ticket/3101

Until the ticket is addresses, you can manually add host IP addresses via
dnsrecord-add command:

# ipa host-add foo.example.com --ip-address 10.16.78.101

Added host "foo.example.com"

   Host name: foo.example.com
   Principal name: host/foo.example@idm.lab.bos.redhat.com
   Password: False
   Keytab: False
   Managed by: foo.example.com
# ipa dnsrecord-add example.com foo --a-rec=10.16.78.111 --a-create-reverse
   Record name: foo
   A record: 10.16.78.101, 10.16.78.111
# ipa dnsrecord-add example.com foo
---rec=2620:52:0:104c:21a:4aff:fe10:4e06 ---create-reverse
   Record name: foo
   A record: 10.16.78.101, 10.16.78.111
    record: 2620:52:0:104c:21a:4aff:fe10:4e06
# host foo.example.com
foo.example.com has address 10.16.78.111
foo.example.com has address 10.16.78.101
foo.example.com has IPv6 address 2620:52:0:104c:21a:4aff:fe10:4e06

HTH,
Martin



Thank you. I know of the dnsrecord-add options, however I was looking 
for a way to do it during host-add. Less typing. :)




Regards,
Siggi

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

Re: [Freeipa-users] krb5-server-1.9-33.el6_3.3.x86_64 prevents named from starting when selinux is enforcing

[Sigbjorn Lie]

On 09/21/2012 02:47 PM, Rob Crittenden wrote:

Simo Sorce wrote:

- Original Message -

Sigbjorn Lie wrote:

On 09/20/2012 10:17 PM, Rob Crittenden wrote:

bind isn't my strongest suite.

My guess is that this file is the ccache for bind. I'm guessing
that
25 is the UID of the named user. If this is the case, then it
should
be safe to stop named, rename the file, and restart. Perhaps the
contexts have changed so when this gets re-created it will get
fixed
automagically.

rob


You guessed well!! :)

Stop named:
# service named stop

Enable selinux:
# setenforce 1

Verify that error still exists:
# service named start
Starting named: [FAILED]

Rename file:
# cd /var/tmp
# mv DNS_25 DNS_25_old

Attempt to start named again:
# service named start
Starting named: [  OK  ]

Voila!

A before and after shot:
# ls -lZ DNS_25*
-rw---. named named unconfined_u:object_r:named_tmp_t:s0 DNS_25
-rw---. named named system_u:object_r:tmp_t:s0 DNS_25_old

What's the odds that this was the entire issue and that named will
now
keep running safe and sound?



Hard to say. Because restorecon didn't fix the bad context I suspect
this isn't directly covered in policy. So if the file should get the
wrong context again you could be back in this position. It is
probably
worth filing a bug. I'm not entirely sure whether it should be
against
bind or selinux, but it'll get to the right folks either way
eventually.


That file is the reply-cache, and it's context is set at runtime by the
krb5 library. It did get out of sync because selinux was disabled, and
restorecon, can't fix the label because the file is in a tmp directory,
so it just takes the tmp_t context by default.

If selinux is not completely disable this shouldn't happen anymore, 
however,
should it happen you can simply remove the file, it is not vital and 
will

get recreated after you restart named.

Simo.



AFAIK he never disabled SELinux. He put it into permissive temporarily 
to get going again while we diagnosed this but before and after the 
krb5-server upgrade he was in enforcing mode.


I wonder if the krb5-server upgrade caused a filesystem relabel and 
this is what hosed the /var/tmp entry.


rob


This is my test environment, and I disabled SElinux completely after the 
upgrade to 2.2 as I got annoyed with how slow it was. The "yum upgrade" 
occured while SElinux was in disabled mode. I then set selinux=enforcing 
in /etc/sysconfig/selinux and rebooted after yum upgrade completed. I 
then set SElinux to permissive during the troubleshooting we did a few 
days ago.


My production environment still got SElinux set to enforcing, and the 
krb5-server has not yet been upgraded until these issues has been clarified.


I'm sorry for the confusion.

Is the conclusion that I'm having this issue in the first place because 
SElinux was disabled when I did "yum upgrade" ?





Regards,
Siggi

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

Re: [Freeipa-users] krb5-server-1.9-33.el6_3.3.x86_64 prevents named from starting when selinux is enforcing

[Sigbjorn Lie]

On 09/20/2012 10:34 PM, Rob Crittenden wrote:

Sigbjorn Lie wrote:

On 09/20/2012 10:17 PM, Rob Crittenden wrote:

bind isn't my strongest suite.

My guess is that this file is the ccache for bind. I'm guessing that
25 is the UID of the named user. If this is the case, then it should
be safe to stop named, rename the file, and restart. Perhaps the
contexts have changed so when this gets re-created it will get fixed
automagically.

rob


You guessed well!! :)

Stop named:
# service named stop

Enable selinux:
# setenforce 1

Verify that error still exists:
# service named start
Starting named: [FAILED]

Rename file:
# cd /var/tmp
# mv DNS_25 DNS_25_old

Attempt to start named again:
# service named start
Starting named:[ OK  ]

Voila!

A before and after shot:
# ls -lZ DNS_25*
-rw---. named named unconfined_u:object_r:named_tmp_t:s0 DNS_25
-rw---. named named system_u:object_r:tmp_t:s0 DNS_25_old

What's the odds that this was the entire issue and that named will now
keep running safe and sound?



Hard to say. Because restorecon didn't fix the bad context I suspect 
this isn't directly covered in policy. So if the file should get the 
wrong context again you could be back in this position. It is probably 
worth filing a bug. I'm not entirely sure whether it should be against 
bind or selinux, but it'll get to the right folks either way eventually.


rob

Filed to the krb people for now.

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



Regards,
Siggi

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

[Freeipa-users] ipa host-add having both an IPv4 and an IPv6 address

[Sigbjorn Lie]

Hi,

I see that I can add hosts with either an IPv4 or an IPv6 address when 
using "ipa host-add --ip-address=".


Is there a way to add a host specifying both an IPv4 and an IPv6 address 
at the same time?


Adding the --ip-address option twice yells this error:

ipa: ERROR: invalid 'ip_address': Only one value is allowed



Regards,
Siggi

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

Re: [Freeipa-users] krb5-server-1.9-33.el6_3.3.x86_64 prevents named from starting when selinux is enforcing

[Sigbjorn Lie]

On 09/20/2012 10:17 PM, Rob Crittenden wrote:

Sigbjorn Lie wrote:

On 09/20/2012 12:08 AM, Rob Crittenden wrote:

Sigbjorn Lie wrote:

On 09/19/2012 11:05 PM, Rob Crittenden wrote:

Sigbjorn Lie wrote:

On 09/19/2012 10:48 PM, Rob Crittenden wrote:

Sigbjorn Lie wrote:

Hi,

I noticed an updated krb5-server package today advertising that 
it's

fixing the issue with slow GSSAPI binds discussed earlier, so I
installed it in my test environment, set SElinux back to
enforcing in
/etc/sysconfig/selinux and rebooted.

The named daemon does not start now. The error below was logged in
/var/log/messages:

Sep 19 21:54:46 ipa01 named[3712]: GSSAPI Error: Unspecified GSS
failure.  Minor code may provide more information (KDC returned
error
string: PROCESS_TGS)

I am able to start named after setting SElinux in permissive mode
(setenforce 0).

Then to verify: I stop all IPA services (ipactl stop), reenabled
selinux
(setenforce 1), and start the IPA services (ipactl start). A new
error
is logged in /var/log/messages:

Sep 19 22:00:49 ipa01 named[5918]: bind to LDAP server failed:
Invalid
credentials
Sep 19 22:00:49 ipa01 named[5918]: loading configuration: 
permission

denied
Sep 19 22:00:49 ipa01 named[5918]: exiting (due to fatal error)


 From the /var/log/krb5kdc.log:
Sep 19 21:54:46 ipa01.ix.test.com krb5kdc[3681](info): TGS_REQ (4
etypes
{18 17 16 23}) 192.168.210.20: PROCESS_TGS: authtime 0, 
for , Cannot create replay cache file
/var/tmp/krbtgt_0:
File exists
Sep 19 21:54:46 ipa01.ix.test.com krb5kdc[3681](info): TGS_REQ (4
etypes
{18 17 16 23}) 192.168.210.20: PROCESS_TGS: authtime 0, 
for , Cannot create replay cache file
/var/tmp/krbtgt_0:
File exists
Sep 19 21:54:46 ipa01.ix.test.com krb5kdc[3681](info): AS_REQ (4
etypes
{18 17 16 23}) 192.168.210.20: NEEDED_PREAUTH:
DNS/ipa01.ix.test@ix.test.com for
krbtgt/ix.test@ix.test.com,
Additional pre-authentication required
Sep 19 21:54:46 ipa01.ix.test.com krb5kdc[3681](info): AS_REQ (4
etypes
{18 17 16 23}) 192.168.210.20: ISSUE: authtime 1348084486, etypes
{rep=18 tkt=18 ses=18}, DNS/ipa01.ix.test@ix.test.com for
krbtgt/ix.test@ix.test.com

/var/named/data/named.run logged nothing.



Any suggestions for how to troubleshoot this issue?


Pure guess, but:

restorecon /var/tmp/krbtgt_0

rob
Sorry, that did not help. There seem to be a new error in the 
messages

file every time I attempt a named restart though. See below for the
latest:

Sep 19 23:01:27 ipa01 named[12638]: default realm from krb5.conf
(IX.TEST.COM) does not match tkey-gssapi-credential
(DNS/ipa01.ix.test.com)
Sep 19 23:01:27 ipa01 named[12638]: configuring TKEY: failure
Sep 19 23:01:27 ipa01 named[12638]: loading configuration: failure
Sep 19 23:01:27 ipa01 named[12638]: exiting (due to fatal error)


I'd continue to check /var/log/audit/audit.log for AVCs.

rob



OK, I had a quick look before I'm off for today. :)

There's a lot of these messages, denying named access to
/var/tmp/DNS_25.



type=AVC msg=audit(1348086955.397:42404): avc:  denied  { getattr } 
for

pid=11648 comm="named" path="/var/tmp/DNS_25" dev=dm-2 ino=132140
scontext=unconfined_u:system_r:named_t:s0
tcontext=system_u:object_r:tmp_t:s0 tclass=file
type=AVC msg=audit(1348086955.398:42405): avc:  denied  { read write }
for  pid=11648 comm="named" name="DNS_25" dev=dm-2 ino=132140
scontext=unconfined_u:system_r:named_t:s0
tcontext=system_u:object_r:tmp_t:s0 tclass=file
type=AVC msg=audit(1348086955.398:42405): avc:  denied  { open } for
pid=11648 comm="named" name="DNS_25" dev=dm-2 ino=132140
scontext=unconfined_u:system_r:named_t:s0
tcontext=system_u:object_r:tmp_t:s0 tclass=file
type=AVC msg=audit(1348088487.524:42438): avc:  denied  { getattr } 
for

pid=12639 comm="named" path="/var/tmp/DNS_25" dev=dm-2 ino=132140
scontext=unconfined_u:system_r:named_t:s0
tcontext=system_u:object_r:tmp_t:s0 tclass=file
type=AVC msg=audit(1348088487.524:42439): avc:  denied  { unlink } for
pid=12639 comm="named" name="DNS_25" dev=dm-2 ino=132140
scontext=unconfined_u:system_r:named_t:s0
tcontext=system_u:object_r:tmp_t:s0 tclass=file
type=AVC msg=audit(1348088487.525:42440): avc:  denied  { getattr } 
for

pid=12639 comm="named" path="/var/tmp/DNS_25" dev=dm-2 ino=132140
scontext=unconfined_u:system_r:named_t:s0
tcontext=system_u:object_r:tmp_t:s0 tclass=file
type=AVC msg=audit(1348088487.525:42441): avc:  denied  { unlink } for
pid=12639 comm="named" name="DNS_25" dev=dm-2 ino=132140
scontext=unconfined_u:system_r:named_t:s0
tcontext=system_u:object_r:tmp_t:s0 tclass=file
type=AVC msg=audit(1348088487.525:42442): avc:  denied  { getattr } 
for

pid=12639 comm="named" path="/var/tmp/DNS_25" dev=dm-2 ino=132140
scontext=unconfined_u:system_r:named_t:s0
tcontext=system_u:object_r:tmp_t:s0 tclass=file
type=AVC msg=audit(1348088487.525:42443): avc:

Re: [Freeipa-users] krb5-server-1.9-33.el6_3.3.x86_64 prevents named from starting when selinux is enforcing

[Sigbjorn Lie]

On 09/20/2012 12:08 AM, Rob Crittenden wrote:

Sigbjorn Lie wrote:

On 09/19/2012 11:05 PM, Rob Crittenden wrote:

Sigbjorn Lie wrote:

On 09/19/2012 10:48 PM, Rob Crittenden wrote:

Sigbjorn Lie wrote:

Hi,

I noticed an updated krb5-server package today advertising that it's
fixing the issue with slow GSSAPI binds discussed earlier, so I
installed it in my test environment, set SElinux back to 
enforcing in

/etc/sysconfig/selinux and rebooted.

The named daemon does not start now. The error below was logged in
/var/log/messages:

Sep 19 21:54:46 ipa01 named[3712]: GSSAPI Error: Unspecified GSS
failure.  Minor code may provide more information (KDC returned 
error

string: PROCESS_TGS)

I am able to start named after setting SElinux in permissive mode
(setenforce 0).

Then to verify: I stop all IPA services (ipactl stop), reenabled
selinux
(setenforce 1), and start the IPA services (ipactl start). A new 
error

is logged in /var/log/messages:

Sep 19 22:00:49 ipa01 named[5918]: bind to LDAP server failed: 
Invalid

credentials
Sep 19 22:00:49 ipa01 named[5918]: loading configuration: permission
denied
Sep 19 22:00:49 ipa01 named[5918]: exiting (due to fatal error)


 From the /var/log/krb5kdc.log:
Sep 19 21:54:46 ipa01.ix.test.com krb5kdc[3681](info): TGS_REQ (4
etypes
{18 17 16 23}) 192.168.210.20: PROCESS_TGS: authtime 0, 
for , Cannot create replay cache file
/var/tmp/krbtgt_0:
File exists
Sep 19 21:54:46 ipa01.ix.test.com krb5kdc[3681](info): TGS_REQ (4
etypes
{18 17 16 23}) 192.168.210.20: PROCESS_TGS: authtime 0, 
for , Cannot create replay cache file
/var/tmp/krbtgt_0:
File exists
Sep 19 21:54:46 ipa01.ix.test.com krb5kdc[3681](info): AS_REQ (4
etypes
{18 17 16 23}) 192.168.210.20: NEEDED_PREAUTH:
DNS/ipa01.ix.test@ix.test.com for 
krbtgt/ix.test@ix.test.com,

Additional pre-authentication required
Sep 19 21:54:46 ipa01.ix.test.com krb5kdc[3681](info): AS_REQ (4
etypes
{18 17 16 23}) 192.168.210.20: ISSUE: authtime 1348084486, etypes
{rep=18 tkt=18 ses=18}, DNS/ipa01.ix.test@ix.test.com for
krbtgt/ix.test@ix.test.com

/var/named/data/named.run logged nothing.



Any suggestions for how to troubleshoot this issue?


Pure guess, but:

restorecon /var/tmp/krbtgt_0

rob

Sorry, that did not help. There seem to be a new error in the messages
file every time I attempt a named restart though. See below for the
latest:

Sep 19 23:01:27 ipa01 named[12638]: default realm from krb5.conf
(IX.TEST.COM) does not match tkey-gssapi-credential
(DNS/ipa01.ix.test.com)
Sep 19 23:01:27 ipa01 named[12638]: configuring TKEY: failure
Sep 19 23:01:27 ipa01 named[12638]: loading configuration: failure
Sep 19 23:01:27 ipa01 named[12638]: exiting (due to fatal error)


I'd continue to check /var/log/audit/audit.log for AVCs.

rob



OK, I had a quick look before I'm off for today. :)

There's a lot of these messages, denying named access to 
/var/tmp/DNS_25.




type=AVC msg=audit(1348086955.397:42404): avc:  denied  { getattr } for
pid=11648 comm="named" path="/var/tmp/DNS_25" dev=dm-2 ino=132140
scontext=unconfined_u:system_r:named_t:s0
tcontext=system_u:object_r:tmp_t:s0 tclass=file
type=AVC msg=audit(1348086955.398:42405): avc:  denied  { read write }
for  pid=11648 comm="named" name="DNS_25" dev=dm-2 ino=132140
scontext=unconfined_u:system_r:named_t:s0
tcontext=system_u:object_r:tmp_t:s0 tclass=file
type=AVC msg=audit(1348086955.398:42405): avc:  denied  { open } for
pid=11648 comm="named" name="DNS_25" dev=dm-2 ino=132140
scontext=unconfined_u:system_r:named_t:s0
tcontext=system_u:object_r:tmp_t:s0 tclass=file
type=AVC msg=audit(1348088487.524:42438): avc:  denied  { getattr } for
pid=12639 comm="named" path="/var/tmp/DNS_25" dev=dm-2 ino=132140
scontext=unconfined_u:system_r:named_t:s0
tcontext=system_u:object_r:tmp_t:s0 tclass=file
type=AVC msg=audit(1348088487.524:42439): avc:  denied  { unlink } for
pid=12639 comm="named" name="DNS_25" dev=dm-2 ino=132140
scontext=unconfined_u:system_r:named_t:s0
tcontext=system_u:object_r:tmp_t:s0 tclass=file
type=AVC msg=audit(1348088487.525:42440): avc:  denied  { getattr } for
pid=12639 comm="named" path="/var/tmp/DNS_25" dev=dm-2 ino=132140
scontext=unconfined_u:system_r:named_t:s0
tcontext=system_u:object_r:tmp_t:s0 tclass=file
type=AVC msg=audit(1348088487.525:42441): avc:  denied  { unlink } for
pid=12639 comm="named" name="DNS_25" dev=dm-2 ino=132140
scontext=unconfined_u:system_r:named_t:s0
tcontext=system_u:object_r:tmp_t:s0 tclass=file
type=AVC msg=audit(1348088487.525:42442): avc:  denied  { getattr } for
pid=12639 comm="named" path="/var/tmp/DNS_25" dev=dm-2 ino=132140
scontext=unconfined_u:system_r:named_t:s0
tcontext=system_u:object_r:tmp_t:s0 tclass=file
type=AVC msg=audit(1348088487.525:42443): avc:  denied  { unlink } for
pid=12639 comm="named" name=&quo

Re: [Freeipa-users] krb5-server-1.9-33.el6_3.3.x86_64 prevents named from starting when selinux is enforcing

[Sigbjorn Lie]

On 09/19/2012 11:05 PM, Rob Crittenden wrote:

Sigbjorn Lie wrote:

On 09/19/2012 10:48 PM, Rob Crittenden wrote:

Sigbjorn Lie wrote:

Hi,

I noticed an updated krb5-server package today advertising that it's
fixing the issue with slow GSSAPI binds discussed earlier, so I
installed it in my test environment, set SElinux back to enforcing in
/etc/sysconfig/selinux and rebooted.

The named daemon does not start now. The error below was logged in
/var/log/messages:

Sep 19 21:54:46 ipa01 named[3712]: GSSAPI Error: Unspecified GSS
failure.  Minor code may provide more information (KDC returned error
string: PROCESS_TGS)

I am able to start named after setting SElinux in permissive mode
(setenforce 0).

Then to verify: I stop all IPA services (ipactl stop), reenabled 
selinux

(setenforce 1), and start the IPA services (ipactl start). A new error
is logged in /var/log/messages:

Sep 19 22:00:49 ipa01 named[5918]: bind to LDAP server failed: Invalid
credentials
Sep 19 22:00:49 ipa01 named[5918]: loading configuration: permission
denied
Sep 19 22:00:49 ipa01 named[5918]: exiting (due to fatal error)


 From the /var/log/krb5kdc.log:
Sep 19 21:54:46 ipa01.ix.test.com krb5kdc[3681](info): TGS_REQ (4 
etypes
{18 17 16 23}) 192.168.210.20: PROCESS_TGS: authtime 0, client>
for , Cannot create replay cache file 
/var/tmp/krbtgt_0:

File exists
Sep 19 21:54:46 ipa01.ix.test.com krb5kdc[3681](info): TGS_REQ (4 
etypes
{18 17 16 23}) 192.168.210.20: PROCESS_TGS: authtime 0, client>
for , Cannot create replay cache file 
/var/tmp/krbtgt_0:

File exists
Sep 19 21:54:46 ipa01.ix.test.com krb5kdc[3681](info): AS_REQ (4 
etypes

{18 17 16 23}) 192.168.210.20: NEEDED_PREAUTH:
DNS/ipa01.ix.test@ix.test.com for krbtgt/ix.test@ix.test.com,
Additional pre-authentication required
Sep 19 21:54:46 ipa01.ix.test.com krb5kdc[3681](info): AS_REQ (4 
etypes

{18 17 16 23}) 192.168.210.20: ISSUE: authtime 1348084486, etypes
{rep=18 tkt=18 ses=18}, DNS/ipa01.ix.test@ix.test.com for
krbtgt/ix.test@ix.test.com

/var/named/data/named.run logged nothing.



Any suggestions for how to troubleshoot this issue?


Pure guess, but:

restorecon /var/tmp/krbtgt_0

rob

Sorry, that did not help. There seem to be a new error in the messages
file every time I attempt a named restart though. See below for the 
latest:


Sep 19 23:01:27 ipa01 named[12638]: default realm from krb5.conf
(IX.TEST.COM) does not match tkey-gssapi-credential 
(DNS/ipa01.ix.test.com)

Sep 19 23:01:27 ipa01 named[12638]: configuring TKEY: failure
Sep 19 23:01:27 ipa01 named[12638]: loading configuration: failure
Sep 19 23:01:27 ipa01 named[12638]: exiting (due to fatal error)


I'd continue to check /var/log/audit/audit.log for AVCs.

rob



OK, I had a quick look before I'm off for today. :)

There's a lot of these messages, denying named access to /var/tmp/DNS_25.



type=AVC msg=audit(1348086955.397:42404): avc:  denied  { getattr } for  
pid=11648 comm="named" path="/var/tmp/DNS_25" dev=dm-2 ino=132140 
scontext=unconfined_u:system_r:named_t:s0 
tcontext=system_u:object_r:tmp_t:s0 tclass=file
type=AVC msg=audit(1348086955.398:42405): avc:  denied  { read write } 
for  pid=11648 comm="named" name="DNS_25" dev=dm-2 ino=132140 
scontext=unconfined_u:system_r:named_t:s0 
tcontext=system_u:object_r:tmp_t:s0 tclass=file
type=AVC msg=audit(1348086955.398:42405): avc:  denied  { open } for  
pid=11648 comm="named" name="DNS_25" dev=dm-2 ino=132140 
scontext=unconfined_u:system_r:named_t:s0 
tcontext=system_u:object_r:tmp_t:s0 tclass=file
type=AVC msg=audit(1348088487.524:42438): avc:  denied  { getattr } for  
pid=12639 comm="named" path="/var/tmp/DNS_25" dev=dm-2 ino=132140 
scontext=unconfined_u:system_r:named_t:s0 
tcontext=system_u:object_r:tmp_t:s0 tclass=file
type=AVC msg=audit(1348088487.524:42439): avc:  denied  { unlink } for  
pid=12639 comm="named" name="DNS_25" dev=dm-2 ino=132140 
scontext=unconfined_u:system_r:named_t:s0 
tcontext=system_u:object_r:tmp_t:s0 tclass=file
type=AVC msg=audit(1348088487.525:42440): avc:  denied  { getattr } for  
pid=12639 comm="named" path="/var/tmp/DNS_25" dev=dm-2 ino=132140 
scontext=unconfined_u:system_r:named_t:s0 
tcontext=system_u:object_r:tmp_t:s0 tclass=file
type=AVC msg=audit(1348088487.525:42441): avc:  denied  { unlink } for  
pid=12639 comm="named" name="DNS_25" dev=dm-2 ino=132140 
scontext=unconfined_u:system_r:named_t:s0 
tcontext=system_u:object_r:tmp_t:s0 tclass=file
type=AVC msg=audit(1348088487.525:42442): avc:  denied  { getattr } for  
pid=12639 comm="named" path="/var/tmp/DNS_25" dev=dm-2 ino=132140 
scontext=unconfined_u:system_r:named_t:s0 
tcontext=system_u:object_r:tmp_t:s0 tclass=file
type=AVC msg=audit(1348088487.525:42443): avc:  denied  { unlink } for  
pid=12639 comm="named" name="DNS_25&

Re: [Freeipa-users] krb5-server-1.9-33.el6_3.3.x86_64 prevents named from starting when selinux is enforcing

[Sigbjorn Lie]

Ok. I'm fairly new to selinux but I will give it a go tomorrow.

Thanks.

Rgds
S.

Rob Crittenden  wrote:

>Sigbjorn Lie wrote:
>> On 09/19/2012 10:48 PM, Rob Crittenden wrote:
>>> Sigbjorn Lie wrote:
>>>> Hi,
>>>>
>>>> I noticed an updated krb5-server package today advertising that
>it's
>>>> fixing the issue with slow GSSAPI binds discussed earlier, so I
>>>> installed it in my test environment, set SElinux back to enforcing
>in
>>>> /etc/sysconfig/selinux and rebooted.
>>>>
>>>> The named daemon does not start now. The error below was logged in
>>>> /var/log/messages:
>>>>
>>>> Sep 19 21:54:46 ipa01 named[3712]: GSSAPI Error: Unspecified GSS
>>>> failure.  Minor code may provide more information (KDC returned
>error
>>>> string: PROCESS_TGS)
>>>>
>>>> I am able to start named after setting SElinux in permissive mode
>>>> (setenforce 0).
>>>>
>>>> Then to verify: I stop all IPA services (ipactl stop), reenabled
>selinux
>>>> (setenforce 1), and start the IPA services (ipactl start). A new
>error
>>>> is logged in /var/log/messages:
>>>>
>>>> Sep 19 22:00:49 ipa01 named[5918]: bind to LDAP server failed:
>Invalid
>>>> credentials
>>>> Sep 19 22:00:49 ipa01 named[5918]: loading configuration:
>permission
>>>> denied
>>>> Sep 19 22:00:49 ipa01 named[5918]: exiting (due to fatal error)
>>>>
>>>>
>>>>  From the /var/log/krb5kdc.log:
>>>> Sep 19 21:54:46 ipa01.ix.test.com krb5kdc[3681](info): TGS_REQ (4
>etypes
>>>> {18 17 16 23}) 192.168.210.20: PROCESS_TGS: authtime 0, client>
>>>> for , Cannot create replay cache file
>/var/tmp/krbtgt_0:
>>>> File exists
>>>> Sep 19 21:54:46 ipa01.ix.test.com krb5kdc[3681](info): TGS_REQ (4
>etypes
>>>> {18 17 16 23}) 192.168.210.20: PROCESS_TGS: authtime 0, client>
>>>> for , Cannot create replay cache file
>/var/tmp/krbtgt_0:
>>>> File exists
>>>> Sep 19 21:54:46 ipa01.ix.test.com krb5kdc[3681](info): AS_REQ (4
>etypes
>>>> {18 17 16 23}) 192.168.210.20: NEEDED_PREAUTH:
>>>> DNS/ipa01.ix.test@ix.test.com for
>krbtgt/ix.test@ix.test.com,
>>>> Additional pre-authentication required
>>>> Sep 19 21:54:46 ipa01.ix.test.com krb5kdc[3681](info): AS_REQ (4
>etypes
>>>> {18 17 16 23}) 192.168.210.20: ISSUE: authtime 1348084486, etypes
>>>> {rep=18 tkt=18 ses=18}, DNS/ipa01.ix.test@ix.test.com for
>>>> krbtgt/ix.test@ix.test.com
>>>>
>>>> /var/named/data/named.run logged nothing.
>>>>
>>>>
>>>>
>>>> Any suggestions for how to troubleshoot this issue?
>>>
>>> Pure guess, but:
>>>
>>> restorecon /var/tmp/krbtgt_0
>>>
>>> rob
>> Sorry, that did not help. There seem to be a new error in the
>messages
>> file every time I attempt a named restart though. See below for the
>latest:
>>
>> Sep 19 23:01:27 ipa01 named[12638]: default realm from krb5.conf
>> (IX.TEST.COM) does not match tkey-gssapi-credential
>(DNS/ipa01.ix.test.com)
>> Sep 19 23:01:27 ipa01 named[12638]: configuring TKEY: failure
>> Sep 19 23:01:27 ipa01 named[12638]: loading configuration: failure
>> Sep 19 23:01:27 ipa01 named[12638]: exiting (due to fatal error)
>
>I'd continue to check /var/log/audit/audit.log for AVCs.
>
>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] krb5-server-1.9-33.el6_3.3.x86_64 prevents named from starting when selinux is enforcing

[Sigbjorn Lie]

On 09/19/2012 10:48 PM, Rob Crittenden wrote:

Sigbjorn Lie wrote:

Hi,

I noticed an updated krb5-server package today advertising that it's
fixing the issue with slow GSSAPI binds discussed earlier, so I
installed it in my test environment, set SElinux back to enforcing in
/etc/sysconfig/selinux and rebooted.

The named daemon does not start now. The error below was logged in
/var/log/messages:

Sep 19 21:54:46 ipa01 named[3712]: GSSAPI Error: Unspecified GSS
failure.  Minor code may provide more information (KDC returned error
string: PROCESS_TGS)

I am able to start named after setting SElinux in permissive mode
(setenforce 0).

Then to verify: I stop all IPA services (ipactl stop), reenabled selinux
(setenforce 1), and start the IPA services (ipactl start). A new error
is logged in /var/log/messages:

Sep 19 22:00:49 ipa01 named[5918]: bind to LDAP server failed: Invalid
credentials
Sep 19 22:00:49 ipa01 named[5918]: loading configuration: permission 
denied

Sep 19 22:00:49 ipa01 named[5918]: exiting (due to fatal error)


 From the /var/log/krb5kdc.log:
Sep 19 21:54:46 ipa01.ix.test.com krb5kdc[3681](info): TGS_REQ (4 etypes
{18 17 16 23}) 192.168.210.20: PROCESS_TGS: authtime 0, 
for , Cannot create replay cache file /var/tmp/krbtgt_0:
File exists
Sep 19 21:54:46 ipa01.ix.test.com krb5kdc[3681](info): TGS_REQ (4 etypes
{18 17 16 23}) 192.168.210.20: PROCESS_TGS: authtime 0, 
for , Cannot create replay cache file /var/tmp/krbtgt_0:
File exists
Sep 19 21:54:46 ipa01.ix.test.com krb5kdc[3681](info): AS_REQ (4 etypes
{18 17 16 23}) 192.168.210.20: NEEDED_PREAUTH:
DNS/ipa01.ix.test@ix.test.com for krbtgt/ix.test@ix.test.com,
Additional pre-authentication required
Sep 19 21:54:46 ipa01.ix.test.com krb5kdc[3681](info): AS_REQ (4 etypes
{18 17 16 23}) 192.168.210.20: ISSUE: authtime 1348084486, etypes
{rep=18 tkt=18 ses=18}, DNS/ipa01.ix.test@ix.test.com for
krbtgt/ix.test@ix.test.com

/var/named/data/named.run logged nothing.



Any suggestions for how to troubleshoot this issue?


Pure guess, but:

restorecon /var/tmp/krbtgt_0

rob
Sorry, that did not help. There seem to be a new error in the messages 
file every time I attempt a named restart though. See below for the latest:


Sep 19 23:01:27 ipa01 named[12638]: default realm from krb5.conf 
(IX.TEST.COM) does not match tkey-gssapi-credential (DNS/ipa01.ix.test.com)

Sep 19 23:01:27 ipa01 named[12638]: configuring TKEY: failure
Sep 19 23:01:27 ipa01 named[12638]: loading configuration: failure
Sep 19 23:01:27 ipa01 named[12638]: exiting (due to fatal error)


Rgds,
Siggi

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

[Freeipa-users] krb5-server-1.9-33.el6_3.3.x86_64 prevents named from starting when selinux is enforcing

[Sigbjorn Lie]

Hi,

I noticed an updated krb5-server package today advertising that it's 
fixing the issue with slow GSSAPI binds discussed earlier, so I 
installed it in my test environment, set SElinux back to enforcing in 
/etc/sysconfig/selinux and rebooted.


The named daemon does not start now. The error below was logged in 
/var/log/messages:


Sep 19 21:54:46 ipa01 named[3712]: GSSAPI Error: Unspecified GSS 
failure.  Minor code may provide more information (KDC returned error 
string: PROCESS_TGS)


I am able to start named after setting SElinux in permissive mode 
(setenforce 0).


Then to verify: I stop all IPA services (ipactl stop), reenabled selinux 
(setenforce 1), and start the IPA services (ipactl start). A new error 
is logged in /var/log/messages:


Sep 19 22:00:49 ipa01 named[5918]: bind to LDAP server failed: Invalid 
credentials

Sep 19 22:00:49 ipa01 named[5918]: loading configuration: permission denied
Sep 19 22:00:49 ipa01 named[5918]: exiting (due to fatal error)


From the /var/log/krb5kdc.log:
Sep 19 21:54:46 ipa01.ix.test.com krb5kdc[3681](info): TGS_REQ (4 etypes 
{18 17 16 23}) 192.168.210.20: PROCESS_TGS: authtime 0,  
for , Cannot create replay cache file /var/tmp/krbtgt_0: 
File exists
Sep 19 21:54:46 ipa01.ix.test.com krb5kdc[3681](info): TGS_REQ (4 etypes 
{18 17 16 23}) 192.168.210.20: PROCESS_TGS: authtime 0,  
for , Cannot create replay cache file /var/tmp/krbtgt_0: 
File exists
Sep 19 21:54:46 ipa01.ix.test.com krb5kdc[3681](info): AS_REQ (4 etypes 
{18 17 16 23}) 192.168.210.20: NEEDED_PREAUTH: 
DNS/ipa01.ix.test@ix.test.com for krbtgt/ix.test@ix.test.com, 
Additional pre-authentication required
Sep 19 21:54:46 ipa01.ix.test.com krb5kdc[3681](info): AS_REQ (4 etypes 
{18 17 16 23}) 192.168.210.20: ISSUE: authtime 1348084486, etypes 
{rep=18 tkt=18 ses=18}, DNS/ipa01.ix.test@ix.test.com for 
krbtgt/ix.test@ix.test.com


/var/named/data/named.run logged nothing.



Any suggestions for how to troubleshoot this issue?



Regards,
Siggi


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

Re: [Freeipa-users] NFS on Mac

[Sigbjorn Lie]

As usual, if someone is interested in sending me a Mac I'll be happy to do the 
testing and submit
the results.

*grin* :)



Regards,
Siggi



On Wed, September 19, 2012 10:08, Petr Spacek wrote:
> On 09/17/2012 10:32 PM, Steven Jones wrote:
>
>> If anyone has MAC instructions' I'd love a copy pls.
>>
>
> As usual, we can create account on freeipa.org wiki if anybody is interested
> in creating a how-to. That is the best place to share.
>
> Let us know!
>
>
> Petr^2 Spacek
>
>
>>
>> --
>> *From:* freeipa-users-boun...@redhat.com [freeipa-users-boun...@redhat.com] 
>> on
>> behalf of Dmitri Pal [d...@redhat.com] *Sent:* Tuesday, 18 September 2012 
>> 6:47 a.m.
>> *To:* george he
>> *Cc:* freeipa-users@redhat.com
>> *Subject:* Re: [Freeipa-users] NFS on Mac
>>
>>
>> On 09/17/2012 02:21 PM, george he wrote:
>>
>>> sounds to me the link may work for nfs version 3 only. Now with IPA and 
>>> NFS4, there got to be
>>> something more. George
>>>
>>
>> I do not know the exact steps on mac because the is no ipa-client on Mac so
>> you would have to configure the machine to be an IPA client manually. This 
>> would mean that you
>> need to authenticate with kerberos and then make the nfs part use the 
>> credential cache of the
>> logged in user (if you are planning to use it for users mounting shares). 
>> This is what needs to
>> happen conceptually. I know that people have done in the past but I do not 
>> think there are
>> instructions.
>>
>> Once you manged to do it please see the presentation how to setup secure NFS
>> on Linux 
>> http://rhsummit.files.wordpress.com/2012/03/dickson_the_evolution_nfs_protocol.pdf
>> May be it will give you some hints and pointers.
>>
>>
>> The only known problem with this slide deck is that on slide 18 after kinit
>> admin and before ipa-getkeytab you need to add service for the NFS server 
>> ipa service-add
>> nfs/`hostname`@EXAMPLE
>>
>> HTH
>>
>>>
>>> --
>>> *From:* Dmitri Pal 
>>> *To:* freeipa-users@redhat.com
>>> *Sent:* Monday, September 17, 2012 11:20 AM
>>> *Subject:* Re: [Freeipa-users] NFS on Mac
>>>
>>>
>>> On 09/17/2012 11:07 AM, george he wrote:
>>>
 Hello all,
 I have IPA server and NFS server set up on a computer running centos 6.3.
 Is there a way to set up a mac laptop to access the data on the NFS server?
 The laptop does not have a static IP. DNS is not configured with IPA.
 If yes, how do I config the mac?

>>>
>>> Is this what you are looking for?
>>> http://www.cyberciti.biz/faq/apple-mac-osx-nfs-mount-command-tutorial/
>>>
>>>
 Thanks,
 George

>
> ___
> 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] MemberOf plugin and LDAP filter

[Sigbjorn Lie]

On 09/18/2012 02:27 PM, James James wrote:

Hi everybody,

can somebody help me with the memberof plugin ? Is there a way to add 
the memberof attribute like it was in 389-ds ?
For my mailing list program, I want to have the email of the emails of 
all the person belongings to a group. Is there a filter to do that ?


Thanks.



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


Hi,

This works for me:

ldapsearch -Y GSSAPI 
memberof=cn=ipausers,cn=groups,cn=accounts,dc=example,dc=com mail




Regards,
Siggi

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

Re: [Freeipa-users] Solaris 11 (OpenIndiana) PAM stack Password Change

[Sigbjorn Lie]

On 09/14/2012 09:42 PM, Dmitri Pal wrote:

On 09/14/2012 01:34 AM, Mullen, Jonathan W. wrote:

Hello All,

I'm in the process of setting up a ZFS file server that authenticates against 
our freeipa infrastructure. I'm running into a few issues, and ALOT of 
confusion between discrepancies in the documentation. Specifically between 
(http://freeipa.com/page/ConfiguringSolarisClients) and 
(http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html)

Hope those comments help

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

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



userA is a freeipa user

SSH with kerberos ticket already acquired:

CLIENT:~ userA$ ssh server.domain -l userA
Last login: Thu Sep 13 22:43:42 2012 from IP
OpenIndiana (powered by illumos)SunOS 5.11oi_151a5June 2012
-bash-4.0$ passwd
passwd: Changing password for userA
Enter existing login password:
Unexpected failure. Password file/table unchanged.
-bash-4.0$ su
Password:
# passwd userA
Enter userA's password:
passwd: userA does not exist.
Permission denied
# exit
exit

SSH With password login (notice the LACK of 'passwd: userA does not exist.' as 
apposed to with kerberos:

CLIENT:~ userA$ ssh server.domain -l userA
Password:
Last login: Thu Sep 13 22:59:02 2012 from IP
OpenIndiana (powered by illumos)SunOS 5.11oi_151a5June 2012
-bash-4.0$ passwd
passwd: Changing password for userA
Enter existing login password:
Unexpected failure. Password file/table unchanged.
-bash-4.0$


Here is my pam.conf, you can see the comments showing the various configurations. The current one works the "best" in 
that BOTH "getent passwd" and "getent passwd userA". Some configurations only "getetn passwd userA" 
would work, and not "getent passwd". No

My aim here is to get password changes working so I can capture smb passwords 
for SMB/CIFS.

Does any one have a working OpenIndiana and freeIPA setup for SMB shares. If so 
would you be so kind as to help me with some sample configs?


# Authentication management
#
# login service (explicit because of pam_dial_auth)
#
login   auth requisite  pam_authtok_get.so.1
login   auth required   pam_dhkeys.so.1
#login   auth sufficient pam_krb5.so.1 try_first_pass
login   auth required   pam_unix_cred.so.1
login   auth required   pam_unix_auth.so.1 use_first_pass
login   auth required   pam_dial_auth.so.1
#
# rlogin service (explicit because of pam_rhost_auth)
#
rlogin  auth sufficient pam_rhosts_auth.so.1
rlogin  auth requisite  pam_authtok_get.so.1
rlogin  auth required   pam_dhkeys.so.1
rlogin  auth required   pam_unix_cred.so.1
rlogin  auth required   pam_unix_auth.so.1
#
# Kerberized rlogin service
#
krlogin auth required   pam_unix_cred.so.1
krlogin auth required   pam_krb5.so.1
#
# rsh service (explicit because of pam_rhost_auth,
# and pam_unix_auth for meaningful pam_setcred)
#
rsh auth sufficient pam_rhosts_auth.so.1
rsh auth required   pam_unix_cred.so.1
#
# Kerberized rsh service
#
krshauth required   pam_unix_cred.so.1
krshauth required   pam_krb5.so.1
#
# Kerberized telnet service
#
ktelnet auth required   pam_unix_cred.so.1
ktelnet auth required   pam_krb5.so.1
#
# PPP service (explicit because of pam_dial_auth)
#
ppp auth requisite  pam_authtok_get.so.1
ppp auth required   pam_dhkeys.so.1
ppp auth required   pam_unix_cred.so.1
ppp auth required   pam_unix_auth.so.1
ppp auth required   pam_dial_auth.so.1
#
# GDM Autologin (explicit because of pam_allow).  These need to be
# here as there is no mechanism for packages to amend pam.conf as
# they are installed.
#
gdm-autologin auth  requiredpam_unix_cred.so.1
gdm-autologin auth  sufficient  pam_allow.so.1
#
# Default definitions for Authentication management
# Used when service name is not explicitly mentioned for authentication
#
other   auth requisite  pam_authtok_get.so.1
other   auth required   pam_dhkeys.so.1
other   auth required   pam_unix_cred.so.1
other   auth sufficient pam_krb5.so.1
other   auth required   pam_unix_auth.so.1
#
# passwd command (explicit because of a different authentication module)
#
#passwd auth required   pam_passwd_auth.so.1
passwd  auth binding  pam_passwd_auth.so.1 server_policy
passwd  auth required pam_ldap.so.1
#
# cron service (explicit because of non-usage of pam_roles.so.1)
#
cronaccount requiredpam_unix_account.so.1
#
# cups service (explicit because of non-usage of pam_roles.so.1)
#
cupsaccount requiredpam_unix_account.so.1
#
# GDM Autologin (explicit because of pam_allow) This needs to be here
# as there is no mechanism for packages to amend pam.conf as they are
# installed.
#
gdm-autologin account  sufficient  pam_allo

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

[Sigbjorn Lie]

On Thu, September 13, 2012 16:46, Rob Crittenden wrote:
> Ondrej Valousek wrote:
>
>> Sorry, the parameter mentioned below has already been implemented :-)
>>
>
> He wants to be able to share a common set of maps between locations
> rather than having to duplicate them across each location.
>
> We're limited by the LDAP clients at this point because they just query
> a basedn and can't really do anything complex.
>
> Using a virtual view is one of the options we've considered, but
> honestly we haven't spent a lot of time looking into this yet. The problem 
> with trying to virtually
> add things to a location is it could get very complex very quickly and either 
> hamper performance,
> debugging, or both very quickly.
>

I see. Is using virtual views in 389-ds considered slow? I suppose it depends 
some on how complex
the filters behind the view is written...


Regards,
Siggi


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

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

[Sigbjorn Lie]

Hi,

That still only supports one automount location. Currently, a map has to be 
redefined in every
automount location if the same map is to be used for several locations.

My request is to be able to share maps between the automount locations, as well 
as having the per
location maps available today.


Regards,
Siggi



On Thu, September 13, 2012 16:24, Ondrej Valousek wrote:
> Sorry, the parameter mentioned below has already been implemented :-)
>
>
> On 09/13/2012 04:12 PM, Ondrej Valousek wrote:
>
>> I guess the easiest implementation would be using pre-defined variable in 
>> automount map names.
>> The variable would be then defined by an automount process using the -D 
>> parameter.
>>
>>
>> The other option (maybe easier) would be to ask sssd developers to add 
>> another option to sssd -
>> say:
>>
>>
>> ldap_autofs_search_base
>>
>> so you could specify a different search base for every site Ondrej
>>
>>
>> On 09/13/2012 03:55 PM, Sigbjorn Lie wrote:
>>
>>> Hi,
>>>
>>>
>>>
>>> I opened a request a while ago for Automount cross-location support.
>>> https://bugzilla.redhat.com/show_bug.cgi?id=768177
>>> https://fedorahosted.org/freeipa/ticket/1699#
>>>
>>>
>>> I see from the comments that it's uncertain how this can be implemented.
>>>
>>>
>>> Could the Virtual Views in 389-ds be used to implement this the cross 
>>> location maps?
>>>
>>>
>>> I'm picturing the ability to add a "virtual" automount map to an automount 
>>> location, where
>>> you select an existing map from one of the other automount locations to 
>>> display.
>>>
>>> All changes to the map will be done in the original map in it's orignal 
>>> automount location,
>>> but it will be displayed in both automount locations.
>>>
>>> Any thoughts to that solution?
>>>
>>>
>>>
>>> Regards,
>>> 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
>>
> ___
> 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 Automount cross-location support

[Sigbjorn Lie]

Hi,


I opened a request a while ago for Automount cross-location support.
https://bugzilla.redhat.com/show_bug.cgi?id=768177
https://fedorahosted.org/freeipa/ticket/1699#

I see from the comments that it's uncertain how this can be implemented.

Could the Virtual Views in 389-ds be used to implement this the cross location 
maps?

I'm picturing the ability to add a "virtual" automount map to an automount 
location, where you
select an existing map from one of the other automount locations to display.

All changes to the map will be done in the original map in it's orignal 
automount location, but it
will be displayed in both automount locations.

Any thoughts to that solution?


Regards,
Siggi


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

Re: [Freeipa-users] Stale NFS file handle

[Sigbjorn Lie]

What nfs version are you using? And if 4, do you use kerberos?

We are using mostly nfs 3 still, and those nfs mounts just reconnect by 
themselves up to a few minutes after the nfs server is back online.



Regards,
Siggi


On 09/12/2012 10:44 PM, george he wrote:

I think it's about half an hour.
Any ideas about the authentication failsure thing?
Thanks,
George


*From:* Sigbjorn Lie 
*To:* freeipa-users@redhat.com
*Sent:* Wednesday, September 12, 2012 3:53 PM
*Subject:* Re: [Freeipa-users] Stale NFS file handle

On 09/12/2012 08:26 PM, george he wrote:

Hello,
My ipa server and my nfs server are the same machine running
centos 6.3.
The server was accidentally down and rebooted.
But then I got "authentication failsure" on some clients when
tried to log on through gdm, and blue screen (no desktop, no
panels) on some others.
On some clients that I was on before the server was downthe, I
got "Stale NFS file handle".
Yet on some other clients, everything is fine. All clients are
running centos 6.3, too.
Is there a way (e.g. restarting some services) to get the above
problems away instead of rebooting the clients?
Thanks,
George



Just wait and it reconnects a while after the nfs server becomes
available again.

How long have you waited before rebooting?


Regards,
Siggi


___
Freeipa-users mailing list
Freeipa-users@redhat.com <mailto: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