freeipa

0 Fork 0

Files

T

Simo Sorce 7a20fc671b Allow to specify Kerberos authz data type per user

Like for services setting the ipaKrbAuthzData attribute on a user object will
allow us to control exactly what authz data is allowed for that user.
Setting NONE would allow no authz data, while setting MS-PAC would allow only
Active Directory compatible data.

Signed-off-by: Simo Sorce <simo@redhat.com>

Ticket: https://fedorahosted.org/freeipa/ticket/2579
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>

2016-03-09 19:00:43 +01:00

certmonger

Refactor ipautil.run

2015-12-14 10:54:23 +01:00

conf

mod_auth_gssapi: Remove ntlmssp support and restrict mechanism to krb5

2015-11-26 15:20:19 +01:00

ffextension

webui: append network.negotiate-auth.trusted-uris

2014-09-11 09:41:51 +02:00

html

Drop configure.jar

2015-11-13 14:02:45 +01:00

migration

Remove unused imports

2015-12-23 07:59:22 +01:00

oddjob

replica promotion: fix AVC denials in remote connection check

2016-02-11 18:40:39 +01:00

Fix URL for reporting bugs in strings

2016-03-01 15:26:52 +01:00

restart_scripts

Move freeipa certmonger helpers to libexecdir.

2016-02-26 08:29:44 +01:00

Allow to specify Kerberos authz data type per user

2016-03-09 19:00:43 +01:00

tools

pylint: supress false positive no-member errors

2016-03-02 14:57:36 +01:00

webui: fail nicely if cookies are disabled

2016-03-03 17:33:13 +01:00

updates

Configure 389ds with "default" cipher suite

2016-03-09 10:04:58 +01:00

wsgi

Modernize 'except' clauses

2015-08-12 18:17:23 +02:00

configure.ac

CONFIGURE: Replace obsolete macros

2016-03-08 20:02:27 +01:00

Makefile.am

trusts: add support for one-way trust and switch to it by default

2015-07-08 01:56:52 +02:00

README.schema

Add some basic rules for adding new schema

2010-08-27 13:40:37 -04:00

README.schema

Ground rules on adding new schema

Brand new schema, particularly when written specifically for IPA, should be
added in share/*.ldif. Any new files need to be explicitly loaded in
ipaserver/install/dsinstance.py. These simply get copied directly into
the new instance schema directory.

Existing schema (e.g. in an LDAP draft) may either be added as a separate
ldif in share or as an update in the updates directory. The advantage of
adding the schema as an update is if 389-ds ever adds the schema then the
installation won't fail due to existing schema failing to load during
bootstrap.

If the new schema requires a new container then this should be added
to install/bootstrap-template.ldif.