Re: [Freeipa-users] Resynchronize Samba Passwort
Am 16.10.2012 23:40, schrieb Simo Sorce: On Tue, 2012-10-16 at 14:22 -0700, Nathan Kinder wrote: On 10/16/2012 05:21 AM, Simo Sorce wrote: On Tue, 2012-10-16 at 10:06 +0200, Marc Grimme wrote: Am 15.10.2012 15:50, schrieb Simo Sorce: On Mon, 2012-10-15 at 14:15 +0200, Marc Grimme wrote: Am 14.10.2012 23:14, schrieb Simo Sorce: On Fri, 2012-10-12 at 16:47 +0200, Marc Grimme wrote: Right I am ok with sambaPwdMustChange not being set. That's all good. What about sambaPwdLastSet ? Not set when a user is created new. It should be set when you give the user a password as long at the sambaSamAccount objectclass is added to the user. When I change the password: sambaPwdLastSet: 0 If this is when you set the password as an admin, it is expected. Ok, understood. But it should change when the user resets his/her password, right? And that is not happening. When the user sets his/her password the sambaPwdLastSet stays untouched. That's odd, how does the user change the password ? Not working with samba! Need to apply my script (see below). Let me ask one thing, are you changing the password as a user ? Or have you tested only setting the password as admin ? I set the initial password as admin. Then the user logs in to a server (sssd, ssh, ipa-member) and is requested to change his/her password. This works but the sambaPwdLastSet stays untouched. Ok this is clearly a bug, can you open a bugzilla against RHEL 6.3 ? If the latter this applies: http://www.freeipa.org/page/NewPasswordsExpired Checked it. But that was my understanding nevertheless. I think it may require: SambaSID=S-1-5-21-xx-xx-xx-assign Simo. # ipa user-add tuser2 --first=Test --last=User2 --shell=/bin/false --setattr=SambaSID=S-1-5-21-xx-xx-xx-assign --- Added user tuser2 --- User login: tuser2 First name: Test Last name: User2 Full name: Test User2 Display name: Test User2 Initials: TU Home directory: /home/tuser2 GECOS field: Test User2 Login shell: /bin/false Kerberos principal: tus...@cl.atix UID: 47378 GID: 47378 Password: False Kerberos keys available: False # ldapsearch -LLL -b uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix sambaSID SASL/GSSAPI authentication started SASL username: ad...@cl.atix SASL SSF: 56 SASL data security layer installed. dn: uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix sambaSID: S-1-5-21-xx-xx-xx-assign The following objectclasses are being set when creating a new user: # ldapsearch -LLL -b uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix objectClass SASL/GSSAPI authentication started SASL username: ad...@cl.atix SASL SSF: 56 SASL data security layer installed. dn: uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixaccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: sambaSAMAccount objectClass: ipasshuser objectClass: ipaSshGroupOfPubKeys objectClass: mepOriginEntry Thanks for your help Seem like a DNA bug ... then, Nathan do you have any idea ? What DNA configuration is used? From a previous mail this look to be the config. Marc is this still correct ? Although my configurations looks ok, doesn't it? # ldapsearch -LLL -b cn=SambaSID,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config -D cn=Directory Manager -x -W Enter LDAP Password: dn: cn=SambaSid,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config objectClass: top objectClass: extensibleObject dnatype: sambaSID dnaprefix: S-1-5-21-1310149461-105972258- dnainterval: 1 dnamagicregen: assign dnafilter: (|(objectclass=sambasamaccount)(objectclass=sambagroupmapping)) dnascope: dc=atix,dc=cl cn: SambaSid dnanextvalue: 15400 Yes didn't change anything. And I already tried --setattr=sambaSid=assign and --setattr=sambaSid=S-1-5-..-assign. Both didn't lead to an attribute sambaSid being set per user. Thanks Marc. -- Marc Grimme E-Mail: grimme( at )atix.de ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] RHEL5 IPA client for RHEL6.3 IPA server?
I have looked back through the last year of mail archives for this list and haven't yet found anything on this. I spent a day or so trying to get a RHEL6.3 server set up with several clients, Clients: RHEL 6.3 32-bit RHEL 6.3 64-bit RHEL 5.8 32-bit RHEL 5.8 64-bit So far I've been able to get the RHEL 6.3 clients to register and setup up as a client for RHEL 6.3 IPA server but whenever I try to install the ipa-client on RHEL 5.8 I just get the following error: [root@rh5 ~]# ipa-client-install Discovery was successful! Hostname: rh5.summersoft Realm: SUMMERSOFT DNS Domain: summersoft IPA Server: ipaserver.summersoft BaseDN: dc=summersoft Continue to configure the system with these values? [no]: yes User authorized to enroll computers: admin Synchronizing time with KDC... Unable to sync time with IPA NTP server, assuming the time is in sync. Password for admin@SUMMERSOFT: Joining realm failed: SASL Bind failed Local error (-2) ! child exited with 9 Installation failed. Rolling back changes. IPA client is not configured on this system. In the install log: 2012-10-16 23:16:34,410 DEBUG stderr= 2012-10-16 23:16:35,032 DEBUG args=/usr/sbin/ipa-join -s ipaserver.summersoft -b dc=summersoft 2012-10-16 23:16:35,032 DEBUG stdout= 2012-10-16 23:16:35,032 DEBUG stderr=SASL Bind failed Local error (-2) ! child exited with 9 Is RHEL 5.8 a supported client for RHEL 6.3 IPA server? If so, what am I doing wrong? I tried following both the RHEL 5.8 and RHEL 6.3 install instructions but nothing I have tried is working so far! Thanks in advance for any help or pointers you can provide. - David Summers ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] RHEL5 IPA client for RHEL6.3 IPA server?
David Summers wrote: I have looked back through the last year of mail archives for this list and haven't yet found anything on this. I spent a day or so trying to get a RHEL6.3 server set up with several clients, Clients: RHEL 6.3 32-bit RHEL 6.3 64-bit RHEL 5.8 32-bit RHEL 5.8 64-bit So far I've been able to get the RHEL 6.3 clients to register and setup up as a client for RHEL 6.3 IPA server but whenever I try to install the ipa-client on RHEL 5.8 I just get the following error: [root@rh5 ~]# ipa-client-install Discovery was successful! Hostname: rh5.summersoft Realm: SUMMERSOFT DNS Domain: summersoft IPA Server: ipaserver.summersoft BaseDN: dc=summersoft Continue to configure the system with these values? [no]: yes User authorized to enroll computers: admin Synchronizing time with KDC... Unable to sync time with IPA NTP server, assuming the time is in sync. Password for admin@SUMMERSOFT: Joining realm failed: SASL Bind failed Local error (-2) ! child exited with 9 Installation failed. Rolling back changes. IPA client is not configured on this system. In the install log: 2012-10-16 23:16:34,410 DEBUG stderr= 2012-10-16 23:16:35,032 DEBUG args=/usr/sbin/ipa-join -s ipaserver.summersoft -b dc=summersoft 2012-10-16 23:16:35,032 DEBUG stdout= 2012-10-16 23:16:35,032 DEBUG stderr=SASL Bind failed Local error (-2) ! child exited with 9 Is RHEL 5.8 a supported client for RHEL 6.3 IPA server? If so, what am I doing wrong? I tried following both the RHEL 5.8 and RHEL 6.3 install instructions but nothing I have tried is working so far! Thanks in advance for any help or pointers you can provide. - David Summers What is the version of the 5.8 ipa-client package? You want ipa-client-2.1.3-2.el5_8 rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
Okay, Rule name: test4 Enabled: TRUE Command category: all Users: asteinfeld Hosts: dbduwdu062.dbr.roche.com Host Groups: tempsudo Client dbduwdu062 is matched in the rule by both the hosts and groups entry. /etc/nsswitch.conf has: Netgroups: files sss Getent netgroup tempsudo returns: [jmacklin@dbduwdu062 Desktop]$ getent netgroup tempsudo tempsudo (dbduwdu063.dbr.roche.com, -, dbr.roche.com) (dbduwdu062.dbr.roche.com, -, dbr.roche.com) To the previous ldapsearch request: [jmacklin@dbduwdu062 Desktop]$ ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com ou=SUDOers,dc=dbr,dc=roche,dc=com SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Server is unwilling to perform (53) additional info: Entry permanently locked. I am still scratching my head on this one... Cheers, Jason If you look closely, the reason that your admin works is because it appears to be matching a sudo rule who has the ALL hosts value set. When you run the non working user, it is attempting to match the hostname/hostgroup to the rule and fails to do so. Try this. Type: getent netgroup hostgroupname - your host's hostgroup goes there. ^ that command should return all of the hosts in your hostgroup. If it does not, then check /etc/nsswitch.conf and make sure that netgroup is set to use sss. You will also need to make sure that the output of: domainname or nisdomainname matches your expected domain. Let me know how things look after trying that. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Setting up sudo in FreeIPA v2.2
On Tue, Oct 16, 2012 at 10:50 PM, JR Aquino jr.aqu...@citrix.com wrote: On the host in question Run the command: domainname That wants to match whatever your domain is. If it doesn't it will fail even if you have all the server rules configured correctly. This is a sudo + netgroups/hostgroups 'feature' ~ Jr Aquino | Sr. Information Security Specialist GIAC Certified Incident Handler | GIAC WebApp Penetration Tester Citrix Online | 7408 Hollister Avenue | Goleta, CA 93117 T: +1 805.690.3478 C: +1 805.717.0365 jr.aqu...@citrixonline.com http://www.citrixonline.com On Oct 16, 2012, at 2:26 PM, Toasted Penguin toastedpenguini...@gmail.com wrote: I have the server setup to manage sudo and I configured a target client to use the IPA server for sudo. When a user tries to use sudo (in this case sudo su -) it fails and they get the error user is not allowed to run sudo on client-host. This incident will be reported. I verified via the log files that the client is making requests to the IPA server when the user is attemping to use sudo and it fails. I temporarily disabled using the IPA server for sudo and I get the standard User not in the sudoers file Its starting to look like the server rules maybe the issue but I believe I have the sudo rule setup correctly. I created a sudo command /bin/su, created a sudo rule Sudo to root , added the group the user in question is a part of to the WHO--User Groups; Added the Host Group the target client host is part of to Access This Host--Host Groups and added the sudo command to the sudo rule via Allow--Sudo Allow Commands. When I delete the sudo rule I get the same result as I did when I temporarily disbled the client host using tghe IPA server for sudo verification. Any ideas why or where to look to figure out this issue? Thanks, David ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users Executing domainname results in the correct domain for theFreeIPA service. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
On 10/17/2012 07:26 AM, Macklin, Jason wrote: Okay, Rule name: test4 Enabled: TRUE Command category: all Users: asteinfeld Hosts: dbduwdu062.dbr.roche.com Host Groups: tempsudo Client dbduwdu062 is matched in the rule by both the hosts and groups entry. /etc/nsswitch.conf has: Netgroups: files sss Getent netgroup tempsudo returns: [jmacklin@dbduwdu062 Desktop]$ getent netgroup tempsudo tempsudo (dbduwdu063.dbr.roche.com, -, dbr.roche.com) (dbduwdu062.dbr.roche.com, -, dbr.roche.com) To the previous ldapsearch request: [jmacklin@dbduwdu062 Desktop]$ ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com ou=SUDOers,dc=dbr,dc=roche,dc=com SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Server is unwilling to perform (53) additional info: Entry permanently locked. I am still scratching my head on this one... This means you cannot search using your kerberos ticket because the corresponding entry is locked. Try using directory manager: ldapsearch -x -D cn=directory manager -W -H ldap://dbduvdu145.dbr.roche.com ou=SUDOers,dc=dbr,dc=roche,dc=com Cheers, Jason If you look closely, the reason that your admin works is because it appears to be matching a sudo rule who has the ALL hosts value set. When you run the non working user, it is attempting to match the hostname/hostgroup to the rule and fails to do so. Try this. Type: getent netgroup hostgroupname- your host's hostgroup goes there. ^ that command should return all of the hosts in your hostgroup. If it does not, then check /etc/nsswitch.conf and make sure that netgroup is set to use sss. You will also need to make sure that the output of: domainname or nisdomainname matches your expected domain. Let me know how things look after trying that. ___ 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] Sudo works for full access, but not on a per command or host level.
ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com
ou=SUDOers,dc=dbr,dc=roche,dc=com
SASL/GSSAPI authentication started
SASL username: ad...@dbr.roche.com
SASL SSF: 56
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base (default) with scope subtree
# filter: ou=SUDOers,dc=dbr,dc=roche,dc=com
# requesting: ALL
#
# search result
search: 4
result: 32 No such object
# numResponses: 1
Different response, but still no success with the non-working account.
Cheers,
Jason
-Original Message-
From: Dmitri Pal [mailto:d...@redhat.com]
Sent: Wednesday, October 17, 2012 11:56 AM
To: Macklin, Jason {DASB~Branford}
Cc: jr.aqu...@citrix.com; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per
command or host level.
On 10/17/2012 09:26 AM, Macklin, Jason wrote:
Okay,
Rule name: test4
Enabled: TRUE
Command category: all
Users: asteinfeld
Hosts: dbduwdu062.dbr.roche.com
Host Groups: tempsudo
Client dbduwdu062 is matched in the rule by both the hosts and groups entry.
/etc/nsswitch.conf has:
Netgroups: files sss
Getent netgroup tempsudo returns:
[jmacklin@dbduwdu062 Desktop]$ getent netgroup tempsudo
tempsudo (dbduwdu063.dbr.roche.com, -, dbr.roche.com)
(dbduwdu062.dbr.roche.com, -, dbr.roche.com)
To the previous ldapsearch request:
[jmacklin@dbduwdu062 Desktop]$ ldapsearch -Y GSSAPI -H
ldap://dbduvdu145.dbr.roche.com ou=SUDOers,dc=dbr,dc=roche,dc=com
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Server is unwilling to perform (53)
additional info: Entry permanently locked.
It seems that you tried the wrong password and the account is now temporarily
locked thus the server is unwilling to perform authentication for this account.
I am still scratching my head on this one...
Cheers,
Jason
If you look closely, the reason that your admin works is because it appears
to be matching a sudo rule who has the ALL hosts value set.
When you run the non working user, it is attempting to match the
hostname/hostgroup to the rule and fails to do so.
Try this. Type: getent netgroup hostgroupname - your host's hostgroup goes
there.
^ that command should return all of the hosts in your hostgroup. If it does
not, then check /etc/nsswitch.conf and make sure that netgroup is set to use
sss.
You will also need to make sure that the output of: domainname or
nisdomainname matches your expected domain.
Let me know how things look after trying that.
--
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] Failed installation
I recently tried installing freeipa on a new server, but ipa-server-install had problems around this point: Configuring certificate server: Estimated time 3 minutes 30 seconds [1/18]: creating certificate server user [2/18]: creating pki-ca instance [3/18]: configuring certificate server instance ipa : CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname fs1.wedgeofli.me-cs_port 9445 -client_certdb_dir /tmp/tmp-UvBMbL -client_certdb_pwd -preop_pin HHxKHUz5RRfzQ3OkFMlR -domain_name IPA -admin_user admin -admin_email root@localhost -admin_ -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject CN=ipa-ca-agent,O=WEDGEOFLI.ME -ldap_host fs1.wedgeofli.me -ldap_port 7389 -bind_dn cn=Directory Manager -bind_ -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12 true -backup_pwd -subsystem_name pki-cad -token_name internal -ca_subsystem_cert_subject_name CN=CA Subsystem,O=WEDGEOFLI.ME-ca_ocsp_cert_subject_name CN=OCSP Subsystem,O= WEDGEOFLI.ME -ca_server_cert_subject_name CN=fs1.wedgeofli.me,O=WEDGEOFLI.ME-ca_audit_signing_cert_subject_name CN=CA Audit,O= WEDGEOFLI.ME -ca_sign_cert_subject_name CN=Certificate Authority,O= WEDGEOFLI.ME -external false -clone false' returned non-zero exit status 255 Unexpected error - see ipaserver-install.log for details: Configuration of CA failed [root@fs1 ~]# The logfile revealed the following stack trace: # Attempting to connect to: fs1.wedgeofli.me:9445 Exception in LoginPanel(): java.lang.NullPointerException ERROR: ConfigureCA: LoginPanel() failure ERROR: unable to create CA ### 2012-10-17T16:24:53Z DEBUG stderr=Exception: Unable to Send Request:java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391) at java.net.Socket.connect(Socket.java:579) at java.net.Socket.connect(Socket.java:528) at java.net.Socket.init(Socket.java:425) at java.net.Socket.init(Socket.java:241) at HTTPClient.sslConnect(HTTPClient.java:326) at ConfigureCA.LoginPanel(ConfigureCA.java:244) at ConfigureCA.ConfigureCAInstance(ConfigureCA.java:1157) at ConfigureCA.main(ConfigureCA.java:1672) java.lang.NullPointerException at ConfigureCA.LoginPanel(ConfigureCA.java:245) at ConfigureCA.ConfigureCAInstance(ConfigureCA.java:1157) at ConfigureCA.main(ConfigureCA.java:1672) Now I seem to be stuck. I tried uninstalling the freeipa-server package with # yum remove freeipa-server and then reinstalled it the same way, but ipa-server-install won't run no matter what I attempt. Any thoughts? I'm pretty new to IPA. Thanks! -- Bret Wortman The Damascus Group Fairfax, VA ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
On Wed, 2012-10-17 at 09:53 -0600, Rich Megginson wrote: On 10/17/2012 07:26 AM, Macklin, Jason wrote: Okay, Rule name: test4 Enabled: TRUE Command category: all Users: asteinfeld Hosts: dbduwdu062.dbr.roche.com Host Groups: tempsudo Client dbduwdu062 is matched in the rule by both the hosts and groups entry. /etc/nsswitch.conf has: Netgroups: files sss Getent netgroup tempsudo returns: [jmacklin@dbduwdu062 Desktop]$ getent netgroup tempsudo tempsudo (dbduwdu063.dbr.roche.com, -, dbr.roche.com) (dbduwdu062.dbr.roche.com, -, dbr.roche.com) To the previous ldapsearch request: [jmacklin@dbduwdu062 Desktop]$ ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com ou=SUDOers,dc=dbr,dc=roche,dc=com SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Server is unwilling to perform (53) additional info: Entry permanently locked. I am still scratching my head on this one... This means you cannot search using your kerberos ticket because the corresponding entry is locked. Try using directory manager: ldapsearch -x -D cn=directory manager -W -H ldap://dbduvdu145.dbr.roche.com ou=SUDOers,dc=dbr,dc=roche,dc=com This sounds very wrong. If the user had a kerberos ticket in the first place it meant it successfully authenticated. If no krb ticket was available GSSAPI would have not started at all. This look like some odd error in directory server failing to recognize valid users ? Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
On 10/17/2012 10:46 AM, Simo Sorce wrote:
On Wed, 2012-10-17 at 09:53 -0600, Rich Megginson wrote:
On 10/17/2012 07:26 AM, Macklin, Jason wrote:
Okay,
Rule name: test4
Enabled: TRUE
Command category: all
Users: asteinfeld
Hosts: dbduwdu062.dbr.roche.com
Host Groups: tempsudo
Client dbduwdu062 is matched in the rule by both the hosts and groups entry.
/etc/nsswitch.conf has:
Netgroups: files sss
Getent netgroup tempsudo returns:
[jmacklin@dbduwdu062 Desktop]$ getent netgroup tempsudo
tempsudo (dbduwdu063.dbr.roche.com, -, dbr.roche.com)
(dbduwdu062.dbr.roche.com, -, dbr.roche.com)
To the previous ldapsearch request:
[jmacklin@dbduwdu062 Desktop]$ ldapsearch -Y GSSAPI -H
ldap://dbduvdu145.dbr.roche.com ou=SUDOers,dc=dbr,dc=roche,dc=com
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Server is unwilling to perform (53)
additional info: Entry permanently locked.
I am still scratching my head on this one...
This means you cannot search using your kerberos ticket because the
corresponding entry is locked. Try using directory manager:
ldapsearch -x -D cn=directory manager -W -H
ldap://dbduvdu145.dbr.roche.com ou=SUDOers,dc=dbr,dc=roche,dc=com
This sounds very wrong.
If the user had a kerberos ticket in the first place it meant it
successfully authenticated.
If no krb ticket was available GSSAPI would have not started at all.
This look like some odd error in directory server failing to recognize
valid users ?
Not sure what's going on. Looking at the code in ipa_lockout.c:
lockout_duration = slapi_entry_attr_get_uint(policy_entry,
krbPwdLockoutDuration);
if (lockout_duration == 0) {
errstr = Entry permanently locked.\n;
ret = LDAP_UNWILLING_TO_PERFORM;
goto done;
}
This means either krbPwdLockoutDuration does not exist at all, or does
exist and has a value of 0.
Can you do an ldapsearch of your entry like this:
ldapsearch -xLLL -D cn=directory manager -W uid=youruserid \*
krbPwdLockoutDuration
?
Simo.
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
On 10/17/2012 12:33 PM, Macklin, Jason wrote:
ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com
ou=SUDOers,dc=dbr,dc=roche,dc=com
You are missing -b
ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com -b
ou=SUDOers,dc=dbr,dc=roche,dc=com
Currently the command treats it as filter and thus returns no results.
I am asking you to run this command to see what LDAP data the server
presents to the client.
Running this would not cure the problem but rather might give more hints
of what the actual problem is.
SASL/GSSAPI authentication started
SASL username: ad...@dbr.roche.com
SASL SSF: 56
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base (default) with scope subtree
# filter: ou=SUDOers,dc=dbr,dc=roche,dc=com
# requesting: ALL
#
# search result
search: 4
result: 32 No such object
# numResponses: 1
Different response, but still no success with the non-working account.
Cheers,
Jason
-Original Message-
From: Dmitri Pal [mailto:d...@redhat.com]
Sent: Wednesday, October 17, 2012 11:56 AM
To: Macklin, Jason {DASB~Branford}
Cc: jr.aqu...@citrix.com; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per
command or host level.
On 10/17/2012 09:26 AM, Macklin, Jason wrote:
Okay,
Rule name: test4
Enabled: TRUE
Command category: all
Users: asteinfeld
Hosts: dbduwdu062.dbr.roche.com
Host Groups: tempsudo
Client dbduwdu062 is matched in the rule by both the hosts and groups entry.
/etc/nsswitch.conf has:
Netgroups: files sss
Getent netgroup tempsudo returns:
[jmacklin@dbduwdu062 Desktop]$ getent netgroup tempsudo
tempsudo (dbduwdu063.dbr.roche.com, -, dbr.roche.com)
(dbduwdu062.dbr.roche.com, -, dbr.roche.com)
To the previous ldapsearch request:
[jmacklin@dbduwdu062 Desktop]$ ldapsearch -Y GSSAPI -H
ldap://dbduvdu145.dbr.roche.com ou=SUDOers,dc=dbr,dc=roche,dc=com
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Server is unwilling to perform (53)
additional info: Entry permanently locked.
It seems that you tried the wrong password and the account is now temporarily
locked thus the server is unwilling to perform authentication for this
account.
I am still scratching my head on this one...
Cheers,
Jason
If you look closely, the reason that your admin works is because it appears
to be matching a sudo rule who has the ALL hosts value set.
When you run the non working user, it is attempting to match the
hostname/hostgroup to the rule and fails to do so.
Try this. Type: getent netgroup hostgroupname - your host's hostgroup goes
there.
^ that command should return all of the hosts in your hostgroup. If it does
not, then check /etc/nsswitch.conf and make sure that netgroup is set to use
sss.
You will also need to make sure that the output of: domainname or
nisdomainname matches your expected domain.
Let me know how things look after trying that.
--
Thank you,
Dmitri Pal
Sr. Engineering Manager for IdM portfolio Red Hat Inc.
---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
--
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] Sudo works for full access, but not on a per command or host level.
On 10/17/2012 10:33 AM, Macklin, Jason wrote:
ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com
ou=SUDOers,dc=dbr,dc=roche,dc=com
SASL/GSSAPI authentication started
SASL username: ad...@dbr.roche.com
SASL SSF: 56
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base (default) with scope subtree
# filter: ou=SUDOers,dc=dbr,dc=roche,dc=com
# requesting: ALL
#
# search result
search: 4
result: 32 No such object
# numResponses: 1
Different response, but still no success with the non-working account.
Sorry - the ldapsearch command is wrong. Try this:
ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com -b
ou=SUDOers,dc=dbr,dc=roche,dc=com
Cheers,
Jason
-Original Message-
From: Dmitri Pal [mailto:d...@redhat.com]
Sent: Wednesday, October 17, 2012 11:56 AM
To: Macklin, Jason {DASB~Branford}
Cc: jr.aqu...@citrix.com; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per
command or host level.
On 10/17/2012 09:26 AM, Macklin, Jason wrote:
Okay,
Rule name: test4
Enabled: TRUE
Command category: all
Users: asteinfeld
Hosts: dbduwdu062.dbr.roche.com
Host Groups: tempsudo
Client dbduwdu062 is matched in the rule by both the hosts and groups entry.
/etc/nsswitch.conf has:
Netgroups: files sss
Getent netgroup tempsudo returns:
[jmacklin@dbduwdu062 Desktop]$ getent netgroup tempsudo
tempsudo (dbduwdu063.dbr.roche.com, -, dbr.roche.com)
(dbduwdu062.dbr.roche.com, -, dbr.roche.com)
To the previous ldapsearch request:
[jmacklin@dbduwdu062 Desktop]$ ldapsearch -Y GSSAPI -H
ldap://dbduvdu145.dbr.roche.com ou=SUDOers,dc=dbr,dc=roche,dc=com
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Server is unwilling to perform (53)
additional info: Entry permanently locked.
It seems that you tried the wrong password and the account is now temporarily
locked thus the server is unwilling to perform authentication for this account.
I am still scratching my head on this one...
Cheers,
Jason
If you look closely, the reason that your admin works is because it appears to be
matching a sudo rule who has the ALL hosts value set.
When you run the non working user, it is attempting to match the
hostname/hostgroup to the rule and fails to do so.
Try this. Type: getent netgroup hostgroupname- your host's hostgroup goes
there.
^ that command should return all of the hosts in your hostgroup. If it does
not, then check /etc/nsswitch.conf and make sure that netgroup is set to use
sss.
You will also need to make sure that the output of: domainname or nisdomainname
matches your expected domain.
Let me know how things look after trying that.
--
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] Sudo works for full access, but not on a per command or host level.
Thanks guys! Adding the -b did make a world of difference though it still doesn't make anything too obvious... at least to me. [jmacklin@dbduwdu062 Desktop]$ ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com -b ou=SUDOers,dc=dbr,dc=roche,dc=com SASL/GSSAPI authentication started SASL username: ad...@dbr.roche.com SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base ou=SUDOers,dc=dbr,dc=roche,dc=com with scope subtree # filter: (objectclass=*) # requesting: ALL # # sudoers, dbr.roche.com dn: ou=sudoers,dc=dbr,dc=roche,dc=com objectClass: extensibleObject ou: sudoers # test4, sudoers, dbr.roche.com dn: cn=test4,ou=sudoers,dc=dbr,dc=roche,dc=com objectClass: sudoRole sudoUser: asteinfeld sudoHost: dbduwdu062.dbr.roche.com sudoHost: +tempsudo sudoCommand: ALL cn: test4 # switch, sudoers, dbr.roche.com dn: cn=switch,ou=sudoers,dc=dbr,dc=roche,dc=com objectClass: sudoRole sudoUser: oyilmaz sudoHost: dbdusdu071.dbr.roche.com sudoCommand: /bin/su cn: switch # jing144, sudoers, dbr.roche.com dn: cn=jing144,ou=sudoers,dc=dbr,dc=roche,dc=com objectClass: sudoRole sudoUser: jli sudoHost: dbduvdu144.dbr.roche.com sudoCommand: ALL cn: jing144 # Admin, sudoers, dbr.roche.com dn: cn=Admin,ou=sudoers,dc=dbr,dc=roche,dc=com objectClass: sudoRole sudoUser: jmacklin sudoUser: mrini sudoUser: cgajare sudoUser: parnold sudoUser: hhebert sudoUser: ckuecherer sudoUser: gferreri sudoHost: ALL sudoCommand: ALL cn: Admin # search result search: 4 result: 0 Success # numResponses: 6 # numEntries: 5 I really appreciate all of the help! Cheers, Jason ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
None of my users have an LDAP password being requested by running that command (except the admin user). Does each user account require an ldap account to go along with their login account? I just get the following over and over no matter which account I switch in the command... [jmacklin@dbduwdu062 Desktop]$ ldapsearch -xLLL -D cn=directory manager -W uid=admin \* krbPwdLockoutDuration ? Enter LDAP Password: ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) [jmacklin@dbduwdu062 Desktop]$ ldapsearch -xLLL -D cn=directory manager -W uid=asteinfeld \* krbPwdLockoutDuration ? Enter LDAP Password: ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) [jmacklin@dbduwdu062 Desktop]$ ldapsearch -xLLL -D cn=directory manager -W uid=jmacklin \* krbPwdLockoutDuration ? Enter LDAP Password: ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
On 10/17/2012 11:13 AM, Macklin, Jason wrote: None of my users have an LDAP password being requested by running that command (except the admin user). Does each user account require an ldap account to go along with their login account? I just get the following over and over no matter which account I switch in the command... [jmacklin@dbduwdu062 Desktop]$ ldapsearch -xLLL -D cn=directory manager -W uid=admin \* krbPwdLockoutDuration ? Enter LDAP Password: ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) [jmacklin@dbduwdu062 Desktop]$ ldapsearch -xLLL -D cn=directory manager -W uid=asteinfeld \* krbPwdLockoutDuration ? Enter LDAP Password: ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) [jmacklin@dbduwdu062 Desktop]$ ldapsearch -xLLL -D cn=directory manager -W uid=jmacklin \* krbPwdLockoutDuration ? Enter LDAP Password: ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) You have to specify which server to talk to using the -H ldap://fqdn.of.host option. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D cn=directory manager
-W uid=asteinfeld \* krbPwdLockoutDuration ?
Enter LDAP Password:
ldap_bind: Invalid credentials (49)
I know this user password because I reset it for the purpose of troubleshooting
this issue with that account. I also get the same response when I use the admin
account of my own account.
-Original Message-
From: Rich Megginson [mailto:rmegg...@redhat.com]
Sent: Wednesday, October 17, 2012 1:15 PM
To: Macklin, Jason {DASB~Branford}
Cc: s...@redhat.com; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per
command or host level.
On 10/17/2012 11:13 AM, Macklin, Jason wrote:
None of my users have an LDAP password being requested by running that
command (except the admin user).
Does each user account require an ldap account to go along with their login
account? I just get the following over and over no matter which account I
switch in the command...
[jmacklin@dbduwdu062 Desktop]$ ldapsearch -xLLL -D cn=directory manager -W
uid=admin \* krbPwdLockoutDuration ?
Enter LDAP Password:
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
[jmacklin@dbduwdu062 Desktop]$ ldapsearch -xLLL -D cn=directory manager -W
uid=asteinfeld \* krbPwdLockoutDuration ?
Enter LDAP Password:
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
[jmacklin@dbduwdu062 Desktop]$ ldapsearch -xLLL -D cn=directory manager -W
uid=jmacklin \* krbPwdLockoutDuration ?
Enter LDAP Password:
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
You have to specify which server to talk to using the -H ldap://fqdn.of.host
option.
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] RHEL5 IPA client for RHEL6.3 IPA server?
David Summers wrote: On 10/17/2012 7:49 AM, Rob Crittenden wrote: David Summers wrote: I have looked back through the last year of mail archives for this list and haven't yet found anything on this. I spent a day or so trying to get a RHEL6.3 server set up with several clients, Clients: RHEL 6.3 32-bit RHEL 6.3 64-bit RHEL 5.8 32-bit RHEL 5.8 64-bit So far I've been able to get the RHEL 6.3 clients to register and setup up as a client for RHEL 6.3 IPA server but whenever I try to install the ipa-client on RHEL 5.8 I just get the following error: [root@rh5 ~]# ipa-client-install Discovery was successful! Hostname: rh5.summersoft Realm: SUMMERSOFT DNS Domain: summersoft IPA Server: ipaserver.summersoft BaseDN: dc=summersoft Continue to configure the system with these values? [no]: yes User authorized to enroll computers: admin Synchronizing time with KDC... Unable to sync time with IPA NTP server, assuming the time is in sync. Password for admin@SUMMERSOFT: Joining realm failed: SASL Bind failed Local error (-2) ! child exited with 9 Installation failed. Rolling back changes. IPA client is not configured on this system. In the install log: 2012-10-16 23:16:34,410 DEBUG stderr= 2012-10-16 23:16:35,032 DEBUG args=/usr/sbin/ipa-join -s ipaserver.summersoft -b dc=summersoft 2012-10-16 23:16:35,032 DEBUG stdout= 2012-10-16 23:16:35,032 DEBUG stderr=SASL Bind failed Local error (-2) ! child exited with 9 Is RHEL 5.8 a supported client for RHEL 6.3 IPA server? If so, what am I doing wrong? I tried following both the RHEL 5.8 and RHEL 6.3 install instructions but nothing I have tried is working so far! Thanks in advance for any help or pointers you can provide. - David Summers What is the version of the 5.8 ipa-client package? You want ipa-client-2.1.3-2.el5_8 rob Yes, I have ipa-client-2.1.3-2.el5_8 but I have not been able to get it to join the IPA server. I've turned off all firewalls. I am running IPv6, does that make a difference? Any ideas? - Thanks - David Summers It is failing trying to get a keytab for the newly enrolled host. Can you provide /var/log/ipaclient-install.log? Can you look in the 389-ds error and access logs for the BIND request and/or other errors when the client enrollment happens (/var/log/dirsrv/slapd-REALM, access buffers for 30 seconds) and the KDC logs in /var/log/krb5kdc? rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] RHEL5 IPA client for RHEL6.3 IPA server?
On 10/17/2012 7:49 AM, Rob Crittenden wrote: David Summers wrote: I have looked back through the last year of mail archives for this list and haven't yet found anything on this. I spent a day or so trying to get a RHEL6.3 server set up with several clients, Clients: RHEL 6.3 32-bit RHEL 6.3 64-bit RHEL 5.8 32-bit RHEL 5.8 64-bit So far I've been able to get the RHEL 6.3 clients to register and setup up as a client for RHEL 6.3 IPA server but whenever I try to install the ipa-client on RHEL 5.8 I just get the following error: [root@rh5 ~]# ipa-client-install Discovery was successful! Hostname: rh5.summersoft Realm: SUMMERSOFT DNS Domain: summersoft IPA Server: ipaserver.summersoft BaseDN: dc=summersoft Continue to configure the system with these values? [no]: yes User authorized to enroll computers: admin Synchronizing time with KDC... Unable to sync time with IPA NTP server, assuming the time is in sync. Password for admin@SUMMERSOFT: Joining realm failed: SASL Bind failed Local error (-2) ! child exited with 9 Installation failed. Rolling back changes. IPA client is not configured on this system. In the install log: 2012-10-16 23:16:34,410 DEBUG stderr= 2012-10-16 23:16:35,032 DEBUG args=/usr/sbin/ipa-join -s ipaserver.summersoft -b dc=summersoft 2012-10-16 23:16:35,032 DEBUG stdout= 2012-10-16 23:16:35,032 DEBUG stderr=SASL Bind failed Local error (-2) ! child exited with 9 Is RHEL 5.8 a supported client for RHEL 6.3 IPA server? If so, what am I doing wrong? I tried following both the RHEL 5.8 and RHEL 6.3 install instructions but nothing I have tried is working so far! Thanks in advance for any help or pointers you can provide. - David Summers What is the version of the 5.8 ipa-client package? You want ipa-client-2.1.3-2.el5_8 rob Yes, I have ipa-client-2.1.3-2.el5_8 but I have not been able to get it to join the IPA server. I've turned off all firewalls. I am running IPv6, does that make a difference? Any ideas? - Thanks - David Summers ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
Macklin, Jason wrote:
ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D cn=directory manager
-W uid=asteinfeld \* krbPwdLockoutDuration ?
Enter LDAP Password:
ldap_bind: Invalid credentials (49)
I know this user password because I reset it for the purpose of troubleshooting
this issue with that account. I also get the same response when I use the admin
account of my own account.
You use the password of the user you are binding as, in this case the
directory manager.
rob
-Original Message-
From: Rich Megginson [mailto:rmegg...@redhat.com]
Sent: Wednesday, October 17, 2012 1:15 PM
To: Macklin, Jason {DASB~Branford}
Cc: s...@redhat.com; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per
command or host level.
On 10/17/2012 11:13 AM, Macklin, Jason wrote:
None of my users have an LDAP password being requested by running that command
(except the admin user).
Does each user account require an ldap account to go along with their login
account? I just get the following over and over no matter which account I
switch in the command...
[jmacklin@dbduwdu062 Desktop]$ ldapsearch -xLLL -D cn=directory manager -W
uid=admin \* krbPwdLockoutDuration ?
Enter LDAP Password:
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
[jmacklin@dbduwdu062 Desktop]$ ldapsearch -xLLL -D cn=directory manager -W
uid=asteinfeld \* krbPwdLockoutDuration ?
Enter LDAP Password:
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
[jmacklin@dbduwdu062 Desktop]$ ldapsearch -xLLL -D cn=directory manager -W
uid=jmacklin \* krbPwdLockoutDuration ?
Enter LDAP Password:
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
You have to specify which server to talk to using the -H ldap://fqdn.of.host
option.
___
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] Failed installation
On 10/17/2012 12:40 PM, Bret Wortman wrote: I recently tried installing freeipa on a new server, but ipa-server-install had problems around this point: Configuring certificate server: Estimated time 3 minutes 30 seconds [1/18]: creating certificate server user [2/18]: creating pki-ca instance [3/18]: configuring certificate server instance ipa : CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname fs1.wedgeofli.me http://fs1.wedgeofli.me -cs_port 9445 -client_certdb_dir /tmp/tmp-UvBMbL -client_certdb_pwd -preop_pin HHxKHUz5RRfzQ3OkFMlR -domain_name IPA -admin_user admin -admin_email root@localhost -admin_ -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject CN=ipa-ca-agent,O=WEDGEOFLI.ME http://WEDGEOFLI.ME -ldap_host fs1.wedgeofli.me http://fs1.wedgeofli.me -ldap_port 7389 -bind_dn cn=Directory Manager -bind_ -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12 true -backup_pwd -subsystem_name pki-cad -token_name internal -ca_subsystem_cert_subject_name CN=CA Subsystem,O=WEDGEOFLI.ME http://WEDGEOFLI.ME -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=WEDGEOFLI.ME http://WEDGEOFLI.ME -ca_server_cert_subject_name CN=fs1.wedgeofli.me http://fs1.wedgeofli.me,O=WEDGEOFLI.ME http://WEDGEOFLI.ME -ca_audit_signing_cert_subject_name CN=CA Audit,O=WEDGEOFLI.ME http://WEDGEOFLI.ME -ca_sign_cert_subject_name CN=Certificate Authority,O=WEDGEOFLI.ME http://WEDGEOFLI.ME -external false -clone false' returned non-zero exit status 255 Unexpected error - see ipaserver-install.log for details: Configuration of CA failed [root@fs1 ~]# The logfile revealed the following stack trace: # Attempting to connect to: fs1.wedgeofli.me:9445 http://fs1.wedgeofli.me:9445 Exception in LoginPanel(): java.lang.NullPointerException ERROR: ConfigureCA: LoginPanel() failure ERROR: unable to create CA ### 2012-10-17T16:24:53Z DEBUG stderr=Exception: Unable to Send Request:java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391) at java.net.Socket.connect(Socket.java:579) at java.net.Socket.connect(Socket.java:528) at java.net.Socket.init(Socket.java:425) at java.net.Socket.init(Socket.java:241) at HTTPClient.sslConnect(HTTPClient.java:326) at ConfigureCA.LoginPanel(ConfigureCA.java:244) at ConfigureCA.ConfigureCAInstance(ConfigureCA.java:1157) at ConfigureCA.main(ConfigureCA.java:1672) java.lang.NullPointerException at ConfigureCA.LoginPanel(ConfigureCA.java:245) at ConfigureCA.ConfigureCAInstance(ConfigureCA.java:1157) at ConfigureCA.main(ConfigureCA.java:1672) Now I seem to be stuck. I tried uninstalling the freeipa-server package with # yum remove freeipa-server and then reinstalled it the same way, but ipa-server-install won't run no matter what I attempt. Any thoughts? I'm pretty new to IPA. Make sure you have packages installed Run the uninstall command several times (5 for example) ipa-server-install --uninstall -U In case of failed installation and other steps you made the installtion might be in the corrupted state. Running severl times might help as it might detect and remove/unconfigure different things at different moments. Before trying to reinstall again make sure you have latest SELinux policies. If it explodes again let us know. Thanks! -- Bret Wortman The Damascus Group Fairfax, VA ___ 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] Failed installation
On 10/17/2012 12:40 PM, Bret Wortman wrote: I recently tried installing freeipa on a new server, but ipa-server-install had problems around this point: Configuring certificate server: Estimated time 3 minutes 30 seconds [1/18]: creating certificate server user [2/18]: creating pki-ca instance [3/18]: configuring certificate server instance ipa : CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname fs1.wedgeofli.me http://fs1.wedgeofli.me -cs_port 9445 -client_certdb_dir /tmp/tmp-UvBMbL -client_certdb_pwd -preop_pin HHxKHUz5RRfzQ3OkFMlR -domain_name IPA -admin_user admin -admin_email root@localhost -admin_ -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject CN=ipa-ca-agent,O=WEDGEOFLI.ME http://WEDGEOFLI.ME -ldap_host fs1.wedgeofli.me http://fs1.wedgeofli.me -ldap_port 7389 -bind_dn cn=Directory Manager -bind_ -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12 true -backup_pwd -subsystem_name pki-cad -token_name internal -ca_subsystem_cert_subject_name CN=CA Subsystem,O=WEDGEOFLI.ME http://WEDGEOFLI.ME -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=WEDGEOFLI.ME http://WEDGEOFLI.ME -ca_server_cert_subject_name CN=fs1.wedgeofli.me http://fs1.wedgeofli.me,O=WEDGEOFLI.ME http://WEDGEOFLI.ME -ca_audit_signing_cert_subject_name CN=CA Audit,O=WEDGEOFLI.ME http://WEDGEOFLI.ME -ca_sign_cert_subject_name CN=Certificate Authority,O=WEDGEOFLI.ME http://WEDGEOFLI.ME -external false -clone false' returned non-zero exit status 255 Unexpected error - see ipaserver-install.log for details: Configuration of CA failed [root@fs1 ~]# The logfile revealed the following stack trace: # Attempting to connect to: fs1.wedgeofli.me:9445 http://fs1.wedgeofli.me:9445 Exception in LoginPanel(): java.lang.NullPointerException ERROR: ConfigureCA: LoginPanel() failure ERROR: unable to create CA ### 2012-10-17T16:24:53Z DEBUG stderr=Exception: Unable to Send Request:java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391) at java.net.Socket.connect(Socket.java:579) at java.net.Socket.connect(Socket.java:528) at java.net.Socket.init(Socket.java:425) at java.net.Socket.init(Socket.java:241) at HTTPClient.sslConnect(HTTPClient.java:326) at ConfigureCA.LoginPanel(ConfigureCA.java:244) at ConfigureCA.ConfigureCAInstance(ConfigureCA.java:1157) at ConfigureCA.main(ConfigureCA.java:1672) java.lang.NullPointerException at ConfigureCA.LoginPanel(ConfigureCA.java:245) at ConfigureCA.ConfigureCAInstance(ConfigureCA.java:1157) at ConfigureCA.main(ConfigureCA.java:1672) Now I seem to be stuck. I tried uninstalling the freeipa-server package with # yum remove freeipa-server and then reinstalled it the same way, but ipa-server-install won't run no matter what I attempt. Any thoughts? I'm pretty new to IPA. There is a good chance this is due to a version mismatch between the IPA packages and the dogtag packages. You didn't mention which OS you're using nor the versions of the relevant packages, that would have been helpful. In any event I would make sure all your packages are up to date. -- 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] Sudo works for full access, but not on a per command or host level.
I assume that this iteration was with the correct credentials as it responds
with something other then Invalid Credentials
ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D cn=directory manager
-W uid=asteinfeld \* krbPwdLockoutDuration ?
Enter LDAP Password:
No such object (32)
Working account returns same thing...
ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D cn=directory manager
-W uid=jmacklin \* krbPwdLockoutDuration ?
Enter LDAP Password:
No such object (32)
-Original Message-
From: Rob Crittenden [mailto:rcrit...@redhat.com]
Sent: Wednesday, October 17, 2012 1:37 PM
To: Macklin, Jason {DASB~Branford}
Cc: rmegg...@redhat.com; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per
command or host level.
Macklin, Jason wrote:
ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D cn=directory manager
-W uid=asteinfeld \* krbPwdLockoutDuration ?
Enter LDAP Password:
ldap_bind: Invalid credentials (49)
I know this user password because I reset it for the purpose of
troubleshooting this issue with that account. I also get the same response
when I use the admin account of my own account.
You use the password of the user you are binding as, in this case the directory
manager.
rob
-Original Message-
From: Rich Megginson [mailto:rmegg...@redhat.com]
Sent: Wednesday, October 17, 2012 1:15 PM
To: Macklin, Jason {DASB~Branford}
Cc: s...@redhat.com; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per
command or host level.
On 10/17/2012 11:13 AM, Macklin, Jason wrote:
None of my users have an LDAP password being requested by running that
command (except the admin user).
Does each user account require an ldap account to go along with their login
account? I just get the following over and over no matter which account I
switch in the command...
[jmacklin@dbduwdu062 Desktop]$ ldapsearch -xLLL -D cn=directory manager -W
uid=admin \* krbPwdLockoutDuration ?
Enter LDAP Password:
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
[jmacklin@dbduwdu062 Desktop]$ ldapsearch -xLLL -D cn=directory manager -W
uid=asteinfeld \* krbPwdLockoutDuration ?
Enter LDAP Password:
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
[jmacklin@dbduwdu062 Desktop]$ ldapsearch -xLLL -D cn=directory manager -W
uid=jmacklin \* krbPwdLockoutDuration ?
Enter LDAP Password:
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
You have to specify which server to talk to using the -H ldap://fqdn.of.host
option.
___
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] Sudo works for full access, but not on a per command or host level.
On 10/17/2012 11:51 AM, Macklin, Jason wrote:
I assume that this iteration was with the correct credentials as it responds with
something other then Invalid Credentials
ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D cn=directory manager
-W uid=asteinfeld \* krbPwdLockoutDuration ?
Enter LDAP Password:
No such object (32)
Working account returns same thing...
ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D cn=directory manager
-W uid=jmacklin \* krbPwdLockoutDuration ?
Enter LDAP Password:
No such object (32)
Sorry, I though ipa would have configured your /etc/openldap/ldap.conf
with your base dn. Try this:
ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D cn=directory
manager -W -b dc=dbr,dc=roche,dc=com uid=jmacklin \*
-Original Message-
From: Rob Crittenden [mailto:rcrit...@redhat.com]
Sent: Wednesday, October 17, 2012 1:37 PM
To: Macklin, Jason {DASB~Branford}
Cc: rmegg...@redhat.com; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per
command or host level.
Macklin, Jason wrote:
ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D cn=directory manager
-W uid=asteinfeld \* krbPwdLockoutDuration ?
Enter LDAP Password:
ldap_bind: Invalid credentials (49)
I know this user password because I reset it for the purpose of troubleshooting
this issue with that account. I also get the same response when I use the admin
account of my own account.
You use the password of the user you are binding as, in this case the directory
manager.
rob
-Original Message-
From: Rich Megginson [mailto:rmegg...@redhat.com]
Sent: Wednesday, October 17, 2012 1:15 PM
To: Macklin, Jason {DASB~Branford}
Cc: s...@redhat.com; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per
command or host level.
On 10/17/2012 11:13 AM, Macklin, Jason wrote:
None of my users have an LDAP password being requested by running that command
(except the admin user).
Does each user account require an ldap account to go along with their login
account? I just get the following over and over no matter which account I
switch in the command...
[jmacklin@dbduwdu062 Desktop]$ ldapsearch -xLLL -D cn=directory manager -W
uid=admin \* krbPwdLockoutDuration ?
Enter LDAP Password:
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
[jmacklin@dbduwdu062 Desktop]$ ldapsearch -xLLL -D cn=directory manager -W
uid=asteinfeld \* krbPwdLockoutDuration ?
Enter LDAP Password:
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
[jmacklin@dbduwdu062 Desktop]$ ldapsearch -xLLL -D cn=directory manager -W
uid=jmacklin \* krbPwdLockoutDuration ?
Enter LDAP Password:
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
You have to specify which server to talk to using the -H ldap://fqdn.of.host
option.
___
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] Failed installation
Now it appears that whatever is supposed to be running on port 9445 (looks like mindarray-ca) isn't running, and I'm not sure how it gets started, exactly. I ran lsof -i:9445 on this server and on a FreeIPA test box I first set up, and it's running on the test box but not the new one. Where should I look next? On Wed, Oct 17, 2012 at 2:07 PM, Bret Wortman bret.wort...@damascusgrp.comwrote: Spot on. It was a fresh install of F17 and I neglected to # yum update first. I've done so, rebooted, and am trying again with better results. On Wed, Oct 17, 2012 at 1:45 PM, John Dennis jden...@redhat.com wrote: On 10/17/2012 12:40 PM, Bret Wortman wrote: I recently tried installing freeipa on a new server, but ipa-server-install had problems around this point: Configuring certificate server: Estimated time 3 minutes 30 seconds [1/18]: creating certificate server user [2/18]: creating pki-ca instance [3/18]: configuring certificate server instance ipa : CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname fs1.wedgeofli.me http://fs1.wedgeofli.me -cs_port 9445 -client_certdb_dir /tmp/tmp-UvBMbL -client_certdb_pwd -preop_pin HHxKHUz5RRfzQ3OkFMlR -domain_name IPA -admin_user admin -admin_email root@localhost -admin_ -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject CN=ipa-ca-agent,O=WEDGEOFLI.ME http://WEDGEOFLI.ME -ldap_host fs1.wedgeofli.me http://fs1.wedgeofli.me -ldap_port 7389 -bind_dn cn=Directory Manager -bind_ -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12 true -backup_pwd -subsystem_name pki-cad -token_name internal -ca_subsystem_cert_subject_**name CN=CA Subsystem,O= WEDGEOFLI.ME http://WEDGEOFLI.ME -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=WEDGEOFLI.ME http://WEDGEOFLI.ME -ca_server_cert_subject_name CN=fs1.wedgeofli.me http://fs1.wedgeofli.me,O=WE**DGEOFLI.ME http://WEDGEOFLI.ME http://WEDGEOFLI.ME -ca_audit_signing_cert_**subject_name CN=CA Audit,O=WEDGEOFLI.ME http://WEDGEOFLI.ME -ca_sign_cert_subject_name CN=Certificate Authority,O=WEDGEOFLI.ME http://WEDGEOFLI.ME -external false -clone false' returned non-zero exit status 255 Unexpected error - see ipaserver-install.log for details: Configuration of CA failed [root@fs1 ~]# The logfile revealed the following stack trace: ##**### Attempting to connect to: fs1.wedgeofli.me:9445 http://fs1.wedgeofli.me:9445 Exception in LoginPanel(): java.lang.NullPointerException ERROR: ConfigureCA: LoginPanel() failure ERROR: unable to create CA ##**##** ### 2012-10-17T16:24:53Z DEBUG stderr=Exception: Unable to Send Request:java.net.**ConnectException: Connection refused java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.**socketConnect(Native Method) at java.net.**AbstractPlainSocketImpl.**doConnect(** AbstractPlainSocketImpl.java:**339) at java.net.**AbstractPlainSocketImpl.**connectToAddress(** AbstractPlainSocketImpl.java:**200) at java.net.**AbstractPlainSocketImpl.**connect(** AbstractPlainSocketImpl.java:**182) at java.net.SocksSocketImpl.**connect(SocksSocketImpl.java:**391) at java.net.Socket.connect(**Socket.java:579) at java.net.Socket.connect(**Socket.java:528) at java.net.Socket.init(Socket.**java:425) at java.net.Socket.init(Socket.**java:241) at HTTPClient.sslConnect(**HTTPClient.java:326) at ConfigureCA.LoginPanel(**ConfigureCA.java:244) at ConfigureCA.**ConfigureCAInstance(**ConfigureCA.java:1157) at ConfigureCA.main(ConfigureCA.**java:1672) java.lang.NullPointerException at ConfigureCA.LoginPanel(**ConfigureCA.java:245) at ConfigureCA.**ConfigureCAInstance(**ConfigureCA.java:1157) at ConfigureCA.main(ConfigureCA.**java:1672) Now I seem to be stuck. I tried uninstalling the freeipa-server package with # yum remove freeipa-server and then reinstalled it the same way, but ipa-server-install won't run no matter what I attempt. Any thoughts? I'm pretty new to IPA. There is a good chance this is due to a version mismatch between the IPA packages and the dogtag packages. You didn't mention which OS you're using nor the versions of the relevant packages, that would have been helpful. In any event I would make sure all your packages are up to date. -- John Dennis jden...@redhat.com Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -- Bret Wortman The Damascus Group Fairfax, VA http://bretwortman.com/ http://twitter.com/BretWortman -- Bret Wortman The Damascus Group Fairfax, VA http://bretwortman.com/ http://twitter.com/BretWortman ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Failed installation
On 10/17/2012 02:31 PM, Bret Wortman wrote: Now it appears that whatever is supposed to be running on port 9445 (looks like mindarray-ca) isn't running, and I'm not sure how it gets started, exactly. I ran lsof -i:9445 on this server and on a FreeIPA test box I first set up, and it's running on the test box but not the new one. Where should I look next? You cert system component failed to start because its DS instance failed to start. Did the install fail again after cleanup? If not it is better to start over with cleanup and if the install fails we will help you to troubleshoot. On Wed, Oct 17, 2012 at 2:07 PM, Bret Wortman bret.wort...@damascusgrp.com mailto:bret.wort...@damascusgrp.com wrote: Spot on. It was a fresh install of F17 and I neglected to # yum update first. I've done so, rebooted, and am trying again with better results. On Wed, Oct 17, 2012 at 1:45 PM, John Dennis jden...@redhat.com mailto:jden...@redhat.com wrote: On 10/17/2012 12:40 PM, Bret Wortman wrote: I recently tried installing freeipa on a new server, but ipa-server-install had problems around this point: Configuring certificate server: Estimated time 3 minutes 30 seconds [1/18]: creating certificate server user [2/18]: creating pki-ca instance [3/18]: configuring certificate server instance ipa : CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname fs1.wedgeofli.me http://fs1.wedgeofli.me http://fs1.wedgeofli.me -cs_port 9445 -client_certdb_dir /tmp/tmp-UvBMbL -client_certdb_pwd -preop_pin HHxKHUz5RRfzQ3OkFMlR -domain_name IPA -admin_user admin -admin_email root@localhost -admin_ -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject CN=ipa-ca-agent,O=WEDGEOFLI.ME http://WEDGEOFLI.ME http://WEDGEOFLI.ME -ldap_host fs1.wedgeofli.me http://fs1.wedgeofli.me http://fs1.wedgeofli.me -ldap_port 7389 -bind_dn cn=Directory Manager -bind_ -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12 true -backup_pwd -subsystem_name pki-cad -token_name internal -ca_subsystem_cert_subject_name CN=CA Subsystem,O=WEDGEOFLI.ME http://WEDGEOFLI.ME http://WEDGEOFLI.ME -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=WEDGEOFLI.ME http://WEDGEOFLI.ME http://WEDGEOFLI.ME -ca_server_cert_subject_name CN=fs1.wedgeofli.me http://fs1.wedgeofli.me http://fs1.wedgeofli.me,O=WEDGEOFLI.ME http://WEDGEOFLI.ME http://WEDGEOFLI.ME -ca_audit_signing_cert_subject_name CN=CA Audit,O=WEDGEOFLI.ME http://WEDGEOFLI.ME http://WEDGEOFLI.ME -ca_sign_cert_subject_name CN=Certificate Authority,O=WEDGEOFLI.ME http://WEDGEOFLI.ME http://WEDGEOFLI.ME -external false -clone false' returned non-zero exit status 255 Unexpected error - see ipaserver-install.log for details: Configuration of CA failed [root@fs1 ~]# The logfile revealed the following stack trace: # Attempting to connect to: fs1.wedgeofli.me:9445 http://fs1.wedgeofli.me:9445 http://fs1.wedgeofli.me:9445 Exception in LoginPanel(): java.lang.NullPointerException ERROR: ConfigureCA: LoginPanel() failure ERROR: unable to create CA ### 2012-10-17T16:24:53Z DEBUG stderr=Exception: Unable to Send Request:java.net http://java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net http://java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) at java.net http://java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) at java.net http://java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391) at java.net.Socket.connect(Socket.java:579) at java.net.Socket.connect(Socket.java:528) at
Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D cn=directory manager -W -b dc=dbr,dc=roche,dc=com uid=asteinfeld \* Enter LDAP Password: dn: uid=asteinfeld,cn=users,cn=compat,dc=dbr,dc=roche,dc=com objectClass: posixAccount objectClass: top gecos: Axel Steinfeld cn: Axel Steinfeld uidNumber: 2011 gidNumber: 2011 loginShell: /bin/bash homeDirectory: /home2/asteinfeld uid: asteinfeld dn: uid=asteinfeld,cn=users,cn=accounts,dc=dbr,dc=roche,dc=com displayName: Axel Steinfeld cn: Axel Steinfeld objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixaccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: mepOriginEntry loginShell: /bin/bash sn: Steinfeld uidNumber: 2011 gidNumber: 2011 gecos: Axel Steinfeld homeDirectory: /home2/asteinfeld krbPwdPolicyReference: cn=global_policy,cn=DBR.ROCHE.COM,cn=kerberos,dc=dbr,dc =roche,dc=com krbPrincipalName: asteinf...@dbr.roche.com givenName: Axel uid: asteinfeld initials: AS userPassword:: e1NTSEF9OGpRZ09pazNWbGV0QlRTdm9DSjQ5b0VwaDhIQzZ5aHJ6Z2Foanc9PQ= = ipaUniqueID: e582ea10-9e89-11e1-a7db-005056bb0010 krbPrincipalKey:: MIIC7qADAgEBoQMCAQGiAwIBA6MDAgEBpIIC1jCCAtIwb6AiMCCgAwIBAKEZ BBdEQlIuUk9DSEUuQ09NYXN0ZWluZmVsZKFJMEegAwIBEqFABD4gAKO2YZ6bzFkcvDQUQR1R0AEFO o+oNDP7NlR75fVLZ0932O8fxrDnbKL90Ti3N6AQJpaZzvUrDozy70LSbjBfoCIwIKADAgEAoRkEF0 RCUi5ST0NIRS5DT01hc3RlaW5mZWxkoTkwN6ADAgERoTAELhAAIROPMbj/O/5yV9gynI1rc2CtckV mu7PczKYvb0O/Wk8D8QwBQyFSryrwMQAwZ6AiMCCgAwIBAKEZBBdEQlIuUk9DSEUuQ09NYXN0ZWlu ZmVsZKFBMD+gAwIBEKE4BDYYANU+Z6tmBZfUx5d7gf6NazwtXIlJsxZQZ8ntFigMGQxTjk4W/hDiz ECD0a6hskJuhmi8OjAwX6AiMCCgAwIBAKEZBBdEQlIuUk9DSEUuQ09NYXN0ZWluZmVsZKE5MDegAw IBF6EwBC4QADS3VnBvucc3YHvX0sL9YiASCYV7Iq5UV2seIw4bYlWt0b5RpLR5/fpbPyA5MFegIjA goAMCAQChGQQXREJSLlJPQ0hFLkNPTWFzdGVpbmZlbGShMTAvoAMCAQihKAQmCADwSRXiuHorXYmh UNvxq+HX/4j/dVSqr5vJ02anMGlZZnduCZcwV6AiMCCgAwIBAKEZBBdEQlIuUk9DSEUuQ09NYXN0Z WluZmVsZKExMC+gAwIBA6EoBCYIANEhS6vyfY9cpethqr64UZcf4XWMQFPYmvkrU6+qlWCnCqfKiD AzoTEwL6ADAgEBoSgEJggA6TGpzIElqIiEN+bgeZYSUJm5G/o3nORRyg1oAp8C1H35cyyVME2gGDA WoAMCAQWhDwQNREJSLlJPQ0hFLkNPTaExMC+gAwIBAaEoBCYIACSVJDR+FFTCMrmWMcwwT4F47jxL LaAac0/gncsxU5+VR+jgfg== krbPasswordExpiration: 20130324201805Z krbLastPwdChange: 20120925201805Z krbExtraData:: AAJ9EWJQa2FkbWluZEBEQlIuUk9DSEUuQ09NAA== mepManagedEntry: cn=asteinfeld,cn=groups,cn=accounts,dc=dbr,dc=roche,dc=com memberOf: cn=dbr,cn=groups,cn=accounts,dc=dbr,dc=roche,dc=com memberOf: ipaUniqueID=be53ab18-0820-11e2-9b0a-005056bb0010,cn=sudorules,cn=sud o,dc=dbr,dc=roche,dc=com memberOf: cn=tempsudo,cn=groups,cn=accounts,dc=dbr,dc=roche,dc=com memberOf: ipaUniqueID=00544f1a-17a6-11e2-8dde-005056bb0010,cn=sudorules,cn=sud o,dc=dbr,dc=roche,dc=com memberOf: ipaUniqueID=9a7ec120-185e-11e2-891c-005056bb0010,cn=hbac,dc=dbr,dc=r oche,dc=com krbLoginFailedCount: 0 krbLastSuccessfulAuth: 20121017184614Z krbTicketFlags: 128 krbLastFailedAuth: 20121015143818Z [jmacklin@dbduwdu062 Desktop]$ ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D cn=directory manager -W -b dc=dbr,dc=roche,dc=com uid=jmacklin \*Enter LDAP Password: dn: uid=jmacklin,cn=users,cn=compat,dc=dbr,dc=roche,dc=com objectClass: posixAccount objectClass: top gecos: Jason Macklin cn: Jason Macklin uidNumber: 2084 gidNumber: 2084 loginShell: /bin/bash homeDirectory: /home2/jmacklin uid: jmacklin dn: uid=jmacklin,cn=users,cn=accounts,dc=dbr,dc=roche,dc=com displayName: Jason Macklin cn: Jason Macklin objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixaccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: mepOriginEntry loginShell: /bin/bash sn: Macklin gecos: Jason Macklin homeDirectory: /home2/jmacklin krbPwdPolicyReference: cn=global_policy,cn=DBR.ROCHE.COM,cn=kerberos,dc=dbr,dc =roche,dc=com krbPrincipalName: jmack...@dbr.roche.com givenName: Jason uid: jmacklin initials: JM uidNumber: 2084 gidNumber: 2084 ipaUniqueID: 045652b4-8e3c-11e1-831f-005056bb0010 mepManagedEntry: cn=jmacklin,cn=groups,cn=accounts,dc=dbr,dc=roche,dc=com memberOf: cn=admins,cn=groups,cn=accounts,dc=dbr,dc=roche,dc=com memberOf: cn=Replication Administrators,cn=privileges,cn=pbac,dc=dbr,dc=roche, dc=com memberOf: cn=Add Replication Agreements,cn=permissions,cn=pbac,dc=dbr,dc=roche ,dc=com memberOf: cn=Modify Replication Agreements,cn=permissions,cn=pbac,dc=dbr,dc=ro che,dc=com memberOf: cn=Remove Replication Agreements,cn=permissions,cn=pbac,dc=dbr,dc=ro che,dc=com memberOf: cn=Host Enrollment,cn=privileges,cn=pbac,dc=dbr,dc=roche,dc=com memberOf: cn=Manage host keytab,cn=permissions,cn=pbac,dc=dbr,dc=roche,dc=com memberOf: cn=Enroll a host,cn=permissions,cn=pbac,dc=dbr,dc=roche,dc=com memberOf: cn=Add krbPrincipalName to a host,cn=permissions,cn=pbac,dc=dbr,dc=r oche,dc=com memberOf: cn=Unlock user
Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
On 10/17/2012 01:05 PM, Macklin, Jason wrote: Thanks guys! Adding the -b did make a world of difference though it still doesn't make anything too obvious... at least to me. [jmacklin@dbduwdu062 Desktop]$ ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com -b ou=SUDOers,dc=dbr,dc=roche,dc=com SASL/GSSAPI authentication started SASL username: ad...@dbr.roche.com SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base ou=SUDOers,dc=dbr,dc=roche,dc=com with scope subtree # filter: (objectclass=*) # requesting: ALL # # sudoers, dbr.roche.com dn: ou=sudoers,dc=dbr,dc=roche,dc=com objectClass: extensibleObject ou: sudoers # test4, sudoers, dbr.roche.com dn: cn=test4,ou=sudoers,dc=dbr,dc=roche,dc=com objectClass: sudoRole sudoUser: asteinfeld sudoHost: dbduwdu062.dbr.roche.com sudoHost: +tempsudo sudoCommand: ALL cn: test4 This means that user asteinfeld should be allowed to execute any command on host dbduwdu062.dbr.roche.com or any host that is a member of the tempsudo host group. Is this the user you making tests with? Keep in mind the other general per-requisits: If you use netgroups the domain should be correct and the netgroups should be configured. Also HBAC should allow this user to authenticate via sudo on this host. AFAIR your HBAC is now wide open but when you start changing things to narrow access you need to make HBAC rules for SUDO too. # switch, sudoers, dbr.roche.com dn: cn=switch,ou=sudoers,dc=dbr,dc=roche,dc=com objectClass: sudoRole sudoUser: oyilmaz sudoHost: dbdusdu071.dbr.roche.com sudoCommand: /bin/su cn: switch This rule allows oyilmaz to execute one command /bin/su on host dbdusdu071.dbr.roche.com # jing144, sudoers, dbr.roche.com dn: cn=jing144,ou=sudoers,dc=dbr,dc=roche,dc=com objectClass: sudoRole sudoUser: jli sudoHost: dbduvdu144.dbr.roche.com sudoCommand: ALL cn: jing144 I hope you can now deduce the meaning of this one :-) # Admin, sudoers, dbr.roche.com dn: cn=Admin,ou=sudoers,dc=dbr,dc=roche,dc=com objectClass: sudoRole sudoUser: jmacklin sudoUser: mrini sudoUser: cgajare sudoUser: parnold sudoUser: hhebert sudoUser: ckuecherer sudoUser: gferreri sudoHost: ALL sudoCommand: ALL cn: Admin given users ALL commands on any host. # search result search: 4 result: 0 Success # numResponses: 6 # numEntries: 5 I really appreciate all of the help! Cheers, Jason So with this knowledge can you try different combinations of users and hosts and provide the results? You might want to remove the Admin for now to get it out of picture. -- 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] Sudo works for full access, but not on a per command or host level.
Yes Dmitri, this is the user I'm doing the tests with on that client. Though I
would expect this user to have sudo capabilities on this host he does not. I
first came across the idea that maybe domainname/nisdomainname/dnsdomainname
did not match and that was causing the problem. I have since fixed all of
those to match my system domain which is the same domain that the client was
enrolled with and it did not change any of the sudo behaviors for this user. I
currently have no specific HBAC rule configured besides the wide open rule.
Do I need one more specific for allowing users to run sudo?
-Original Message-
From: Dmitri Pal [mailto:d...@redhat.com]
Sent: Wednesday, October 17, 2012 2:57 PM
To: Macklin, Jason {DASB~Branford}
Cc: jr.aqu...@citrix.com; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per
command or host level.
On 10/17/2012 01:05 PM, Macklin, Jason wrote:
Thanks guys! Adding the -b did make a world of difference though it still
doesn't make anything too obvious... at least to me.
[jmacklin@dbduwdu062 Desktop]$ ldapsearch -Y GSSAPI -H
ldap://dbduvdu145.dbr.roche.com -b ou=SUDOers,dc=dbr,dc=roche,dc=com
SASL/GSSAPI authentication started
SASL username: ad...@dbr.roche.com
SASL SSF: 56
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base ou=SUDOers,dc=dbr,dc=roche,dc=com with scope subtree #
filter: (objectclass=*) # requesting: ALL #
# sudoers, dbr.roche.com
dn: ou=sudoers,dc=dbr,dc=roche,dc=com
objectClass: extensibleObject
ou: sudoers
# test4, sudoers, dbr.roche.com
dn: cn=test4,ou=sudoers,dc=dbr,dc=roche,dc=com
objectClass: sudoRole
sudoUser: asteinfeld
sudoHost: dbduwdu062.dbr.roche.com
sudoHost: +tempsudo
sudoCommand: ALL
cn: test4
This means that user asteinfeld should be allowed to execute any command on
host dbduwdu062.dbr.roche.com or any host that is a member of the tempsudo
host group.
Is this the user you making tests with?
Keep in mind the other general per-requisits: If you use netgroups the domain
should be correct and the netgroups should be configured.
Also HBAC should allow this user to authenticate via sudo on this host.
AFAIR your HBAC is now wide open but when you start changing things to narrow
access you need to make HBAC rules for SUDO too.
# switch, sudoers, dbr.roche.com
dn: cn=switch,ou=sudoers,dc=dbr,dc=roche,dc=com
objectClass: sudoRole
sudoUser: oyilmaz
sudoHost: dbdusdu071.dbr.roche.com
sudoCommand: /bin/su
cn: switch
This rule allows oyilmaz to execute one command /bin/su on host
dbdusdu071.dbr.roche.com
# jing144, sudoers, dbr.roche.com
dn: cn=jing144,ou=sudoers,dc=dbr,dc=roche,dc=com
objectClass: sudoRole
sudoUser: jli
sudoHost: dbduvdu144.dbr.roche.com
sudoCommand: ALL
cn: jing144
I hope you can now deduce the meaning of this one :-)
# Admin, sudoers, dbr.roche.com
dn: cn=Admin,ou=sudoers,dc=dbr,dc=roche,dc=com
objectClass: sudoRole
sudoUser: jmacklin
sudoUser: mrini
sudoUser: cgajare
sudoUser: parnold
sudoUser: hhebert
sudoUser: ckuecherer
sudoUser: gferreri
sudoHost: ALL
sudoCommand: ALL
cn: Admin
given users ALL commands on any host.
# search result
search: 4
result: 0 Success
# numResponses: 6
# numEntries: 5
I really appreciate all of the help!
Cheers,
Jason
So with this knowledge can you try different combinations of users and hosts
and provide the results?
You might want to remove the Admin for now to get it out of picture.
--
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] Sudo works for full access, but not on a per command or host level.
On 10/17/2012 12:49 PM, Macklin, Jason wrote:
ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D cn=directory manager -W -b
dc=dbr,dc=roche,dc=com uid=asteinfeld \*
snip
dn: uid=asteinfeld,cn=users,cn=accounts,dc=dbr,dc=roche,dc=com
...snip...
krbPrincipalName: asteinf...@dbr.roche.com
krbPasswordExpiration: 20130324201805Z
krbLastPwdChange: 20120925201805Z
krbLoginFailedCount: 0
krbLastSuccessfulAuth: 20121017184614Z
krbTicketFlags: 128
krbLastFailedAuth: 20121015143818Z
No krbPwdLockoutDuration attribute - so according to ipalockout_preop()
this means the Entry permanently locked. Not sure why.
[jmacklin@dbduwdu062 Desktop]$ ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D
cn=directory manager -W -b dc=dbr,dc=roche,dc=com uid=jmacklin \*Enter LDAP
Password:
dn: uid=jmacklin,cn=users,cn=compat,dc=dbr,dc=roche,dc=com
objectClass: posixAccount
objectClass: top
gecos: Jason Macklin
cn: Jason Macklin
uidNumber: 2084
gidNumber: 2084
loginShell: /bin/bash
homeDirectory: /home2/jmacklin
uid: jmacklin
dn: uid=jmacklin,cn=users,cn=accounts,dc=dbr,dc=roche,dc=com
displayName: Jason Macklin
cn: Jason Macklin
objectClass: top
objectClass: person
objectClass: organizationalperson
objectClass: inetorgperson
objectClass: inetuser
objectClass: posixaccount
objectClass: krbprincipalaux
objectClass: krbticketpolicyaux
objectClass: ipaobject
objectClass: mepOriginEntry
loginShell: /bin/bash
sn: Macklin
gecos: Jason Macklin
homeDirectory: /home2/jmacklin
krbPwdPolicyReference: cn=global_policy,cn=DBR.ROCHE.COM,cn=kerberos,dc=dbr,dc
=roche,dc=com
krbPrincipalName: jmack...@dbr.roche.com
givenName: Jason
uid: jmacklin
initials: JM
uidNumber: 2084
gidNumber: 2084
ipaUniqueID: 045652b4-8e3c-11e1-831f-005056bb0010
mepManagedEntry: cn=jmacklin,cn=groups,cn=accounts,dc=dbr,dc=roche,dc=com
memberOf: cn=admins,cn=groups,cn=accounts,dc=dbr,dc=roche,dc=com
memberOf: cn=Replication Administrators,cn=privileges,cn=pbac,dc=dbr,dc=roche,
dc=com
memberOf: cn=Add Replication Agreements,cn=permissions,cn=pbac,dc=dbr,dc=roche
,dc=com
memberOf: cn=Modify Replication Agreements,cn=permissions,cn=pbac,dc=dbr,dc=ro
che,dc=com
memberOf: cn=Remove Replication Agreements,cn=permissions,cn=pbac,dc=dbr,dc=ro
che,dc=com
memberOf: cn=Host Enrollment,cn=privileges,cn=pbac,dc=dbr,dc=roche,dc=com
memberOf: cn=Manage host keytab,cn=permissions,cn=pbac,dc=dbr,dc=roche,dc=com
memberOf: cn=Enroll a host,cn=permissions,cn=pbac,dc=dbr,dc=roche,dc=com
memberOf: cn=Add krbPrincipalName to a host,cn=permissions,cn=pbac,dc=dbr,dc=r
oche,dc=com
memberOf: cn=Unlock user accounts,cn=permissions,cn=pbac,dc=dbr,dc=roche,dc=co
m
memberOf: cn=Manage service keytab,cn=permissions,cn=pbac,dc=dbr,dc=roche,dc=c
om
memberOf: cn=dbr,cn=groups,cn=accounts,dc=dbr,dc=roche,dc=com
memberOf: ipaUniqueID=23216c12-9934-11e1-bd4c-005056bb0010,cn=sudorules,cn=sud
o,dc=dbr,dc=roche,dc=com
krbLastFailedAuth: 20121017164159Z
krbPrincipalKey:: MIIC4qADAgEBoQMCAQGiAwIBBaMDAgEBpIICyjCCAsYwbaAgMB6gAwIBAKEX
BBVEQlIuUk9DSEUuQ09Nam1hY2tsaW6hSTBHoAMCARKhQAQ+IACOG0H0Ebd8nSSY6zU3Y29ZHtQ9a
sC2QJFL/lnbaFO1DYG15WjJYXnJ7k3m0LN0aTyjvz7FN4OWMF4tvvowXaAgMB6gAwIBAKEXBBVEQl
IuUk9DSEUuQ09Nam1hY2tsaW6hOTA3oAMCARGhMAQuEAD6UdNSe/mp8qqi4OuT7HOqIs80DFQDRny
37aZaD4lYrFsnQiBtpnpMnNSxADBloCAwHqADAgEAoRcEFURCUi5ST0NIRS5DT01qbWFja2xpbqFB
MD+gAwIBEKE4BDYYADAQZLDW61U+4aEZT4b+/X/OpiQLHTQlyIUolm9EjVG4wXu+8Mn4lMYMZyR/F
Gw6NWeeq1kwXaAgMB6gAwIBAKEXBBVEQlIuUk9DSEUuQ09Nam1hY2tsaW6hOTA3oAMCARehMAQuEA
CiWDGd28XkiaDAwpGyK0MqSawLCXs+jKOFAA5BoSpayVTJJqjzAwSEitSu5zBVoCAwHqADAgEAoRc
EFURCUi5ST0NIRS5DT01qbWFja2xpbqExMC+gAwIBCKEoBCYIAKL5bzV4nQide/+6/2FE5LxYGULv
8Ws/Uu0RXrwAnR8/ZuUh0TBVoCAwHqADAgEAoRcEFURCUi5ST0NIRS5DT01qbWFja2xpbqExMC+gA
wIBA6EoBCYIANgV0agxRmfBwY2Cb7gPlm1oWDY5qhZidd8a0KmeIlBG56XLZjAzoTEwL6ADAgEBoS
gEJggAo/BQC7g4SWQY0UkU7rvoOAXwobVlAZn8mesgQEznRDr2+bxjME2gGDAWoAMCAQWhDwQNREJ
SLlJPQ0hFLkNPTaExMC+gAwIBAaEoBCYIAMDDcwjYU6jLJTnE+Lzs0Ulxgf4FDEnTRXTjfJBqXIJb
R5aBPg==
krbLastPwdChange: 20120809140419Z
krbPasswordExpiration: 20130205140419Z
userPassword:: e1NTSEF9a0NXcUxTc1JOQ2tEUVlLVVF4VTdJLzh1TXREVnBWZjlnMWRxa0E9PQ=
=
krbExtraData:: AAJjwyNQa2FkbWluZEBEQlIuUk9DSEUuQ09NAA==
krbLastSuccessfulAuth: 2012101718Z
krbLoginFailedCount: 0
krbTicketFlags: 128
So with all of that output, I would like to mention the discrepancy with ldap.conf. Just
trying to get any sudo working on RHEL 6.3 was problematic until I stumbled
upon a post that mentioned creating/editing /etc/sudo-ldap.conf rather then
/etc/ldap.conf or /etc/openldap/ldap.conf. If I remove the /etc/sudo-ldap.conf then I
have no sudo capabilities at all.
-Original Message-
From: Rich Megginson [mailto:rmegg...@redhat.com]
Sent: Wednesday, October 17, 2012 2:06 PM
To: Macklin, Jason {DASB~Branford}
Cc: rcrit...@redhat.com; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per
command or host level.
On 10/17/2012 11:51 AM, Macklin, Jason wrote:
Re: [Freeipa-users] Failed installation
Bret Wortman wrote: Now it appears that whatever is supposed to be running on port 9445 (looks like mindarray-ca) isn't running, and I'm not sure how it gets started, exactly. I ran lsof -i:9445 on this server and on a FreeIPA test box I first set up, and it's running on the test box but not the new one. Where should I look next? See if there are any SELinux denials: ausearch -m AVC It looks like tomcat failed to start. The logs are in /var/log/pki-ca. rob On Wed, Oct 17, 2012 at 2:07 PM, Bret Wortman bret.wort...@damascusgrp.com mailto:bret.wort...@damascusgrp.com wrote: Spot on. It was a fresh install of F17 and I neglected to # yum update first. I've done so, rebooted, and am trying again with better results. On Wed, Oct 17, 2012 at 1:45 PM, John Dennis jden...@redhat.com mailto:jden...@redhat.com wrote: On 10/17/2012 12:40 PM, Bret Wortman wrote: I recently tried installing freeipa on a new server, but ipa-server-install had problems around this point: Configuring certificate server: Estimated time 3 minutes 30 seconds [1/18]: creating certificate server user [2/18]: creating pki-ca instance [3/18]: configuring certificate server instance ipa : CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname fs1.wedgeofli.me http://fs1.wedgeofli.me http://fs1.wedgeofli.me -cs_port 9445 -client_certdb_dir /tmp/tmp-UvBMbL -client_certdb_pwd -preop_pin HHxKHUz5RRfzQ3OkFMlR -domain_name IPA -admin_user admin -admin_email root@localhost -admin_ -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject CN=ipa-ca-agent,O=WEDGEOFLI.ME http://WEDGEOFLI.ME http://WEDGEOFLI.ME -ldap_host fs1.wedgeofli.me http://fs1.wedgeofli.me http://fs1.wedgeofli.me -ldap_port 7389 -bind_dn cn=Directory Manager -bind_ -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12 true -backup_pwd -subsystem_name pki-cad -token_name internal -ca_subsystem_cert_subject___name CN=CA Subsystem,O=WEDGEOFLI.ME http://WEDGEOFLI.ME http://WEDGEOFLI.ME -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=WEDGEOFLI.ME http://WEDGEOFLI.ME http://WEDGEOFLI.ME -ca_server_cert_subject_name CN=fs1.wedgeofli.me http://fs1.wedgeofli.me http://fs1.wedgeofli.me,O=WE__DGEOFLI.ME http://WEDGEOFLI.ME http://WEDGEOFLI.ME -ca_audit_signing_cert___subject_name CN=CA Audit,O=WEDGEOFLI.ME http://WEDGEOFLI.ME http://WEDGEOFLI.ME -ca_sign_cert_subject_name CN=Certificate Authority,O=WEDGEOFLI.ME http://WEDGEOFLI.ME http://WEDGEOFLI.ME -external false -clone false' returned non-zero exit status 255 Unexpected error - see ipaserver-install.log for details: Configuration of CA failed [root@fs1 ~]# The logfile revealed the following stack trace: ##__### Attempting to connect to: fs1.wedgeofli.me:9445 http://fs1.wedgeofli.me:9445 http://fs1.wedgeofli.me:9445 Exception in LoginPanel(): java.lang.NullPointerException ERROR: ConfigureCA: LoginPanel() failure ERROR: unable to create CA ##__##__### 2012-10-17T16:24:53Z DEBUG stderr=Exception: Unable to Send Request:java.net http://java.net.__ConnectException: Connection refused java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.__socketConnect(Native Method) at java.net http://java.net.__AbstractPlainSocketImpl.__doConnect(__AbstractPlainSocketImpl.java:__339) at java.net http://java.net.__AbstractPlainSocketImpl.__connectToAddress(__AbstractPlainSocketImpl.java:__200) at java.net http://java.net.__AbstractPlainSocketImpl.__connect(__AbstractPlainSocketImpl.java:__182) at java.net.SocksSocketImpl.__connect(SocksSocketImpl.java:__391) at java.net.Socket.connect(__Socket.java:579) at java.net.Socket.connect(__Socket.java:528) at java.net.Socket.init(Socket.__java:425) at java.net.Socket.init(Socket.__java:241) at HTTPClient.sslConnect(__HTTPClient.java:326) at
Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
On 10/17/2012 03:05 PM, Macklin, Jason wrote:
Yes Dmitri, this is the user I'm doing the tests with on that client. Though
I would expect this user to have sudo capabilities on this host he does not.
I first came across the idea that maybe
domainname/nisdomainname/dnsdomainname did not match and that was causing the
problem. I have since fixed all of those to match my system domain which is
the same domain that the client was enrolled with and it did not change any
of the sudo behaviors for this user. I currently have no specific HBAC rule
configured besides the wide open rule. Do I need one more specific for
allowing users to run sudo?
No. It should just work then. It definitely connects and matches the
Admin rule but not the other rules so I was not sure if you are testing
the right rule on the right machine with the right user.
We can start dealing with the problems step by step.
We know Admin rule works.
If you add all hosts to a hostgroup and use it in the Admin rule instead
of just all would it continue to work?
Then you can start removing hosts from the group one by one.
After testing with group you can replace the group with individual host
and see whether it works and so on.
May be there is a bug somewhere but so far we have not narrowed it done
well enough.
I am traveling next day so I hope someone else will pickup the thread.
-Original Message-
From: Dmitri Pal [mailto:d...@redhat.com]
Sent: Wednesday, October 17, 2012 2:57 PM
To: Macklin, Jason {DASB~Branford}
Cc: jr.aqu...@citrix.com; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per
command or host level.
On 10/17/2012 01:05 PM, Macklin, Jason wrote:
Thanks guys! Adding the -b did make a world of difference though it still
doesn't make anything too obvious... at least to me.
[jmacklin@dbduwdu062 Desktop]$ ldapsearch -Y GSSAPI -H
ldap://dbduvdu145.dbr.roche.com -b ou=SUDOers,dc=dbr,dc=roche,dc=com
SASL/GSSAPI authentication started
SASL username: ad...@dbr.roche.com
SASL SSF: 56
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base ou=SUDOers,dc=dbr,dc=roche,dc=com with scope subtree #
filter: (objectclass=*) # requesting: ALL #
# sudoers, dbr.roche.com
dn: ou=sudoers,dc=dbr,dc=roche,dc=com
objectClass: extensibleObject
ou: sudoers
# test4, sudoers, dbr.roche.com
dn: cn=test4,ou=sudoers,dc=dbr,dc=roche,dc=com
objectClass: sudoRole
sudoUser: asteinfeld
sudoHost: dbduwdu062.dbr.roche.com
sudoHost: +tempsudo
sudoCommand: ALL
cn: test4
This means that user asteinfeld should be allowed to execute any command on
host dbduwdu062.dbr.roche.com or any host that is a member of the
tempsudo host group.
Is this the user you making tests with?
Keep in mind the other general per-requisits: If you use netgroups the domain
should be correct and the netgroups should be configured.
Also HBAC should allow this user to authenticate via sudo on this host.
AFAIR your HBAC is now wide open but when you start changing things to narrow
access you need to make HBAC rules for SUDO too.
# switch, sudoers, dbr.roche.com
dn: cn=switch,ou=sudoers,dc=dbr,dc=roche,dc=com
objectClass: sudoRole
sudoUser: oyilmaz
sudoHost: dbdusdu071.dbr.roche.com
sudoCommand: /bin/su
cn: switch
This rule allows oyilmaz to execute one command /bin/su on host
dbdusdu071.dbr.roche.com
# jing144, sudoers, dbr.roche.com
dn: cn=jing144,ou=sudoers,dc=dbr,dc=roche,dc=com
objectClass: sudoRole
sudoUser: jli
sudoHost: dbduvdu144.dbr.roche.com
sudoCommand: ALL
cn: jing144
I hope you can now deduce the meaning of this one :-)
# Admin, sudoers, dbr.roche.com
dn: cn=Admin,ou=sudoers,dc=dbr,dc=roche,dc=com
objectClass: sudoRole
sudoUser: jmacklin
sudoUser: mrini
sudoUser: cgajare
sudoUser: parnold
sudoUser: hhebert
sudoUser: ckuecherer
sudoUser: gferreri
sudoHost: ALL
sudoCommand: ALL
cn: Admin
given users ALL commands on any host.
# search result
search: 4
result: 0 Success
# numResponses: 6
# numEntries: 5
I really appreciate all of the help!
Cheers,
Jason
So with this knowledge can you try different combinations of users and hosts
and provide the results?
You might want to remove the Admin for now to get it out of picture.
--
Thank you,
Dmitri Pal
Sr. Engineering Manager for IdM portfolio Red Hat Inc.
---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
--
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] Sudo works for full access, but not on a per command or host level.
Rich Megginson wrote:
On 10/17/2012 12:49 PM, Macklin, Jason wrote:
ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D cn=directory
manager -W -b dc=dbr,dc=roche,dc=com uid=asteinfeld \*
snip
dn: uid=asteinfeld,cn=users,cn=accounts,dc=dbr,dc=roche,dc=com
...snip...
krbPrincipalName: asteinf...@dbr.roche.com
krbPasswordExpiration: 20130324201805Z
krbLastPwdChange: 20120925201805Z
krbLoginFailedCount: 0
krbLastSuccessfulAuth: 20121017184614Z
krbTicketFlags: 128
krbLastFailedAuth: 20121015143818Z
No krbPwdLockoutDuration attribute - so according to ipalockout_preop()
this means the Entry permanently locked. Not sure why.
I don't believe this applies if the attribute doesn't exist. It doesn't
for any of my test users and it works fine.
[jmacklin@dbduwdu062 Desktop]$ ldapsearch -xLLL -H
ldap://dbduvdu145.dbr.roche.com -D cn=directory manager -W -b
dc=dbr,dc=roche,dc=com uid=jmacklin \*Enter LDAP Password:
dn: uid=jmacklin,cn=users,cn=compat,dc=dbr,dc=roche,dc=com
objectClass: posixAccount
objectClass: top
gecos: Jason Macklin
cn: Jason Macklin
uidNumber: 2084
gidNumber: 2084
loginShell: /bin/bash
homeDirectory: /home2/jmacklin
uid: jmacklin
dn: uid=jmacklin,cn=users,cn=accounts,dc=dbr,dc=roche,dc=com
displayName: Jason Macklin
cn: Jason Macklin
objectClass: top
objectClass: person
objectClass: organizationalperson
objectClass: inetorgperson
objectClass: inetuser
objectClass: posixaccount
objectClass: krbprincipalaux
objectClass: krbticketpolicyaux
objectClass: ipaobject
objectClass: mepOriginEntry
loginShell: /bin/bash
sn: Macklin
gecos: Jason Macklin
homeDirectory: /home2/jmacklin
krbPwdPolicyReference:
cn=global_policy,cn=DBR.ROCHE.COM,cn=kerberos,dc=dbr,dc
=roche,dc=com
krbPrincipalName: jmack...@dbr.roche.com
givenName: Jason
uid: jmacklin
initials: JM
uidNumber: 2084
gidNumber: 2084
ipaUniqueID: 045652b4-8e3c-11e1-831f-005056bb0010
mepManagedEntry: cn=jmacklin,cn=groups,cn=accounts,dc=dbr,dc=roche,dc=com
memberOf: cn=admins,cn=groups,cn=accounts,dc=dbr,dc=roche,dc=com
memberOf: cn=Replication
Administrators,cn=privileges,cn=pbac,dc=dbr,dc=roche,
dc=com
memberOf: cn=Add Replication
Agreements,cn=permissions,cn=pbac,dc=dbr,dc=roche
,dc=com
memberOf: cn=Modify Replication
Agreements,cn=permissions,cn=pbac,dc=dbr,dc=ro
che,dc=com
memberOf: cn=Remove Replication
Agreements,cn=permissions,cn=pbac,dc=dbr,dc=ro
che,dc=com
memberOf: cn=Host Enrollment,cn=privileges,cn=pbac,dc=dbr,dc=roche,dc=com
memberOf: cn=Manage host
keytab,cn=permissions,cn=pbac,dc=dbr,dc=roche,dc=com
memberOf: cn=Enroll a host,cn=permissions,cn=pbac,dc=dbr,dc=roche,dc=com
memberOf: cn=Add krbPrincipalName to a
host,cn=permissions,cn=pbac,dc=dbr,dc=r
oche,dc=com
memberOf: cn=Unlock user
accounts,cn=permissions,cn=pbac,dc=dbr,dc=roche,dc=co
m
memberOf: cn=Manage service
keytab,cn=permissions,cn=pbac,dc=dbr,dc=roche,dc=c
om
memberOf: cn=dbr,cn=groups,cn=accounts,dc=dbr,dc=roche,dc=com
memberOf:
ipaUniqueID=23216c12-9934-11e1-bd4c-005056bb0010,cn=sudorules,cn=sud
o,dc=dbr,dc=roche,dc=com
krbLastFailedAuth: 20121017164159Z
krbPrincipalKey::
MIIC4qADAgEBoQMCAQGiAwIBBaMDAgEBpIICyjCCAsYwbaAgMB6gAwIBAKEX
BBVEQlIuUk9DSEUuQ09Nam1hY2tsaW6hSTBHoAMCARKhQAQ+IACOG0H0Ebd8nSSY6zU3Y29ZHtQ9a
sC2QJFL/lnbaFO1DYG15WjJYXnJ7k3m0LN0aTyjvz7FN4OWMF4tvvowXaAgMB6gAwIBAKEXBBVEQl
IuUk9DSEUuQ09Nam1hY2tsaW6hOTA3oAMCARGhMAQuEAD6UdNSe/mp8qqi4OuT7HOqIs80DFQDRny
37aZaD4lYrFsnQiBtpnpMnNSxADBloCAwHqADAgEAoRcEFURCUi5ST0NIRS5DT01qbWFja2xpbqFB
MD+gAwIBEKE4BDYYADAQZLDW61U+4aEZT4b+/X/OpiQLHTQlyIUolm9EjVG4wXu+8Mn4lMYMZyR/F
Gw6NWeeq1kwXaAgMB6gAwIBAKEXBBVEQlIuUk9DSEUuQ09Nam1hY2tsaW6hOTA3oAMCARehMAQuEA
CiWDGd28XkiaDAwpGyK0MqSawLCXs+jKOFAA5BoSpayVTJJqjzAwSEitSu5zBVoCAwHqADAgEAoRc
EFURCUi5ST0NIRS5DT01qbWFja2xpbqExMC+gAwIBCKEoBCYIAKL5bzV4nQide/+6/2FE5LxYGULv
8Ws/Uu0RXrwAnR8/ZuUh0TBVoCAwHqADAgEAoRcEFURCUi5ST0NIRS5DT01qbWFja2xpbqExMC+gA
wIBA6EoBCYIANgV0agxRmfBwY2Cb7gPlm1oWDY5qhZidd8a0KmeIlBG56XLZjAzoTEwL6ADAgEBoS
gEJggAo/BQC7g4SWQY0UkU7rvoOAXwobVlAZn8mesgQEznRDr2+bxjME2gGDAWoAMCAQWhDwQNREJ
SLlJPQ0hFLkNPTaExMC+gAwIBAaEoBCYIAMDDcwjYU6jLJTnE+Lzs0Ulxgf4FDEnTRXTjfJBqXIJb
R5aBPg==
krbLastPwdChange: 20120809140419Z
krbPasswordExpiration: 20130205140419Z
userPassword::
e1NTSEF9a0NXcUxTc1JOQ2tEUVlLVVF4VTdJLzh1TXREVnBWZjlnMWRxa0E9PQ=
=
krbExtraData:: AAJjwyNQa2FkbWluZEBEQlIuUk9DSEUuQ09NAA==
krbLastSuccessfulAuth: 2012101718Z
krbLoginFailedCount: 0
krbTicketFlags: 128
So with all of that output, I would like to mention the discrepancy
with ldap.conf. Just trying to get any sudo working on RHEL 6.3 was
problematic until I stumbled upon a post that mentioned
creating/editing /etc/sudo-ldap.conf rather then /etc/ldap.conf or
/etc/openldap/ldap.conf. If I remove the /etc/sudo-ldap.conf then I
have no sudo capabilities at all.
-Original Message-
From: Rich Megginson [mailto:rmegg...@redhat.com]
Sent: Wednesday, October 17, 2012 2:06 PM
To: Macklin, Jason {DASB~Branford}
Cc: rcrit...@redhat.com; freeipa-users@redhat.com
Subject:
Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
Can you confirm that you have sudoer_debug set to 2? If I gather correctly, this is on RHEL 6.3? What version of sudo? I'm seeing different output. Mine includes the number of candidate results for sudoUser are found. If you watch /var/log/dirsrv/slapd-REALM/access on your IPA server you'll be able to see the LDAP searches the sudo client is making. The log is buffered so you won't see them immediately. Can you send us the queries that are being made? thanks rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
On Wed, Oct 17, 2012 at 2:26 PM, Rob Crittenden rcrit...@redhat.com wrote: Rich Megginson wrote: On 10/17/2012 12:49 PM, Macklin, Jason wrote: ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.**comhttp://dbduvdu145.dbr.roche.com-D cn=directory manager -W -b dc=dbr,dc=roche,dc=com uid=asteinfeld \* snip dn: uid=asteinfeld,cn=users,cn=**accounts,dc=dbr,dc=roche,dc=**com ...snip... krbPrincipalName: asteinf...@dbr.roche.com krbPasswordExpiration: 20130324201805Z krbLastPwdChange: 20120925201805Z krbLoginFailedCount: 0 krbLastSuccessfulAuth: 20121017184614Z krbTicketFlags: 128 krbLastFailedAuth: 20121015143818Z No krbPwdLockoutDuration attribute - so according to ipalockout_preop() this means the Entry permanently locked. Not sure why. I don't believe this applies if the attribute doesn't exist. It doesn't for any of my test users and it works fine. [jmacklin@dbduwdu062 Desktop]$ ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.**com http://dbduvdu145.dbr.roche.com -D cn=directory manager -W -b dc=dbr,dc=roche,dc=com uid=jmacklin \*Enter LDAP Password: dn: uid=jmacklin,cn=users,cn=**compat,dc=dbr,dc=roche,dc=com objectClass: posixAccount objectClass: top gecos: Jason Macklin cn: Jason Macklin uidNumber: 2084 gidNumber: 2084 loginShell: /bin/bash homeDirectory: /home2/jmacklin uid: jmacklin dn: uid=jmacklin,cn=users,cn=**accounts,dc=dbr,dc=roche,dc=**com displayName: Jason Macklin cn: Jason Macklin objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixaccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: mepOriginEntry loginShell: /bin/bash sn: Macklin gecos: Jason Macklin homeDirectory: /home2/jmacklin krbPwdPolicyReference: cn=global_policy,cn=DBR.ROCHE.**COM http://DBR.ROCHE.COM ,cn=kerberos,dc=dbr,dc =roche,dc=com krbPrincipalName: jmack...@dbr.roche.com givenName: Jason uid: jmacklin initials: JM uidNumber: 2084 gidNumber: 2084 ipaUniqueID: 045652b4-8e3c-11e1-831f-**005056bb0010 mepManagedEntry: cn=jmacklin,cn=groups,cn=**accounts,dc=dbr,dc=roche,dc= **com memberOf: cn=admins,cn=groups,cn=**accounts,dc=dbr,dc=roche,dc=**com memberOf: cn=Replication Administrators,cn=privileges,**cn=pbac,dc=dbr,dc=roche, dc=com memberOf: cn=Add Replication Agreements,cn=permissions,cn=**pbac,dc=dbr,dc=roche ,dc=com memberOf: cn=Modify Replication Agreements,cn=permissions,cn=**pbac,dc=dbr,dc=ro che,dc=com memberOf: cn=Remove Replication Agreements,cn=permissions,cn=**pbac,dc=dbr,dc=ro che,dc=com memberOf: cn=Host Enrollment,cn=privileges,cn=** pbac,dc=dbr,dc=roche,dc=com memberOf: cn=Manage host keytab,cn=permissions,cn=pbac,**dc=dbr,dc=roche,dc=com memberOf: cn=Enroll a host,cn=permissions,cn=pbac,** dc=dbr,dc=roche,dc=com memberOf: cn=Add krbPrincipalName to a host,cn=permissions,cn=pbac,**dc=dbr,dc=r oche,dc=com memberOf: cn=Unlock user accounts,cn=permissions,cn=**pbac,dc=dbr,dc=roche,dc=co m memberOf: cn=Manage service keytab,cn=permissions,cn=pbac,**dc=dbr,dc=roche,dc=c om memberOf: cn=dbr,cn=groups,cn=accounts,**dc=dbr,dc=roche,dc=com memberOf: ipaUniqueID=23216c12-9934-**11e1-bd4c-005056bb0010,cn=**sudorules,cn=sud o,dc=dbr,dc=roche,dc=com krbLastFailedAuth: 20121017164159Z krbPrincipalKey:: MIIC4qADAgEBoQMCAQGiAwIBBaMDAg**EBpIICyjCCAsYwbaAgMB6gAwIBAKEX BBVEQlIuUk9DSEUuQ09Nam1hY2tsaW**6hSTBHoAMCARKhQAQ+** IACOG0H0Ebd8nSSY6zU3Y29ZHtQ9a sC2QJFL/**lnbaFO1DYG15WjJYXnJ7k3m0LN0aTy**jvz7FN4OWMF4tvvowXaAgMB6gAwIBA **KEXBBVEQl IuUk9DSEUuQ09Nam1hY2tsaW6hOTA3**oAMCARGhMAQuEAD6UdNSe/** mp8qqi4OuT7HOqIs80DFQDRny 37aZaD4lYrFsnQiBtpnpMnNSxADBlo**CAwHqADAgEAoRcEFURCUi5ST0NIRS5** DT01qbWFja2xpbqFB MD+gAwIBEKE4BDYYADAQZLDW61U+**4aEZT4b+/X/**OpiQLHTQlyIUolm9EjVG4wXu+** 8Mn4lMYMZyR/F Gw6NWeeq1kwXaAgMB6gAwIBAKEXBBV**EQlIuUk9DSEUuQ09Nam1hY2tsaW6hO** TA3oAMCARehMAQuEA CiWDGd28XkiaDAwpGyK0MqSawLCXs+**jKOFAA5BoSpayVTJJqjzAwSEitSu5z** BVoCAwHqADAgEAoRc EFURCUi5ST0NIRS5DT01qbWFja2xpb**qExMC+**gAwIBCKEoBCYIAKL5bzV4nQide/+6/** 2FE5LxYGULv 8Ws/Uu0RXrwAnR8/**ZuUh0TBVoCAwHqADAgEAoRcEFURCUi** 5ST0NIRS5DT01qbWFja2xpbqExMC+**gA wIBA6EoBCYIANgV0agxRmfBwY2Cb7g**Plm1oWDY5qhZidd8a0KmeIlBG56XLZ** jAzoTEwL6ADAgEBoS gEJggAo/**BQC7g4SWQY0UkU7rvoOAXwobVlAZn8**mesgQEznRDr2+** bxjME2gGDAWoAMCAQWhDwQNREJ SLlJPQ0hFLkNPTaExMC+**gAwIBAaEoBCYIAMDDcwjYU6jLJTnE+** Lzs0Ulxgf4FDEnTRXTjfJBqXIJb R5aBPg== krbLastPwdChange: 20120809140419Z krbPasswordExpiration: 20130205140419Z userPassword:: e1NTSEF9a0NXcUxTc1JOQ2tEUVlLVV**F4VTdJLzh1TXREVnBWZjlnMWRxa0E9**PQ= = krbExtraData:: AAJjwyNQa2FkbWluZEBEQlIuUk9DSE**UuQ09NAA== krbLastSuccessfulAuth: 2012101718Z krbLoginFailedCount: 0 krbTicketFlags: 128 So with all of that output, I would like to mention the discrepancy with ldap.conf. Just trying to get any sudo working on RHEL 6.3 was problematic
Re: [Freeipa-users] Failed installation
I think I have SELinux turned off but will double-check in the morning. And reply to the list -- Bret Wortman http://bretwortman.com/ http://twitter.com/bretwortman On Wednesday, October 17, 2012 at 3:17 PM, Rob Crittenden wrote: Bret Wortman wrote: Now it appears that whatever is supposed to be running on port 9445 (looks like mindarray-ca) isn't running, and I'm not sure how it gets started, exactly. I ran lsof -i:9445 on this server and on a FreeIPA test box I first set up, and it's running on the test box but not the new one. Where should I look next? See if there are any SELinux denials: ausearch -m AVC It looks like tomcat failed to start. The logs are in /var/log/pki-ca. rob On Wed, Oct 17, 2012 at 2:07 PM, Bret Wortman bret.wort...@damascusgrp.com mailto:bret.wort...@damascusgrp.com wrote: Spot on. It was a fresh install of F17 and I neglected to # yum update first. I've done so, rebooted, and am trying again with better results. On Wed, Oct 17, 2012 at 1:45 PM, John Dennis jden...@redhat.com mailto:jden...@redhat.com wrote: On 10/17/2012 12:40 PM, Bret Wortman wrote: I recently tried installing freeipa on a new server, but ipa-server-install had problems around this point: Configuring certificate server: Estimated time 3 minutes 30 seconds [1/18]: creating certificate server user [2/18]: creating pki-ca instance [3/18]: configuring certificate server instance ipa : CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname fs1.wedgeofli.me http://fs1.wedgeofli.me http://fs1.wedgeofli.me -cs_port 9445 -client_certdb_dir /tmp/tmp-UvBMbL -client_certdb_pwd -preop_pin HHxKHUz5RRfzQ3OkFMlR -domain_name IPA -admin_user admin -admin_email root@localhost -admin_ -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject CN=ipa-ca-agent,O=WEDGEOFLI.ME http://WEDGEOFLI.ME http://WEDGEOFLI.ME -ldap_host fs1.wedgeofli.me http://fs1.wedgeofli.me http://fs1.wedgeofli.me -ldap_port 7389 -bind_dn cn=Directory Manager -bind_ -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12 true -backup_pwd -subsystem_name pki-cad -token_name internal -ca_subsystem_cert_subject___name CN=CA Subsystem,O=WEDGEOFLI.ME http://WEDGEOFLI.ME http://WEDGEOFLI.ME -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=WEDGEOFLI.ME http://WEDGEOFLI.ME http://WEDGEOFLI.ME -ca_server_cert_subject_name CN=fs1.wedgeofli.me http://fs1.wedgeofli.me http://fs1.wedgeofli.me,O=WE__DGEOFLI.ME http://WEDGEOFLI.ME http://WEDGEOFLI.ME -ca_audit_signing_cert___subject_name CN=CA Audit,O=WEDGEOFLI.ME http://WEDGEOFLI.ME http://WEDGEOFLI.ME -ca_sign_cert_subject_name CN=Certificate Authority,O=WEDGEOFLI.ME http://WEDGEOFLI.ME http://WEDGEOFLI.ME -external false -clone false' returned non-zero exit status 255 Unexpected error - see ipaserver-install.log for details: Configuration of CA failed [root@fs1 ~]# The logfile revealed the following stack trace: ##__### Attempting to connect to: fs1.wedgeofli.me:9445 http://fs1.wedgeofli.me:9445 http://fs1.wedgeofli.me:9445 Exception in LoginPanel(): java.lang.NullPointerException ERROR: ConfigureCA: LoginPanel() failure ERROR: unable to create CA ##__##__### 2012-10-17T16:24:53Z DEBUG stderr=Exception: Unable to Send Request:java.net http://java.net.__ConnectException: Connection refused java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.__socketConnect(Native Method) at java.net http://java.net.__AbstractPlainSocketImpl.__doConnect(__AbstractPlainSocketImpl.java:__339) at java.net http://java.net.__AbstractPlainSocketImpl.__connectToAddress(__AbstractPlainSocketImpl.java:__200) at java.net http://java.net.__AbstractPlainSocketImpl.__connect(__AbstractPlainSocketImpl.java:__182) at java.net.SocksSocketImpl.__connect(SocksSocketImpl.java:__391) at java.net.Socket.connect(__Socket.java:579) at java.net.Socket.connect(__Socket.java:528) at java.net.Socket.init(Socket.__java:425) at java.net.Socket.init(Socket.__java:241) at HTTPClient.sslConnect(__HTTPClient.java:326) at ConfigureCA.LoginPanel(__ConfigureCA.java:244) at ConfigureCA.__ConfigureCAInstance(__ConfigureCA.java:1157) at ConfigureCA.main(ConfigureCA.__java:1672) java.lang.NullPointerException at ConfigureCA.LoginPanel(__ConfigureCA.java:245) at ConfigureCA.__ConfigureCAInstance(__ConfigureCA.java:1157) at ConfigureCA.main(ConfigureCA.__java:1672) Now I seem to be stuck. I tried uninstalling the freeipa-server package with # yum remove freeipa-server and then reinstalled it the same way, but
