Re: [Freeipa-users] User admins for different groups
On 03/26/2013 12:39 AM, Dmitri Pal wrote: I am trying to do the following: We have some branch offices at different locations. We want to use one ipa-server with replicas in each branch office. Each branch office should have it's own set of administrators who should be able to create/modify/delete users for its own branch but should not be allowed to change users from other branches. every member of admin-at should be forced to create/modify/delete only users in branch-at. The same applies for admin-us/branch-us. at first, i thought of a combination of (a) new role(s), with write/delete permissions set for the branch-at group, as well as an automember rule but it seems there is no way to filter for the creator of an entry, which would be needed for the group membership.. am i missing anything? This might help https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html#delegating-users Yes, I read the whole document but as far as I understand delegates are only helpful for editing existing records. I want admins of one branch to be able the also create users, but only in the assigned branch. Currently we use standard openldap with different ou's for the branches. Each branch admin has full ldap permissions for it's own ou-subtree. -- : Philipp Richter : LINBIT | Your Way to High Availability : Tel: +43-1-8178292-51, Fax: +43-1-8178292-82 : : http://www.linbit.com DRBD® and LINBIT® are registered trademarks of LINBIT, Austria. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] mutiple domain, single realm
On Tue, 26 Mar 2013, Stijn De Weirdt wrote: hi all, how can one add more domains to the same (existing) realm with ipa? we would like to bring multiple networks (some private, some public) under a single realm. as far as i understand krb5.conf, it means creating the following domain_realm section [domain_realm] .domain1 = REALM .domain2 = REALM reading the documentation, i didn't find any clues how to do this with ipa. default ipa server creation seems to assume a one-to-one mapping between domain and realm. It should be done mostly in the same way. As long as all clients and servers have these mappings configured, they should be able to work. Right now you have to maintain all these mappings manually, both at client and server sides. For 3.2 release or shortly afterwards we are trying to make it easier configurable. 3.1.3 will have 'ipa realmdomains' command to manage associated domains' list -- i.e. which DNS domains are associated with our own realm. 3.2 will have this list exposed to trusted AD domains so that they can see our topology and know where to send TGT requests (our KDCs). In addition KDC driver will be able to use the same list to augment the mapping in KDC. SSSD is also going to fetch the list like it fetches now list of trusted domains and configures them for clients. -- / Alexander Bokovoy ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] mutiple domain, single realm
thanks for the info. i'll setup a test with current branch and see if that works for us. stijn On 03/26/2013 01:52 PM, Alexander Bokovoy wrote: On Tue, 26 Mar 2013, Stijn De Weirdt wrote: hi all, how can one add more domains to the same (existing) realm with ipa? we would like to bring multiple networks (some private, some public) under a single realm. as far as i understand krb5.conf, it means creating the following domain_realm section [domain_realm] .domain1 = REALM .domain2 = REALM reading the documentation, i didn't find any clues how to do this with ipa. default ipa server creation seems to assume a one-to-one mapping between domain and realm. It should be done mostly in the same way. As long as all clients and servers have these mappings configured, they should be able to work. Right now you have to maintain all these mappings manually, both at client and server sides. For 3.2 release or shortly afterwards we are trying to make it easier configurable. 3.1.3 will have 'ipa realmdomains' command to manage associated domains' list -- i.e. which DNS domains are associated with our own realm. 3.2 will have this list exposed to trusted AD domains so that they can see our topology and know where to send TGT requests (our KDCs). In addition KDC driver will be able to use the same list to augment the mapping in KDC. SSSD is also going to fetch the list like it fetches now list of trusted domains and configures them for clients. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] User admins for different groups
Philipp Richter wrote: On 03/26/2013 12:39 AM, Dmitri Pal wrote: I am trying to do the following: We have some branch offices at different locations. We want to use one ipa-server with replicas in each branch office. Each branch office should have it's own set of administrators who should be able to create/modify/delete users for its own branch but should not be allowed to change users from other branches. every member of admin-at should be forced to create/modify/delete only users in branch-at. The same applies for admin-us/branch-us. at first, i thought of a combination of (a) new role(s), with write/delete permissions set for the branch-at group, as well as an automember rule but it seems there is no way to filter for the creator of an entry, which would be needed for the group membership.. am i missing anything? This might help https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html#delegating-users Yes, I read the whole document but as far as I understand delegates are only helpful for editing existing records. I want admins of one branch to be able the also create users, but only in the assigned branch. Currently we use standard openldap with different ou's for the branches. Each branch admin has full ldap permissions for it's own ou-subtree. IPA uses a flat DIT so here is no way to control adding users in a given branch office. The most you'd be able to do is delegae management (delete/modify) a subset of users who are members of a group that represents that branch office. Any new users added would need to be added to the appropriate branch group by the admin adding them. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] User admins for different groups
On 26.3.2013 15:10, Rob Crittenden wrote: Philipp Richter wrote: On 03/26/2013 12:39 AM, Dmitri Pal wrote: I am trying to do the following: We have some branch offices at different locations. We want to use one ipa-server with replicas in each branch office. Each branch office should have it's own set of administrators who should be able to create/modify/delete users for its own branch but should not be allowed to change users from other branches. every member of admin-at should be forced to create/modify/delete only users in branch-at. The same applies for admin-us/branch-us. at first, i thought of a combination of (a) new role(s), with write/delete permissions set for the branch-at group, as well as an automember rule but it seems there is no way to filter for the creator of an entry, which would be needed for the group membership.. am i missing anything? This might help https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html#delegating-users Yes, I read the whole document but as far as I understand delegates are only helpful for editing existing records. I want admins of one branch to be able the also create users, but only in the assigned branch. Currently we use standard openldap with different ou's for the branches. Each branch admin has full ldap permissions for it's own ou-subtree. IPA uses a flat DIT so here is no way to control adding users in a given branch office. The most you'd be able to do is delegae management (delete/modify) a subset of users who are members of a group that represents that branch office. Any new users added would need to be added to the appropriate branch group by the admin adding them. This sounds like big deficiency to me... Is it possible to hack automember plugin to enforce some group assignment based on creator's group/name as proposed above? It should allow users to prepare some hand crafted ACIs, I guess. (Sorry, I don't have any knowledge about automember internals :-) -- Petr^2 Spacek ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] User admins for different groups
Petr Spacek wrote: On 26.3.2013 15:10, Rob Crittenden wrote: Philipp Richter wrote: On 03/26/2013 12:39 AM, Dmitri Pal wrote: I am trying to do the following: We have some branch offices at different locations. We want to use one ipa-server with replicas in each branch office. Each branch office should have it's own set of administrators who should be able to create/modify/delete users for its own branch but should not be allowed to change users from other branches. every member of admin-at should be forced to create/modify/delete only users in branch-at. The same applies for admin-us/branch-us. at first, i thought of a combination of (a) new role(s), with write/delete permissions set for the branch-at group, as well as an automember rule but it seems there is no way to filter for the creator of an entry, which would be needed for the group membership.. am i missing anything? This might help https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html#delegating-users Yes, I read the whole document but as far as I understand delegates are only helpful for editing existing records. I want admins of one branch to be able the also create users, but only in the assigned branch. Currently we use standard openldap with different ou's for the branches. Each branch admin has full ldap permissions for it's own ou-subtree. IPA uses a flat DIT so here is no way to control adding users in a given branch office. The most you'd be able to do is delegae management (delete/modify) a subset of users who are members of a group that represents that branch office. Any new users added would need to be added to the appropriate branch group by the admin adding them. This sounds like big deficiency to me... Is it possible to hack automember plugin to enforce some group assignment based on creator's group/name as proposed above? It should allow users to prepare some hand crafted ACIs, I guess. (Sorry, I don't have any knowledge about automember internals :-) Using automember doesn't prevent an admin from adding a user outside of the branch. It would just automatically assign that new user to the correct branch based on the automember rules AND assuming that the admin that added the user included the right information for the rules. ACIs control add at the subtree level, so for us it is a binary. Either you can add users or you can't. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Heads-up: Removing self-sign CA
Hello list, FreeIPA's self-sign CA is a holdout from days where the our integration with a real CA wasn't that good. Also its name is confusing: the Dogtag CA also uses a self-signed certificate by default. We will soon be introducing a way to install IPA with custom certificates without a CA at all. When that is merged, it will no longer be possible to install a self-sign server. After that, the plan is to convert existing self-sign masters to CA-less on upgrade, and remove the self-sign code. On a CA-less master, IPA's cert commands will no longer be available and cert rotation will need to be done manually. Documentation on how to do this (using the existing self-signed CA cert) will be provided. -- Petr³ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Announcing FreeIPA 3.1.3
The FreeIPA team is proud to announce version FreeIPA v3.1.3.
It can be downloaded from http://www.freeipa.org/page/Downloads. The new
version has also been built for Fedora 18 and is on its way to updates-testing:
https://admin.fedoraproject.org/updates/freeipa-3.1.3-1.fc18
This release includes backport of selected (mainly Trust related) features from
upcoming FreeIPA 3.2.0 release. The following 3.1.x releases will contain
primarily bugfixes only.
== Highlights in 3.1.3 ==
=== New features ===
* New cert-find command. Search certificates in the Dogtag database based on
their serial number, validity or revocation details. This feature is available
both as a CLI command and Web UI page.
* New trustconfig-show and trustconfig-mod command. Show or modify AD Trust
settings generated during AD Trust installation (ipa-adtrust-install)
* New realmdomains-show and realmdomains-mod command. Manage list of domains
managed by FreeIPA server. The list will be used in future releases to inform
trusted domain about domains managed by FreeIPA. This feature is available both
as a CLI command and Web UI page.
* Support trusted domain users in HBAC test command (hbactest command).
* Allow filtering incoming trusted domain SIDs per-trust (trust-mod command).
* Faster UI loading. FreeIPA Web UI application is now packaged in minimalized
format. FreeIPA web server is now also able to transmit data in compressed
format.
=== Bug fixes ===
* Fixed migration from OpenLDAP. FreeIPA is now able to migrate users and
groups from OpenLDAP database instances.
* Migration process is now also a lot faster and provides more debug output (to
httpd error log).
* SUDO rules disabled by sudorule-disable command are now removed from
ou=sudoers compat tree without a need to restart 389 Directory Server instance.
* Fixed LDAP schema upgrade when upgrading from a pre-2.2.0 release
* Fixed server installation with external CA (--external-ca)
* Consolidate on-line help system, show help without need of valid Kerberos
credentials (ipa help)
* ... and many others stabilization fixes, see Detailed changelog for full
details
== Upgrading ==
An IPA server can be upgraded simply by installing updated rpms. The server
does not need to be shut down in advance.
Please note, that the referential integrity extension requires an extended set
of indexes to be configured. RPM update for an IPA server with a excessive
number of hosts, SUDO or HBAC entries may require several minutes to finish.
If you have multiple servers you may upgrade them one at a time. It is expected
that all servers will be upgraded in a relatively short period (days or weeks
not months). They should be able to co-exist peacefully but new features will
not be available on old servers and enrolling a new client against an old
server will result in the SSH keys not being uploaded.
Downgrading a server once upgraded is not supported.
Upgrading from 2.2.0 is supported. Upgrading from previous versions is not
supported and has not been tested.
An enrolled client does not need the new packages installed unless you want to
re-enroll it. SSH keys for already installed clients are not uploaded, you will
have to re-enroll the client or manually upload the keys.
== Feedback ==
Please provide comments, bugs and other feedback via the freeipa-users mailing
list: http://www.redhat.com/mailman/listinfo/freeipa-users
== Detailed Changelog since 3.1.2 ==
Alexander Bokovoy (2):
* ipasam: use base scope when fetching domain information about own domain
* Process exceptions when talking to Dogtag
Ana Krivokapic (6):
* Take into consideration services when deleting replicas
* Add list of domains associated to our realm to cn=etc
* Remove check for alphabetic only characters from domain name validation
* Fix internal error for ipa show-mappings
* Realm Domains page
* Use default NETBIOS name in unattended ipa-adtrust-install
Jakub Hrozek (1):
* Allow ipa-replica-conncheck and ipa-adtrust-install to read krb5 includedir
Jan Cholasta (6):
* Pylint cleanup.
* Raise ValidationError on invalid CSV values.
* Run interactive_prompt callbacks after CSV values are split.
* Fix remove while iterating in suppress_netgroup_memberof.
* Remove disabled entries from sudoers compat tree.
* Fix internal error in output_for_cli method of sudorule_{enable,disable}.
Martin Kosek (33):
* Fix migration for openldap DS
* Remove unused krbV imports
* Use fully qualified CCACHE names
* Fix permission_find test error
* Add trusconfig-show and trustconfig-mod commands
* ipa-kdb: add sentinel for LDAPDerefSpec allocation
* ipa-kdb: avoid ENOMEM when all SIDs are filtered out
* ipa-kdb: reinitialize LDAP configuration for known realms
* Add SID blacklist attributes
* ipa-kdb: read SID blacklist from LDAP
* ipa-sam: Fill SID blacklist when trust is added
* ipa-adtrust-install should ask for SID generation
* Test NetBIOS name clash before creating a trust
* Generalize AD GC search
* Do not hide SID resolver error in
Re: [Freeipa-users] User admins for different groups
On 03/26/2013 11:55 AM, Rob Crittenden wrote: Petr Spacek wrote: On 26.3.2013 15:10, Rob Crittenden wrote: Philipp Richter wrote: On 03/26/2013 12:39 AM, Dmitri Pal wrote: I am trying to do the following: We have some branch offices at different locations. We want to use one ipa-server with replicas in each branch office. Each branch office should have it's own set of administrators who should be able to create/modify/delete users for its own branch but should not be allowed to change users from other branches. every member of admin-at should be forced to create/modify/delete only users in branch-at. The same applies for admin-us/branch-us. at first, i thought of a combination of (a) new role(s), with write/delete permissions set for the branch-at group, as well as an automember rule but it seems there is no way to filter for the creator of an entry, which would be needed for the group membership.. am i missing anything? This might help https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html#delegating-users Yes, I read the whole document but as far as I understand delegates are only helpful for editing existing records. I want admins of one branch to be able the also create users, but only in the assigned branch. Currently we use standard openldap with different ou's for the branches. Each branch admin has full ldap permissions for it's own ou-subtree. IPA uses a flat DIT so here is no way to control adding users in a given branch office. The most you'd be able to do is delegae management (delete/modify) a subset of users who are members of a group that represents that branch office. Any new users added would need to be added to the appropriate branch group by the admin adding them. This sounds like big deficiency to me... Is it possible to hack automember plugin to enforce some group assignment based on creator's group/name as proposed above? It should allow users to prepare some hand crafted ACIs, I guess. (Sorry, I don't have any knowledge about automember internals :-) Using automember doesn't prevent an admin from adding a user outside of the branch. It would just automatically assign that new user to the correct branch based on the automember rules AND assuming that the admin that added the user included the right information for the rules. ACIs control add at the subtree level, so for us it is a binary. Either you can add users or you can't. I think Petr was suggesting to be able to add new factor into the auto-member configuration. If the admin that adds a user has some property than the user needs to be automatically placed into a specific group. And admin would have ACIs against that group. Isn't what should happen to support the use case with the flat tree we have? rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] kinit seg-fault for Solaris 9
Hi, I've setup FreeIPA for the first time and am using it successfully with Linux and Solaris 10 clients. On 8 separate Solaris 9 clients I'm running into an issue where 'kinit USER', for any user, fails with a segmentation fault after prompting for a password. On the client side there are no log entries. On the server side the Additional pre-authentication required entry is written to the log. When I execute 'kinit -k' everything works normally. I've verified that the keytabs for the Solaris 9 clients use only des-cbc-crc encryption and that allow_weak_crypto = true is set on the server side. Running 'truss kinit USER' on the Solaris 9 clients end with: Incurred fault #6, FLTBOUNDS %pc = 0xFF3582E4 siginfo: SIGSEGV SEGV_MAPERR addr=0x0004 Received signal #11, SIGSEGV (default) siginfo: SIGSEGV SEGV_MAPERR addr=0x0004 I've been fighting this for a while and have ensured that my Solaris 9 boxes are running the latest patches. Kerberos on the clients is the standard one that comes with Solaris. I've installed no additional kerberos components or packages. I'm hoping someone has seen this before or can point me in a new direction. At this point I've pretty much reached the end of my rope and am looking at using local passwords (blech!) on my Solaris 9 clients. Thanks in advance, Dave ~~ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] kinit seg-fault for Solaris 9
David Redmond wrote: Hi, I've setup FreeIPA for the first time and am using it successfully with Linux and Solaris 10 clients. On 8 separate Solaris 9 clients I'm running into an issue where 'kinit USER', for any user, fails with a segmentation fault after prompting for a password. On the client side there are no log entries. On the server side the Additional pre-authentication required entry is written to the log. When I execute 'kinit -k' everything works normally. I've verified that the keytabs for the Solaris 9 clients use only des-cbc-crc encryption and that allow_weak_crypto = true is set on the server side. Running 'truss kinit USER' on the Solaris 9 clients end with: Incurred fault #6, FLTBOUNDS %pc = 0xFF3582E4 siginfo: SIGSEGV SEGV_MAPERR addr=0x0004 Received signal #11, SIGSEGV (default) siginfo: SIGSEGV SEGV_MAPERR addr=0x0004 I've been fighting this for a while and have ensured that my Solaris 9 boxes are running the latest patches. Kerberos on the clients is the standard one that comes with Solaris. I've installed no additional kerberos components or packages. I'm hoping someone has seen this before or can point me in a new direction. At this point I've pretty much reached the end of my rope and am looking at using local passwords (blech!) on my Solaris 9 clients. I don't have a very helpful answer, but if memory serves my Sparc 9 install exhibits the same behavior. I don't have access to the latest updates though so I assumed it was related to that. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Cannot Enter in IP Addresses via GUI
adam smith wrote: First off, I am a new IPA admin, so please bear with me! I was wondering if something has changed recently...As of this past Friday, I was able to create Hosts under the Identity tab within the GUI. However, now it will not accept any IP address that I enter in. The message received is: Not a valid IP address (regardless of what I put into the field) When I force it without an IP address entered in, it goes through, but then I am not able to add the IP address into DNS manually afterwards because of the same error. When I try to add this host and record manually via the command line on the server, it fails with ipa: ERROR: did not receive Kerberos credentials. Trying through the GUI does not generate any error messages becasue it doesnt let me submit, it wont let me add the record at all. I have tried rebooting the server and restarting the service a few different times to no avail... Any thoughts or things that I can try? Heres the info on the ipa package installed: It sounds like you don't have a ticket when running on the command-line. Do a kinit first. You might check /var/log/httpd/error_log for additional details. You can enable server-side debugging by creating /etc/ipa/server.conf with the contents: [global] debug = True and restart httpd Not sure if you can, but it might be helpful to see what IP address you're trying to add. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] User admins for different groups
Dmitri Pal wrote: On 03/26/2013 11:55 AM, Rob Crittenden wrote: Petr Spacek wrote: On 26.3.2013 15:10, Rob Crittenden wrote: Philipp Richter wrote: On 03/26/2013 12:39 AM, Dmitri Pal wrote: I am trying to do the following: We have some branch offices at different locations. We want to use one ipa-server with replicas in each branch office. Each branch office should have it's own set of administrators who should be able to create/modify/delete users for its own branch but should not be allowed to change users from other branches. every member of admin-at should be forced to create/modify/delete only users in branch-at. The same applies for admin-us/branch-us. at first, i thought of a combination of (a) new role(s), with write/delete permissions set for the branch-at group, as well as an automember rule but it seems there is no way to filter for the creator of an entry, which would be needed for the group membership.. am i missing anything? This might help https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html#delegating-users Yes, I read the whole document but as far as I understand delegates are only helpful for editing existing records. I want admins of one branch to be able the also create users, but only in the assigned branch. Currently we use standard openldap with different ou's for the branches. Each branch admin has full ldap permissions for it's own ou-subtree. IPA uses a flat DIT so here is no way to control adding users in a given branch office. The most you'd be able to do is delegae management (delete/modify) a subset of users who are members of a group that represents that branch office. Any new users added would need to be added to the appropriate branch group by the admin adding them. This sounds like big deficiency to me... Is it possible to hack automember plugin to enforce some group assignment based on creator's group/name as proposed above? It should allow users to prepare some hand crafted ACIs, I guess. (Sorry, I don't have any knowledge about automember internals :-) Using automember doesn't prevent an admin from adding a user outside of the branch. It would just automatically assign that new user to the correct branch based on the automember rules AND assuming that the admin that added the user included the right information for the rules. ACIs control add at the subtree level, so for us it is a binary. Either you can add users or you can't. I think Petr was suggesting to be able to add new factor into the auto-member configuration. If the admin that adds a user has some property than the user needs to be automatically placed into a specific group. And admin would have ACIs against that group. Isn't what should happen to support the use case with the flat tree we have? The problem is we can't constrain a user from adding a user to the wrong branch. Once in the wrong branch, a delegated admin would have no way of administering it. There are two kinds of access controls, attribute-level (read, write, search) and entry-level (delete, add). So it is very possible to add an entry with attributes you aren't later allowed to modify. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] kinit seg-fault for Solaris 9
Hi again, I've got a bit more information. I've found that I can successfully kinit on the Solaris 9 clients if, on the server, I change the user's password by: ipa-getkeytab -s SERVER -p USER@REALM -k krb5.keytab -P This works even if I delete the resulting keytab file. However, kinit on the Solaris 9 client seg-faults if I set the user's password using the web gui, the 'passwd' or 'kpasswd' commands, or even the `ipa user-mod --password` command. There must be something different about how the ipa-getkeytab command stores the password. Any help would be greatly appreciated. Thanks, Dave ~~ On Tue, Mar 26, 2013 at 4:05 PM, Rob Crittenden rcrit...@redhat.com wrote: David Redmond wrote: Hi, I've setup FreeIPA for the first time and am using it successfully with Linux and Solaris 10 clients. On 8 separate Solaris 9 clients I'm running into an issue where 'kinit USER', for any user, fails with a segmentation fault after prompting for a password. On the client side there are no log entries. On the server side the Additional pre-authentication required entry is written to the log. When I execute 'kinit -k' everything works normally. I've verified that the keytabs for the Solaris 9 clients use only des-cbc-crc encryption and that allow_weak_crypto = true is set on the server side. Running 'truss kinit USER' on the Solaris 9 clients end with: Incurred fault #6, FLTBOUNDS %pc = 0xFF3582E4 siginfo: SIGSEGV SEGV_MAPERR addr=0x0004 Received signal #11, SIGSEGV (default) siginfo: SIGSEGV SEGV_MAPERR addr=0x0004 I've been fighting this for a while and have ensured that my Solaris 9 boxes are running the latest patches. Kerberos on the clients is the standard one that comes with Solaris. I've installed no additional kerberos components or packages. I'm hoping someone has seen this before or can point me in a new direction. At this point I've pretty much reached the end of my rope and am looking at using local passwords (blech!) on my Solaris 9 clients. I don't have a very helpful answer, but if memory serves my Sparc 9 install exhibits the same behavior. I don't have access to the latest updates though so I assumed it was related to that. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
