Creating a wildcard webserver certificate with your internal Microsoft CA

Robbie Roberts Blog OCS, Exchange & Technology

It is sometimes necessary to issue a wildcard certificate from your internal Microsoft CA, I had such a requirement this week and thought it would make a nice blog post.

The post assumes you have a Enterprise CA already deployed and a web server template deployed and available for enrolment.

First we need to create the certificate request that will be issued to your CA.

1. Logon to a Windows 2008 R2 or Windows 7 domain member

2. Open the certificates MMC snap-in

image

image

image

image

image

Now create the certificate request

3. Right click the Certificates folder which is found under the personal folder

4. Select All Tasks > Advanced Options > Create Custom Request

image

5. In the Certificate Enrolment Wizard Click Next

image

6. In the Certificate Enrollment Page select Custom Request > Proceed without enrolment Policy and then select Next

image

7. In the Custom Request Page select (No template) Legacy Key from…

View original post 379 more words

Exchange 2010 SP3 sets AllowCrossSiteRPCClientAccess back to false

Jason (Izzy) Sherry's Blog

If you have any scripts, like those used during the failover process, that use this cmdlet for Exchange 2010 you need to update them to set this value each time.

Just add “–AllowCrossSiteRPCClientAccess $True” to the cmdlet line when calling Set-DatabaseAvailabilityGroup, this assumes  you want to allow cross site RPC access without requiring your users to restart Outlook when their active database is moved to another AD Site.

Set-DatabaseAvailabilityGroup –AllowCrossSiteRPCClientAccess $True.

I’m pretty sure  I’ve seen this value reset back to $False with SP2 (RU unknown) also, so this “bug” might have existed before SP3. This switch was added, or really it started working, in SP2 RU3.

See this blog post for more details:
http://blogs.technet.com/b/rmilne/archive/2013/05/08/exchange-2010-dag-allowcrosssiterpcclientaccess-reverts-to-false.aspx

For general Exchange 2013 questions or to discuss non-support topics join the “Microsoft Exchange 2013” Facebook group I admin: https://www.facebook.com/groups/MSEX2013

For community based support goto TechNet forums: http://social.technet.microsoft.com/Forums/exchange/

View original post

Samba config with Windows Registry Editor

Look at

http://manpages.ubuntu.com/manpages/zesty/man5/smb.conf.5.html

When you would not use a smb.conf and edit under Windows

REGISTRY-BASED CONFIGURATION

       Starting with Samba version 3.2.0, the capability to store Samba
       configuration in the registry is available. The configuration is stored
       in the registry key HKLM\Software\Samba\smbconf. There are two levels
       of registry configuration:

        1. Share definitions stored in registry are used. This is triggered by
           setting the global parameter registry shares to “yes” in smb.conf.

           The registry shares are loaded not at startup but on demand at
           runtime by smbd. Shares defined in smb.conf take priority over
           shares of the same name defined in registry.

        2. Global smb.conf options stored in registry are used. This can be
           activated in two different ways:

           Firstly, a registry only configuration is triggered by setting
           config backend = registry in the [global] section of smb.conf. This
           resets everything that has been read from config files to this
           point and reads the content of the global configuration section
           from the registry. This is the recommended method of using registry
           based configuration.

           Secondly, a mixed configuration can be activated by a special new
           meaning of the parameter include = registry in the [global] section
           of smb.conf. This reads the global options from registry with the
           same priorities as for an include of a text file. This may be
           especially useful in cases where an initial configuration is needed
           to access the registry.

           Activation of global registry options automatically activates
           registry shares. So in the registry only case, shares are loaded on
           demand only.

       Note: To make registry-based configurations foolproof at least to a
       certain extent, the use of lock directory and config backend inside the
       registry configuration has been disabled: Especially by changing the
       lock directory inside the registry configuration, one would create a
       broken setup where the daemons do not see the configuration they loaded
       once it is active.

       The registry configuration can be accessed with tools like regedit or
       net (rpc) registry in the key HKLM\Software\Samba\smbconf. More
       conveniently, the conf subcommand of the net(8) utility offers a
       dedicated interface to read and write the registry based configuration
       locally, i.e. directly accessing the database file, circumventing the

Linux Kernel 4.13 change standard mount options for smb 1

Hello,

good news. You are using Linux with Kernel 4.13 so that can happend that you get a mount error by mounting a smb share. Why happend this?
You are mounting a SMB 1 share.

Since Kernel 4.13 it will be tried to mount with version 3.

See git commit

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=eef914a9eb5eb83e60eb498315a491cd1edc13a1

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2a38e12053b760a8f5e85030eb89512660077c15

 

You should use SMB in Version 2.1 or higher

SMB 1.0 is broken, see blog post from Microsoft

https://blogs.technet.microsoft.com/filecab/2016/09/16/stop-using-smb1/

 

 

 

gitlab ldap groups

It´s not very easy to understand with the ce edition.

 

Here is my working config with gitlab ce 10

Before you edit your gitlab.rb please make a backup

 cp /etc/gitlab/gitlab.rb /etc/gitlab/gitlab.rb_org

 

Please remember your are editing a yaml file, yaml files are sensitiv for spaces etc

gitlab_rails[‘ldap_enabled’] = true

gitlab_rails[‘ldap_servers’] = YAML.load <<-EOS # remember to close this block with ‘EOS’ below
main:
label: ‘ActiveDirectory’
host: ‘dc01.example.com’
port: 389 #Change to 636 if using LDAPS
method: ‘plain’ # Change to “tls” if using LDAPS
uid: ‘sAMAccountName’ # Don’t change this
bind_dn: ‘CN=gitlab,OU=users,DC=example,DC=com’
password: ‘mypassowrd’
timeout: 10
active_directory: true
allow_username_or_email_login: false
block_auto_created_users: false
base: ‘DC=example,DC=com’
# Optional: the next line specifies that only members of the user group “gitlab-users” can authenticate to Gitlab:
user_filter: ‘(memberOf=CN=grpGitlab,OU=Application,OU=Servers,DC=example,DC=com)’
EOS

 

 

Attention i have tried a lots of user_filter examples there variants are working for me.

Check your LDAP Access and Group Members


gitlab-rake gitlab:ldap:check

Most found there

https://www.caseylabs.com/setup-gitlab-ce-with-active-directory-authentication/

Redirect to the Remote Web Access pages (/RDWeb)

msfreaks

If you have published Remote Desktop Web Access out of the box, and you visit
http(s)://<url for remote desktop web access>, you’ll be presented with the IIS welcome page:
IIS Welcome page

To prevent this you need to redirect the root to /RDWeb.

On the RD Web Access server(s) open Internet Information Services (IIS) Manager (it’s under Administrative Tools).
Expand the tree and click Default Web Site, then open the “HTTP Redirect” app:
HTTP Redirect
Fill in the redirect path, don’t forget to check “Only redirect requests to content in this directory”, and click apply.

That’s it. No need to reset IIS. This is tested to be working on Windows 2012 and Windows 2012 R2 versions of RD Web Access.

As an added bonus, HTTP requests are redirected to HTTPS as well.

Arjan

View original post