Re: [Freeipa-users] Extending schema
On 10/16/2011 04:53 PM, Sigbjorn Lie wrote: On 10/14/2011 03:14 PM, Jenny Galipeau wrote: - Original Message - On Thu, 2011-10-13 at 15:44 +0200, Sigbjorn Lie wrote: Hi, What is your recommendations for avoiding incompatability with future upgrades of IPA if extending the dirsrv schema and adding custom objects to the LDAP server is required? What considerations and precautions should be taken? Such as adding RBAC support for Solaris clients... Additional schema is unlikely to cause issues if it does not conflict with standard schema. We also tend to prefix all the attributes/objectlasses we create for FreeIPA so name clashes are unlikely. If it is custom schema I suggest you to prefix names appropriately too, so you have your own 'namespace'. As for placement I suggest you put this data in a separate container from standard FreeIPA stuff for new objects. In the base DN create a container named something like your company name or ticker: cn=ACME,suffix and put all your customized entries there. Attaching additional data to users is not a big deal for custom schema. If it is not custom schema but standard schema not currently used by FreeIPA I would be a little bit more careful as a following version of FreeIPA might conceivably start using those attributes, and there is generally enough space to use them in a sort of 'incompatible' way. But don't let that stop you if you really need it. Please note that when adding additional objectclasses to users and/or group etc ... if there are required attributes in the new objectclasses, you will no longer be able to add these objects from Web UI and you will not be able to define values for the new attributes introduced from the Web UI withoutcustomization. You will have to use the CLI and the --setattr option with the command. Thank you both, I will keep that in mind. Since Solaris RBAC is what I need at this point, is there any plans of including support for Solaris' RBAC at some point? No, not really. We found that very limiting for different applications and RBAC model is very different depending on the context and resources being deal with by the app. So we decided not to spend time on this effort but contributions are always welcome ;-) Regards, Siggi ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, 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] Extending schema
- Original Message - On Thu, 2011-10-13 at 15:44 +0200, Sigbjorn Lie wrote: Hi, What is your recommendations for avoiding incompatability with future upgrades of IPA if extending the dirsrv schema and adding custom objects to the LDAP server is required? What considerations and precautions should be taken? Such as adding RBAC support for Solaris clients... Additional schema is unlikely to cause issues if it does not conflict with standard schema. We also tend to prefix all the attributes/objectlasses we create for FreeIPA so name clashes are unlikely. If it is custom schema I suggest you to prefix names appropriately too, so you have your own 'namespace'. As for placement I suggest you put this data in a separate container from standard FreeIPA stuff for new objects. In the base DN create a container named something like your company name or ticker: cn=ACME,suffix and put all your customized entries there. Attaching additional data to users is not a big deal for custom schema. If it is not custom schema but standard schema not currently used by FreeIPA I would be a little bit more careful as a following version of FreeIPA might conceivably start using those attributes, and there is generally enough space to use them in a sort of 'incompatible' way. But don't let that stop you if you really need it. Please note that when adding additional objectclasses to users and/or group etc ... if there are required attributes in the new objectclasses, you will no longer be able to add these objects from Web UI and you will not be able to define values for the new attributes introduced from the Web UI withoutcustomization. You will have to use the CLI and the --setattr option with the command. ~ Jenny Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Extending schema
Hi, What is your recommendations for avoiding incompatability with future upgrades of IPA if extending the dirsrv schema and adding custom objects to the LDAP server is required? What considerations and precautions should be taken? Such as adding RBAC support for Solaris clients... Regards, Siggi ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Extending schema
On Thu, 2011-10-13 at 15:44 +0200, Sigbjorn Lie wrote: Hi, What is your recommendations for avoiding incompatability with future upgrades of IPA if extending the dirsrv schema and adding custom objects to the LDAP server is required? What considerations and precautions should be taken? Such as adding RBAC support for Solaris clients... Additional schema is unlikely to cause issues if it does not conflict with standard schema. We also tend to prefix all the attributes/objectlasses we create for FreeIPA so name clashes are unlikely. If it is custom schema I suggest you to prefix names appropriately too, so you have your own 'namespace'. As for placement I suggest you put this data in a separate container from standard FreeIPA stuff for new objects. In the base DN create a container named something like your company name or ticker: cn=ACME,suffix and put all your customized entries there. Attaching additional data to users is not a big deal for custom schema. If it is not custom schema but standard schema not currently used by FreeIPA I would be a little bit more careful as a following version of FreeIPA might conceivably start using those attributes, and there is generally enough space to use them in a sort of 'incompatible' way. But don't let that stop you if you really need it. 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] Extending Schema, CLI and Web UI for use with Samba 3 (groups!)
Ryan Thomson wrote:
Hello,
I'm trying to follow various steps and instructions I've found online for
extending FreeIPA v2 for use with Samba 3 as the LDAP backend. Things have
mostly gone well but I've hit a road block that I can't quite figure out.
Basically, I'm trying to get every new group added to FreeIPA (either via CLI
or Web UI) to automagically become a valid samba group with sambaGroupMapping
(and thus sambaSid and sambaGroupType).
Here's what I've done this far:
1. Added an ipaUserObjectClasses attribute with value sambaSAMAccount to
cn=ipaConfig,cn=etc,$SUFFIX. This works as expected for generating Samba hashes
for users on password changes.
2. Configured the DNA plugin to automatically add a sambaSid attribute to every
user with a sambaSAMAccount objectClass and group with sambaGroupMapping
objectClass:
# SambaSid, Distributed Numeric Assignment Plugin, plugins, config
dn: cn=SambaSid,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config
objectClass: top
objectClass: extensibleObject
dnatype: sambaSID
dnaprefix: S-1-5-21-3180075094-3347106287-3821849995-
dnainterval: 1
dnamagicregen: assign
dnafilter: (|(objectclass=sambasamaccount)(objectclass=sambagroupmapping))
dnascope: dc=fmri,dc=ubc,dc=ca
cn: SambaSid
dnanextvalue: 15289
This works as expected.
3. Added an ipaGroupObjectClasses attribute with value sambaGroupMapping to
cn=ipaConfig,cn=etc,$SUFFIX. This works as expected, adding the objectClass
sambaGroupMapping to every new group (and thus requiring sambaSid and
sambaGroupType attributes).
4. Extended the schema (correct terminology?) using ipaCustomFields with (unquoted) value
Samba Group Type,sambagrouptype,true.
5. Extended the CLI in group.py (.../site-packages/ipalib/plugins/group.py)
like so:
--- group.py.orig 2011-08-15 14:59:48.570715207 -0700
+++ group.py2011-08-16 12:43:43.493236507 -0700
@@ -118,6 +118,13 @@
label=_('GID'),
doc=_('GID (use this option to set it manually)'),
),
+Int('sambagrouptype',
+cli_name='sgt',
+label=_('Samba Group Type'),
+doc=_('Samba Group Type (default is 4)'),
+default=4,
+autofill=True,
+),
)
api.register(group)
However, when I try to add a group with ipa group-add groupname --desc=Group
desc I get the following output:
ipa: ERROR: missing attribute sambaGroupType required by object class
sambaGroupMapping
and if I turn on the debugging, I see the following lines:
ipa: DEBUG: raw: group_add(u'groupname', description=u'Group desc',
sambagrouptype=4, nonposix=False, all=False, raw=False, version=u'2.1')
ipa: DEBUG: group_add(u'groupname', description=u'Group desc',
sambagrouptype=4, nonposix=False, all=False, raw=False, version=u'2.1')
Which looks like my edit of group.py is doing what I expected it to do... but
the IPA server is still returning the missing attribute error.
However, if I use --addatr=sambagrouptype=4 as an argument to ipa group-add,
it works fine and the attribute is added and the group is created.
What am I missing?
Thank you,
This all looks fine. Did you restart the httpd process after making the
changes to group.py?
rob
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Extending Schema, CLI and Web UI for use with Samba 3 (groups!)
On 08/16/2011 03:50 PM, Ryan Thomson wrote:
Hello,
I'm trying to follow various steps and instructions I've found online for
extending FreeIPA v2 for use with Samba 3 as the LDAP backend. Things have
mostly gone well but I've hit a road block that I can't quite figure out.
Basically, I'm trying to get every new group added to FreeIPA (either via CLI
or Web UI) to automagically become a valid samba group with sambaGroupMapping
(and thus sambaSid and sambaGroupType).
Here's what I've done this far:
1. Added an ipaUserObjectClasses attribute with value sambaSAMAccount to
cn=ipaConfig,cn=etc,$SUFFIX. This works as expected for generating Samba
hashes for users on password changes.
2. Configured the DNA plugin to automatically add a sambaSid attribute to
every user with a sambaSAMAccount objectClass and group with
sambaGroupMapping objectClass:
# SambaSid, Distributed Numeric Assignment Plugin, plugins, config
dn: cn=SambaSid,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config
objectClass: top
objectClass: extensibleObject
dnatype: sambaSID
dnaprefix: S-1-5-21-3180075094-3347106287-3821849995-
dnainterval: 1
dnamagicregen: assign
dnafilter: (|(objectclass=sambasamaccount)(objectclass=sambagroupmapping))
dnascope: dc=fmri,dc=ubc,dc=ca
cn: SambaSid
dnanextvalue: 15289
This works as expected.
3. Added an ipaGroupObjectClasses attribute with value sambaGroupMapping to
cn=ipaConfig,cn=etc,$SUFFIX. This works as expected, adding the objectClass
sambaGroupMapping to every new group (and thus requiring sambaSid and
sambaGroupType attributes).
4. Extended the schema (correct terminology?) using ipaCustomFields with
(unquoted) value Samba Group Type,sambagrouptype,true.
5. Extended the CLI in group.py (.../site-packages/ipalib/plugins/group.py)
like so:
--- group.py.orig 2011-08-15 14:59:48.570715207 -0700
+++ group.py 2011-08-16 12:43:43.493236507 -0700
@@ -118,6 +118,13 @@
label=_('GID'),
doc=_('GID (use this option to set it manually)'),
),
+Int('sambagrouptype',
+cli_name='sgt',
+label=_('Samba Group Type'),
+doc=_('Samba Group Type (default is 4)'),
+default=4,
+autofill=True,
+),
)
api.register(group)
However, when I try to add a group with ipa group-add groupname
--desc=Group desc I get the following output:
ipa: ERROR: missing attribute sambaGroupType required by object class
sambaGroupMapping
and if I turn on the debugging, I see the following lines:
ipa: DEBUG: raw: group_add(u'groupname', description=u'Group desc',
sambagrouptype=4, nonposix=False, all=False, raw=False, version=u'2.1')
ipa: DEBUG: group_add(u'groupname', description=u'Group desc',
sambagrouptype=4, nonposix=False, all=False, raw=False, version=u'2.1')
Which looks like my edit of group.py is doing what I expected it to do... but
the IPA server is still returning the missing attribute error.
However, if I use --addatr=sambagrouptype=4 as an argument to ipa
group-add, it works fine and the attribute is added and the group is created.
What am I missing?
Thank you,
Should we open a ticket and have a way to just turn this integration on?
Something like ipa-server-install install flag --samba-integration. Then
it will translate into enabling all of the above at the install time or
after.
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IPA project,
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] Extending Schema, CLI and Web UI for use with Samba 3 (groups!)
On Tue, 2011-08-16 at 16:50 -0400, Dmitri Pal wrote: Should we open a ticket and have a way to just turn this integration on? Something like ipa-server-install install flag --samba-integration. Then it will translate into enabling all of the above at the install time or after. It may conflict with the adtrust work if not done right, so I would prefer to do this as part of the 3.0-Trust work. 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] Extending Schema, CLI and Web UI for use with Samba 3 (groups!)
On 08/16/2011 05:11 PM, Simo Sorce wrote: On Tue, 2011-08-16 at 16:50 -0400, Dmitri Pal wrote: Should we open a ticket and have a way to just turn this integration on? Something like ipa-server-install install flag --samba-integration. Then it will translate into enabling all of the above at the install time or after. It may conflict with the adtrust work if not done right, so I would prefer to do this as part of the 3.0-Trust work. Simo. I am not suggesting to do it earlier. Can you please create a ticket to track it as a part of the trust effort? -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, 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
