LDAP Authentication
This is a big one. It can be got from the MediaWiki Extensions Site. The instructions are pretty tough to follow, but it does work.Here are our settings in LocalSettings.php, in which the user is authenticated against the domain, and all users except those in a select group are disallowed from logging in.
A note about SSL encryption
SSL encryption is necessary to ensure this is a secure process. Especially given that we're talking about domain usernames and passwords. So first, make sure that the apache server is requiring https when accessing the wiki. Second, for the SSL piece of the LDAP authentication to work, the wiki server has to recognize and trust the root CA of the LDAP server (or, in our case, the LDAP virtual IP fronted by a netscaler device). I hope to have instructions on doing this piece posted soon. In any case, please do this before going further.
LocalSettings.php Contents
#LDAP authentication
require_once( "$IP/extensions/LdapAuthentication.php" );
#$wgLDAPDebug = 6;
$wgAuth = new LdapAuthenticationPlugin();
$wgLDAPDomainNames = array( "DOMAINNAME");
$wgLDAPServerNames = array( "DOMAINNAME"=>"ldapserver.FQDN" );
$wgLDAPSearchStrings = array( "domainname"=>"DOMAINNAME\\USER-NAME" );
$wgLDAPEncryptionType = array( "domainname"=>"ssl" );
$wgLDAPUseLocal = false;
$wgMinimalPasswordLength = 1;
$wgLDAPBaseDNs = array( "domainname"=>"dc=tcu,dc=edu" );
$wgLDAPSearchAttributes = array( "domainname"=>"sAMAccountName" );
#Everything above is for simple LDAP authentication; the stuff below is for group syncronization
#DNs in $wgLDAPRequiredGroups must be lowercase, as search result attribute values are...
$wgLDAPRequiredGroups = array( "domainname"=>array("Fully qualified LDAP cn structure goes here") );
$wgLDAPGroupUseFullDN = array( "domainname"=>true );
$wgLDAPLowerCaseUsername = array( "domainname"=>true, );
$wgLDAPGroupObjectclass = array( "domainname"=>"group" );
$wgLDAPGroupAttribute = array( "domainname"=>"member" );
$wgLDAPGroupSearchNestedGroups = array( "domainname"=>true );
$wgLDAPUseLDAPGroups = array( "domainname"=>"true" );
$wgLDAPGroupNameAttribute = array( "domainname"=>"cn" );
#Adding new groups to the list of possible groups. This value (the group name)
#also needs to be added to the user_groups table in the database. That happens manually.
$wgGroupPermissions['groupname']['edit']= true;
The first bit should be pretty self-explanatory: load the extension, then set the basic variables as specific to your environment. In the examples here, I have used "domainname" and "DOMAINNAME" instead of our true domain name. Case matters here, so stay sharp!
Note that the $wgLDAPBaseDNs variable is important; it must be correct. In most cases, this is the final bit of your domain name. For instance, if my domain is example.com, my base DN is also example.com.
#$wgLDAPDebug = 6;
$wgAuth = new LdapAuthenticationPlugin();
$wgLDAPDomainNames = array( "DOMAINNAME");
$wgLDAPServerNames = array( "DOMAINNAME"=>"ldapserver.FQDN" );
$wgLDAPSearchStrings = array( "domainname"=>"DOMAINNAME\\USER-NAME" );
$wgLDAPEncryptionType = array( "domainname"=>"ssl" );
$wgLDAPUseLocal = false;
$wgMinimalPasswordLength = 1;
$wgLDAPBaseDNs = array( "domainname"=>"dc=tcu,dc=edu" );
$wgLDAPSearchAttributes = array( "domainname"=>"sAMAccountName" );
#Everything above is for simple LDAP authentication; the stuff below is for group syncronization
#DNs in $wgLDAPRequiredGroups must be lowercase, as search result attribute values are...
$wgLDAPRequiredGroups = array( "domainname"=>array("Fully qualified LDAP cn structure goes here") );
$wgLDAPGroupUseFullDN = array( "domainname"=>true );
$wgLDAPLowerCaseUsername = array( "domainname"=>true, );
$wgLDAPGroupObjectclass = array( "domainname"=>"group" );
$wgLDAPGroupAttribute = array( "domainname"=>"member" );
$wgLDAPGroupSearchNestedGroups = array( "domainname"=>true );
$wgLDAPUseLDAPGroups = array( "domainname"=>"true" );
$wgLDAPGroupNameAttribute = array( "domainname"=>"cn" );
#Adding new groups to the list of possible groups. This value (the group name)
#also needs to be added to the user_groups table in the database. That happens manually.
$wgGroupPermissions['groupname']['edit']= true;
Likewise, $wgLDAPRequiredGroups is very specific, and if it's not just right, the whole thing will break. Note that ldapsearch--a piece of openssl--can be an extremely useful tool in determining the correct settings for all of this. If you're using linux, you very likely already will have this tool. If you're using Windows, dsget is an equivalent (as a part of Windows Server) that can really help you out of a jam. Many will recommend a web-base ldap browser, but, honestly, I think the command-line tools like ldapsearch and dsget are much easier to use and set up.
If you're having difficulty, uncomment the $wgLDAPDebug line, and it'll provide a lot of useful debugging information within the browser session.
User Rights Management
User rights management is done through groups. We use the domain groups for this purpose, but it's also necessary to tell MediaWiki about the groups, and how we'll use them. This is done in a single step:Defining group rights
Edit the LocalSettings.php file and add lines as below:
## The following three lines disable anonymous access
$wgGroupPermissions['*' ]['createaccount'] = false;
$wgGroupPermissions['*' ]['read'] = false;
$wgGroupPermissions['*' ]['edit'] = false;
$wgGroupPermissions['tcudba']['edit'] = true;
$wgGroupPermissions['user' ]['move'] = false;
$wgGroupPermissions['user' ]['read'] = true;
$wgGroupPermissions['user' ]['edit'] = false;
$wgGroupPermissions['user' ]['upload'] = false;
In the above example, the default group (user) only can read articles. Those who have not authenticated (*) cannot do anything in the wiki. Those in TCUDBA can edit documents.
$wgGroupPermissions['*' ]['read'] = false;
$wgGroupPermissions['*' ]['edit'] = false;
$wgGroupPermissions['tcudba']['edit'] = true;
$wgGroupPermissions['user' ]['move'] = false;
$wgGroupPermissions['user' ]['read'] = true;
$wgGroupPermissions['user' ]['edit'] = false;
$wgGroupPermissions['user' ]['upload'] = false;
There are a variety of possible permissions, which are detailed here. The table below shows a few of the more relevant permissions:
Permission | Description |
read | allows viewing pages not defined in $wgWhitelistRead |
edit | allows editing unprotected pages. |
createpage | allows the creation of new pages (requires the edit right). |
move | allows renaming page titles. |
upload | allows the creation of new images and files. |
createaccount | allows the creation of new user accounts. |
delete | allows the deletion of edits and pages. |
Modifying User Groups
An easy way to modify the Mediawiki database is to use PHPmyAdmin. Of course, whether you use a GUI or the command line, the data to modify is the same.After logging in to phpmyadmin, select the WIKIDB database on the left. Then select the user_groups table and click on the browse button. You'll see the userid and group name of all the users. Note that the userid is a number; you have to use the users table to find out which userid corresponds to which username. Use this method to get back as a sysop in the wiki if you've accidentally removed yourself from that group. If you're still a sysop, you simply can use the special:userrights page.
Troubleshooting
If you receive the error basedn is not set for this type of entry, trying to get the default basedn, that means that the $wgLDAPBaseDNs variable isn't set correctly. At the time of this writing, the correct value for that is$wgLDAPBaseDNs = array( "tcu"=>"dc=tcu,dc=edu" );
The following commands also can be helpful in determining if your system is set up correctly:
ldapsearch -x -D @TCU -W -b "dc=tcu,dc=edu" "sAMAccountName=" -H ldaps://ldap.example.com
openssl s_client -connect ldap.example.com:636
Hi
ReplyDeleteI have myself installed MediaWiki and the Ldap Authentication extension this week. I'm trying to get this working with Active Directory groups, but can't understand how to link AD groups with MediaWiki privileges. Could you exlapin me this line you wrote :
$wgGroupPermissions['tcudba']['edit'] = true;
Were did you create the TCUDBA group ?? I understand we can set privileges for the sysop and bureaucrat users, but how can we handle new ones ?
thanks
Michael
Excellent question. The 'tcudba' group, first of all, is a domain security group. It's one of the groups that is allowed to log in to the MediaWiki instance. If you've not locked down the instance any more than disallowing anonymous posting (and you don't want or need to), you don't need to worry about doing more than making sure it's in the LDAPRequiredGroups array.
ReplyDeleteIf, however, you want to assign permissions based on domain security group (which I'm assuming is what you want to do), you have to add this same group to the MediaWiki database, in the user_groups table.
To do this, open your database in whatever tool you'd like to use. If you're not familiar with MYSQL or other database products, I'd suggest installing MYSQL Administrator and MYSQL Query Browser, which can be got at this web page.
BTW, this is a good time to suggest backing up your MYSQL database. We're not talking about drastic modifications here, but you never know when something might go awry.
When you installed mediawiki, it asked for a database name and a table prefix. The default database name is 'wikidb', if I remember correctly. The table you need to open is called "user_groups". Note that it'll have any prefix you specified at installation.
(So if you specified "dbo_" as a prefix, the table name would be "dbo_user_groups".)
In short, add the group name to this table.
Here's the rub, though: that's not just a table for groups; it's a table that joins users to groups, and the users are specified by user_id, which is a number.
So here's what to do:
query the user table to find the number that corresponds to the user you'd like in your group.
Once you've got this number (let's say it was 3), open the user_group table and insert 3 into the ug_user field, and the group name in the ug_group field.
Once you've done this once, any user in that domain group who logs in to the MediaWiki instance will be placed in this group automatically.
And this group now can be used to set privileges, just as can be done with the sysop and bureaucrat groups.
If you run into trouble, let mw know.
Thanks for the quick response !
ReplyDeleteI'm a programmer/developper, so i'm familiar with SQL and queries, and I understood easily that the user_groups table is used to link users to one or more groups. [ You can go crazy on technical words and precision ;) ]
Your answer seems to be exactly what I need :) In my active directory, i have 3-4 groups : let's name them gp1 to gp4. This is what I will use them for :
gp1 = reader rights,
gp2 = contributor rights,
gp3 = editor/manager rights,
gp4 = admin rights .
In the settings file (DefaultSettings.php or LocalSettings.php), I will add those groups to the LDAPRequiredGroups array. Is that right ?
In my case, those groups are for privileges, not verified to allow log in. I think that the LDAPRequiredGroups array is for log in ... explanations ?
Adding my groups in the user_groups table of the MediaWiki database
What difference will that make ? It will just add one MediaWiki user in the group. What I want is every AD user to be put in the right MediaWiki group the first time he logs in, based on the AD groups he is in.
Still possible ?
If this require some custom modifications to the php code, i can do it - with your help ;) !
Michael
Do you think those 2 arrays would be usefull ??
ReplyDelete$wgLDAPLocallyManagedGroups
//A list of groups that won't automatically have their members
//removed, but will have them added. The sysop, bureaucrat, and bot
//groups are always considered locally managed.
$wgLDAPGroupsPrevail
//Get every group from LDAP, and add it to $wgGroupPermissions. This
//is useful for plugins like Group Based Access Control. This is very
//resource intensive, and probably shouldn't be used in very large
//environments.
//Default: false
Hi, Michael!
ReplyDeleteVery good: we should be able to get you set pretty quickly! :)
If you're not using the LDAP groups for authentication, but are just using them for permission, you don't need to add them to the LDAPRequiredGroups array. Once you've added the group to the database, Mediawiki then will automatically populate that group based on the LDAP information returned. This is good news, of course: it'll detect who is to be given what perms based on the LDAP group, once that group is added to the local MediaWiki DB.
If you have a small domain with just a few groups and users, it might be easy to use the $wgLDAPGroupsPrevail functionality, but the truth is that I've never used it: for one thing, we've got a very large domain, and for another, manually adding a few domain groups to the MediaWiki DB has given us all the functionality we need.
I think it will work quite well for you, too. By now you already may have got this all working, but if you haven't seen it already, I'd take a look at the wgGroupPermissions Manual Page on the MediaWiki Site. There they lay out all of the possible values for the that array, such that you can assign pretty specific rights to each group.
I hope that helps! -Lane
Ok, i wont use the $wgLDAPGroupsPrevail functionality. I added this record in the user_groups table :
ReplyDeleteINSERT INTO user_groups VALUES ('19','DevelopersGroup'). 19 is the userId of UserMike. Now, you tell me that when an other user will log in for the first time, if he is in the DevelopersGroup AD group, he will be put in the MediaWiki group with the same name ? Is that it (AD group and MediaWiki group names have to correspond) ? I'll try this, but I don't understand...
A MediaWiki group is not "created" when referenced in the user_groups table : it exists because it is in the $wgGroupPermissions array in the DeafultSettings.php file !!! Am I wrong ?
Also, in your AD, where are your domain groups for permission ? And where is your group for authentication ? Do they have to be in the same place or they can be totally distincts ? Which variables define where to look for the permission groups ?
thanks again for your help, Lane
I did some research. I went on this special page "title=Special:Permissions" with a user of the bureaucrat group. I selected a existing user and saw the groups i can take him off and those i can put him in. The "DevelopersGroup" ( that I previously added in the user_groups table ) wasn't there. Then I edited the DefaultSettings.php file, adding this line << $wgGroupPermissions['DevelopersGroup']['read'] = true; >> TADAM ! The "DevelopersGroup" appears in the choices of available groups !
ReplyDeleteI have not yet tested succesfully the authentication of a member of the DevelopersGroup in AD (because of basic binding problems). I'm working on it.
The authentication of a new AD user coming from a group named "Developers" in the "Users" group worked. BUT, this new user has not been added to the MediaWiki group "Developers"...? Here is the debug log :
ReplyDeleteEntering validDomain
User is using a valid domain.
Setting domain as: DOMAIN
Entering getCanonicalName
Username isn't empty.
Munged username: Mpicard
Entering userExists
Entering authenticate
Entering Connect
Using TLS or not using encryption.
Using servers: ldap://SERVERNAME.DOMAIN
Connected successfully
Entering getSearchString
Doing a straight bind
userdn is: Mpicard@DOMAIN
Binding as the user
Bound successfully
Entering getUserDN
Created a regular filter: (sAMAccountName=Mpicard)
Entering getBaseDN
basedn is not set for this type of entry, trying to get the default basedn.
Entering getBaseDN
basedn is DC=DO,DC=MA,DC=IN
Using base: DC=DO,DC=MA,DC=IN
Fetched username is not a string (check your hook code...). This message can be safely ignored if you do not have the SetUsernameAttributeFromLDAP hook defined.
Pulled the user's DN: CN=Maxim Picard,CN=Users,DC=DO,DC=MA,DC=IN
Retrieving LDAP group membership
Entering getUserGroups
Entering getGroups
Entering getBaseDN
basedn is not set for this type of entry, trying to get the default basedn.
Entering getBaseDN
basedn is DC=DO,DC=MA,DC=IN
Search string: (&(=CN=Maxim Picard,CN=Users,DC=DO,DC=MA,DC=IN)(objectclass=))
No entries returned from search.
Retrieving preferences
Retrieved: EMAIL, , Maxim Picard, Maxim Picard
Authentication passed
Entering initUser
Entering updateUser
Setting user preferences.
Setting user groups.
Entering setGroups.
Locally managed groups is unset, using defaults: bot,sysop,bureaucrat
Available groups are: Developers,bot,sysop,bureaucrat
Effective groups are: *,user,autoconfirmed
Checking to see if user is in: Developers
Entering hasLDAPGroup
Checking to see if user is in: bot
Entering hasLDAPGroup
Checking to see if user is in: sysop
Entering hasLDAPGroup
Checking to see if user is in: bureaucrat
Entering hasLDAPGroup
Saving user settings.
Entering authenticate
Entering Connect
Using TLS or not using encryption.
Using servers: ldap://SERVERNAME.DOMAIN
Connected successfully
Entering getSearchString
Doing a straight bind
userdn is: Mpicard@DOMAIN
Binding as the user
Bound successfully
Entering getUserDN
Created a regular filter: (sAMAccountName=Mpicard)
Entering getBaseDN
basedn is not set for this type of entry, trying to get the default basedn.
Entering getBaseDN
basedn is DC=DO,DC=MA,DC=IN
Using base: DC=DO,DC=MA,DC=IN
Pulled the user's DN: CN=Maxim Picard,CN=Users,DC=DO,DC=MA,DC=IN
Retrieving LDAP group membership
Entering getUserGroups
Returning short name group cache.
Retrieving preferences
Retrieved: EMAIL, , Maxim Picard, Maxim Picard
Authentication passed
Entering updateUser
Setting user preferences.
Setting user groups.
Entering setGroups.
Locally managed groups is unset, using defaults: bot,sysop,bureaucrat
Available groups are: Developers,bot,sysop,bureaucrat
Effective groups are: *,user,autoconfirmed
Checking to see if user is in: Developers
Entering hasLDAPGroup
Checking to see if user is in: bot
Entering hasLDAPGroup
Checking to see if user is in: sysop
Entering hasLDAPGroup
Checking to see if user is in: bureaucrat
Entering hasLDAPGroup
Saving user settings.
I don't either understand why almost everything seems to have been done twice ...
Will the mighty Lane be able to help me through this ? ;)
It worked !!!
ReplyDelete[ apologizes for filling your blog of my comments ]
I changed some settings, trying to figure things out. And i managed to authenticate an AD user in MediaWiki + adding him to the MediaWiki group with the same name. That deserves a celebration dance..................................... done.
Thanks to Lane for everything.
PS - If you are interested, I can post here my complete config code?
Michael, I'm glad it's working! I'd love to see your config file; it always helps folks to have a concrete example of a working config.
ReplyDeleteBTW, do you know which change fixed your problem?
Hoping this will help some, here is my complete config (what I think that solved my problem is bold text) :
ReplyDeleterequire_once 'extensions/LdapAuthentication.php';
$wgAuth = new LdapAuthenticationPlugin();
$wgLDAPDomainNames = array('DOMAIN');
$wgLDAPServerNames = array('DOMAIN' => 'SERVERNAME.DOMAIN');
$wgLDAPBaseDNs = array('DOMAIN' => 'DC=DO,DC=MA,DC=IN');
$wgMinimalPasswordLength = 1;
$wgLDAPSearchAttributes = array('DOMAIN' => 'sAMAccountName');
// Ne pas afficher l'adresse IP en haut de l'écran pour les utilisateurs non enregistrés
$wgShowIPinHeader = false;
// Chaine utilisée pour le straight bind
// USER-NAME sera remplacé par le username de celui qui s'authentifie
// Cette option ne doit pas être utilisée si on utilise un agent proxy avec mot de passe
$wgLDAPSearchStrings = array('DOMAIN' => 'USER-NAME@DOMAIN');
// ***** Autres syntaxes possibles *****
// 'cn=USER-NAME,CN=GROUP,DC=DO,DC=MA,DC=IN'
// "DOMAIN\\USER-NAME"
// Le objectclass des groupes qu'on cherche
$wgLDAPGroupObjectclass = array ('DOMAIN' => 'group');
// L'attribut utilisé pour les membres d'un groupe
$wgLDAPGroupAttribute = array ('DOMAIN' => 'member');
// L'attribut de nom dans un groupe
$wgLDAPGroupNameAttribute = array ('DOMAIN' => 'cn');
// Indique si on doit chercher dans les sous-groupes (pas utilisé présentement pour la synchronisation de groupes)
$wgLDAPGroupSearchNestedGroups = array('DOMAIN'=> false);
// Le type d'encryption à utiliser lors de la connexion au serveur LDAP (tls,ssl,clear)
$wgLDAPEncryptionType = array('DOMAIN' => 'clear'); //todo SSL
// Indique si on utilise la base de données locale ET la base de données LDAP
$wgLDAPUseLocal = false;
// Indique qu'on veut ramener des informations de l'Active Directory
$wgLDAPRetrievePrefs = array('DOMAIN' => true);
// Sert à mettre à jour les groupes de sécurité dans MediaWiki à partir des groupes LDAP
$wgLDAPUseLDAPGroups = array('DOMAIN'=> true);
// Indique si le username dans le groupe est un DN complet (habituel avec AD), ou juste un username seul
$wgLDAPGroupUseFullDN = array('DOMAIN' => true);
$wgLDAPGroupUseRetrievedUsername = array('DOMAIN' => true);
*Comments in my config are in french.
Lines in bold text were just not there before. Now, everything is working perfecto ! :) THANKS to Lane
NEXT STEP : Integrate SSL in there
Michael, thanks for posting your working(!) configuration.
ReplyDeleteI hope the rest goes smoothly!
-Lane
Everything works fine ! Now i would like to push this further : to auto-authenticate the user without asking him his username & password. I would like to bind to the AD as an admin user(with read/browse rights), then authenticate the real user by verifying his presence in the right place in AD.
ReplyDeleteMay those variables be usefull :
$_SERVER['AUTH_USER'] and $_SERVER['AUTH_PASSWORD']
Is that possible within your extension, or can i find another extension that does this ?? If this absolutely requires custom changes in the php code, show me the way and i'll do it.
Ah, now that _is_ pushing the boundaries!
ReplyDeleteI do want to be clear: I'm not the author of this extension; I'm no programmer, nor do I play one on T.V.
Having said that, I'm guessing what you're looking for is Windows' Integrated Authentication, such as is available in several IIS applications. We don't have this implemented, and I'm not sure how one would go about it, but this link looks promising on the old MediaWiki Meta site.
The gold standard, I'll bet, would be to talk with the guy who wrote this extension. His name is Ryan Lane, and he's very active on the discussion page of this extension here.
He's very helpful, so I'd recommend dropping him a line. If you find something that works, I'd love to hear about it; integrated authentication (true SSO) is kindof the holy grail these days.
The new version of the plugin (1.2a) supports integrated authentication plus the other niceties of the plugin (like group syncing, preference pulling, etc.).
ReplyDeleteI haven't yet written terribly good documentation on this yet, but it is doable.
You should even be able to do Kerberos authentication against an AD domain via Apache and mod_auth_kerb.
I pretty much just made the SSLAuth portion of the plugin more generic to handle any kind of webserver authentication.
Ryan, that's fantastic news. Thanks so much for posting that here; I know that's going to be a really popular feature!
ReplyDeleteGreat information! It's been very helpful in aiding to get a wiki going in our IT department. I've run into a bit of hangup though. I've got LDAP/AD authentication going and domain security groups have been setup. If a domain user isn't in one of the groups, they're denied access as it should be. However, if someone is in one of the groups, the MW permissions set in the LocalSettings file don't take effect.
ReplyDeleteIn addition, the same user groups that I create in the database via phpmyadmin, using one of the user_id number and the same domain group name, gets deleted when I login using one of the accounts in that group. It's really weird.
Any thoughts?
Hey Lane,
ReplyDeleteI think I figured it out. Looks like it had something to do with the way I was creating the user groups in the DB via PMA. Whenever I created the user group name and changed the corresponding ID value and saved the changes, it wouldn't retain the group.
However, when I just created the group, left the ID value at default, and then went back and changed the value after creating the group, it held. I doubt that's the real reason though, more than likely probably I clicked the wrong button along the way.
Anyhow, thanks for the blog, it's been a tremendous help.
Andre, I'm glad you got it working, and I'm pleased to know this was useful to you, as well. Thanks for taking the time to post your results!
ReplyDeletehello there ;) thanks for the great support to others, hope i can enjoy support too!
ReplyDeleteFollowing project:
Mediawiki in our company.
Domain "corp"
Every buisness unit got it Active Directery group.
In Addition, there are a lot of other groups too.
Depending on this groups, user should have different rights. We want to combine it with site based rights so i want to hise pages for users from the other business unit.
Example:
BU1: Type Users (read, edit)
- User A, B and C
BU2: Type Users (read, edit)
- User D, E and F
User A should be able to protect his page using group based access control or something like this.
He grants access to BU1 so only A, B and C can read this page.
In Adtition there is a group with admins in AD.
BU1_Admin: Type Admin (read, edit, delete...)
User A
Is this possible?
In summary, we have around
15 BU_user - AD groups
15 BU_admin - AD groups
15 BU_bureaucrat - AD groups
which are in interest for the wiki, these are new groups, beside there are 100 of other groups too.
1500 Users share in these groups. Maybe its possible to say that one user can only be in one wiki-group, should be enough.
So User A should be in all 3 groups BU1_Users, BU1_Admins and BU1_Bur...
Simply because his bureaucrat rights contain the subrights already, so he should be able to have access on all 3 groups of this BU.
Well, song story short, how to handle this?
Is it possible to map
"ADGroupBU1 -> WikigroupBU1" ?
Is it possible to say this group has administrator right?
Is it possible to secure pages using this sync. WikigroupBU1 and only this group is able to access?...
Thanks a lot, hope u understand :D
haha okay sorry or posting anonymous again, googleaccount posting seems to do not work.
ReplyDeleteSimply:
AD Group -> map to WikiGroup -> add several rights for this group -> protect page using this group -> only members of this group can access this page
thats all.
Hi all,
ReplyDeleteI recently added this extension to my mediawiki, it is wonderful!
I just have a quick question: Reading about how to configure the local settings.php to use this extension with Global Catalog I was unable to found a how-to-do-it solution. I'm not sure if my configuration is correct:
$wgLDAPDomainNames = array('[I'm not using a domain name just a random word because I'm trying to read the global catalog and not an specific domain]');
$wgLDAPServerNames = array("Global Catalog" => 'serverGC.com');
$wgLDAPPort = array("Global Catalog" => 389); //do I have to use this port or the 3268
Please, I would appreciate any direction.
In mediawiki says that $wgLDAPDomainNames is required, how this has to be configured if it is necessary to read the global catalog and not just one domain?
ReplyDeleteI always make pancakes for my family everyday and they love it. Thanks. keep it up
ReplyDeleteAi & Artificial Intelligence Course in Chennai
PHP Training in Chennai
Ethical Hacking Course in Chennai Blue Prism Training in Chennai
UiPath Training in Chennai