Re: [Freeipa-users] sudo made a bit easier to configure
On Sun, Apr 14, 2013 at 01:49:14PM +0200, Jan-Frode Myklebust wrote: On Thu, Dec 20, 2012 at 04:43:08PM +0100, Han Boetes wrote: An even better config would be if we could use the host's keytab to bind to LDAP here.. Coming up as a default in sssd 1.10 (beta). ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] User Roles and access in GUI
On 04/12/2013 08:17 PM, Chandan Kumar wrote: Thanks for the response. The way we can turn off the anonymous bind in 389 Server. using nsslapd-allow-anonymous-access: off. Is there any way to limit the read access of user to only to the DNS entries? In that way I can create a user who could/will be able to see/edit DNS entries only. In general yes though it is not standard because as I mentioned earlier the tree is assumed to be readable to an authenticated user. When user logs in the framework the UI or CLI will log into LDAP as a user and try to do operations. It will need to read user entry and groups and other things so closing read access to everything other than DNS would not work. You can close access to some of the objects but not to all of them. It still unclear what is the harm in ability to read other parts of the tree but not modify them. To change the permissions you would have to user LDAP level ACI commands as we do not expose these capabilities via CLI or UI but be careful as I mentioned above you might end up hiding something that would prevent framework from functioning properly. Thanks, Chandan On Friday, April 12, 2013, Dmitri Pal wrote: On 04/12/2013 02:23 AM, Martin Kosek wrote: On 04/12/2013 01:07 AM, Chandan Kumar wrote: Hello, I have a question regarding Uer Roles and Access in GUI. What I have found that irrespective of Role assigned to a user, he gets read only access across the directory. For example, I created one user say dnsadmin with only Roles related to DNS such as DNS Servers, DNS Administrator. Now that user has read only access to entire directory. Is there any way of controlling it? Thanks, Chandan Hello Chandan, If you create a new role, assign DNS Administrators privilege to it, and assign that role to user dnsadmin, that user will have write access to DNS tree and configuration. Beyond that tree, dnsadmin will have read-only access just like all other non-admin users. If you want dnsadmin to have write access also to other entries, you would need to assign more privileges/roles to it. HTH, Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com javascript:; https://www.redhat.com/mailman/listinfo/freeipa-users If you are worried about the read access the LDAP data is traditionally readable by any authenticated user. In the past is was even possible to read the tree as anonymous user which is a bad security practice and not recommended. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ http://www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com javascript:; https://www.redhat.com/mailman/listinfo/freeipa-users -- -- http://about.me/chandank -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa-server-install: ERROR Failed to initialize IPA API
On 04/15/2013 03:16 PM, Arturo Borrero wrote:
Hi there,
In a freshly installed server, I try:
# ipa-server-install
[...]
[12/13]: restarting httpd
[13/13]: configuring httpd to start on boot
Done configuring the web interface (httpd).
Applying LDAP updates
Restarting the directory server
Restarting the KDC
Sample zone file for bind has been created in /tmp/sample.zone.NGKJk1.db
Restarting the web server
Configuration of client side components failed!
ipa-client-install returned: Command '/usr/sbin/ipa-client-install --on-master
--unattended --domain cica.es --server sheldon.cica.es --realm CICA.ES
--hostname sheldon.cica.es' returned non-zero exit status 1
If I see the ipa-client-install logs, I have:
[...]
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/pwpolicy.py'
args=klist -V
stdout=Kerberos 5 version 1.10.3
stderr=
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/role.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/selfservice.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/selinuxusermap.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/service.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/sudocmd.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/sudocmdgroup.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/sudorule.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/trust.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/user.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/virtual.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/xmlclient.py'
Failed to initialize IPA API.
Installation failed. Rolling back changes.
IPA client is not configured on this system.
I fit all prerequisites listed in fedora and redhat documentation:
http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/installing-ipa.html
After this, if I try ipactl:
# ipactl start
Starting Directory Service
Starting dirsrv:
CICA-ES... already running [ OK ]
PKI-IPA... already running [ OK ]
Failed to read data from Directory Service: Unknown error when retrieving list
of services from LDAP: {'info': 'SASL(-4): no mechanism available: ', 'desc':
'Unknown authentication method'}
Shutting down
Shutting down dirsrv:
CICA-ES... [ OK ]
PKI-IPA... [ OK ]
Any idea how to get rid of this error and continuing installing/using?
regards
Hello Arturo,
This error could have been caused if /etc/ipa/default.conf was not created
before ipa-client-install was executed.
Could you please check ipaserver-install.log and see if there are not any
errors related to creating /etc/ipa/default.conf?
Does /etc/ipa/ exist?
Thanks,
Martin
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] User Roles and access in GUI
Dmitri Pal wrote: On 04/12/2013 08:17 PM, Chandan Kumar wrote: Thanks for the response. The way we can turn off the anonymous bind in 389 Server. using nsslapd-allow-anonymous-access: off. Is there any way to limit the read access of user to only to the DNS entries? In that way I can create a user who could/will be able to see/edit DNS entries only. In general yes though it is not standard because as I mentioned earlier the tree is assumed to be readable to an authenticated user. When user logs in the framework the UI or CLI will log into LDAP as a user and try to do operations. It will need to read user entry and groups and other things so closing read access to everything other than DNS would not work. You can close access to some of the objects but not to all of them. It still unclear what is the harm in ability to read other parts of the tree but not modify them. To change the permissions you would have to user LDAP level ACI commands as we do not expose these capabilities via CLI or UI but be careful as I mentioned above you might end up hiding something that would prevent framework from functioning properly. There is no easy way to do this. We start with granting all authenticated users read access to the tree with the exception of certain attributes (like passwords). You'd have to start by removing that, then one by one granting read access to the various containers based on, well, something. It would be very prone to error, with probably lots of corner cases and overlap. Do you really want to deny read access or do you want to simplify the the UI to include only certain tabs/functions? rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa-server-install: ERROR Failed to initialize IPA API
Arturo Borrero wrote:
On 15/04/13 15:33, Martin Kosek wrote:
On 04/15/2013 03:16 PM, Arturo Borrero wrote:
Hi there,
In a freshly installed server, I try:
# ipa-server-install
[...]
[12/13]: restarting httpd
[13/13]: configuring httpd to start on boot
Done configuring the web interface (httpd).
Applying LDAP updates
Restarting the directory server
Restarting the KDC
Sample zone file for bind has been created in /tmp/sample.zone.NGKJk1.db
Restarting the web server
Configuration of client side components failed!
ipa-client-install returned: Command '/usr/sbin/ipa-client-install
--on-master
--unattended --domain cica.es --server sheldon.cica.es --realm CICA.ES
--hostname sheldon.cica.es' returned non-zero exit status 1
If I see the ipa-client-install logs, I have:
[...]
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/pwpolicy.py'
args=klist -V
stdout=Kerberos 5 version 1.10.3
stderr=
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/role.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/selfservice.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/selinuxusermap.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/service.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/sudocmd.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/sudocmdgroup.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/sudorule.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/trust.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/user.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/virtual.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/xmlclient.py'
Failed to initialize IPA API.
Installation failed. Rolling back changes.
IPA client is not configured on this system.
I fit all prerequisites listed in fedora and redhat documentation:
http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/installing-ipa.html
After this, if I try ipactl:
# ipactl start
Starting Directory Service
Starting dirsrv:
CICA-ES... already running [ OK ]
PKI-IPA... already running [ OK ]
Failed to read data from Directory Service: Unknown error when
retrieving list
of services from LDAP: {'info': 'SASL(-4): no mechanism available: ',
'desc':
'Unknown authentication method'}
Shutting down
Shutting down dirsrv:
CICA-ES... [ OK ]
PKI-IPA... [ OK ]
Any idea how to get rid of this error and continuing installing/using?
regards
Hello Arturo,
This error could have been caused if /etc/ipa/default.conf was not
created
before ipa-client-install was executed.
Could you please check ipaserver-install.log and see if there are not any
errors related to creating /etc/ipa/default.conf?
Does /etc/ipa/ exist?
Thanks,
Martin
Thanks,
/etc/ipa exist, with this content:
[root@sheldon ipa]# ll -R
.:
total 8
-r--r--r--. 1 root root 1295 abr 15 13:40 ca.crt
drwxr-xr-x. 2 root root 4096 abr 12 11:37 html
./html:
total 28
-rw-r--r--. 1 root root 3929 mar 8 15:10 browserconfig.html
-rw-r--r--. 1 root root 2871 mar 8 15:10 ffconfig.js
-rw-r--r--. 1 root root 4603 mar 8 15:10 ffconfig_page.js
-rw-r--r--. 1 root root 521 mar 8 15:10 ipa_error.css
-rw-r--r--. 1 root root 3974 mar 8 15:10 ssbrowser.html
-rw-r--r--. 1 root root 1370 mar 8 15:10 unauthorized.html
So, no /etc/ipa/default.conf exist.
Which package is intended to deploy it?
The server installer creates it.
I believe this file gets removed by the client when its install fails.
The server log may have some failures though, as suggested by Martin, so
I'd start there.
rob
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa-server-install: ERROR Failed to initialize IPA API
On 04/15/2013 03:50 PM, Rob Crittenden wrote:
Arturo Borrero wrote:
On 15/04/13 15:33, Martin Kosek wrote:
On 04/15/2013 03:16 PM, Arturo Borrero wrote:
Hi there,
In a freshly installed server, I try:
# ipa-server-install
[...]
[12/13]: restarting httpd
[13/13]: configuring httpd to start on boot
Done configuring the web interface (httpd).
Applying LDAP updates
Restarting the directory server
Restarting the KDC
Sample zone file for bind has been created in /tmp/sample.zone.NGKJk1.db
Restarting the web server
Configuration of client side components failed!
ipa-client-install returned: Command '/usr/sbin/ipa-client-install
--on-master
--unattended --domain cica.es --server sheldon.cica.es --realm CICA.ES
--hostname sheldon.cica.es' returned non-zero exit status 1
If I see the ipa-client-install logs, I have:
[...]
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/pwpolicy.py'
args=klist -V
stdout=Kerberos 5 version 1.10.3
stderr=
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/role.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/selfservice.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/selinuxusermap.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/service.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/sudocmd.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/sudocmdgroup.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/sudorule.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/trust.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/user.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/virtual.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/xmlclient.py'
Failed to initialize IPA API.
Installation failed. Rolling back changes.
IPA client is not configured on this system.
I fit all prerequisites listed in fedora and redhat documentation:
http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/installing-ipa.html
After this, if I try ipactl:
# ipactl start
Starting Directory Service
Starting dirsrv:
CICA-ES... already running [ OK ]
PKI-IPA... already running [ OK ]
Failed to read data from Directory Service: Unknown error when
retrieving list
of services from LDAP: {'info': 'SASL(-4): no mechanism available: ',
'desc':
'Unknown authentication method'}
Shutting down
Shutting down dirsrv:
CICA-ES... [ OK ]
PKI-IPA... [ OK ]
Any idea how to get rid of this error and continuing installing/using?
regards
Hello Arturo,
This error could have been caused if /etc/ipa/default.conf was not
created
before ipa-client-install was executed.
Could you please check ipaserver-install.log and see if there are not any
errors related to creating /etc/ipa/default.conf?
Does /etc/ipa/ exist?
Thanks,
Martin
Thanks,
/etc/ipa exist, with this content:
[root@sheldon ipa]# ll -R
.:
total 8
-r--r--r--. 1 root root 1295 abr 15 13:40 ca.crt
drwxr-xr-x. 2 root root 4096 abr 12 11:37 html
./html:
total 28
-rw-r--r--. 1 root root 3929 mar 8 15:10 browserconfig.html
-rw-r--r--. 1 root root 2871 mar 8 15:10 ffconfig.js
-rw-r--r--. 1 root root 4603 mar 8 15:10 ffconfig_page.js
-rw-r--r--. 1 root root 521 mar 8 15:10 ipa_error.css
-rw-r--r--. 1 root root 3974 mar 8 15:10 ssbrowser.html
-rw-r--r--. 1 root root 1370 mar 8 15:10 unauthorized.html
So, no /etc/ipa/default.conf exist.
Which package is intended to deploy it?
The server installer creates it.
I believe this file gets removed by the client when its install fails.
The server log may have some failures though, as suggested by Martin, so I'd
start there.
rob
This file is being created right after the wizard part of ipa-server-install,
so when the services are being configured, it should be there (you can check
that and get its contents). Unfortunately, there is not logging around it, so
you may not see much info in you ipaserver-install.log...
BTW I really suspect that missing or unreadable /etc/ipa/default.conf may
really be the root cause of this issue, I reproduced this exact message when I
run ipa-client-install --on-master on clean VM without /etc/ipa/default.conf.
Martin
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa-server-install: ERROR Failed to initialize IPA API
On 15/04/13 15:33, Martin Kosek wrote:
On 04/15/2013 03:16 PM, Arturo Borrero wrote:
Hi there,
In a freshly installed server, I try:
# ipa-server-install
[...]
[12/13]: restarting httpd
[13/13]: configuring httpd to start on boot
Done configuring the web interface (httpd).
Applying LDAP updates
Restarting the directory server
Restarting the KDC
Sample zone file for bind has been created in /tmp/sample.zone.NGKJk1.db
Restarting the web server
Configuration of client side components failed!
ipa-client-install returned: Command '/usr/sbin/ipa-client-install --on-master
--unattended --domain cica.es --server sheldon.cica.es --realm CICA.ES
--hostname sheldon.cica.es' returned non-zero exit status 1
If I see the ipa-client-install logs, I have:
[...]
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/pwpolicy.py'
args=klist -V
stdout=Kerberos 5 version 1.10.3
stderr=
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/role.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/selfservice.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/selinuxusermap.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/service.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/sudocmd.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/sudocmdgroup.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/sudorule.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/trust.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/user.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/virtual.py'
importing plugin module
'/usr/lib/python2.6/site-packages/ipalib/plugins/xmlclient.py'
Failed to initialize IPA API.
Installation failed. Rolling back changes.
IPA client is not configured on this system.
I fit all prerequisites listed in fedora and redhat documentation:
http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/installing-ipa.html
After this, if I try ipactl:
# ipactl start
Starting Directory Service
Starting dirsrv:
CICA-ES... already running [ OK ]
PKI-IPA... already running [ OK ]
Failed to read data from Directory Service: Unknown error when retrieving list
of services from LDAP: {'info': 'SASL(-4): no mechanism available: ', 'desc':
'Unknown authentication method'}
Shutting down
Shutting down dirsrv:
CICA-ES... [ OK ]
PKI-IPA... [ OK ]
Any idea how to get rid of this error and continuing installing/using?
regards
Hello Arturo,
This error could have been caused if /etc/ipa/default.conf was not created
before ipa-client-install was executed.
Could you please check ipaserver-install.log and see if there are not any
errors related to creating /etc/ipa/default.conf?
Does /etc/ipa/ exist?
Thanks,
Martin
Thanks,
/etc/ipa exist, with this content:
[root@sheldon ipa]# ll -R
.:
total 8
-r--r--r--. 1 root root 1295 abr 15 13:40 ca.crt
drwxr-xr-x. 2 root root 4096 abr 12 11:37 html
./html:
total 28
-rw-r--r--. 1 root root 3929 mar 8 15:10 browserconfig.html
-rw-r--r--. 1 root root 2871 mar 8 15:10 ffconfig.js
-rw-r--r--. 1 root root 4603 mar 8 15:10 ffconfig_page.js
-rw-r--r--. 1 root root 521 mar 8 15:10 ipa_error.css
-rw-r--r--. 1 root root 3974 mar 8 15:10 ssbrowser.html
-rw-r--r--. 1 root root 1370 mar 8 15:10 unauthorized.html
So, no /etc/ipa/default.conf exist.
Which package is intended to deploy it?
regads.
--
Arturo Borrero González
Departamento de Seguridad Informática
Centro Informático Científico de Andalucía (CICA)
Avda. Reina Mercedes s/n - 41012 - Sevilla (Spain)
Tfno.: +34 955 056 600 / FAX: +34 955 056 650
Consejería de Economía, Innovación, Ciencia y Empleo
Junta de Andalucía
smime.p7s
Description: S/MIME Cryptographic Signature
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] User Roles and access in GUI
On 15.4.2013 15:39, Rob Crittenden wrote: There is no easy way to do this. We start with granting all authenticated users read access to the tree with the exception of certain attributes (like passwords). You'd have to start by removing that, then one by one granting read access to the various containers based on, well, something. Would it be possible to create a new role to allow current 'read-all access' and add this role to all users by default? It could be much simpler to change the behaviour with this role, or not? :-) -- Petr Spacek ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] User Roles and access in GUI
On Mon, 15 Apr 2013, Petr Spacek wrote: On 15.4.2013 15:39, Rob Crittenden wrote: There is no easy way to do this. We start with granting all authenticated users read access to the tree with the exception of certain attributes (like passwords). You'd have to start by removing that, then one by one granting read access to the various containers based on, well, something. Would it be possible to create a new role to allow current 'read-all access' and add this role to all users by default? It could be much simpler to change the behaviour with this role, or not? :-) It would affect service accounts (include host/fqdn@REALM) since roles cannot be applied to them, if I remember correctly. We would need to make an exclusive ACI that allows all services to gain read only access... -- / Alexander Bokovoy ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] User Roles and access in GUI
I think controlling Visibility of tabs would be the best option, if possible, based on Roles as mentioned by Rob. As long as other entries are not visible in UI, even though they have read only access with command line, should be enough. On Monday, April 15, 2013, Alexander Bokovoy wrote: On Mon, 15 Apr 2013, Petr Spacek wrote: On 15.4.2013 15:39, Rob Crittenden wrote: There is no easy way to do this. We start with granting all authenticated users read access to the tree with the exception of certain attributes (like passwords). You'd have to start by removing that, then one by one granting read access to the various containers based on, well, something. Would it be possible to create a new role to allow current 'read-all access' and add this role to all users by default? It could be much simpler to change the behaviour with this role, or not? :-) It would affect service accounts (include host/fqdn@REALM) since roles cannot be applied to them, if I remember correctly. We would need to make an exclusive ACI that allows all services to gain read only access... -- / Alexander Bokovoy __**_ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/**mailman/listinfo/freeipa-usershttps://www.redhat.com/mailman/listinfo/freeipa-users -- -- http://about.me/chandank ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] FreeIPA dual stacked
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, Adam Bishop gpg: 0x6609D460 Janet, the UK's research and education network. Janet(UK) is a trading name of Jisc Collections and Janet Limited, a not-for-profit company which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] FreeIPA dual stacked
On 04/15/2013 09:45 AM, 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, Adam Bishop gpg: 0x6609D460 Janet, the UK's research and education network. Janet(UK) is a trading name of Jisc Collections and Janet Limited, a not-for-profit company which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users Probably the installer. I have a a dual stacked IPA setup that is working just fine, though when it was originally installed it was running only IPv4. -Erinn signature.asc Description: OpenPGP digital signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] FreeIPA dual stacked
On 04/15/2013 11:45 AM, 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? We're supposed to work fine with IPv6. Dual stack should also be fine. I know we've done a bunch of testing in this area but apparently something fell through the cracks. I suspect this is an installer only issue where it's validation logic is not sufficiently robust. Please open a bug report so we can address this. I think if you pick one of the addresses and let the install proceed everything should just work. Please let us know if it doesn't. I'm not surprised we still have some IPv6 bumps to smooth out, it doesn't get exercised as much as IPv4. FWIW we fully expect IPv6 enabled systems to be dual stack. -- John Dennis jden...@redhat.com Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] FreeIPA dual stacked
On 04/15/2013 05:45 PM, Adam Bishop wrote: Hi, I've just had a go at deploying FreeIPA v3.1.3 and have hit a minor road bump. The server hostname resolves to more than one address: :::::4 xxx.xxx.xxx.180 Please provide the IP address to be used for this host name: The answer I would like to give here is both - is this a limitation of the installation script that I can fix up later, or is FreeIPA incompatible with dual-stacked hosts at the moment? Thanks, My IPA was installed having dual stack from the beginning and is working just fine with dual stack today. That was IPA 2.1.3 when I originally installed it. Regards, Siggi ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] IPA not authenticating - SSSD issue maybe
Hello, From time to time we are getting complaints that I can sum up as I cannot log in to server X Here is a spinet of the /var/log/sssd/sssd_DOMAIN.log ... *(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [be_pam_handler] (0x0100): Got request with the following data (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100): command: PAM_ACCT_MGMT (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100): domain: 4OVER.COM (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100): user: tradeftp (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100): service: vsftpd (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100): tty: ftp (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100): ruser: tradeftp (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100): rhost: mammoth.4over.com (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100): authtok type: 0 (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100): authtok size: 0 (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100): newauthtok type: 0 (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100): newauthtok size: 0 (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100): priv: 1 (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100): cli_pid: 17841 (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC rule [allow_all] (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, NULL) [Success] (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, Success) [Success] (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [be_pam_handler_callback] (0x0100): Sending result [0][4OVER.COM] (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [be_pam_handler_callback] (0x0100): Sent result [0][4OVER.COM] (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [be_pam_handler] (0x0100): Got request with the following data (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100): command: PAM_SETCRED (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100): domain: 4OVER.COM (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100): user: tradeftp (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100): service: vsftpd (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100): tty: ftp (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100): ruser: tradeftp (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100): rhost: mammoth.4over.com (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100): authtok type: 0 (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100): authtok size: 0 (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100): newauthtok type: 0 (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100): newauthtok size: 0 (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100): priv: 1 (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [pam_print_data] (0x0100): cli_pid: 17841 (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM]]] [be_pam_handler] (0x0100): Sending result [0][4OVER.COM] (Mon Apr 15 09:37:00 2013) [sssd[be[4OVER.COM]]] [be_get_account_info] (0x0100): Got request for [3][1][name=tradeftp] (Mon Apr 15 09:37:00 2013) [sssd[be[4OVER.COM]]] [sdap_initgr_nested_search] (0x0040): Search for group cn=ipausers,cn=groups,cn=accounts,dc=4over,dc=com, returned 0 results. Skipping * Here (more interesting) is the krb log file *(Mon Apr 15 09:36:54 2013) [[sssd[krb5_child[17855 [unpack_buffer] (0x0100): cmd [241] uid [6676] gid [104] validate [true] offline [false] UPN [trade...@4over.com] (Mon Apr 15 09:36:54 2013) [[sssd[krb5_child[17855 [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_6676_0CTKUc] keytab: [/etc/krb5.keytab] (Mon Apr 15 09:36:54 2013) [[sssd[krb5_child[17855 [krb5_child_setup] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Mon Apr 15 09:36:54 2013) [[sssd[krb5_child[17855 [krb5_child_setup] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Mon Apr 15 09:36:54 2013) [[sssd[krb5_child[17855 [krb5_set_canonicalize] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Mon Apr 15 09:36:54 2013) [[sssd[krb5_child[17855 [krb5_child_setup] (0x0100): Not using FAST. (Mon Apr 15 09:36:56 2013) [[sssd[krb5_child[17862 [unpack_buffer] (0x0100): cmd [241] uid [6676] gid [104] validate [true] offline [false] UPN [trade...@4over.com] (Mon Apr 15 09:36:56 2013) [[sssd[krb5_child[17862 [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_6676_0CTKUc] keytab: [/etc/krb5.keytab]
Re: [Freeipa-users] IPA not authenticating - SSSD issue maybe
Christian Hernandez wrote: Hello, From time to time we are getting complaints that I can sum up as I cannot log in to server X Here is a spinet of the /var/log/sssd/sssd_DOMAIN.log ... /(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [be_pam_handler] (0x0100): Got request with the following data (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): command: PAM_ACCT_MGMT (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): domain: 4OVER.COM http://4OVER.COM (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): user: tradeftp (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): service: vsftpd (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): tty: ftp (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): ruser: tradeftp (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): rhost: mammoth.4over.com http://mammoth.4over.com (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): authtok type: 0 (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): authtok size: 0 (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): newauthtok type: 0 (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): newauthtok size: 0 (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): priv: 1 (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): cli_pid: 17841 (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC rule [allow_all] (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, NULL) [Success] (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, Success) [Success] (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [be_pam_handler_callback] (0x0100): Sending result [0][4OVER.COM http://4OVER.COM] (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [be_pam_handler_callback] (0x0100): Sent result [0][4OVER.COM http://4OVER.COM] (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [be_pam_handler] (0x0100): Got request with the following data (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): command: PAM_SETCRED (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): domain: 4OVER.COM http://4OVER.COM (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): user: tradeftp (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): service: vsftpd (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): tty: ftp (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): ruser: tradeftp (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): rhost: mammoth.4over.com http://mammoth.4over.com (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): authtok type: 0 (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): authtok size: 0 (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): newauthtok type: 0 (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): newauthtok size: 0 (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): priv: 1 (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): cli_pid: 17841 (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [be_pam_handler] (0x0100): Sending result [0][4OVER.COM http://4OVER.COM] (Mon Apr 15 09:37:00 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [be_get_account_info] (0x0100): Got request for [3][1][name=tradeftp] (Mon Apr 15 09:37:00 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [sdap_initgr_nested_search] (0x0040): Search for group cn=ipausers,cn=groups,cn=accounts,dc=4over,dc=com, returned 0 results. Skipping / Here (more interesting) is the krb log file /(Mon Apr 15 09:36:54 2013) [[sssd[krb5_child[17855 [unpack_buffer] (0x0100): cmd [241] uid [6676] gid [104] validate [true] offline [false] UPN [trade...@4over.com mailto:trade...@4over.com] (Mon Apr 15 09:36:54 2013) [[sssd[krb5_child[17855 [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_6676_0CTKUc] keytab: [/etc/krb5.keytab] (Mon Apr 15 09:36:54
Re: [Freeipa-users] IPA not authenticating - SSSD issue maybe
We are running 1.9.2 Looks like 3.0 is available for my build of CentOS ~ Any suggestions on how to proceed to updating? Is Multimaster replication sustained during updating? Thank you, Christian Hernandez 1225 Los Angeles Street Glendale, CA 91204 Phone: 877-782-2737 ext. 4566 Fax: 818-265-3152 christi...@4over.com mailto:christi...@4over.com www.4over.com http://www.4over.com On Mon, Apr 15, 2013 at 11:29 AM, Rob Crittenden rcrit...@redhat.comwrote: Christian Hernandez wrote: Hello, From time to time we are getting complaints that I can sum up as I cannot log in to server X Here is a spinet of the /var/log/sssd/sssd_DOMAIN.log ... /(Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [be_pam_handler] (0x0100): Got request with the following data (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): command: PAM_ACCT_MGMT (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): domain: 4OVER.COM http://4OVER.COM (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): user: tradeftp (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): service: vsftpd (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): tty: ftp (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): ruser: tradeftp (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): rhost: mammoth.4over.com http://mammoth.4over.com (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): authtok type: 0 (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): authtok size: 0 (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): newauthtok type: 0 (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): newauthtok size: 0 (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): priv: 1 (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): cli_pid: 17841 (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC rule [allow_all] (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, NULL) [Success] (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, Success) [Success] (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [be_pam_handler_callback] (0x0100): Sending result [0][4OVER.COM http://4OVER.COM] (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [be_pam_handler_callback] (0x0100): Sent result [0][4OVER.COM http://4OVER.COM] (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [be_pam_handler] (0x0100): Got request with the following data (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): command: PAM_SETCRED (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): domain: 4OVER.COM http://4OVER.COM (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): user: tradeftp (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): service: vsftpd (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): tty: ftp (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): ruser: tradeftp (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): rhost: mammoth.4over.com http://mammoth.4over.com (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): authtok type: 0 (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): authtok size: 0 (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): newauthtok type: 0 (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): newauthtok size: 0 (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): priv: 1 (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [pam_print_data] (0x0100): cli_pid: 17841 (Mon Apr 15 09:36:59 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [be_pam_handler] (0x0100): Sending result [0][4OVER.COM http://4OVER.COM ] (Mon Apr 15 09:37:00 2013) [sssd[be[4OVER.COM http://4OVER.COM]]] [be_get_account_info] (0x0100): Got request for [3][1][name=tradeftp] (Mon Apr 15 09:37:00 2013) [sssd[be[4OVER.COM
Re: [Freeipa-users] User Roles and access in GUI
On 04/15/2013 11:11 AM, Chandan Kumar wrote: I think controlling Visibility of tabs would be the best option, if possible, based on Roles as mentioned by Rob. As long as other entries are not visible in UI, even though they have read only access with command line, should be enough. It would not be a security feature though. Just a convenience because the same admin would be able to bind directly to ldap and run a search. This is why we did not go this route. Yes we can hide panels but it would not mean that the user can't easily get that info. So is there really a value in hiding? So far we did not see any this is why we did not do it, but may be you have some arguments that might convince us that we are wrong. Can you please share these arguments with us? On Monday, April 15, 2013, Alexander Bokovoy wrote: On Mon, 15 Apr 2013, Petr Spacek wrote: On 15.4.2013 15:39, Rob Crittenden wrote: There is no easy way to do this. We start with granting all authenticated users read access to the tree with the exception of certain attributes (like passwords). You'd have to start by removing that, then one by one granting read access to the various containers based on, well, something. Would it be possible to create a new role to allow current 'read-all access' and add this role to all users by default? It could be much simpler to change the behaviour with this role, or not? :-) It would affect service accounts (include host/fqdn@REALM) since roles cannot be applied to them, if I remember correctly. We would need to make an exclusive ACI that allows all services to gain read only access... -- / Alexander Bokovoy ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- -- http://about.me/chandank ___ 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
Re: [Freeipa-users] User Roles and access in GUI
On Mon, Apr 15, 2013 at 3:13 PM, Dmitri Pal d...@redhat.com wrote: On 04/15/2013 11:11 AM, Chandan Kumar wrote: I think controlling Visibility of tabs would be the best option, if possible, based on Roles as mentioned by Rob. As long as other entries are not visible in UI, even though they have read only access with command line, should be enough. It would not be a security feature though. Just a convenience because the same admin would be able to bind directly to ldap and run a search. This is why we did not go this route. Yes we can hide panels but it would not mean that the user can't easily get that info. So is there really a value in hiding? So far we did not see any this is why we did not do it, but may be you have some arguments that might convince us that we are wrong. Can you please share these arguments with us? I wasn't involved in this thread before now, however, in our case we do not allow LDAP access (only Kerberos and WebUI) from outside firewall so there *could* be a distinction between the two. I could also present that some users have been confused when they login to change their personal information and see a huge list of other users. Of course, they are directed to their information first upon login, however, we all know that one wrong click can always happen with some users. Perhaps it's better to just put together a new WebUI using the Python API, however, with the fantastic new password reset page in 3.x, I've become lazy and let users access IPA directly. Steve ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] LDAP authentication for 3rd party
On 12 April 2013 23:59, Rich Megginson rmegg...@redhat.com wrote: On 04/11/2013 11:58 PM, Peter Brown wrote: On 12 April 2013 15:51, Simon Williams simon.willi...@thehelpfulcat.comwrote: I use Atlassian products, but use Crowd to provide single signon. This means that Crowd is the only application that needs to authenticate against LDAP. I found that I had to tell Crowd that the server was 389 DS. I could not get it to work set to OpenLDAP. I had a look at crowd but it seemed like overkill when I could just point everything at FreeIPA. We are a small shop so the extra queries weren't going to affect much. I tried telling my Atlaassian apps that freeipa was a 389 ds server but it refused to work properly. Not sure what that means, exactly. Check the 389 access logs to see what operations Atlassian is performing against 389. I don't remember the exact error and they get used every day and they work as is so I will have to wait for an update to switch it over to see what errors it produces. Slightly strange considering the ldap modules for all of them are the same as the one used in crowd. Regards Simon On 11 Apr 2013 23:36, Peter Brown rendhal...@gmail.com wrote: On 12 April 2013 05:04, John Dennis jden...@redhat.com wrote: On 04/11/2013 02:47 PM, Bartek Moczulski wrote: hi, I've got a problem with using IPA as authentication source over LDAP. Generally there are two approaches to LDAP authentication: 1. bind using admin account and read passwords from user objects (but in ipa you cannot read passwords through ldap, right?) 2. bind to authenticate - service tries to log in to ldap with user's credentials. If login is successful authentication is also succesful - this approach does not work because you cannot login to IPA ldap using bare username, you need a full LDAP DN. Most applications I know of that do bind as user to authenticate also permit you to specify a format string into which the user name is inserted (i.e. the format string is the dn, e.g. uid=%u,cn=users,cn=accounts,dc=example,dc=com) -or- they do a search to discover the dn. If you application does not support either approach it's broken IMHO. I have used this method for Confluence, Jira, Stash, Icinga and Foreman. I will be adding more applications in the future as well. If the application doesn't support Kerberos it's the next best thing in my opinion. I have also use it to get email lists into dovecot and postfix. One caveat I found is you need to tell Atlassian applications that FreeIPA is a plain OpenLDAP server to get it to work. Apart from that it works out of the box as they say. Reading passwords and/or password hashes is not supported for security reasons. Now, I've got a 3rd party application supporting both mentioned above appoaches and the question is - how to make it work with ipa? thanks in advance, Bartek. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- John Dennis jden...@redhat.com 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 listFreeipa-users@redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] IPA not authenticating - SSSD issue maybe
On Mon, Apr 15, 2013 at 02:29:18PM -0400, Rob Crittenden wrote: There are some odd errors in ldap_child.log but it seems to cover a later period than the other logs (not being able to bind using its keytab is a bad thing). I think what you'll want to do, and this may be relatively tough, is try to correlate these failures with the 389-ds access log and the KDC logs to see if there are equivalent failures at around the same times. I agree, the ldap_child failing usually indicates an issue with the keytab and/or the KDC. The ldap_child functionality is roughly equivalent to kinit -k. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] User Roles and access in GUI
I agree it won't be a security feature nor you are doing wrong by not adding it. However, it might come as nice to have feature. Let me explain you my condition. We host web application where lot of DNS entries (Public and Internal) are created for different kind of requests and features. Now we already have a separate DNS server, Separate Manual Linux User/Access Control management by puppet. Linux users ACL have no relationship with the web application user (which is internal to the web app). So FreeIPA can help me to centralize the Linux user-management as well as (Public and Internal) DNS. However, the problem is : traditionally the access levels were different for DNS users (support guys) and user management (sysadmins). Now bring both system together even the Host based access control, sudoers rule everything becomes visible to non-sysadmin group. You are right that every user could query all entries from command line and hence it won't help to secure the system, but not having it on GUI may help to avoid obvious visibility of the whole directory. I believe similar GUI views could be applied for discussion http://osdir.com/ml/freeipa-users/2013-03/msg00218.html where geographically separate Organization units may share the same directory with limited visibility on other branches. Having said that, I am not sure how feasible/logical my view is owing to my limited knowledge in 389 directory server and IPA. Thanks Chandan On Monday, April 15, 2013, Dmitri Pal wrote: On 04/15/2013 11:11 AM, Chandan Kumar wrote: I think controlling Visibility of tabs would be the best option, if possible, based on Roles as mentioned by Rob. As long as other entries are not visible in UI, even though they have read only access with command line, should be enough. It would not be a security feature though. Just a convenience because the same admin would be able to bind directly to ldap and run a search. This is why we did not go this route. Yes we can hide panels but it would not mean that the user can't easily get that info. So is there really a value in hiding? So far we did not see any this is why we did not do it, but may be you have some arguments that might convince us that we are wrong. Can you please share these arguments with us? On Monday, April 15, 2013, Alexander Bokovoy wrote: On Mon, 15 Apr 2013, Petr Spacek wrote: On 15.4.2013 15:39, Rob Crittenden wrote: There is no easy way to do this. We start with granting all authenticated users read access to the tree with the exception of certain attributes (like passwords). You'd have to start by removing that, then one by one granting read access to the various containers based on, well, something. Would it be possible to create a new role to allow current 'read-all access' and add this role to all users by default? It could be much simpler to change the behaviour with this role, or not? :-) It would affect service accounts (include host/fqdn@REALM) since roles cannot be applied to them, if I remember correctly. We would need to make an exclusive ACI that allows all services to gain read only access... -- / Alexander Bokovoy ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- -- http://about.me/chandank ___ Freeipa-users mailing listFreeipa-users@redhat.comhttps://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/ -- -- http://about.me/chandank ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] IPA not authenticating - SSSD issue maybe
Okay, So I tried to update to the newest version. Update went okay and users can authenticate (as far as I can tell)... But I think may be replication broke? [r...@ipa1.da2.4over.com log]# ipa-replica-manage force-sync --from= ipa1.gln.4over.com Invalid password Any ideas? Thank you, Christian Hernandez 1225 Los Angeles Street Glendale, CA 91204 Phone: 877-782-2737 ext. 4566 Fax: 818-265-3152 christi...@4over.com mailto:christi...@4over.com www.4over.com http://www.4over.com On Mon, Apr 15, 2013 at 4:19 PM, Jakub Hrozek jhro...@redhat.com wrote: On Mon, Apr 15, 2013 at 02:29:18PM -0400, Rob Crittenden wrote: There are some odd errors in ldap_child.log but it seems to cover a later period than the other logs (not being able to bind using its keytab is a bad thing). I think what you'll want to do, and this may be relatively tough, is try to correlate these failures with the 389-ds access log and the KDC logs to see if there are equivalent failures at around the same times. I agree, the ldap_child failing usually indicates an issue with the keytab and/or the KDC. The ldap_child functionality is roughly equivalent to kinit -k. ___ 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 Roles and access in GUI
On 04/15/2013 07:42 PM, Chandan Kumar wrote: I agree it won't be a security feature nor you are doing wrong by not adding it. However, it might come as nice to have feature. Let me explain you my condition. We host web application where lot of DNS entries (Public and Internal) are created for different kind of requests and features. Now we already have a separate DNS server, Separate Manual Linux User/Access Control management by puppet. Linux users ACL have no relationship with the web application user (which is internal to the web app). So FreeIPA can help me to centralize the Linux user-management as well as (Public and Internal) DNS. However, the problem is : traditionally the access levels were different for DNS users (support guys) and user management (sysadmins). Now bring both system together even the Host based access control, sudoers rule everything becomes visible to non-sysadmin group. You are right that every user could query all entries from command line and hence it won't help to secure the system, but not having it on GUI may help to avoid obvious visibility of the whole directory. I believe similar GUI views could be applied for discussion http://osdir.com/ml/freeipa-users/2013-03/msg00218.html where geographically separate Organization units may share the same directory with limited visibility on other branches. Having said that, I am not sure how feasible/logical my view is owing to my limited knowledge in 389 directory server and IPA. I think you are talking about this: https://fedorahosted.org/freeipa/ticket/217 and somewhat about this https://fedorahosted.org/freeipa/ticket/1313 Would you mind adding the details of your use case to one of those two tickets? Alternatively we can start another ticket. However I think we should have some kind of a complete solution that covers LDAP, UI and CLI consistently. Doing it right would be a huge task IMO. For LDAP we would probably have to implement some kind of smart proxy that would reply only to the requests that user are entitled to. Same with CLI and UI. But the point is that one configuration should be respected by all three at the same time. For example if you are not allowed to manage sudo the sudo commands should not return any data as well as LDAP searches and there should be no panel in the UI. I am really reluctant to fix just UI because we would end up different components of the system behaving differently and it would be hard to evolve them and maintain. Thanks Dmitri Thanks Chandan On Monday, April 15, 2013, Dmitri Pal wrote: On 04/15/2013 11:11 AM, Chandan Kumar wrote: I think controlling Visibility of tabs would be the best option, if possible, based on Roles as mentioned by Rob. As long as other entries are not visible in UI, even though they have read only access with command line, should be enough. It would not be a security feature though. Just a convenience because the same admin would be able to bind directly to ldap and run a search. This is why we did not go this route. Yes we can hide panels but it would not mean that the user can't easily get that info. So is there really a value in hiding? So far we did not see any this is why we did not do it, but may be you have some arguments that might convince us that we are wrong. Can you please share these arguments with us? On Monday, April 15, 2013, Alexander Bokovoy wrote: On Mon, 15 Apr 2013, Petr Spacek wrote: On 15.4.2013 15:39, Rob Crittenden wrote: There is no easy way to do this. We start with granting all authenticated users read access to the tree with the exception of certain attributes (like passwords). You'd have to start by removing that, then one by one granting read access to the various containers based on, well, something. Would it be possible to create a new role to allow current 'read-all access' and add this role to all users by default? It could be much simpler to change the behaviour with this role, or not? :-) It would affect service accounts (include host/fqdn@REALM) since roles cannot be applied to them, if I remember correctly. We would need to make an exclusive ACI that allows all services to gain read only access... -- / Alexander Bokovoy ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- -- http://about.me/chandank ___ Freeipa-users mailing list Freeipa-users@redhat.com
Re: [Freeipa-users] IPA not authenticating - SSSD issue maybe
On 04/15/2013 08:41 PM, Christian Hernandez wrote: Yup, looks like replication is broken =\ [r...@ipa1.gln.4over.com mailto:r...@ipa1.gln.4over.com ipa]# ipa-replica-manage disconnect ipa1.la3.4over.com http://ipa1.la3.4over.com Failed to get list of agreements from 'ipa1.la3.4over.com http://ipa1.la3.4over.com': Invalid credentials SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context [r...@ipa1.gln.4over.com mailto:r...@ipa1.gln.4over.com ipa]# ipa-replica-manage list ipa1.la3.4over.com http://ipa1.la3.4over.com Failed to get data from 'ipa1.la3.4over.com http://ipa1.la3.4over.com': Invalid credentials SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context [r...@ipa1.gln.4over.com mailto:r...@ipa1.gln.4over.com ipa]# ipa-replica-manage list ipa1.la3.4over.com http://ipa1.la3.4over.com: master ipa1.gln.4over.com http://ipa1.gln.4over.com: master ipa1.da2.4over.com http://ipa1.da2.4over.com: master Do the machines resolve each other correctly? Thank you, Christian Hernandez 1225 Los Angeles Street Glendale, CA 91204 Phone: 877-782-2737 ext. 4566 Fax: 818-265-3152 christi...@4over.com mailto:christi...@4over.com mailto:christi...@4over.com mailto:christi...@4over.com www.4over.com http://www.4over.com/ http://www.4over.com http://www.4over.com/ On Mon, Apr 15, 2013 at 4:58 PM, Christian Hernandez christi...@4over.com mailto:christi...@4over.com wrote: Okay, So I tried to update to the newest version. Update went okay and users can authenticate (as far as I can tell)... But I think may be replication broke? [r...@ipa1.da2.4over.com mailto:r...@ipa1.da2.4over.com log]# ipa-replica-manage force-sync --from=ipa1.gln.4over.com http://ipa1.gln.4over.com Invalid password Any ideas? Thank you, Christian Hernandez 1225 Los Angeles Street Glendale, CA 91204 Phone: 877-782-2737 ext. 4566 Fax: 818-265-3152 christi...@4over.com mailto:christi...@4over.com mailto:christi...@4over.com mailto:christi...@4over.com www.4over.com http://www.4over.com/ http://www.4over.com http://www.4over.com/ On Mon, Apr 15, 2013 at 4:19 PM, Jakub Hrozek jhro...@redhat.com mailto:jhro...@redhat.com wrote: On Mon, Apr 15, 2013 at 02:29:18PM -0400, Rob Crittenden wrote: There are some odd errors in ldap_child.log but it seems to cover a later period than the other logs (not being able to bind using its keytab is a bad thing). I think what you'll want to do, and this may be relatively tough, is try to correlate these failures with the 389-ds access log and the KDC logs to see if there are equivalent failures at around the same times. I agree, the ldap_child failing usually indicates an issue with the keytab and/or the KDC. The ldap_child functionality is roughly equivalent to kinit -k. ___ 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 -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] IPA not authenticating - SSSD issue maybe
Yes; I verified that both forward and reverse DNS match on all nodes. Thank you, Christian Hernandez 1225 Los Angeles Street Glendale, CA 91204 Phone: 877-782-2737 ext. 4566 Fax: 818-265-3152 christi...@4over.com mailto:christi...@4over.com www.4over.com http://www.4over.com On Mon, Apr 15, 2013 at 6:21 PM, Dmitri Pal d...@redhat.com wrote: On 04/15/2013 08:41 PM, Christian Hernandez wrote: Yup, looks like replication is broken =\ [r...@ipa1.gln.4over.com ipa]# ipa-replica-manage disconnect ipa1.la3.4over.com Failed to get list of agreements from 'ipa1.la3.4over.com': Invalid credentials SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context [r...@ipa1.gln.4over.com ipa]# ipa-replica-manage list ipa1.la3.4over.com Failed to get data from 'ipa1.la3.4over.com': Invalid credentials SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context [r...@ipa1.gln.4over.com ipa]# ipa-replica-manage list ipa1.la3.4over.com: master ipa1.gln.4over.com: master ipa1.da2.4over.com: master Do the machines resolve each other correctly? Thank you, Christian Hernandez 1225 Los Angeles Street Glendale, CA 91204 Phone: 877-782-2737 ext. 4566 Fax: 818-265-3152 christi...@4over.com mailto:christi...@4over.com www.4over.com http://www.4over.com On Mon, Apr 15, 2013 at 4:58 PM, Christian Hernandez christi...@4over.com wrote: Okay, So I tried to update to the newest version. Update went okay and users can authenticate (as far as I can tell)... But I think may be replication broke? [r...@ipa1.da2.4over.com log]# ipa-replica-manage force-sync --from= ipa1.gln.4over.com Invalid password Any ideas? Thank you, Christian Hernandez 1225 Los Angeles Street Glendale, CA 91204 Phone: 877-782-2737 ext. 4566 Fax: 818-265-3152 christi...@4over.com mailto:christi...@4over.com www.4over.com http://www.4over.com On Mon, Apr 15, 2013 at 4:19 PM, Jakub Hrozek jhro...@redhat.comwrote: On Mon, Apr 15, 2013 at 02:29:18PM -0400, Rob Crittenden wrote: There are some odd errors in ldap_child.log but it seems to cover a later period than the other logs (not being able to bind using its keytab is a bad thing). I think what you'll want to do, and this may be relatively tough, is try to correlate these failures with the 389-ds access log and the KDC logs to see if there are equivalent failures at around the same times. I agree, the ldap_child failing usually indicates an issue with the keytab and/or the KDC. The ldap_child functionality is roughly equivalent to kinit -k. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing listFreeipa-users@redhat.comhttps://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
Re: [Freeipa-users] IPA not authenticating - SSSD issue maybe
Looks like I've narrowed it down to...something... [r...@ipa1.la3.4over.com ~]# ipa-replica-manage list ipa1.gln.4over.com Failed to get data from 'ipa1.gln.4over.com': Invalid credentials SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context [r...@ipa1.la3.4over.com ~]# ipa-replica-manage list ipa1.da2.4over.com ipa1.gln.4over.com: replica ipa1.la3.4over.com: replica [r...@ipa1.la3.4over.com ~]# ipa-replica-manage list $(hostname) ipa1.da2.4over.com: replica ipa1.gln.4over.com: replica [r...@ipa1.la3.4over.com ~]# rpm -qa |egrep '389|ipa' ipa-admintools-3.0.0-26.el6_4.2.x86_64 python-iniparse-0.3.1-2.1.el6.noarch ipa-python-3.0.0-26.el6_4.2.x86_64 libipa_hbac-python-1.9.2-82.4.el6_4.x86_64 389-ds-base-libs-1.2.11.15-12.el6_4.x86_64 ipa-pki-common-theme-9.0.3-7.el6.noarch ipa-pki-ca-theme-9.0.3-7.el6.noarch ipa-server-selinux-3.0.0-26.el6_4.2.x86_64 libipa_hbac-1.9.2-82.4.el6_4.x86_64 ipa-client-3.0.0-26.el6_4.2.x86_64 389-ds-base-1.2.11.15-12.el6_4.x86_64 ipa-server-3.0.0-26.el6_4.2.x86_64 Although when I try to remove the replication agreement...I can't =\ [r...@ipa1.la3.4over.com ~]# ipa-replica-manage disconnect $(hostname) ipa1.gln.4over.com Failed to get list of agreements from 'ipa1.gln.4over.com': Invalid credentials SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context Thank you, Christian Hernandez 1225 Los Angeles Street Glendale, CA 91204 Phone: 877-782-2737 ext. 4566 Fax: 818-265-3152 christi...@4over.com mailto:christi...@4over.com www.4over.com http://www.4over.com On Mon, Apr 15, 2013 at 6:58 PM, Christian Hernandez christi...@4over.comwrote: Yes; I verified that both forward and reverse DNS match on all nodes. Thank you, Christian Hernandez 1225 Los Angeles Street Glendale, CA 91204 Phone: 877-782-2737 ext. 4566 Fax: 818-265-3152 christi...@4over.com mailto:christi...@4over.com www.4over.com http://www.4over.com On Mon, Apr 15, 2013 at 6:21 PM, Dmitri Pal d...@redhat.com wrote: On 04/15/2013 08:41 PM, Christian Hernandez wrote: Yup, looks like replication is broken =\ [r...@ipa1.gln.4over.com ipa]# ipa-replica-manage disconnect ipa1.la3.4over.com Failed to get list of agreements from 'ipa1.la3.4over.com': Invalid credentials SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context [r...@ipa1.gln.4over.com ipa]# ipa-replica-manage list ipa1.la3.4over.com Failed to get data from 'ipa1.la3.4over.com': Invalid credentials SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context [r...@ipa1.gln.4over.com ipa]# ipa-replica-manage list ipa1.la3.4over.com: master ipa1.gln.4over.com: master ipa1.da2.4over.com: master Do the machines resolve each other correctly? Thank you, Christian Hernandez 1225 Los Angeles Street Glendale, CA 91204 Phone: 877-782-2737 ext. 4566 Fax: 818-265-3152 christi...@4over.com mailto:christi...@4over.com www.4over.com http://www.4over.com On Mon, Apr 15, 2013 at 4:58 PM, Christian Hernandez christi...@4over.com wrote: Okay, So I tried to update to the newest version. Update went okay and users can authenticate (as far as I can tell)... But I think may be replication broke? [r...@ipa1.da2.4over.com log]# ipa-replica-manage force-sync --from= ipa1.gln.4over.com Invalid password Any ideas? Thank you, Christian Hernandez 1225 Los Angeles Street Glendale, CA 91204 Phone: 877-782-2737 ext. 4566 Fax: 818-265-3152 christi...@4over.com mailto:christi...@4over.com www.4over.com http://www.4over.com On Mon, Apr 15, 2013 at 4:19 PM, Jakub Hrozek jhro...@redhat.comwrote: On Mon, Apr 15, 2013 at 02:29:18PM -0400, Rob Crittenden wrote: There are some odd errors in ldap_child.log but it seems to cover a later period than the other logs (not being able to bind using its keytab is a bad thing). I think what you'll want to do, and this may be relatively tough, is try to correlate these failures with the 389-ds access log and the KDC logs to see if there are equivalent failures at around the same times. I agree, the ldap_child failing usually indicates an issue with the keytab and/or the KDC. The ldap_child functionality is roughly equivalent to kinit -k. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing listFreeipa-users@redhat.comhttps://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
Re: [Freeipa-users] IPA not authenticating - SSSD issue maybe
Christian Hernandez wrote: Looks like I've narrowed it down to...something... [r...@ipa1.la3.4over.com mailto:r...@ipa1.la3.4over.com ~]# ipa-replica-manage list ipa1.gln.4over.com http://ipa1.gln.4over.com Failed to get data from 'ipa1.gln.4over.com http://ipa1.gln.4over.com': Invalid credentials SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context [r...@ipa1.la3.4over.com mailto:r...@ipa1.la3.4over.com ~]# ipa-replica-manage list ipa1.da2.4over.com http://ipa1.da2.4over.com ipa1.gln.4over.com http://ipa1.gln.4over.com: replica ipa1.la3.4over.com http://ipa1.la3.4over.com: replica [r...@ipa1.la3.4over.com mailto:r...@ipa1.la3.4over.com ~]# ipa-replica-manage list $(hostname) ipa1.da2.4over.com http://ipa1.da2.4over.com: replica ipa1.gln.4over.com http://ipa1.gln.4over.com: replica [r...@ipa1.la3.4over.com mailto:r...@ipa1.la3.4over.com ~]# rpm -qa |egrep '389|ipa' ipa-admintools-3.0.0-26.el6_4.2.x86_64 python-iniparse-0.3.1-2.1.el6.noarch ipa-python-3.0.0-26.el6_4.2.x86_64 libipa_hbac-python-1.9.2-82.4.el6_4.x86_64 389-ds-base-libs-1.2.11.15-12.el6_4.x86_64 ipa-pki-common-theme-9.0.3-7.el6.noarch ipa-pki-ca-theme-9.0.3-7.el6.noarch ipa-server-selinux-3.0.0-26.el6_4.2.x86_64 libipa_hbac-1.9.2-82.4.el6_4.x86_64 ipa-client-3.0.0-26.el6_4.2.x86_64 389-ds-base-1.2.11.15-12.el6_4.x86_64 ipa-server-3.0.0-26.el6_4.2.x86_64 Although when I try to remove the replication agreement...I can't =\ [r...@ipa1.la3.4over.com mailto:r...@ipa1.la3.4over.com ~]# ipa-replica-manage disconnect $(hostname) ipa1.gln.4over.com http://ipa1.gln.4over.com Failed to get list of agreements from 'ipa1.gln.4over.com http://ipa1.gln.4over.com': Invalid credentials SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context A couple of things to try: - Check the KDC logs on the various hosts to see what error it is logging trying to get a ticket. - kdestroy and let ipa-replica-manage prompt you for the DM password, or pass it via -p on the command-line The first might tell you why you are seeing an auth failure, the second should show the status of replication and let you run other commands. I'm not sure that disconnecting is going to fix anything though. I'm not sure what it is you're trying to do there. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
