I'm looking for any way to extend the LDAP person / organizationalPerson Object by one attribute (userPrincipalName) in order to mimic the structure of an Active Directory for testing purposes. I'm an absolute LDAP newbie using OpenLDAP via docker. Looking for the easiest way possible, it can be hackish since its not running with production data. I'm struggling hard with the manuals / articles about the topic. I stumbled upon this SO post but I have no idea about an implementation: Extending a default schema in OpenLDAP
I tried adding a user_attr.ldif file looking like this:
dn: cn={0}core,cn=schema, cn=config
changetype: modify
add: olcAttributeTypes
olcAttributeTypes: ( 1.2.840.113556.1.4.656
NAME 'userPrincipalName'
DESC 'MSDN Active Directory UPN'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX '1.3.6.1.4.1.1466.115.121.1.15'
SINGLE-VALUE )
That seems to work when included in my slapd-init.sh.
Now the question is, how to extend the person class schema to include with this defined attribute? So far all my attempts failed unfortunately.
In the end I want to be able to add userPrincipleName to my user definition files which doesn't work right now Object class violation (65); additional info: attribute 'userPrincipalName' not allowed.
My user definition looks like so:
dn: cn=Amy Wong+sn=Kroker,ou=_employees,DC=foo,DC=bar
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: InetOrgPerson
cn: Amy Wong
sn: Kroker
memberOf: CN=some_group,OU=_Groups,DC=foo,DC=bar
userPrincipalName: amy#planetexpress.com
userPassword:: e1NTSEF9d0p2OXMyWjltMGJTMFIxV1k3QjdCRWZEVVZPQzg2Y3BWL3VDMHc9PQ==
Could anyone please guide me into the right direction? As said, I even take dirty shortcuts if necessary since this is for dev / testing purposes only.
best regards,
Andi
PS: Just to be precise here - I know how to modify existing records / data, I want to add an attribute to a core objectClass!
Related
I need to admit that I am a beginner with AD DS Schema.
I want to make some user attribute fields required at the time of creating a user account in AD.
I followed the instructions in the article here. I made a mistake (don't remember which values I set in mustContain attribute) now I can't create an active directory account I would like to query mustContain attribute in class= user to find the values in mustContain. I tried ldp.exe search but confuse what parameters in need to use in search function.
Probably you would need to set up your Base DN to CN=User,CN=Schema,CN=Configuration,DC=... and Scope to Base. In the Attributes section put mustContain or leave asterisk to get all the attributes.
How can I get all users properties like (email, address, phone and etc..)
using search filter syntax?
Can't find anything in the docs.
I tried this
(&(objectCategory=person)(objectClass=user)(cn=Erika Wynn))
but all I get is the dn details :
CN=Erika Wynn,CN=Users,DC=****,DC=local
I wish to get all user fields General (telephone, email..), Address (Street, City), Organization.
LDAP allows you to specify which attributes you want to receive. If you do not specify anything, Active Directory will return every attribute that has a value. So if it is not doing that in your case, then there must be some part of the code that has set the list of attributes to only the distinguishedName.
You will have to show your code for us to help you more. You can update your question to include your code.
I should of just provide a user name similar to AD login, as a filter and any attribute I needed to get.
I used this great article, to get all the different attributes that you can fetch from Active Directory.
https://www.manageengine.com/products/ad-manager/help/csv-import-management/active-directory-ldap-attributes.html
this is the query:
filter=(sAMAccountName=username) attributes=cn,department,company,streetAddress,L,st,co,mail
I'm quite new with Django, and so far I have a pretty basic setup where I attach an extra model to the default User model from (django.contrib.auth.models). In my accounts.models.py I have something in the line of:
class UserExtension(models.Model):
user = models.OneToOneField(User, primary_key=True)
# more code
I also have another model which needs to be specified an owner. My question is: Which is the better (more django-ish, more readable, more efficient, more flexible) way to signify the owner:
class Owned(models.Model):
# code
owner = models.ForeignKey(User)
# more code
or:
class Owned(models.Model)
# code
owner = models.ForeignKey(UserExtension)
# more code
I'll really appreciate if you mention pros and cons of those approaches.
I'd recommend the first option. The user model is the nontrivial model in the sense that an owned object should not be able to exist without a user, but could exist without a UserExtension.
Also consider that in Django 1.5 you are able to create custom user model, eliminating the need for the UserExtension class. See the documentation for more information.
Consider using UserProfile for any per user add-on information. Check out this blog to see how to do it. Then you can be assured that you are creating UserProfile object every time you create the User.
Now whether you FK on User or UserProfile depends logically on what you are doing within Owned. If Owned works with User's data/field, FK on User; if it works with UserProfile's data, FK on UserProfile.
The AD administrator at my company added a custom attribute to the Active Directory schema. The name assigned to this attribute is just plain wrong, and I want it to be corrected. Is there any way to change the name of a custom attribute, or remove it from the schema?
The icing on this cake is that he tossed it directly into the production environment.
Your help is appreciated!
As far as I know, it's not possible to rename an attribute in Active-Directory Schema.
To Handle your problem I will :
first create the new (well spelled) attribute in the Shema (Make sure the schema is replicated).
Search all the objects with the old (plain wrong) attribute then copy the value to the new attribute AND remove the value from the old attribute.
Then you'll find here under an LDIF script that allow to place an attribute as defunct. The strange way it's done (renaming in the schema definition all the attributes where the name is present) allow you to recreate an attribute with the same name (for example if you want to change the syntax of the attribute). It's supposed to work up to W2K3R2 (dont test on W2K8R2).
dn: CN=slxMesPotes,CN=Schema,CN=Configuration,DC=XXXX
changetype: modrdn
newrdn: cn=slxMesPotesOld
deleteOldRdn: 1
dn: CN=slxMesPotesOld,CN=Schema,CN=Configuration,DC=XXXX
changetype: modify
replace: adminDisplayName
adminDisplayName: slxMesPotesOld
-
dn: CN=slxMesPotesOld,CN=Schema,CN=Configuration,DC=XXXX
changetype: modify
replace: lDAPDisplayName
lDAPDisplayName: slxMesPotesOld
-
dn: CN=slxMesPotesOld,CN=Schema,CN=Configuration,DC=XXXX
changetype: modify
replace: isDefunct
isDefunct: TRUE
-
I have an application that pulls user information from an OU in Active Directory. The parameters it takes are a base for the search and a filter string.
I have an OU I want to pull information from, but there is a sub OU I want to avoid:
Wanted
users from OU=People,DC=mydomain,DC=com
Not Wanted
users from OU=Evil,OU=People,DC=mydomain,DC=com
I know that this could be done by rewriting the application performing teh import to stop it searching sub-OUs, but is there any way to do this with an LDAP filter on the search? Something like (DistinguishedName !contains "Evil") or similar that will let me exclude users based on the path to the user, rather than filtering on a property of the user.
If you're using System.DirectoryServices(.Protocols) in .NET you could set the SearchScope to OneLevel to only search in the People-OU (and no child-OUs). But that won't work if you have any OU=Good,OU=People,DC=mydomain,DC=com...
The second option would be to query the People-OU for all sub-OU:s (objectClass=organizationalUnit) and then issue multiple search requests; one for each of them (except the "Evil" one).
Edit: #geoffc - that will be really difficult to implement. By default all authenticated users have read access to all objects in Active Directory. Just setting a "Deny Read" on the Evil OU won't do the trick because the read right for authenticated users is set on the individual user object (in this case) and thus has precedence over the Deny ACL set on the OU. You will essentially have to set the Deny Read ACL on each of the objects in the Evil-OU and always make sure new objects added to the directory get the same Deny rights set. You could edit the Active Directory schema and remove the rights for Authenticated Users but that will break a lot of other things (including Exchange) and is not supported by Microsoft.
AFAICT, this cannot be done with an LDAP filter in active directory. Many other LDAP implementations support extensible matching, but AD does not.
Users recommending filters containing (ou:dn:=Evil) or wildcards on distinguishedName have not tested against Active Directory.
The following will do the trick:
(&(objectClass=user)(!(distinguishedName:=%Evil%)))
I ran into a similar problem while building an address book for scan to e-mail.
I tried (&(objectClass=user)(!(distinguishedName:=*Evil*))) but it seems that some MFP's don't accept * as a wildcard, but they do accept %
According to http://www.zytrax.com/books/ldap/apa/component.html, it's possible to get what you want using LDAP Component Filters. Here's an example that would match what you describe:
(&(objectClass=organizationalUnit)(!(ou:dn:=Evil)))
This matches all objects who have an objectClass of organizationUnit, but rejects anything whose DN contains a component that matches ou=Evil.
The objectClasses organizationalUnit and its descendant inetOrgPerson allow the attribute ou to be present in an entry. Add an ou attribute with value evil to the objects subordinate to the ou=evil branch and include the assertion (!(ou=evil)) to the search filter to limit responses from the candidate list to those that do not contain an attribute ou with the value evil. Alternatively, the LDAP Assertion Control could be used on requests in the same fashion to ensure that requests that contain an ou with the value evil are not processed. Professional quality directory servers that are LDAP compliant will support both of these methods.